• Tom Herbert's avatar
    ipv6: Implement limits on Hop-by-Hop and Destination options · 47d3d7ac
    Tom Herbert authored
    RFC 8200 (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.
    
      25.38%  [kernel]                    [k] __fib6_clean_all
      21.63%  [kernel]                    [k] ip6_parse_tlv
       4.21%  [kernel]                    [k] __local_bh_enable_ip
       2.18%  [kernel]                    [k] ip6_pol_route.isra.39
       1.98%  [kernel]                    [k] fib6_walk_continue
       1.88%  [kernel]                    [k] _raw_write_lock_bh
       1.65%  [kernel]                    [k] dst_release
    
    This patch adds configurable limits to Destination and Hop-by-Hop
    options. There are three limits that may be set:
      - Limit the number of options in a Hop-by-Hop or Destination options
        extension header.
      - Limit the byte length of a Hop-by-Hop or Destination options
        extension header.
      - Disallow unrecognized options in a Hop-by-Hop or Destination
        options extension header.
    
    The limits are set in corresponding sysctls:
    
      ipv6.sysctl.max_dst_opts_cnt
      ipv6.sysctl.max_hbh_opts_cnt
      ipv6.sysctl.max_dst_opts_len
      ipv6.sysctl.max_hbh_opts_len
    
    If a max_*_opts_cnt is less than zero then unknown TLVs are disallowed.
    The number of known TLVs that are allowed is the absolute value of
    this number.
    
    If a limit is exceeded when processing an extension header the packet is
    dropped.
    
    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).
    
    These limits have being proposed in draft-ietf-6man-rfc6434-bis.
    
    Tested (by Martin Lau)
    
    I tested out 1 thread (i.e. one raw_udp process).
    
    I changed the net.ipv6.max_dst_(opts|hbh)_number between 8 to 2048.
    With sysctls setting to 2048, the softirq% is packed to 100%.
    With 8, the softirq% is almost unnoticable from mpstat.
    
    v2;
      - Code and documention cleanup.
      - Change references of RFC2460 to be RFC8200.
      - Add reference to RFC6434-bis where the limits will be in standard.
    Signed-off-by: default avatarTom Herbert <tom@quantonium.net>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    47d3d7ac
af_inet6.c 25.8 KB