The IESG has approved the following document: - 'Securing Neighbor Discovery Proxy: Problem Statement ' <draft-ietf-csi-sndp-prob-04.txt> as an Informational 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://www.ietf.org/internet-drafts/draft-ietf-csi-sndp-prob-04.txt Technical Summary Neighbor Discovery Proxies are used to provide an address presence on a link for nodes that are no longer present on the link. They allow a node to receive packets directed at its address by allowing another device to perform neighbor discovery operations on its behalf. Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for Neighbor discovery messages. Neighbor Discovery Proxy currently cannot be secured using SEND. Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbor Discovery relates to Secured Neighbor Discovery. Working Group Summary Nothing special that worth noting. Not a controversial document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? Personnel The document is an informational problem statement. The problem described in one of the main issues the CSI is chartered to work on. There is already a WG document describing a proposed solution to the problem. The document had 5 through reviews, including reviews from Julien Laganier, Sheng Jiang, Tony Cheneau and no substantive issues were identified. RFC Editor Note (1) In Section 4.1.3, please make the following substitution: OLD 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. Applied to SEND, the addresses are cryptographically generated using multiple public keys and the Neighbor Discovery messages are signed with an RSA ring signature. NEW 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. Applied to SEND, the addresses are cryptographically generated using multiple public keys and the Neighbor Discovery messages are signed with an RSA ring signature. [RING] (Note that the cryptographic algorithms that are the foundation for [RING] and other similar solutions are not widely accepted in the security community; additional research is needed before a standards track protocol could be developed.) (2) Please add the following reference in Section 9.2: [RING] Kemp J., and C., Gentry, "Secure IPv6 Address Proxying using Multi-Key Cryptographically Generated Addresses (MCGAs)", draft-kempf-mobopts-ringsig-ndproxy-02.txt, 22 August 2005. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
