Subject: RE: Security

From: "Choudhary, Abdur R (Rahim)" <[email-masked]>
Date: Wed, 16 Oct 2002 12:16:28 -0400

Thank you for the input. I did not mean to suggest that there ought to be competing Security Policies at layer 3. What I did mean to suggest is that, the Security is a fairly dynamic field at this time. We expect that the requirements and operational environment will change, and do so at a speed that might not be slow enough for the current approach that IETF seems to have taken. For instance try to see how the approach would accommodate requirements for "Security Auditing in VoIP".

The current IETF approach is illustrated by the work at IPSecurity Policy. What they have done is effectively the following. Take the RFC 3060 (Policy Core Information Model - Version 1 Specification) and use it to formulate the following IDs (no RFC yet released).
	IPsec Configuration Policy Model 
	IP Security Policy Requirements 
	IPSec Policy Information Base 
	IPsec Policy Configuration MIB  

This process tries to take a big leap. Such a big leap may be possible at the first stage. However in view of the dynamic nature of the Security requirements and operational scenarios, such a leap might not be possible within the available time (that depends on how fast the things in the security landscape change).

I therefore tried to suggect a more efficient approach. I will rephrase it below.

An RFC like 3060 could first be translated into a Security Policy Framework. This means the following efforts.

1. First examine the work that went into RFC 3060 from a Security focused perspective. Hopefully this will not mean changes to RFC 3060 itself.

2. Formulate a "Security Policy Framework" and document it in an RFC (call it RFC xxxx). This would specialise the RFC 3060 to the Security landscape. However it would be reusable to formulate an RFC for the IPSec Policy (call it RFC yyyy), in a similar sense in which RFC 3060 is specialised to formulate RFC xxxx.

The above approach would be facilitated via a Security Policy Working Group, that currently does not exist at IETF. (Of course there are some "rationale" issues that I have not repeated here).

Thanks and Regards
Rahim

Note: Note: My thoughts are personal to myself, and do not represent my employer.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, October 15, 2002 2:25 PM
To: Choudhary, Abdur R (Rahim)
Cc: [email-masked]
Subject: Re: Security 

The reason there's only IPSec at its level is because having two competing
ways to do it there is probably counterproductive (even at higher levels,
the only reason there's both OpenPGP and S/MIME is because the two have
radically different trust models).

Another reason why you only see IPSec at that level is because it's mostly a
"done deal" - the Internet has decided that IPSec is the way to provide the
functions it provides.  You tuned in about 5 years too late to see the competing
proposals that have since evaporated in the mists of time...
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: "Perry E. Metzger" <[email-masked]>
Date: 16 Oct 2002 14:19:41 -0400

"Choudhary, Abdur R (Rahim)" <[email-masked]> writes:
> Thank you for the input. I did not mean to suggest that there ought
> to be competing Security Policies at layer 3. What I did mean to
> suggest is that, the Security is a fairly dynamic field at this
> time. We expect that the requirements and operational environment
> will change, and do so at a speed that might not be slow enough for
> the current approach that IETF seems to have taken. For instance try
> to see how the approach would accommodate requirements for "Security
> Auditing in VoIP".

1) The IETF is not a monolithic entity. It is a group of engineers. If
   you wish to propose a new security protocol, nothing prevents you
   from doing so. If consensus is that it is good, it would even end
   up published as a standard.
2) Repeating: the IETF does not have an "approach". It is a group of
   engineers, not an organism. It does not have a single opinion. It
   has a set of documents it has produced.
3) Additional bureaucracy, etc., in designing security protocols is
   unlikely to improve security.
4) Additional "frameworks", etc., are unlikely to help.
5) Additional committees are also unlikely to help.
5) Vague comments about "the dynamic nature of the Security
   requirements" are unlikely to illuminate anything. They have all
   the content of political speeches without the entertainment
   value.
6) It is easiest in life to accomplish by doing something rather than
   proposing that someone ELSE do something.

What produces successful new protocol work? Lots of hard thinking
(security is frequently a hard problem) and running code, followed by
rough consensus based documentation and standardization. Unfortunately,
it is much easier to engage in vague discussion or proposals than to
think, and far easier to propose bureaucracies than to write code.

Perry