Subject: Re: Should SEND deal with Remote ND DoS attack ?

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 02 Dec 2002 20:50:48 -0500

> Being the one who proposed the threat in the draft,
> I have to admit, it's a different beast than the other ones.
> A possible solution is to rely on a complete table of
> IPv6 addresses used on a link on the access routers (i.e,
> like a neighbor table instead of a neighbor cache). 

You should probably rate-limit neighbor solicitations to
previously-unseen neighbors (multicast is effectively broadcast on
some links).
   
This is also pretty similar to the SYN flood problem, and the
engineering solution which worked well for SYN floods should also work
here: do something more clever than tail drop when the cache is full.

Hosts should worry about this problem as well.

						- Bill
--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 2 Dec 2002 18:14:37 -0800

> here: do something more clever than tail drop when the cache is full.

Attack can be taxing both on the limited neighbor cache of the 
router and on the limited bandwidth resources. (broadcast
is effectively one unicast per host on some links).

> Hosts should worry about this problem as well.

I didn't get this part. If this host is not routing,
why does it have to resolve arbitrary IP addresses?
(unless it's being abused by an application attempting
to send packets to arbitrary on-link destinations)

alper

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 02 Dec 2002 22:04:39 -0500

> to send packets to arbitrary on-link destinations)

Bingo.  And in many cases I suspect it's very easy to trigger that
sort of thing.

				  - Bill

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 03 Dec 2002 09:48:11 +0200

I added the following pieces of text to the draft:

    In a way, this problem is fairly similar to the TCP SYN flooding
    problem.  Rate limitating Neighbor Solicitations, restricting the
    amount of state reserved for unresolved soliciations, and clever
    cache management should be applied.

    It should be noted that both hosts and routers need to worry about
    this problem.  The router case was discussed above.  Hosts are also
    vulnerable since the neighbor discovery process can potentially be
    abused by an application that is tricked into sending packets to
    arbitrary on-link destinations.

Satisfied?

-----

Now back to the process question:

   1. Should SEND address this or should we kick this back to IPV6?

   2. If SEND should address this, should it be addressed
        a) in the psreq draft, and eventually in the
           Informational RFC that results,
        b) in a separate Standards track draft/RFC?
        c) somewhere else?

--Pekka Nikander

---

From: Pars Mutaf <[email-masked]>
Date: Tue, 03 Dec 2002 17:10:04 +0100

> here: do something more clever than tail drop when the cache is full.

There is no engineering solution that worked well for SYN-flooding.
Therefore
SYN-cookies approach has been proposed and it is used today (although it
introduces some other problems, people prefer it). In SYN-cookies, the
target
takes the advantage of the TCP 3-way handshake to check the attacker's
return routability before allocating resources.

In ND DoS attack you don't have such a possibility. I think we shouldn't
compare this attack with SYN flooding. Both are DoS attacks OK, but the
way
the attack is mounted and defense possibilities are completety different.

pars

---

From: Pars Mutaf <[email-masked]>
Date: Tue, 03 Dec 2002 18:03:56 +0100

>     cache management should be applied.

Hello,

IMVHO, the above text is misleading.  The result of rate limiting
Neighbor Solicitations would be buffer overflow or session setup
delays. Restricting the amount of state reserved would result in
denial-of-service to new legitimate correspondent nodes. So, I don't
see how the above text will solve the problem.

pars

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 03 Dec 2002 14:50:40 -0500

> There is no engineering solution that worked well for SYN-flooding.

This is quite simply false.  For a line-rate SYN flood, you just need
to be able to "absorb" a bit over a delay-bandwidth product or so of
outstanding syn's so the good connections can ACK the SYN/ACK while
the duds just age out.

see (among other places):

http://people.freebsd.org/~jlemon/papers/syncache.pdf

(as the paper cites, similar work was done earlier on BSDI and
NetBSD; something similar is also in solaris).

In the case of the "remote ND DoS" attack, the "delay" part is the
delay across the local link, which in many cases of interest to this
WG will be relatively small.

						- Bill

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 3 Dec 2002 17:35:57 -0800

>     cache management should be applied.

do we really want to get into solution space in this document?
I guess not.

alper

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Tue, 3 Dec 2002 17:43:11 -0800

> Bingo.  And in many cases I suspect it's very easy to trigger that

Actually, to go one step further, I think we can see two
different attacks here.

The malicious application might be running on the victim host.
For each different on-link destination this app attempts to
send a packet to, associated state is created in the neighbor
cache, hence a way to deplete resources. (well, there are other
resources this malicious app can suck up too).

