<pre>Network Working Group                                   P. Nikander, Ed.
Request for Comments: 3756                 Ericsson Research Nomadic Lab
Category: Informational                                         J. Kempf
                                                         DoCoMo USA Labs
                                                             E. Nordmark
                                           Sun Microsystems Laboratories
                                                                May 2004


         <span class="h1">IPv6 Neighbor Discovery (ND) Trust Models and Threats</span>

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   The existing IETF standards specify that IPv6 Neighbor Discovery (ND)
   and Address Autoconfiguration mechanisms may be protected with IPsec
   Authentication Header (AH).  However, the current specifications
   limit the security solutions to manual keying due to practical
   problems faced with automatic key management.  This document
   specifies three different trust models and discusses the threats
   pertinent to IPv6 Neighbor Discovery.  The purpose of this discussion
   is to define the requirements for Securing IPv6 Neighbor Discovery.

Table of Contents

   <a href="#section-1">1</a>.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-2">2</a>
       <a href="#section-1.1">1.1</a>. Remarks . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-3">3</a>
   <a href="#section-2">2</a>.  Previous Work. . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-4">4</a>
   <a href="#section-3">3</a>.  Trust Models . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-4">4</a>
       <a href="#section-3.1">3.1</a>. Corporate Intranet Model. . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
       <a href="#section-3.2">3.2</a>. Public Wireless Network with an Operator. . . . . . . . .  <a href="#page-6">6</a>
       <a href="#section-3.3">3.3</a>. Ad Hoc Network. . . . . . . . . . . . . . . . . . . . . .  <a href="#page-7">7</a>
   <a href="#section-4">4</a>.  Threats on a (Public) Multi-Access Link. . . . . . . . . . . .  <a href="#page-8">8</a>
       <a href="#section-4.1">4.1</a>. Non router/routing related threats. . . . . . . . . . . .  <a href="#page-9">9</a>
            <a href="#section-4.1.1">4.1.1</a>. Neighbor Solicitation/Advertisement Spoofing . . .  <a href="#page-9">9</a>
            <a href="#section-4.1.2">4.1.2</a>. Neighbor Unreachability Detection (NUD) failure. . <a href="#page-10">10</a>
            <a href="#section-4.1.3">4.1.3</a>. Duplicate Address Detection DoS Attack . . . . . . <a href="#page-11">11</a>
       <a href="#section-4.2">4.2</a>. Router/routing involving threats. . . . . . . . . . . . . <a href="#page-12">12</a>
            <a href="#section-4.2.1">4.2.1</a>. Malicious Last Hop Router. . . . . . . . . . . . . <a href="#page-12">12</a>



<span class="grey">Nikander, et al.             Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


            <a href="#section-4.2.2">4.2.2</a>. Default router is 'killed' . . . . . . . . . . . . <a href="#page-13">13</a>
            <a href="#section-4.2.3">4.2.3</a>. Good Router Goes Bad . . . . . . . . . . . . . . . <a href="#page-14">14</a>
            <a href="#section-4.2.4">4.2.4</a>. Spoofed Redirect Message . . . . . . . . . . . . . <a href="#page-14">14</a>
            <a href="#section-4.2.5">4.2.5</a>. Bogus On-Link Prefix . . . . . . . . . . . . . . . <a href="#page-14">14</a>
            <a href="#section-4.2.6">4.2.6</a>. Bogus Address Configuration Prefix . . . . . . . . <a href="#page-15">15</a>
            <a href="#section-4.2.7">4.2.7</a>. Parameter Spoofing . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
       <a href="#section-4.3">4.3</a>. Replay attacks and remotely exploitable attacks . . . . . <a href="#page-17">17</a>
            <a href="#section-4.3.1">4.3.1</a>. Replay attacks . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
            <a href="#section-4.3.2">4.3.2</a>. Neighbor Discovery DoS Attack. . . . . . . . . . . <a href="#page-18">18</a>
       <a href="#section-4.4">4.4</a>. Summary of the attacks. . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
   <a href="#section-5">5</a>.  Security Considerations. . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
   <a href="#section-6">6</a>.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
   <a href="#section-7">7</a>.  Informative References . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   The IPv6 Neighbor Discovery (ND) <a href="./rfc2461">RFC 2461</a> [<a href="#ref-2" title="&quot;Neighbor Discovery for IP Version 6 (IPv6)&quot;">2</a>] and Address
   Autoconfiguration <a href="./rfc2462">RFC 2462</a> [<a href="#ref-3" title="&quot;IPv6 Stateless Address Autoconfiguration&quot;">3</a>] mechanisms are used by nodes in an
   IPv6 network to learn the local topology, including the IP to MAC
   address mappings for the local nodes, the IP and MAC addresses of the
   routers present in the local network, and the routing prefixes served
   by the local routers.  The current specifications suggest that IPsec
   AH <a href="./rfc2402">RFC 2402</a> [<a href="#ref-1" title="&quot;IP Authentication Header&quot;">1</a>] may be used to secure the mechanisms, but does not
   specify how.  It appears that using current AH mechanisms is
   problematic due to key management problems [<a href="#ref-8" title="&quot;Effects of ICMPv6 on IKE&quot;">8</a>].

   To solve the problem, the Secure Neighbor Discovery (SEND) working
   group was chartered in Fall 2002.  The goal of the working group is
   to define protocol support for securing IPv6 Neighbor Discovery
   without requiring excessive manual keying.

   The purpose of this document is to define the types of networks in
   which the Secure IPv6 Neighbor Discovery mechanisms are expected to
   work, and the threats that the security protocol(s) must address.  To
   fulfill this purpose, this document first defines three different
   trust models, roughly corresponding to secured corporate intranets,
   public wireless access networks, and pure ad hoc networks.  After
   that, a number of threats are discussed in the light of these trust
   models.  The threat catalog is aimed to be exhaustive, but it is
   likely that some threats are still missing.  Thus, ideas for new
   threats to consider are solicited.








<span class="grey">Nikander, et al.             Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Remarks</span>

   Note that the SEND WG charter limits the scope of the working group
   to secure Neighbor Discovery functions.  Furthermore, the charter
   explicitly mentions zero configuration as a fundamental goal behind
   Neighbor Discovery.  Network access authentication and access control
   are outside the scope of this work.

   During the discussions while preparing this document, the following
   aspects that may help to evaluate the eventual solutions were
   mentioned.

      Zero configuration

      Interaction with access control solutions

      Scalability

      Efficiency

   However, the main evaluation criteria are formed by the trust models
   and threat lists.  In other words, the solutions are primarily
   evaluated by seeing how well they secure the networks against the
   identified threats, and only secondarily from the configuration,
   access control, scalability, and efficiently point of view.

   IMPORTANT.  This document occasionally discusses solution proposals,
   such as Cryptographically Generated Addresses (CGA) [<a href="#ref-7" title="&quot;Authentication of Mobile IPv6 Binding Updates and Acknowledgments&quot;">7</a>] and Address
   Based Keys (ABK) [<a href="#ref-6" title="&quot;Securing IPv6 Neighbor Discovery Using Address Based Keys (ABKs)&quot;">6</a>].  However, such discussion is solely for
   illustrative purposes.  Its purpose is to give the readers a more
   concrete idea of *some* possible solutions.  Such discussion does NOT
   indicate any preference on solutions on the behalf of the authors or
   the working group.

   It should be noted that the term "trust" is used in this document in
   a rather non-technical manner.  The most appropriate interpretation
   is to consider it as an expression of an organizational or collective
   belief, i.e., an expression of commonly shared beliefs about the
   future behavior of the other involved parties.  Conversely, the term
   "trust relationship" denotes a mutual a priori relationship between
   the involved organizations or parties where the parties believe that
   the other parties will behave correctly even in the future.  A trust
   relationship makes it possible to configure authentication and
   authorization information between the parties, while the lack of such
   a relationship makes it impossible to pre-configure such information.






<span class="grey">Nikander, et al.             Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Previous Work</span>

   The RFCs that specify the IPv6 Neighbor Discovery and Address
   Autoconfiguration protocols [<a href="#ref-2" title="&quot;Neighbor Discovery for IP Version 6 (IPv6)&quot;">2</a>] [<a href="#ref-3" title="&quot;IPv6 Stateless Address Autoconfiguration&quot;">3</a>] contain the required discussion
   of security in a Security Considerations section.  Some of the
   threats identified in this document were raised in the original RFCs.
   The recommended remedy was to secure the involved packets with an
   IPsec AH [<a href="#ref-1" title="&quot;IP Authentication Header&quot;">1</a>] header.  However, that recommendation oversimplifies the
   problem by leaving the AH key management for future work.  For
   example, a host attempting to gain access to a Public Access network
   may or may not have the required IPsec security associations set up
   with the network.  In a roaming (but not necessarily mobile)
   situation, where a user is currently accessing the network through a
   service provider different from the home provider, it is not likely
   that the host will have been preconfigured with the proper mutual
   trust relationship for the foreign provider's network, allowing it to
   directly authenticate the network and get itself authenticated.

   As of today, any IPsec security association between the host and the
   last hop routers or other hosts on the link would need to be
   completely manually preconfigured, since the Neighbor Discovery and
   Address Autoconfiguration protocols deal to some extent with how a
   host obtains initial access to a link.  Thus, if a security
   association is required for initial access and the host does not have
   that association, there is currently no standard way that the host
   can dynamically configure itself with that association, even if it
   has the necessary minimum prerequisite keying material.  This
   situation could induce administration hardships when events such as
   re-keying occur.

   In addition, Neighbor Discovery and Address Autoconfiguration use a
   few fixed multicast addresses plus a range of 16 million "solicited
   node" multicast addresses.  A naive application of pre-configured SAs
   would require pre-configuring an unmanageable number of SAs on each
   host and router just in case a given solicited node multicast address
   is used.  Preconfigured SAs are impractical for securing such a large
   potential address range.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Trust Models</span>

   When considering various security solutions for the IPv6 Neighbor
   Discovery (ND) [<a href="#ref-2" title="&quot;Neighbor Discovery for IP Version 6 (IPv6)&quot;">2</a>], it is important to keep in mind the underlying
   trust models.  The trust models defined in this section are used
   later in this document, when discussing specific threats.







<span class="grey">Nikander, et al.             Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


   In the following, the <a href="./rfc2461">RFC 2461</a>/RFC 2462 mechanisms are loosely
   divided into two categories: Neighbor Discovery (ND) and Router
   Discovery (RD).  The former denotes operations that do not primarily
   involve routers while the operations in the latter category do.

   Three different trust models are specified:

   1.  A model where all authenticated nodes trust each other to behave
       correctly at the IP layer and not to send any ND or RD messages
       that contain false information.  This model is thought to
       represent a situation where the nodes are under a single
       administration and form a closed or semi-closed group.  A
       corporate intranet is a good example.

   2.  A model where there is a router trusted by the other nodes in the
       network to be a legitimate router that faithfully routes packets
       between the local network and any connected external networks.
       Furthermore, the router is trusted to behave correctly at the IP
       layer and not to send any ND or RD messages that contain false
       information.

       This model is thought to represent a public network run by an
       operator.  The clients pay to the operator, have its credentials,
       and trust it to provide the IP forwarding service.  The clients
       do not trust each other to behave correctly; any other client
       node must be considered able to send falsified ND and RD
       messages.

   3.  A model where the nodes do not directly trust each other at the
       IP layer.  This model is considered suitable for e.g., ad hoc
       networks.

   Note that even though the nodes are assumed to trust each other in
   the first trust model (corporate intranet), it is still desirable to
   limit the extent of damage a node is able to inflict to the local
   network if it becomes compromised.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Corporate Intranet Model</span>

   In a corporate intranet or other network where all nodes are under
   one administrative domain, the nodes may be considered to be reliable
   at the IP layer.  Thus, once a node has been accepted to be a member
   of the network, it is assumed to behave in a trustworthy manner.

   Under this model, if the network is physically secured or if the link
   layer is cryptographically secured to the extent needed, no other
   protection is needed for IPv6 ND, as long as none of the nodes become
   compromised.  For example, a wired LAN with 802.1x access control or



