Valery Smyslov writes:
> 1. Section 3.15.1:
>
> o APPLICATION_VERSION - The version or application information of
> the IPsec host. This is a string of printable ASCII characters
> that is NOT null terminated.
>
> "NOT" is uppercase. Although it might be an intention to ephasise
> the fact, that it is not null terminated, but it looks like RFC2119 word,
> that is not the case.
That "NOT" is intentional and it is used to emphasize the fact there
is no terminator.
> 2. Section 3.16:
>
> o Type (1 octet) is present only if the Code field is Request (1) or
> Response (2). For other codes, the EAP message length MUST be
> four octets and the Type and Type_Data fields MUST NOT be present.
> In a Request (1) message, Type indicates the data being requested.
> In a Response (2) message, Type MUST either be Nak or match the
> type of the data requested. Note that since IKE passes an
> indication of initiator identity in the first message in the
> IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity
> requests (type 1). The initiator MAY, however, respond to such
> requests if it receives them.
> ...
>
> Note that since IKE passes an indication of initiator identity in the
> first message in the IKE_AUTH exchange, the responder should not send
> EAP Identity requests. The initiator may, however, respond to such
> requests if it receives them.
>
> The last para in the section is absolutely equal to the last two sentences
> in the cited bullet, except that it doesn't use RFC2119 wording.
> I failed to see that it adds any value here.
It is to emphasize that you really, really need to leave out those
identity requests. We didn't want to such important thing stay hidden
under the bulleted list describing the fields in payload...
And it has already been fixed during the rfc editor process to have
exactly same RFC2119 wording that the text above has. Current text
says:
----------------------------------------------------------------------
o Type (1 octet) - Present only if the Code field is Request (1) or
Response (2). For other codes, the EAP message length MUST be
four octets and the Type and Type_Data fields MUST NOT be present.
In a Request (1) message, Type indicates the data being requested.
In a Response (2) message, Type MUST either be Nak or match the
type of the data requested. Note that since IKE passes an
indication of initiator identity in the first message in the
IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity
requests (type 1). The initiator MAY, however, respond to such
requests if it receives them.
o Type_Data (variable length) - Varies with the Type of Request and
the associated Response. For the documentation of the EAP
methods, see [EAP].
Note that since IKE passes an indication of initiator identity in the
first message in the IKE_AUTH exchange, the responder SHOULD NOT send
EAP Identity requests. The initiator MAY, however, respond to such
requests if it receives them.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
