Subject: Re: Destination options and denial of service attack

From: "C. M. Heard" <[email-masked]>
Date: Wed, 26 Apr 2017 07:51:29 -0700

On Wed, 26 Apr 2017 10:52:58 +0200 Peter Hessler wrote:
> On 2017 Apr 25 (Tue) at 19:56:20 -0700 (-0700), Tom Herbert wrote:
> :AFAICT from reading
> :2640bis a host must process all extension headers and must process all
> :destination options in a packet.

A host must also process all hop-by-hop options as well, as is made
clear by the new proposed extension header text for 2460bis:

https://www.ietf.org/mail-archive/web/ipv6/current/msg27144.html

> There are many firewalls deployed in the wild that by default drop all
> IPv6 packets with extension headers.
>
> That avoids the DoS condition.

That is not a terribly satisfactory answer. RFC 7045 was published by
this WG precisely to discourage such behavior. Per Section 2.1 of that
RFC, the filtering behavior MUST be configurable, and the default SHOULD
be to accept all standard extension headers, including the Hop-by-Hop
Options header and the Destination Options header.

Mike Heard

---

From: Tom Herbert <[email-masked]>
Date: Wed, 26 Apr 2017 09:30:26 -0700

> Options header and the Destination Options header.
RFC 7045 refers only to behavior of intermediate nodes processing
extension headers not end hosts. There is no requirement that hosts
live behind a firewall, so even if firewalls do drop packets with EH
that doesn't solve the host-side problem. It may be true that firewall
blocking EH may be enough (so far) to make a wide scale DOS attack
ineffective.

Dropping all packets with EH at the host (or intermediate node for
that matter) is not the right solution. We need a way to differentiate
a legitimate use of options from one that is likely illegitimate-- a
packet with 1282 TLVs is clearly an illegitimate use case! This seems
to imply that we need to place some limits on the options, for
instance how many destination options a host is willing to process.
Unfortunately, I don't see any way to do this without violating the
spec.

Tom

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

---

From: Bob Hinden <[email-masked]>
Date: Wed, 26 Apr 2017 09:57:07 -0700

Tom,

> On Apr 26, 2017, at 9:30 AM, Tom Herbert <[email-masked]> wrote:
> 

Most DDOS attacks I am aware of all send legitimate traffic.  They attempt to overwhelm the target.

So while I agree that at some level protecting against these kinds of attacks are technical violations of some specifications, for example IPv6, TCP, DNS, TLS, etc., in practice they aren’t.  A single packet doesn’t make for an attack, it many packets from many sources.  Protecting against DDOS attacks requires looking at the overall attack patter.

Further, at least any DDOS attacks using 1282 TLVs is pretty easy to detect and block since it’s such an outlier, as compared to simple attacks that use very generic packets that can’t be differentiated from non-attack traffic.

Bob

---

From: Tom Herbert <[email-masked]>
Date: Wed, 26 Apr 2017 11:21:48 -0700

> So while I agree that at some level protecting against these kinds of attacks are technical violations of some specifications, for example IPv6, TCP, DNS, TLS, etc., in practice they aren’t.  A sin…
Right, but IPv6 is stateless so that analyzing an attack may require
new state and resource monitoring that may be prohibitive to implement
on low end devices (IoT devices for instance). I think the simplest
approach is to create an OS configurable limit for number of non-pad
TLVs with a reasonable default, maybe something like five or ten of
them. This is at least better then unilaterally blocking all packets
with extension headers.

Tom

---

From: Bob Hinden <[email-masked]>
Date: Wed, 26 Apr 2017 11:31:04 -0700

Tom,

> On Apr 26, 2017, at 11:21 AM, Tom Herbert <[email-masked]> wrote:
> 
>> 
>> 

Something to consider for the node requirement update.  Picking some default values will be a challenging.

I also think that for IoT devices, there are so many potential DDOS attack vectors (and most much worse than this one), there there is little an individual device can do.  Maybe better to limit who can talk to them instead of trying to protect against stuff like this.

Bob

p.s. IoT devices seem to be used more for the source of DDOS attacks these days :-)

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Apr 2017 08:58:03 +1200

On 27/04/2017 06:21, Tom Herbert wrote:
...
> them. This is at least better then unilaterally blocking all packets

Even ignoring a few hundred pads could be an issue, surely?

It might be simpler to set a configurable limit on the acceptable Hdr_Ext_Len
for any Options header.

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Apr 2017 07:06:04 +1000

In message <[email-masked]>, Bob Hinden writes:
> I also think that for IoT devices, there are so many potential DDOS
> attack vectors (and most much worse than this one), there there is little
> an individual device can do.  Maybe better to limit who can talk to them
> instead of trying to protect against stuff like this.
>
> Bob
>

And what is the real different between processing a series of IPv6
options and a 1500 byte DNS packet which is essentially a series
of TLV fields?  None.

It also in the worst case devolves to the equivalent of a byte by
byte copy of the packet which while not great is also not the end
of the world.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Tom Herbert <[email-masked]>
Date: Wed, 26 Apr 2017 14:59:36 -0700

> Even ignoring a few hundred pads could be an issue, surely?
There's a nice trick in Linux, I don't know if it's standard, that at
most seven consecutive pad bytes are allowed.

> It might be simpler to set a configurable limit on the acceptable Hdr_Ext_Len
That might be useful also. Even a single 1200 byte destination option
can cause problems with current implementations (pulling up checksum
in checksum complete for instance).

Another thing I'll probably add is configuration to drop any packets
with unknown options. In a closed system, like a datacenter, things
are typically controlled so there shouldn't be "ignored" data in the
network. I wouldn't set this as a default.

Tom

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Apr 2017 08:26:08 +1000

> most seven consecutive pad bytes are allowed.

Which assumes the only use of pad is to force alignment.

> network. I wouldn't set this as a default.

Even data centers upgrade equipement incrementally, have equipement
from different vendors with different capabilities, etc.  Setting
such a option is like laying landmines, they explode on you later.

Mark

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 26 Apr 2017 15:57:05 -0700

> network. I wouldn't set this as a default.

Thank you for not making this behaviour the default. I presume that
the default will be to look at the top two bits, per the standard.

//cmh

---

From: [email-masked]
Date: Thu, 27 Apr 2017 08:07:32 +0200 (CEST)

> options and a 1500 byte DNS packet which is essentially a series

One significant difference is that the IPv6 options would normally
be processed entirely by the operating system TCP/IP stack, while a
1500 byte DNS packet would be processed by an application running in
user space. The former means a greater potential for DoS of the whole
operating system.

Steinar Haug, AS2116