<span class="grey">Nikander, et al.             Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


   a WLAN with 802.11i Robust Security Network (RSN) with AES encryption
   may be considered secure enough, requiring no further protection
   under this trust model.  On the other hand, ND security would add
   protection depth even under this model (see below).  Furthermore, one
   should not overestimate the level of security any L2 mechanism is
   able to provide.

   If the network is not physically secured and the link layer does not
   have cryptographic protection, or if the cryptographic protection is
   not secure enough (e.g., just 802.1x and not 802.11i in a WLAN), the
   nodes in the network may be vulnerable to some or all of the threats
   outlined in <a href="#section-4">Section 4</a>.  In such a case some protection is desirable
   to secure ND.  Providing such protection falls within the main
   initial focus of the SEND working group.

   Furthermore, it is desirable to limit the amount of potential damage
   in the case a node becomes compromised.  For example, it might still
   be acceptable that a compromised node is able to launch a denial-of-
   service attack, but it is undesirable if it is able to hijack
   existing connections or establish man-in-the-middle attacks on new
   connections.

   As mentioned in <a href="#section-2">Section 2</a>, one possibility to secure ND would be to
   use IPsec AH with symmetric shared keys, known by all trusted nodes
   and by no outsiders.  However, none of the currently standardized
   automatic key distribution mechanisms work right out-of-the-box.  For
   further details, see [<a href="#ref-8" title="&quot;Effects of ICMPv6 on IKE&quot;">8</a>].  Furthermore, using a shared key would not
   protect against a compromised node.

   More specifically, the currently used key agreement protocol, IKE,
   suffers from a chicken-and-egg problem [<a href="#ref-8" title="&quot;Effects of ICMPv6 on IKE&quot;">8</a>]: one needs an IP address
   to run IKE, IKE is needed to establish IPsec SAs, and IPsec SAs are
   required to configure an IP address.  Furthermore, there does not
   seem to be any easy and efficient ways of securing ND with symmetric
   key cryptography.  The required number of security associations would
   be very large [<a href="#ref-9" title="&quot;Manual Configuration of Security Associations for IPv6 Neighbor Discovery&quot;">9</a>].

   As an example, one possible approach to overcome this limitation is
   to use public key cryptography, and to secure ND packets directly
   with public key signatures.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Public Wireless Network with an Operator</span>

   A scenario where an operator runs a public wireless (or wireline)
   network, e.g., a WLAN in a hotel, airport, or cafe, has a different
   trust model.  Here the nodes may be assumed to trust the operator to
   provide the IP forwarding service in a trustworthy manner, and not to
   disrupt or misdirect the clients' traffic.  However, the clients do



<span class="grey">Nikander, et al.             Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


   not usually trust each other.  Typically the router (or routers) fall
   under one administrative domain, and the client nodes each fall under
   their own administrative domain.

   It is assumed that under this scenario the operator authenticates all
   the client nodes, or at least requires authorization in the form of a
   payment.  At the same time, the clients must be able to authenticate
   the router and make sure that it belongs to the trusted operator.
   Depending on the link-layer authentication protocol and its
   deployment, the link layer may take care of the mutual
   authentication.  The link-layer authentication protocol may allow the
   client nodes and the access router to create a security association.
   Note that there exist authentication protocols, e.g., particular EAP
   methods, that do not create secure keying material and/or do not
   allow the client to authenticate the network.

   In this scenario, cryptographically securing the link layer does not
   necessarily block all the threats outlined in <a href="#section-4">Section 4</a>; see the
   individual threat descriptions.  Specifically, even in 802.11i RSN
   with AES encryption the broadcast and multicast keys are shared
   between all nodes.  Even if the underlying link layer was aware of
   all the nodes' link-layer addresses, and were able to check that no
   source addresses were falsified, there would still be
   vulnerabilities.

   One should also note that link-layer security and IP topology do not
   necessarily match.  For example, the wireless access point may not be
   visible at the IP layer at all.  In such a case cryptographic
   security at the link layer does not provide any security with regard
   to IP Neighbor Discovery.

   There seems to be at least two ways to bring in security into this
   scenario.  One possibility seems to be to enforce strong security
   between the clients and the access router, and make the access router
   aware of the IP and link-layer protocol details.  That is, the router
   would check ICMPv6 packet contents, and filter packets that contain
   information which does not match the network topology.  The other
   possibly acceptable way is to add cryptographic protection to the
   ICMPv6 packets carrying ND messages.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Ad Hoc Network</span>

   In an ad hoc network, or any network without a trusted operator, none
   of the nodes trust each other.  In a generic case, the nodes meet
   each other for the first time, and there are no guarantees that the
   other nodes would behave correctly at the IP layer.  They must be
   considered suspicious to send falsified ND and RD messages.




<span class="grey">Nikander, et al.             Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


   Since there are no a priori trust relationships, the nodes cannot
   rely on traditional authentication.  That is, the traditional
   authentication protocols rely on some existing relationship between
   the parties.  The relationship may be direct or indirect.  The
   indirect case relies on one or more trusted third parties, thereby
   creating a chain of trust relationships between the parties.

   In the generic ad hoc network case, there are no trusted third
   parties, nor do the parties trust each other directly.  Thus, the
   traditional means of first authenticating and then authorizing the
   users (to use their addresses) do not work.

   It is still possible to use self-identifying mechanisms, such as
   Cryptographically Generated Addresses (CGA) [<a href="#ref-7" title="&quot;Authentication of Mobile IPv6 Binding Updates and Acknowledgments&quot;">7</a>].  These allow the
   nodes to ensure that they are talking to the same nodes (as before)
   at all times, and that each of the nodes indeed have generated their
   IP address themselves and not "stolen" someone else's address.  It
   may also be possible to learn the identities of any routers using
   various kinds of heuristics, such as testing the node's ability to
   convey cryptographically protected traffic towards a known and
   trusted node somewhere in the Internet.  Methods like these seem to
   mitigate (but not completely block) some of the attacks outlined in
   the next section.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Threats on a (Public) Multi-Access Link</span>

   In this section we discuss threats against the current IPv6 Neighbor
   Discovery mechanisms, when used in multi-access links.  The threats
   are discussed in the light of the trust models defined in the
   previous section.

   There are three general types of threats:

   1.  Redirect attacks in which a malicious node redirects packets away
       from the last hop router or other legitimate receiver to another
       node on the link.

   2.  Denial-of-Service (DoS) attacks, in which a malicious node
       prevents communication between the node under attack and all
       other nodes, or a specific destination address.

   3.  Flooding Denial-of-Service (DoS) attacks, in which a malicious
       node redirects other hosts' traffic to a victim node, and thereby
       creates a flood of bogus traffic at the victim host.

   A redirect attack can be used for DoS purposes by having the node to
   which the packets were redirected drop the packets, either completely
   or by selectively forwarding some of them and not others.



