Re: the encrypted payload in IKEv2-05

["jpickering@creeksidenet.com" <jpickering@creeksidenet.com>]

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.
> 
> 
> 
>