Subject: /64 ND DoS

From: Philip Homburg <[email-masked]>
Date: Tue, 12 Jul 2011 10:48:47 +0200

Occasionally the subject comes up: /64 (and SLAAC) is bad because it is
easy to DoS routers by getting to perform too much ND.

At least in theory this seems to be a valid complaint. A router can (and
should) carefully allocate resources for ND to avoid having ND interfere with
other parts of the routers functionality. 

But in the end, if the ND part of a router is overloaded and it needs to do
ND for a genuine neighbor, it may have to drop the packet.

So what I was thinking of, what if a router that is under attack would 
periodically multicast to the all-nodes multicast address a message saying
"help I'm under attack". Upon receiving such a message all nodes send a 
neighbor solication to the router. This populates the router's neighbor
cache with entries for all of it's neighbors. Thus ensuring that normal traffic
can flow uninterrupted.

---

From: Sander Steffann <[email-masked]>
Date: Tue, 12 Jul 2011 11:22:06 +0200

Hi,

> cache with entries for all of it's neighbors. Thus ensuring that normal traffic

I have thought about this too. I wouldn't even mind if this became (configurable) default behaviour. One thing though: all nodes should send neighbour solicitations for each IPv6 address they are listening on.

Thanks,
Sander

---

From: Philip Homburg <[email-masked]>
Date: Tue, 12 Jul 2011 11:46:17 +0200

In your letter dated Tue, 12 Jul 2011 11:22:06 +0200 you wrote:
>I have thought about this too. I wouldn't even mind if this became =
>(configurable) default behaviour. One thing though: all nodes should =
>send neighbour solicitations for each IPv6 address they are listening =
>on.

I was thinking that it might be easiest to allocate some flags in the router
advertisement message. In that case, you could in theory also do it per prefix.
But that may complicate routers too much.

(When doing ND, routers can keep track of for which on-link prefixes they
have recently dropped packets. Also, routers can give priority to ND requests
that originate from whithin the router, so there should never be any reason
to request help for link-local addresses).

---

From: Karl Auer <[email-masked]>
Date: Tue, 12 Jul 2011 22:34:53 +1000

> > So what I was thinking of, what if a router that is under attack would

The router would need to know that it was under attack. That could be
quite a complicated heuristic. It seems to me that it is simpler to
treat ND slot exhaustion as the problem, and not worry too much about
the cause.

I have no clue how sensible these ideas are:

- when slots get scarce, start favouring existing completed entries.
  Don't time them out as fast. That is, treat completed entries as more
  valuable than incomplete ones. Silly to toss out a probably-good entry
  in favour of a definitely-incomplete one.

- when slots get very scarce, start timing out incomplete entries
  faster, returning the slots to the pool. There will be a useful
  minimum time here...

- store source info with each slot. Have separate slot
  space for local (on-router) sources and remote (off-router) sources.
  This lets the local network keep working even when under attack from
  off-router.

- when slot space reaches a critical level, start ignoring requests from
  sources that have no completed entries. Yes, innocent new sources will
  suffer, but you are heading into crisis.

- when and as long as there are NO slots left:
   - don't delete completed entries at all while there are incomplete
     entries to delete

   - delete entries with sources with the fewest completed entries
     first. After them, delete the oldest entries first.

> > neighbor solication to the router.

This could be a reaction to a rapid decrease in available cache slots.
Do you need a special message? A ping to the all-nodes multicast address
should result in all nodes responding, and the responses would have all
the info in them that you need. You'd have to do that on each link,
though. And you'd have to do it *fast*. In fact, it seems to me that you
would be unlikely to be able to do it fast enough to make a difference -
by the time your nodes had responded, the attacker would have filled the
ND cache. Doing it preemptively would make for a very chatty link.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])                   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/                   +61-428-957160 (mob)

GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156

---

From: Florian Weimer <[email-masked]>
Date: Tue, 12 Jul 2011 12:40:12 +0000

* Philip Homburg:

> periodically multicast to the all-nodes multicast address a message
> saying "help I'm under attack". Upon receiving such a message all
> nodes send a neighbor solication to the router. This populates the
> router's neighbor cache with entries for all of it's neighbors. Thus
> ensuring that normal traffic can flow uninterrupted.

Assuming that neighbor discovery is vulnerable, wouldn't the same issue
affect the triggered solications?  And isn't it a fine way to overload a
router on a large subnet?

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Philip Homburg <[email-masked]>
Date: Tue, 12 Jul 2011 15:11:44 +0200

