2.3.12 Securing Neighbor Discovery (send)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-02-12

Pekka Nikander <Pekka.Nikander@nomadiclab.com>
James 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.
  • - draft-ietf-send-psreq-01.txt
  • - draft-ietf-send-ipsec-00.txt
  • No Request For Comments

    Current Meeting Report

    Securing Neighbor Discovery WG (send)
    Tuesday, March 18 at 1545-1645
    CHAIRS:	James Kempf <kempf@docomolabs-usa.com>
    	Pekka Nikander <Pekka.Nikander@nomadiclab.com> 
    5 min. - Agenda discussion, chairs
    The agenda was accepted.  The chairs later on changed it so that
    the second last item, interaction with PANA / DHCP, was moved after
    the last item, draft status and schedule.
    10 min. - Last Call Issues as resolved for 
              Pekka Nikander
    Pekka Nikander went over the issues raised during the WG last call.
    Most of the issues were minor.  However, there were two larges
    issues, worth spending some face-to-face time.
    The first issue centered around using the term "trust".  Currently the
    draft uses the term trusts, trusted, trustworthy, etc., in multiple
    places.  However, it would be better to replace the word with more
    specific words, e.g. "delegation", "authorized", etc.  Pekka
    described how the word is used right now, but also told that he is
    not very happy with the current resolution of the issue.  Bill
    Sommerfeld came up and promised to come up with alternate wording
    suggestion by the end of next week (March 28th).  It was decided that
    if Bill comes up with an acceptable alternate wording, that will be
    incorporated to the next version of the draft.  Otherwise the current
    wording will be used.
    The other problematic issue was that the current draft discusses a
    number of possible solutions.  Even though these solutions are only
    used for illustrative purposes, some people had been raised the
    question on the mailing list whether a problem statement document
    should include this kind of text at all.  The discussion at the
    mailing list has inconclusive.
    James Kempf (taking his chair hat off) suggested that the solutions
    text should be left in the draft, after all, as examples.  Bill
    Sommerfeld supported that, and Alper Yegin (who had raised the issue
    originally) agreed that the solutions can stay in as long as it is
    explained that they are just examples.  Thus, the decision was to
    keep the solutions in the text.
    10 min. - Self Signed Certificates for CGAs, Tuomas Aura (presented
               by Pekka Nikander)
    Pekka Nikander presented Tuomas Aura's slides on his generic draft on
    using Cryptographically generated IPv6 addresses (CGA).  (See the
    Pekka told that as far as he knows, the idea is covered by IPR at
    least by Ericsson and possibly by Microsoft.  Ericsson has recently
    released the IPR on this; the statement has been posted to the mailing
    list and is available at the IETF IPR page.  The chairs are 
    the issue with Microsoft now.
    Hesham Soliman asked whether is the IPR on the CGA idea, or on
    specific applications?  Pekka replied that as far as he knows, the
    IPRs cover the CGA idea itself.
    One of the biggest technical problems with CGA so far has been the
    fact that the IPv6 address structure limits the hash length into 62
    bits, which is somewhat insecure.  The basic idea in
    draft-aura-cga-00.txt a method for removing this 64 bit limit by
    introducing a security parameter (sec) and a seconnd hash (see the
    slides).  With this technique, the cost of address generation and the
    cost of attacks are increased, keeping their ratio 2^59, but the cost
    of verification remains constant.  Furthermore, the additional cost
    possibly imposed at address generation can be divided over multiple
    addresses, since the second hash is independent on the routing prefix
    and can therefore be used multiple times.
    In addition to solving the problem with short hash lengths the draft
    provides exacts algorithms and formats for using CGA addresses.
    After the presentation Jari Arkko went to the microphone and expressed
    that he liked this draft, that he likes the idea of generating two
    separate hashes, and that it looks good for fast mobility.
    20 min. - Open Issues on 
    draft-ietf-send-ipsec-00.txt, Jari Arkko
    (see slides)
    The Design Team has worked on a solution for some time now, and the
    draft represents a snapshot of the current thinking.  Jari first went
    through the overall design, and the continued to the most important
    issues with the document.
    The first issue with the document is that it has somewhat broad
    scope, describing several more or less independent techniques, and it
    looks like the final draft might become quite large.  Furthermore,
    since CGA is covered by IPRs, it may be necessary to split the CGA
    dependent portions of the draft out.  
    James Kempf opinioned that if the Working Group is able to get the CGA
    IPR released, the draft does not have to be split.  A split could slow
    down the process.  Thus, all parts should go together.  Bill
    Sommerfeld seconded that splitting out CGA makes sense.  Alper Yegin
    said that since there are two independent problems and solutions,
    Neighbor Discovery and Router Discovery, it makes sense to split, so
    that one or the other part can be replaced with alternative methods
    when they are available.
    After some discussion the chairs declared consensus on that if CGA IPR
    not resolved, we need to split CGA as a separate part.  Otherwise,
    we'll go with one draft, since there doesn't seem to be any
    compelling reason to split, and there seems to be different
    suggestions for splitting, without any single one getting any larger
    The second open issue considered the presented transition scheme.  The
    basic idea in the transition scheme is to view the link as two
    separate logical links, one being secured with SEND and the other one
    not.  Alper Yegin noted that there is a problem with DAD when some
    nodes do not support SEND.  That can lead to colliding link-local IPv6
    addresses.  Erik Nordmark noted that the two colliding addresses
    should be considered to be on two separate links, so no problem.
    However, this might require implementation considerations.  Pekka
    Savola noted that possibley one could also look at the G bit.  Erik
    Nordmark continued that what doesn't work in this case is that DAD is
    not going to detect two identical mac addresses being same.  This
    has some disadvantages.
    In general, it looks like the transition scheme has still some open
    issues and requires more consideration.
    The next open issues considered solicitations.  Some soliciations have
    side effects, and therefore they should be secured.  However, some
    solicitations use unassigned source address, and therefore it is very
    hard to secure them with CGA.  Dave Thaler said that there is clearly
    a threat with the solicitations, the solution should handle
    it.   Additionally, the requirements draft should talk about this
    threat.  It was agreed that the requirements draft must be updated to
    handle this.
    The overall plan is to run the Design Team for another couple of
    months to resolve the remaining technical issues.  At the same time,
    the chairs continue talking to the IPR holders on CGA, to get the IPR
    released specifically for SEND.
    5 min.  - Draft Status and Schedule, chairs
    James Kempf discussed the draft status and schedule (see slides).
    There was no discussion.
    10 min. - Interaction with PANA / DHCP, chairs
    The final item considered interaction with SEND and PANA and DHCP.
    Pekka Nikander described some possible scenarios, mainly made to give
    people something to think about.  (see slides)
    Bernard Aboba said that passing PANA created keys between various
    parties is not a good idea.  The overall system looks very complex,
    and analysing it would be a nightmare.  Parijat Mishra said that in
    his opinion this is a good idea.  If we don't do this, we'll end up
    with too many keys.  Bill Sommerfelds reaction was similar to that of
    Bernard.  There is gotta be a better way.  Erik Nordmark said that a
    short write up on what kind of problems we are solving here would be


    SEND IPSEC Protocol
    Cryptographically Generated IPv6 Addresses (CGA)