SEcure Neighbor Discovery (SEND)
draft-ietf-send-ndopt-06

[Ballot comment]
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.

[Ballot comment]
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/

[Ballot discuss]
> 5.1.1 Processing Rules for Senders
>
>
>    The CGA option MUST be present in all Neighbor Solicitation and
>    Advertisement messages, and MUST be present in Router Solicitation
>    messages unless they are sent with the unspecified source address.
>    The CGA option MAY be present in other messages.

MUST? so it's not an option to implement the spec, but then not
actually use a feature? That seems wrong; i.e., end user should be
able to disable or choose not  to use.

>    minSec

Why require this if it is not used? How can including this facilitate
experimentation? I don't understand the need to include this here.

>    All solicited advertisements MUST include a Nonce, copied from the
>    received solicitation.  Note that routers may decide to send a
>    multicast advertisement to all nodes instead of a response to a
>    specific host. In such case the router MAY still include the nonce
>    value for the host that triggered the multicast advertisement.
>    Omitting the nonce value may, however, cause the host to ignore the
>    router's advertisement, unless the clocks in these nodes are
>    sufficiently synchronized so that timestamps can be relied on.

But if a multicast RA includes the nonce, won't the other nodes ignore
it, defeating the purpose of having a multicast RA?

>    o  Advertisements sent to a unicast destination address with the
>      Signature option but without a Nonce option MUST be silently
>      discarded.
>

This may break an assumption in ND. Namely, that one can send
unsolicited unicast RAs or NAs. This is currently legal in ND, but
would no longer be above. Is this restriction necessary?

>      implementation decision. However, typical policies may prefer
>      existing entries over new ones, CGAs with a large Sec value over
>      smaller Sec values, and so on.  The issue is briefly discussed in
>      Appendix C.

not much guidance for Sec value; I don't really understand what this
is to be used for.

>          A single advertisement MUST be broken into separately sent
>          components if there is more than one Certificate option, in
>          order to avoid excessive fragmentation at the IP layer.  Unlike
>          the fragmentation at the IP layer, individual components of an
>          advertisement may be stored and used before all the components
>          have arrived; this makes them slightly more reliable and less
>          prone to Denial-of-Service attacks.

Seems wrong. the sender should definitely fragment as necessary, but
the protocol should not require it if two Certificate options could
fit in a single message. some link types have large MTUs. Hmm, maybe
this is to keep the algorithms simple. That might be OK.

>      Component
>
>
>          A 16-bit unsigned integer field, used for informing the
>          receiver which certificate is being sent, and how many are
>          still left to be sent in the whole chain.

