Network Working Group                                           J. Arkko
Internet-Draft                                               P. Nikander
Expires: September 1, 2003                                      Ericsson
                                                              T. Kivinen
                                                                M. Rossi
                                             SSH Communications Security
                                                           March 3, 2003

    Manual Configuration of Security Associations for IPv6 Neighbor

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 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://

   The list of Internet-Draft Shadow Directories can be accessed at

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

Copyright Notice

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


   This informational document discusses the use of manually configured
   IPsec security associations to protect IPv6 Neighbor Discovery (ND)
   messages.  IPsec security associations are generally identified by
   the triple (security parameters index, destination address,
   protocol).  In the case of Neighbor Discovery, configuring these
   associations requires some effort, however.  There are multiple known
   destination addresses plus a number of addresses that depend on the

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

Internet-Draft             Manual SAs for ND                  March 2003

   physical link addresses.  This document describes the security
   implications of protecting or not protecting the Neighbor Discovery
   messages and lists the security associations that must be configured
   manually.  The presented method is applicable only in small networks,
   but some approaches for reducing the configuration effort are

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terms  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Addressing . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Neighbor Discovery Tasks . . . . . . . . . . . . . . . . . . .  8
         5.1 Router and Prefix Discovery  . . . . . . . . . . . . . .  8
         5.2 Address Autoconfiguration  . . . . . . . . . . . . . . .  8
         5.3 Duplicate Address Detection  . . . . . . . . . . . . . .  9
         5.4 Address Resolution . . . . . . . . . . . . . . . . . . .  9
         5.5 Neighbor Reachability Detection  . . . . . . . . . . . .  9
         5.6 Redirect . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Recommendation for manual security association setup . . . . . 11
   7.  Security Implications of Neighbor Discovery Messages . . . . . 14
         7.1 Router Discovery . . . . . . . . . . . . . . . . . . . . 15
         7.2 Address Resolution . . . . . . . . . . . . . . . . . . . 15
         7.3 Duplicate Address Detection  . . . . . . . . . . . . . . 16
         7.4 Address Autoconfiguration  . . . . . . . . . . . . . . . 16
         7.5 Neighbor Reachability Detection  . . . . . . . . . . . . 16
         7.6 Redirect . . . . . . . . . . . . . . . . . . . . . . . . 17
         7.7 Summary  . . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  Approaches for Reducing Configuration Effort . . . . . . . . . 19
   9.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 21
       Normative References . . . . . . . . . . . . . . . . . . . . . 22
       Informative References . . . . . . . . . . . . . . . . . . . . 23
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
       Intellectual Property and Copyright Statements . . . . . . . . 26

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

Internet-Draft             Manual SAs for ND                  March 2003

1. Introduction

   IPv6 architecture makes it possible to secure all IP packets using
   IPsec [3], even control messages and even to multicast addresses.
   IPsec architecture has a Security Policy Database that specifies
   which traffic is protected, and how.

   The IPv6 Neighbor Discovery [5] protocol is intended to be used for
   router discovery, address resolution, and other tasks on the local
   link.  As described elsewhere [11], dynamically negotiated security
   associations cannot be used to protect these messages as the
   negotiation would already require the messages to have been
   exchanged.  Instead, manually configured security associations must
   be used.

   However, setting up these security associations is not easy.  This
   document lists those fixed multicast, calculated multicast, and node
   addresses for which the security associations must be created.  We
   will also discuss the security implications of the Neighbor Discovery
   messages under various assumptions of attacker capabilities.
   Finally, we discuss approaches that can be used to reduce
   configuration work in setting up the manual security associations.
   These approaches include configuration tools, the use of well-known
   SPI numbers with special treatment, and new protocols.

   The configuration guidelines in this document are one approach which
   MAY be used by system administrators.  The guidelines do not imply
   any implementation modifications or extensions for Neighbor Discovery
   or IPsec.  However, the ability of IPsec security policy entries to
   use ICMP type as a selector eases the construction of the entries.
   Such extensions are outside the scope of this document.

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

Internet-Draft             Manual SAs for ND                  March 2003

2. Terminology

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [1].

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

Internet-Draft             Manual SAs for ND                  March 2003

