On Fri, Jan 11, 2019 at 6:54 AM Timothy Winters <twint...@iol.unh.edu> wrote: > > Hi Michal and Eric, > > Thanks for the clarification. I'm thinking about creating a draft to say no > fragments less then 640 unless it's the last fragment. Does that work for > your code going forward?
I will prepare a patchset to convert IPv6 defrag queue to rbtree+list, similarly to how IPv4 defrag queue currently works. Just in case it is decided to go this route. I don't think having an arbitrary/non-standard size cap (640) is a good approach. Thanks, Peter > > ~Tim > > On Fri, Jan 11, 2019 at 9:21 AM Michal Kubecek <mkube...@suse.cz> wrote: >> >> On Friday, 11 January 2019 14:26 Timothy Winters wrote: >> > Hi Eric, >> > >> > So I understand correctly the attack that you are trying to prevent is >> > many small fragments from different IPs? >> > >> > The 6MAN working group has had some discussion about this topic, if >> > you want read some IPv6 networking prospectives. >> > >> > https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=zsYUwQTt0mA >> > dXdk9MN4dP-uiiag >> >> I haven't read all mails in that discussion but most seem to be missing >> the point. The problem is not memory consumption, we have a (runtime >> configurable) limit for that. The problem is that by sending many small >> (8 bytes) fragments of a large (up to 64 KB) packet but never finishing >> it, an attacker can force receiving host into using quite a lot of CPU >> time just by looking up the fragment queue of the partially reassembled >> packet. >> >> Currently, IPv6 reassembly uses a simple linear list which is fine with >> 1280 byte long fragments (up to ~50 of them) but not with 8 byte long >> ones (there could be as many as ~8000). The IPv4 reassembly code (where >> we cannot assume minimal size of non-last fragment) switched to rbtree >> (with logarithmic lookup time) exactly for this reason. >> >> > What about lowering the value of accepted fragments? to something >> > like 1280/2? >> >> That would be probably sufficient to mitigate the DoS attacks. >> >> Michal Kubecek >> >>
