2.3.12 Securing Neighbor Discovery (send)

Last Modified: 2003-07-29

Pekka Nikander <Pekka.Nikander@nomadiclab.com>
James Kempf <kempf@docomolabs-usa.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <mrw@windriver.com>
Internet Area Advisor:
Margaret Wasserman <mrw@windriver.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

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
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.
Jul 03  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.
  • - draft-ietf-send-psreq-03.txt
  • - draft-ietf-send-ipsec-01.txt
  • - draft-ietf-send-cga-01.txt
  • No Request For Comments

    Current Meeting Report

    SEND Working Group Minutes
    IETF57, Vienna, Austria
    Monday, July 14, 9:00 am
    Minutes produces by the chairs, based on notes taken by TJ Kniveton and 
    Michael Richardson.  Thanks to the notetakers.
    Executive summary
    draft-ietf-send-psreq-01.txt is at the IESG, waiting for review.
    The working group deciced to move from using IPsec into using ND 
    options.  Discussion on some smaller open issues needs to continue at the 
    mailing list. The document editor will revise the document soon, and the 
    plan is to have the next version of protocol draft will be out at the end of 
    August, possibly with some certificates related work to be done.  WG last 
    call is expected in October.
    Moving from IPsec to ND options requires re-chartering.  This is OK with the 
    The IPR holders on CGA have released they IPRs (royalty-free license) on CGA 
    for SEND purposes; CGA is technically almost completed.  WG last call is 
    planned in August.
    Introduction and Agenda Bashing (5 min.) Chairs
      Introduction and Agenda Bashing (5 min.) Chairs
      Draft Status (10 min.) Chairs
      Implementation Report (20 min.) Pekka, James
      IPR discussion (10 min) all, with chairs moderating
      Open issues in draft-ietf-send-ipsec (20 min) Jari
      IPsec, IPsec w. CGA Header, or ND options?
         ND options (10 min) Jari
         IPsec w. CGA header (10 min) Pekka
         technical discussion (40 min or until done),
         all with James moderating
       Summary and Way Forward (10 min). Chairs
    Draft Status (10 min.) Chairs
    draft-ietf-send-psreq-03.txt has been submitted to the IESG at the end of 
    April, intended to be published as an Information RFC.  The IESG review has 
    not begun yet.
    draft-ietf-send-ipsec-01.txt has a number of open issues, the largest of 
    which was to issue of whether to use IPsec or ND options.  The issue was 
    resolved, and ND options will be used, as reported below.
    draft-ietf-send-cga-00.txt is fairly close to be completed, but some 
    details still need discussion at the mailing list.
    Implementation Report (20 min.) Pekka, James
    Pekka went over implementation notes for FreeBSD.  Basically, they did not 
    get very far before realizing that the WG draft needs some changes.  
    Firstly, directly mixing CGA and AH is a bad idea.  There would be a need to 
    change PF_KEY data structure quite a lot. Secondly, doing PK crypto is hard 
    without kernel threads, so PK crypto operations need to be passed to user 
    space (possibly through the revised PF_KEY interface).
    What comes to the CGA draft, it seems fairly good.  It was easy enough to 
    implement an ifconfig extension for CGA configuration.  However, 
    generating the modifier must be done with a separate user space tool, 
    since it may take a long time to compute.
    PF_KEY and ifconfig can be used for communication between the user space and 
    the kernel space.  Bigger issue is whether to do PK operations in a 
    kernel thread or at the user space.
    The code is available by request.
    James described another implementation, written by Jonathan Wood.  It 
    partially implements the WG draft on linux 2.5.x (w/ IPsec for v4 and v6).  
    The focus of the implementation work was replicating what a vendor would 
    implement, and to be conformant with the IPsec RFCs.
    One of the results is that the WG draft approach would have a major 
    impact on the IPsec fast-path (interrupt context at bottom of driver). RSA, 
    ASN.1, and cert chain retrieval are not realy suitable for the 
    interrupt context.  Additionally, the approach would have a high impact on 
    the IPsec transform interface, the existing one in the Linux kernel 
    wouldn't work.  Hence, no work would saved by using IPsec because 
    implementation has to be restructured.
    What comes to CGA, it seems to be ok for kernel use as specified. 
    However, it is best to be implemented with a specialed ASN.1 parser, which 
    leads to losses in extensibility.
    Performance results are shown on the slides.
    Summary: The Linux IPsec design is not well suited for PK 
    algorithms; SEND implementation would require restructuring of kernel fast 
    paths.  CGA gets good, efficient results (based on Sec parameter).
    Michael Richardson: Linux 2.5 implementation of IPsec does not support 
    async hardware offload of cryptographic operations.  Going to external hw 
    for symmetric crypto, you have to suspend all processing; 
    effectively same problem as doing RSA in user space.  May need to 
    re-evaluate the conclusion that there is no advantage of using IPsec, 
    because the Linux hardware acceleration code is < 6-8 months old.  The code 
    is not in 2.6; don't know when API will get to usable hw offload.
    Pekka: Someone might want to implement on OpenBSD which already has hw 
    offload.  Regarding second point, with AH just as a PK algorithm 
    (without CGA), there is no need to restructure the kernel transport 
    Bob Hinden: What about people building low-power, slower systems.
    James: If Sec is 0, it is only microseconds.
    Bob Hinden: If we want this to be useful everywhere, CPU performance is an 
    Pekka: Hash extension pre-computation has to be done once.  So for sec 
    higher than 0, you can offload pre-computation to another node. Don't need to 
    do it again unless you change your public key.
    IPR discussion (10 min) all, with chairs moderating
    Ericsson released IPR before SF IETF.  Microsoft has released IPRs about a 
    week ago.  These are royalty-free, non-discriminatory licenses.  
    However, do read IPR notes at IETF site for details.
    As far as the chairs know, there are no other IPR claims.  Anyone 
    knowing about IPRs related to draft must inform the IETF.
    Based on this, the chairs polled on objections on using CGA? (no).The WG 
    decided to go ahead and use CGA.
    Open issues in draft-ietf-send-ipsec (20 min) Jari
    Very good reviews received during the last month.  The resulting issues all 
    at the URL shown on slides.
    Issue #7 - certificate-only ND protection
    - - - - - - - - - - - - - - - - - - - - -
    Complaint: not well thought out.  The authors agree.  The authors 
    proposal, based on new information about IPRs, to remove the text of using 
    certificates for ND; just rely on CGA.  ND certificates could be added as an 
    extension later.
    Francis Dupont: Don't believe dropping ND certificates is a good idea. CGA 
    does not provide the same properties.
    Jari: With certificates, can also ensure this node is a member of this 
    company, etc.  Agreed.
    Michael Richardson: Don't think I understand your proposal. Is it to say I 
    will use a CGA address signed by key, but PK is not authorized by CA. 
    (yes.) I rather we went forward quickly, but I am concerned that req for 
    retrieving cert chains may be significant chain to state machines and 
    operational pieces. Might find ourselves in a bad situation in the future 
    because it may be hard to add later.
    Jari: Yes, but for discovering routers, we would still use 
    certificate discovery. Just drop it for NS & NAs for now.
    Rick A.?: Isn't is straight-forward to add a capability in hosts to say no, I 
    don't have a certificate chain. Because you should provide trust chain, but 
    you can give a simple NAK. I don't have a trust chain to give you. At 
    least you know that you got a response.
    Jari: Current spec has some aspects of that.  But some details have not 
    been fully thought out. It's a little tricky with addressing, before ND is 
    Pekka: More practical problem is that we'd like to advance draft, and 
    current text is not specific enough.  We'd like to leave it out for now.  If 
    anyone in room would like to rewrite?  Otherwise we would like to take out.
    Rick: I'm willing to work on text, either for WG draft or parallel draft.
    James: Issues with certificate interoperability as well.
    Pekka Savola: We have to consider scenario where this would give 
    additional protection.  Where layer 2 or lower has not 
    authentication to network. So what is the applicability?
    Pasi Eronen: Agree with chairs that it should be dropped now.  Current spec 
    does not say how it should work.  So there is no section in draft to 
    James: Some L2 protocols provide certified MAC address.  That would be 
    ideal situation for SEND. But Cable Licensing? is only L2 protocol that 
    does that.
    The WG decision was to remove the ND certificate facility for now. 
    However, if someone (Rick?) produces a separate draft on that, it can be 
    accepted as a WG item.
    Issue #14: CGA RD protection useful?
    - - - - - - - - - - - - - - - - - -
    Michael: To me, this seems like worst of both worlds. We have code for 
    both; can't use both; we have to deal with certs in kernel even when we 
    don't want to talk to peers. Don't see optimizations except towards 
    shortest IETF process.
    Jari: Different problems: ND problem, RD problem. Need slightly 
    different security solution
    Pekka: Might help on router discovery for ad-hoc networks.  But this is not 
    the focus of WG.  So dropping this is OK with me.
    Tuomas: Might make sense to protect, even if you don't have 
    authorization for the router, to prove address ownership.
    Michael: Any network that doesn't have certificate is an "ad-hoc" 
    network, e.g., this network at Telekom Austria, since DNS was not 
    reloaded on Monday morning.  Can't get certificate because they're 
    closed.  Maybe we should have more documents: How to protect ND with PK, how 
    to protect RD with PK, how to get PK addressed CGA, how to deal with cert 
    retrieval.  We could proceed with getting reviews of some of the pieces.  I 
    feel afraid of getting a certificate for my router, because 95% of people 
    won't be able to do that without putting out dollars.
    James: This is mainly simplicity. CGA with RD doesn't provide a lot of 
    security, just that router is authorized to send packet with the 
    Dave: Question is whether threats are significant enough to protect 
    Pasi: CGA-only RD protection may not be useful, but used with 
    certificates, it might be.
    Rick: Isn't really secure to use CGA on these things, but you can choose any 
    prefix you like, so it may be possible hijack a prefix.
    Dave: True, but this is denial of reachability.
    Rick: Unless you can tunnel to a different link.
    Tuomas: Using CGA and certs together makes sense, because you may trust 
    router for a prefix, but not to steal IP address of another router on the 
    Pekka: Getting feeling we want to use CGA with certs, but what about CGA 
    without certs?  We can discuss on the ML.
    Issue #6 - Millisecond granularity for protecting against replays is not 
    fine enough?
    - - - - - - - - - -
    May be future high-speed link where this is problematic. Can decide this is 
    not an issue (1000 messages/s is enough), or change rule that you can 
    still receive during same 1-ms interval, but monotonically 
    increasing.  Normally we try to prevent replays, but for ND & RD, replay 
    "attacks" in short amount of time may not be a problem.
    Pekka: slight difference in semantics of timestamp between ND options and 
    CGA header.  In the CGA header approach, the timestamp is a kind of 
    lifetime for the security association, but in ND options, it's just a 
    Michael: I would prefer you put 16 bits of decimal-point seconds. So 
    seconds / 64k (50 us).  Monotonically increasing seems simpler. Do you 
    really need to produce thousands or millions of ND messages per second?  May 
    be a question to mobile phone operators, for rate of movement from one BS to 
    another. Or how fast are trains moving in the future.
    Jari: Large # of nodes on the same link may cause this. But currently 
    limits on how fast routers respond to router discovery. But I like your 
    suggestion about 64k.
    Dave: What is resolution?
    James: Jari will make a suggestion to the list.
    Issue 14 - Certificate details (James)
    - - - - - - - - - - - - - - - - - - - -
    Comments from review board - problems using attribute 
    certificates. RFC3281 is a fairly New spec, not a lot of 
    infrastructure in place as with PKC certs.  A disadvantage of using PKC 
    certs is that we need a new extension.  We would have certificate chain 
    mirroring prefix delegation.
    Unfortunately, attribute certificate chains not permitted by RFC 3281.  
    However, there seems to be some interest for doing this in BGP or SBGP.
    Distinguished Names to identify trusted roots.
    Michael: New code is needed, period.  Every single thing requires new code in 
    their CAs.  ASN.1 is not that extensible in the real life, as you know if 
    you have written any code. "There is no infrastructure" is a red 
    herring.  Reality is that someone is going to write code.  Let's write code 
    that the X.509 people have suggested, authorization certs.
    DNs are not useful. Let's use FQDNs, because we should tell them what to do.
    Pekka: No opinion about DN vs FQDN, but regarding certs, strongly agree 
    with Michael that we should go with authorization certificates. Use 
    object hash as an issuer (i.e. PK instead of name).  Simple change, 
    already there in RFC3281 ASN.1 specification, just need to remove 2 lines 
    from the RFC (the statement that using an object hash as an issuer 
    explicitly forbidden).
    Russ Housley: I put those lines there; so far I haven't heard a 
    reasonable justification for removing them.  I agree with attribute 
    certs, but not convinced that constructing hierarchy is the answer. What 
    structure are you trying to create?  What are you trying to find tha 
    attribute certificate to?  PK and things you're binding to PK have 
    different lifetimes.  So, extension to PKC certs is not good; use 
    attribute certificates.
    Pekka: Scheme we would like to support is chain of ISPs, with 
    higher-level and lower level ISPs, or even users running their own 
    routers.  Chain of attribute certificates based on prefix, 
    sub-prefixes can be delegated down the chain.  Name of ISPs doesn't 
    matter to the party doing the verification, just that there's a secure 
    chain of PKs, and that the prefixes properly nest so that the router is 
    authorized to advertise the prefix.
    Russ: We'll have to talk later.
    James: Let's take it to the list and talk about it more. I'll generate 
    proposal for options with Jari.  No one wants to use PKCs.  Anyone 
    support getting rid of attribute certs and going to PKCs? (no).  We'll talk 
    about attribute certificates later.
    IPsec, IPsec w. CGA Header, or ND options?
    Mostly an architectural issue - should we use IPsec, PK crypto at all for 
    this type of thing?
    ND options (10 min) Jari
    - - - - - - - - - - - - -
    (see slides)
    Erik Nordmark: Last benefit on slide - can you actually reverse 
    processing, and source is already in your path.  Packet is not going to 
    change my state, so I will skip checking security part?
    Jari: Don't have details on that, but there are potential DoS dangers. PK 
    operations, without knowing whether IP address on other side exists.  If 
    everything is on one layer, we can make that sort of scheme as you 
    James: This is to use ND options, and generic signalling protocol may come 
    out of this, but it would be handled by another WG.
    CGA header approach for SEND - Pekka
    - - - - - - - - - - - - - - - - - - -
    (see slides)
    Discussion starting
    - - - - - - - - - -
    Michael: I prefer AH philosophically.  Comes down to scope of effort. Is 
    this security neighbor discovery, or public-key motivated AH working 
    group?  Issues with IPsec wg are irrelevant.  Whether 2461 says to use AH is 
    IPsec didn't reject SKIP because it was in-line, but because it wasn't a 
    real key management protocol that scaled beyond an enterprise. Tried to 
    figure out how to use PK inline, but at the time it didn't work. I would 
    like to see it happen. If this WG goes with ND (i'm sitting on the 
    fence), I believe IPsec should retire AH. IPv6 should remove it from their 
    documents. It clearly is a failure.  IESG should understand that AH is 
    I will refrain from offering an opinion on which one I like. 
    Pasi: I have a feeling that there's a difference in 
    functionality. ND option allows nodes that have clocks, no clocks, or bad 
    clocks. IPsec/AH requires synchronized clocks, or nobody checks 
    timestamps.  Other differences are which is easier to implement.  
    Certainly ND options, so I prefer that. 
    Pekka: I disagree about timestamps. Sender is providing timestamp, so 
    sender may say that I don't have a clock. Sender is the one at risk, so it 
    can choose whether to put timestamp. 
    Erik: Comment about generality.  Using MLD for anycast.  CGA-based 
    anycast addresses could allow you to apply same technique.  IP address 
    you're protecting is not source address, but one in payload.  CGA+AH would 
    look at wrong address.  There might be slight differences in 
    Steve Bellovin:  I sent out first message calling AH useless in 1995.  It 
    was largely kept alive for things in IPv6.  I'm not going to tell IPsec wg to 
    get rid of it; there's enough sentiment. 
    (aside from Bob H. - we thought you said we had to use it) 
    Steve Bellovin: lesson learned of 2461 - unless you do hard work of 
    making sure it works, you can't be sure it will apply. 
    Packet signing -- unless you do work of figuring out how to do it, it may 
    not work.  Using generality of AH here might not get you generality 
    anywhere else.  Don't use that as a consideration. 
    Bob Hinden: Idon't have a strong opinion on two approaches.  Sounds like 
    putting it in ND has an easier transition.  You're going to have to have a 
    mixed environment for this to get useage.
    James: Follow up discussion on timestamp? (no)
    Consensus call (see slides):
    Question 1:
    (A) no one raised hand.
    (B) 20 raised hands.
    Question 2:
    (A) no raised hands.
    (B) 34 raised hands.
    Will move forward with draft-arkko-send-ndopt-00.
    Erik: What has been learned by looking at applying IPsec here would be good 
    to get that written down. 
    James: Pekka and Jari have a paper relating to this, perhaps they could 
    submit it to IPsec wg. 
    After IETF, we'll do a last call on the CGA draft, also submit to SAAG.  
    Will continue with ND options, send to review group and IPv6 group.  Not 
    clear if we'll meet at next IETF; depends on whether issues come up.  
    Currently on-track for original goal to finish within a year.


    Issues in the SEND base document
    The ND Option Approach for SEND
    The CGA header approach for SEND
    Implementing draft-send-ipsec and CGA on Linux