3. Terms

   Internet Control Message Protocol version 6 (ICMPv6)

      The IPv6 control signaling protocol.  Neighbor Discovery is a part
      of ICMPv6.

   Neighbor Discovery (ND)

      The IPv6 Neighbor Discovery protocol [5].

   Security association (SA)

      A security association (SA) is a simplex "connection" that affords
      security services to the traffic carried by it.  Security services
      are afforded to an security association by the use of AH, or ESP,
      but not both.  A security association is uniquely identified by a
      triple consisting of a Security Parameter Index (SPI), an IP
      Destination Address, and a security protocol (AH or ESP)
      identifier [3].

   Security Association Database (SAD)

      A nominal database containing parameters that are associated with
      each (active) security association.  For inbound and outbound
      IPsec processing, these databases are separate.

   Security Parameters Index (SPI)

      An arbitrary 32-bit value.  Together with the destination IP
      address and security protocol (ESP or AH) identifier, the SPI
      uniquely identifies the Security Association.  Values from 1 to
      255 are reserved.

   Security Parameters Index (SPI)

      A security parameters index identifies a particular security
      association among a group of security associations with the same
      destination address and protocol.

   Security Policy

      The security policy determines the security services afforded to
      an IPsec protected packet and the treatment of the packet in the

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

Internet-Draft             Manual SAs for ND                  March 2003

   Security Policy Database (SPD)

      A nominal database containing a list of policy entries.  Each
      policy entry is keyed by one or more selectors that define the set
      of IP traffic encompassed by this policy entry.  Separate entries
      for inbound and outbound traffic is required  [3].

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

Internet-Draft             Manual SAs for ND                  March 2003

4. Addressing

   Neighbor Discovery messages are sent using various kinds of source
   and destination address types.  The nature of the destination address
   is of relevance here, as the destination address is used to find the
   right security association.  The destination address can be either a
   well known multicast address, a computed multicast address, such as
   the solicited-node multicast address, or a unicast address.  Many
   Neighbor Discovery messages use multicast addresses in most cases.
   Some messages can also be sent to unicast addresses in certain
   situations.  For instance, the Neighbor Solicitation messages are
   usually sent to multicast addresses, but the Neighbor Advertisement
   messages are also sent to unicast addresses when sent as a response
   to a node that has an address.

   The Neighbor Discovery specifications do not always use specific
   language when talking about the possible forms of addresses for the
   messages.  The word "typically" is in some cases used to describe an
   address that would most logically be used for a particular message,
   but other addresses may still be used in some situations or in some

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

Internet-Draft             Manual SAs for ND                  March 2003

5. Neighbor Discovery Tasks

   Neighbor Discovery has several tasks, and many of these tasks are
   overloaded on a few central message types such as the Neighbor
   Solicitation message.  In this chapter we explain some of these tasks
   and their effects in order to understand better how the messages
   should be treated.  We will only discuss those tasks for which manual
   security association protection is relevant, i.e., which cannot be
   protected using IKE-based [4] security associations according to

5.1 Router and Prefix Discovery

   The main purpose of the router discovery is to find neighboring
   routers that are willing to forward packets on the behalf of hosts.
   Prefix discovery involves determining which destinations are directly
   on a link; this information is necessary in order to know whether a
   packet should be sent to a router or to the destination directly.
   Typically, address autoconfiguration and other tasks can not proceed
   until the router discovery process has run.

   The Router Solicitation and Router Advertisement messages are used
   for this and only this purpose.

   The Router Solicitation message has ICMPv6 type 133.  The destination
   address is typically the All Routers multicast address [2].  This
   message is always used only locally on the link.

   The Router Advertisement message has ICMPv6 typer 134.  The
   destination address can be either a unicast or the All Nodes
   multicast address [2].  Like the solicitation message, the
   advertisement is also local to the link only.

5.2 Address Autoconfiguration

   Address autoconfiguration is another part of the Neighbor Discovery
   protocol [6].  It's purpose is to automatically assign addresses to
   interfaces.  It comes in two variants, stateless and stateful.  In
   this document we consider only the stateless autoconfiguration

   The Neighbor Solicitation and Advertisement messages are used for
   this purpose, among other things.  Furthermore, Router and Prefix
   Discovery and Duplicate Address Detection have an effect to the
   Address Autoconfiguration tasks.

   The Neighbor Solicitation message has ICMPv6 type 135.  The
   destination address is either the solicited node multicast address,

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

