Subject: [v6ops] Fwd: Fwd: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt

From: Ray Hunter <[email-masked]>
Date: Mon, 24 Oct 2011 21:46:57 +0200

> It populates this cache upon receiving Rotuer Solicitation or 
Neighbor Advertisement messages from hosts on the subnet.

It does seem to eliminate the requirement for a router to maintain an 
entry in local memory with an "incomplete" state for ND triggered by a 
packet from an off-link node on the WAN side, which I do think is the 
crux of the worry for most people. So I can see the initial thought 
behind it.

What are the implications at L2?

IMHO The (new) router that has just booted up generally won't see any 
solicited neighbor advertisements on a switched network as they must be 
sent to the unicast (MAC) address when replying to specific neighbor 
solicitations (section 7.2.4 of RFC4861).

So the proposed solution would seem to presume that the router is 
listening for Unsolicited Neighbor Advertisements and Router 
Solicitation messages sent to the link-local all nodes multicast address.

What event prompts a normal end host to send an Unsolicited Neighbor 
Advertisement?

Section 7.2.6 of RFC4861 is a bit vague for me for when an Unsolicited 
Neighbor Advertisement should be triggered, and seems mainly to be 
targeted at proxies and other special nodes or at interface transition 
events. "In such cases, a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT 
unsolicited Neighbor Advertisement messages to the all-nodes multicast 
address."

Note that it's a MAY and not a SHOULD so I have no idea what typical 
implementations really do in practice.

But it does explicitly state that "they [Unsolicited Neighbor 
Advertisements] should only be viewed as a performance optimization to 
quickly update the caches in most neighbors." which doesn't seem very 
reliable to me.

Equally for router solicitation, section 4.1. states that "Hosts send 
Router Solicitations in order to prompt routers to generate Router 
Advertisements quickly."

6.3.7 defines when to send Router Solicitations. They look like pretty 
rare events to me.

If the end node has already discovered one or more default routers that 
have advertised very generous lifetimes, what would trigger the end node 
to multicast a new router solicitation request (to populate the remote 
ND cache on a router just booting up)?

In fact sending excessive Router Solicitations is explicitly prohibited: 
"Once the host sends a Router Solicitation, and receives a valid Router 
Advertisement with a non-zero Router Lifetime, the host MUST desist from 
sending additional solicitations on that interface, until the next time 
one of the above events occurs."

It thus seems to me to be a bit hit and miss (unless I've got my 
reasoning wrong of course)
The efficiency and essentially silent nature of ND seems to be against 
you here.

If you're going down this approach of routers effectively passively 
waiting for end-nodes to register themselves (via an Unsolicited 
Neighbor Advertisements and Unsolicited Router Advertisements) what is 
the advantage of this approach over defining a new explicit registration 
transaction such as that defined in 6LoWPAN? You'd still need existing 
ND for on-link host to host traffic of course.

regards,
RayH

> Subject:
> [v6ops] Fwd: Fwd: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt
> From:
> Joel jaeggli <[email-masked]>
> Date:
> Mon, 24 Oct 2011 06:22:40 -0700
>
> To:
> IPv6 Ops WG <[email-masked]>
>
> Content-Transfer-Encoding:
> 7bit
> Precedence:
> list
> MIME-Version:
> 1.0
> References:
> <[email-masked]>
> In-Reply-To:
> <[email-masked]>
> Message-ID:
> <[email-masked]>
> Content-Type:
> text/plain; charset=ISO-8859-1
> Message:
> 1
>
>
> This document is germain to the problem of IPv6 neighbor discovery.
>
> joel
>
> -------- Original Message --------
> Subject: Fwd: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt
> Date: Fri, 21 Oct 2011 10:44:23 -0400
> From: Joel M. Halpern<[email-masked]>
> To:[email-masked]  <[email-masked]>
>
> I would like to call people's attention to the draft below.
> I would like to hear from folks as to what they think of this complement
> to some of the existing work on the ND based denial of service attack.
> I do not intend to present this at the WG meeting, as I would like a
> chance to hear from folks first.
>
> Yours,
> Joel
>
> -------- Original Message --------
> Subject: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt
> Date: Mon, 17 Oct 2011 14:17:09 -0700
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> 	Title           : Mitigating Neighbor Discovery Based Denial of Service
> Attacks
> 	Author(s)       : Joel M. Halpern
> 	Filename        : draft-halpern-6man-nddos-mitigation-00.txt
> 	Pages           : 6
> 	Date            : 2011-10-17
>
>     It has been observed that with the large space of IPv6 addresses
>     within a subnet, remote attackers can send packets that saturate a
>     rotuers ND cache, and potentially saturate a subnet with ND
>     Soliciation messages as well.  Some operational techniques and small
>     protocol adjustments have been proposed that can help alleviate this
>     problem.  This draft proposes a slightly more drastic optional
>     behavior for routers, which can nearly eliminate this problem.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-halpern-6man-nddos-mitigation-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-halpern-6man-nddos-mitigation-00.txt
> _______________________________________________
>

