Subject: IKEv2 payload #14

From: "Stephen C. Koehler" <[email-masked]>
Date: Thu, 19 Jun 2003 14:41:28 -0500

I recently noticed that payload type 14, which was the attribute payload for
mode config and xauth in IKEv1 as been reused for TSi in IKEv2.  This causes
some hardships for IKEv1 implementations that support mode config and xauth, 
because now payload 14 will have completely different meanings, based on 
context.  I think it would be better to leave payload 14 reserved in IKEv2.

A couple of weeks ago I sent out a message noting the changed encoding for 
protocols in proposals (between IKEv1 and IKEv2).  I didn't get any responses
on this.  Is anyone else having trouble dealing with changed encoding in IKEv2
implementations?

I realize fixing these things would require bits on the wire changes, and
it's rather late for that.  However, I think it's important to make people 
aware of implementation issues, like this.
-- 
Steve Koehler
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 19 Jun 2003 19:40:58 -0400

>>>>> "Stephen" == Stephen C Koehler <[email-masked]> writes:
    Stephen> context.  I think it would be better to leave payload 14
    Stephen> reserved in IKEv2. 

  I'd like IKEv2 to use all payloads that are entirely different in #.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: "Stephen C. Koehler" <[email-masked]>
Date: Fri, 20 Jun 2003 09:07:49 -0500

Thanks, Richard.  Does anyone else have concerns about this?  It seems to 
me that the options are (assuming there are any options this late in the game):

    1. Leave the spec as it currently stands with conflicting use of payload
       14 and changed structure definitions of a number of other payloads.

    2. Move TSi to another number and leave payload 14 reserved in IKEv2.

    3. Move any conflicting payload definitions to new numbers in IKEv2, but
       don't change the ones that have not changed in structure.

    4. Make all IKEv2 payloads have numbers distinct from those in IKEv1, 
       regardless of whether the structure or meaning has changed.

I would very much like for IKEv2 to use option (3).  (4) is perhaps overkill,
but I could be convinced otherwise.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 21 Jun 2003 17:41:08 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Stephen" == Stephen C Koehler <[email-masked]> writes:
    Stephen>     3. Move any conflicting payload definitions to new numbers
    Stephen>     in IKEv2, but 
    Stephen>        don't change the ones that have not changed in structure.

    Stephen>     4. Make all IKEv2 payloads have numbers distinct from those
    Stephen>     in IKEv1,  
    Stephen>        regardless of whether the structure or meaning has changed.

    Stephen> I would very much like for IKEv2 to use option (3).  (4) is
    Stephen> perhaps overkill, 
    Stephen> but I could be convinced otherwise.

  #4 has the advantage if there are any semantic differences.
  Also, it likely has better debugging characteristics...

  So, I agree - 3 or 4.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 23 Jun 2003 16:57:21 +0300

>        regardless of whether the structure or meaning has changed.

I would say number 3 or 4 are good. Actually I think 4 is better. 

> but I could be convinced otherwise.

BTW, this is not only about the paylaod number 14, the payload numbers
15, and 16 are used by the draft-ietf-ipsec-nat-t-ike-06.txt for IKEv1
also... 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: "Stephen C. Koehler" <[email-masked]>
Date: Mon, 23 Jun 2003 11:01:46 -0500

We now have a few folks who see this as a problem, and would prefer a
renumbering of the IKEv2 payloads.  Is there any chance for this suggestion to
be considered seriously? I would like to hear a response from those who have
the most say about the final spec.  Charlie?  Paul?  (I don't really know who
should be included in this list.)

This feedback comes from an implementer's perspective.  Conflicting payload
numbers are causing me a fairly large amount of difficulty combining v1 and v2
code that I would be very happy to have go away.

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 24 Jun 2003 19:26:18 -0400

Renumbering the payloads so they're non-overlapping sounds like a good
idea.  Now's the time to do it..

---

From: "Stephen C. Koehler" <[email-masked]>
Date: Fri, 27 Jun 2003 11:42:54 -0500

> idea.  Now's the time to do it..

So far, I have heard only positive feedback on my proposal to renumber
IKEv2 payloads so they don't overlap with IKEv1 payloads, or at least
to move the ones that collide or have changed syntax.  However,  the
topic seems to have died on the list without any clear indication that
this idea has been accepted.  As Bill stated, now is the time to do this
if we are going to do it.

I would really like to hear arguments from anyone who thinks we should not make
this change, even if the argument is that it is too late to make bits on the
wire changes.
-- 
Steve Koehler
[email-masked]