Internet-Draft             Manual SAs for ND                  March 2003

   unicast address, or an anycast address [2, 7].  Neighbor Solicitation
   and Advertisement messages are used for multiple purposes: address
   autoconfiguration, duplicate address detection, and reachability
   detection.  In all these roles they are link local.

   The Neighbor Advertisement type is 136.  The the destination address
   is either a unicast address or the All Nodes multicast address [2].
   Like the solicitation message, this message is link local.

5.3 Duplicate Address Detection

   As a part of the stateless address autoconfiguration procedure, nodes
   check for duplicate addresses prior to assigning an address to an
   interface [6].  This procedure uses the same messages as the Neighbor
   Discovery protocol [5].  Since the rules outlined in RFC 2462 [6]
   forbid the use of an address for both sending and receiving packets
   until it has been found unique, no higher layer traffic is possible
   until this procedure has completed.

   The Neighbor Solicitation and Advertisement messages are used also
   for this purpose.

5.4 Address Resolution

   In address resolution nodes determine the link-layer address of a
   local destination given only the destination's IP address.  Again, no
   higher level traffic can proceed until the sender knows the hardware
   address of the destination or the next hop router.

   The Neighbor Solicitation and Advertisement messages are used also
   for this purpose.

5.5 Neighbor Reachability Detection

   Hosts monitor the reachability of local destinations and routers in
   the Neighbor Unreachability procedure, which is a part of the
   Neighbor Discovery protocol [5].  No higher level traffic can proceed
   if this procedure flushes out neighbor cache entries after (perhaps
   incorrectly) determining that the peer is not reachable.

   The Neighbor Solicitation and Advertisement messages are used also
   for this purpose.

5.6 Redirect

   In the Redirect procedure, a router informs a host of a better
   first-hop node to reach a particular destination [5].  It is a part
   of the Neighbor Discovery protocol.  As routers forward packets

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

Internet-Draft             Manual SAs for ND                  March 2003

   regardless of them being sent first to the wrong place,
   communications can still be established without the ability to
   process Redirect messages.

   The Redirect message is used solely in the Redirect procedure.  Its
   ICMPv6 type is 137.  The Redirect message is always sent from a
   unicast addresses to the source address of the packet that triggered
   the Redirect.  Rules in RFC 2373 [2] dictate that unspecified,
   anycast, or multicast addresses may not be used as source addresses.
   Therefore, the destination address will always be a unicast address.
   This message is only used for link local purposes, not for end-to-end

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

Internet-Draft             Manual SAs for ND                  March 2003

6. Recommendation for manual security association setup

   As described above, Neighbor Discovery uses as a destination address
   either an unicast address, a known multicast address, or a computed
   multicast addresses (based on the physical link addresses).  On a
   given link, the following security associations are required if all
   Neighbor Discovery traffic is to be secured with IPsec:

   1.  ICMPv6 packets to the All Nodes multicast address
       FF02:0:0:0:0:0:0:1 [2].

   2.  ICMPv6 packets to the All Routers multicast address
       FF02:0:0:0:0:0:0:1 [2].

   3.  For each node on the network, ICMPv6 packets to the Solicited
       Node multicast address FF02:0:0:0:0:1:FFXX:XXXX target='RFC2373'
       />.  Note that, in general, there will be multiple such addresses
       when there are multiple nodes, but it is also possible that some
       of these multicast addresses collide since only 24 bits from the
       physical link addresses are used in the multicast address.

   4.  For each node on the network, ICMPv6 packets to the unicast
       address of that node.

       Given that such ICMPv6 packets may be sent also from other
       sources than the those on the local link, it is necessary to
       construct the security policy entries in the following manner:

       *  Only the addresses of other nodes on the same link can appear
          as the source address, along with the Unspecified address

       *  Alternatively, only ICMP types related to Neighbor Discovery
          (Neighbor Solicitation, Neighbor Advertisement, Router
          Solicitation, Router Advertisement, and Redirect) are listed.
          However, this requires the IPsec security policy mechanisms to
          support ICMP type as a selector in the manner described in

   5.  For each node that has multiple unicast addresses, items (3) and
       (4) have to be repeated for each address.

   These rules result in at most 2 * (N * M + 1) security associations
   where N is the number of nodes in the network and M is the number of
   addresses each node has.  Table 1 below tabulates the number of
   security associations required as a function of the number of nodes
   in the network:

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

