Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)
RFC 6496

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

(Jari Arkko) Yes

Comment (2010-07-01 for -)
No email
send info
This is a very well written specification and it was nice to read it.
I did not spot any major or minor issues.

However, we have in the past discussed the question of compatibility
with non-SEND, SEND, and proxy SEND nodes. I think the current 
specification is now reasonable in that respect. However, I think that
the decision to employ two levels of security in proxied messages (ND
or SPND) has lead to the rules that are not optimal in all circumstances.
In particular, the document says:

   As a rule of thumb, if the proxied nodes can return to the link in
   which the proxy operates, the Secure ND Proxy MUST only generate PS
   options on behalf of nodes with SEND capabilities (i.e. that they
   could use SEND to defend their messages if being in the same link
   than the proxy, either RFC3971 nodes or SPND nodes).  This is
   relevant to allow nodes preferring secured information over unsecured
   one ...

What this essentially says is that unless there is knowledge about the
network structure and movement patterns, secure proxy cannot proxy
plain old ND messages with security at all. I happen to believe that
this situation is the typical situation. 

If you had provided one additional bit of information in the secure
proxy messages about the SEND/non-SEND status of the original message,
there would not be this limitation. You could have amended the
backwards compatibility rules of SEND to prefer native SEND messages
over proxied SEND messages over unsecured ND messages.

I would like to ask the authors to consider this before final approval
of the document as an RFC.

(Ralph Droms) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Lars Eggert) No Objection

(Adrian Farrel) No Objection

(Russ Housley) No Objection

Alexey Melnikov (was Discuss) No Objection

Comment (2010-07-21 for -)
No email
send info
The last sentence in section 5.2.2 looks out of sync when compared to the text in item 1 of the same section.

I am also agreeing with Sean's DISCUSS.

(Tim Polk) No Objection

Comment (2010-07-15 for -)
No email
send info
I support Sean's discuss.

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Sean Turner) (was Discuss) No Objection