Securing Neighbor Discovery Proxy: Problem Statement
RFC 5909

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    csi mailing list <cga-ext@ietf.org>, 
    csi chair <csi-chairs@tools.ietf.org>
Subject: Document Action: 'Securing Neighbor Discovery Proxy: Problem Statement' to Informational RFC

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.