Subject: [v6ops] Review of draft-gashinsky-v6ops-v6nd-problems

From: "George, Wes" <[email-masked]>
Date: Mon, 10 Oct 2011 11:33:56 -0400

I've read the -00 draft, below are some (hopefully useful) comments.

Section 2 -I think that your problem statement is incomplete. This problem can also be triggered in situations completely independent of NMAP or ping flood type activities. If the majority of the hosts attempt to use ND (especially RS) simultaneously on a subnet or router with a sufficiently large number of hosts terminating to it, this may overwhelm the routers with the rate of messages. A good example of this would be during a mass software upgrade of the end hosts on the subnet that triggers a reboot of many of them at once, or a router/Spanning tree failover, power restoration, etc, where a large number of the hosts have to learn about their upstream rapidly due to some external trigger.
In a way there are two separate problems here- ND cache exhaustion because something is trying to talk to a bunch of nonexistent hosts within the subnet, and cpu/rate exhaustion due to legitimate ND messages in a subnet with a large number of hosts (thousands) and an underpowered router. There's maybe even a third variant, where you have a network with a lot of traffic directly between the hosts that may drive ND cache exhaustion or other ND related control plane issues on the hosts themselves rather than the router. These are important to this discussion IMO even if they are not necessarily all attack vectors, because they are all legitimate ND scale problems. You discuss some of this in section 7.2, but I think it makes sense to have it more clearly discussed in the problem statement.
I also agree with Hemant that it would be better to explain what you mean by "join" a network rather than putting it in quotes. Perhaps "As a result of these vulnerabilities, new devices may not be able to find or be found by their gateway, which may make it impossible to establish..." Maybe even add "new devices may not be able to find their neighbors in order to send traffic directly to other hosts within the subnet"

Section 4 - May want to note the fact that NDP is in contention with other control-plane processes and therefore depending on prioritization, there can be collateral damage (NDP starvation by other control plane processes with higher priority or vice versa). Also, as noted in my comments above, this needs to discuss the problem when it is triggered in the reverse direction (many hosts making simultaneous RS).

Section 6 - The passive voice grammar pedant in me respectfully requests that you drop "it can be stipulated that" from the second sentence. It stands on its own without that phrase.
Section 6.2 - this is a bit incomplete without some discussion of the /64  subnet size "rule" and cases where it makes sense to "violate" it. You may be able to simply reference other documents that cover the use of /64 vs something smaller, but I can't think of one to recommend off of the top of my head. There's also the idea of allocating a /64 in your addressing database, but only assigning and routing the portion of it that is large enough to cover the hosts on the subnet plus a healthy margin for growth. This gives you the ability to grow the subnet as necessary without reallocation, but does have some limitations. It's somewhat related to the solution in 6.1, but covers the prefix drop in routing instead of via ACLs similar to 6.3.
Section 6.3 - Given that IGPs carry their routes through a large portion of the network depending on their hierarchy and topology, this suggestion worries me as it's currently presented. Lots of hosts can do quagga/zebra etc and still announce small blocks via BGP, and at least in that case you can manage how far it propagates into the network, even if you have to carry a lot more BGP sessions on your upstream router.
independent of whether this is done in IGP, there's a considerable scaling consideration here in carrying a /128 route for each host in a suitably large network, even if we're only talking about carrying it on the local directly upstream router and no farther. Maybe it's not an issue if said router isn't carrying the full internet routing table (only carrying default + IGP routes, for example), but if it is, or worse, a full iBGP table that might be a good bit larger than the DFZ routing table due to aggregates, that might be problematic, and depending on the churn of the hosts (especially in the case of VMs which get instantiated and dropped as demand grows and shrinks), this may create a different routing table scale problem, in that the near-constant updates overwhelm the router's RP and convergence suffers.
Section 6.4 - I would put the last sentence first. Set that as the basis for the optimization, and then explain why it's important, rather than adding it as an afterthought at the end. May also want to talk about tuning prioritization of different control plane processes that may be in contention for available resources and how it may affect the router's response. This is different from your discussion later in the document about prioritization within ND, this is more about prioritization of ND vs BGP update processing or BFD hellows, etc. Some of this will depend on the specific implantation as to which of these things are actually in contention, so I provide those merely as examples, and I think that the discussion should remain fairly general.

Section 7.1
#1 - "especially when a router" I would suggest "especially when one is acting as a router"

Thanks,

Wes George

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.