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

Versions: 00 01 02 03 04 RFC 3756

Secure Neighborhood Discovery                       P. Nikander (editor)
Working Group                              Ericsson Research Nomadic Lab
Internet-Draft                                                  J. Kempf
Expires: July 24, 2003                                   DoCoMo USA Labs
                                                             E. Nordmark
                                           Sun Microsystems Laboratories
                                                        January 23, 2003


            IPv6 Neighbor Discovery trust models and threats
                        draft-ietf-send-psreq-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 July 24, 2003.

Copyright Notice

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

Abstract

   The existing IETF standards specify that IPv6 Neighbor Discovery and
   Address Autoconfiguration mechanisms MAY be protected with IPsec 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.



Nikander (editor), et al.    Expires July 24, 2003              [Page 1]


Internet-Draft          IPv6 ND trust & threats             January 2003


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Previous Work  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.    Trust models . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.1   Corporate Intranet Model . . . . . . . . . . . . . . . . . .  5
   3.2   Public Wireless Network with an Operator . . . . . . . . . .  6
   3.3   Ad Hoc Network . . . . . . . . . . . . . . . . . . . . . . .  7
   4.    Threats on a (Public) Multi-Access Link  . . . . . . . . . .  8
   4.1   Non router/routing related threats . . . . . . . . . . . . .  8
   4.1.1 Neighbor Solicitation/Advertisement Spoofing . . . . . . . .  8
   4.1.2 Neighbor Unreachability Detection (NUD) failure  . . . . . .  9
   4.1.3 Duplicate Address Detection DoS Attack . . . . . . . . . . . 10
   4.2   Router/routing involving threats . . . . . . . . . . . . . . 10
   4.2.1 Malicious Last Hop Router  . . . . . . . . . . . . . . . . . 10
   4.2.2 Good Router Goes Bad . . . . . . . . . . . . . . . . . . . . 11
   4.2.3 Spoofed Redirect Message . . . . . . . . . . . . . . . . . . 11
   4.2.4 Bogus On-Link Prefix . . . . . . . . . . . . . . . . . . . . 12
   4.2.5 Bogus Address Configuration Prefix . . . . . . . . . . . . . 13
   4.2.6 Parameter Spoofing . . . . . . . . . . . . . . . . . . . . . 14
   4.3   Remotely exploitable attacks . . . . . . . . . . . . . . . . 15
   4.3.1 Neighbor Discovery DoS Attack  . . . . . . . . . . . . . . . 15
   4.4   Summary of the attacks . . . . . . . . . . . . . . . . . . . 15
   5.    Security Considerations  . . . . . . . . . . . . . . . . . . 18
   6.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
         References . . . . . . . . . . . . . . . . . . . . . . . . . 20
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21
   A.    Changes between versions . . . . . . . . . . . . . . . . . . 22
         Intellectual Property and Copyright Statements . . . . . . . 23






















Nikander (editor), et al.    Expires July 24, 2003              [Page 2]


Internet-Draft          IPv6 ND trust & threats             January 2003


1. Introduction

   The IPv6 Neighbor Discovery RFC2461 [3] and Address Autoconfiguration
   RFC2462 [4] 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 RFC2402 [2] 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 [10].

   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 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 is 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.

   This document occasionally discusses solution proposals, such as CGA
   [9]  and ABK [8].  However, the discussion is solely for illustrative
   purposes.  It is meant to give the readers a more concrete idea of
   some possible solutions.  It 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 here in a rather
   non-technical and loose 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.






Nikander (editor), et al.    Expires July 24, 2003              [Page 3]


Internet-Draft          IPv6 ND trust & threats             January 2003


2. Previous Work

   The RFCs that specify the IPv6 Neighbor Discovery and Address
   Autoconfiguration protocols [3][4] 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 [2] header.  However, that solution is not always possible due to
   key management problems.  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 4 billion "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.














Nikander (editor), et al.    Expires July 24, 2003              [Page 4]


Internet-Draft          IPv6 ND trust & threats             January 2003


3. Trust models

   When considering various security solutions for the IPv6 Neighbor
   Discovery (ND) [3], 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.

   In the following, the RFC2461/RFC2662 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.

