Securing Neighbor Discovery Proxy: Problem Statement
RFC 5909

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

(Ralph Droms) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lars Eggert) No Objection

(Pasi Eronen) (was Discuss) No Objection

(Adrian Farrel) No Objection

Comment (2009-12-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Russ Housley) No Objection

Comment (2009-12-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  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]./

(Cullen Jennings) No Objection

(Tim Polk) (was Discuss, No Objection) No Objection

Comment (2009-12-03)
No email
send info
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.

(Dan Romascanu) No Objection

(Robert Sparks) No Objection

Magnus Westerlund No Objection

(Jari Arkko) (was Discuss) Recuse

Comment (2009-12-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.)