[Cake] Fwd: [Codel] fq_codel_drop vs a udp flood

[David Lang]

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 <david at lang.hm> wrote:
>
>> On Fri, 6 May 2016, Stephen Hemminger wrote:
>>
>> On Fri, 6 May 2016 02:00:02 -0700 (PDT)
>>> David Lang <david at lang.hm> wrote:
>>>
>>> On Fri, 6 May 2016, moeller0 wrote:
>>>>
>>>> Hi Jonathan,
>>>>>
>>>>> On May 6, 2016, at 06:44 , Jonathan Morton <chromatix99 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On 6 May, 2016, at 07:35, Dave Taht <dave.taht at gmail.com> 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 at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>>
>>
>