[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
IPv6 maintenance Working Group (6man)                            F. Gont
Internet-Draft                                    SI6 Networks / UTN-FRH
Updates: 4861 (if approved)                                    R. Bonica
Intended status: Standards Track                        Juniper Networks
Expires: August 18, 2014                                          W. Liu
                                                     Huawei Technologies
                                                       February 14, 2014


 Validation of Neighbor Discovery Source Link-Layer Address (SLLA) and
                Target Link-layer Address (TLLA) options
                 draft-gont-6man-lla-opt-validation-00

Abstract

   This memo documents two scenarios in which an on-link attacker emits
   a crafted IPv6 Neighbor Discovery (ND) packet that poisons its
   victim's neighbor cache.  In the first scenario, the attacker causes
   a victim to map a local IPv6 address to a local router's own link-
   layer address.  In the second scenario, the attacker causes the
   victim to map a unicast IP address to a link layer broadcast address.
   In both scenarios, the attacker can exploit the poisoned neighbor
   cache to perform a subsequent forwording-loop attack, thus
   potentially causing a Denial of Service.

   Finally, this memo specifies simple validations that the recipient of
   an ND message can execute in order to protect itself against the
   above-mentioned threats.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on August 18, 2014.






Gont, et al.             Expires August 18, 2014                [Page 1]


Internet-Draft       Validation of SLLA/TLLA options       February 2014


Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  ND-based Forwarding-Loop Attacks  . . . . . . . . . . . . . .   3
     3.1.  Mapping an IPv6 Address to a Local Router's Own Link-
           layer Address . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Mapping a Unicast IPv6 Address to A Broadcast Link-Layer
           Address . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Implications of Malicious Link-layer Address Options  . . . .   6
   5.  Validation Checks for the Source Link-Layer Address Option  .   7
   6.  Validation Checks for the Target Link-Layer Address Option  .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     10.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   IPv6 [RFC2460] nodes use a Neighbor Discovery (ND) [RFC4861]
   mechanism to discover on-link neighbors and learn their link layer
   addresses.  Having discovered an on-link neighbor and learned its
   link layer address, an IPv6 node stores that information in a local
   data structure, called the "neighbor cache".

   ND defines the following ICMPv6 [RFC4443] messages:

   o  Router Solicitation (RS)

   o  Router Advertisement (RA)



Gont, et al.             Expires August 18, 2014                [Page 2]


Internet-Draft       Validation of SLLA/TLLA options       February 2014


   o  Neighbor Solicitation (NS)

   o  Neighbor Advertisement (NA)

   o  Redirect

   ND also defines a Source Link-Layer Address (SLLA) option and a
   Target Link-Layer Address (TLLA) option.  The RS, RA, and NS messages
   all typically contain the SLLA option, that contains the link layer
   address of the node sending the message.  The NA and Redirect
   messages contain the TLLA option, that maps a target IPv6 address
   that is contained by the NA or Redirect message to a link layer
   address.

   This memo documents two scenarios in which an on-link attacker emits
   a crafted ND packet that poisons its victim's neighbor cache.  In the
   first scenario, the attacker causes a victim to map an IPv6 address
   to a the victim router's own link-layer address.  In the second
   scenario, the attacker causes the victim to map a unicast IP address
   to the link layer broadcast or multicast address.  In both scenarios,
   the attacker can subsequently exploit the poisoned neighbor cache to
   perform a forwording-loop attack, thus potentially causing a Denial
   of Service (DoS).

   Finally, this memo specifies simple validations that the recipient of
   an ND message can execute in order to protect itself against the
   above-mentioned threats.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  ND-based Forwarding-Loop Attacks

3.1.  Mapping an IPv6 Address to a Local Router's Own Link-layer Address














Gont, et al.             Expires August 18, 2014                [Page 3]


Internet-Draft       Validation of SLLA/TLLA options       February 2014


                         +----------+      +--------+
                    ...==| Router A |      | Host C |
                         +----------+      +--------+
                              ||               ||
                         =============================
                                  ||
                                  ||          Network 1
                             +----------+
                             | Attacker |
                             +----------+

                     Figure 1: Unicast Forwarding Loop

   In Figure 1, the Attacker sends Router A a crafted ND message.  The
   aforementioned ND message contains the Target Addres set to Host C's
   IPv6 address, and a TLLA option set to Router A's link-layer address.
   The ND message causes Router A to map Host C's IPv6 address to the
   link layer address of Router A's interface to Network 1.  This sets
   up the scenario for a subsequent attack.

   A packet is sent to Router A with the IPv6 Destination Address set to
   that of Host C. Router A forwards the packet on Network 1, specifying
   its own Network 1 interface as the link layer destination.  Because
   Router A specified itself as the link layer destination, Router A
   receives the packet and forwards it again.  This process repeats
   until the IPv6 Hop Limit is decremented to 0 (and hence the packet is
   discarded).  In this scenario, the amplification factor is equal to
   the Hop Limit minus one.

   An attacker can realize this attack by sending either of the
   following:

   o  An ND message whose SLLA maps an IPv6 address to the link layer
      address of the victim router's (Router A's in our case) interface
      to the local network (Network 1 in our case)

   o  An ND message whose TLLA maps an IPv6 address to the link layer
      address of the victim router's (Router A's in our case) interface
      to the local network (Network 1 in our case)

