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