Re: IKEv2 allocation policies

[Jari Arkko <jari.arkko@kolumbus.fi>]

Michael,

Thanks for the list of motivations! Some comments inline:

> Motivation for these rules:
> 
>    IKEv2 Exchange types			    Standards Action.
>    IKEv2 Security Protocol Identifiers	    Standards Action.
> 
> I believe that new exchange types will be entirely new protocols, or
> significant extensions. If they are sufficiently different to be totally
> incompatible, then they could run on their own port. If they aren't 
> that incompatible, then I presume that we need to think hard about this.

Yes.

>    IKEv2 Encryption Transform IDs	    expert review.
>    IKEv2 Pseudo-random Transform IDs	    expert review.
>    IKEv2 Integrity Algorithm Transform IDs  expert review. 
>    IKEv2 Notification IPCOMP Transform IDs  expert review. 
> 
> Algorithms are relatively simple to standardize, and if an implementation
> does not understand them, then it can just ignore them.

Fine.

>    IKEv2 Diffie-Hellman, ECP/EC2N           Specification Required.
> 
> If one guess wrong, then an extra round trip is required. It seems that
> there should be very little reason to have private definitions that are
> not published somewhere.

Ok.

>    IKEv2 Payload Types			    Specification Required.
> 
> New payloads will be significant features, so need to be described.
> IKEv1's lack of a critical bit meant it was effectively Standards Action,
> so this is a relaxation.

Hmm.... I think Specification Required is quite weak. Does this mean
that with the critical bit set to 1, a vendor (with documentation) can
prevent interoperability with a base RFC compliant IKEv2 implementation?
How about IESG Approval or IETF Consensus? Or Specification Required
if critical = 0, IETF consensus otherwise?

>    IKEv2 Transform Types		    Specification Required.
>    IKEv2 Transform Attribute Types	    Specification Required.
> 
> If we invent something other than authenticate, encrypt and compress,
> then I think it needs to be described well.

I think Specification Required is too weak for a 8 bit IKEv2 Transform
Type.

>    IKEv2 Extended Sequence Numbers Transform IDs    IETF Consenus.
> 
> A new value here would require an "RFC2401bis"-bis. (128bit sequence
> numbers?)  

Ok.

>    IKEv2 Identification Payload ID Types    Specification Required.
>    IKEv2 Certificate Encodings		    Specification Required.
>    IKEv2 Authentication Method		    Specification Required.
>    IKEv2 Traffic Selector Types		    Specification Required.

Ok otherwise, but it looks like a new Traffic Selector Type would have
a major impact on RFC 2401 processing, or have I misunderstood something?
If so, IETF Consensus might be more appropriate?

> I think that new types should be explained, or it will be very hard to
> interop. 
> 
>    IKEv2 Notification Payload Types	    First Come-First Served.

How about Specification Required? Is there a reason why we should not
document the notifications?

> Big wide space, with minimal impact on interop.
> 
>    IKEv2 Configuration Payload CFG Types    Specification Required.
>    IKEv2 Configuration Payload Attribute Types    Specification Required.
> 
> These remind me of the problems in PPP,radius,DHCP with having vendors too
> easily able to innovate (and become incompatible). Specification Required at
> least requires that there be a document that exaplain things. It shouldn't be
> too onerous, in my opinion. This could be watered down to "expert review".

Specification Required is fine for this, I think.

--Jari