<span class="grey">Nikander, et al.             Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


   The subsections below identify specific threats for IPv6 network
   access.  The threat descriptions are organized in three subsections.
   We first consider threats that do not involve routers or routing
   information.  We next consider threats that do involve routers or
   routing information.  Finally, we consider replay attacks and threats
   that are remotely exploitable.  All threats are discussed in the
   light of the trust models.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Non router/routing related threats</span>

   In this section we discuss attacks against "pure" Neighbor Discovery
   functions, i.e., Neighbor Discovery (ND), Neighbor Unreachability
   Detection (NUD), and Duplicate Address Detection (DAD) in Address
   Autoconfiguration.

<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>.  Neighbor Solicitation/Advertisement Spoofing</span>

   Nodes on the link use Neighbor Solicitation and Advertisement
   messages to create bindings between IP addresses and MAC addresses.
   More specifically, there are two cases when a node creates neighbor
   cache entries upon receiving Solicitations:

   1.  A node receives a Neighbor Solicitation that contains a node's
       address.  The node can use that to populate its neighbor cache.
       This is basically a performance optimization, and a SHOULD in the
       base documents.

   2.  During Duplicate Address Detection (DAD), if a node receives a
       Neighbor Solicitation for the same address it is soliciting for,
       the situation is considered a collision, and the node must cease
       to solicit for the said address.

   In contrast to solicitation messages that create or modify state only
   in these specific occasions, state is usually modified whenever a
   node receives a solicited-for advertisement message.

   An attacking node can cause packets for legitimate nodes, both hosts
   and routers, to be sent to some other link-layer address.  This can
   be done by either sending a Neighbor Solicitation with a different
   source link-layer address option, or sending a Neighbor Advertisement
   with a different target link-layer address option.

   The attacks succeed because the Neighbor Cache entry with the new
   link-layer address overwrites the old.  If the spoofed link-layer
   address is a valid one, as long as the attacker responds to the
   unicast Neighbor Solicitation messages sent as part of the Neighbor
   Unreachability Detection, packets will continue to be redirected.
   This is a redirect/DoS attack.



<span class="grey">Nikander, et al.             Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


   This mechanism can be used for a DoS attack by specifying an unused
   link-layer address; however, this DoS attack is of limited duration
   since after 30-50 seconds (with default timer values) the Neighbor
   Unreachability Detection mechanism will discard the bad link-layer
   address and multicast anew to discover the link-layer address.  As a
   consequence, the attacker will need to keep responding with
   fabricated link-layer addresses if it wants to maintain the attack
   beyond the timeout.

   The threat discussed in this subsection involves Neighbor
   Solicitation and Neighbor Advertisement messages.

   This attack is not a concern if access to the link is restricted to
   trusted nodes; if a trusted node is compromised, the other nodes are
   exposed to this threat.  In the case where just the operator is
   trusted, the nodes may rely on the operator to certify the address
   bindings for other local nodes.  From the security point of view, the
   router may act as a trusted proxy for the other nodes.  This assumes
   that the router can be trusted to represent correctly the other nodes
   on the link.  In the ad hoc network case, and optionally in the other
   two cases, the nodes may use self certifying techniques (e.g., CGA)
   to authorize address bindings.

   Additionally, some implementations log an error and refuse to accept
   ND overwrites, instead requiring the old entry to time out first.

<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>.  Neighbor Unreachability Detection (NUD) failure</span>

   Nodes on the link monitor the reachability of local destinations and
   routers with the Neighbor Unreachability Detection procedure [<a href="#ref-2" title="&quot;Neighbor Discovery for IP Version 6 (IPv6)&quot;">2</a>].
   Normally the nodes rely on upper-layer information to determine
   whether peer nodes are still reachable.  However, if there is a
   sufficiently long delay on upper-layer traffic, or if the node stops
   receiving replies from a peer node, the NUD procedure is invoked.
   The node sends a targeted NS to the peer node.  If the peer is still
   reachable, it will reply with a NA.  However, if the soliciting node
   receives no reply, it tries a few more times, eventually deleting the
   neighbor cache entry.  If needed, this triggers the standard address
   resolution protocol to learn the new MAC address.  No higher level
   traffic can proceed if this procedure flushes out neighbor cache
   entries after determining (perhaps incorrectly) that the peer is not
   reachable.

   A malicious node may keep sending fabricated NAs in response to NUD
   NS messages.  Unless the NA messages are somehow protected, the
   attacker may be able to extend the attack for a long time using this
   technique.  The actual consequences depend on why the node become




<span class="grey">Nikander, et al.             Informational                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


   unreachable for the first place, and how the target node would behave
   if it knew that the node has become unreachable.  This is a DoS
   attack.

   The threat discussed in this subsection involves Neighbor
   Solicitation/Advertisement messages.

   This attack is not a concern if access to the link is restricted to
   trusted nodes; if a trusted node is compromised, the other nodes are
   exposed to this DoS threat.  Under the two other trust models, a
   solution requires that the node performing NUD is able to make a
   distinction between genuine and fabricated NA responses.

<span class="h4"><a class="selflink" id="section-4.1.3" href="#section-4.1.3">4.1.3</a>.  Duplicate Address Detection DoS Attack</span>

   In networks where the entering hosts obtain their addresses using
   stateless address autoconfiguration [<a href="#ref-3" title="&quot;IPv6 Stateless Address Autoconfiguration&quot;">3</a>], an attacking node could
   launch a DoS attack by responding to every duplicate address
   detection attempt made by an entering host.  If the attacker claims
   the address, then the host will never be able to obtain an address.
   The attacker can claim the address in two ways: it can either reply
   with an NS, simulating that it is performing DAD, too, or it can
   reply with an NA, simulating that it has already taken the address
   into use.  This threat was identified in <a href="./rfc2462">RFC 2462</a> [<a href="#ref-3" title="&quot;IPv6 Stateless Address Autoconfiguration&quot;">3</a>].  The issue may
   also be present when other types of address configuration is used,
   i.e., whenever DAD is invoked prior to actually configuring the
   suggested address.  This is a DoS attack.

   The threat discussed in this subsection involves Neighbor
   Solicitation/Advertisement messages.

   This attack is not a concern if access to the link is restricted to
   trusted nodes; if a trusted node is compromised, the other nodes
   become exposed to this DoS threat.  Under the two other trust models,
   a solution requires that the node performing DAD is able to verify
   whether the sender of the NA response is authorized to use the given
   IP address or not.  In the trusted operator case, the operator may
   act as an authorizer, keeping track of allocated addresses and making
   sure that no node has allocated more than a few (hundreds of)
   addresses.  On the other hand, it may be detrimental to adopt such a
   practice, since there may be situations where it is desirable for one
   node to have a large number of addresses, e.g., creating a separate
   address per TCP connection, or when running an ND proxy.  Thus, it
   may be inappropriate to suggest that ISPs could control how many
   addresses a legitimate host can have; the discussion above must be
   considered only as examples, as stated in the beginning of this
   document.




<span class="grey">Nikander, et al.             Informational                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


   In the ad hoc network case one may want to structure the addresses in
   such a way that self authorization is possible.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Router/routing involving threats</span>

   In this section we consider threats pertinent to router discovery or
   other router assisted/related mechanisms.

<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>.  Malicious Last Hop Router</span>

   This threat was identified in [<a href="#ref-5" title="&quot;Threat Models introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6&quot;">5</a>] but was classified as a general
   IPv6 threat and not specific to Mobile IPv6.  It is also identified
   in <a href="./rfc2461">RFC 2461</a> [<a href="#ref-2" title="&quot;Neighbor Discovery for IP Version 6 (IPv6)&quot;">2</a>].  This threat is a redirect/DoS attack.

   An attacking node on the same subnet as a host attempting to discover
   a legitimate last hop router could masquerade as an IPv6 last hop
   router by multicasting legitimate-looking IPv6 Router Advertisements
   or unicasting Router Advertisements in response to multicast Router
   Advertisement Solicitations from the entering host.  If the entering
   host selects the attacker as its default router, the attacker has the
   opportunity to siphon off traffic from the host, or mount a man-in-
   the-middle attack.  The attacker could ensure that the entering host
   selected itself as the default router by multicasting periodic Router
   Advertisements for the real last hop router having a lifetime of
   zero.  This may spoof the entering host into believing that the real
   access router is not willing to take any traffic.  Once accepted as a
   legitimate router, the attacker could send Redirect messages to
   hosts, then disappear, thus covering its tracks.

   This threat is partially mitigated in <a href="./rfc2462">RFC 2462</a>; in <a href="./rfc2462#section-5.5.3">Section&nbsp;5.5.3 of
   RFC 2462</a> it is required that if the advertised prefix lifetime is
   less than 2 hours and less than the stored lifetime, the stored
   lifetime is not reduced unless the packet was authenticated.
   However, the default router selection procedure, as defined in
   <a href="./rfc2461#section-6.3.6">Section&nbsp;6.3.6. of RFC 2461</a>, does not contain such a rule.

   The threat discussed in this subsection involves Router Advertisement
   and Router Advertisement Solicitation messages.

   This attack is not a concern if access to the link is restricted to
   trusted nodes; if a trusted node is compromised, the other nodes are
   exposed to this threat.  However, the threat can be partially
   mitigated through a number of means, for example, by configuring the
   nodes to prefer existing routers over new ones.  Note that this
   approach does not necessarily prevent one from introducing new
   routers into the network, depending on the details of implementation.
   At minimum, it just makes the existing nodes to prefer the existing
   routers over the new ones.



<span class="grey">Nikander, et al.             Informational                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


   In the case of a trusted operator, there must be a means for the
   nodes to make a distinction between trustworthy routers, run by the
   operator, and other nodes.  There are currently no widely accepted
   solutions for the ad hoc network case, and the issue remains as a
   research question.

<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>.  Default router is 'killed'</span>

   In this attack, an attacker 'kills' the default router(s), thereby
   making the nodes on the link to assume that all nodes are local.  In
   <a href="./rfc2461#section-5.2">Section&nbsp;5.2 of RFC 2461</a> [<a href="#ref-2" title="&quot;Neighbor Discovery for IP Version 6 (IPv6)&quot;">2</a>] it is stated that "[if] the Default
   Router List is empty, the sender assumes that the destination is on-
   link."  Thus, if the attacker is able to make a node to believe that
   there are no default routers on the link, the node will try to send
   the packets directly, using Neighbor Discovery.  After that the
   attacker can use NS/NA spoofing even against off-link destinations.

   There are a few identified ways how an attacker can 'kill' the
   default router(s).  One is to launch a classic DoS attack against the
   router so that it does not appear responsive any more.  The other is
   to send a spoofed Router Advertisement with a zero Router Lifetime
   (see <a href="./rfc2461#section-6.3.4">Section&nbsp;6.3.4 of RFC 2461</a> [<a href="#ref-2" title="&quot;Neighbor Discovery for IP Version 6 (IPv6)&quot;">2</a>]).  However, see also the
   discussion in <a href="#section-4.2.1">Section 4.2.1</a>, above.

   This attack is mainly a DoS attack, but it could also be used to
   redirect traffic to the next better router, which may be the
   attacker.

   The threat discussed in this subsection involves Router Advertisement
   messages.  One variant of this threat may be possible by overloading
   the router, without using any ND/RD messages.

   This attack is not a concern if access to the link is restricted to
   trusted nodes; if a trusted node is compromised, the other nodes are
   exposed to this threat.  In the case of a trusted operator, there
   must be a means for the nodes to make a distinction between
   trustworthy routers, run by the operator, and other nodes.  That
   protects against spoofed Router Advertisements, but it does not
   protect against router overloading.  There are currently no widely
   accepted solutions for the ad hoc network case, and the issue remains
   as a research question.

   Thanks to Alain Durand for identifying this threat.








<span class="grey">Nikander, et al.             Informational                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


<span class="h4"><a class="selflink" id="section-4.2.3" href="#section-4.2.3">4.2.3</a>.  Good Router Goes Bad</span>

   In this attack, a router that previously was trusted is compromised.
   The attacks available are the same as those discussed in <a href="#section-4.2.1">Section</a>
   <a href="#section-4.2.1">4.2.1</a>.  This is a redirect/DoS attack.

   There are currently no known solutions for any of the presented three
   trust models.  On the other hand, on a multi-router link one could
   imagine a solution involving revocation of router rights.  The
   situation remains as a research question.