---

From: Ray Hunter <[email-masked]>
Date: Mon, 24 Oct 2011 22:21:44 +0200

Don't get me wrong, I'd like this to be a solution, but I don't see the 
proposed workarounds being "good enough" either.
Thanks for keeping the discussion going though.

 > keep sending Router Solicitation messages

Destroys the silent nature of ND: one of the design goals. And is 
doesn't cover the case of potentially multiple IPv6 addresses per node 
(proxies etc.)

 > could deefine a "please respond" flag in the Router Advertisement

Potentially causes a storm on links with large numbers of end nodes all 
trying to reply simultaneously.
You can then talk about throttling, or random back off, but it's still 
likely to be a problem to make this anywhere near reliable.

 > One thing the existing router could do, which would provided the 
needed robustness, is to cause all the hsots it knows about to send new 
Neighbor Advertisements.  It can do this by sending each host a  Neghbor 
soliciation with a source address of the unspecified address. This will 
cause the host to multicast the Neghbor Advertisement it responds with.

Again incredibly chatty and requires each router to cycle through its ND 
table to refresh the cache. That could end up as quite an intensive 
process for a busy router. Or be quite expensive on a link with many 
routers.

IMHO You may as well then define that end nodes should send Unsolicited 
Neighbor Advertisements on a periodic basis, so that they advertise 
their IPv6 addresses to the all routers address (note all routers, not 
all nodes), so as to refresh all of the routers' ND caches periodically 
and simultaneously. But that's not really that different from your "keep 
on sending Router Solicitation messages" except that they don't trigger 
any RA processing.

 > an operational router on the subnet could send its neighbor cache to 
the new router

Possible, but unlikely to become an open standard.

My personal favorite solution (posted some time ago) is extending SLAAC 
so that it can work with VLSM beyond 64 bits.
My guess is that that idea may not prove very popular. The other 
feasible alternative IMHO is to copy existing work from 6LoWPAN.

regards,
RayH

Joel Halpern wrote:
> Yes, the sequence of thoughts starts from wanting to eleiminate teh 
> incomplete entries.
> And then notices that there needs to be a way to cope when a router 
> comes up late in teh cycle.
> If, although late, it is still teh first router advertising a given 
> prefix on teh LAN, then things work out.
> But, clearly, we can not assume that ordering.
> So the last part of the draft describes a series of mechanisms 
> specifically aimed at coping with that condition.  I think that they 
> cover all the cases, but I could be wrong.
> Yours,
> Joel
>
> ------------------------------------------------------------------------
> *From:* Ray Hunter [mailto:[email-masked]]
> *Sent:* Monday, October 24, 2011 3:47 PM
> *To:* Joel Jaeggli; Joel Halpern
> *Cc:* [email-masked] WG
> *Subject:* [v6ops] Fwd: Fwd: I-D Action: 
> draft-halpern-6man-nddos-mitigation-00.txt
>
> solicited neighbor advertisements on a switched network as they must 
> be sent to the unicast (MAC) address when replying to specific 
> neighbor solicitations (section 7.2.4 of RFC4861).
>
> events. "In such cases, a node MAY send up to 
> MAX_NEIGHBOR_ADVERTISEMENT unsolicited Neighbor Advertisement messages 
> to the all-nodes multicast address."
>
> If the end node has already discovered one or more default routers 
> that have advertised very generous lifetimes, what would trigger the 
> end node to multicast a new router solicitation request (to populate 
> the remote ND cache on a router just booting up)?
>
> In fact sending excessive Router Solicitations is explicitly 
> prohibited: "Once the host sends a Router Solicitation, and receives a 
> valid Router Advertisement with a non-zero Router Lifetime, the host 
> MUST desist from sending additional solicitations on that interface, 
> until the next time one of the above events occurs."
>
> the advantage of this approach over defining a new explicit 
> registration transaction such as that defined in 6LoWPAN? You'd still 
> need existing ND for on-link host to host traffic of course.
>
> regards,
> RayH
>
>> Subject:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 24 Oct 2011 16:41:30 -0400

