Subject: RFC 3971 issues and errata

From: Alfred Hönes <[email-masked]>
Date: Mon, 14 May 2007 23:28:42 +0200 (MESZ)

Hello,
quite some time ago, I had studied RFC 3971 (SEND) authored by you,
but I did not find the time to submit the marginal notes I had made.
The recent publication of RFC 4866 and its relationship via CGA to
SEND now has pushed me to come back to RFC 3971 and perform this
task now.

The comments below point out some issues I found with the RFC
text and supply material for an appropriate RFC Errata Note.

The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

(1)  Section 2 -- wrong reference tags

Near the bottom of page 5, Section 2 of RFC 3971 says:

   Neighbor Discovery Protocol (NDP)

|     The IPv6 Neighbor Discovery Protocol [7, 8].

      The Neighbor Discovery Protocol is a part of ICMPv6 [6].

It should say:

   Neighbor Discovery Protocol (NDP)

|     The IPv6 Neighbor Discovery Protocol [4, 5].

      The Neighbor Discovery Protocol is a part of ICMPv6 [6].

Rationale:
  See Section 12.1, on page 50; the proper references are
  RFC 2461 [4] and RFC 2462 [5].

Subsequently, on top of page 6, RFC 3971 says:

   Non-SEND node

      An IPv6 node that does not implement this specification but uses
      only the Neighbor Discovery protocol defined in RFCs 2461 and
|     2462, as updated, without security.
           ^^^^^^^^^^^^
It should say:

   Non-SEND node

      An IPv6 node that does not implement this specification but uses
      only the Neighbor Discovery protocol defined in RFCs 2461 and
|     2462, without security.

Rationale:
  Perhaps, there once was a reference to some work in progress,
  e.g., what has become RFC 4311, or the 2461bis and 2462bis I-Ds,
  and this reference was been removed only partially.  Cleanup!
  For an alternative text change, see the next item.

(2)  Section 3 -- clarification ?

At the bottom of page 6, Section 3 says:

                         [...]  This section is not normative, and if
   this section and the original Neighbor Discovery RFCs are in
|  conflict, the original RFCs, as updated, take precedence.
                                ^^^^^^^^^^^

It is unclear what has been inteded here.  The rationale above
might apply here as well.  Or was it intended to say:

                         [...]  This section is not normative, and if
   this section and the original Neighbor Discovery RFCs are in
|  conflict, the original RFCs, or any updates to these, take
   precedence.
                                ^^^^^^^^^^^^^^^^^^^^^^^^
Please comment.

(3)  Section 6.4.1 -- spurious word / grammar, and a clarification

(3a)
On page 30, the explanation for 'Source Address' in Section 6.4.1 says:

         A link-local unicast address assigned to the sending interface,
|        or to the unspecified address if no address is assigned to the
         sending interface.

It should say:

         A link-local unicast address assigned to the sending interface,
|        or the unspecified address if no address is assigned to the
         sending interface.

(3b)
The last paragraph of Section 6.4.1, at the bottom of page 31,
(as quoted below) has several issues.

First of all, this sentence apparently does *not* belong to the
discussion of `Valid Options` above it; hence, it should be indented
one step less.

Next, I propose to add an initial article, 'The'.

But most importantly, I suspect that the ICMP lenght specification,
 >= 8 , in fact should be:  > 8 .
Unfortunately I cannot find a precise statement specifying clearly
that the Trust Anchor option is mandatory in the Certification Path
Solicitation Message, but the explanation 9 lines before the end of
the section,

         The first (or only) Trust Anchor option MUST contain a DER
         Encoded X.501 Name; see Section 6.4.3.

IMHO in fact does imply this.

If that is correct, the final line,

|     ICMP length (derived from the IP length) MUST be 8 or more octets.

should say:

|  The ICMP length (derived from the IP length) MUST be greater than 8
   octets.

(4)  Section 6.4.2 -- clarification

Similar to the rationale for item (3b) above, I suspect that
the Certification Path Advertisement Message will always include
at least one Option.

Therefore, the last paragraph of Section 6.4.2, on mid-page 34,

      The ICMP length (derived from the IP length) MUST be 8 or more
      octets.

should say:

   The ICMP length (derived from the IP length) MUST be greater than 8
   octets.

(5)  Section 6.4.3 -- mis-specification ?

At the bottom of page 34, Section 6.4.3 contains the explanation:

   Length

      The length of the option (including the Type, Length, Name Type,
|     Pad Length, and Name fields), in units of 8 octets.
                  ^^^^^^^^^