>treat ND slot exhaustion as the problem, and not worry too much about

First, let me make clear that I was thinking about remote attacks. I think
that's the most serious problem. If you have malicious hosts directly
attached you have bigger problems, and you have to use either SeND or L2
filtering.

Assuming a remote attack, the only thing the attacker can do is cause
incomplete entries to be created. So the table consist of a collection of
normal (complete) entries for neighbors and a potentially large number of
incomplete entries.

Ultimately, the limit is not so much the number of incomplete entries in
the table, but the number of NS messages you can send per second.

So my definition of under attack would be that the router did not send a
NS because doing so would exceed the maximum number NS messages per second.

Beyond that, scale the table to hold that number of incomplete entries and
you are done.

>  in favour of a definitely-incomplete one.

This can be done all the time. If a completed entry is less then 1 minute
old, keep it.  If you run out of space, then there is a local attack
(or the number of neighbors exceeds what the router can handle)

>  faster, returning the slots to the pool. There will be a useful

You only need incomplete entries for about 3 seconds (default settings).

>  This lets the local network keep working even when under attack from

Yes. Just one bit to mark an incomplete entry as local. But that should 
mostly effect the sending of NS messages.

>  suffer, but you are heading into crisis.

That would be just the packets that are forwarded. 

>   - don't delete completed entries at all while there are incomplete

I would just partition the table: some number of entries for completed and
some number for incomplete. 

>     first. After them, delete the oldest entries first.

I think that for remote attack this doesn't make much sense. 

>the info in them that you need. 

No, other nodes have to send a NS (or anything else that contains their 
link layer addresses).

>You'd have to do that on each link,
>though. 

If the bottleneck is not the table size, but number of NS messages you
can send per second, then it is per overloaded link.

>And you'd have to do it *fast*. In fact, it seems to me that you

The attacker fills the cache with incomplete entries. NS requests can be used
to create complete entries. So you can always add them to the table.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 12 Jul 2011 15:19:05 +0200

>router on a large subnet?

One, I was thinking about a remote attack. So neighbors are trusted.

Two, a NS doesn't require the router to maintain any state. The router
just stores the IPv6 address and the MAC in the table and sends an NA.

As long as the router is properly sized for the number of neighbors, it
should be able to store it.

I'd say that a router has to be able to handle one NS per address per
neighbor every 30 seconds anyhow.

If the router can do that, then sending one request for help
every minute should do the trick.

---

From: Florian Weimer <[email-masked]>
Date: Tue, 12 Jul 2011 13:22:32 +0000

> just stores the IPv6 address and the MAC in the table and sends an NA.

Huh?  If this isn't state, then what is it?

---

From: Philip Homburg <[email-masked]>
Date: Tue, 12 Jul 2011 15:26:57 +0200

>Huh?  If this isn't state, then what is it?

It is state, but it is not required :-)

Updating the table is optional. In this case it is desired. But there is 
no reason to expect that the situation will get worse. Unless the router was
too small to begin with.

---

From: Florian Weimer <[email-masked]>
Date: Tue, 12 Jul 2011 13:31:23 +0000

* Philip Homburg:

> First, let me make clear that I was thinking about remote attacks.

How would a remote attack work?

> I think that's the most serious problem. If you have malicious hosts
> directly attached you have bigger problems, and you have to use either
> SeND or L2 filtering.

On its own, neither SeND nor L2 filtering prevent any attacks on
neighbor discovery.  You need some sort of layering violation to tie
endpoints to specific addresses, and nothing working exclusively on
layer 2 or the IP layer can achieve that.  Once you can make that
connection, you can also limit the amount of processing power and state
per identified endpoint.  But without that, you have zero chance against
a local attacker.

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 12 Jul 2011 06:45:59 -0700

we had a couple of suggestions.

http://www.ietf.org/id/draft-gashinsky-v6nd-enhance-00.txt

On Jul 12, 2011, at 1:48 AM, Philip Homburg wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Philip Homburg <[email-masked]>
Date: Tue, 12 Jul 2011 15:56:24 +0200

>How would a remote attack work?

You send a stream of packets directed to a particular /64 but you make sure
that each packet has a different destination address. 

The router that attaches to the /64 has perform ND for each packet. Assuming
that those addresses are not in use, it takes 3 seconds for the ND to time out.

So the router will have to maintain a huge amount of state. And, because the
NS messages are multicast, you have to rate limit them.

>per identified endpoint.  But without that, you have zero chance against

