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

Versions: 00 01 02 03 04 RFC 3756

SEND Working Group                                 P. Nikander (editor)
Internet Draft                                     October 17, 2002
draft-ietf-send-psreq-00.txt
Expires: April 17, 2002



            IPv6 Neighbor Discovery trust models and threats


Status of this Memo

   This document is an Internet-Draft and is subject to 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.

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 pertient to IPv6 Neighbor
   Discovery.  The purpose of this discussion is to define the
   requirements for Securing IPv6 Neigbor Discovery.


draft-ietf-send-psreq-00.txt                        P. Nikander (editor)

Table of Contents

   1.0 Introduction
   2.0 Previous Work
   3.0 Trust models
       3.1 Corporate Intranet Model
       3.2 Public Wireless Network with an Operator
       3.3 Ad Hoc Network
   4.0 Threats on a (Public) Multi-Access Link
       4.1 Non router/routing related threats
           4.1.1 Neighbor Solicitation/Advertisement Spoofing
           4.1.2 Neighbor Unreachability Detection (NUD) failure
           4.1.3 Duplicate Address Detection DoS Attack
       4.2 Router/routing involving threats
           4.2.1 Malicious Last Hop Router
           4.2.2 Good Router Goes Bad
           4.2.3 Spoofed Redirect Message
           4.2.4 Bogus On-Link Prefix
           4.2.5 Bogus Address Configuration Prefix
           4.2.6 Parameter Spoofing
       4.3 Remotely exploitable attacks
           4.3.1 Neighbor Discovery DoS Attack
       4.4 Summary of the attacks
   5.0 Security Considerations
   6.0 Acknowledgements
   7.0 References
   8.0 Authors' Addresses
   9.0 Copyright Statement

1.0     Introduction

   The IPv6 Neighbor Discovery [RFC2461] and Address Autoconfiguration
   [RFC2462] 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] 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 [IKE-ND].

   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 fulfil
   this purpose, this document first defines three different trust
   models, roughly corresponding to secured corporate intranets,
   public wireless access networks, and pure ad hoc netwroks.  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

draft-ietf-send-psreq-00.txt                        P. Nikander (editor)

   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 [CGA] and ABK [ABK].  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.

2.0     Previous Work

   The RFCs that specify the IPv6 Neighbor Discovery and Address
   Autoconfiguration protocols [RFC2461] [RFC2462] 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 header [RFC2402].  However,
   thas 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.

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

3.0     Trust models

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

draft-ietf-send-psreq-00.txt                        P. Nikander (editor)

   Three different trust models are specified:

     1. A model where all authenticated nodes trust each other.
        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.  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 service.  The clients do not trust each other.

     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.

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

   As mentioned in Section 2.0, one possiblity would be to use IPsec
   AH with symmetric shared keys, known by all trusted nodes and by no
   outsiders.  However, none of the currently standardised automatic
   key distribution mechanisms work right out-of-the-box.  For further
   details, see [IKE-ND].

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.
   However, they 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.

draft-ietf-send-psreq-00.txt                        P. Nikander (editor)

   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.  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.0; 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.  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].  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 convery
   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.

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

draft-ietf-send-psreq-00.txt                        P. Nikander (editor)

   There are two general types of threats:

      1) Redirect attacks in which a malicious node redirects packets
         away from the last hop router 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, Neigbor
   Unreachability Discovery, and Address Autoconfiguration.

4.1.1   Neighbor Solicitation/Advertisement Spoofing

   Nodes on the link use Neighbor Solicitation and Adverticement
   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.  The attack
   results 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.

draft-ietf-send-psreq-00.txt                        P. Nikander (editor)

   This threat involves Neighbor Solicitation and Neighbor
   Advertisement messages.

   This attack is not a concern if access to the link is restricted to
   trusted nodes.  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
   trusted operator case, 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 procedure [RFC2461].
   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 distrupt communications for
   a long time using this technique.  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.  Under the two other trust models, a solution
   requires that the node performing NUD is able to make a
   disctinction 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 [RFC2462], an attacking node
   could launch a DoS attack by responding to every duplicate address
   detection attempt 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 RFC 2462 [RFC2462].  This is a DoS
   attack.

   This attack involves Neighbor Solicitation/Advertisement.

