Subject: [v6ops] preventing denial of service in IPv6

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 23 Oct 2015 11:58:13 +0200

[this was originally sent to saag list, and I'm resending it here as
this list is focused on IPv6]

I've been looking on ways to prevent denial of service on a server
application, and I stumbled on IPv6. By denial of service, I mean
exhaustion of resources, being memory or CPU.

Unlike IPv4, in IPv6 a user may typically have 2^64, and more able adversaries
may have 2^80 or even more addresses(*). That means that single IP
blacklisting to prevent DoS is not going to work; not even against a
single adversary who has 2^64 IPs. So one would expect software to
blacklist whole ranges of networks, e.g., a /64 or /48 once few IPs
violate some of its "detection properties".  Given recommendations
like RFC6164 which recommend /127 for PtP links (which can be a user
VPN link), any heuristic that will ban whole networks looks more like
a vessel to perform another denial of service (e.g., denying some user
access to a server), rather than a solution to the original denial of
service. This is further reinforced by the fact that smaller than /64 networks
are occasionally handed out by ISPs to their users.

Are there any recommendations for protecting servers from the IPv6
address proliferation? If not, are there any conventions for IPv6
address assignment to end-users?

regards,
Nikos

[0]. rfc6177 is supposed to describe the best current practice, but it
mostly focuses on what isn't the current best practice (i.e., /48 is
not recommended any more)

---

From: Philip Homburg <[email-masked]>
Date: Fri, 23 Oct 2015 14:19:31 +0200

>address assignment to end-users?

I think the real problem is at a different level.

A first start is to define a policy on how many individual entries you
want to have before you escalate.

For example, you can have a policy that you can have block list entries for
256 /128s in a /64 and then decide to block the /64. Have 256 /64s and
block a /48, etc. (Typically also, have abuse from 256 different /64s in a /48
and block the /48).

Using BGP dumps you can efficiently find out what netblocks belong to a single
AS. So you can find out if a collection of /48s are part of a single /32 or not.
(Taking information from BGP is way easier than trying to parse whois)

This mostly requires real world experience. Create a policy, watch what works
or doesn't work and refine it.

There are two harder to solve issues:
- An ISP may have customers and its own infrastructure in a single prefix.
  For example, for spam you may want to block all customer prefixes but then
  that can result in blocking the ISP's smarthosts as well. 
- If you were to publish the block list in DNS as a DNSBL then you may hit
  (lack of) caching issues. There is a proposal for dealing with that, no
  idea how wide spread the implementation is.

---

From: "Metzler, Dan J" <[email-masked]>
Date: Fri, 23 Oct 2015 13:18:04 +0000

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Nikos
> Mavrogiannopoulos
> Sent: Friday, October 23, 2015 4:58 AM
> To: [email-masked]
> Subject: [v6ops] preventing denial of service in IPv6
> 
> [this was originally sent to saag list, and I'm resending it here as this list is
> focused on IPv6]
> 
> application, and I stumbled on IPv6. By denial of service, I mean exhaustion
> of resources, being memory or CPU.
> 
> Unlike IPv4, in IPv6 a user may typically have 2^64, and more able
> adversaries may have 2^80 or even more addresses(*). 
[DJM] I'm not sure I understand that statement.  A router might have 64 bits of address space.
A typical user would have 1 - 3 addresses per network interface, with 1 typically used for outbound traffic at any given point in time.

> That means that
> single IP blacklisting to prevent DoS is not going to work; not even against a
> single adversary who has 2^64 IPs. 
[DJM] I would disagree with that assumption.  On the surface the problem seems little different from the same situation in IPv4.

> So one would expect software to blacklist
> whole ranges of networks, e.g., a /64 or /48 once few IPs violate some of its
> "detection properties".  

[DJM] I would think one would expect software to block a single IP address for IPv6 in the same scenarios where that would happen in IPv4.
Granted IPv6 makes it a bit easier to repeatedly change addresses, purely from an availability standpoint, in the same way that it makes it a bit harder to scan addresses.
I would expect blocking a /64 to be the equivalent of blocking a subnet in IPv4, because it is.