For fixed ethernet (wireless is more tricky) a switch could limit the number
of MAC addresses per port in time. If you then limit the number of IPv6
address per MAC (that would require a layer violation) then can prevent
hosts from executing a local attack.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 12 Jul 2011 16:04:33 +0200

>http://www.ietf.org/id/draft-gashinsky-v6nd-enhance-00.txt

Yes, but I prefer something triggered by a router then just requiring
host to do something occasionally on their own.

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 12 Jul 2011 08:17:31 -0700

> host to do something occasionally on their own.

The problem in my opinion is not that the router isn't sending enough messages. It's sending too many for it's own purposes.

keeping existing known hosts in the cache and learning new ones in the face of resource exhaustion is the challenge.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 12 Jul 2011 17:40:29 +0200

In your letter dated Tue, 12 Jul 2011 08:17:31 -0700 you wrote:
>The problem in my opinion is not that the router isn't sending enough =
>messages. It's sending too many for it's own purposes.
>
>keeping existing known hosts in the cache and learning new ones in the =
>face of resource exhaustion is the challenge.

In theory, when the router is in distress, it could just limit itself to
sending out the distress signal and waiting for the neighbors to respond
with NS messages.

---

From: Jared Mauch <[email-masked]>
Date: Tue, 12 Jul 2011 12:09:03 -0400

> host to do something occasionally on their own.

You can't have two-party communication have only one part (the router) perform all the actions.

Is there a specific part of the above draft that you think should be changed?  In what manner?

I happen to think that it's not desirable to have any network element under attack, but the ideas in the draft seem to be well thought out, but perhaps not clearly stated enough for your needs?  (and with the least amount of protocol changes necessary, infact i believe only one, the rest could be seen as implementation details that would result in a lab failure and failure of RFP with noncompliant vendors).

- Jared

---

From: Philip Homburg <[email-masked]>
Date: Tue, 12 Jul 2011 18:39:42 +0200

In your letter dated Tue, 12 Jul 2011 12:09:03 -0400 you wrote:
>You can't have two-party communication have only one part (the router) =
>perform all the actions.

So, in my proposal, the router sends out a request for help. And all of its
neighbors respond with a Neighbor Solicitation.

>Is there a specific part of the above draft that you think should be =
>changed?  In what manner?

Well, add my proposal :-) Formally request a change to the Neighbor Discovery 
RFC that allows this to happen.

>I happen to think that it's not desirable to have any network element =
>under attack, but the ideas in the draft seem to be well thought out, =
>but perhaps not clearly stated enough for your needs?  (and with the =
>least amount of protocol changes necessary, infact i believe only one, =
>the rest could be seen as implementation details that would result in a =
>lab failure and failure of RFP with noncompliant vendors).

I think they are certainly not stated clearly enough. But also don't think
they go far enough. As far as I can tell, the draft does not contain a protocol
that will always work.

It contains a number of suggestions that to some extent mitigate the problem.

For example,

"Hosts MAY be configured to send unsolicited Neighbor advertisement
"at a rate set at the discretion of the operators.  The rate SHOULD
"be appropriate to the sizing of ND cache parameters and the host
"count on the subnet.  An unsolicited NA rate parameter MUST NOT be
"enabled by default.

What does that mean? Each time I connect my laptop to a network, an operator
shows up from behind the bushes and configures the right parameters?

What if it doesn't happen? Then my laptop is not protected a case of a DoS on
the router?

IMHO, what is needed is to write a document that lists changes and additions
relative to the neighbor discovery rfc, such that by default, routers and
hosts can be protected against this attack.

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 12 Jul 2011 09:56:33 -0700

> shows up from behind the bushes and configures the right parameters?

first off, beaconing is clearly not appropriate for all environments. so I wouldn't expect a laptop to do it at all unless you were  explicit  in your desire to do so. the goal was also to make the mechanism backward compatible with existing ND behavior, where such a message unsolicited would be grounds for kicking off a neighbor discovery process.

> What if it doesn't happen? Then my laptop is not protected a case of a DoS on

it's the router's ndp cache not the laptop that's the target of the dos.

> hosts can be protected against this attack.

7.3 and 7.4 are in fact proposals for changes to 4861. They could be split into a separate document. goal was to get something out so that we could shoot holes in it.

implementation advice in 7.1 7.2 are things that can be done without making changes to the way that NDP works today.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 12 Jul 2011 19:31:33 +0200