<span class="h4"><a class="selflink" id="section-4.2.4" href="#section-4.2.4">4.2.4</a>.  Spoofed Redirect Message</span>

   The Redirect message can be used to send packets for a given
   destination to any link-layer address on the link.  The attacker uses
   the link-local address of the current first-hop router in order to
   send a Redirect message to a legitimate host.  Since the host
   identifies the message by the link-local address as coming from its
   first hop router, it accepts the Redirect.  As long as the attacker
   responds to Neighbor Unreachability Detection probes to the link-
   layer address, the Redirect will remain in effect.  This is a
   redirect/DoS attack.

   The threat discussed in this subsection involves Redirect messages.

   This attack is not a concern if access to the link is restricted to
   trusted nodes; if a trusted node is compromised, the other nodes are
   exposed to this threat.  In the case of a trusted operator, there
   must be a means for the nodes to make a distinction between
   trustworthy routers, run by the operator, and other nodes.  There are
   currently no widely accepted solutions for the ad hoc network case,
   and the issue remains as a research question.

<span class="h4"><a class="selflink" id="section-4.2.5" href="#section-4.2.5">4.2.5</a>.  Bogus On-Link Prefix</span>

   An attacking node can send a Router Advertisement message specifying
   that some prefix of arbitrary length is on-link.  If a sending host
   thinks the prefix is on-link, it will never send a packet for that
   prefix to the router.  Instead, the host will try to perform address
   resolution by sending Neighbor Solicitations, but the Neighbor
   Solicitations will not result in a response, denying service to the
   attacked host.  This is a DoS attack.

   The attacker can use an arbitrary lifetime on the bogus prefix
   advertisement.  If the lifetime is infinity, the sending host will be
   denied service until it loses the state in its prefix list e.g., by
   rebooting, or after the same prefix is advertised with a zero




<span class="grey">Nikander, et al.             Informational                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


   lifetime.  The attack could also be perpetrated selectively for
   packets destined to a particular prefix by using 128 bit prefixes,
   i.e., full addresses.

   Additionally, the attack may cause a denial-of-service by flooding
   the routing table of the node.  The node would not be able to
   differentiate between legitimate on-link prefixes and bogus ones when
   making decisions as to which ones are kept and which are dropped.
   Inherently, any finite system must have some point at which new
   received prefixes must be dropped rather than accepted.

   This attack can be extended into a redirect attack if the attacker
   replies to the Neighbor Solicitations with spoofed Neighbor
   Advertisements, thereby luring the nodes on the link to send the
   traffic to it or to some other node.

   This threat involves Router Advertisement message.  The extended
   attack combines the attack defined in <a href="#section-4.1.1">Section 4.1.1</a> and in this
   section, and involves Neighbor Solicitation, Neighbor Advertisement,
   and Router Advertisement messages.

   This attack is not a concern if access to the link is restricted to
   trusted nodes; if a trusted node is compromised, the other nodes are
   exposed to this threat.  In the case of a trusted operator, there
   must be a means for the nodes to make a distinction between
   trustworthy routers, run by the operator, and other nodes.  There are
   currently no known solutions for the ad hoc network case, and the
   issue remains as a research question.

   As an example, one possible approach to limiting the damage of this
   attack is to require advertised on-link prefixes be /64s (otherwise
   it's easy to advertise something short like 0/0 and this attack is
   very easy).

<span class="h4"><a class="selflink" id="section-4.2.6" href="#section-4.2.6">4.2.6</a>.  Bogus Address Configuration Prefix</span>

   An attacking node can send a Router Advertisement message specifying
   an invalid subnet prefix to be used by a host for address
   autoconfiguration.  A host executing the address autoconfiguration
   algorithm uses the advertised prefix to construct an address [<a href="#ref-3" title="&quot;IPv6 Stateless Address Autoconfiguration&quot;">3</a>],
   even though that address is not valid for the subnet.  As a result,
   return packets never reach the host because the host's source address
   is invalid.  This is a DoS attack.

   This attack has the potential to propagate beyond the immediate
   attacked host if the attacked host performs a dynamic update to the
   DNS based on the bogus constructed address.  DNS update [<a href="#ref-4" title="&quot;Secure Domain Name System (DNS) Dynamic Update&quot;">4</a>] causes
   the bogus address to be added to the host's address record in the



