Re: IKE V2 Open Issues

["Theodore Ts'o" <tytso@mit.edu>]

On Fri, Apr 11, 2003 at 04:14:27PM -0700, Paul Hoffman / VPNC wrote:
> 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.

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

						- Ted