While I could quibble about the rest of the analysis, I will leave that 
for other folks to judge on their own.

It seems pretty clear to me, and from conversation also to some other 
people, that the solution of resending the RS messages is the right long 
term solution.  The issue of having multiple prefixes clearly can be dealt.
Your primary objection seems to be that this violates the "silent 
nature" of ND.  Maybe it does.  Maybe experience is teaching us that was 
not as good a trade-off as we thought.

Yours,
Joel

---

From: Ray Hunter <[email-masked]>
Date: Tue, 25 Oct 2011 08:43:05 +0200

I'm not strongly objecting: I'm just exploring the consequences and 
trying to stimulate the debate. I'd like a solution for DOS attacks as 
much as anyone else.

So then indeed there is a trade off to be made of how noisy you find it 
acceptable for ND to be by default versus overall reliability.

Given that 6LoWPAN found even the current specification of ND too 
chatty, and went ahead and developed their own solution, it could be 
argued that the design goal of low chattiness should be de-weighted for 
vanilla ND, and we accept that there'll be two ND implementations with 
different design goals.

On the other hand, multicast is an expensive operation. The days of LANs 
being passive buses are long gone, and multicast actually has to be 
emulated in silicon. Any increase in chattiness will likely impose an 
upper limit on the number of nodes per link, that is probably much lower 
than the limit with today's ND.

And the concern about router solicitation being inadequate isn't just 
multiple prefixes: it's also multiple addresses within one prefix on one 
interface. There's plenty of devices that operate in high availability 
mode with address take-overs. It also loses the solution to the 
half-open pipe problem, which means ND is no longer a reliable 
indication of two-way communications being possible. How are you going 
to do reachability confirmation if the router does not send out Neighbor 
Solicitation messages?

It could then be argued that the right option is to place the initiative 
for address registration with the end node. I shudder to mention LANE 
type solutions, where there could be an explicit IP address to media 
address translation service independent of the routers. Each end node 
would then register with this name translation service. That name 
resolution service could also be used for local resolution, as well as 
the off-link case. But that registration could run on anycast or a 
well-known unicast address, rather than multicast or broadcast. Highly 
disruptive to today's implementations of course.

So I'd like to see more investigation of the practical knock on effects, 
especially at L2, before coming to a conclusion and backing any 
particular solution.

regards,
RayH

Joel M. Halpern wrote:
> While I could quibble about the rest of the analysis, I will leave 
> that for other folks to judge on their own.
>
> people, that the solution of resending the RS messages is the right 
> long term solution.  The issue of having multiple prefixes clearly can 
> be dealt.
> nature" of ND.  Maybe it does.  Maybe experience is teaching us that 
> was not as good a trade-off as we thought.
>
> Yours,
> Joel
>

---

From: Philip Homburg <[email-masked]>
Date: Tue, 25 Oct 2011 14:28:24 +0200

(Do we want this discussion in v6ops if the draft belongs to 6man?)

>than the limit with today's ND.

One question that needs to be answered is whether we want to completely replace
ND or augment it to just deal with an ND attack.

My preference is to just survive an attack. 

The advantage of the multicast option is that it doesn't require any protocol
changes. The disadvantage is that it will never work on networks where
multicast is very expensive (for example wifi).

On other networks, for example a wired network in a datacenter, MLD snooping
may even reduce the impact on the actual network to almost zero. Of course that
does require routers that can generate NS messages at wire speed and switches
that can do multicast filtering/forwarding also at wire speed.

Going beyond that, a 'please register option' in an RS message can be sent
always by a router to ensure that the router always has a complete list
of neighbors or just when the router is under attack.

Doing it always makes ND more chatty but may simplify router design. And also
weeds out bad hosts. 

Doing it only when under attack makes to option more error prone (because it is
not used until it is really needed) but doesn't cause any load on the network
during normal operation.

>It also loses the solution to the 