In your letter dated Tue, 12 Jul 2011 09:56:33 -0700 you wrote:
>> What does that mean? Each time I connect my laptop to a network, an =
>operator
>first off, beaconing is clearly not appropriate for all environments. so =
>I wouldn't expect a laptop to do it at all unless you were  explicit  in =
>your desire to do so. the goal was also to make the mechanism backward =
>compatible with existing ND behavior, where such a message unsolicited =
>would be grounds for kicking off a neighbor discovery process.

>From a presentation perspective, I think it would be better if you start with
the general solution before moving to more specialized ones.

(I'll ignore this part for now)

>it's the router's ndp cache not the laptop that's the target of the dos.

I know. But it is vital that my laptop's MAC gets into the router's
neighbor cache. So I assumed that this was done using beaconing.

>> IMHO, what is needed is to write a document that lists changes and =
>additions
>> relative to the neighbor discovery rfc, such that by default, routers =
>and
>7.3 and 7.4 are in fact proposals for changes to 4861. They could be =
>split into a separate document. goal was to get something out so that we =
>could shoot holes in it.

Moving it to separate document is one thing. Moving it to its own section
and using more formal language wouldn't hurt. In particular try to 
make clear what you want to add to what sections of RFC-4861.

Now to Section 7.4. Are you seriously suggesting that on a large network,
every host when it boots sends a multicast to the all-routers address? 
You have 6000 hosts that wake up after a power failure and they just randomly
multicast to the all-routers address?

And then what? How does this stay in all of the routers' neighbor caches
for ever? Except that hosts can use privacy address, so more and more
addresses have to become locked in the routers' caches.

What if a router reboots?

>implementation advice in 7.1 7.2 are things that can be done without =
>making changes to the way that NDP works today.

Even then, if doing things in the right order is critical, that should be
considered part of the protocol. Even if the bits on the wire remain the
same.

---

From: Jared Mauch <[email-masked]>
Date: Tue, 12 Jul 2011 13:50:16 -0400

Keeping the scope on this part only...

> multicast to the all-routers address?

I think this is just an example, it's also IMHO a test that means you read the draft (or at least that part).

I think this needs to be refined, hence the feedback process via the community here.  I think sending to all-routers (or all-hosts) is generally an unwelcome event, but it is a way to have the host communicate with something that is setting the "i'm a router" bit.

- Jared

---

From: Doug Barton <[email-masked]>
Date: Tue, 12 Jul 2011 11:39:01 -0700

> cache with entries for all of it's neighbors. Thus ensuring that normal traffic

I like this idea, and would like to suggest that we name it the HHIBR
packet.

Doug (Help, help! I'm being repressed!)

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Sander Steffann <[email-masked]>
Date: Tue, 12 Jul 2011 21:09:20 +0200

Hi Doug,

> Doug (Help, help! I'm being repressed!)

Well, this is all about the violence inherent in the system! ;-)
Sander

---

From: Fred Baker <[email-masked]>
Date: Tue, 12 Jul 2011 16:39:19 -0400

> easy to DoS routers by getting to perform too much ND.

I suppose the same might be true of ARP. Has it been observed in the wild?

---

From: Christian Huitema <[email-masked]>
Date: Tue, 12 Jul 2011 20:52:11 +0000

> I suppose the same might be true of ARP. Has it been observed in the wild?

Suppose a simple attack of:

	For each address A in subnet,
		Compose packet with source=local and dest=A
		Send packet to router

In a typical IPv4 subnet, the loop will run 255 times. In a very large one, a few thousand times. In an IPv6 subnet, the loop will run 2^64 times, and the effect on the neighbor cache on the router could be interesting.

On the other hand, there are many ways for a local host to DOS a local router. I am not sure that this specific one is particularly practical, or worrisome.

-- Christian Huitema

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 12 Jul 2011 13:58:35 -0700

> I suppose the same might be true of ARP. Has it been observed in the wild?

if you have a big enough subnet yes it is...

on the scale of a /19 the volume of broadcast traffic begins to annoy imho.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 12 Jul 2011 23:06:48 +0200

In your letter dated Tue, 12 Jul 2011 20:52:11 +0000 you wrote:
>On the other hand, there are many ways for a local host to DOS a local rout=
>er. I am not sure that this specific one is particularly practical, or worr=
>isome.

I guess I should have been way more explicit that I was thinking about the
remote attack.

---

From: Arturo Servin <[email-masked]>
Date: Tue, 12 Jul 2011 18:32:15 -0400

IMHO I think this would be a vector for other attacks in ND.

	You may solve a remote attack but you are opening the door to local attacks, and a big ones I think.

Regards,
.as

---

From: Christian Huitema <[email-masked]>
Date: Tue, 12 Jul 2011 23:56:38 +0000

>  From: [email-masked] [mailto:[email-masked]] On Behalf Of Philip Homburg
>> On the other hand, there are many ways for a local host to DOS a local 
> >router. I am not sure that this specific one is particularly 
>> practical, or worrisome.
>
> I guess I should have been way more explicit that I was thinking about the remote attack.

Then I am really not worried. This kind of attack is trivially mitigated by any stateful firewall on the path. In addition to all other mitigations that were listed on this thread.

-- Christian Huitema

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Jul 2011 07:28:58 +0200 (CEST)

> I suppose the same might be true of ARP. Has it been observed in the wild?

Yes. At Interop they had this exact problem because they had huge subnets 
(/16 or something, I don't know exactly, they had a /8 so they could 
"afford" it), and they had to make them smaller.

I've seen it at other places as well, in the IPv4 Internet it doesn't even 
need to be ddos, it only needs to be the "normal" scanning traffic that 
the botnets do.

This is a REAL problem already, has been forever, and I imagine if I take 
most IPv6 router platforms today and give it 10kpps to random destinations 
to its attached /64 (10kpps of small packets is 5 megabit/s) it'll stop 
working normally.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Florian Weimer <[email-masked]>
Date: Wed, 13 Jul 2011 07:33:02 +0000

> I suppose the same might be true of ARP. Has it been observed in the

Yes, for the remote case.  Sequential scanning used to trigger it.  I
suspect that router capacities for ARP processing have since increased.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 13 Jul 2011 10:00:06 +0200

In your letter dated Tue, 12 Jul 2011 23:56:38 +0000 you wrote:
>Then I am really not worried. This kind of attack is trivially mitigated by=
> any stateful firewall on the path. 

If a stateful firewall is mandatory for the operation of IPv6 then it
should be there in the specs. Last time I looked, there was no standards
track RFC that made stateful firewall mandatory. I could be wrong though.

I'm not aware of any system today that in the presence of just SLAAC can
figure out where the stateful firewall is hiding in the network and how to
get it to open the port you need automatically (i.e. whenever a host allocate
a passive socket).

If you want to go that route, then IMHO, there is a huge amount of work to be 
done. Certainly to get it to work transparently for every possible protocol
that runs on top of IPv6.

Otherwise, it may be more productive to see a stateful firewall as an optional
extra and fix the protocols to be safe even in the absence of such a device.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Jul 2011 10:08:46 +0200 (CEST)

On Tue, 12 Jul 2011, Christian Huitema wrote:

> Then I am really not worried. This kind of attack is trivially mitigated 
> by any stateful firewall on the path. In addition to all other 
> mitigations that were listed on this thread.

Think as an ISP. We do not stateful firewall our customers, and we might 
be forced to have requipment in the customer /64, at least initially. This 
is a real problem, as this device will in some cases be a L3 switch with 
quite limited CPU and FIB table size.

I definitely prefer to have only link-local between me and a CPE and just 
route the /56 to the CPE, so I do not ever have to keep any state 
regarding individual customer placed devices.

We have already requested that our L3 switch vendors have ND starvation 
protection, but there is serious lack of documentation to point to.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 13 Jul 2011 08:15:30 +0000

* Mikael Abrahamsson:

>> Then I am really not worried. This kind of attack is trivially
>> mitigated by any stateful firewall on the path. In addition to all
>> other mitigations that were listed on this thread.
>
> Think as an ISP. We do not stateful firewall our customers, and we
> might be forced to have requipment in the customer /64, at least
> initially.

Could you rephrase that?

If you're in the IPv4 consumer market, I'm pretty sure you provide
stateful filtering for customers.  (The filter probably resides on the
CPE.)  It's possible to do things differently with IPv6, but customers
will probably not like it.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 13 Jul 2011 10:17:43 +0200

In your letter dated Tue, 12 Jul 2011 18:32:15 -0400 you wrote:
>	You may solve a remote attack but you are opening the door to =
>local attacks, and a big ones I think.

Let's assume for a moment a 'normal' link (not one with 6000 hosts) and a
protocol that spreads NS requests by the hosts over a period of say 20 seconds,
how would you then use this as an attack vector?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Jul 2011 10:57:01 +0200 (CEST)

>> might be forced to have requipment in the customer /64, at least

Our central (for some definition of central) equipment might have to be 
the default gw of the devices residing in the customer /64.

To scale, I of course want to have a LL onmly between my central equipment 
and a CPE, and DHCPv6-PD it a /56 and don't have to care about how many 
devices the customer has in his/her home, but a lot of people say 
requiring a CPE to deploy IPv6 is a showstopper so that most likely will 
not happen initially.

> will probably not like it.

No, we do not provide stateful filtering. We a lot of the time don't even 
provide a CPE. Customer can connect their computer directly into the wall 
RJ45 and get an IPv4 address today.

When looking at deploying IPv6 in this scenario, we'd like to put each 
customer in a separate /64 so we don't have to deal with a lot of the 
security issues seen when sharing L2 domain between several customers, but 
we'd still have to limit the amount of IPv6 addresses the customer can 
have "active" due to ND table size limitations (if our central equipment 
is the default gw on the customer LAN). This is even without any ddos 
discussion, this is just normal operations.

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 13 Jul 2011 11:03:04 +0200

On 2011-07-13 10:57 , Mikael Abrahamsson wrote:
[..]
> No, we do not provide stateful filtering. We a lot of the time don't
> even provide a CPE. Customer can connect their computer directly into
> the wall RJ45 and get an IPv4 address today.
> 
> security issues seen when sharing L2 domain between several customers,
> but we'd still have to limit the amount of IPv6 addresses the customer
> can have "active" due to ND table size limitations (if our central
> equipment is the default gw on the customer LAN). This is even without
> any ddos discussion, this is just normal operations.

Why not deploy it like a lot of folks have been deploying IPv6 for over
a decade already:

 - a /64 link to the router/host of the user
   (<link>::1 is you, <link>::2 is them)
 - a route, be it /64, /56 or /48 to <link>::2 aka the user

That link can be a real Ethernet link or a tunnel. AVM Fritz!Box
supports this and various other vendors also find this great.

The "ND" issue now lies at the CPE device of the user, who will most
likely not be able to handle 1GB/s anyway when somebody wants to DDoS
them off the net...

Greets,
 Jeroen
  (who saw 500mbit coming sourced from 6to4 on Monday... and indeed most
home networks don't have 500mbit connectivity yet...)

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Jul 2011 11:18:12 +0200 (CEST)

> supports this and various other vendors also find this great.

What? If it's a /64, then we have the /64 ND DoS problem we've been 
discussing for a gazillion mail already.

> likely not be able to handle 1GB/s anyway when somebody wants to DDoS

No it doesn't, if I am ::1 then if someone sends 10kpps to random values 
of ::X:Y:Z:W on that subnet I have to ND all those. 10kpps is 5 megabit/s, 
anyone can do that. I doubt most routers will work properly when handling 
10k ND state changes per second.

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 13 Jul 2011 11:22:38 +0200

> discussing for a gazillion mail already.

It might look like a /64, but you only use ::1 and ::2 and those are
effectively static and effectively it is a /127 without the anycast issue.

Heck, some people pick a /120 for it or whatever they find nice.
Configuration wise and counting wise /64 is just handy. And if one day
you have multi-access on that link, well, no re-numbering, just enable it.

> of ::X:Y:Z:W on that subnet I have to ND all those.

There is no subnet, only ::2, the rest you can ignore.

> 10kpps is 5 megabit/s, anyone can do that. I doubt most routers will
work properly
> when handling 10k ND state changes per second.

Test it out today and complain to your vendor ;)

Greets,
 Jeroen

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Jul 2011 12:09:28 +0200 (CEST)

> you have multi-access on that link, well, no re-numbering, just enable 

That's why /125 is nice for renumbering, and no ND issue.

> There is no subnet, only ::2, the rest you can ignore.

What should the router do when someone sends a packet to ::3 on that 
subnet? If it's a /64, then it's a subnet with 2^64 active addresses, I 
don't understand how you can call it a non-subnet.

> Test it out today and complain to your vendor ;)

Wow.

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 13 Jul 2011 12:59:54 +0200

> That's why /125 is nice for renumbering, and no ND issue.

Yeah, pick whatever you like I would say. Just stay away from actually
putting a /127 on the link. Two /128s works like a charm though as then
subnet anycast is not involved anymore.

> don't understand how you can call it a non-subnet.

To take this little thing called SixXS as an example, we allocate a /64
per tunnel, but only use <tunnel>::1 (PoP) and <tunnel>::2 (user).

We actually only configure ::1 on the tunnel and route ::2 to the
tunnel, thus effectively two /128's. Thus for everything else there will
be directly an ICMP unreachable. Simple as that.

>> Test it out today and complain to your vendor ;)

