[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                      G. Montenegro
Internet-Draft                                           Sun Labs Europe
Expires: September 1, 2003                                   J. Laganier
                                                ENS Lyon/Sun Labs Europe
                                                         C. Castelluccia
                                                       INRIA Rhone-Alpes
                                                           March 3, 2003


                    Securing IPv6 Neighbor Discovery
                    draft-montenegro-send-cga-rr-01

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 1, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   The known security vulnerabilities in Neighbor Discovery have not
   been properly dealt with.  This note suggests some techniques based
   on cryptographically generated addresses and probes that may be
   applied even in the absence of a pre-established security
   relationship between the parties involved.






Montenegro, et al.      Expires September 1, 2003               [Page 1]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


Table of Contents

   1.  Introduction and Problem Statement . . . . . . . . . . . . . .  3
   2.  Node Configuration and Requirements  . . . . . . . . . . . . .  5
   3.  Securing Neighbor Advertisements . . . . . . . . . . . . . . .  6
   4.  Cryptographic Layering Enforcement  (CLE)  . . . . . . . . . .  7
   5.  Securing Router Advertisements . . . . . . . . . . . . . . . .  9
   5.1 Delegation Certificate Chains  . . . . . . . . . . . . . . . .  9
   5.2 Reverse Probing and Traceroute . . . . . . . . . . . . . . . . 10
   5.3 The Objective in Securing Router Advertisements  . . . . . . . 12
   5.4 Securing Redirects . . . . . . . . . . . . . . . . . . . . . . 13
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   8.  Changes from Previous Versions . . . . . . . . . . . . . . . . 17
   9.  Intellectual Property Considerations . . . . . . . . . . . . . 18
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
       Normative References . . . . . . . . . . . . . . . . . . . . . 20
       Informative References . . . . . . . . . . . . . . . . . . . . 21
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23































Montenegro, et al.      Expires September 1, 2003               [Page 2]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


1. Introduction and Problem Statement

   [4] identified several security issues with IPv6 signaling packets
   such as Neighbor discovery [1] and stateless address
   autoconfiguration [6] Other issues are identified within the
   specifications themselves.  The usual recommendation is to use IPsec
   to secure the traffic.

   At the heart of these issues is the difficulty in securing a security
   association such that any node can verify another node's
   authorization when issuing a given IPv6 signaling packet.  Such
   difficulty precludes a straightforward application of IPsec between
   any two previously unknown nodes (either of which may be a router).
   The impossibility of always having the choice of obtaining such a
   security association by leveraging a centralized infrastructure (PKI,
   KDC, TTC, etc) has led to cryptographic techniques commonly known as
   CGA or SUCV to be applied under similar constraints to problems of
   securing Mobile IPv6 [3][10], group management for multicast and
   anycast [12], and others.

   Despite the strong cryptographic assurances afforded by the above,
   Mobile IPv6 has adopted non-cryptographic techniques in its base
   specification [2].  The basis of adopting the Return Routability (RR)
   procedure is the assumption that by means of "liveness probes", trust
   in the routing infrastructure can be leveraged to infer some level of
   trust in binding updates.  Of course, as in the MIPv6 case, relying
   on probes does not offer as much protection as cryptographic
   techniques.

   Accordingly, this note presents a very high level overview of the
   suggested techniques.  Further details  (including packet formats)
   are deferred to other documents.  We assume that the CGA-related
   material is sent by some available means.  This could either be
   packets immediately preceding the protected neighbor discovery
   messages (similar to how sucvP has been proposed to protect Mobile
   IPv6 Binding Updates [3]) or a modified AH header preceding the ND
   itself (as in the SEND protocol).  Instead, the crypto material could
   be sent as neighbor discovery options, as suggested by others.
   However, in the interest of interoperability, the neighbor discovery
   options mechanism mandates that any unrecognized options are simply
   ignored.  This allows, in effect, a very simple "bidding-down" attack
   precluding requiring compliance with a secure version of neighbor
   discovery.

   This note proposes techniques based on CGA and probes to secure
   neighbor discovery in the absence of any pre-existing security .
   relationships.  The initial version of this document aimed at
   generating discussion about the proposed mechanisms.  Most of these,



Montenegro, et al.      Expires September 1, 2003               [Page 3]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


   or some variant of them, are currently part of the official SEND
   Protocol specification [11].  This document's only remaining sections
   not included there are those on CLE and Reverse Probing and
   Traceroute.  We currently include all the sections to give better
   background and context.  Nevertheless, a future version of this
   document may remove the redundant sections and instead reference the
   SEND protocol specification more fully.












































Montenegro, et al.      Expires September 1, 2003               [Page 4]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


2. Node Configuration and Requirements

   Each node that wants its messages to be verifiable (and heeded) by
   other nodes generates a public-private key pair, PK and SK,
   respectively.  The nodes then use PK to obtain an IPv6
   Cryptographically Generated Address (CGA):

   CGA = NetworkPrefix | SHA1_64( PK | Imprint )

   Where Imprint is a fixed 64 bit quantity used to restrict the
   validity scope of the CGA on which both parties have agreed.  This is
   usually the IPv6 Network Prefix as found in [10].

   Notice that this does not mandate that all nodes generate and use
   SUCV addresses.  This is only required for those nodes that wish to
   sign their packets.



































Montenegro, et al.      Expires September 1, 2003               [Page 5]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


3. Securing Neighbor Advertisements

   A Neighbor Solicitation message triggers the response of a Neighbor
   Advertisement message.  A direct application of CGA or SUCV would
   have the node sign the Neighbor Advertisement packet with its private
   key SK.  Along with the packet, the node includes PK and its
   signature in a format TBD.

   At a receiving node, verification of this packet's signature produces
   two assurances:

   1.  Integrity of the packet contents.

   2.  Data origin of the packet.

   A node's Neighbor Advertisement messages need not change.  If so, the
   node can prepare the signed message in advance and simply send it out
   when solicited.  Nevertheless, the signed Neighbor Advertisement
   message is significantly larger than the incoming Neighbor Discovery
   message (it must carry the signature as well as the public key of the
   source).  Particularly when operating over wireless links, it is
   desirable to limit transmission time as much as possible due to its
   cost in terms of power (battery life) and money.

   Because of this, it may also be desirable to delay sending the
   Neighbor Advertisement (beyond the rate-limiting already mandated by
   neighbor discovery) in order to protect against DoS attacks.
   Accordingly, a procedure similar to sucvP [3] could be used by the
   responding node's assuming that the initial Neighbor Discovery is
   equivalent to sucvP1.  Accordingly, instead of responding with a
   signed Neighbor Advertisement packet, the responder may choose to
   issue an sucvP2 packet containing a cookie puzzle for the initiator.
   Receiving a valid solution in sucvP3 would finally cause the
   responder to issue a signed Neighbor Advertisement message to the
   initiator.

   Nevertheless, such a procedure may be justified only if the objective
   is to use sucvP in order to obtain a security association with the
   peer.  This would allow subsequent Neighbor Unreachability Detection
   to be secured via HMAC as used with ESP, for example.

   Neighbor Solicitation messages also have the cabapility to change
   neighbor cache entries.  Accordingly, the mechanism outlined above
   may also be applied to secure these messages as well in order to
   avoid caching non-authentic information.






Montenegro, et al.      Expires September 1, 2003               [Page 6]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


4. Cryptographic Layering Enforcement  (CLE)

   Threats to Neighbor Discovery are particularly serious for multi-
   access link-layers which use addresses to deliver frames or packets
   [4].  The local delivery depends on correctly mapping the link-layer
   (also known as MAC) addresses with the corresponding IP addresses.
   When these identifiers are sufficiently long (more than 48 bits),
   these bits may be used to improve the level of security provided by
   CGA from 62 (of the 64 bits in the interface identifier portion of
   the address) bits to approximately 100, and most commonly 110 bits.
   This is secure enough for any application for a long time.  These
   link-layer addresses are usually outside the purview of the IETF.
   The observation is that this lack of coordination between the IP
   layer and the underlying link-layer is precisely the weakness that
   makes them so easy to attack.

   The CLE proposal aims at establishing a cryptographic coordination
   between these two layers, thus closing this gaping hole in ND
   security.  This is a straighforward way to extend the security
   afforded by CGA beyond the current 62 bits.  The advantage of this
   mechanism, as opposed to that suggested in [11] is its simplicity,
   but above all, the fact that the additional security does not incur
   additional work load when generating the addresses.  This point is
   essential for resource constrained devices, which will become
   arguably the majority of the node population.

   CLE defines the link-layer address (LLaddr) as a CGA using the same
   public key as that used to generate the CGA IP address (IPaddr).
   However, these two addresses use different bit ranges from the
   resultant hash.  For example:

      (1) LLaddr = h_bottom( PK | Imprint )

      (2) IPaddr = h_top( PK | Imprint )

   By doing so, a node is able to prove that:

      (3) It owns its IPaddr (protected by h_bottom bits)

      (4) It owns its LLaddr (protected by h_top bits)

   But what is most important, is the fact that the node can prove that
   it is authorized to establish the mapping:

      (5) IPaddr is at LLaddr (protected by h_top + h_bottom bits)

   Thus, an attacker will have a much harder time finding a collision on
   the mapping.  Of course, the attackers task of defeating either the



Montenegro, et al.      Expires September 1, 2003               [Page 7]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


   link-layer or the IP level CGA when trying a candidate public key
   PK_i is:

      (6) P( LLaddr ) = probability that he'll find a collision with
      PK_i such that LLaddr = h_bottom( PK_i )

      (7) P( IPaddr ) = probability that he'll find a collision with
      PK_i such that IPaddr = h_top( PK_i )

   Given that the hash function acts as an unbiased random-bit generator
   [13], (6) and (7) are independent events.

   Since they are independent events, the probability of finding a valid
   mapping (5) is then:

      (8) P( IPaddr & LLaddr ) = P( IPaddr ) * P( LLaddr )

   So the attacker's task is much much harder than to defeat the
   individual CGA addresses.

   Furthermore, one could similarly protect other mappings between
   addresses (for example, that of the home address and the care-of
   address in Mobile IP).  If one uses different bit ranges from the
   hash output for the different CGA addresses, one can arrive at a
   relationship between addresses which is very hard to forge.  True, at
   any given point in time, not all observers would be able to judge and
   verify more than one such mapping (where each mapping specifies the
   link between two addresses), but having all the address mappings obey
   such strict cryptographic binding increases the chance that at least
   one observer can detect attempted forgeries.





















Montenegro, et al.      Expires September 1, 2003               [Page 8]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


5. Securing Router Advertisements

   Securing Router Advertisements is not as straightforward because what
   is at hand is a router's authorization to "speak for" a given global
   routing prefix [7], and CGA does not enable routing prefix
   generation.

   [5] proposes that ISP's generate private keys such that the 64 bit
   prefix is the public key used by routers to sign their
   advertisements.  However, it is not clear why malicious nodes cannot
   themselves generate these private keys using the same techniques as
   the ISP's.  Accordingly, it seems like in the absence of any security
   relationship, trust in the routing hierarchy can be leveraged to
   infer trust in any particular router.  This is similar to the
   justification behind return routability adopted by MIPv6 [2].

   In the interest of generating discussion, we present two different
   proposals on how to carry this out.

5.1 Delegation Certificate Chains

   Here, we use concepts similar to those in [12].

   Each router is also a CGA node.  That is, each router has a public-
   private key pair and uses CGA addresses as above.

   The idea then is that each router R signs its router advertisements
   using its private key.  Additionally, each router must obtain a
   delegation certificate such as is used in [12] signed by a router
   higher up in the routing hierarchy (I).  This certificate includes:

      the public key of I

      anything necessary to generate the SUCV address of I (perhaps an
      anycast address itself)

      delegation allowing R the right to handle the given 64 bit prefix

      signed by I with its private key

   Notice that R may include several such independently issued
   certificates from I1, I2, ...  Ij along with its Router
   Advertisements.  Presumably, the collection of signers I1..Ij would
   include the routing authorities directly above R in the hierarchy,
   but it should not be limited to these as it may prove beneficial to
   have other authorities vouch for R as well.

   The delegation certificate chain must be anchored at a public



Montenegro, et al.      Expires September 1, 2003               [Page 9]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


   topology point [8].  Each TLA must issue delegation certificates for
   its NLA's.  In order to verify routing advertisements from router R,
   a node M verifies the chain up to the TLA.  The first element in the
   chain is the delegation certificate whereby IANA gives control of a
   given TLA ID (i.e.  /16 prefix) to the entity which owns a certain
   public key.  Let's call this the TLA authorization certificate, and
   it must also include a secure binding between the TLA ID and the
   public key of the entity owning that TLA ID:

   TLA Authorization Certificate:

   o  signed by IANA

   o  beneficiary: an entity with public key P

   o  authorization to manage a given TLA ID

   Now, verification of the entire chain requires secure establishment
   of IANA's public key.  This step is possible by IANA's using a third
   party certificate (via a PKI provider) or via a grass-roots web of
   trust certificate like PGP.  Furthermore, IANA's public key can be
   downloaded and verified in advance.  It need not (should not) be done
   in real-time, so chain verification can take place locally upon
   receiving a signed router advertisement.

   This method implies quite an overhead in terms of operations and
   management.  Also, each level in the hierarchy must also use SUCV
   addresses in order for this chain to be verifiable in the absence of
   a PKI.  The overhead implied by the certificate chains may be reduced
   by certificate reduction as explained in [12].

   Another possible optimization is for the visiting node to do some
   preprocessing by downloading and verifying all the TLA authorization
   certificates.  This is certainly possible, given the maximum limit of
   8,192 TLA authorization certificates with the current scheme [8].
   Doing this would enable the visiting node to save a list of TLA ID's
   along with the corresponding public key of the managing entities.
   This would save one verification step, that of the first element in
   all chains.  Such preprocessing would eliminate the need to send the
   first element in the chain, saving on bandwidth as well as CPU.

   Nevertheless, the main obstacle is probably convincing IANA to issue
   the TLA authorization certificates as described above.

5.2 Reverse Probing and Traceroute

   As compared to the previous method, this second method is much more
   lightweight operationally.  However, it presupposes the existence of



Montenegro, et al.      Expires September 1, 2003              [Page 10]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


   a "friendly" node, F, that will aid  a node M in determining the
   suitability of the different routers it discovers.

   This assumes that M has trust in some part of the Internet, which it
   then uses to derive some diminished level of trust in its vicinity
   (just enough to decide which first hop router to use).

   Suppose the following scenario in which M hears router advertisements
   from multiple routers.  Without loss of generality, assume there are
   two such routers, R1 and R2, each advertising prefixes P1 and P2,
   respectively.


          M
         / \
        /   \
       R1   R2
       |     |
    /-----------\
    |           |
    | Internet  |
    |           |
    \-----------/
          |
          |
          F


   M has a "friend", F, in some other location with which it has mutual
   trust, and which is willing to carry out certain operations on its
   behalf.  We assume M and F have a secure channel, perhaps via IPsec
   ESP.  The security association between them may be a pre-shared
   secret, or established dynamically via IKE or sucvP (F could be M's
   VPN gateway, for example).

   M follows this algorithm:

      If P1 != P2 it auto configures two addresses M1 and M2.

      M sends simple probes to F via R1 and R2, using source addresses
      M1 and M2, respectively.

      If one performs much better (less dropped packets) than the other,
      prefer that router.

      If both perform approximately the same, request F to carry out a
      reverse probe (perhaps augmented with reverse traceroute [9])
      towards M.



Montenegro, et al.      Expires September 1, 2003              [Page 11]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


      F reports results to M, and M chooses the "best" router.

   The above assumes that a node can always reach a friendly system F
   regardless of where it connects in the Internet.  If this is not the
   case, then presumably, M is not able to reach any trusted node, in
   which case there is no trust to leverage from, so none of this
   applies.

   In the absence of any security relationship with the existing
   infrastructure, involving the routing infrastructure in either of the
   manners specified above seems to be a scalable method for an
   arbitrary node to gain some level of trust in the surrounding routing
   fabric.

5.3 The Objective in Securing Router Advertisements

   Depending on which parties are interested in gaining trust in the
   infrastructure, either of the above proposals may be a better fit.

   For example, if the objective is for the routing fabric to verify
   itself, then the first scheme using the delegation certificates would
   allow basically any router within an administrative domain to verify
   another router's authorization to route certain prefixes.  Being
   within an administrative domain allows the routers to
   cryptographically derive strong trust in the surrounding
   infrastructure.

   This would apply as well to any node that belongs to that
   administrative domain.  Of course, being within a given
   administrative domain would allow the use of conventional
   certificates in which case CGA would not be necessary.  The benefit
   of using CGA addresses is that they imply the binding from a public
   key to the corresponding address without recourse to a separate
   certificate.

   This seemingly small point has a large simplifying effect.  Because
   of this, even within a given administrative domain, the distributed
   nature of CGA's helps in avoiding issues due to centralization
   (bottlenecks, single points of failure, etc).

   On the other hand, the objective may be to allow an arbitrary
   visiting node to gain some level of confidence in the infrastructure
   of a domain it is visiting.  How much confidence? Just enough to be
   able to choose a first-hop router.

   However, this may not be a realistic expectation in the general case.
   In particular, it may be able to verify the SUCV chain of delegation
   and find its way to the TLA level (which it must verify independently



Montenegro, et al.      Expires September 1, 2003              [Page 12]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


   of SUCV) this implies no judgement on the scruples or practices of
   the NLA.

   It is interesting to compare this scenario to a node M which dials up
   via a well-known public ISP.  In this case, there is much greater
   trust in the fact that the first hop router is indeed authorized to
   perform that function.  There is less doubt as PPP will only reveal
   one such device on the other end, and because this process relies on
   telephony routing which, presumably, is much harder to subvert than
   internet routing.

   Nevertheless, both situations are approximately the same in terms of
   the precautions that M must take.  Namely, in both cases there is
   little or no trust in the intervening Internet fabric.  Accordingly,
   in both cases M must secure its communications in an end-to-end
   fashion by using IKE with IPsec, sucvP with IPsec, TLS, SSH or
   similar protocols.  Even if there is complete trust in the first hop
   router's authorization to route a certain prefix, this has little or
   no bearing on the overall trust in the end-to-end path.  Therefore,
   choosing amongst multiple router advertisements becomes a question of
   reliability.  The objective of the above procedure is simply:

      Find the most reliable first hop router upon which to establish a
      secure end-to-end session.

   Because of this, the procedure to choose should be predominantly
   based on performance of the possibly multiple paths, as exemplified
   by the procedure outlined previously.

5.4 Securing Redirects

   [1] specifies the usage of AH during ND operations, but does not say
   how to set up the associated SAs.  Furthermore, a host may be
   configured to ignore non AH-protected ICMP Redirect headers, to avoid
   trivial spoofing attacks.

   To avoid the loss of ICMP Redirect facility, we can secure the
   message in the same way as ND:

   o  The router could include its signature along with the Redirect
      header along the lines outlined above for Neighbor Advertisement
      and solicitation.

   Alternatively, the router could engage in sucvP as in [3] in order to
   provide some protection against DoS attacks.  In such a case:

   o  The router responds to the initial packet with the equivalent of
      an sucvP2.



Montenegro, et al.      Expires September 1, 2003              [Page 13]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


   o  To avoid DoS attacks, the router must not retain the redirected
      destination address between the sending of p2 and the reception of
      p3.  So we must include in p3 the initial destination address to
      allow the router to issue a p4 carrying an appropriate Redirect
      message.

   Note that we can obtain approximately the same level of trust by
   asking the new preferred router (the target) to advertise the
   neighbor prefix which matches the redirected address, and protecting
   the NS-NA exchange with sucvP as shown in the previous section.

   But it is also interesting to consider this as a mean of spinning a
   web of trust from a router which support sucvP to others routers who
   don't.  In other words to gain trust from routing infrastructure.
   However, we don't consider the matter of establishing trust between a
   router issuing redirect messages targeted to a non-sucvP router.
   This is out of scope.


































Montenegro, et al.      Expires September 1, 2003              [Page 14]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


6. Conclusion

   This note presents a high level overview of how CGA and probing
   techniques can be used to secure Neighbor Discovery.  The techniques
   are sufficiently well understood and can use widely deployed and
   implemented mechanisms.  This proposal works in the absence of any
   previously established direct or indirect (via a broker, AAA roaming
   operator or trusted third party) security relationship.  Because of
   this, these methods are very practical and deployable.










































Montenegro, et al.      Expires September 1, 2003              [Page 15]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


7. Security Considerations

   This document discusses security issues specifically with respect to
   neighbor discovery, and outlines some high level mechanisms to
   address them.  Some of the mechanisms discussed impose a heavy load
   on processing nodes due to the use of public key cryptography.  When
   packets are not variable, these operations may be amortized at the
   source by doing them once and reusing the resultant signed packets as
   frequently as deemed appropriate.

   However, this allows any node to replay the packets, misleading
   Neighbor Unreachability Detection to incorrectly assume liveness for
   the original signer of the packets.  Accordingly, a replay protection
   mechanism is in order.  It may be possible to protect against replay
   without incurring heavy processing costs by judicious use of hash
   chain techniques.  This is under study.

   Many neighbor discovery operations include link-layer information.
   In order to reap full benefit of CGA techniques, it is worthwhile
   considering the option of using cryptographically generated address
   at the link layer as well.  Doing so would enable a node to not only
   prove it has legitimate claim to using a given IPv6 address, but also
   the underlying link-layer address.  This is under study.




























Montenegro, et al.      Expires September 1, 2003              [Page 16]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


8. Changes from Previous Versions

   This section details the non-editorial changes made in between the
   different versions of this document.

   From rev 00 to 01:

      The publication of [11] is reflected throughout, for example by
      allowing it as a possible means to obtain the CGA crypto material,
      and by acknowledging that most of the topics in this draft are now
      addressed in that SEND protocol document.

      Addition of the section on CLE (cryptographic layering
      enforcement).





































Montenegro, et al.      Expires September 1, 2003              [Page 17]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


9. Intellectual Property Considerations

   The IETF takes no position regarding the validity or scope of
   intellectual property or other rights that might be claimed pertain
   to the implementation or use of the technology described in this
   document or the extent to which any license under such rights might
   or might not be available; neither does it represent that it has made
   any effort to identify any such rights.  Information on the IETF's
   procedures with respect to rights in standards-track and standards-
   related documentation can be found in BCP-11.  Copies of claims of
   rights made available for publication and any assurances of licenses
   to be made available, or the result of an attempt made to obtain a
   general license or permission for the use of such proprietary rights
   by implementors or users of this specification can be obtained from
   the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

























Montenegro, et al.      Expires September 1, 2003              [Page 18]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


10. Acknowledgements

   Thanks to Jari Arkko, Jim Kempf and Erik Nordmark for their comments
   and discussion.















































Montenegro, et al.      Expires September 1, 2003              [Page 19]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


Normative References

   [1]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
        IP Version 6 (IPv6)", RFC 2461, December 1998.















































Montenegro, et al.      Expires September 1, 2003              [Page 20]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


Informative References

   [2]   Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
         IPv6", Internet-Draft http://www.ietf.org/internet-drafts/
         draft-ietf-mobileip-ipv6-21, February 2003.

   [3]   Montenegro, G. and C. Castelluccia, "Statistically Unique and
         Cryptographically Verifiable  (SUCV) Identifiers and
         Addresses.", NDSS 2002, February 2002.

   [4]   Kempf, J. and E. Nordmark, "Threat Analysis for IPv6 Public
         Multi-Access Links", draft-kempf-ipng-netaccess-threats-01
         (work in progress), June 2002.

   [5]   Kempf, J., Gentry, C. and A. Silverberg, "Securing IPv6
         Neighbor Discovery Using Address Based Keys (ABKs)", draft-
         kempf-secure-nd-00.txt (work in progress), February 2002.

   [6]   Thomson, S. and T. Narten, "IPv6 Stateless Address
         Autoconfiguration", RFC 2462, December 1998.

   [7]   Hinden, R. and S. Deering, "IP Version 6 Addressing
         Architecture (under revision as "draft-ietf-ipngwg-addr-arch-
         v3-07.txt)"", RFC 2373, July 1998.

   [8]   Hinden, R. and S. Deering, "An IPv6 Aggregatable Global Unicast
         Address Format", RFC 2374, July 1998.

   [9]   "Reverse Tracing and Traceroute", Web Resources http://
         www.slac.stanford.edu/comp/net/wan-mon/traceroute-srv.html,
         http://sourceforge.net/projects/rtraceroute/, //www.caida.org/
         analysis/routing/reversetrace/.

   [10]  Roe, M., Aura, T., O'Shea, G. and J. Arkko, "Authentication of
         Mobile IPv6 Binding Updates and Acknowledgments", draft-roe-
         mobileip-updateauth (work in progress), February 2002.

   [11]  Arkko, J., Kempf, J., Sommerfeld, B. and B. Zill, "SEcure
         Neighbor Discovery (SEND)", draft-ietf-send-ipsec (work in
         progress), February 2003.

   [12]  Castelluccia, C. and G. Montenegro, "Securing Group Management
         in IPv6 with  Cryptographically Generated  Addresses", INRIA
         Research Report RR-4523, August 2002.

   [13]  Schneier, B., "Applied Cryptography, Second Edition", Wiley ,
         1996.




Montenegro, et al.      Expires September 1, 2003              [Page 21]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


Authors' Addresses

   Gabriel Montenegro
   Sun Labs Europe
   29, chemin du Vieux Chene
   38240 Meylan
   France

   EMail: gab@sun.com


   Julien Laganier
   ENS Lyon/Sun Labs Europe
   46 Allee d'Italie
   69007 Lyon
   France

   EMail: julien.laganier@sun.com


   Claude Castelluccia
   INRIA Rhone-Alpes
   65 avenue de l'Europe
   38330 Montbonnot Saint-Martin
   France

   EMail: claude.castelluccia@inria.fr
























Montenegro, et al.      Expires September 1, 2003              [Page 22]


Internet-Draft      Securing IPv6 Neighbor Discovery          March 2003


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Montenegro, et al.      Expires September 1, 2003              [Page 23]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/