[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: the encrypted payload in IKEv2-05



  I have not coded up IKEv2 (yet) but I did write several versions of
IKEv1 and the "envelope" type of payload (SA/proposal/transform in IKEv1
and encryption payload in IKEv2) is ugly. It's an exception to a nice
rule. Perhaps it's not as ugly as other things I've written (I have
written a fair share of hideous code) but unless it's absolutely
necessary it's relative ugliness is not reason to keep it. And I don't
know why it was added in the first place.

  The IV used to be part of the IKE header iff the encryption bit was
set. The encryption bit was removed and this envelope payload was added. 

  From a sheer coding point of view it's probably a wash whether you
check the encryption bit and grab the IV out of the IKE header before
processing or check the "next payload" and grab the IV out of that
and process. But from a cleanliness-and-order point-of-view there is
a clear difference.

  Dan.

On Fri, 28 Feb 2003 14:46:50 EST you wrote
> 
> Dan,
> 
> Having coded this and compared it with things in other specs that have 
> resulted
> in ugly code, I dont believe this is an issue. Given that the encrypt 
> payload is
> the last/only payload you need a special check for it anyway and things 
> after that
> fall out nicely.
> 
> Jeff
> 
> Dan Harkins wrote:
> 
> >   Parsing IKEv2 messages is straightforward because if you're at
> > the current payload, curr, the next payload is at curr + curr->length
> > and the type of that payload will be curr->next_payload. And all the
> > payloads have the same generic format so parsing is easy.
> > 
> >   Except for the Encrypted Payload. It's "next payload" is, in fact,
> > the first interior payload. So this is alot like the clumsy IKEv1
> > construction of SA, proposal and transform. This is the sort of stuff
> > we were supposed to get rid of in IKEv2.
> > 
> >   It's an exception to an otherwise nice and clean rule. And that
> > makes for bad code.
> > 
> >   I missed when this got added but I recommend it be removed and we
> > go back to the way it used to be-- IV is part of the IKE Header iff
> > the rest of the message is encrypted, and there is a "trailer" appended
> > which includes the padding, pad length, and auth data.
> > 
> >   thanks,
> > 
> >     Dan.
> > 
> > 
> > 
> > 
>