3.2.  Mapping a Unicast IPv6 Address to A Broadcast Link-Layer Address










Gont, et al.             Expires August 18, 2014                [Page 4]


Internet-Draft       Validation of SLLA/TLLA options       February 2014


             +----------+      +--------+         +----------+
             | Router A |      | Host C |         | Router B |
             +----------+      +--------+         +----------+
                  ||               ||                  ||
              =================================================
                                ||
                                ||
                           +----------+
                           | Attacker |
                           +----------+

                    Figure 2: Broadcast Forwarding Loop

   In Figure 2, the Attacker sends one crafted ND message to Router A,
   and one crafted ND message to Router B. Each crafted ND message
   contains the Target Addres set to Host C's IPv6 address, and a TLLA
   option set to the Ethernet broadcast address (ff:ff:ff:ff:ff:ff).
   These ND messages causes each router to map Host C's IPv6 address to
   the Ethernet broadcast address.  This sets up the scenario for a
   subsequent attack.

   Subsequently, the Attacker sends a packet to the Ethernet broadcast
   address (ff:ff:ff:ff:ff:ff), with an IPv6 Destination Address equal
   to the IPv6 address of Host C. Upon receipt, both Router A and Router
   C decrement the Hop Limit of the packet, and resend it to the
   Ethernet broadcast address.  As a result, both Router A and Router B
   receive two copies of the same packet (one sent by Router A, and
   another sent by Router B).  This would result in a "chain reaction"
   that would only disappear once the Hop Limit of each of the packets
   is decremented to 0.  The equation in Figure 3 describes the
   amplification factor for this scenario :

                                   HopLimit-1
                                      ---
                                      \          x
                         Packets =    /   Routers
                                      ---
                                      x=0

                  Figure 3: Maximum amplification factor

   This equation does not take into account ICMPv6 Redirect messages
   that each of the Routers could send, nor the possible ICMPv6 "time
   exceeded in transit" error messages that each of the routers could
   send to the Source Address of the packet when each of the "copies" of
   the original packet is discarded as a result of their Hop Limit being
   decremented to 0.




Gont, et al.             Expires August 18, 2014                [Page 5]


Internet-Draft       Validation of SLLA/TLLA options       February 2014


   An attacker can realize this attack by sending either of the
   following:

   o  An ND message whose SLLA maps an IPv6 address not belonging to the
      victim routers to the broadcast link-layer address

   o  An ND message whose TLLA maps an IPv6 address not belonging to the
      victim routers to the broadcast link-layer address

      NOTE: the IPv6 Destination Address of the attack packet should not
      belong to any of the victim routers, such that they forward the
      packet rather than "consume" it.

   An additional mitigation would be for routers to not forward IPv6
   packets on the same interface if the link-layer destination address
   of the received packet was a broadcast or multicast address.

4.  Implications of Malicious Link-layer Address Options

   If SLLA or TLLA options are allowed to contain broadcast (e.g., the
   IEEE 802 "ff:ff:ff:ff:ff:ff") or multicast (e.g., the IEEE 802
   "33:33:00:00:00:01") addresses, traffic directed to the corresponding
   IPv6 address would be sent to the broadcast or multicast address
   specified in the SLLA or TLLA option.  This could have multiple
   implications:

   o  It would have a negative impact on the performance of the nodes
      attached to the network and on the network itself, as packets sent
      to these addresses would need to be delivered to multiple nodes
      (and processed by them) unnecessarily.

   o  An attacker could easily capture traffic on a switched network,
      without the need to forward packets to their intended
      destinations, as the corresponding packets would be delivered to
      all (in the case of broadcast) or multiple (in the case of
      multicast) nodes.

   o  Packets could result in forwarding loops at routers, as a router
      forwarding a packet to the corresponding address would receive
      itself a copy of the forwarded packet.  The loop would end only
      when the Hop Limit is eventually decremented to 0.  The problem
      would be exacerbated if multiple routers are present on the same
      link.  Section 3 of this document contains further analysis of
      this vulnerability.

   Additionally, if SLLA or TLLA options are allowed to contain the
   receiving router's own link-layer address, the victim router would




Gont, et al.             Expires August 18, 2014                [Page 6]


