From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (lang.hm [66.167.227.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 62A033B25E for ; Fri, 6 May 2016 22:09:23 -0400 (EDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id u4729JO8018238; Fri, 6 May 2016 19:09:19 -0700 Date: Fri, 6 May 2016 19:09:19 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Benjamin Cronce cc: Stephen Hemminger , cake@lists.bufferbloat.net In-Reply-To: Message-ID: References: <1462201620.5535.250.camel@edumazet-glaptop3.roam.corp.google.com> <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <2D83E4F6-03DD-4421-AAE0-DD3C6A8AFCE0@gmail.com> <1577AB06-3C14-43D1-92AD-E37CEDCB8E11@gmail.com> <8F329CCB-038C-4EF4-A01D-DB8C093AE6B2@gmx.de> <20160506083114.0730d9f1@xeon-e3> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-1779322456-1462586959=:1540" Subject: Re: [Cake] Fwd: [Codel] fq_codel_drop vs a udp flood X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2016 02:09:23 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --680960-1779322456-1462586959=:1540 Content-Type: TEXT/PLAIN; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT 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 >> >> > --680960-1779322456-1462586959=:1540--