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