Securing Neighbor Discovery Proxy: Problem Statement
RFC 5909

Received changes through RFC Editor sync (changed abstract to 'Neighbor Discovery Proxies are used to provide an address presence on a link for nodes that are no longer present on the link. They allow a node to receive packets directed at its address by allowing another device to perform Neighbor Discovery operations on its behalf.

Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for Neighbor Discovery messages.

Neighbor Discovery Proxy currently cannot be secured using Secure Neighbor Discovery (SEND). Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbor Discovery relates to SEND. This document is not an Internet Standards Track specification; it is published for informational purposes.')

[Ballot comment]
I am not, repeat NOT, a cryptographer, and am not familiar with ring signature schemes, but
my quick research on ring signature schemes came up with descriptions very different from those in section 4.1.3:

  This is the case, for example, with ring signature algorithms.  These
  algorithms generate a signature using the private key of any member
  from the same group, but to verify the signature the public keys of
  all group members are required. 

The abstract of "Cryptanalysis of a Generalized Ring Signature Scheme" (published in
vol. 6 no. 2 of IEEE Transactions on Dependable and Secure Computing) states:

      In a ring signature, instead of revealing the actual identity of the message signer, it
      specifies a set of possible signers. The verifier can be convinced that the signature
      was indeed generated by one of the ring members; however, the verifier is unable to
      tell which member actually produced the signature. A convertible ring signature
      scheme allows the real signer to convert a ring signature into an ordinary signature
      by revealing secret information about the ring signature.

These definitions seem in conflict.  One of the cryptographers here at NIST noted that
both descriptions seem to fall into the "group signature" class of algorithms, but she
was not immediately familiar with the term "ring signature" so she couldn't tell me which
was the accepted definition.

I would strongly encourage you to include a reference for the class of algorithms identified
in 4.1.3, since there is some confusion even within the cryptographic community.

[Ballot discuss]
After sleeping on this, I have changed one issue from a comment to a discuss...
specifically, I believe solutions that are based on group cryptographic algorithms
lack the maturity needed for standards track specifications so things described in 4.1.3
would need to be published as Experimental.

Accordingly, I believe a new section to the security considerations describing the
risks of being on the bleeding edge with cryptography should be added.  Where classes
of algorithms have  had limited scrutiny, there are risks that new attacks will be developed
in the future.  I think group algorithms are on the bleeding edge, and that makes this
class of solutions less attractive than the alternative.

[Ballot comment]
Section 2.3 states:

  The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a
  method by which multiple link layer segments are bridged into a
  single segment and specifies the IP-layer support that enables
  bridging under these circumstances.  The proxy in this case forwards
  messages while modifying their source and destination MAC addresses,
  and rewrites their Link-Layer Address Options, solicited, and
  override flags.

This is a bit misleading. Classic bridging does not require ND proxying
at all. However, there are circumstances outlined in RFC 4389 where
its desirable to implement ND proxying / ARP proxying instead of
classic bridging. I would suggest a small rewrite:

  The Neighbor Discovery (ND) Proxy specification [RFC4389] defines an
  alternative method to classic bridging. Just as with classic bridging,
  multiple link layer segments are bridged into a single segment, but
  with the help of proxying at IP layer rather than link layer bridging.
  The proxy in this case forwards
  messages while modifying their source and destination MAC addresses,
  and rewrites their Link-Layer Address Options, solicited, and
  override flags.

Section 4.1.2 says:

  When sending its Binding Update to the HA, the MN would need to
  provide a certificate containing the subject(proxy-HA)'s public key
  and address, the issuer(MN)'s CGA and public key, and timestamps
  indicating when the authority began and when it ends.  This
  certificate would need to be transmitted at binding time, possibly in
  a Certificate Path Advertisement [RFC3971].  Messaging or such an
  exchange mechanism would have to be developed.

If I have understood correctly, you are suggesting that the MN sends
a certificate to the router. If so, CPA seems the wrong message, as
it goes from the router to the host per RFC 3971.

(Much of the solution space discussion was enlightening, but details
like this you could also remove.)

[Ballot discuss]
Section 2.3 states:

  The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a
  method by which multiple link layer segments are bridged into a
  single segment and specifies the IP-layer support that enables
  bridging under these circumstances.  The proxy in this case forwards
  messages while modifying their source and destination MAC addresses,
  and rewrites their Link-Layer Address Options, solicited, and
  override flags.

This is a bit misleading. Classic bridging does not require ND proxying
at all. However, there are circumstances outlined in RFC 4389 where
its desirable to implement ND proxying / ARP proxying instead of
classic bridging. I would suggest a small rewrite:

  The Neighbor Discovery (ND) Proxy specification [RFC4389] defines an
  alternative method to classic bridging. Just as with classic bridging,
  multiple link layer segments are bridged into a single segment, but
  with the help of proxying at IP layer rather than link layer bridging.
  The proxy in this case forwards
  messages while modifying their source and destination MAC addresses,
  and rewrites their Link-Layer Address Options, solicited, and
  override flags.

[Ballot comment]
Several editorial improvements were suggested in the Gen-ART Review
  by Vijay Gurbani.  Please consider them.

  > 1) You may want to expand SEND before first use in Section 2;
  > you do so later on (below Figure 1), but should move that up.
  >
  > 2) S2.3, below Figure 3: The text says that "An alternative
  > (alluded to in an appendix of ND Proxy)..."  You may want to
  > provide a reference to the document containing this appendix.
  >
  > 3) S3.3: s/options) [RFC4389]/options) [RFC4389]./

