|Main Archive Page > Month Archives > ipsec archives|
Paul Hoffman writes:
> At 4:44 PM -0400 4/10/09, Black_David@emc.com wrote:
> >That looks like an oversight at least wrt RFC 4869.
> Actually, this started with an oversight in RFC 4543. Section 5
> clearly says that it is for IKEv1 and IKEv2, but section 9 only
> seems to cover IKEv2.
> >Chairs (of ipsecme) and Pasi (AD) - is a new RFC needed to
> >allocate this value, or is there a lower overhead and faster
> >means of getting this done?
> This can probably be done by Pasi, given the nature of the error.
> Otherwise, we probably need a revision to RFC 4543.
It would be easier to fix that if the value would be missing from the IKEv2 registry as those are expert review actions.
The whole ikev1 (http://www.iana.org/assignments/isakmp-registry) registry is completele mess. For example the top level iana list (http://www.iana.org/protocols/) only contains following registries pointing to the isakmp-registry:
The RFC2407 lists more registries: 6.1 IPSEC Situation Definition 6.2 IPSEC Security Protocol Identifiers 6.3 IPSEC ISAKMP Transform Identifiers 6.4 IPSEC AH Transform Identifiers 6.5 IPSEC ESP Transform Identifiers 6.6 IPSEC IPCOMP Transform Identifiers 6.7 IPSEC Security Association Attributes 6.8 IPSEC Labeled Domain Identifiers 6.9 IPSEC Identification Type 6.10 IPSEC Notify Message Types
And those are the registries actually included in the isakmp-registry file.
In addition to those the isakmp-registry also contains the "ISAKMP Domain of Interpretation (DOI)", and "Next Payload Types" registries. The "Next Payload Types" which was created afterwords when we noticed we do need it. I do not think its creation is specified in any RFC. Don't even know when the DOI registry was created.
Most of those IKEv1 registries do require RFC and IESG review (IPsec Situation Definition, IPSEC Security Protocol Identifiers, IPSEC ISAKMP Transform Identifiers, IPSEC AH Transform Identifiers, IPSEC ESP Transform Identifiers, IPSEC IPCOMP Transform Identifiers, IPSEC Identification Type). Rest just require Internet Draft to specify it...
As this change to the isakmp-registry changes the IPSEC ESP Transform Identifiers registry, which do require Standard Track RFC or IESG review, I think we cannot simply modify the registry, but we at minimum need to make errata for the RFC4543 which reserves values also from the IKEv1 registry.
Of course as everybody should be using the IKEv2, and everybody should be moving away from the obsoleted IKEv1 protocol, we can also just say that you cannot use those algorithms with obsoleted IKEv1 protocol, and you need to use IKEv2 for it :-)
Anyways IANA should fix their toplevel list (http://www.iana.org/protocols/) to include all the registries listed in the isakmp-registry file, i.e.: