Subject: WG Action: Securing Neighbor Discovery (send)

From: The IESG <[email-masked]>
Date: Wed, 09 Oct 2002 15:47:17 -0400

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  <[email-masked]>
     J. Kempf  <[email-masked]>

 Internet Area Director(s)
     Thomas Narten  <[email-masked]>
     Erik Nordmark  <[email-masked]>

 Internet Area Advisor
     Erik Nordmark  <[email-masked]>

 Mailing Lists 
     General Discussion		[email-masked]
     To Subscribe      		[email-masked]
         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.