IPv6 Attack: NDP Table Exhaustion

    IPv6 is confidently moving, sooner or later it will enter our lives to the same extent as IPv4. An interesting feature - a long period of development and implementation led to the fact that some of the initial ideas were scrapped and the design itself gradually overgrown with crutches. And, what a shame, to solve some serious problems started only recently.

    Under the cut - how to put IPv6 and even IPv4 network DoS-attack NDP Table Exhaustion, as well as options for half measures and protection measures.

    image



    Topic Help


    Neighbor Discovery Protocol (NDP) plays a key role in IPv6. In essence, this is a replacement for ARP with a number of new features and a number of new problems.

    Spherical packet exchange in vacuum according to the RFC looks like this: node A without the necessary entry in the neighborhood table looks for the physical address of node B by IPv6 address. To do this, it creates an entry in the table marked "INCOMPLETE", sends Neighbor Solicitation (NS) to a special address (solicited-node multicast) and waiting. Node B receives the message and replies with a Neighbor Advertisement (NA) message. Node A writes the address to the table, the exchange of information begins, everyone is happy.

    It will also be useful to recall two important features of addressing in IPv6. The first - there can be many global unique addresses on an interface, even with the same prefix. At the same time, they are equivalent in a sense, and the logic for using these addresses often depends on the implementation. For example, instead of EUI-64, an interface identifier can be randomly generated in the name of privacy.

    The second feature - the recommended (initially) network size is / 64. Even on point-to-point connections. Personally, it always bothered me - how can one distribute so many globally unique (= public) addresses to such a network ?! But, according to the authors of IPv6, the “hungry years” and IPv4 deficit in the past are therefore more effective. For this reason, some hardware and software developers are guided by the rule "subnet - only / 64"

    The essence of the problem


    How many addresses are in an IPv4 subnet? Depends on the size, but most likely not enough. Favorite size - / 24 - assumes no more than 254, large networks are rare because of poor scalability.

    How many addresses are in an IPv6 subnet? 2 to the power of 64. Even if it has one node, it can use random addresses from the entire range. To find the device (or to establish the fact of its absence), the neighbor detection mechanism is used.

    How many NDP entries can a device remember? For “medium” L3-switches, the figure will be somewhere around several thousand, for more powerful devices - tens or hundreds of thousands of records. In any case, this is a drop in the bucket compared to the number of possible addresses.

    Each query creates an entry in this table. As a result, even a simple ping sweep can easily overflow it. Given the global nature of addresses, this can be done not only from the inside, but also from the outside by sending absolutely any packet to addresses from this network.

    Effects


    All devices are potentially susceptible to attack, however, a number of settings and properties can reduce the severity of the problem or practically solve it.

    Scenario 0. Observed on some devices . A valid ND implementation limits the number of INCOMPLETE entries and cleans the queue if necessary. The attack does not pass.

    Scenario 1 - Bad. On the device there is only a limit on the number of packets per second for Neighbor Discovery (Control Plane policer).
    • In this case, an attack is possible, but will be slower.
    • During an attack, IPv6 resolution in the MAC will be difficult for all nodes.
    • It is possible that sooner or later the overflow of the table will nevertheless occur. In this case, the events will go according to scenario 2.
    • A severe restriction will interfere with the normal operation of the network (for example, in case of restarting a large number of machines)


    Scenario 2 - Even worse. There are no restrictions, the table overflowed on the affected interface
    • New entries will no longer be able to get there. That is, part of the devices will be “invisible”.
    • Some implementations remove old records from the table, even if the records are actively used. Now the working devices have disappeared


    Scenario 3 - Arrived. Occurs when resources are shared.
    • On some platforms, all IPv6 interfaces stop working normally
    • Separate implementations share memory for ND in IPv6 and ARP in IPv4. Broken IPv6 also pulls IPv4 too.


    What to do


    In fact, the basis of this problem is not a bug, but a feature. It’s just that today devices don’t have so many resources to accommodate enough records for a / 64 network. In addition, the device cannot distinguish legitimate requests from "just asked." But the main aggravating factor is the ND messaging algorithm.

    The developers of hardware and software should theoretically review the implementation of this algorithm. For example, requests for unknown addresses should have a minimum priority, and upon reaching a certain percentage of filling the table, INCOMPLETE records should be forgotten in the first place. Some devices already work this way, but by no means on all platforms is this done properly.

    What to do now:

    • Limit the number of packets per second to the control plane. It does not solve the problem, because with a small table size and a long record storage period, even a very small stream will fill it sooner or later. However, it slows down the process and in some situations can help. Poor if peaks in ND traffic are possible
    • Use smaller subnets, such as / 127 for point-to-point connections. Unfortunately, trying to get away from “too large” / 64 networks does not always work. At the same time, SLAAC is lost, as well as a number of other technologies, as evidenced by RFC 5375 (section 3). Although / 127 is permitted by RFC 6164, engineers also build / 64 networks during development, so on a number of platforms traffic for non-standard networks can only be processed completely programmatically. In general, there are many side effects.
    • Use static ND entries everywhere. In some cases, it can help out, but even on an average scale it looks more like masochism.
    • Use a route to nowhere for network / 64 and separate routes / 128 to nodes. In this case, for scalability, nodes will need to participate in routing.
    • Limit the range of addresses to which connections can be initiated using the ACL / firewall on the edge device. This method protects against attacks from an external network.
    • Enable Neighbor Discovery Inspection with Destination Inspection. This technology is part of Cisco's First Hop Security IPv6 suite of technologies. There are analogues or, probably, will appear in other vendors. At its core, it is similar to IP DHCP Snooping + ARP Inspection for IPv4: the device listens to all ND messages and maintains a Binding Table. The Destination Inspection option prohibits the recognition of addresses that are not contained in the table, which means that they are not on the network. First Hop Security configuration guide can be found here .


    Conclusion


    Security in IPv6 is a delicate matter. This is a consequence of the relative novelty of the protocol, and the result of new features incorporated into it. The problems are not always obvious, and it is possible that, as they are introduced, new difficulties will be found, but at the very least, known vulnerabilities need to be closed now.

    A good list to check for typical vulnerabilities is here . Remember that by default on many modern OS IPv6 is already enabled and working.

    Also popular now: