On Nov 12, 2013, at 12:18 PM, Tero Kivinen <[email protected]> wrote:
> Paul Wouters writes:
>> 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.
>
> I do not think it is that important to have names, I am good at
> inventing better names than what they use in standards :-)
>
>> So just naming it in the RFC like we do for the other IKEv2 proposal
>> fields would be useful. I would suggest "last payload".
>
> As it is not payload, I used "Last Substruc" instead. The data inside
> those are Proposal or Transform Substructures.
>
> Changed:
>
> 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|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> ...
>
> 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.
>
>
> To:
> 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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Last Substruc | RESERVED | Proposal Length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Proposal Num | Protocol ID | SPI Size |Num Transforms|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> ...
>
> o Last Substruc (1 octet) - Specifies whether this is the last
> Proposal Substructure in the SA. This field has value 0 if this
> was last Proposal Substructure, and value 2 there are more
> Proposal Substructures. 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.
Slight editorial clean-up on the new wording:
o Last Substruc (1 octet) - Specifies whether or not this is the last
Proposal Substructure in the SA. This field has a value of 0 if this
was last Proposal Substructure, and a value of 2 if there are more
Proposal Substructures. . . .
> And:
>
> 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 3 | RESERVED | Transform Length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |Transform Type | RESERVED | Transform ID |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> ...
> o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the
> last Transform Substructure in the Proposal. This syntax is
> inherited from ISAKMP, but is unnecessary because the last
> transform could be identified from the length of the proposal.
> The value (3) corresponds to a payload type of Transform in IKEv1,
> and the first four octets of the Transform structure are designed
> to look somewhat like the header of a payload.
>
>
> To:
> 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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Last Substruc | RESERVED | Transform Length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |Transform Type | RESERVED | Transform ID |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> ...
> o Last Substruc (1 octet) - Specifies whether this is the last
> Transform Substructure in the Proposal. This field has value 0 if
> this was last Transform Substructure, and value 3 there are more
> Transform Substructures. This syntax is inherited from ISAKMP,
> but is unnecessary because the last transform could be identified
> from the length of the proposal. The value (3) corresponds to a
> payload type of Transform in IKEv1, and the first four octets of
> the Transform structure are designed to look somewhat like the
> header of a payload.
Editorial:
o Last Substruc (1 octet) - Specifies whether or not this is the last
Transform Substructure in the Proposal. This field has a value of 0 if
this was last Transform Substructure, and a value of 3 if there are more
Transform Substructures. . . .
--Paul Hoffman
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
