Subject: Destination options and denial of service attack

From: Tom Herbert <[email-masked]>
Date: Tue, 25 Apr 2017 19:56:20 -0700

The topic of limits of unbounded lists of TLVs that can be ignored
came up on tsvwg. By my estimate, it is possible the create an
Ethernet MTU size packet that holds 1282 TLVs in destination options
(a combination of PAD1s and two bytes option with a type value that is
known to be undefined) or at least 724 two byte options that would be
ignored. Processing such packets on a host would be quite expensive
and could likely be used as a DOS attack. HBH options have similar
characteristics , but there are known workarounds such as devices
ignoring them completely per the new allowance. Also, it's pretty well
known that a router can throw packets with EH into a slow path that
provides a from of rate limiting (albeit possibly at the possible
expense of hampering legitimate use cases of EH)-- there's no obvious
equivalent mechanism for a host. I am specifically concerned with
destination options and processing them on hosts. The Linux stack for
instance currently has no limits on destination options and will
process all that are in a packet AFAICT.

My question is what mitigations do we have to handle a DOS attack like
this that would be in compliance with the spec? AFAICT from reading
2640bis a host must process all extension headers and must process all
destination options in a packet. There is no limit to number of
options or space used other than they need to fit into an MTU IIRC.
Appendix A of 2460bis mentions "It may be assumed that, when either of
the option-bearing headers are present, they carry a very small number
of options, usually only one.", but that does not establish an
enforceable limit.

Thanks,
Tom

---

From: Peter Hessler <[email-masked]>
Date: Wed, 26 Apr 2017 10:52:58 +0200

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.

There are many firewalls deployed in the wild that by default drop all
IPv6 packets with extension headers.

That avoids the DoS condition.

-- 
Did you know ...

That no-one ever reads these things?

---

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Apr 2017 15:22:20 +0100

> of options, usually only one.", but that does not establish an

That's part of what I mentioned regarding providing pointers regarding
the security implications of IPv6 EHs.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 26 Apr 2017 19:08:08 -0400

Hi Tom,

> process all that are in a packet AFAICT.

Yes. I agree with you that this is an issue (at least implementation
wise). I encountered this the first time I dealt with a NPU based fast
path implementation of IPv6 in 2003. I wrote it up in

https://tools.ietf.org/html/draft-krishnan-ipv6-hopbyhop-00 (circa 2004)

but it did not go anywhere. Basically, the WG did not feel it was
something worth working on.

> of options, usually only one.", but that does not establish an

There are a lot of possibilities to fix these and as someone said
downthread, it is a fine balance between the desire for extensibility
and one to prevent attacks.

Cheers
Suresh