The other is, there might be a malicious host on the same link, 
and sending, say ping packets, with random on-link source addresses. 
Again, each corresponding icmp echo replies will create a neighbor cache
entry on the victim host. This type of threat is not available
to off-link attackers since ingress filtering routers won't let
their packet come in.

alper

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 04 Dec 2002 10:32:27 +0200

> do we really want to get into solution space in this document?

Well, in Section 1 it is stated:

    This document occasionally discusses solution proposals, such as
    CGA [CGA] and ABK [ABK].  However, the discussion is solely for
    illustrative purposes.  It is meant to give the readers a more
    concrete idea of some possible solutions.  It does NOT indicate any
    preference on solutions on the behalf of the authors or the working
    group.

Thus, I think it is safe to include such a vague solution proposal,
isn't it?  Well, I changed the wording to be more suggestive:

   "should be" -> "may be"

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 04 Dec 2002 10:47:18 +0200

> see how the above text will solve the problem.

Well, if you don't do anything for a DoS attack, you are in trouble,
too.  Besides, IP is a stateless protocol.  Thus, if your router
can't deliver some packet due to ND failing under a DoS attack,
you can always try again.

Do you have some better suggestion in mind?  Remember, the solutions
proposal text in this document is only suggestive, not normative.

--Pekka Nikander

---

From: Pars Mutaf <[email-masked]>
Date: Wed, 04 Dec 2002 11:47:30 +0100

> you can always try again.

I think it depends on the rate of Neighbor Solicitations and the
attacker's
flooding capacity. If there are 10000 malicious packets waiting in the
queue
and served at a limited rate, then the subnet will be temporarily
disconnected.
You can limit the queue size of course, but the attacker can easily fill
it up in
this case.

But, having no better solution in mind :-) I would only suggest
to reconsider the SYN-flooding comparison (really different protocol
and different attack) and may be considering the possible side
effects of the proposed solutions.

The above text gives the impression that the defense is trivial, which
would be misleading IMHO.

Thanks,

pars

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 04 Dec 2002 13:07:34 +0200

> would be misleading IMHO.

Personally I have difficulties understanding your position.
However, I want to be here very open minded and listen carefully.

Would you please tell us why, exactly, do you think that this
is so different from TCP SYN-flooding situation?  In both
cases someone needs to preserve resources for handling a
packet that comes from an unknown source.  Same kind of
solutions, engineering or cookie-like, probably apply.

Your model of queuing up requests is sure to lead to a bad
situation.  However, what I tried to suggest in the draft was
a combination of rate limitation, limited memory space, and clever
cache/queue management.  That is, you drop packets that require
ND already when they arrive at router (most routers do that
already now?), and if you wait-for-NA memory is already
full, use some probabilistic algorithm to either drop something
from that memory or don't send the NS at all.  You still have
some probability for the good packets to succeed.  Remember
that it is a rather rare situation that you have a non-communicating
host on a link, and you suddenly receive a packet destined to
that host.  It is much more usual that the host becomes
active itself, or that a packet arriving from outside
is destined to a host that is already active.

If we think about a typical situation where the local link
is much faster than the remote link, e.g., 100 Mbs Ethernet
vs. 2 Mbps DSL, you can get maybe something like 50 000
packets per second from the remote link.  If we think that
each of these causes ND, and the typical RTT over the local
link is at max 10ms, you need a buffer for 500 (or maybe 1000)
outstanding ND requests.  That is much, but maybe not too much.
If you rate limit your ND requests to 1000 per second, much
smaller memory (just 20 outstanding requests) is enough, but
it will take much longer for a new host in the network to
gain connectivity.

Sigh, the more I write the more details come to my mind,
and I wouldn't like to go into very details in an e-mail.

Maybe somebody could write a brief drafty draft about this?

I'd like to hear the opinion of the other WG members on this.
Comments, please!

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 04 Dec 2002 14:18:51 +0200

Pars Mutaf wrote:
> so I wanted to make sure that I understand correctly. For example
> I don't understand how a cookie can apply to this attack
> without changing the correspondent node implementation etc.
> 
> I thought that the attack was different from SYN-flooding because
> you can't solve it using cookies for example.

Well, SEND is all about *changing* ND to make it more secure.
I could easily imagine a situation where a router includes
a cookie in an NS message, and expects the host to include
the same cookie in its NA response.  In that way we could
avoid creating state in the router when it receives a packet
from the outside and needs to perform ND.

But I'm not a particular fan of that solution.  IMHO,
traditional engineering seems to be a better solution here.
But, as I said, I am listening, or at least trying to.