3.1 Corporate Intranet Model

   In a corporate intranet or other network where all nodes are under
   one administrative domain, the nodes may be considered to be reliable



Nikander (editor), et al.    Expires July 24, 2003              [Page 5]


Internet-Draft          IPv6 ND trust & threats             January 2003


   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 extend 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
   a WLAN with 802.11i RNS/EAS may be considered secure enough,
   requiring no further protection under this trust model.

   On the other hand, 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 Section 4.  In such case some
   protection is desirable to secure ND.  Providing such protection
   falls within the main initial focus of the SEND working group.

   Furthermore, even under this model 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 Section 2, 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 [10].  Furthermore, using a shared key would not
   protect against a compromised node.

3.2 Public Wireless Network with an Operator

   A scenario where an operator runs a public wireless (or wireline)
   network, e.g., a WLAN in a hotel, air port, 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
   not usually trust each other.  Typically the router (or routers) fall
   under one administrative domain, and the client nodes each fall under
   its 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



Nikander (editor), et al.    Expires July 24, 2003              [Page 6]


Internet-Draft          IPv6 ND trust & threats             January 2003


   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.
   Notice that there exists authentication protocols, e.g., variants of
   EAP, 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 Section 4; see the
   individual threat descriptions.  Specifically, even in 802.11i RNS/
   EAP the broadcast and multicast keys are shared between all nodes.
   Even if the underlying link layer is aware of all the nodes' link
   layer addresses, and is able to check that no source addresses were
   falsified, there may still be vulnerabilities.

   There seems to be two ways to bring in security into this scenario.
   One is to enforce strong security between the clients and the access
   router, and make the access router aware of the IP 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 way is to add cryptographic protection
   to the ICMPv6 packets carrying ND messages.

3.3 Ad Hoc Network

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

   Since there are no a priori trust relationships, the nodes cannot
   rely on traditional authentication.  However, it is still possible to
   use self-identifying mechanisms, such as Cryptographically Generated
   Addresses (CGA) [9].  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.








Nikander (editor), et al.    Expires July 24, 2003              [Page 7]


Internet-Draft          IPv6 ND trust & threats             January 2003


4. Threats on a (Public) Multi-Access Link

   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 two 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.

   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.

   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, and only after then those that do.  Finally, we consider
   threats that are remotely exploitable.  All threats are discussed in
   the light of the trust models.

4.1 Non router/routing related threats

   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.

4.1.1 Neighbor Solicitation/Advertisement Spoofing

   Nodes on the link use Neighbor Solicitation and Advertisement
   messages to created bindings between IP addresses and MAC addresses.

   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 IP address
   could additionally be the subnet router anycast address, allowing the
   attacker to capture traffic to that address.




Nikander (editor), et al.    Expires July 24, 2003              [Page 8]


Internet-Draft          IPv6 ND trust & threats             January 2003


   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.

   This mechanism can be used for a DoS attack by specifying an unused
   link-layer address, however, the 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.

   This threat involves Neighbor Solicitation and Neighbor
   Advertisement.

   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 just the operator is trusted,
   the nodes may rely on the operator to certify the address bindings
   for other local nodes.  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.

4.1.2 Neighbor Unreachability Detection (NUD) failure

   Nodes on the link monitor the reachability of local destinations and
   routers with the Neighbor Unreachability Detection procedure [3].
   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 first waits for a small random delay, and then 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.  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 cryptographically 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



Nikander (editor), et al.    Expires July 24, 2003              [Page 9]


Internet-Draft          IPv6 ND trust & threats             January 2003


   become 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.

   This threat involves Neighbor Solicitation/Advertisement.

   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.

4.1.3 Duplicate Address Detection DoS Attack

   In networks where the entering hosts obtain their addresses using
   stateless address autoconfiguration [4], 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.
   This threat was identified in RF2462 [4].  This is a DoS attack.

   This threat involves Neighbor Solicitation/Advertisement.

   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 may allocated more than a few (hundreds of)
   addresses.  In the ad hoc network case one has to structure the
   addresses in such a way that self authorization is possible.  CGA [9]
   provides one possible way to achieve that.

4.2 Router/routing involving threats

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

4.2.1 Malicious Last Hop Router

   This threat was identified in [6] but was classified as a general
   IPv6 threat and not specific to Mobile IPv6.  It is also identified
   in RFC2461 [3].  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



