Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)
Note: This ballot was opened for revision 05 and is now closed.
(Jari Arkko) Yes
Comment (2010-07-01 for -)
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 -)
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 -)
I support Sean's discuss.