I don't see how the receiver can learn (definitively) how many
certificates there are in a reply. the protocol seems to assume the
first response will not get lost, and the component value indicates
the number of messages. This seems unrobust. Given that there are
reserved/unused fields, why not just include the total number in all
messages? (And for that matter, would it be useful to allow a request
to indicate which component needs to be retransmitted? This would
help remove systematic failures, which is one of  the reasons IP
fragmentation is problematic.

[Ballot discuss]
I'm very concerned that the authorization model used by the authors is incorrect.  Several of the following comments, including the most serious ones, are based on that belief.

Section 4 says "A host and a router must have at least one common trust anchor before the host can adopt the router as its default router."  I don't know what it means to "have ... a common trust anchor", but the relationships are different.  The host must believe that the chain of authorizations, from the anchor to the router, identifies a node that is *authorized* to route packets for this link.  That has nothing to do with whether or not the host in some way trusts the anchor for other purposes.  To give a concrete example, since router certificates are tied to the addressing structure they're presumably rooted at an RIR.  That will be true of virutally all router certificates describing public address space, including the routers belonging to EvilHackerDudes.example.org.  The fact that I'll trust the certificates from routers for MyCompany.example.com doesn't mean that I'll trust the evil ones.  While trust anchors may suffice, the spec must mandate some sort of user (or configuration) interface to describe a full chain of authorized certificates.  In some situations, these may not be address certificates.  A user sitting in a public hot spot may be willing to trust the owner of the hotspot -- say, via a standard commercial identity certificate, of the type used today on the Web -- without regard to the particular addresses being advertised or assigned.

5.2.2: Clarify that options after the signature option MUST always be ignored (or the packet dropped); in this context, it's ambiguous if such options are only dropped for purposes of signature verification.

5.2.4 says that the IPv6 header is covered by the signature.  5.2.1 says that the ICMPv6 header is covered, as well as the source and destination addresses.  Which is it?

5.3.4.2: A 1-hour DELTA value seems amazingly high.  Kerberos uses 5 minutes.

6.2.1: Per my comments on Section 4, I'm not convinced that a trust anchor is useful.

6.2.6: Why does it say that "hosts SHOULD NOT store certificates" under certain conditions?  Certificates are self-validating.  Ones that aren't part of a chain may be useless, and it may be advantageous under certain conditions to discard them, but strongly advising their discard seems wrong -- if you have the storage (and a good search algorithm), possessing them is useful because it can avoid the need to solicit or receive them later.

8: The spec says that nodes SHOULD have an option to restrict them to secure NDP messages only.  What is the default value for this option?

The Security Considerations section should discuss the effects of an NTP attack on router time values.  See
@inproceedings{Bishop-ntp,
        author = {Bishop, Matt},
        title = "A Security Analysis of the {NTP} Protocol",
        booktitle = {Sixth  Annual Computer Security Conference Proceedings},
        address = {Tucson, AZ},
        pages = {20--29},
        year = 1990,
        month = {December},
        url = {ftp://louie.udel.edu/pub/ntp/doc/security.ps.Z}
}

[Ballot comment]
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.

[Ballot discuss]
The protocol supports a single digital signature algorithm.  Since
  no algorithm identifiers appear in any of the protocol data units,
  it is not possible to support others in the future.  While I think
  this is a poor design choice, I am not blocking the document on this
  point.  However, I do insist that this situation be explained in the
  document introduction.  I also insist that the name of the signature
  option be changed.  The name needs to reflect the signature algorithm
  so that it is clear that the mechanism to support other signature
  algorithms is the definition of a new option.

  Since the document only supports RSA PKCS#1 v1.5 signatures, section 6.2
  ought to discuss the processing of subjectPublicKeyInfo within the
  certificate to ensure that only RSA public keys are used to attempt the
  validation of signatures.

  In section 5.2, the document says:
  >
  > The Signature option allows public-key based signatures to be
  > attached to NDP messages. Configured trust anchors, CGAs, or both are
  > supported as the trusted root.
  >
  The term "trusted root" is not explained.  In fact, I do not think that
  the traditional use of the term applies here.  The public key that is
  used to verify the signature is not contained in a certificate when a
  CGA is employed.  The processing to validate a public key needs to be
  explained for each supported case.

  In section 5.2.3, I expected some information about the source of
  trust anchors.  When I show up at an IETF meeting, how will my
  laptop software learn the anchor for the IETF WLAN?  If this
  information is not going to be provided in this document, where can
  I find it?  One possible solution is to define a PKI that is rooted
  at IANA.  In this case, a single trust anchor is needed, so it can be
  built into every implementation.  However, there are several clues in
  the document that indicate that a more local scheme is envisioned.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
I'm very concerned that the authorization model used by the authors is incorrect.  Several of the following comments, including the most serious ones, are based on that belief.

Section 4 says "A host and a router must have at least one common trust anchor before the host can adopt the router as its default router."  I don't know what it means to "have ... a common trust anchor", but the relationships are different.  The host must believe that the chain of authorizations, from the anchor to the router, identifies a node that is *authorized* to route packets for this link.  That has nothing to do with whether or not the host in some way trusts the anchor for other purposes.  To give a concrete example, since router certificates are tied to the addressing structure they're presumably rooted at an RIR.  That will be true of virutally all router certificates describing public address space, including the routers belonging to EvilHackerDudes.example.org.  The fact that I'll trust the certificates from routers for MyCompany.example.com doesn't mean that I'll trust the evil ones.  While trust anchors may suffice, the spec must mandate some sort of user (or configuration) interface to describe a full chain of authorized certificates.  In some situations, these may not be address certificates.  A user sitting in a public hot spot may be willing to trust the owner of the hotspot -- say, via a standard commercial identity certificate, of the type used today on the Web -- without regard to the particular addresses being advertised or assigned.

5.2.2: Clarify that options after the signature option MUST always be ignored (or the packet dropped); in this context, it's ambiguous if such options are only dropped for purposes of signature verification.

5.2.4 says that the IPv6 header is covered by the signature.  5.2.1 says that the ICMPv6 header is covered, as well as the source and destination addresses.  Which is it?

5.3.4.2: A 1-hour DELTA value seems amazingly high.  Kerberos uses 5 minutes.

6.2.1: Per my comments on Section 4, I'm not convinced that a trust anchor is useful.

6.2.6: Why does it say that "hosts SHOULD NOT store certificates" under certain conditions?  Certificates are self-validating.  Ones that aren't part of a chain may be useless, and it may be advantageous under certain conditions to discard them, but strongly advising their discard seems wrong -- if you have the storage (and a good search algorithm), possessing them is useful because it can avoid the need to solicit or receive them later.

8: The spec says that nodes SHOULD have an option to restrict them to secure NDP messages only.  What is the default value for this option?

[Ballot discuss]
I guess I have a fundamental design question.  The draft describes part of the
underlying logic in section 6.1 as:


  The certificate chain of a router terminates in a Router
  Authorization Certificate that authorizes a specific IPv6 node to act
  as a router.  Because authorization chains are not a common practice
  in the Internet at the time this specification was written, the chain
  MUST consist of standard Public Key Certificates (PKC, in the sense
  of [19]).  The certificate chain MUST start from the identity of a
  trust anchor that is shared by the host and the router.  This allows
  the host to anchor trust for the router's public key in the trust
  anchor.  Note that there MAY be multiple certificates issued by a
  single trust anchor.

One of the common use cases for V6 is in mobile networks, where it
may be common for a terminal to operate in a network operated
by a provider to whom the user has no direct relationship.  Managing
the trust anchors in this instance looks to be a fairly hard problem.
The draft doesn't seem to address this part of the problem
directly, though there is a bit of text on how fast hand-off may enable
one router to pass data on the next router along.

Have I missed something here in the way of context or text?

IANA Last Call Comments:
We understand the IANA Actions to be the following:

ICMPv6 type numbers for:

Delegation Chain Solicitation message
Delegation Chain Advertisement message

in the following registry (informational range):


Neighbor Discovery Protocol Option assignments for:

CGA option
Signature option
Timestamp option
Nonce option
Trust Anchor option
Certificate option

in the "IPv6 NEIGHBOR DISCOVERY OPTION FORMATS"
registry at:
>

The IANA Considerations section says the following:

  "This document defines a new 128-bit value under the CGA Message Type
  [13] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08."

This document is asking for an assignment in a registry that is created
by another document .  The IANA will not be
able to make this assignment until that document is approved to become
an RFC.  We are confirming that this is correct.

A new registry (name space) will be created for Name Type fileds
in the Trust Anchor option.  There are 2 values currently:

  1  DER Encoded X.501 Name
  2  FQDN

(New types allocated via Standards Action)

A new registry (name space) will be created for Cert Type fileds
in the Certification option.  There is 1 value currently:

  1  X.509v3 Certificate

(New types allocated via Standards Action)>

Document submission questionnaire from James Kempf:

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

James Kempf has reviewed the immediately previous verison, which went through WG Last Call in Feb., of the ID and he believes that it is sufficiently baked to forward to the IESG for publication. In addition, the design was implemented by at least one implementor, without any complications, though not specifically this draft.

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

The draft has been carefully reviewed by several prominent members of the WG, including Tuomas Aura and Pekka Savola who submitted comments. Pasi Eronen reviewed the 04 draft and submitted detailed commments.

Charlie Kaufman, who is not a WG member, also reviewed the immediately previous version of draft during WG Last Call and had a few basic comments about the underlying motivation and architecture which James Kempf discussed with him and resolved to his apparent satisfaction.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

James Kempf sent email the the WG chairs of the PKIX WG requesting a review of Section 6.1 for compliance with draft-ietf-pkix-x509-ipaddr-as-extn-03.txt, since the router certs in SEND use the address range extension in that draft, but received no response. That section should be reviewed by someone familiar with the PKIX address range extension prior to the draft being published.

 
4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

No.
 
5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

The WG concensus appears to be solidly behind the draft.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

No.
 
7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

Yes.

8) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary

IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover
other nodes on the link, to determine the link-layer addresses of
other nodes on the link, to find routers, and to maintain
reachability information about the paths to active neighbors.  If not
secured, NDP is vulnerable to various attacks.  This document
specifies security mechanisms for NDP.  Unlike the original NDP
specifications, these mechanisms do not make use of IPsec.

  - Working Group Summary

The only major issue in the WG about this document was that both
Microsoft and Ericsson declared that they had IPR on CGA technology.
This issue was resolved after license conditions agreeable to the
WG participants and suited for public domain software were posted by
the respective companies. Before this, the WG briefly investigated an
alternative that would have required the configuration of hosts with
certificates, which might have resulted in deployment problems.

Another significant issue in the WG focused around the design of the
protocol and whether it should be based on IPsec AH or stand on its
own. After documenting the alternatives and comparing their pros and
cons, the consensus of the WG was to use an ND options based approach
instead of IPsec. The benefits of this were lack of impact on IPsec
architecture and implementations, and better ability to make security
decisions based on application state. This is important, for instance,
for co-existence of SEND and insecure ND on the same link.

A minor issue involved how to represent the authorization for routers to
route a certain prefix. The WG originally favored attribute certificates,
but since the PKIX WG was planning on defining an identity certificate
extension for this purpose, the WG decided to go with the IP address
range extension in draft-ietf-pkix-x509-ipaddr-as-extn-03.txt. Note that
this constructs a normative dependence on that draft, and it would be
helpful if we could get that draft to advance as quickly as possible
(or alterntively figure out a way to remove the normative dependence)
since there is a market window on how long before it becomes too late
for SEND to achieve widespread deployment, and having an officially
published RFC is important for implementors.

  - Protocol Quality

    - is the protocol already being implemented?

The basic protocol design has been implemented on Linux, though not specifically the details in this draft. That implementation was used to fine tune the design, and the results of the fine tuning went into the final draft.

    - have a significant number of vendors indicated they plan to
      implement the spec?

We have heard from at least one vendor that has expressed interest in the protocol.
 
    - are there any reviewers (during the end stages) that merit
      explicit mention as having done a thorough review that resulted
      in important changes or a conclusion that the document was fine
      (except for maybe some nits?)

Major reviewers are listed above. There were no major changes in the draft after 00, mostly just a matter of fixing fine points.