>Given recommendations like RFC6164 which
> recommend /127 for PtP links (which can be a user VPN link), any heuristic
> that will ban whole networks looks more like a vessel to perform another
> denial of service (e.g., denying some user access to a server), rather than a
> solution to the original denial of service. 
[DJM] Absolute agreement here, as is the case with IPv4.
A better approach would be to intelligently and dynamically block offending individual addresses, or sets of addresses, based off of more information than a simple assumption that if there is one offender on a subnet, then they all must be offenders. 
Of course one might want to block a whole subnet once some sort of critical threshold was reached of a certain number of offending IPs on that subnet.

> This is further reinforced by the fact
> that smaller than /64 networks are occasionally handed out by ISPs to their
> users.
> 
> Are there any recommendations for protecting servers from the IPv6 address
> proliferation? 
[DJM] Address proliferation doesn't seem like a vulnerability to protect against.
I think that would be deviating from the problem; the DOS attack.
DOS is largely a game of resources; attempting to allocate a large enough pool of resources, that participate in a DOS attack, so as to exceed the capacity of the finite resources dedicated to handling a load.  The fact that the resources instigating the attack has a larger pool of addresses, to use, doesn't change the amount of resources participating in the attack, or the number of addresses in use at a given point in time.
Also, the likelihood that a DOS attack would be  sourced entirely from a single subnet seems more and more of an edge case as time goes on.  (If it were only that easy.)

> If not, are there any conventions for IPv6 address assignment
> to end-users?
[DJM] Outside of the typical DHCPv6 and SLAAC?
Is this an ISP scenario?

> 
> regards,
> Nikos
> 
> [0]. rfc6177 is supposed to describe the best current practice, but it mostly
> focuses on what isn't the current best practice (i.e., /48 is not recommended
> any more)
[DJM] This definitely sounds more like an ISP scenario, if you're referencing 6177, but again, regarding DOS attacks, not sure the proliferation of addresses matters to the person trying to defend against an active DOS attack.

> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 23 Oct 2015 17:07:42 +0200