There is of course some interaction with NUD, but to a large extent that is
a separate problem. A router can use any of the techniques that protect against
a DoS to find out where a node is (find its link layer address) and then use
point-to-point communication for verifying the reachability of the node.

---

From: Joel Halpern <[email-masked]>
Date: Mon, 24 Oct 2011 15:50:58 -0400

Yes, the sequence of thoughts starts from wanting to eleiminate teh incomplete entries.
And then notices that there needs to be a way to cope when a router comes up late in teh cycle.

If, although late, it is still teh first router advertising a given prefix on teh LAN, then things work out.
But, clearly, we can not assume that ordering.
So the last part of the draft describes a series of mechanisms specifically aimed at coping with that condition.  I think that they cover all the cases, but I could be wrong.

Yours,
Joel

________________________________
From: Ray Hunter [mailto:[email-masked]]
Sent: Monday, October 24, 2011 3:47 PM
To: Joel Jaeggli; Joel Halpern
Cc: [email-masked] WG
Subject: [v6ops] Fwd: Fwd: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt

> It populates this cache upon receiving Rotuer Solicitation or Neighbor Advertisement messages from hosts on the subnet.

It does seem to eliminate the requirement for a router to maintain an entry in local memory with an "incomplete" state for ND triggered by a packet from an off-link node on the WAN side, which I do think is the crux of the worry for most people. So I can see the initial thought behind it.

IMHO The (new) router that has just booted up generally won't see any solicited neighbor advertisements on a switched network as they must be sent to the unicast (MAC) address when replying to specific neighbor solicitations (section 7.2.4 of RFC4861).

So the proposed solution would seem to presume that the router is listening for Unsolicited Neighbor Advertisements and Router Solicitation messages sent to the link-local all nodes multicast address.

What event prompts a normal end host to send an Unsolicited Neighbor Advertisement?

Section 7.2.6 of RFC4861 is a bit vague for me for when an Unsolicited Neighbor Advertisement should be triggered, and seems mainly to be targeted at proxies and other special nodes or at interface transition events. "In such cases, a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited Neighbor Advertisement messages to the all-nodes multicast address."

Note that it's a MAY and not a SHOULD so I have no idea what typical implementations really do in practice.

But it does explicitly state that "they [Unsolicited Neighbor Advertisements] should only be viewed as a performance optimization to quickly update the caches in most neighbors." which doesn't seem very reliable to me.

Equally for router solicitation, section 4.1. states that "Hosts send Router Solicitations in order to prompt routers to generate Router Advertisements quickly."

6.3.7 defines when to send Router Solicitations. They look like pretty rare events to me.

If the end node has already discovered one or more default routers that have advertised very generous lifetimes, what would trigger the end node to multicast a new router solicitation request (to populate the remote ND cache on a router just booting up)?

In fact sending excessive Router Solicitations is explicitly prohibited: "Once the host sends a Router Solicitation, and receives a valid Router Advertisement with a non-zero Router Lifetime, the host MUST desist from sending additional solicitations on that interface, until the next time one of the above events occurs."

It thus seems to me to be a bit hit and miss (unless I've got my reasoning wrong of course)
The efficiency and essentially silent nature of ND seems to be against you here.

If you're going down this approach of routers effectively passively waiting for end-nodes to register themselves (via an Unsolicited Neighbor Advertisements and Unsolicited Router Advertisements) what is the advantage of this approach over defining a new explicit registration transaction such as that defined in 6LoWPAN? You'd still need existing ND for on-link host to host traffic of course.

regards,
RayH

Subject:
[v6ops] Fwd: Fwd: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt
From:
Joel jaeggli <[email-masked]><mailto:[email-masked]>
Date:
Mon, 24 Oct 2011 06:22:40 -0700
To:
IPv6 Ops WG <[email-masked]><mailto:[email-masked]>
Content-Transfer-Encoding:
7bit
Precedence:
list
MIME-Version:
1.0
References:
<[email-masked]><mailto:[email-masked]>
In-Reply-To:
<[email-masked]><mailto:[email-masked]>
Message-ID:
<[email-masked]><mailto:[email-masked]>
Content-Type:
text/plain; charset=ISO-8859-1
Message:
1

joel

-------- Original Message --------
Subject: Fwd: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt
Date: Fri, 21 Oct 2011 10:44:23 -0400
From: Joel M. Halpern <[email-masked]><mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

Yours,
Joel