It should say:

   Length

      The length of the option (including the Type, Length, Name Type,
|     Pad Length, Name, and Padding fields), in units of 8 octets.
                ^^^^^^^^^^^^^^^^^^^^

Rationale:
  See the explanation for the 'Padding' field, at the bottom of page 35.

(6)  Section 6.4.4 -- mis-specification ?

On page 36, Section 6.4.4 contains the explanation:

   Length

      The length of the option (including the Type, Length, Cert Type,
|     Pad Length, and Certificate fields), in units of 8 octets.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

It should say:

   Length

      The length of the option (including the Type, Length, Cert Type,
|     Reserved, Certificate, and Padding fields), in units of 8 octets.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Rationale:
  Apparently, there's no 'Pad Length' field in the Certificate Option;
  the artwork on top of page 36 shows a 'Reserved' field in the same
  octet where the Trust Anchor Option carries a 'Pad Length' field,
  and the text contains a description of that 'Reserved' field.
  According to the explanation for the 'Padding' field at the bottom
  of page 36, the length of the 'Padding' field must be derived
  implicitely from the ASN.1 encoding of the 'Certificate' field,
  and the 'Length' field comprises the length of the 'Padding' field.

Note:
  Because the extensible format potentially allows for other Cert Type
  values and other Certificate encodings, I am in doubt whether the
  decision to include a Reserved octet in place of a Pad Length octet
  was very wise.
  The current description of the 'Reserved' field will admit a future
  revision of that decision.

(7)  Section 6.4.5 vs. Section 6.4.6 -- contradiction!

The first paragraph of Section 6.4.5, on page 37, says:

                                      [...].  Future, backward-
|  compatible changes to the protocol may specify the contents of the
|  Reserved field or add new options; backward-incompatible changes may
   use different Code values.  [...]

Contrary to that, the first paragraph of Section 6.4.6, on page 38,
says:

                                       [...].  Future, backward-
|  compatible changes to the protocol MAY specify the contents of the
|  Reserved field or add new options; backward-incompatible changes MUST
   use different Code values.  [...]

I suspect that the first "may" above should be a "MAY" and the second
"may" should have been a "MUST" as well.

If that's correct, the first paragraph of Section 6.4.5 should say:

                                      [...].  Future, backward-
|  compatible changes to the protocol MAY specify the contents of the
|  Reserved field or add new options; backward-incompatible changes MUST
   use different Code values.  [...]

(8)  Section 6.4.6 -- missing article

On top of page 39, at the end of the first paragraph there,
Section 6.4.6 says:

     [...].  If there are multiple missing certificates, additional CPS
|  messages can be sent after getting a response to first one.  However,
   the complete retrieval process may last at most CPS_RETRY_MAX
   seconds.

It should say:

     [...].  If there are multiple missing certificates, additional CPS
|  messages can be sent after getting a response to the first one.
   However, the complete retrieval process may last at most
   CPS_RETRY_MAX seconds.

(9)  Section 7.4 -- a spurious and a missing article

(9a)
The first paragraph of Section 7.4, on page 41, says:

         [...].  This specification also does not apply to addresses
|  generated by the IPv6 stateless address autoconfiguration from a
   fixed interface identifiers (such as EUI-64).
                             ^                                   ^^
It should say:

         [...].  This specification also does not apply to addresses
|  generated by the IPv6 stateless address autoconfiguration from fixed
   interface identifiers (such as EUI-64).

(9a)
The last paragraph of Section 7.4, on page 42, says:
                        v
|  The Target Address in Neighbor Advertisement is required to be equal
   to the source address of the packet, except in proxy Neighbor
   Discovery, which is not supported by this specification.

It should say:
                        vvv
|  The Target Address in a Neighbor Advertisement is required to be
   equal to the source address of the packet, except in proxy Neighbor
   Discovery, which is not supported by this specification.

(10)  Section 9.1 -- missing article

The third paragraph of Section 9.1, at the bottom of page 44, says:
                   v
|  There may not be cryptographic binding in SEND between the link layer
   frame address and the IPv6 address.  An unsecured link layer could
   allow nodes to spoof the link layer address of other nodes.

It should say:
                   vvv
|  There may not be a cryptographic binding in SEND between the link
   layer frame address and the IPv6 address.  An unsecured link layer
   could allow nodes to spoof the link layer address of other nodes.

Please comment.

Most items seem to be appropriate for an Errata Note; some need
resolution.

Preferrably, you should submit an Author's Errata Note to the
RFC Editor's RFC Errata web pages, making freely use of the
material supplied above.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+