> block a /48, etc. (Typically also, have abuse from 256 different /64s in a /48

My point is exactly this disproportion. In this suggestion you add a
heuristic of 256 misbehaving addresses to block 2^64 addresses in
total (for a /64), and 256*256=2^16 mibehaving addresses to block 2^80
addresses. This will affect someone who has divided a /64 into 2^32
/96 subnets and shared it to different users, he will have his subnet
completely blocked even if only 256 out of 2^32 is misbehaving. We may
adjust these numbers as we like, but the disproportion will remain if
we want to keep reasonable memory consumption for the server.

I've been experimenting and attempting to account for smaller nets
such as /112 and /96, on the server side for DoS protection, but it
quickly becomes unmanageable due to memory needed to store these
tables, if you are under attack from an adversary with access to a /48
for example. So in the end some simple heuristic should be used as you
describe above, but it should be, if possible, documented, so it
becomes a common heuristic which is taken into account in address
allocation and by ISPs.

> (Taking information from BGP is way easier than trying to parse whois)

We currently don't need that information for basic IPv4 DoS
protection, it would be a petty if we have to require that for IPv6.

> or doesn't work and refine it.

That's what I'm afraid of. We end up with X vendors having X IP
blocking policies all different, which cause issues to different ISPs.

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 23 Oct 2015 17:26:31 +0200

> I would expect blocking a /64 to be the equivalent of blocking a subnet in IPv4, because it is.

Then a single user can exhaust a server's resources by simply
attacking the server with all his available addresses.

> Also, the likelihood that a DOS attack would be  sourced entirely from a single subnet seems more and more of an edge case as time goes on.  (If it were only that easy.)

IPv6 makes that easy. In IPv4 DOS attacks don't come from a single
subnet because it is expensive to obtain control of a big subnet. In
IPv6 you get 2^64 addresses just like that.

> [DJM] Outside of the typical DHCPv6 and SLAAC?

Could you elaborate what on that? I know that SLAAC requires /64 to
operate, but I'm not aware of any conventions for DHCPv6.

regards,
Nikos

---

From: Erik Nygren <[email-masked]>
Date: Fri, 23 Oct 2015 11:39:36 -0400

My colleagues David Plonka and Arthur Berger are presenting this paper at
IMC next week
which is of direct relevance to this topic:

David Plonka and Arthur Berger. "Temporal and Spatial Classification of
Active IPv6 Addresses".
Proceedings of the ACM Internet Measurement Conference (IMC), Tokyo, Japan,
October 28-30 2015.
http://arxiv.org/abs/1506.08134

http://conferences2.sigcomm.org/imc/2015/program.html

David will also be in Yokohama if people would like to ask him questions on
his research.

         Erik

On Fri, Oct 23, 2015 at 5:58 AM, Nikos Mavrogiannopoulos <[email-masked]>
wrote:

> adversaries

---

From: Gert Doering <[email-masked]>
Date: Fri, 23 Oct 2015 18:47:59 +0200

Hi,

On Fri, Oct 23, 2015 at 05:07:42PM +0200, Nikos Mavrogiannopoulos wrote:
> This will affect someone who has divided a /64 into 2^32
> completely blocked even if only 256 out of 2^32 is misbehaving. 

And rightly so.

There are enough IPv6 addresses available to NEVER give users less than
a /64 if they are given a "subnet".

So, someone doing this, and getting all his users blocked if a few of
them are misbehaving is getting what he deserves.  Period.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Enno Rey <[email-masked]>
Date: Fri, 23 Oct 2015 20:09:16 +0200

Hi,

> them are misbehaving is getting what he deserves.  Period.

wait a second.
what about a "Guest Wifi" network (implemented as a /64 - I mean, what else, and) shared by hundreds of users?
any of those users can still perform attacks with many many different source addresses... or am I overlooking sth here/misunderstanding the scenario laid out?

best

Enno

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================

---

From: Fernando Gont <[email-masked]>
Date: Fri, 23 Oct 2015 13:11:38 -0300

Hi, Nikos,

On 10/23/2015 06:58 AM, Nikos Mavrogiannopoulos wrote:
> violate some of its "detection properties". 

Yes. I'd expect that in those cases where in IPv4 you'd ban a single
IPv4, you'd likely ban a prefix in the IPv6 world (typically a /64).

You might want to re-ask your question on this list, too:
<http://www.si6networks.com/community/mailing-lists.html>

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Gert Doering <[email-masked]>
Date: Fri, 23 Oct 2015 22:20:38 +0200

Hi,

> any of those users can still perform attacks with many many different source addresses... or am I overlooking sth here/misunderstanding the scenario laid out?

What would you do in IPv4 land?  Right, block the single external IPv4
address of the Guest Wifi NAT router...

This usually gets the attention of those operating the network that 
they have something bad in their backyard.

With IPv6, one could do better, of course - reduce the amount of addresses
that a client can use (enforce first hop security), and/or delegate a 
dedicated prefix to the client (Lorenzo's recent draft)

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 24 Oct 2015 11:46:10 +1300

> them are misbehaving is getting what he deserves.  Period.

Or to say it another way: don't do that. Read http://tools.ietf.org/html/rfc7421
which tells you in painful detail why you shouldn't do that.

If you must blacklist, blacklist a /64. As others have said, that is roughly
the same as blacklisting the IPv4 address of a NAT, or blacklisting an
IPv4 subnet. In any case, with IPv6, you must expect the attacker to be
changing their interface identifier all the time.

   Brian

---

From: "Metzler, Dan J" <[email-masked]>
Date: Sat, 24 Oct 2015 02:09:02 +0000

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Nikos
> Mavrogiannopoulos
> Sent: Friday, October 23, 2015 10:27 AM
> To: Metzler, Dan J <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [v6ops] preventing denial of service in IPv6
> 
> >> So one would expect software to blacklist whole ranges of networks,
> >> e.g., a /64 or /48 once few IPs violate some of its "detection
> >> properties".
> > [DJM] I would think one would expect software to block a single IP address
> for IPv6 in the same scenarios where that would happen in IPv4.
> > Granted IPv6 makes it a bit easier to repeatedly change addresses, purely
> from an availability standpoint, in the same way that it makes it a bit harder
> to scan addresses.
> Then a single user can exhaust a server's resources by simply attacking the
> server with all his available addresses.
[DJM] That's true on IPv4 as well as it is on IPv6, and no more so on IPv6.  So, to the extent that a single user can DOS attack a server over whatever bandwidth he has through the ISP...
However the number of potential addresses available has nothing to do with the capacity to DOS attack a server.
That depends more on CPU, the number of network interfaces on the attacking system.

The main point is that 2^64 addresses does not equate more attacking systems.
One could argue that it makes it easier to hide, but in most cases, I would think that'd be fairly weak argument.
They are all still coming from the same /64, and still have the same signature.

> 
> >>Given recommendations like RFC6164 which  recommend /127 for PtP links
> >>(which can be a user VPN link), any heuristic  that will ban whole
> >>networks looks more like a vessel to perform another  denial of
> >>service (e.g., denying some user access to a server), rather than a
> > A better approach would be to intelligently and dynamically block offending
> individual addresses, or sets of addresses, based off of more information
> than a simple assumption that if there is one offender on a subnet, then they
> all must be offenders.
> > Of course one might want to block a whole subnet once some sort of
> critical threshold was reached of a certain number of offending IPs on that
> subnet.
> >
> >> This is further reinforced by the fact that smaller than /64 networks
> >> address proliferation?
> > DOS is largely a game of resources; attempting to allocate a large enough
> pool of resources, that participate in a DOS attack, so as to exceed the
> capacity of the finite resources dedicated to handling a load.  The fact that
> the resources instigating the attack has a larger pool of addresses, to use,
> doesn't change the amount of resources participating in the attack, or the
> number of addresses in use at a given point in time.
> > Also, the likelihood that a DOS attack would be  sourced entirely from
> > a single subnet seems more and more of an edge case as time goes on.
> > (If it were only that easy.)
> 
> IPv6 makes that easy. In IPv4 DOS attacks don't come from a single subnet
> because it is expensive to obtain control of a big subnet. In

[DJM] I don't think I agree with this premise.  IPv4 DOS attacks, in my opinion, typically don't come from a single subnet because it isn't helpful to the attack.  The more distributed, and spread out across different subnets, the better.

If you have a single subnet full of 250 computers to be used in an attack...
1) They are all coming from the same subnet, and that's fairly trivial to block.  (Even easier to detect if one can assume that everyone uses /64s, which likely people will do anyway, regardless of how small you try to limit address space in actuality.)
2) 250 computers on the same subnet are really the same 250 hosts whether they use IPv4 or IPv6.  A greater pool of addresses does not increase the number of interfaces on the network, or the number of compute resources involved in the attack. 
3) Bad guys have nothing to gain by attempting to have all of their attackers on a single subnet.  It limits their bandwidth relative to a distributed attack.

