On Fri, May 12, 2017 at 8:38 AM, David Miller <da...@davemloft.net> wrote: > 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?
Yes, if you count the one byte pad TLVs then maximum TLVs processed (# times through the loop) with the default of 8 is 8 + 9*7= 71. The padding TLVs are less expensive to process at least. Function is: N(max_non_pad) = (max_non_pad + 1) * 7 + max_non_pad
