Document Action: 'Secure Proxy ND Support for SEND' to Experimental RFC (draft-ietf-csi-proxy-send-05.txt)

The IESG <iesg-secretary@ietf.org> Mon, 21 March 2011 21:26 UTC

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Document Action: 'Secure Proxy ND Support for SEND' to Experimental RFC (draft-ietf-csi-proxy-send-05.txt)
Message-ID: <20110321212627.19002.4638.idtracker@localhost>
Date: Mon, 21 Mar 2011 14:26:27 -0700
Cc: csi chair <csi-chairs@tools.ietf.org>, Internet Architecture Board <iab@iab.org>, csi mailing list <cga-ext@ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Precedence: list

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 (marcelo@it.uc3m.es) is the document shepherd.  Ralph
   Droms (rdroms.ietf@gmail.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.

Document Action: 'Secure Proxy ND Support for SEN… The IESG