> 
> >> If not, are there any conventions for IPv6 address assignment to
> >> end-users?
[DJM]  
DHCPv6 Stateless - same as SLAAC.
DHCPv6 Stateful - I think the "convention" is still /64 for end user nets because, well... it is IPv6, but you could theoretically make it smaller (prefix larger), if that's what you're after, and you're willing to deal with any issues that might arise.  (One of them being devices that don't support DHCPv6 and only support SLAAC.)

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sun, 25 Oct 2015 09:20:59 +0000

> On Oct 23, 2015, at 8:39 AM, Erik Nygren <[email-masked]> wrote:
> 
> My colleagues David Plonka and Arthur Berger are presenting this paper at IMC next week

Dave offered to re-present in v6ops at IETF-94, and I took him up on it. It seems timely.

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Tue, 27 Oct 2015 11:35:59 +0000

Hi Nikos,

Please see my reply in-line below.

> Sent: Friday, October 23, 2015 11:08 PM
> To: Philip Homburg
> Cc: [email-masked]

> My point is exactly this disproportion. In this suggestion you add a heuristic of
> 256 misbehaving addresses to block 2^64 addresses in total (for a /64), and
> 256*256=2^16 mibehaving addresses to block 2^80 addresses. This will affect
> someone who has divided a /64 into 2^32
> /96 subnets and shared it to different users, he will have his subnet completely
> blocked even if only 256 out of 2^32 is misbehaving. We may adjust these
> numbers as we like, but the disproportion will remain if we want to keep
> reasonable memory consumption for the server.

[Will] Just to chime in here to say that, IMHO, for SLAAC the network can typically be assumed to be a /64. And you might make a similar assumption for DHCPv6.

Regards,
Will (Shucheng LIU)