Subject: the encrypted payload in IKEv2-05

From: Dan Harkins <[email-masked]>
Date: Fri, 28 Feb 2003 09:18:55 -0800

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.

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 28 Feb 2003 14:46:50 -0500

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

---

From: Dan Harkins <[email-masked]>
Date: Fri, 28 Feb 2003 12:46:59 -0800

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 28 Feb 2003 16:04:15 -0500

The Encrypted Payload is somewhat confusing.  The Integrity Checksum 
Data is part of this Payload, but the computation includes the IKEv2 
Header as well.

Dan's suggestion (I believe that was the case in -02- or -03-) sounds 
better.

regards,
Lakshminath

PS:  Let us not use 'auth data' (means something else in IKEv2) while 
referring to Integrity Checksum Data :-).  How about ICD or may be ICV?

Dan Harkins wrote:
<deleted text>