NIST IPv6 document

Thu Jan 6 21:21:08 UTC 2011

On Thu, Jan 6, 2011 at 7:34 AM, Robert E. Seastrom <rs at seastrom.com> wrote:
> I continue to believe that the "allocate the /64, configure the /127
> as a workaround for the router vendors' unevolved designs" approach,

As a point of information, I notice that Level3 has deployed without
doing this, e.g. they have densely packed /126 subnets which are
conceptually identical to /30s for infrastructure and point-to-point.
I am still taking your conservative approach, as I see no operational
disadvantage to it; but opinions must differ.

On Thu, Jan 6, 2011 at 11:28 AM,  <Valdis.Kletnieks at vt.edu> wrote:
> And the "ZOMG they can overflow the ARP/ND/whatever table" is a total red
> herring - you know damned well that if a script kiddie with a 10K node botnet
> wants to hose down your network, you're going to be looking at a DDoS, and it
> really doesn't matter whether it's SYN packets, or ND traffic, or forged ICMP
> echo-reply mobygrams.

I agree, botnets are large enough to DDoS most things.  However, with
the current state of ARP/ND table implementations in some major
equipment vendors' routers, combined with standards-compliant
configuration, it doesn't take a botnet.  I could DoS your subnet (or
whole router) without a botnet, say, using an IPv6 McDonald's Wi-Fi
hotspot.  That is very much a legitimate concern.  A few hundred
packets per second will be enough to cripple some platforms.

On Thu, Jan 6, 2011 at 1:20 PM, Owen DeLong <owen at delong.com> wrote:
> And there are ways to mitigate ND attacks as well.

No, Owen, there aren't.  The necessary router knobs do not exist.  The
"Cisco approach" is currently to police NDP on a per-interface basis
(either with per-int or global configuration knob) and break NDP on
the interface once that policer is exceeded.  This is good (thanks,
Cisco) because it limits damage to one subnet; but bad because it
exemplifies the severity of the issue: the "Cisco solution" is known
to be bad, but is less bad than letting the whole box break.  Cisco is
not going to come up with a magic knob because there isn't any -- with
the current design, you have to pick your failure modes and live with
them.  That's not good and it is not a Cisco failing by any means, it
is a design failing brought on by the standards bodies.

I would also like to reply in public to a couple of off-list
questions, because the questions are common ones, the answers are not
necessarily cut-and-dry (my opinion is only one approach; there are
others) and this is the kind of useful discussion needed to address
this matter.  I will leave out the names of the people asking since
they emailed me in private, but I'm sure they won't mind me pasting
their questions.

Anonymous Questioner:
>What do you think about using only link-local ip addresses on the infrastructure links please?
I can't think of any potential drawbacks do you?

This can be done, but then you don't have a numbered next-hop for
routing protocols.  That's okay if you re-write it to something else.
Note that link-local subnets still have an NDP table, and if that
resource is exhausted due to attacks on the router, neighbors with
link-local addressing are not immune.

link-local scope offers numerous advantages which are mostly
out-weighed by more practical concerns, like, how hard it is going to
be to convince the average Windows sysadmin to configure his machine
to suit such a design, instead of just taking his business elsewhere.
Not a problem for enterprise/gov/academia so much, but a problem for
service providers.

On Thu, Jan 6, 2011 at 3:43 PM, Jack Bates <jbates at brightok.net> wrote:
> Given that the incomplete age is to protect the L2 network from excessive
> broadcast/multicast, I agree that aging them out fast would be a wiser

I agree that it would be nice to have such a knob.  I bet you and I
would make different choices about how to use it, which is the whole
point of having a knob instead of a fixed value.

> I'm still a proponent for removing as needed requests like this, though. It
> would have been better to send a global "everyone update me" request
> periodically, even if triggered by an unknown entry, yet limited to only
> broadcasting once every 10-30 seconds.

> Given that all requests for an unknown arp/ND entry results in all hosts on
> the network checking, it only makes sense for all hosts to respond. There

This isn't a new idea and it has its own set of problems, which are
well-understood.  IPv6 NS messages are more clever than ARP, though,
and are sent to a computed multicast address.  This means that the
number of hosts which receive the message is minimized.  See RFC2461
section 2.3 for the quick introduction.

NDP is better than ARP.  However, your statement that NDP has all (I'd
like to say some) of the same problems as ARP but the increased subnet
size has magnified them, is basically correct.  NDP does some things a
lot better than ARP, but not this.  It's important to realize that
when this stuff was designed, there were few hardware-based layer-3
routers for IPv4.  The biggest networks (Sprint/UUnet/etc) were
exchanging a few hundred megabits per second on PNIs and the tier-2
guys had DS3s to IXPs.  The network has come a long way in terms of
user-base, bandwidth, and sophistication since then.

Second Anonymous Questioner:
> That is, I don't see why a smart rate-limiting implementation doesn't solve most of it.

This is a good question, which I have tried to cover in much earlier
posts, perhaps without explaining it effectively.  There currently are
major vendors shipping IPv6 routers which age out ARP/NDP entries even
if they have continuous traffic -- these routers do an occasional
ARP/NDP "refresh" even though the neighbor is constantly sending and
receiving traffic.  For this reason, an attack can trigger your
rate-limit and prevent the "refresh" from working.  So over a period
of time, all hosts attached to the router will stop working.

Smarter platforms are still unable to learn about new neighbors when
your rate-limit is being triggered.  How bad this is depends on the
implementation.

Finally, any compromised host on the LAN can fill up the NDP table for
the interface (which on most platforms, really means fill up the
combined NDP/ARP table for the whole box) and either prevent any new
neighbor associations, or far worse, cause churn that will disable the
entire router and all traffic that needs to transit through it.  This
is extremely bad, and yet, it is trivial to execute if you have access
to a machine on the LAN.

>Yes, during this period, lots of unreachables will not be sent,

Unreachables are really of no concern.  The router staying up, and its
interfaces continuing to function correctly, are in question.
Actually, they're not so much in question ... because all existing
IPv6 routers can be broken with the trivial method we are discussing
if /64 subnets are in use.  What's implementation-specific is "how
broken," but as you can read above, Cisco has given customers a knob
to control the damage, but it's very, very far from a complete
solution.  Unlike Cisco, some other vendors haven't given this the
first thought, let alone added a knob; but even Cisco must do more.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts