From: Tom Herbert <t...@herbertland.com> Date: Wed, 10 May 2017 14:33:19 -0700
> RFC 2460 (IPv6) defines hop by hop options and destination options > extension headers. Both of these carry a list of TLVs which is > only limited by the maximum length of the extension header (2048 > bytes). By the spec a host must process all the TLVs in these > options, however these could be used as a fairly obvious > denial of service attack. I think this could in fact be > a significant DOS vector on the Internet, one mitigating > factor might be that many FWs drop all packets with EH (and > obviously this is only IPv6) so an Internet wide attack might not > be so effective (yet!). > > By my calculation, the worse case packet with TLVs in a standard > 1500 byte MTU packet that would be processed by the stack contains > 1282 invidual TLVs (including pad TLVS) or 724 two byte TLVs. I > wrote a quick test program that floods a whole bunch of these > packets to a host and sure enough there is substantial time spent > in ip6_parse_tlv. These packets contain nothing but unknown TLVS > (that are ignored), TLV padding, and bogus UDP header with zero > payload length. ... > Default values are set to 8 for options counts, and set to INT_MAX > for maximum length. Note the choice to limit options to 8 is an > arbitrary guess (roughly based on the fact that the stack supports > three HBH options and just one destination option). So the maximum number of TLVs we could process is some function of the option count limit, and the number of padding TLVs that can be stuffed alongside of those 8 non-padding options?