What else would you do? :)

Greets,
 Jeroen

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Jul 2011 13:20:31 +0200 (CEST)

> be directly an ICMP unreachable. Simple as that.

A tunnel is not a broadcast medium, it's a point to point device. You 
already statically tell it what the other end address is, right? Thus, 
this is not a problem on this type of tunnel.

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 13 Jul 2011 13:46:37 +0200

> this is not a problem on this type of tunnel.

And you can do exactly the same on a Ethernet link... if there are only
2 addresses (router + user) then there is no need to do ND, well, you
might need to discover the ::2 but that is it, the rest can be ignored.

Greets,
 Jeroen

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Jul 2011 13:52:33 +0200 (CEST)

> might need to discover the ::2 but that is it, the rest can be ignored.

Yes, true, you route ::2 to the ethernet interface, but then it's not 
really a /64, it's a /128 that you reach via ethernet.

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 13 Jul 2011 13:55:20 +0200

On 2011-07-13 13:52 , Mikael Abrahamsson wrote:
>> And you can do exactly the same on a Ethernet link... if there are
>> only 2 addresses (router + user) then there is no need to do ND, well,
>> you might need to discover the ::2 but that is it, the rest can be
>> ignored.
> 

And is that not what you want to achieve?

It gives you the flexibility to limit the number of NDs being made,
while also the option of making it multi-access, or one day upgrading it
to one of those fancy proposed crypto-IP-address schemes ;)

