Network Working Group                                       Jari Arkko
     INTERNET-DRAFT                                          Pekka Nikander
     Category: Standards Track                                     Ericsson
     <draft-arkko-manual-icmpv6-sas-01.txt>                    Tero Kivinen
     23 June 2002                                              Markku Rossi
                                                SSH Communications Security
     
     
     
              Manual SA Configuration for IPv6 Link Local Messages
     
     
     1.  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 docu¡
     ments  of  the  Internet Engineering Task Force (IETF), its areas, and
     its working groups.  Note that other groups may also distribute  work¡
     ing documents as Internet-Drafts.
     
     Internet-Drafts  are draft documents valid for a maximum of six months
     and may be updated, replaced, or made obsolete 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   may    be    found    at
     http://www.ietf.org/ietf/1id-abstracts.txt
     
     The  list  of  Internet-Draft  Shadow  Directories  may  be  found  at
     http://www.ietf.org/shadow.html.
     
     The distribution of this memo is unlimited.  It is  filed  as  <draft-
     arkko-manual-icmpv6-sas-00.txt>,  and  expires August 1, 2001.  Please
     send comments to the author or to  IPsec  and/or  IPNG  working  group
     mailing lists.
     
     2.  Abstract
     
     This  draft discusses the use of manually configured IPsec SAs to pro¡
     tect ICMPv6 messages such as router discovery and  address  resolution
     on  the  local  link. IPsec SAs are generally identified by the triple
     <SPI, destination address, protocol>. For the ICMPv6 messages  config¡
     uring  the SAs requires some effort, however, since there are multiple
     known destination addresses plus a number of addresses that depend  on
     the physical link addresses.  This draft describes the security impli¡
     cations of protecting or not protecting the  link  local  ICMPv6  mes¡
     sages,  lists  the SAs that must be configured manually, and discusses
     some approaches for reducing configuration effort.
     
     3.  Introduction
     
     IPv6 architecture makes it possible to secure  all  IP  packets  using
     IPsec  [6],  even  control  messages  and even to multicast addresses.
     IPsec architecture has a Security Policy Database that specifies which
     
     
     
     Arkko et al                                                   [Page 1]


     INTERNET-DRAFT            Manual ICMPv6 SAs               23 June 2002
     
     
     traffic is protected, and how.
     
     The  control message protocol for IPv6, ICMPv6 [3], contains many mes¡
     sages that are intended to be used for router discovery, address reso¡
     lution,  and other tasks on the local LAN link. As described elsewhere
     [4], dynamically negotiated SAs cannot be used to protect  these  mes¡
     sages  as  the  negotiation would already require the messages to have
     been exchanged. Instead, manually configured SAs must  be  used.  How¡
     ever,  setting  up  these SA is not easy. This draft lists those fixed
     multicast,  node  addresses,  and  node  address  dependent  multicast
     addresses  for which the SAs must be created. We will also discuss the
     security implications of the link local ICMPv6 messages under  various
     assumptions  of  attacker capabilities. Finally, we discuss approaches
     that can be used to reduce configuration work in setting up the manual
     SAs.  These  approaches  include configuration tools, the use of well-
     known SPI numbers with special treatment, and new protocols.
     
     This draft is a re-submission of an earlier Internet Draft  from  Jan¡
     uary  2001.   It is intended as an input paper for the Secure Neighbor
     Discovery (SEND) BOF.
     
     4.  Nature of the Addresses
     
     ICMPv6 messages are sent using various kinds of source and destination
     address  types.  As  the destination address is used to find the right
     SA, the nature of the destination address is of relevance  here.   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. While many ICMPv6 messages use multi¡
     cast addresses most of the time, some also use unicast addresses some¡
     times.  For  instance, the Neighbour Solicitation messages are usually
     sent to multicast addresses, but the Neighbour Advertisement  messages
     are  also  sent to unicast addresses when sent as a response to a node
     that has an address.
     
     Unfortunately, the ICMPv6 specifications do not always use  very  spe¡
     cific  language when talking about the possible forms of addresses for
     the messages. The word  "typically"  is  often  used  to  describe  an
     address  that  would  most logically be used for a particular message,
     but a question remains whether other addresses could be used  in  some
     situations or in some implementations.
     
     5.  ICMPv6 Tasks
     
     In  IPv6,  ICMP  has  several tasks, and many of these tasks are over¡
     loaded on a few central message types such as the Neighbour  Discovery
     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 SA protec¡
     tion is relevant, i.e., which cannot be protected using IKE-based  [7]
     SAs according to [4].
     
     
     
     
     
     
     Arkko et al                                                   [Page 2]


     INTERNET-DRAFT            Manual ICMPv6 SAs               23 June 2002
     
     
     5.1.  Router and Prefix Discovery
     
     Router  and prefix discovery is a part of the Neighbour Discovery pro¡
     tocol [1], which in turn is a part of the ICMPv6.  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 informa¡
     tion is necessary in order to know whether a packet should be sent  to
     a  router  or to the destination directly. Typically, address autocon¡
     figuration and other tasks can't 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 [1]. This mes¡
     sage 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
     [1]. Like the solicitation message, the advertisement is also local to
     the link only.
     
     5.2.  Address Autoconfiguration
     
     Address  autoconfiguration  is another part of the Neighbour Discovery
     protocol [1, 2]. It's purpose is to automatically assign addresses  to
     interfaces. It comes in two variants, stateless and statefull. In this
     document we consider only the stateless autoconfiguration aspects.
     
     The Neighbour Solicitation and Advertisement  messages  are  used  for
     this  purpose, among other things. Furthermore, Router and Prefix Dis¡
     covery and Duplicate Address Detection have an effect to  the  Address
     Autoconfiguration tasks.
     
     The  Neighbour  Solicitation message has ICMPv6 type 135. The destina¡
     tion address is either the solicited node multicast  address,  unicast
     address,  or  an  anycast  address  [1, 3]. Neighbour Solicitation and
     Advertisement messages are used for multiple purposes:  address  auto¡
     configuration,  duplicate  address  detection, and reachability detec¡
     tion. In all these roles they are link local.
     
     The Neighbour Advertisement type is 136. The the  destination  address
     is  either  a  unicast address or the All Nodes multicast address [1].
     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 [2]. This procedure uses the same messages as the  Neighbour
     Discovery protocol [1]. Since the rules outlined in [2] forbid the use
     of an address for both sending and receiving packets until it has been
     
     
     
     Arkko et al                                                   [Page 3]


     INTERNET-DRAFT            Manual ICMPv6 SAs               23 June 2002
     
     
     found unique, no higher layer traffic is possible until this procedure
     has completed.
     
     The Neighbour 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 [1].  Again,
     no  higher  level traffic can proceed until the sender knows the hard¡
     ware address of the destination or the next hop router.
     
     The Neighbour 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 Neighbour Unreachability procedure, which is a part of the  Neigh¡
     bour  Discovery  protocol  [1]. No higher level traffic can proceed if
     this procedure flushes out  neighbour  cache  entries  after  (perhaps
     incorrectly) determining that the peer is not reachable.
     
     The  Neighbour  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 [1]. It is a part of the
     Neighbour Discovery protocol. As routers forward packets 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 Redi¡
     rect [1]. Rules in [5] dictate that unspecified, anycast, or multicast
     addresses may not be used as source addresses. Therefore, the destina¡
     tion  address  will always be a unicast address.  This message is only
     used for link local purposes, not for end-to-end communications.
     
     6.  Recommendation for manual SA setup
     
     As  described  above,  ICMPv6  uses  as  destination  address  unicast
     addresses,  known multicast addresses, and a set of computed multicast
     addresses (based on the physical link addresses). On a given link, the
     following SAs are required if all ICMPv6 traffic is to be secured with
     IPsec:
     
     (1) All Nodes multicast address FF02:0:0:0:0:0:0:1 [5].
     
     
     
     
     
     Arkko et al                                                   [Page 4]


     INTERNET-DRAFT            Manual ICMPv6 SAs               23 June 2002
     
     
     (2) All Routers multicast address FF02:0:0:0:0:0:0:1 [5].
     
     (3) For each node on the network, the Solicited Node multicast address
     FF02:0:0:0:0:1:FFXX:XXXX  [5].  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, the unicast address of that node.
     
     (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) SAs where N is the  num¡
     ber of nodes in the network and M is the number of addresses each node
     has. Table 1 below tabulates the number of SAs required as a  function
     of the number of nodes in the network:
     
     +--------------+-------------+-------------+
     | # 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
     
     
     
     Arkko et al                                                   [Page 5]


     INTERNET-DRAFT            Manual ICMPv6 SAs               23 June 2002
     
     
     necessarily know the addresses itself but they are rather specified in
     the  set  of  router advertisements received.  These things complicate
     the setup but is similar to the requirement that the keys can be  con¡
     figured  manually for all of these nodes; it isn't possible to provide
     security and at the same time allow previously unknown  nodes  to  the
     system when manual keying is used.
     
     Note that if the privacy extension [9] is used for address autoconfig¡
     uration, it may not be possible to know the physical  address  identi¡
     fiers.  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 this is to use sta¡
     ble 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.
     
     7.  Security Implications of Link Local Messages
     
     In this chapter we discuss the security implications of either  secur¡
     ing 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  rea¡
     sonable  since higher level traffic is already very well secured using
     existing mechanisms, and if security is of interest, these  mechanisms
     should  be  used.   Note  that  this assumption has a number of conse¡
     quences.  For instance, being able to redirect a message  flow  to  an
     attacker doesn't 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  secu¡
     rity  implications  of the link local messages in the case of insecure
     higher layers.
     
     The second set of alternative assumptions is dividing  the  tools  the
     attacker  has  available  in  two categories. The weak attacker can do
     nothing more than to inject forged messages. The strong  attacker  can
     also  block messages, or the whole link. 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:
     
     -  Denial-of-Service, e.g. being able to block all traffic to and from
     a node.
     
     
     
     
     Arkko et al                                                   [Page 6]


     INTERNET-DRAFT            Manual ICMPv6 SAs               23 June 2002
     
     
     - Impersonation, i.e. the ability of the attacker to claim that it  is
     the node at a particular IP address and not the real node.
     
     -  Spying i.e. being able to read packets in transit. In general, spy¡
     ing is always possible for the local traffic unless higher layer secu¡
     rity is in place.
     
     -  Man-in-the-middle  i.e.  being  able  to read and modify packets in
     transit. In general, this is always possible on a  local  link  for  a
     strong attacker if there is no higher layer security.
     
     -  Identity  selection  i.e.  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
     the  other router than it really is. However, since hosts are required
     to detect when communication to a destination appears  to  be  failing
     [1] they should be able to find the real router sooner or later. Also,
     additional address  prefixes  shouldn't  cause  any  problems  either,
     except in the case the attacker makes the host believe that a destina¡
     tion 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  imperson¡
     ate  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 per¡
     form 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
     
     
     
     Arkko et al                                                   [Page 7]


     INTERNET-DRAFT            Manual ICMPv6 SAs               23 June 2002
     
     
     Denial-of-Service already caused by the weak attacker.
     
     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  attack¡
     ers  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-Ser¡
     vice 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  situa¡
     tion  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't really cause any more damage than the weak one.
     
     When statefull address autoconfiguration is used, both weak and strong
     attackers can use the duplicate address detection procedure to artifi¡
     cially 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 discov¡
     ery apply also here.
     
     7.5.  Neighbour Reachability Detection
     
     The weak attacker can only make a node believe that another node is up
     when in reality it isn't. 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.
     
     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
     
     
     
     Arkko et al                                                   [Page 8]


     INTERNET-DRAFT            Manual ICMPv6 SAs               23 June 2002
     
     
     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 inher¡
     ent  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(R)| DoS, Spy     |
     | Discovery   |              |              | 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    |              |              |              |              |
     +-------------+-----------------------------+-----------------------------+
     | Neighbour   | DoS(Pd)      | DoS          | DoS(Pd)      | DoS          |
     | Reachability|              |              |              |              |
     | Detection   |              |              |              |              |
     +-------------+-----------------------------+-----------------------------+
     | Redirect    | DoS(R)       | DoS(R)       | DoS(R)       | DoS(R),      |
     |             |              |              | Spy(R),Imp(R)| Spy(R),Imp(R)|
     |             |              |              | MitM(R)      | MitM(R)      |
     +-------------+-----------------------------+-----------------------------+
     
     Notation:
     
     DoS    = Denial-of-Service
     Spy    = Listening in
     Imp    = Impersonation
     MitM   = Man-in-the-Middle
     IDSel  = Identity selection (forcing a particular IP address on a host)
     
     
     
     Arkko et al                                                   [Page 9]


     INTERNET-DRAFT            Manual ICMPv6 SAs               23 June 2002
     
     
     (R)    = This attack is only possible for traffic destined to hosts outside
              the local link
     (Sf)   = This attack is possible only with statefull address autoconfiguration
     (Pd)   = Weak form; the attack only succeeds in hiding the fact that the other
              peer is down
     
     
     These results can be compared to the base situation for payload  pack¡
     ets.  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 statefull address  autocon¡
     figuration is used.
     
     8.  Approaches for Reducing Configuration Effort
     
     If  security  implications  of  leaving ICMPv6 messages are considered
     unacceptable, one may question the  feasibility  of  configuring  very
     large  networks  with manual SAs. There are possible remedies for this
     situation. These include the following:
     
     (1) Management tools exist at a higher level to  create  SAs  for  the
     link  local  traffic  in  an easy manner for the user, but several SAs
     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 SAs.
     
     (2)  A  well-known SPI number could be reserved from the IANA-adminis¡
     tered range (0-255) to signify link local message protection. In  con¡
     junction  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 implementa¡
     tions, and potentially even hardware-based packet matching  and/or  SA
     search.
     
     A  fixed  set  of SA parameters must be used throughout the local net¡
     work. Obviously, replay protection can't be employed as several  nodes
     use  the same SAs. It might be possible to use more than SPI number to
     enable the simultaneous use of several SAs during a manual key  change
     period  (such  changes would typically be long-lasting since e.g. lap¡
     tops might easily be away from their home LAN for weeks).
     
     
     
     
     
     Arkko et al                                                  [Page 10]


     INTERNET-DRAFT            Manual ICMPv6 SAs               23 June 2002
     
     
     This approach has the advantage that it would enable the  use  of  the
     address  privacy  extension [9] as the SAs could be configured without
     knowledge of the actual physical addresses and/or  randomly  generated
     temporary addresses.
     
     (3) In conjunction with the above, an automatic change procedure could
     be designed to force the nodes to regularly update the local SA from a
     central  server.   One  of  the  routers  on the link could act as the
     server.  A set of SPIs would be required in order to maintain at least
     two SAs while a key change is in progress.
     
     One  way  to provide such an automatic procedure is to use unprotected
     communications to find the local DHCP server, establish an IKE connec¡
     tion  to  it,  and  then  request  for 'local SA data' from the server
     through the created IPsec SA. This approach requires the server to  be
     able to negotiate IPsec SAs with clients having the undefined address.
     This seems to be possible, given that DHCP servers also  are  able  to
     respond  to  the  undefined  address  through replying to the physical
     address.  The use of IKE in this context would be beneficial, since it
     contains  facilities  for certificate-based authentication, making the
     setting up of a set of nodes for a  network  easier.  Separate  shared
     secrets  for  each node do not scale well, and the use of group shared
     key has both security drawbacks and is hard to  handle  in  situations
     where some of the nodes are away for long times.
     
     Since  at  boot  stage the finding of the server would have to be done
     through unprotected communications, the clients should try  to  estab¡
     lish  IKE  and  DHCP with all responding routers, in case attackers on
     the link try to perform a Denial-of-Service attack by responding  with
     fake router addresses.
     
     (4)  A unicast key management protocol and a group key management pro¡
     tocol would be used to create SAs for the  ICMPv6  traffic.  It  isn't
     clear,  however,  if this is feasible. Reference [4] already describes
     how IKE runs into chicken and egg problems in this area; and  this  is
     not  simply  a  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 manage¡
     ment WG in the IETF will run into similar problems.
     
     (5) An ICMPv6-level key management protocol would be developed. Such a
     protocol  would  run  as  a  part  of the ICMPv6 operations using e.g.
     physical link addresses to exchange packets,  and  would  not  require
     passing  through  the  rest of the ICMPv6 processes before any contact
     could be established. This seems to be a possible approach  and  ideas
     along  this approach have been presented [8, 10], though most propably
     the result would quite complex. The protocol would have to handle both
     unicast and multicast key management.
     
     9.  Conclusions
     
     When  payload traffic packets are protected e.g. using IPsec, the most
     serious attacks ``weak attackers'' are able  to  mount  on  IPv6  link
     local   control   message  result  in  Denial-of-Service.  When  these
     
     
     
     Arkko et al                                                  [Page 11]


     INTERNET-DRAFT            Manual ICMPv6 SAs               23 June 2002
     
     
     messages, too, are protected with IPsec in  the  manner  described  in
     this  draft,  these  attacks  can  be  prevented.  Against  a ``strong
     attacker'', Denial-of-Service can not be  prevented,  as  he  can  for
     instance  jam the whole link. However, such attacks are perhaps a lit¡
     tle bit easier to detect. 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 particu¡
     larly  dangerous  as  it  is  likely that at least some traffic on the
     Internet will remain unprocted well into the future.
     
     The Denial-of-Service and other attacks can be solved with the use  of
     IPsec  on the link local messages. In order to use IPsec, the SAs must
     be configured manually as described in this draft. A  fair  amount  of
     configuration  work is involved.  If smaller amount of work is desired
     some of the advanced schemes listed in this draft could  be  employed,
     though some schemes would have an effect to existing IPsec implementa¡
     tions. In view of the  relatively  small  security  impacts  of  using
     unprotected  link  local  messages, it is perhaps best to use the most
     simple methods.  However,  scalable  local  link  key  management  may
     require the use of certificate based authentication.
     
     This  work  does  not  consider the authorization problems in Neighbor
     Discovery. These are treated more in depth in [10].  The  ND  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 ND messages.   Furthermore,
     even  if  a  particular node is authorized to send Neighbor Advertise¡
     ments, it is usually authorized to send them only on its own behalf.
     
     10.  References
     
     [1] T. Narten, E. Nordmark, W. Simpson "Neighbor Discovery for IP Ver¡
     sion  6  (IPv6)" RFC 2461, IBM, Sun Microsystems, Daydreamer, December
     1998.
     
     [2] S. Thomson, T. Narten "IPv6 Stateless  Address  Autoconfiguration"
     RFC 2462, Bellcore, IBM, December 1998.
     
     [3]  A.  Conta, S. Deering "Internet Control Message Protocol (ICMPv6)
     for the Internet Protocol Version 6 (IPv6)  Specification"  RFC  2463,
     Lucent, Cisco Systems, December 1998.
     
     [4]  J.  Arkko  "Effects  of ICMPv6 on IKE and IPsec Policies", draft-
     arkko-icmpv6-ike-effects-00.txt, Work In Progress, IETF, January 2001.
     
     [5]  R. Hinden, S. Deering "IP Version 6 Addressing Architecture", RFC
     2373, Ipsilon Networks, Xerox PARC, July 1998.
     
     [6]  S. Kent, R. Atkinson "Security Architecture for the Internet Pro¡
     tocol" RFC 2401, BBN Corp, @Home Network, November 1998.
     
     [7]   D.  Harkins and D. Carrel "The Internet Key Exchange", RFC 2409,
     Cisco Systems, November 1998.
     
     
     
     Arkko et al                                                  [Page 12]


     INTERNET-DRAFT            Manual ICMPv6 SAs               23 June 2002
     
     
     [8] P.  Nikander  "Denial-of-Service,  Address  Ownership,  and  Early
     Authentication  in  the  IPv6  World",  Work In Progress, Ericsson, to
     appear, 2001.
     
     [9] T. Narten, R. Draves "Privacy  Extensions  for  Stateless  Address
     Autoconfiguration in IPv6", RFC 3041, IBM, Microsoft Research, January
     2001.
     
     [10] J. Arkko, P. Nikander, V.-M. Mantyla "Securing IPv6 Neighbor Dis¡
     covery  Using  Cryptographically  Generated Addresses (CGAs)", Work In
     Progress, June 2002.
     
     11.  Acknowledgements
     
     The authors would like that Erik Nordmark, James Kempf,  Bill  Sommer¡
     feld, Gabriel Montenegro, Tuomas Aura, Mike Roe, and others for inter¡
     esting discussions in this problem space.
     
     12.  Author's Address
     
     Jari Arkko
     Oy LM Ericsson Ab
     02420 Jorvas
     Finland
     E-mail: Jari.Arkko@ericsson.com
     
     Tero Kivinen
     SSH Communications Security Corp
     Fredrikinkatu 42
     FIN-00100 HELSINKI
     Finland
     E-mail: kivinen@ssh.fi
     
     Pekka Nikander
     Oy LM Ericsson Ab
     02420 Jorvas
     Finland
     E-mail: Pekka.Nikander@nomadiclab.com
     
     Markku Rossi
     SSH Communications Security Corp
     Fredrikinkatu 42
     FIN-00100 HELSINKI
     Finland
     E-mail: mtr@ssh.fi
     
     
     
     
     
     
     
     
     
     
     
     
     Arkko et al                                                  [Page 13]