Re: IKE V2 Open Issues

[Russ Housley <housley@vigilsec.com>]

Ted:

> > None of the "other assigned numbers" are dealt with in Jeff's
> > document; these are.
> >
> > Implementers *have* to read both documents. They cannot implement the
> > mandatory algorithms without reading Jeff's document. Thus, having
> > the algorithm identifiers in the same document as the explanations of
> > what is mandatory makes more sense than putting the numeric values in
> > one document and the protocol description of the values (what is
> > mandatory and what is not) in a different document.
>
>Implementors can start implementing IKEv2 without knowing exactly
>which algorithms will be mandatory and which will be optional.  In
>most implementations which I've seen, the choice of such things is
>kept in a modular design, and given that we've already said that what
>will be mandatory will be changing over time, a wise implementor will
>certainly make their product easy to update with respect to what
>crypto algorithms are in use.
>
>Furthermore, I would like to reduce the number of interdependencies on
>the ikev2 document, so that we don't end up having to hold up the
>ikev2 document based on external dependencies.  The good news is that
>Jeff has finished the first cut at the document, so this is not to say
>that I don't have faith that the second document won't be immediately
>forthcoming.  However, Barbara and I would like to be able to get
>ikev2 off our hands and into the IESG's plate as soon as possible, and
>so anything where we can remove dependencies is a good thing.
>
>Due to its complexity ikev2 will probably require extra time for the
>IESG to consider, if past experience with IKE is any guide.  So we can
>finish polishing the required crypto algorithms document in parallel
>with the IESG cogitating over ikev2, and once it's ready, we can ship
>that off to the IESG, and given that the required crypto algorithms
>document will be much simpler, I imagine that will be able to zip
>through the IESG review stage very quickly.
>
>Having seen a first draft of Jeff's document, one compromise which I
>think would work well is to have the initial definition of algorithms
>and assigned numbers in both documents.  Given that it is the IANA
>registry which is authoratative, NOT either of these documents, having
>the numbers in both places will be most convenient to the
>implementors, and allows us to avoid having a forward dependency from
>ikev2 to the "required algorithms" draft.

I strongly disagree.  The major motivation for segregating the algorithm 
discussion is to allow the protocol document to progress up the standards 
track hierarchy and not be pulled back down to Proposed Standard when an 
algorithm decision is made.

>Russ, Steve --- procedurally, do you think any of the IESG
>nit-pickers/process mavens will have a problem with this approach?

I have a problem.  I consider myself pragmatic, but I guess you can apply 
the other labels if you wish.  In the S/MIME WG we went through this effort 
for CMS.  RFC 2630 became RFC 3369 and 3370.  Similarly, it was done for 
the certificate profile in PKIX.  RFC 2459 became RFC 3279 and 3280.  It 
was not that hard, so I think we should do it right the first time.

Russ