Indefensible Neighbor Discovery
draft-jaeggli-v6ops-indefensible-nd-01

Abstract

NDP resource exhastion is a problem which cannot fundamently be addressed through limited protocol changes or implementation tweaks; mitigations proposed in RFC 6583 may well prevent the outright failure of a device under duress. 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 January 3, 2019.

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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Requirements Language
• 2. ND under stress
• 2.1. Ways in which resources are consumed:
• 3. Mitigations
• 3.1. RFC 6583
• 3.2. Link-Local
• 3.3. RFC 6164
• 3.4. Firewalls
• 3.5. Subnetting
• 3.6. Stateless Neighbor Presence Discovery
• 3.7. Solicitied Node Multicast Group Membership
• 4. Acknowledgements
• 5. IANA Considerations
• 6. Security Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Author's Address

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 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, 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 style /127 prefixes for example 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 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.

If we are to characterize the achitectural challenge posed by ARP and ND. It is that traffic in the data-plane from untrusted source may impose demands on the control plane to create and then exhaust available state. In IPv4 the mitigiation for this is for the most part relatively trivial and tighly coupled to subnet and forwarding hardware sizing; address conservation principles that do not apply to IPv6 subnets therefore generally but not entirely ameliorate this problem in IPv4.

1.1. Requirements Language

This document does not employ and should not interpreted through RFC 2119 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:

• 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.
• 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. 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.
• 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).

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 ultizing an address registration scheme to limit the need for discovery.

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 suggests some practical mitigations, which can reduce the extent to which ND fails but not eliminate it.

3.2. Link-Local

RFC 7404(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 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.

3.5. Subnetting

Sizing subnets effectively to support the number of hosts present does limit the scope for ND exhaustion attacks. RFC 7608 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. In the draft 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.

Use of very long prefixes has the potential to expose subnets to the considerations in RFC 7707 where for example neighboring devices on a subnet might be trivial to discover via scanning as for example are router interfaces numbered as "::1" out of convience . The extent to which discoverability is an issue may vary by usage and also methodoly, so for example sparsely allocated pseudo-randomly assigned /128s may be no more discoverable then IPv6 self assigned privacy addresses, but machines clumped together in a /121 may be trivially identified when one of them is located. other methods of discovering detailed in RFC 7707 e.g. forward or reverse dns mappings may trivialy reveal the presence of additional hosts within a prefix.

3.6. Stateless Neighbor Presence Discovery

"Mitigating IPv6 Neighbor Discovery DoS Attack Using Stateless Neighbor Presence Discovery" was a proposal by Mark Smith, to aleviate the pressure on the neghbor discovery process when under duress.

3.7. Solicitied Node Multicast Group Membership

"Further Mitigating Router ND Cache Exhaustion DoS Attacks Using Solicited-Node Group Membership" was a proposal by Mark Smith, to use the solicited node multicast group to limit the need to multicast ND to all ports when performing ND.

4. Acknowledgements

This Document is entirely depedent on previous work done in the IETF community and other authors. Mark Smith offered valuable contributions and References to the initia Draft. Brian Carpenter reviewed the initial draft and provided additional references.

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

7.2. Informative References

Author's Address