On Fri, 6 May 2016, Benjamin Cronce wrote: > The good ones do. You need to reassemble the packets if you want to enforce > proper stateful TCP. I wonder how those new network stacks that use MSS to > send packets directly to a specific core will handle fragments, since they > need all packets for a flow to get assigned to the same core, which means > L3/L4 must hash to the same value, and no L4 for later fragments. Unless > all fragmented packets get handled on a specific core, like ICMP. I remember a big fuss 10 or so years ago with a bunch of firewall vulnerabilities where people could get creative with fragments and bypass the firewall rules. > On Fri, May 6, 2016 at 1:50 PM, David Lang wrote: > >> On Fri, 6 May 2016, Stephen Hemminger wrote: >> >> On Fri, 6 May 2016 02:00:02 -0700 (PDT) >>> David Lang wrote: >>> >>> On Fri, 6 May 2016, moeller0 wrote: >>>> >>>> Hi Jonathan, >>>>> >>>>> On May 6, 2016, at 06:44 , Jonathan Morton >>>>>> wrote: >>>>>> >>>>>> >>>>>> On 6 May, 2016, at 07:35, Dave Taht wrote: >>>>>>> >>>>>>> this would be a pretty nifty feature for cake to have in this hostile >>>>>>> universe. >>>>>>> >>>>>> >>>>>> Yes, but difficult to implement since the trailing fragments lose the >>>>>> proto/port information, and thus get sorted into a different queue than the >>>>>> leading fragment. We would essentially need to implement the same tracking >>>>>> mechanisms as for actual reassembly. >>>>>> >>>>> >>>>> But the receiver needs to be able to re-segment the fragments >>>>> so all required information needs to be there; what about looking at src >>>>> and dst address and the MF flag in the header as well as the fragment >>>>> offset and scrape proto/port from the leading fragment and “virtually” >>>>> apply it to all following fragments, that way cake will do the right thing. >>>>> All of this might be too costly in implementation and computation to be >>>>> feasible… >>>>> >>>> >>>> wait a minute here. If the fragments are going to go over the network as >>>> separate packets, each fragment must include source/dest ip and >>>> source/dest >>>> port, otherwise the recipient isn't going to be able to figure out what >>>> to do >>>> with it. >>>> >>>> David Lang >>>> >>> >>> Fragments are reassembled by IP id, not src/dest port. >>> Only the first fragment has the L4 header with src/dest port, >>> all the rest are just data. >>> >>> That is why most firewalls reassemble all packets (and then refragment as >>> needed) >>> to allow matching on port values. >>> >> >> actually, many firewalls do not reassemble packets, they pass packets >> through without reassembly. >> >> what IP id are you referring to? I don't remember any such field in the >> packet header. >> >> David Lang >> >> >> For several cases where flow information is necessary most code does: >>> flowid = is_fragementd(ip) ? ip->id : hash(ip + tcp) >>> >>> >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake >> >> >