Internet-Draft             Manual SAs for ND                  March 2003

   |   # of Nodes |  # of Addrs |    # of SAs |
   |            1 |           1 |           4 |
   |            1 |           2 |           6 |
   |            4 |           1 |          10 |
   |            4 |           2 |          18 |
   |           10 |           1 |          22 |
   |           10 |           2 |          42 |
   |           20 |           1 |          42 |
   |           20 |           2 |          82 |
   |           50 |           1 |         102 |
   |           50 |           2 |         202 |
   |          100 |           1 |         202 |
   |          100 |           2 |         402 |
   |         1000 |           1 |        2002 |
   |         1000 |           2 |        4002 |

   The above setup also implies that one knows beforehand the physical
   link and IP level addresses of each node on the link, including the
   multiple addresses mentioned under (5).  Normally, a node may not
   necessarily know the addresses itself but they are rather specified
   in the set of router advertisements received.  These things
   complicate the setup.  But the complication is similar to the
   requirement that the keys can be configured manually for all of these
   nodes; it is not possible to provide security and at the same time
   allow previously unknown nodes to the system when manual keying is

   Note that if the address privacy extension [8] is used for address
   autoconfiguration, it may not be possible to know the physical
   address identifiers.  Even if the hosts could reveal this information
   for some time to the future, the network would have to support
   multiple addresses for the same node.  One possible way to deal with

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

Internet-Draft             Manual SAs for ND                  March 2003

   this is to use stable addresses for link local messages and run IPsec
   tunnel mode to autoconfigure the temporary identifiers, and then use
   those for the end-to-end traffic.

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

Internet-Draft             Manual SAs for ND                  March 2003

7. Security Implications of Neighbor Discovery Messages

   In this chapter we discuss the security implications of either
   securing or not securing the link local messages.  In this analysis
   we will make a few alternative assumptions.  The first assumption is
   that all subsequent communications at a higher level are secured
   using e.g.  IPsec and IKE.  It can be argued that making this
   assumption is reasonable since higher level traffic can already very
   well be secured using existing mechanisms, and if security is of
   interest, these mechanisms should be used.  Note that this assumption
   has a number of consequences.  For instance, being able to redirect a
   message flow to an attacker does not really gain any information
   about the flow.

   In practice we can not always have secure higher layer
   communications.  First of all, because there is always some traffic
   that goes to public servers e.g.  on the Internet and it is not
   likely that we will have the trust and key infrastructure necessary
   to be able to communicate with everyone securely.  Secondly, even for
   other communications it may be that upper layer security does not
   exist for reasons of missing support in the involved nodes, lack of
   time to set these up properly, or performance.  Therefore, it also
   also necessary to study the security implications of the Neighbor
   Discovery messages in the case of insecure higher layers.

   The second set of alternative assumptions divides the tools the
   attacker has available in to two categories.  The weak attacker can
   do nothing more than eavesdrop other messages and inject forged
   messages.  The strong attacker can also block some or all messages.
   It is interesting to consider these two as separate, because strong
   measures such as jamming WLAN reception are likely to be detected and
   less likely to be available to large numbers of attackers, whereas
   the weak measures are easily available to anyone with standard
   hardware and software.

   We will use the following attacks to classify the dangers:

   o  Denial-of-Service.  For instance, being able to block all traffic
      to and from a node.

   o  Impersonation; the ability of the attacker to claim that it is the
      node at a particular IP address and not the real node.

   o  Spying; being able to read packets in transit.  In general, spying
      is always possible for the local traffic unless higher layer
      security is in place.

   o  Man-in-the-middle; being able to read and modify packets in

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

Internet-Draft             Manual SAs for ND                  March 2003

      transit.  In general, this is always possible on a local link for
      a strong attacker if there is no higher layer security.

   o  Identity selection; being able to have an effect to the IP address
      selection of a node.

