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

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

Lars Eggert No Objection

(Jari Arkko; former steering group member) Yes

Yes (2010-07-01 for -** No value found for 'p.get_dochistory.rev' **)
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; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Alexey Melnikov; former steering group member) (was Discuss) No Objection

No Objection (2010-07-21 for -** No value found for 'p.get_dochistory.rev' **)
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.

(Dan Romascanu; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Peter Saint-Andre; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Robert Sparks; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Stewart Bryant; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Tim Polk; former steering group member) No Objection

No Objection (2010-07-15 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I support Sean's discuss.