Internet-Draft       Validation of SLLA/TLLA options       February 2014


   receive a copy of the very same packets it means to forward to other
   destinations.  This could have the following implications:

   o  It would have a negative impact on the performance of the victim
      router and of the network itself, as a single packet would be sent
      multiple times (up to 255) on the local network, thus serving as
      an amplification vector.

5.  Validation Checks for the Source Link-Layer Address Option

   The Source link-layer address option contains the link-layer address
   of the sender of the packet.  It is used by Neighbor Solicitation,
   Router Solicitation, and Router Advertisement messages.

   The following figure illustrates the syntax of the source link-layer
   address:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |    Link-Layer Address ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 4: ND Source link-layer address option

   The Type field is set to 1.  The Length field specifies the length of
   the option (including the Type and Length octets) in units of 8
   octets.  A node that receives an ICMPv6 message with this option MUST
   verify that the Length field is valid for the underlying link layer.
   For example, for IEEE 802 addresses the Length field MUST be 1
   [RFC2464].  If the packet does not pass this check, it MUST be
   silently dropped.

      NOTE: The Link-Layer Address field contains the link-layer
      address.  The length, contents, and format of this field varies
      from one link layer to another, and is specified in specific
      documents that describes how IPv6 operates over different link
      layers.

   Additionally, the SLLA option MUST NOT not contain a broadcast or
   multicast address.  If the option does not pass this check, the
   Neighbor Discovery message carrying the option MUST be discarded.
   Finally, nodes MUST NOT allow the SLLA option to contain one of the
   receiving node's link-layer addresses.  If the option does not pass
   this check, the Neighbor Discovery message carrying the option MUST
   discarded.





Gont, et al.             Expires August 18, 2014                [Page 7]


Internet-Draft       Validation of SLLA/TLLA options       February 2014


6.  Validation Checks for the Target Link-Layer Address Option

   The Target link-layer address option contains the link-layer address
   of the Target of the packet.  It is used by Neighbor Advertisement
   and Redirect messages.

   The following figure illustrates the syntax of the Target link-layer
   address:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |    Link-Layer Address ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 5: ND Target link-layer address option format

   The Type field is set to 2.  The Length field specifies the length of
   the option (including the Type and Length octets) in units of 8
   octets.  A node that receives a ND message with this option MUST
   verify that the Length field is valid for the underlying link-layer.
   For example, for IEEE 802 addresses the Length field MUST be 1
   [RFC2464].  If the packet does not pass this check, it MUST be
   silently dropped.

   A node that receives a ND message with this option MUST verify that
   the Length field is valid for the underlying link layer.  For
   example, for IEEE 802 addresses the Length field MUST be 1 [RFC2464].
   If the packet does not pass this check, it MUST be silently dropped.

   The TLLA option MUST NOT not contain a broadcast or multicast
   address.  If the option does not pass this check, the Neighbor
   Discovery message carrying the option MUST be discarded.  Finally,
   nodes MUST NOT allow the source link-layer address to contain one of
   the receiving node's link-layer addresses.  If the option does not
   pass this check, the Neighbor Discovery message carrying the option
   MUST discarded.

7.  IANA Considerations

   There are no IANA registries within this document.  The RFC-Editor
   can remove this section before publication of this document as an
   RFC.








Gont, et al.             Expires August 18, 2014                [Page 8]


Internet-Draft       Validation of SLLA/TLLA options       February 2014


8.  Security Considerations

   This document discusses how the Neighbor DIscovery SLLA and TLLA
   options can be leveraged to perform a number of attacks, and
   specifies sanity checks to be enforced by Neighbor Discovery
   implementations, such that these vulnerabilities are eliminated.

9.  Acknowledgements

   This document is based on the technical report "Security Assessment
   of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by
   Fernando Gont on behalf of the UK Centre for the Protection of
   National Infrastructure (CPNI).

10.  References

10.1.  Normative References

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

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, December 1998.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

10.2.  Informative References

   [CPNI-IPv6]
              Gont, F., "Security Assessment of the Internet Protocol
              version 6 (IPv6)", UK Centre for the Protection of
              National Infrastructure, (available on request).

Authors' Addresses








Gont, et al.             Expires August 18, 2014                [Page 9]


Internet-Draft       Validation of SLLA/TLLA options       February 2014


   Fernando Gont
   SI6 Networks / UTN-FRH
   Evaristo Carriego 2644
   Haedo, Provincia de Buenos Aires  1706
   Argentina

   Phone: +54 11 4650 8472
   Email: fgont@si6networks.com
   URI:   http://www.si6networks.com


   Ronald P. Bonica
   Juniper Networks
   2251 Corporate Park Drive
   Herndon, VA  20171
   US

   Phone: 571 250 5819
   Email: rbonica@juniper.net


   Will (Shucheng) Liu
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Email: liushucheng@huawei.com























Gont, et al.             Expires August 18, 2014               [Page 10]