SEcure Neighbor Discovery (SEND)
RFC 3971

Note: This ballot was opened for revision 06 and is now closed.

(Margaret Cullen) Yes

(Thomas Narten) (was Discuss) Yes

Comment (2004-06-11)
No email
send info
Editorial (more or less):


>       4.  The 32-bit ICMP header.

Would be better to make clear exactly what part of the header you are
referring to. ICMP has more than a 32 bit header in some cases. Also,
see below comment.

>    o  For the purpose of constructing a signature, the following data
>       items are concatenated:
> 
> 
>       *  The 128-bit CGA Type Tag.

This is a repetition  of what was given just a page earlier. Can we
just have one definition/algorith (and make sure it is clear?)


>    o  The receiver MUST ignore any options the come after the first
>       Signature option.

s/the come/that come/


>    Messages that do not pass all the above tests MUST be silently
>    discarded.  The receiver MAY also otherwise silently discard packets,
>    e.g., as a response to an apparent CPU exhausting DoS attack.

the MUST seems too strong. I.e., if the sender includes a signature I
don't have a key for, I have to drop the packet? Can't I run ND in
insecure mode? Later, text implies yes.

Actually my confusion may stem from:

>    A message containing a Signature option MUST be checked as follows:

What messages? I assumed ND in general, but maybe this is only for a
RS/NS? Please clarify.



> 5.2.3 Configuration
> 
> 
>    All nodes that support the reception of the Signature options MUST be
>    configured with the following information for each separate NDP
>    message type:

must "allow the following information to be configured" (or some such,
i.e, make clear that a config interface needs to be provided).

> 5.2.4 Performance Considerations
> 
> 
>    The construction and verification of this option is computationally
>    expensive. In the NDP context, however, the hosts typically have the
>    need to perform only a few signature operations as they enter a link,
>    and a few operations as they find a new on-link peer with which to
>    communicate.

What about NUD? these operations can potentially be reinvoked once per
minute...

>    If a message has both Nonce and Timestamp options, the Nonce option
>    SHOULD precede the Timestamp option in the message.

Why? What value does this have (and its only a SHOULD, so receivers
can't count on it...). This seems useless.

>    TIMESTAMP_DRIFT (see Section 11.

missing closing paren.

>    o  If the timestamp is NOT within the boundaries but the message is a
>       Neighbor Solicitation message which should be answered by the
>       receiver, the receiver MAY respond to the message.  However, if it
>

Seems like MAY -> SHOULD for better interoperability.

>       In the FQDN case the Name field is an "IDN-unaware domain name

s/case/case,/

>    Nodes that use stateless address autoconfiguration SHOULD generate a
>    new CGA and a CGA Parameters data structure as specified in Section 4
>    of [13] each time they run the autoconfiguration procedure.

I hope this isn't what it sounds like it does... Why can't one
continue to reuse the same one one had earlier? That seems like a
performance win. (And networks come and go rather frequently
sometimes, e.g., in the wireless case...)

>    If the Target Address and Destination Address fields in the ICMP
>    Redirect message are equal, then this message is used to inform hosts
>    that a destination is in fact a neighbor.  In this case the receiver
>    MUST verify that the given address falls within the range defined by
>    the router's certificate.  Redirect messages failing this check MUST
>    be silently discarded.

Note: this seems to contradict what Section 7.3 says, which allows
uncertified prefixes to be accepted.

>    Note that RFC 2461 rules prevent a host from accepting a Redirect
>    message from a router that is not its default router. This prevents
>    an attacker from tricking a node into redirecting traffic when the
>    attacker is not the default router.

nit: the rules in 2461 say one only accepts a redirect from the router
a host is using to reach the destination mentioned in the
redirect. That is slightly different.

>    This specification does not address the protection of NDP packets for
>    nodes that are configured with a static address (e.g., PREFIX::1).
>    Future certificate chain-based authorization specifications are
>    needed for such nodes.

Or addresses configured under normal stateless addrconfig...

>    SEND nodes MUST send only secured messages.  Plain (non-SEND)
>    Neighbor Discovery nodes will obviously send only insecure messages.
>    Per RFC 2461 [7], such nodes will ignore the unknown options and will
>    treat secured messages in the same way as they treat insecure ones.
>    Secured and insecure nodes share the same network resources, such as
>    prefixes and address spaces.

Wording odd. What is a "SEND node"? One that implements this spec?
That's too strong. It should be an operational choice whether to use
SEND or not, if it is implemented.

>       flag on entries indicating whether the entry issecured. Received

s/issecured/is secured/

(Harald Alvestrand) No Objection

Comment (2004-06-10 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Reviewed by Michael Patton, Gen-ART.

I believe this needs a respin for other reasons. But the number of language issues identified in Patton's review is large enough that it should have a careful language review in the same respin.
So if there hadn't been other reasons to respin it, this might have been a (marginal) DISCUSS.

(Steven Bellovin) (was Discuss) No Objection

Comment (2004-06-09)
No email
send info
Given that there are implementations of this spec, it would be nice to include an appendix giving typical packet lengths, especially for messages with certificates.

(Bill Fenner) No Objection

(Ted Hardie) (was Discuss) No Objection

Comment (2004-06-14)
No email
send info
Removed DISCUSS as Steve's was a superset of the issues I raised.  To
make coordination a bit easier, he will hold the DISCUSS token on this.

(Scott Hollenbeck) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2004-06-10)
No email
send info
  RFC 3280 uses the term "certification path," not the term "certificate
  chain." Likewise, RFC 3280 uses the term "certification authority," not
  the term "certificate authority."  Please align with RFC 3280.

  Please change "PKCS#1 signature" to "PKCS#1 v1.5 signature"
  throughout the document.

  In at least two places the document talks about ASN.1, and in another
  place it talks about DER.  Normative references are needed.

  In the 2nd bullet of section 4, the document says:
  >
  > This specification also allows a node to use non-CGAs with
  > certificates to authorize their use.  However, the details of
  > such use are beyond the scope of this specification.
  >
  The point that this topic is out of scope ought to come much earlier in
  the document, preferably in the introduction.

  In section 5.2.2, the introduction of the "valid authorization delegation
  chain" has no foundation.  Please include a forward reference to section 6.

  In section 6.2, last paragraph: s/must be a subset/MUST be a subset/

  In section 6.2.3, the document says:
  >
  > When the Name Type field is set to 1, the Name field contains a
  > DER encoded X.501 certificate Name, represented and encoded
  > exactly as in the matching X.509v3 trust anchor certificate.
  >
  However, a trust anchor need not have a certificate.  It must have a
  X.501 name to be used in the issuer field of certificates that it issues,
  but the use of a self-signed certificate is not required.

(David Kessens) No Objection

(Allison Mankin) No Objection

(Jon Peterson) No Objection

(Bert Wijnen) No Objection

(Alex Zinin) No Objection