Indefensible Neighbor Discovery
draft-jaeggli-v6ops-indefensible-nd-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Joel Jaeggli | ||
| Last updated | 2018-06-25 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jaeggli-v6ops-indefensible-nd-00
v6ops J. Jaeggli
Internet-Draft Fastly
Intended status: Informational June 24, 2018
Expires: December 26, 2018
Indefensible Neighbor Discovery
draft-jaeggli-v6ops-indefensible-nd-00
Abstract
NDP resource exhastion is a problem which cannot fundamently be
addressed through limited protocol changes or implementation tweaks;
mitigations proposed in RFC 6583 [RFC6583] may well prevent the
outright failure of a device under durress. This draft discusses
some mitigations which have or can be employeed by networks looking
to reduce or eliminate the exposure of the Neighbor Discovery
Process.
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 https://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 December 26, 2018.
Copyright Notice
Copyright (c) 2018 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
(https://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
Jaeggli Expires December 26, 2018 [Page 1]
Internet-Draft IND June 2018
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. ND under stress . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Ways in which resources are consumed: . . . . . . . . . . 3
3. Mitigations . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. RFC 6583 . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Link-Local . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. RFC 6164 . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 4
3.5. Subnetting . . . . . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Neighbor discovery serves to allow the discovery of hosts and the
self assignment of resources within the sparse address space of IPv6
subnets. Since the definition of Interface IDs and accompanying
subnet sizes RFC 1885 [RFC1885] the potential has existed for the
forwarding and control plane resources of a router to be greatly
exceeded by locally or remotely triggered attempts to desocver
connected neighbors. The problem of the number of adjacencies that
can reasonably be supported and signaled in not unique to IPv6 though
it is especially accute there. It also exists in IPv4 as well as
other non-internet protocols. Practical scaling limits of the number
of adjaciences or amount of signaling serve as incentives for
operators to limit the size and number of participants in layer-2
domains.
Because of the size of typical IPv6 Interface IDs as well as the
property of self-assignment, IPv6 subnets and connected devices are
particularly exposed to resource consumption; therefore proactive
mitigations are required to limit the potential for resource
consumption resulting in Denial of Service. In RFC 6583 [RFC6583],
we detailed the threat posed by neighbor discovery resource
consumption to network devices as well as some mitigations which
could improve the situation. While some mitigations remove the
threat entirely; RFC 6164 [RFC6164] style /127 prefixes for example
Jaeggli Expires December 26, 2018 [Page 2]
Internet-Draft IND June 2018
are not subject to ND attacks, they have the property of not being
practical for subnets supporting end systems. Practical mitigations
in RFC 6583 section 7 [RFC6583] implementation advice serve to tamp
down, but cannot entirely eliminate the threat of resource
exhaustion; devices operating under durress cannot be expected to
perform as well as devices which are not.
1.1. Requirements Language
This document does not employ and should not interpreted through RFC
2119 [RFC2119] requirements language.
2. ND under stress
In characterizing the behavior of devices under stress we posit that
the neighbor discovery process responsible for resolving an
effectively unlimited number of unknown neighbors itself is
ultimately indefensible. By Indefensible we mean that if implemented
as intended by 4861 the protocol is always exposed to resource
consumption constraints that require mitigation.
2.1. Ways in which resources are consumed:
o Host-routes / Negative cache entries - IPv6 subnets do not have
constraints on the number of addresses which can be employed
within the limit (64 bits) imposed by the subnet mask. Networks
employing stateful DHCP v6 address assignment can make some
assumptions about the number of host to address mappings they are
willing to support, devices performing SLAAC and deriving
addresses subsequently are under no such constraints.
o CPU / RAM - Neighbor Discovery is intended to be triggered for
addresses for which no layer-2 next-hop yet exists. This allows
for the classical DDOS of the ND process described in RFC 3756
[RFC3756]. Since the senders of packets which might trigger ND
are not subject to the same constraints as devices which have to
initiate it this asymmetry is trivial to exercise.
o Multicast - Multicast replication of Neighbor solicitations may be
expensive for certain link-layers or hosts particularly wireless
networks. In cases where multicast is transmitted at lower rates
then the prevailing unicast rate, performance of other traffic may
be directly impacted by the presence of this traffic even at
relatively low levels (draft-perkins-intarea-multicast-ieee802-03
[draft-perkins-intarea-multicast-ieee802-03]).
Jaeggli Expires December 26, 2018 [Page 3]
Internet-Draft IND June 2018
3. Mitigations
Recognition of the short-comings of IPv6 neighbor discovery are
sufficiently common that link-layers supporting resource constrained
infrastructure typically have to address them directly, 6LowPAN for
example has RFC 6775 [RFC6775].
There are various forms of mitigation which can be applied in order
to avoid having neighbor discovery become the ineluctable bottleneck
in defending a subnet. Many of these approaches are more specially
changes to harden networks or transfer the burden of state rather
than alterations of the neighbor discovery process itself.
3.1. RFC 6583
RFC 6583 [RFC6583] suggests some practical mitigations, which can
reduce the extent to which ND fails but not eliminate it.
3.2. Link-Local
RFC 7404 [RFC7404](Using Only Link-Local Addressing inside an IPv6
Network) style approaches, link-local-only numbered interfaces make
it impossible to target the subnet address from off-link, at the cost
of limiting the ability to ping interfaces, return useful interface
IPs in traceroute and so on.
Link-local-only addressing may be extended to Hosts by assigning
unicast addressees on loopback interfaces rather than on subnet
connected interfaces. In conjunction with routing (typically BGP but
alternatives are possible), it is possible to construct networks in
which no external targeting of neighbor discovery on connected
subnets is possible. The existence of a prefix of arbitrary length
is signaled in a routing protocol. Probes addressed to unused
addresses may be discarded by an aggregate route.
3.3. RFC 6164
RFC 6164 [RFC6164] uses /127s allows for the use of /127s for inter-
router links. This effectively precludes ND exhaustion attempts for
point to point links.
3.4. Firewalls
Stateful inspection firewalls may limit the expense of performing
neighbor discovering for unknown addresses by discarding packets for
unestablished connections. While this may be a transfer of expense
from one account (ND) to another (firewall) it never-the-less
precludes targeting subnets for NDP exhaustion.
Jaeggli Expires December 26, 2018 [Page 4]
Internet-Draft IND June 2018
3.5. Subnetting
Sizing subnets effectively to support the number of hosts present
does limit the scope for ND exhaustion attacks. RFC 7608 [RFC7608]
does instruct that devices be able to forward to arbitrary length
subnets. Arbitrary length subnets e.g. a /120 or /121 are presently
considered incompatible with SLAAC and conflict with some goals for
privacy address RFC 4941 [RFC4941]. In the draft draft-bourbaki-
6man-classless-ipv6-03 [draft-bourbaki-6man-classless-ipv6-03] is a
proposal to eliminate the expectation of fixed length subnetting.
Alternative to resizing the subnet, stateful DHCPv6 address
assignment can be used to limit the range of IPs within a /64 subnet
which are consumed which may be used to ACL to target sub-prefixes of
the entire subnet.
4. Acknowledgements
This Document is entirely depedent on previous work done in the IETF
community and other authors.
5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
All drafts are required to have a security considerations section.
This document is essentially a collection of related security
considerations, it is hoped that by exploring these issues somce
insight into the rational and methodology for mitigating the exposure
posed by ND ay be gained. Some methods considered here are currently
and may remain non-standard.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
7.2. Informative References
Jaeggli Expires December 26, 2018 [Page 5]
Internet-Draft IND June 2018
[draft-bourbaki-6man-classless-ipv6-03]
Nicholas Bourbaki, "Classes IPv6", 2018,
<https://tools.ietf.org/html/
draft-bourbaki-6man-classless-ipv6-03>.
[draft-perkins-intarea-multicast-ieee802-03]
Perkins, C., "Multicast Considerations over IEEE 802
Wireless Media", 2018, <https://tools.ietf.org/html/
draft-perkins-intarea-multicast-ieee802-03>.
[RFC1885] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6)", RFC 1885, DOI 10.17487/RFC1885, December 1995,
<https://www.rfc-editor.org/info/rfc1885>.
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
Neighbor Discovery (ND) Trust Models and Threats",
RFC 3756, DOI 10.17487/RFC3756, May 2004,
<https://www.rfc-editor.org/info/rfc3756>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>.
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti,
L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-
Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011,
<https://www.rfc-editor.org/info/rfc6164>.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583,
DOI 10.17487/RFC6583, March 2012,
<https://www.rfc-editor.org/info/rfc6583>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>.
[RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local
Addressing inside an IPv6 Network", RFC 7404,
DOI 10.17487/RFC7404, November 2014,
<https://www.rfc-editor.org/info/rfc7404>.
Jaeggli Expires December 26, 2018 [Page 6]
Internet-Draft IND June 2018
[RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix
Length Recommendation for Forwarding", BCP 198, RFC 7608,
DOI 10.17487/RFC7608, July 2015,
<https://www.rfc-editor.org/info/rfc7608>.
Author's Address
Joel Jaeggli
Fastly
Mountain View, CA 94043
US
Phone: +5415134095
Email: joelja@bogus.com
Jaeggli Expires December 26, 2018 [Page 7]