Subject: Re: [IPsec] Typos in draft-kivinen-ipsecme-ikev2-rfc5996bis-04

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 5 Sep 2014 17:05:42 +0400

Section 2.23, 4th bullet:

   o  The recipient of either the NAT_DETECTION_SOURCE_IP or
      NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied
      value to a SHA-1 hash of the SPIs, source or recipient IP address
      (respectively), address, and port, and if they don't match, it
      SHOULD enable NAT traversal.  [...]

It seems that there is an extra "address". Shouldn't it be:

   o  The recipient of either the NAT_DETECTION_SOURCE_IP or
      NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied
      value to a SHA-1 hash of the SPIs, source or recipient IP address and 
port
      (respectively), and if they don't match, it
      SHOULD enable NAT traversal.  [...]

or

   o  The recipient of either the NAT_DETECTION_SOURCE_IP or
      NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied
      value to a SHA-1 hash of the SPIs, source or recipient (respectively)
      IP address and port, and if they don't match, it
      SHOULD enable NAT traversal.  [...]

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 17 Sep 2014 15:00:00 +0400

In Section 3.8 (Authentication Payload) the description
of the 3-octet RESERVED field is absent. I think it is a typo,
as in all other cases, when reserved field is present
in payload (KE, ID, TS, CP), its description is given.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 18 Sep 2014 15:42:47 +0400

In Section 3.13.1 the description of the Selector Length field
doesn't mention that it is unsigned integer (as it is mentioned
for all other such fields).

---

From: Paul Wouters <[email-masked]>
Date: Thu, 18 Sep 2014 09:27:12 -0400 (EDT)

> for all other such fields).

What's an unsigned integer? :P

Do we mean octets? :)

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 18 Sep 2014 17:56:01 +0400

> What's an unsigned integer? :P

Unsigned integer is an interpretation of this two-octets value
(presumably in network byte order). It is explicitely stated
for most multi-byte fields in the document. For example:

Section 3.11 (Delete Payload):

   o  Num of SPIs (2 octets, unsigned integer) - The number of SPIs
      contained in the Delete payload.  The size of each SPI is defined
      by the SPI Size field.

Compare with the Section 3.13.1, which I has complained about:

   o  Selector Length - Specifies the length of this Traffic Selector
      substructure including the header.

No indication of how "Selector Length" (it is 2 octets) should be treated.

OK, we all know how to interpret it (and we have interoperable 
implementations),
but it needs to be stated here, as it is stated for other such fields
in the document. I'm probably acting here as a perisher, but as
document is intended to become Internet Standard such nits need to be
removed, IMHO.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 18 Sep 2014 10:10:29 -0400 (EDT)

> document is intended to become Internet Standard such nits need to be

Oh, I agree completely! Had I been able to pay more attention at the
time, I would have suggested never to mention "integers" or "(un)signed"
at all, and only mentioned octets. But we should make it all consistent
in the document, so thanks for catching that!

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 23 Sep 2014 17:14:50 +0400

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.

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.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 23 Sep 2014 16:47:49 +0300

> in payload (KE, ID, TS, CP), its description is given.

Fix sent to the RFC editor during the AUTH48d... 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 23 Sep 2014 16:48:33 +0300

> No indication of how "Selector Length" (it is 2 octets) should be

Fix sent in for the rfc-editor...
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 23 Sep 2014 16:53:43 +0300

> the fact, that it is not null terminated, but it looks like RFC2119 word,

That "NOT" is intentional and it is used to emphasize the fact there
is no terminator. 

> 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

   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-masked]