the encrypted payload in IKEv2-05

[Dan Harkins <dharkins@trpz.com>]

  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.