Actually, Pars, I would encourage you to write a personal
draft about the various ways you think this problem could
be solved.  Or even just to specify the problem more clearly,
and try to quantify it with a number of scenario examples,
e.g. a busy server LAN a la Google, a root DNS server LAN,
a home network with DSL/Cable connection, etc.  That would
help us to better understand the scale of the problem.

--Pekka Nikander

---

From: [email-masked] (Parijat)
Date: Thu, 5 Dec 2002 01:24:43 +0800

---end quoted text---

Does it have to be a mailicous application?  I can't think of any, but
are there (genuine) applications using protocols that would try to connect to any host whose IP(v6) address they received, say in the payload of a message?

Hope nonesuch were blesses by IETF ;-)

-- 
Sincerely,
Parijat Mishra
R & D Engineer,
Institute for Communications Research
Tel: (65)68709353

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 04 Dec 2002 12:29:25 -0500

> This type of threat is not available to off-link attackers since
> ingress filtering routers won't let their packet come in.

I think you're being overly optimistic.

Large fractions of the ipv4 internet do not do ingress filtering.  

It's not clear whether v6 routers do ingress filtering in their
default out-of-box config (and I rather suspect that they won't)

I predict that large fractions of the v6 network will not do ingress
filtering and thus it is conservative/defensive to assume it won't
always be there.

						- Bill

---

From: "James Kempf" <[email-masked]>
Date: Wed, 4 Dec 2002 10:51:14 -0800

Bill,

Actually, this is likely to change. The Feds (National CyperSecurity Task Force)
are going to put a whole bunch of money into educating ISPs about security.
Ingress filtering is on the top of the list of easy measures to make the
Internet more secure. Of course, the ISPs might not choose to act, but if they
don't the Feds may get a little more proactive about requiring it. If there are
easy ways to do the design such that it will work with and without ingress
filtering, then I don't see much problem with including them. On the other hand,
I don't think we need to put in complex features to get around bad BCP.

            jak

----- Original Message -----
From: "Bill Sommerfeld" <[email-masked]>
To: "Alper E. YEGIN" <[email-masked]>
Cc: <[email-masked]>; "Pekka Nikander" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, December 04, 2002 9:29 AM
Subject: Re: Should SEND deal with Remote ND DoS attack ?

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 4 Dec 2002 11:27:50 -0800

> I think you're being overly optimistic.

I should clarify: ingress filtering tool is available to
network administrators to prevent this type of attacks. 
Whether they use it or not, is their problem. They should
be aware of the risk of not using it.

The final solution might be suggesting administrators
to use the collection of SEND + ingress filtering + 
some_other_existing_mechanisms. If they fail to use
the right ingredients, solution might fail.

> filtering and thus it is conservative/defensive to assume it won't

I think mechanism/protocol re-use is a good thing, and we should
advocate it as much as possible. At the end, SEND may require
ingress filtering be turned on at the access routers. This
requirement might be part of the solution if needed, imo.

alper

---

From: Pekka Savola <[email-masked]>
Date: Wed, 4 Dec 2002 22:25:21 +0200 (EET)

> the right ingredients, solution might fail.

I believe Alper meant 'egress filtering' here.

(The terminology _is_ confusing, and I'm not sure even I got it 100% 
right.)

That is, there are two types of source address filtering:

 a) site X configures a filter at its edge to prevent addresses of site X
from coming from Internet to site X

(often called egress filtering)

 b) ISP Y configures a filter at its edge to prevent addresses other than
those of site Z (customer of ISP Y) from arriving from the direction of
site Z.

(often called ingress filtering)

I think Bill may have been referring to b) by the more common terminology
-- and we cannot assume b) will be used.

But it may be perfectly OK to assume a) _is_ if it makes our life easier
(often, it does) -- because that's _your network_ to configure, not
everybody else's in the Internet.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 04 Dec 2002 16:05:58 -0500

let me reiterate my stance on the filtering issue:

from a robustness point of view, it would be poor for a mobile host to
assume that the network it's visiting is "appropriately"
ingress/egress filtered.

it may be filtered.  it may not be.  if at all possible our design
should make minimal assumptions either way.

					- Bill

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 04 Dec 2002 18:39:31 -0500

> If there are easy ways to do the design such that it will work with
> and without ingress filtering, then I don't see much problem with
> including them. On the other hand, I don't think we need to put in
> complex features to get around bad BCP.

once again, a BCP for security is "don't assume that entities you
don't control are doing the right thing."

						- Bill