7.1 Router Discovery

   First we deal with the secure higher layer assumption.  A weak
   attacker can make the network believe there are additional addresses
   and prefixes on the link, or that the route towards the Internet is
   on another router than it really is.  However, since hosts are
   required to detect when communication to a destination appears to be
   failing [5] they should be able to find the real router sooner or
   later.  Also, additional address prefixes should not cause any
   problems either, except in the case the attacker makes the host
   believe that a destination somewhere else is actually on the link.
   In this special case the result is a Denial-of-Service attack.

   Strong attackers can also hide prefixes and addresses and routers
   that really exist on the link.  As such, they can perform various
   kinds of Denial-of-Service attacks.

   In the case of insecure higher layers, even weak attackers can read
   and modify traffic contents towards remote destinations, or
   impersonate as something they are not.  For instance, if the weak
   attacker has control over a node outside the local link, he can
   tunnel all traffic he receives from himself to this outside node,
   resulting in a Man-in-the-Middle attack.  The situation may continue
   for an extended period of time, not allowing the nodes to find out
   the "real" router but diverting all traffic through the attacker.  A
   strong attacker can perform impersonation on the behalf of any node
   on the link by hiding the router advertisement with the correct
   prefix, and claiming to be a router towards the impersonated node.
   Reading and modification of local traffic is also possible using only
   router discovery messages through sending different router discovery
   messages to different nodes on the same network.

7.2 Address Resolution

   In the secure higher layer situation, weak attackers can cause a
   Denial-of-Service by making other nodes on the link believe that the
   node is in some other address than it really is on.

   Strong attackers can also prevent correct address resolution messages
   from being read by others, but the result of this is no worse than
   the Denial-of-Service already caused by the weak attacker.

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

Internet-Draft             Manual SAs for ND                  March 2003

   In the case of no security at higher layers, both weak and strong
   attackers can read traffic destined anywhere as well as impersonate
   other nodes and perform Man-in-the-Middle attacks.  Even weak
   attackers can fake address resolution messages by sending forged
   messages right after seeing the correct ones.

7.3 Duplicate Address Detection

   Regardless of the higher layer security situation, a weak attacker
   can easily forge messages that cause other nodes on the link to
   believe their addresses are duplicates.  This makes it impossible for
   them to communicate using these addresses, causing an all-out
   Denial-of-Service situation.

   Strong attackers can cause nodes to believe there is no duplicates
   when there is one in fact.  This will cause several problems later in
   the communication, in practice leading to a Denial-of-Service
   situation for all or most communication from the nodes.  On the other
   hand, if there really was a duplicate address situation they would
   not have been able to communicate in the first place.  Therefore, the
   strong attacker can not really cause any more damage than the weak

   When stateful address autoconfiguration is used, both weak and strong
   attackers can use the duplicate address detection procedure to
   artificially cause given addresses to fail; it may be possible to
   force a particular address to be selected by repeatedly blocking the
   use of certain addresses.

7.4 Address Autoconfiguration

   All attacks against the duplicate address detection and router
   discovery apply also here.

7.5 Neighbor Reachability Detection

   The weak attacker can only make a node believe that another node is
   up when in reality it is not.  This can be done by sending a forged
   answer to a reachability detection message.  This causes a weak form
   of a Denial-of-Service attack; the communications would not have
   succeeded anyway but now one node thinks that it can communicate with
   the other node.  Depending on what kind of communications is in
   question, this may imply either nothing or delay the attempt of the
   node to switch to an alternative communications partner.

   A strong attacker can also cause the reverse, i.e.  make a node
   believe that another node is down.  This results in a full
   Denial-of-Service attack.

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

Internet-Draft             Manual SAs for ND                  March 2003

7.6 Redirect

   At worst in the secure higher layer case, the attacker succeeds in a
   Denial-of-Service attack by either constructing a forged Redirect
   message or blocking a real Redirect message.  The latter action is
   only available to a strong attacker.

   In the case of insecure higher layer, any attacker can now reroute
   non-local traffic to itself, presenting additional opportunities for
   spying, impersonation and Man-in-the-Middle attacks.