draft-ietf-send-psreq-00.txt                        P. Nikander (editor)

   This attack is not a concern if access to the link is restricted to
   trusted nodes.  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 acts 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 noc network case one has to structure the addresses in
   such a way that self authorization is possible.  CGA [CGA] provides
   one possible way to achieve that.

4.2     Router/routing involving threats

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

4.2.1   Malicious Last Hop Router

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

   [XXX: The section above needs reconsideration.  It appears that
   just sending an RA with a zero lifetime is not enough.  New text is
   needed.]

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


draft-ietf-send-psreq-00.txt                        P. Nikander (editor)

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

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

   This attack is not a concern if access to the link is restricted to
   trusted nodes.  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.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 threat involves Router Advertisement messages.

   This attack is not a concern if access to the link is restricted to
   trusted nodes.  In the case of a trusted operator, there must be a
   means for the nodes to make a distinction between trustworthy

draft-ietf-send-psreq-00.txt                        P. Nikander (editor)

   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 [RFC2462],
   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.

   This threat involves Router Advertisement messages.

   This attack is not a concern if access to the link is restricted to
   trusted nodes.  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 [RFC2461].  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 legitmate
         host with its own bogus replies.

draft-ietf-send-psreq-00.txt                        P. Nikander (editor)

   This attack involves Router Advertisements.

   This attack is not a concern if access to the link is restricted to
   trusted nodes.  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.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 attack involves Neighbor Solicitation.

   This attack does not directly involve the trust models presented.
   However, if access to the link is restricted to registed 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.

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

draft-ietf-send-psreq-00.txt                        P. Nikander (editor)

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
     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
     +     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 |
   | 4.2.5 | Bogus address config prefix| RD  | DoS   | RA    | - | + | R |
   | 4.2.6 | Parameter spoofing         | RD  | DoS   | RA    | - | + | R |
   +-------+----------------------------+-----+-------+-------+---+---+---+
   | 4.3.1 | Remote ND DoS              | ND  | DoS   | NS    | + | + | + |
   +------------------------------------+-----+-------+-------+---+---+---+

draft-ietf-send-psreq-00.txt                        P. Nikander (editor)

5.0     Security Considerations

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

6.0     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 M„ntyl„ of Ericsson
   Research Nomadiclab for discussing some of the threats with us.

7.0     References

   [RFC2461] T. Narten, E. Nordmark, and W. Simson, "Neighbor
             Discovery for IP Version 6 (IPv6)," RFC2461,
             December, 1998.

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

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

   [MIP_TH]  Mankin, et. al., "Threat Models introduced by Mobile IPv6 and
             Requirements for Security in Mobile IPv6," draft-ietf-mobileip-
             mipv6-scrty-reqts-01.txt, a work in progress.

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

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

   [DHCPv6]  Droms, R., editor, "Dynamic Host Configuration Protocol for
             IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-20.txt, a work in
             progress.

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

   [CGA]     M. Roe, T. Aura, G. O'Shea, J. Arkko, "Authentication
             of Mobile IPv6 binding updates and acknowledgements,"
             work in progress, draft-roe-mobileip-updateauth-02.txt,
             IETF Mobile IP WG, February 2002.

   [IKE-ND]  J. Arkko, "Effects of ICMPv6 on IKE and IPsec
             Policies," work in progress,
             drat-arkko-icmpv6-ike-effects-02.txt, June 2002.


draft-ietf-send-psreq-00.txt                        P. Nikander (editor)

8.0     Authors' Addresses

   Pekka Nikander (editor)
   Ericsson Research Nomadic Lab  Phone: +358 9 299 1
   FIN-02420 JORVAS               Email: pekka.nikander@nomadiclab.com
   FINLAND

   James Kempf
   DoCoMo USA Labs
   181 Metro Drive, Suite 300     Phone:  +1 408 451 4711
   San Jose, CA, 95110            Email:  kempf@docomolabs-usa.com
   USA

   Erik Nordmark
   Sun Microsystems Laboratories  Phone: +33 4 76 18 88 03
   29, Chemin du Vieux Chene      Fax:   +33 4 76 18 88 88
   38240 Meylan                   Email: erik.nordmark@sun.com
   France

9.0     Copyright Statement

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

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

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

SEND Working Group                                 P. Nikander (editor)
Internet Draft                                     October 17, 2002
draft-ietf-send-psreq-00.txt
Expires: April 17, 2002


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