ietf
[Top] [All Lists]

RE: Security

2002-10-16 10:10:31

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: Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu 
[mailto:Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu]
Sent: Tuesday, October 15, 2002 2:25 PM
To: Choudhary, Abdur R (Rahim)
Cc: ietf(_at_)ietf(_dot_)org
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



<Prev in Thread] Current Thread [Next in Thread>