Subject: [IPsec] 5996bis 3.3.1 proposal structure

From: Paul Wouters <[email-masked]>
Date: Tue, 29 Oct 2013 09:19:17 -0400 (EDT)

>From the 5996 bis 02 draft:

3.3.1. Proposal Substructure

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | 0 (last) or 2 |   RESERVED    |         Proposal Length       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Proposal Num  |  Protocol ID  |    SPI Size   |Num  Transforms|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                        SPI (variable)                         ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                        <Transforms>                           ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 7:  Proposal Substructure

    o  0 (last) or 2 (more) (1 octet) - Specifies whether this is the
       last Proposal Substructure in the SA.  This syntax is inherited
       from ISAKMP, but is unnecessary because the last Proposal could be
       identified from the length of the SA.  The value (2) corresponds
       to a payload type of Proposal in IKEv1, and the first four octets
       of the Proposal structure are designed to look somewhat like the
       header of a payload.

It's a little confusing to me whether the first octet should be
interpreted as a "flags" field with two (of eight) bit flags assigned
or as a single octet that can have two values (0 or 2) and it will never
get updated to contain other values.

Are we ever planning on having values other then 0 or 2 ?

If a byte, could we give this byte a "name" like we have done for the other
proposal pieces?

If bits, could we give this octet a name (proposal flags) and these bits names? 
(bit 0 being reserved and MUST be 0, bit 1 being "non-last proposal")

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 29 Oct 2013 16:18:37 +0200

> 3.3.1. Proposal Substructure

It is one octect, and it used to have name called Next Payload, but as
we use that already in the IKEv2 we do not want to reuse it here.

The text quite clearly says "1 octect", which indicates it is not
bitfield or flags, but one byte having values of 0 or 2.

> Are we ever planning on having values other then 0 or 2 ?

No.

> If a byte, could we give this byte a "name" like we have done for the other

I think the name was explictly removed to make it clear that we do not
assume this to be Next Payload structure of the embedded payloads
having embedded payloads. Same thing with the Transforms substructure. 

> (bit 0 being reserved and MUST be 0, bit 1 being "non-last proposal")

I do not think we want to change this part of the text. The text tells
that this was supposed to look somewhat like the header of the
payload and I think that should make the payload clear enough.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 29 Oct 2013 10:46:18 -0400 (EDT)

> bitfield or flags, but one byte having values of 0 or 2.

It does say that clearly, but I wanted to confirm it was not a mistake,

>> Are we ever planning on having values other then 0 or 2 ?

Ok good.

> payload and I think that should make the payload clear enough.

Implementors still need to name that struct. Instead of everyone coming
up with their own name it would be good to have a standard name for it.

For example, the reason I'm looking at this was because the openswan
implementation actually called the struct isap_np and when it failed to
map an IKEv2 next payload type to it, failed. Libreswan is now calling
it isap_lp for "last proposal" and it will no longer accept IKEv1 next
payload types, which openswan was doing.

In a way, I think we did a disservce to implementors by re-using these
values and clunking it into ikev1 values. It may lead to other ikev1
values (eg for Next Payload Type) bleeding into ikev2 by accident by
agile implementors :P

So just naming it in the RFC like we do for the other IKEv2 proposal
fields would be useful. I would suggest "last payload".

Paul