7.7 Summary

   The following table summarizes the security effects of the link local
   control functions under different assumption.  In the table we have
   listed the additional dangers resulting e.g.  from an insecure
   address resolution function.  The table does not include dangers
   already inherent in the network otherwise, such as the obvious
   ability to read all traffic given insecure higher layer protocols.

   |           |     Secure higher layer   |   Insecure higher layer   |
   | Control   +-------------+-------------+-------------+-------------+
   | Function  |    Weak     |  Strong     |    Weak     |  Strong     |
   |           |   Attacker  | Attacker    |   Attacker  | Attacker    |
   | Router    | DoS(R)      | DoS         | DoS(R),Spy- | DoS, Spy,   |
   | Discovery |             |             | (R), Imp(R),| Imp,        |
   |           |             |             | MitM(R)     | MitM        |
   | Address   | DoS         | DoS         | DoS, Spy,   | DoS, Spy,   |
   | Resolution|             |             | Imp, MitM   | Imp, MitM   |
   |           |             |             |             |             |
   | Duplicate | DoS,        | DoS,        | DoS,        | DoS,        |
   | Address   | IDSel(Sf)   | IDSel(Sf)   | IDSel(Sf)   | IDSel(Sf)   |
   | Detection |             |             |             |             |
   | Address   | DoS,        | DoS,        | DoS,        | DoS,        |
   | Autoconfi-| IDSel(Sf)   | IDSel(Sf)   | IDSel(Sf)   | IDSel(Sf)   |
   | guration  |             |             |             |             |
   | Neighbor  | DoS(Pd)     | DoS         | DoS(Pd)     | DoS         |
   | Reachab.  |             |             |             |             |
   | Detection |             |             |             |             |
   | Redirect  | DoS(R)      | DoS(R)      | DoS(R),Spy- | DoS(R),Spy- |
   |           |             |             | (R), Imp(R),| (R), Imp(R),|

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

