Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, csi mailing list <firstname.lastname@example.org>, csi chair <email@example.com> Subject: Document Action: 'Secure Proxy ND Support for SEND' to Experimental RFC (draft-ietf-csi-proxy-send-05.txt) The IESG has approved the following document: - 'Secure Proxy ND Support for SEND' (draft-ietf-csi-proxy-send-05.txt) as an Experimental RFC This document is the product of the Cga & Send maIntenance Working Group. The IESG contact persons are Ralph Droms and Jari Arkko. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-csi-proxy-send/
Technical Summary Secure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats. As defined today, SEND assumes that the node sending a ND message is the owner of the address from which the message is sent, so that it is in possession of the private key used to generate the digital signature on the message. This means that the Proxy ND signaling performed by nodes that do not possess knowledge of the address owner's private key cannot be secured using SEND. This document extends the current SEND specification in order to secure Proxy ND operation. Working Group Summary Nothing special that worth noting. Not a controversial document. Document Quality The document has benefited from a number of reviewers, who are detailed in the ACK section of the draft. Personnel Marcelo Bagnulo (firstname.lastname@example.org) is the document shepherd. Ralph Droms (email@example.com) is the responsible AD. RFC Editor Note In Section 6.3, please make the following change: OLD: 4. The PS option MUST be added as the last option in the message, signing all the information contained so far in the message. To be able to sign any NS, NA, RS, RA o Redirect message, the key used must correspond to a certificate with KeyPurposeId values of id-kp-sendProxiedOwner and id-kp-sendProxiedRouter. NEW: 4. The PS option MUST be added as the last option in the message, signing all the information contained so far in the message. To be able to sign any NS, NA, RS, RA or Redirect message, the key used MUST correspond to a certificate with KeyPurposeId values of id-kp-sendProxiedOwner and id-kp-sendProxiedRouter.