Fwd: WG Action: Securing Neighbor Discovery (send)

[Paul Hoffman / VPNC <paul.hoffman@vpnc.org>]

This is of probable interest to the WG.

>From: The IESG <iesg-secretary@ietf.org>
>To: IETF-Announce: ;
>Subject: WG Action: Securing Neighbor Discovery (send)
>Date: Wed, 09 Oct 2002 15:47:17 -0400
>Sender: jhargest@cnri.reston.va.us
>
>
>
>A new IETF working group has been established in the Internet Area.
>Please contact the Area Directors or WG Chairs for additional
>information.
>
>
>Securing Neighbor Discovery (send)
>----------------------------------
>
>  Current Status: Active Working Group
>
>  Chair(s)
>      Pekka Nikander  <Pekka.Nikander@nomadiclab.com>
>      J. Kempf  <kempf@docomolabs-usa.com>
>
>  Internet Area Director(s)
>      Thomas Narten  <narten@us.ibm.com>
>      Erik Nordmark  <erik.nordmark@sun.com>
>
>  Internet Area Advisor
>      Erik Nordmark  <erik.nordmark@sun.com>
>
>  Mailing Lists
>      General Discussion		ietf-send@standards.ericsson.net
>      To Subscribe     		Majordomo@standards.ericsson.net
>          In Body      		subscribe ietf-send
>      Archive 
>	http://standards.ericsson.net/lists/ietf-send/threads.html
>
>Description of Working Group
>
>Neighbor Discovery is the basic protocol by which IPv6 nodes discover
>their default routers on the local link, and by which nodes on a local
>link resolve IPv6 addresses to MAC layer addresses, for delivery of
>packets on the local link. Neighbor Discovery is specified in RFC
>2461. One of the design principles behind Neighbor Discovery is to
>enable zero configuration, i.e., to allow hosts to start communicating
>with other hosts at the local link and in the Internet without any
>requirements for manual configuration.
>
>RFC 2461 specifies that IPsec AH should be used to secure signaling
>for Neighbor Discovery. Due to bootstrapping issues, only manual keying
>works and that is impractical for most cases. This is in conflict with
>the goal of Neighbor Discovery, namely to allow complete
>address autoconfiguration of a node.
>
>The objective of this working group is to define protocol support for
>securing IPv6 Neighbor Discovery without requiring manual keying. The
>following are charter items for the working group
>
>1) A threat assessment and trust model for local links will be
>    worked out. The threat assessment will clearly describe which
>    threats the Neighbor Discovery security solution(s) will address
>    and which are not addressed. The trust model will describe what
>    types of networks require what level of security solution.
>    Together these form a clear problem statement and a set of
>    requirements.
>
>2) A protocol for assuring authenticatable distribution of public keys,
>    that allows for example tying a public key to a node's IP address or
>    interface ID, and for example authenticating a router's
>    authorization to route, will be designed. The working group will
>    consider the presentation by Steve Bellovin at the SEND BOF as a
>    starting point.
>
>3) The use of the key distribution protocol and public key
>    cryptographic scheme for calculating digital signatures
>    in IPsec AH and/or ESP headers will be specified. IANA
>    may be requested to reserve one or more of the reserved
>    SPIs (1-255) for the protocol.
>
>The Working Group will attempt to use well-known and existing public
>key cryptographic protocols with good security properties, in order to
>reduce the risk of unintended side effects, and to expedite the
>completion of the work. The protocol will be designed to assure that all
>functions of RFC 2461 and RFC 2462 are addressed.
>
>Specifically out of scope is IPv4 and ARP. Although ARP has similar
>problems, there is a huge installed base of ARP. It seems unlikely that
>any substantial fraction of that installed based would be updated
>quickly enough to make a difference. On the other hand, IPv6 deployment
>is still its initial stages, and changes to Neighbor Discovery are more
>likely to be widely adopted, if the Working Group executes quickly
>enough on its task.
>
>  Goals and Milestones
>
>    NOV 02       First draft of draft-ietf-send-psreq-00.txt, the combined
>                 Neighbor Discovery threats and trust model drafts.
>
>    DEC 02       Complete draft-ietf-send-psreq-xx.txt and send to IESG for
>                 approval.
>
>    MAR 03       Complete selection of a public key scheme. Initial draft of
>                 key distribution protocol, draft-ietf-send-protocol-00.txt.
>
>    JUL 03       Intermediate draft of draft-ietf-send-protocol-xx.txt
>                 submitted to Security Directorate for security review.
>
>    DEC 03       Submit draft-ietf-send-protocol-xx.txt to IESG for
>                 approval.