Nikander (editor), et al.    Expires July 24, 2003             [Page 10]


Internet-Draft          IPv6 ND trust & threats             January 2003


   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 RFC2462; in Section 5.5.3 of
   RFC2462 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 Section 6.3.6.  of
   RFC2461, does not contain such a rule.

   This threat involves Router Advertisement and Router Advertisement
   Solicitation.

   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.

   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.

4.2.2 Good Router Goes Bad

   In this attack, a router that previously was trusted is compromised.
   The attacks available are the same as those discussed in Section
   4.2.1.  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.

4.2.3 Spoofed Redirect Message




Nikander (editor), et al.    Expires July 24, 2003             [Page 11]


Internet-Draft          IPv6 ND trust & threats             January 2003


   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.

   This threat involves Redirect.

   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.

4.2.4 Bogus On-Link Prefix

   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 the same prefix is advertised with a zero lifetime.
   The attack could also be perpetrated selectively for packets destined
   to a particular prefix by using 128 bit prefixes, i.e.  full
   addresses.

   This attack can be extended into a redirect attack if the tacker
   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.  The extended attack
   combines the attack defined in Section 4.1.1 and in this section, and
   involves Neighbor Solicitation, Neighbor Advertisement, and Router
   Advertisement.




Nikander (editor), et al.    Expires July 24, 2003             [Page 12]


Internet-Draft          IPv6 ND trust & threats             January 2003


   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.

4.2.5 Bogus Address Configuration Prefix

   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 [4],
   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 causes the
   bogus address to be added to the host's AAAA record in the 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 IP address in the AAAA RRset, 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 <ATTACK_PRFX>, and a target who has an interface
   ID <TARGET_IID>.  The attacker creates a reverse DNS entry for
   <ATTACK_PRFX>:<TARGET_IID>, pointing to the real domain name of the
   target, e.g.  "secure.target.com".  Next the attacker advertises the
   <ATTACK_PRFX> prefix at the target's link.  The target will create an
   address <ATTACK_PRFX>:<TARGET_IID>, and update its DNS entry so that
   "secure.target.com" points to <ATTACK_PRFX>:<TARGET_IID>.

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

   There is also a related possibility of advertising the 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,



Nikander (editor), et al.    Expires July 24, 2003             [Page 13]


Internet-Draft          IPv6 ND trust & threats             January 2003


   then the target link will get all the replies for those initial
   communication attempts.

   This threat involves Router Advertisement.  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.

4.2.6 Parameter Spoofing

   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 [3].  An attacking node could
   send out a valid-seeming Router Advertisement that duplicates the
   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.

   This threat involves Router Advertisements.

   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
   as a research question.





Nikander (editor), et al.    Expires July 24, 2003             [Page 14]


Internet-Draft          IPv6 ND trust & threats             January 2003


4.3 Remotely exploitable attacks

4.3.1 Neighbor Discovery DoS Attack

   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.

   This threat involves Neighbor Solicitation.

   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.  Rate limitating Neighbor Solicitations, restricting the
   amount of state reserved for unresolved soliciations, 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.

   It is an open question whether the SEND WG should address this threat
   or not.

4.4 Summary of the attacks

   Columns:

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

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






Nikander (editor), et al.    Expires July 24, 2003             [Page 15]


Internet-Draft          IPv6 ND trust & threats             January 2003


   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


         +-------+----------------------------+-----+-------+-------+---+---+---+
         | 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 | Good router goes bad       | RD  | Redir | RA RS | R | R | R |
         | 4.2.3 | Spoofed redirect           | RD  | Redir | Redir | + | + | R |
         | 4.2.4 | Bogus on-link prefix       | RD  | DoS   | RA    | - | + | R | 1)
         | 4.2.5 | Bogus address config prefix| RD  | DoS   | RA    | - | + | R | 2)
         | 4.2.6 | Parameter spoofing         | RD  | DoS   | RA    | - | + | R |
         +-------+----------------------------+-----+-------+-------+---+---+---+
         | 4.3.1 | Remote ND DoS              | ND  | DoS   | NS    | + | + | + |
         +------------------------------------+-----+-------+-------+---+---+---+

                                Figure 1

   1.  Note that the extended attack defined in Section 4.2.4 combines
       sending a bogus on-link prefix and performing NS/NA spoofing as
       per Section 4.1.1 Thus, if the NA/NS exchange is secured, the
       ability to use Section 4.2.4 for redirect is most probably
       blocked, too.

   2.  The bogus DNS registration resulting from blindly registering the
       new address via DynDNS 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 [11].



