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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