[Ballot comment]
I am not repeat NOT a cryptographer, and am not familiar with ring signature schemes, but
my quick research on ring signature schemes came up with descriptions very different from those in section 4.1.3:

  This is the case, for example, with ring signature algorithms.  These
  algorithms generate a signature using the private key of any member
  from the same group, but to verify the signature the public keys of
  all group members are required. 

The abstract of "Cryptanalysis of a Generalized Ring Signature Scheme" (published in
vol. 6 no. 2 of IEEE Transactions on Dependable and Secure Computing) states:

      In a ring signature, instead of revealing the actual identity of the message signer, it
      specifies a set of possible signers. The verifier can be convinced that the signature
      was indeed generated by one of the ring members; however, the verifier is unable to
      tell which member actually produced the signature. A convertible ring signature
      scheme allows the real signer to convert a ring signature into an ordinary signature
      by revealing secret information about the ring signature.

These definitions seem in conflict.  One of the cryptographers here at NIST noted that
both descriptions seem to fall into the "group signature" class of algorithms, but she
was not immediately familiar with the term "ring signature" so she couldn't tell me which
was the accepted definition.

I would strongly encourage you to include a reference for the class of algorithms identified
in 4.1.3, since there is some confusion even within the cryptographic community.

I would also suggest adding a new section to the security considerations describing the
risks of being on the bleeding edge with cryptography.  Where classes of algorithms have
had limited scrutiny, there are risks that new attacks will be developed in the future.

[Ballot comment]
I am not repeat NOT a cryptographer, and am not familiar with ring signature schemes, but
my quick research describes ring signature schemes very differently.  From section 4.1.3:

  Specific cryptographic algorithms may help to allow trust between
  entities of a same group.

  This is the case, for example, with ring signature algorithms.  These
  algorithms generate a signature using the private key of any member
  from the same group, but to verify the signature the public keys of
  all group members are required.  Applied to SEND, the addresses are
  cryptographically generated using multiple public keys and the
  Neighbor Discovery messages are signed with an RSA ring signature.

The abstract of "Cryptanalysis of a Generalized Ring Signature Scheme" (published in
vol. 6 no. 2 of IEEE Transactions on Dependable and Secure Computing) states:

      In a ring signature, instead of revealing the actual identity of the message signer, it
      specifies a set of possible signers. The verifier can be convinced that the signature
      was indeed generated by one of the ring members; however, the verifier is unable to
      tell which member actually produced the signature. A convertible ring signature
      scheme allows the real signer to convert a ring signature into an ordinary signature
      by revealing secret information about the ring signature.

These definitions seem in conflict, but the class of algorithms seem to meet the stated
goal...

[Ballot comment]
I am not repeat NOT a cryptographer, and am not familiar with ring signature schemes, but
my quick research describes ring signature schemes very differently.  From section 4.1.3:

  Specific cryptographic algorithms may help to allow trust between
  entities of a same group.

  This is the case, for example, with ring signature algorithms.  These
  algorithms generate a signature using the private key of any member
  from the same group, but to verify the signature the public keys of
  all group members are required.  Applied to SEND, the addresses are
  cryptographically generated using multiple public keys and the
  Neighbor Discovery messages are signed with an RSA ring signature.

The abstract of "Cryptanalysis of a Generalized Ring Signature Scheme" (published in
vol. 6 no. 2 of IEEE Transactions on Dependable and Secure Computing) states:

      In a ring signature, instead of revealing the actual identity of the message signer, it
      specifies a set of possible signers. The verifier can be convinced that the signature
      was indeed generated by one of the ring members; however, the verifier is unable to
      tell which member actually produced the signature. A convertible ring signature
      scheme allows the real signer to convert a ring signature into an ordinary signature
      by revealing secret information about the ring signature.

These definitions seem in conflict, but the class of algorithms seem to meet the stated
goal...

[Ballot comment]
I am not repeat NOT a cryptographer, and am not familiar with ring signature schemes, but
my quick research describes ring signature schemes very differently.  From section 4.1.3:

  Specific cryptographic algorithms may help to allow trust between
  entities of a same group.

  This is the case, for example, with ring signature algorithms.  These
  algorithms generate a signature using the private key of any member
  from the same group, but to verify the signature the public keys of
  all group members are required.  Applied to SEND, the addresses are
  cryptographically generated using multiple public keys and the
  Neighbor Discovery messages are signed with an RSA ring signature.