Nikander (editor), et al.    Expires July 24, 2003             [Page 16]


Internet-Draft          IPv6 ND trust & threats             January 2003


   Especially the table in Section 7.7 of [11] is very good.


















































Nikander (editor), et al.    Expires July 24, 2003             [Page 17]


Internet-Draft          IPv6 ND trust & threats             January 2003


5. Security Considerations

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















































Nikander (editor), et al.    Expires July 24, 2003             [Page 18]


Internet-Draft          IPv6 ND trust & threats             January 2003


6. Acknowledgements

   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 E.  Yegin, Pekka Savola and Bill Sommerfeld for their
   constructive comments.









































Nikander (editor), et al.    Expires July 24, 2003             [Page 19]


Internet-Draft          IPv6 ND trust & threats             January 2003


References

   [1]   Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
         Protocol (EAP)", RFC 2284, March 1998.

   [2]   Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
         November 1998.

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

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

   [5]   Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
         December 1998.

   [6]   "Threat Models introduced by Mobile IPv6  and Requirements for
         Security in Mobile IPv6",
         draft-ietf-mobileip-mipv6-scrty-reqts-02 (work in progress),
         November 2001.

   [7]   Droms, R., "Dynamic Host Configuration Protocol for IPv6
         (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress),
         November 2002.

   [8]   Kempf, J., "Securing IPv6 Neighbor Discovery Using Address
         Based Keys (ABKs)", draft-kempf-secure-nd-01 (work in
         progress), June 2002.

   [9]   Roe, M., "Authentication of Mobile IPv6 Binding Updates and
         Acknowledgments", draft-roe-mobileip-updateauth-02 (work in
         progress), March 2002.

   [10]  Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies",
         draft-arkko-icmpv6-ike-effects-01 (work in progress), June
         2002.

   [11]  Arkko, J., "Manual SA Configuration for IPv6 Link Local
         Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress),
         June 2002.










Nikander (editor), et al.    Expires July 24, 2003             [Page 20]


Internet-Draft          IPv6 ND trust & threats             January 2003


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 Laboratories
   29, Chemin du Vieux Chene
   Meylan  38240
   France

   Phone: +33 4 76 18 88 03
   EMail: erik.nordmark@sun.com






















Nikander (editor), et al.    Expires July 24, 2003             [Page 21]


Internet-Draft          IPv6 ND trust & threats             January 2003


Appendix A. Changes between versions

   (To be removed before publication.)

   -00 to -01

      Added text to Section 4.2.4 to explained the combined NS/NA
      spoofing + Bogus On-Link Prefix attack (suggested by Pekka
      Savola).

      Added text to Section 4.2.5 to describe how it can be extended to
      include a valid reverse DNS mapping (suggested by Pekka Savola).

      Added text to Section 4.2.5 to consider its potential flooding
      effects (suggested by Jari Arkko).

      Added text through the document to trust model 1, considering what
      happens if a previously trusted node becomes compromised
      (suggested by Pekka Savola and Bill Sommerfeld).

      Changed the summary table in Section 4.4 so that the redirect
      threats should be considered even in the corporate intranet case.

      Added qualifying text to all occasions where a node is said to
      trust another node, and even to some cases where a node is said
      not to trust another node.

      Added footnotes 1) and 2) to Figure 1

      Added more discussion to threat Section 4.3.1 noting that it is
      similar to TCP SYN flooding, and that also hosts need to worry
      about it.

      Converted to xml2rfc.

















Nikander (editor), et al.    Expires July 24, 2003             [Page 22]


Internet-Draft          IPv6 ND trust & threats             January 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; 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.


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 assignees.

   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



Nikander (editor), et al.    Expires July 24, 2003             [Page 23]


Internet-Draft          IPv6 ND trust & threats             January 2003


   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.











































Nikander (editor), et al.    Expires July 24, 2003             [Page 24]


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