2.3.14 Securing Neighbor Discovery (send)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-15

Chair(s):
Pekka Nikander <Pekka.Nikander@nomadiclab.com>
James Kempf <kempf@docomolabs-usa.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret.wasserman@nokia.com>
Internet Area Advisor:
Margaret Wasserman <margaret.wasserman@nokia.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:
Done  First draft of draft-ietf-send-psreq-00.txt, the combined Neighbor Discovery threats and trust model drafts.
Done  Complete selection of a public key scheme. Initial draft of key distribution protocol, draft-ietf-send-ipsec-00.txt.
Done  Complete draft-ietf-send-psreq-xx.txt and send to IESG for approval.
Done  Initial draft for CGA, draft-ietf-send-cga-00.txt.
Done  Intermediate drafts for draft-ietf-send-cga-xx.txt and draft-ietf-send-ipsec-xx.txt submitted to selected reviewers.
Dec 03  Submit draft-ietf-send-cga-xx.txt and draft-ietf-send-ipsec-xx.txt to IESG for approval.
Internet-Drafts:
  • - draft-ietf-send-psreq-04.txt
  • - draft-ietf-send-cga-02.txt
  • - draft-ietf-send-ndopt-00.txt
    • No Request For Comments

    Current Meeting Report

    Securing IPv6 Neighbor Discovery (SEND)

    These are the minutes for the Securing Neigbor IPv6 Discovery (SEND) WG meeting, held at IETF-58 on Tuesday, November 11, 2003, at Minneapolis Hilton. Thanks to Michael Richardson and Greg Daley for the notes, on which these minutes are based on.

    Decisions

    1. Probably last face-to-face WG meeting. Submit drafts to the IESG, keep the mailing list running at least until the drafts have passed the IESG review.

    Action Points

    Open action points from IETF-57

    IETF57-AP1: Re-charter

    Status: Closed. (Dec 5th)

    Later decision: The WG will skip the re-charter. The re-chartering would have been only technical in nature (not touching the real content of the WG, and the WG is closing.

    IETF57-AP8: WG LC on draft-ietf-send-ndopts

    Status: Delayed. (Dec 5th)

    New target date: December 2003.

    New action points from IETF-58

    IETF58-AP9: Advance draft-ietf-send-psreq at the IESG

    Owner: James Kempf

    Target date: November 2003

    Status: Pending IESG. (Dec 18th)

    Document scheduled for IESG meeting on Dec 18th

    IETF58-AP10: Submit draft-ietf-send-cga to IESG

    Owner: Pekka Nikander

    Target date: November 2003

    Status: Pending editor. (Dec 5th)

    Editor making last minor modifications. Draft expected to be submitted on week ending on Dec 12th.

    IETF58-AP11: Clarify measurements from implementation report

    Owner: James Kempf

    Target date: November 2003

    Status: Closed. (Nov 28th)

    Details sent to the mailing list.

    IETF58-AP12: Discuss CGA address selection at mailing list

    Owner: Pekka Nikander

    Target date: November 2003

    Status: Closed. (Nov 31th)

    Discussion ongoing.

    IETF58-AP13: Cover different functions of Redirect

    Owner: Jari Arkko

    Target date: December 2003

    Status: Open.

    IETF58-AP14: Add text on unsolicited ND to NDOPTs

    Owner: Jari Arkko

    Target date: December 2003

    Status: Open.

    IETF58-AP15: Remove excess text from NDOPTs

    Owner: Jari Arkko

    Target date: December 2003

    Status: Open.

    IETF58-AP16: WG last call & board review on NDOPTs

    Owner: Chairs

    Target date: December 2003

    Status: Pending AP13-15.

    Milestones

    Review of open milestones

    Dec 03
    Submit draft-ietf-send-cga-xx.txt to IESG for approval.
    • Expected to be completed on week ending on Dec 12th.
    Dec 03
    Submit draft-ietf-send-ipsec-xx.txt to IESG for approval.
    • May be delayed until January 2004.

    Charter review

    Technically, the WG should be rechartered to reflect the fact that the WG will produce an ND OPTions based on approach instead of an IPsec based approach. However, it was decided that the rechartering will not be done since the WG is closing to end anyway.

    Discussion

    Pasi Eronen:
    I reviewed the CGA draft and even checked the hashes in the examples, and the draft seems to be OK.
    James Kempf:
    Thanks, these kinds of reviews are important, especially ones that go deep enough.
    Greg Daley:
    Did Jon Wood implement the DCS/DCA response delay? In other words, did the measured number include the DCS/DCA random delay?
    James Kempf:
    No, I don't think so. I will post a definite answer to the list.
    Margaret Wasserman:
    Question. HOW do we configure to use the secure address as the source address? All the other address selection rules in RFC3484 check the prefix of the address. How can the configuration table in RFC3484 dtermine if the address is a CGA address? Or do we always want to prefer the secure address?
    Christian Huitema:
    We already do this with RFC3014 privacy addresses. We might not want to prefer a CGA address, we might want to use some other address, a throw away address which we use for privacy. We may also want to use a different key for privacy addresses.
    Samita Chakrabarti:
    Answering to Margaret's question, in terms of source addresses it is implementation specific how to determine whether to use a CGA address or not. The local node will know if a given source address is a CGA or not. The MIPv6 API contains switching of addresses on/off.
    Jari:
    For care-of addresses, one might prefer, but why CGA?
    Samita:
    I am not sure, I am probably not the best person to answer this question. But please specify what the default mode is to be, to use CGA addresses or not? For the question of whether a new API should be created or not, please consult the IPv6 WG.
    [Clarification by Samita, send afterwards:
    draft-chakrabarti-ipv6-addrselect-api-02.txt already has a mechanism to choose CGA and NON-CGA source addresses by the application using socket api. The SEND wg needs to decide whether such API is needed for applications running on a SEND-node. Please send the decision on this to the IPv6 wg alias - based on that we will update the address selection API draft (which actually goes along with RFC3484).]
    Tony Hain:
    The new public keys will have to registered somewhere, right?
    Jari Arkko:
    We do not need any infrastructure to store the keys.
    James:
    These keys aren't being used elsewhere. Only in RS/ND.
    Tony Hain:
    If CGAs become the preferred addresses, we need to ensure that there is a place to make the keys available, since people will want to use the keys elsewhere. So, don't go there right now.
    James Kempf:
    We need to take this to the list.
    Greg Daley:
    I have not seen any hosts that send redirects. However, if there indeed are such cases, maybe we have to have a look into this.
    James Kempf:
    Lets take this, too, to the list.
    Pasi Eronen:
    I did the review of the NDopts document, too, and most of the issues are editorial in nature. For example, the ndopts document says the modifier is 16 bits and the CGA document states that it is 16 octets (or was it the other way around?). However, I have an issue with the timestamp algorithm. I am not sure whether it works with 1 second resolution for timestamp, even with less than 1 second timestamp. Allow things to be off by 1 second. But I've sent this comment to the list already. There seems to be also some text missing about unsolicited ND. If the node has some reason to update things, it can send them.
    Jari Arkko:
    Yes, we need to handle these issues. Thank you for bringing them up.
    Pasi Eronen:
    There is also lots of redundant text.
    Jari Arkko:
    Yes, the document needs some serious editing.
    James Kempf:
    The goal right now is to get the document ready, and announce another last call before the end of November, if possible. We will also send the document to the review board. Apparently, it will take some time to process the review comments, but the goal is to get the document ready for IESG before the end of the year. Then it usually takes 6-9 months to get through the IESG and the RFC Editor.
    Margaret Wasserman:
    We need to try to do better than 9 months for getting this through.
    James Kempf:
    The idea is to shut down the working group of the IESG review, but keep the mailing list running anyway.
    Margeret Wasserman:
    Maybe we need to keep the group on a hiatus if we need to go to draft standard. But that is just a process issue.
    James Kempf:
    I like things to start, cruise, and reach end. Hence I would prefer to close down the working group and run later another bof, if needed.

    Valid XHTML 1.0!

    Copyright  ©  2003 Internet Engineering Task Force.

    Slides

    Agenda
    SEND Linux Implementation Report
    Issues in the SEND base document
    CGA LC issues