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 PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 15, 2002 2:25 PM
To: Choudhary, Abdur R (Rahim)
Cc: [EMAIL PROTECTED]
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