Greets,
 Jeroen

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Jul 2011 14:41:21 +0200 (CEST)

> And is that not what you want to achieve?

Not in the deployment scenario I was talking about (where we act 
default-gw for customer which want to directly hook up SLAAC devices).

For routed scenarios I prefer LL only between PE and CPE.

---

From: Arturo Servin <[email-masked]>
Date: Wed, 13 Jul 2011 09:14:15 -0400

What's the point?

   If you asume unrealistic scenarios to prove your concept, then you
have a problem with your solution.

   The problem is that you have a link where the attacker can have
2^64 different addresses to spoof and it can send NS request at any
rate.

-as

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Jul 2011 11:54:08 -0400

There appear to be several different cases, which can be addressed by 
different reasonable mechanisms (not firewalls, and not lengthening the 
subnet prefix.)

For ISPs, I would assume the primary concern is routers connecting to 
subnets used to provide services.  A non-dynamic approach to ND can 
address that.

For ISPs providing bridged residential services, the ISP normally 
operates on the basis that it gets registration information from all the 
devices in the home.  Thus, it does not need to generate ND solicitations.

Yours,
Joel

On 7/13/2011 4:08 AM, Mikael Abrahamsson wrote:
> be forced to have requipment in the customer /64, at least initially.
> This is a real problem, as this device will in some cases be a L3 switch
> with quite limited CPU and FIB table size.
>
> I definitely prefer to have only link-local between me and a CPE and
> just route the /56 to the CPE, so I do not ever have to keep any state

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Jul 2011 18:07:33 +0200 (CEST)

