Subject: [CGA-EXT] Old comments on RFC 3971

From: Jari Arkko <[email-masked]>
Date: Tue, 08 Apr 2008 14:10:04 +0300

I found this when cleaning up my mailbox. Please see if it contains
something that you want to address in the revision:

Alfred Hines wrote:

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

_______________________________________________
CGA-EXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cga-ext