The abstract of "Cryptanalysis of a Generalized Ring Signature Scheme" (published in
vol. 6 no. 2 of IEEE Transactions on Dependable and Secure Computing) states:

      In a ring signature, instead of revealing the actual identity of the message signer, it
      specifies a set of possible signers. The verifier can be convinced that the signature
      was indeed generated by one of the ring members; however, the verifier is unable to
      tell which member actually produced the signature. A convertible ring signature
      scheme allows the real signer to convert a ring signature into an ordinary signature
      by revealing secret information about the ring signature.

These definitions seem in conflict, but the class of algorithms seem to meet the stated
goal...

[Ballot comment]
Section 5

  The previous part of this document focused on the case where two
  nodes defend the same address (i.e. the node and the proxy).  But,
  there are scenarios where two or more nodes are defending the same
  address.

I read this a couple of times and it doesn't compute :-)
Firstly I suggest you insert a reference in place of "the previous part
of this document".
Secondly: can you resolve the "But"? The second sentence seems to say,
"but the first sentence is true"!

---

A petty nit...

Would you consider changing the title to...
Problem Statement for Securing Neighbor Discovery Proxy
...or...
Securing Neighbor Discovery Proxy : Problem Statement
...to add a little clarity.

[Ballot discuss]
I have reviewed draft-ietf-csi-sndp-prob-03, and have a couple of
questions/concerns that I'd like to discuss before recommending
approval of the document:

- I think the text about IKEv2 (Section 2.2) is quite misleading. As
far as I know, in most security gateway deployments the gateway has a
block of addresses, and "intercepting" packets sent to this block is
handled by routing (static routes or intra-AS routing protocol), not
by ND/ARP messages.

It's not totally impossible that the approach described in Section 2.2
could be used, but IMHO it would be rare.

- For Mobile IPv6, I guess we don't really have deployments, but are
there any SDOs that are even considering deployments where one MN
would *ever* see ND queries from another MN, even if both are at home?
(AFAIK in most other SDO specs, every MN gets a full IPv6 prefix, so
securing NS/NA is not really an issue -- and RS/RA is handled by
security the point-to-point link to the router.)


From Stephen Farrell's SecDir review:

- Section 4.2.6: I think current best practices usually avoid
increasing certificate serial numbers (and use random-looking serial
numbers instead).  I'd suggest either deleting that if its felt to be
unlikely used, or else, if its actually likely to be used, then
documenting how it could actually work

- In Section 7.2, I would strongly recommend deleting the word
"non-repudiable" (or alternatively, explaining what is meant by
the term in this context -- it's very overloaded term.)

Document Shepherd Write-up fordraft-ietf-csi-sndp-prob-02

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

          The document shepherd is Marcelo Bagnulo who has reviewed
          this version of the document and believes that us ready for
          forwarding to the IESG for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

          The document has been reviewed by 6 reviewers and the reviews
          were thorough. We issues 2 WGLC. During the first one, we
          received the reviews and during the second one, nobody objected.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

          No.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

          No special concerns or issues. The document is an informational
          document describing the problem and the solution space.

  (1.e)  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 document describes one of the main problems the CSI is
          chartered to work on. The understanding of the problem by the
          WG is good and this is reflected in the document.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

          No conflicts.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

          I have verified the ID nits.
          There a couple of references that need updating (already
          informed the authors) and there is no disclaimer for
          pre-RFC5378 work, but i don't think it is needed in this case.

          No MIB Doctor, media type nor UR type reviews are needed for
          this document.

          The document intended status is informational.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

          The references are split into normative and informative.
          All normative references are in RFC state. The is no
          downward dependency, since this is an informational document.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

          The document has a IANA considerations section, but there is no
          IANA action required. No protocol extensions are required
          No new registry is created.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

          The document does no contain any section written in a formal
          language.
 
  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

  Neighbor Discovery Proxies are used to provide an address presence on
  a link for nodes that are no longer present on the link.  They allow
  a node to receive packets directed at its address by allowing another
  device to perform neighbor discovery operations on its behalf.

  Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols
  to provide reachability from nodes on the home network when a Mobile
  Node is not at home, by allowing the Home Agent to act as proxy.  It
  is also used as a mechanism to allow a global prefix to span multiple
  links, where proxies act as relays for Neighbor discovery messages.

  Neighbor Discovery Proxy currently cannot be secured using SEND.
  Today, SEND assumes that a node advertising an address is the address
  owner and in possession of appropriate public and private keys for
  that node.  This document describes how existing practice for proxy
  Neighbor Discovery relates to Secured Neighbor Discovery.


          Working Group Summary
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?

          Nothing special that worth noting. Not a controversial document.

          Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)?  In the case of a Media Type
            Review, on what date was the request posted?

          The document is an informational problem statement. The problem
          described in one of the main issues the CSI is chartered to
          work on. There is already a WG document describing a proposed
          solution to the problem.
          The document had 5 through reviews, including reviews from
          Julien Laganier, Sheng Jiang, Tony Cheneau and no substantive
          issues were identified.

          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?  If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'

        Document shepherd: Marcelo Bagnulo
        Area Director: Ralf Droms