> devices in the home.  Thus, it does not need to generate ND 

Is there some description of this behaviour somewhere, what would this 
feature be called that I can ask vendors if they have in their equipment?

Just to be sure, we're now saying that reachability won't be had from the 
outside unless the internal device keeps itself "registered" with the ISP 
router.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Jul 2011 12:31:01 -0400

I asked our PMs about this after some earlier discussions, and for many 
BRAS deployments of IPv6, this restriction is a natural side-effect of 
normal and desired behavior.
I do not know what the feature name is as used in product.
(I worry more about what it does, not what it is called in the 
marketting literature.  Sorry.)

Yours,
Joel

On 7/13/2011 12:07 PM, Mikael Abrahamsson wrote:
>> operates on the basis that it gets registration information from all
>> the devices in the home. Thus, it does not need to generate ND
>> solicitations.
>
> Just to be sure, we're now saying that reachability won't be had from
> the outside unless the internal device keeps itself "registered" with
> the ISP router.
>

---

From: Philip Homburg <[email-masked]>
Date: Wed, 13 Jul 2011 18:52:42 +0200

>2^64 different addresses to spoof and it can send NS request at any

I guess I completely misunderstand what your are trying to say. Without
specific L2 and L3 measures, already today, a local attacker can send
NS requests for around 2^64 different addresses.

Nothing I proposed changes that.

So, I said I want to deal with a remote attack. And then you suggested that
I made local attacks worse. 

But now you mention a local attack works already today.

So I missing the point to are trying to make.

---

From: Jared Mauch <[email-masked]>
Date: Wed, 13 Jul 2011 13:01:40 -0400

> 2^64 different addresses to spoof and it can send NS request at any

I think what's most interesting is that the nature of the "threat" on the IPv6 capable Internet is the ability to generate high PPS rate activity easily.  One needs to look no further than the risk and high PPS attacks on the IPv4 side of things.  It's quite reasonable to expect to have 10k or more unique hosts(source IPs) participating in an attack.

If you are a CDN, Major Web Property, or even Residential provider your risk in IPv4 is one per host or routed IP.  The scale involved here is much larger by design, and the potential of a poorly behaving NDP implementation to be overwhelmed is quite easy.  Not many vendors can handle 10k or 100kpps in their control-plane.

To (re)state the biggest design issue with NDP again, it's outlined in 7.3 of the v6nd-enhance draft:

-- snip --
7.3.  NDP Protocol Gratuitous NA

   Per RFC 4861, section 7.2.5 and 7.2.6 [RFC4861] requires that
   unsolicited neighbor advertisements result in the receiver setting
   it's neighbor cache entry to STALE, kicking off the resolution of the
   neighbor using neighbor solicitation.
-- snip --

Forcing an entry to STALE if you see an unsolicited NA (assuming it matches the existing NA) seems unnecessary and counterproductive as it can interrupt traffic to existing hosts.

Solving a remotely-exploitable specification problem is much different than solving a layer-2 compromise.  Those are different risks and require a different solution and mitigation, (eg: duplicate IP detection in v4 and various layer-2 security features dhcp-guard, etc).

- Jared

---

From: "George, Wesley" <[email-masked]>
Date: Wed, 13 Jul 2011 14:14:31 -0400

For some value of "normal and desired" anyway... Smells like a major scale problem to me for the BRAS to have to maintain that much state, at least if you're not making a distinction between devices which are directly connected (one pc directly connected to the modem, or a couple hanging off of a switch directly connected to the modem) and those who have a router (even if it's not NATing) in between and potentially many more devices connected behind it.

At least for the case with a router, the alternative is to use IPv6 Prefix Delegation and allow the downstream CPE router to handle the registration (be it ND or DHCP) of the devices within the local network. It doesn't eliminate the problem of ND DoS, but it does abstract it from the ISP router. Unfortunately it probably pushes it onto a router that is even less capable of handling the issue without dying, but that's still preferable to killing the ISP router and affecting many more customers at once.

Thanks,

Wes George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, July 13, 2011 12:31 PM
To: Mikael Abrahamsson
Cc: [email-masked]
Subject: Re: /64 ND DoS

Yours,
Joel

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.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 13 Jul 2011 14:35:03 -0400

> I suppose the same might be true of ARP. Has it been observed in the wild?

same does happen with arp, yes... and yes, observed in several fields.

---

From: james woodyatt <[email-masked]>
Date: Wed, 13 Jul 2011 17:04:07 -0700

> that runs on top of IPv6.

I don't believe there are any implementations, but I did propose a system to do this:

  <http://tools.ietf.org/html/draft-woodyatt-ald>

It provoked an interesting and illustrative discussion once people understood just what ubiquitous deployment of a protocol to do this would mean for Internet privacy.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Thomas Narten <[email-masked]>
Date: Wed, 20 Jul 2011 22:36:40 -0400

playing catchup ...

> Forcing an entry to STALE if you see an unsolicited NA (assuming it
>  matches the existing NA) seems unnecessary and counterproductive as
>  it can interrupt traffic to existing hosts.

It shouldn't.

A STALE entry is still usable, but it's a flag that says "verify that
this entry is still correct, it may no longer be correct". You then
wait a little while, and hope that TCP connections that are flowing
through the specific entry get ACKs for the data they are sending,
which in turn should get the state changed back to VALID. All without
any additional ND traffic.

Only if a node is sending traffic to a neighbor in a STALE state, and
no TCP "forward progress" indications (i.e. ACKs) are updating the
entry, then you send out a a (unicast) NS.

Changing the above text in RFC cited above would significantly change
the robustness of NUD. One would no longer detect failures where
connectivity between neighbors is only unidirectional.

I also do not understand how such a change would actually address the
problem described in draft-gashinsky-v6nd-enhance-00.txt.

Thomas