Internet-Draft             Manual SAs for ND                  March 2003

   |           |             |             | MitM(R)     | MitM(R)     |


   DoS    = Denial-of-Service
   Spy    = Listening in
   Imp    = Impersonation
   MitM   = Man-in-the-Middle
   IDSel  = Identity selection (forcing a particular IP address on a
   (R)    = This attack is only possible for traffic destined to hosts
            outside the local link
   (Sf)   = This attack is possible only with stateful address
   (Pd)   = Weak form; the attack only succeeds in hiding the fact that
            the other peer is down

   These results can be compared to the original situation for payload
   packets.  In there, weak attackers cannot perform any attacks if
   there is security at higher layers, but strong attackers succeed in
   Denial-of-Service.  If there is no security at higher layers, both
   weak and strong attackers also succeed in Denial-of-Service and can
   perform Spying, Impersonation and Man-in-the-Middle attacks.  In
   conclusion, the additional dangers resulting from the insecure
   control traffic are the following:

      Denial-of-Service for weak attackers under higher layer security.

      Man-in-the-Middle, Spying, and Impersonation for all attackers
      under no higher layer security.

      Identity selection in all situations, if stateful address
      autoconfiguration is used.

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

Internet-Draft             Manual SAs for ND                  March 2003

8. Approaches for Reducing Configuration Effort

   If the Neighbor Discovery messages need to be protected in a given
   environment, a number of security associations is needed.  One may
   question the feasibility of configuring very large networks in this
   manner.  There are possible remedies for this situation.  These
   include the following:

   o  Management tools exist at a higher level to create security
      associations for the link local traffic in an easy manner for the
      user, but several security associations would still be used on the
      wire.  This has the effect of removing the configuration problems
      for the user while still being able to use existing
      implementations as is.  However, resources such as memory must
      still be reserved for the security associations.

   o  A well-known SPI number could be reserved from the
      IANA-administered range (0-255) to stand for Neighbor Discovery
      protection.  In conjunction with this, the rules for processing
      incoming IPsec packets would have to be changed in order to ignore
      the destination address for this special SPI.  This has
      implications to existing implementations, and potentially even
      hardware-based packet matching and/or security association search.

      A fixed set of security association parameters must be used
      throughout the local network.  Obviously, replay protection can
      not be employed as several nodes use the same security
      associations.  It might be possible to use more than SPI number to
      enable the simultaneous use of several security associations
      during a manual key change period (such changes would typically be
      long-lasting since mobile nodes might easily be away from their
      home LAN for weeks).

      This approach has the advantage that it would enable the use of
      the address privacy extension [8] as the security associations
      could be configured without knowledge of the actual physical
      addresses and/or randomly generated temporary addresses.

   o  In conjunction with the above, an automatic change procedure could
      be designed to force the nodes to regularly update the local
      security association from a central server.  One of the routers on
      the link could act as the server.

   o  A unicast key management protocol and a group key management
      protocol would be used to create security associations for the
      Neighbor Discovery traffic.  It is not clear, however, if this is
      feasible.  Reference [11] already describes how IKE runs into
      chicken and egg problems in this area; and this is not simply a

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

Internet-Draft             Manual SAs for ND                  March 2003

      problem of IKE but rather a fundamental limitation in
      communications architecture.  Likewise, it is likely that
      multicast key management schemes such as those worked by the
      multicast key management WG in the IETF will run into similar

   o  A specific key management mechanism could be developed for
      Neighbor Discovery.  Such a protocol would run as a part of the
      ICMPv6 messages.  This seems to be a possible approach and ideas
      along this approach have been presented [12] and [9].  The
      protocol would have to handle both unicast and multicast key

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

Internet-Draft             Manual SAs for ND                  March 2003

9. Conclusions

   When payload packets are cryptographically protected,
   Denial-of-Service is the most serious attack ``weak attackers'' are
   able to mount on Neighbor Discovery.  When these messages are
   protected with IPsec as well, in the manner described in this
   document, these attacks can be prevented.  Against a ``strong
   attacker'', Denial-of-Service can not be prevented, for instance the
   whole radio link can be jammed.  However, such attacks are perhaps
   easier to detect than IP-layer attacks.

   Without security for payload packets, the situation is more serious
   and even weak attackers can perform various kinds of attacks,
   including Impersonation and Spying.  This is particularly dangerous
   as it is likely that at least some traffic on the Internet will
   remain unprotected well into the future.

   The Denial-of-Service and other attacks performed by outsiders can be
   solved with the use of IPsec.  In order to use IPsec, the security
   associations must be configured manually as described in this
   document.  A fair amount of configuration work is involved, and this
   scheme is generally possible only on a limited scale.  A more
   scalable method which requires IPsec extensions is described in [9].

   This work does not consider the authorization problems in Neighbor
   Discovery.  These are treated more in depth in [9] and [10].  The
   Neighbor Discovery protocol provides no mechanism to determine, which
   neighbors are authorized to send a particular type of message, e.g a
   Router Advertisement.  The current set of IPsec policy selectors do
   not allow us to define which nodes are allowed to send which
   particular Neighbor Discovery messages.  Furthermore, even if a
   particular node is authorized to send Neighbor Advertisements, it is
   usually authorized to send them only on its own behalf.  Thus, the
   presented mechanisms can not protect against attacks from the
   legitimate hosts in the same manner as is possible in [9].

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

Internet-Draft             Manual SAs for ND                  March 2003

Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Hinden, R. and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 2373, July 1998.

   [3]  Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

   [4]  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
        RFC 2409, November 1998.

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

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

   [7]  Conta, A. and S. Deering, "Internet Control Message Protocol
        (ICMPv6) for the Internet Protocol Version 6 (IPv6)
        Specification", RFC 2463, December 1998.

   [8]  Narten, T. and R. Draves, "Privacy Extensions for Stateless
        Address Autoconfiguration in IPv6", RFC 3041, January 2001.

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

Internet-Draft             Manual SAs for ND                  March 2003

Informative References

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

   [10]  Nikander, P., "IPv6 Neighbor Discovery trust models and
         threats", draft-ietf-send-psreq-00 (work in progress), October

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

   [12]  Nikander, P., "Denial-of-Service, Address Ownership, and Early
         Authentication in the IPv6 World", Proceedings of the Cambridge
         Security Protocols Workshop, April 2001.

Authors' Addresses

   Jari Arkko
   Jorvas  02420


   Pekka Nikander
   Jorvas  02420


   Tero Kivinen
   SSH Communications Security
   Fredrikinkatu 42
   Helsinki  00100


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

Internet-Draft             Manual SAs for ND                  March 2003

   Markku Rossi
   SSH Communications Security
   Fredrikinkatu 42
   Helsinki  00100


Arkko, et al.          Expires September 1, 2003               [Page 24]

Internet-Draft             Manual SAs for ND                  March 2003

Appendix A. Acknowledgements

   The authors would like that Erik Nordmark, James Kempf, Bill
   Sommerfeld, Gabriel Montenegro, Tuomas Aura, Mike Roe, and others for
   interesting discussions in this problem space.

Arkko, et al.          Expires September 1, 2003               [Page 25]

Internet-Draft             Manual SAs for ND                  March 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

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

   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

Arkko, et al.          Expires September 1, 2003               [Page 26]

Internet-Draft             Manual SAs for ND                  March 2003



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

Arkko, et al.          Expires September 1, 2003               [Page 27]