Internet DRAFT - draft-gont-6man-lla-opt-validation
draft-gont-6man-lla-opt-validation
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]
