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