<span class="grey">Nikander, et al.             Informational                     [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


   DNS.  Should this occur, applications performing name resolution
   through the DNS obtain the bogus address and an attempt to contact
   the host fails.  However, well-written applications will fall back
   and try the other addresses registered in DNS, which may be correct.

   A distributed attacker can make the attack more severe by creating a
   falsified reverse DNS entry that matches with the dynamic DNS entry
   created by the target.  Consider an attacker who has legitimate
   access to a prefix &lt;ATTACK_PRFX&gt;, and a target who has an interface
   ID &lt;TARGET_IID&gt;.  The attacker creates a reverse DNS entry for
   &lt;ATTACK_PRFX&gt;:&lt;TARGET_IID&gt;, pointing to the real domain name of the
   target, e.g., "secure.target.com".  Next the attacker advertises the
   &lt;ATTACK_PRFX&gt; prefix at the target's link.  The target will create an
   address &lt;ATTACK_PRFX&gt;:&lt;TARGET_IID&gt;, and update its DNS entry so that
   "secure.target.com" points to &lt;ATTACK_PRFX&gt;:&lt;TARGET_IID&gt;.

   At this point "secure.target.com" points to
   &lt;ATTACK_PRFX&gt;:&lt;TARGET_IID&gt;, and &lt;ATTACK_PRFX&gt;:&lt;TARGET_IID&gt; points to
   "secure.target.com".  This threat is mitigated by the fact that the
   attacker can be traced since the owner of the &lt;ATTACK_PRFX&gt; is
   available at the registries.

   There is also a related possibility of advertising a target prefix as
   an autoconfiguration prefix on a busy link, and then have all nodes
   on this link try to communicate to the external world with this
   address.  If the local router doesn't have ingress filtering on, then
   the target link may get a large number of replies for those initial
   communication attempts.

   The basic threat discussed in this subsection involves Router
   Advertisement messages.  The extended attack scenarios involve the
   DNS, too.

   This attack is not a concern if access to the link is restricted to
   trusted nodes; if a trusted node is compromised the other nodes are
   exposed to this threat.  In the case of a trusted operator, there
   must be a means for the nodes to make a distinction between
   trustworthy routers, run by the operator, and other nodes.  There are
   currently no known solutions for the ad hoc network case, and the
   issue remains as a research question.

<span class="h4"><a class="selflink" id="section-4.2.7" href="#section-4.2.7">4.2.7</a>.  Parameter Spoofing</span>

   IPv6 Router Advertisements contain a few parameters used by hosts
   when they send packets and to tell hosts whether or not they should
   perform stateful address configuration [<a href="#ref-2" title="&quot;Neighbor Discovery for IP Version 6 (IPv6)&quot;">2</a>].  An attacking node could
   send out a valid-seeming Router Advertisement that duplicates the




<span class="grey">Nikander, et al.             Informational                     [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


   Router Advertisement from the legitimate default router, except the
   included parameters are designed to disrupt legitimate traffic.  This
   is a DoS attack.

   Specific attacks include:

   1.  The attacker includes a Current Hop Limit of one or another small
       number which the attacker knows will cause legitimate packets to
       be dropped before they reach their destination.

   2.  The attacker implements a bogus DHCPv6 server or relay and the
       'M' and/or 'O' flag is set, indicating that stateful address
       configuration and/or stateful configuration of other parameters
       should be done.  The attacker is then in a position to answer the
       stateful configuration queries of a legitimate host with its own
       bogus replies.

   The threat discussed in this subsection involves Router Advertisement
   messages.

   Note that securing DHCP alone does not resolve this problem.  There
   are two reasons for this.  First, the attacker may prevent the node
   from using DHCP in the first place.  Second, depending on the node's
   local configuration, the attacker may spoof the node to use a less
   trusted DHCP server.  (The latter is a variant of the so called
   "bidding down" or "down grading" attacks.)

   As an example, one possible approach to mitigate this threat is to
   ignore very small hop limits.  The nodes could implement a
   configurable minimum hop limit, and ignore attempts to set it below
   said limit.

   This attack is not a concern if access to the link is restricted to
   trusted nodes; if a trusted node is compromised the other nodes are
   exposed to this treat.  In the case of a trusted operator, there must
   be a means for the nodes to make a distinction between trustworthy
   routers, run by the operator, and other nodes.  There are currently
   no known solutions for the ad hoc network case, and the issue remains
   a research question.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Replay attacks and remotely exploitable attacks</span>

<span class="h4"><a class="selflink" id="section-4.3.1" href="#section-4.3.1">4.3.1</a>.  Replay attacks</span>

   All Neighbor Discovery and Router Discovery messages are prone to
   replay attacks.  That is, even if they were cryptographically
   protected so that their contents cannot be forged, an attacker would




<span class="grey">Nikander, et al.             Informational                     [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


   be able to capture valid messages and replay them later.  Thus,
   independent on what mechanism is selected to secure the messages,
   that mechanism must be protected against replay attacks.

   Fortunately it is fairly easy to defeat most replay attacks.  In
   request-reply exchanges, such as Solicitation-Advertisement, the
   request may contain a nonce that must appear also in the reply.
   Thus, old replies are not valid since they do not contain the right
   nonce.  Correspondingly, stand-alone messages, such as unsolicited
   Advertisements or Redirect messages, may be protected with timestamps
   or counters.  In practise, roughly synchronized clocks and timestamps
   seem to work well, since the recipients may keep track of the
   difference between the clocks of different nodes, and make sure that
   all new messages are newer than the last seen message.

<span class="h4"><a class="selflink" id="section-4.3.2" href="#section-4.3.2">4.3.2</a>.  Neighbor Discovery DoS Attack</span>

   In this attack, the attacking node begins fabricating addresses with
   the subnet prefix and continuously sending packets to them.  The last
   hop router is obligated to resolve these addresses by sending
   neighbor solicitation packets.  A legitimate host attempting to enter
   the network may not be able to obtain Neighbor Discovery service from
   the last hop router as it will be already busy with sending other
   solicitations.  This DoS attack is different from the others in that
   the attacker may be off-link.  The resource being attacked in this
   case is the conceptual neighbor cache, which will be filled with
   attempts to resolve IPv6 addresses having a valid prefix but invalid
   suffix.  This is a DoS attack.

   The threat discussed in this subsection involves Neighbor
   Solicitation messages.

   This attack does not directly involve the trust models presented.
   However, if access to the link is restricted to registered nodes, and
   the access router keeps track of nodes that have registered for
   access on the link, the attack may be trivially plugged.  However, no
   such mechanisms are currently standardized.

   In a way, this problem is fairly similar to the TCP SYN flooding
   problem.  For example, rate limiting Neighbor Solicitations,
   restricting the amount of state reserved for unresolved
   solicitations, and clever cache management may be applied.

   It should be noted that both hosts and routers need to worry about
   this problem.  The router case was discussed above.  Hosts are also
   vulnerable since the neighbor discovery process can potentially be
   abused by an application that is tricked into sending packets to
   arbitrary on-link destinations.



<span class="grey">Nikander, et al.             Informational                     [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Summary of the attacks</span>

   Columns:

      N/R Neighbor Discovery (ND) or Router Discovery (RD) attack

      R/D Redirect/DoS (Redir) or just DoS attack

      Msgs Messages involved in the attack: NA, NS, RA, RS, Redir

      1  Present in trust model 1 (corporate intranet)

      2  Present in trust model 2 (public operator run network)

      3  Present in trust model 3 (ad hoc network)

   Symbols in trust model columns:

      -  The threat is not present or not a concern.

      +  The threat is present and at least one solution is known.

      R  The threat is present but solving it is a research problem.

   Note that the plus sign '+' in the table does not mean that there is
   a ready-to-be-applied, standardized solution.  If solutions existed,
   this document would be unnecessary.  Instead, it denotes that in the
   authors' opinion the problem has been solved in principle, and there
   exists a publication that describes some approach to solve the
   problem, or a solution may be produced by straightforward application
   of known research and/or engineering results.

   In the other hand, and 'R' indicates that the authors' are not aware
   of any publication describing a solution to the problem, and cannot
   at the time of writing think about any simple and easy extension of
   known research and/or engineering results to solve the problem.















<span class="grey">Nikander, et al.             Informational                     [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


   +-------+----------------------+-----+-------+-------+---+---+---+
   | Sec   | Attack name          | N/R | R/D   | Msgs  | 1 | 2 | 3 |
   +-------+----------------------+-----+-------+-------+---+---+---+
   | 4.1.1 | NS/NA spoofing       | ND  | Redir | NA NS | + | + | + |
   | 4.1.2 | NUD failure          | ND  | DoS   | NA NS | - | + | + |
   | 4.1.3 | DAD DoS              | ND  | DoS   | NA NS | - | + | + |
   +-------+----------------------+-----+-------+-------+---+---+---+
   | 4.2.1 | Malicious router     | RD  | Redir | RA RS | + | + | R |
   | 4.2.2 | Default router killed| RD  | Redir | RA    |+/R|+/R| R | 1)
   | 4.2.3 | Good router goes bad | RD  | Redir | RA RS | R | R | R |
   | 4.2.4 | Spoofed redirect     | RD  | Redir | Redir | + | + | R |
   | 4.2.5 | Bogus on-link prefix | RD  | DoS   | RA    | - | + | R | 2)
   | 4.2.6 | Bogus address config | RD  | DoS   | RA    | - | + | R | 3)
   | 4.2.7 | Parameter spoofing   | RD  | DoS   | RA    | - | + | R |
   +-------+----------------------+-----+-------+-------+---+---+---+
   | 4.3.1 | Replay attacks       | All | Redir | All   | + | + | + |
   | 4.3.2 | Remote ND DoS        | ND  | DoS   | NS    | + | + | + |
   +------------------------------+-----+-------+-------+---+---+---+

                                Figure 1

   1.  It is possible to protect the Router Advertisements, thereby
       closing one variant of this attack.  However, closing the other
       variant (overloading the router) does not seem to be plausible
       within the scope of this working group.

   2.  Note that the extended attack defined in <a href="#section-4.2.5">Section 4.2.5</a> combines
       sending a bogus on-link prefix and performing NS/NA spoofing as
       per <a href="#section-4.1.1">Section 4.1.1</a>.  Thus, if the NA/NS exchange is secured, the
       ability to use <a href="#section-4.2.5">Section 4.2.5</a> for redirect is most probably
       blocked, too.

   3.  The bogus DNS registration resulting from blindly registering the
       new address via DNS update [<a href="#ref-4" title="&quot;Secure Domain Name System (DNS) Dynamic Update&quot;">4</a>] is not considered an ND security
       issue here.  However, it should be noted as a possible
       vulnerability in implementations.

   For a slightly different approach, see also Section 7 in [<a href="#ref-9" title="&quot;Manual Configuration of Security Associations for IPv6 Neighbor Discovery&quot;">9</a>].
   Especially the table in Section 7.7 of [<a href="#ref-9" title="&quot;Manual Configuration of Security Associations for IPv6 Neighbor Discovery&quot;">9</a>] is very good.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Security Considerations</span>

   This document discusses security threats to network access in IPv6.
   As such, it is concerned entirely with security.







<span class="grey">Nikander, et al.             Informational                     [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Acknowledgements</span>

   Thanks to Alper Yegin of DoCoMo Communications Laboratories USA for
   identifying the Neighbor Discovery DoS attack.  We would also like to
   thank Tuomas Aura and Michael Roe of Microsoft Research Cambridge as
   well as Jari Arkko and Vesa-Matti Mantyla of Ericsson Research
   Nomadiclab for discussing some of the threats with us.

   Thanks to Alper Yegin, Pekka Savola, Bill Sommerfeld, Vijay
   Devaparalli, Dave Thaler, and Alain Durand for their constructive
   comments.

   Thanks to Craig Metz for his numerous very good comments, and
   especially for more material of implementations that refuse to accept
   ND overrides, for the bogus on-link prefix threat, and for reminding
   us about replay attacks.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Informative References</span>

   [<a id="ref-1">1</a>]   Kent, S. and R. Atkinson, "IP Authentication Header", <a href="./rfc2402">RFC 2402</a>,
         November 1998.

   [<a id="ref-2">2</a>]   Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
         for IP Version 6 (IPv6)", <a href="./rfc2461">RFC 2461</a>, December 1998.

   [<a id="ref-3">3</a>]   Thomson, S. and T. Narten, "IPv6 Stateless Address
         Autoconfiguration", <a href="./rfc2462">RFC 2462</a>, December 1998.

   [<a id="ref-4">4</a>]   Wellington, B., "Secure Domain Name System (DNS) Dynamic
         Update", <a href="./rfc3007">RFC 3007</a>, November 2000.

   [<a id="ref-5">5</a>]   Mankin, A., "Threat Models introduced by Mobile IPv6  and
         Requirements for Security in Mobile IPv6", Work in Progress.

   [<a id="ref-6">6</a>]   Kempf, J., Gentry, C. and A. Silverberg, "Securing IPv6
         Neighbor Discovery Using Address Based Keys (ABKs)", Work in
         Progress, June 2002.

   [<a id="ref-7">7</a>]   Roe, M., "Authentication of Mobile IPv6 Binding Updates and
         Acknowledgments", Work in Progress, March 2002.

   [<a id="ref-8">8</a>]   Arkko, J., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22Effects+of+ICMPv6+on+IKE%22'>"Effects of ICMPv6 on IKE"</a>, Work in Progress, March
         2003.

   [<a id="ref-9">9</a>]   Arkko, J., "Manual Configuration of Security Associations for
         IPv6 Neighbor Discovery", Work in Progress, March 2003.





<span class="grey">Nikander, et al.             Informational                     [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


Authors' Addresses

   Pekka Nikander (editor)
   Ericsson Research Nomadic Lab
   JORVAS  FIN-02420
   FINLAND

   Phone: +358 9 299 1
   EMail: pekka.nikander@nomadiclab.com


   James Kempf
   DoCoMo USA Labs
   181 Metro Drive, Suite 300
   San Jose, CA  95110
   USA

   Phone: +1 408 451 4711
   EMail: kempf@docomolabs-usa.com


   Erik Nordmark
   Sun Microsystems
   17 Network Circle
   Menlo Park, CA 94043
   USA

   Phone: +1 650 786 2921
   EMail: erik.nordmark@sun.com






















<span class="grey">Nikander, et al.             Informational                     [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc3756">RFC 3756</a>            IPv6 ND Trust Models and Threats            May 2004</span>


Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

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









Nikander, et al.             Informational                     [Page 23]
</pre>