Re: Non-Last Small IPv6 Fragments
Tom Herbert <tom@herbertland.com> Sat, 12 January 2019 17:08 UTC
Return-Path: <tom@herbertland.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094AC126F72 for <ipv6@ietfa.amsl.com>; Sat, 12 Jan 2019 09:08:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.041
X-Spam-Level:
X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ww-Afdz1d8j for <ipv6@ietfa.amsl.com>; Sat, 12 Jan 2019 09:08:14 -0800 (PST)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E992124BAA for <ipv6@ietf.org>; Sat, 12 Jan 2019 09:08:14 -0800 (PST)
Received: by mail-qk1-x735.google.com with SMTP id q1so8318036qkf.13 for <ipv6@ietf.org>; Sat, 12 Jan 2019 09:08:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=650DZ5nk5y7hDCVjAvmTHWJqrgA4k73O0gC5XpeY/pA=; b=C7ep3aflrA2eaO077ud1B87HRhdz4hRahMU0K13p+3k9VNRE+OPQSGYlaPcIdbUL40 6+gXMPQgDRLk43jJFEwwY/6zc/7AwpENUF5JWVJ0zbWaZdxVTR2h1r+E9Y9kU4zV69zt WFo+wzS+KiNijR4gZX8MqZn2kx0JlioY94uzkt7dspsXuumdiUchEyf48ha4e2r1FURt oCLUGWuiFfHl9arRp0rbWKKzNcFRu2zmqJ9hJa+5Ap6SAH7to/pjebpEUxxH2elX8myu sHMZYgmlA/d7hRX1ME553Z5JBbl3edLbZCtGIIKilYCSmqPI5YTRNrjifZENsDfaeWik rBgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=650DZ5nk5y7hDCVjAvmTHWJqrgA4k73O0gC5XpeY/pA=; b=dUVsfFr7PvxV+FFUU9EDuDjga6byIZbq3d+W/Jq4CO2SSeZI9eX0HcPCmPW7TNJx6c n8DMH3rC2iwswe4xr05RSwMJEDrsgmzXC31QjQ/WmlCTVwgsVRmEGJbRLxkz2oINiIGv KhaRhsrudzKqQ7eVnV8q/xuJYRNDyphxrFQhsP+a/tX2+0Asl4GL3TKc1eufWWSa1B+R 6h/chtdVqXE1u3mrbcgImVCcY85m/wCCAnImgRhv8VzHK2MM3Skb6FwRYR7DxJza4LJn mxjf7CgSVqqbFCBMj1FQZL11AQ6/rE/L6+dWhZsc6MWMHlkbdy+sEY9Ixa7UiwKV5+Qs Q3Lw==
X-Gm-Message-State: AJcUukfXl/VtDXrD/wDeiDky7PplLcMp4Ski/nO2OBd8qNj6dz45wyxR /ZH8rOzlbCR4EWGBIN6nRJsa07IntWyS0mthZpIYzQ==
X-Google-Smtp-Source: ALg8bN4VAU+jbfx3ZKMgNzhu1wtbHJTU6sUAL25F+A41Bwwp0efo0EXamDUtHUz9ZPaoOxeguzat78cGaddg8ZnfuzI=
X-Received: by 2002:a37:7885:: with SMTP id t127mr17471221qkc.323.1547312892833; Sat, 12 Jan 2019 09:08:12 -0800 (PST)
MIME-Version: 1.0
References: <CAOSSMjV0Vazum5OKztWhAhJrjLjXc5w5YGxdzHgbzi7YVSk7rg@mail.gmail.com> <BYAPR05MB4245B9305E6EC57EDD45509FAE840@BYAPR05MB4245.namprd05.prod.outlook.com> <7453645f-ff91-e866-b087-e7d4f1450ab6@gmail.com> <0e792b48-4360-6977-9ae8-9cdfdc78c7b8@gmail.com> <16A642DC-D3A4-452C-B7D1-20CA0EEEDDA2@lists.zabbadoz.net> <CAOSSMjWS9po2XuBHJ5hbN9hfNDKZ1diecH08Kt697-15jRtAvg@mail.gmail.com> <0e0c3141-889e-ff60-2787-2889b3a9af6b@si6networks.com> <748DA428-5AB2-4487-A4FB-F2DABF5BF8BE@thehobsons.co.uk> <8b43af81-1c49-5cea-6472-97703674e661@si6networks.com> <CAN-Dau1HwG5RndacpSA+si+zKuTdpSvA=QA1A11A==rMNe=4+w@mail.gmail.com> <CALx6S35KNhV2gFp9OdU+M1zy5WUuEAEvXkDXNDWWxi7uQ4e_cw@mail.gmail.com> <CAN-Dau0rTdiiF2SjByxcMG6nhPCEjUH2pYBCOeK_FSGJ_ucDQw@mail.gmail.com> <CALx6S34AyV9OpvnjQhQc56n5vfeVgU5Zd3kheP0g+XvsMbBV9g@mail.gmail.com> <1b2e318e-1a9f-bb5d-75a5-04444c42ef20@si6networks.com> <CALx6S37TJr++fC=pVoeS=mrO1fHc4gL_Wtu-XkVTswzs2XxXCA@mail.gmail.com> <9352bb4d-f4d9-ebc6-34f9-dcb2f3ec24f1@si6networks.com>
In-Reply-To: <9352bb4d-f4d9-ebc6-34f9-dcb2f3ec24f1@si6networks.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sat, 12 Jan 2019 09:08:00 -0800
Message-ID: <CALx6S35Tz85tQu67Rp0EHLrZLh7OYZ1V3mDOjKVC6iuCeUAjxA@mail.gmail.com>
Subject: Re: Non-Last Small IPv6 Fragments
To: Fernando Gont <fgont@si6networks.com>
Cc: David Farmer <farmer@umn.edu>, IPv6 List <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/uCTclQaqcrZmMOtyOUiYBsiPQAs>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Jan 2019 17:08:17 -0000
On Fri, Jan 11, 2019 at 8:49 PM Fernando Gont <fgont@si6networks.com> wrote: > > On 12/1/19 00:47, Tom Herbert wrote: > > On Fri, Jan 11, 2019 at 7:32 PM Fernando Gont <fgont@si6networks.com> wrote: > >> > >> On 11/1/19 19:47, Tom Herbert wrote: > >>> On Fri, Jan 11, 2019 at 2:33 PM David Farmer <farmer@umn.edu> wrote: > >>>> > >>>> > >>>> On Fri, Jan 11, 2019 at 3:27 PM Tom Herbert <tom@herbertland.com> wrote: > >>>>> > >>>>> On Fri, Jan 11, 2019 at 1:13 PM David Farmer <farmer@umn.edu> wrote: > >>>>>> > >>>>>> On Fri, Jan 11, 2019 at 1:58 PM Fernando Gont <fgont@si6networks.com> wrote: > >>>>>>> > >>>>>>> On 11/1/19 15:38, Simon Hobson wrote: > >>>>>>>> Fernando Gont <fgont@si6networks.com> wrote: > >>>>>>>> > >> [....] > >>>>>> > >>>>>> I just had a thought for the guidance; > >>>>>> > >>>>>> 1. System-wide limit the number of fragments based on the overall system resources available. > >>>>>> 2. As you near said limit, maybe 75% of the limit, drop outright, or at a high probability, non-final fragments smaller than (1280/2) 640 bytes. > >>>>>> > >>>>>> The reasonable fragmentation algorithms I can think of do not generate non-final fragments that are less than 640 bytes. Nevertheless, such fragments SHOULD NOT be dropped except for when the system is under stress. > >>>>>> > >>>>>> What do others think? > >>>>> > >>>>> I don't see any practical purpose of sending tiny fragments with eight > >>>>> byte payloads in non-first fragments, these can only happens under DOS > >>>>> attack or synthetic testing. So I do believe it's prudent to have some > >>>>> guidance on setting limits for minimal sizes of non-first fragments. > >>>>> The limit should probably be configurable with some recommended > >>>>> default value. I believe the 1280 limit in Linux is too high, but > >>>>> there are some compelling arguments for 640. > >>>> > >>>> > >>>> Why non-first fragments? Did you mean non-final? Maybe both first and last should be exempted? > >>>> > >>> Yes. > >> > >> So why should I, as an attacker, send you first fragments, then? If for > >> some reason I just want to send you, I'd send fragments such that > >> Offset!=0 and M=0, with small size, WHat have you gained with the check > >> you propose? > > > > That sort of attack would exhaust the limit on how many packets are > > allowed to be in reassembly at which point such packets would start to > > be dropped. It's also easy enough to prioritize packets for reassmbly > > for which the first fragment has already been received when > > considering eviction from the reassembly queue. > > I agree with the above (please see the ref I posted to RFC6274, which > basically argues about this). HOowever, it is still not clear to me > what's the problem you are addressing by enforcing a minimum fragment > size. If you allow MIN_MTU/2, then you require first frags to be 640 > bytes.. and teh attacker is required to send 640 as opposed to 60 bytes > or so. Doesn't seem to be much of a difference to me. > And as noted by Bob, I still don't see what's the big deal with the > small fragments. > Hi Fernando, Consider that the smallest packet containing an IPv6 fragment is: IP hdr. 40 Fragment header: 8 Fragment data: 8 Sums to 56 bytes. Maximum reassemble packet size is 65,535, so a single packet could be composed of 8,186 such fragments. A stream of these packet creates high load on both CPU and memory. Fundamentally, I see no other purpose for sending a stream of fragments like this other than DOS attack. I don't think it's at all unreasonable for a host to outright reject these packets. But as you point out, this isn't on the only way to attack fragmentation, and it's easy to contrive other attacks. Consider, a fragment like this: IP hdr:40 Dst: opt: 2 722 Destination options of two byte length, where each option type is 00 in high order bits Fragment header: 8 Fragment data: 8 Sums to 1500, ie. typical MTU. So this fragment will pass the minimum 1280 check but still carries the minimum fragment data so it can attack memory used in reassembly. Processing long lists of options is also a good attack on CPU. This attack could be mitigated by applying limits on headers like in draft-int-area-header-limits. The default limit number of bytes in network headers in that draft is 256 bytes, so the minimum size of fragment data that could be accepted under that limit is 384 bytes (much better then 8 bytes). In any case, this discussion underscores a big challenge we have with have with IPv6. There are several very powerful mechanisms in the specifications that were defined without any limits. To get to practical and deployable implementations we need to set some limits. IMO the best way do that is to publically define the limits needed, make them configurable, and suggest default values. I believe this is a *FAR* better approach than implementions providing their own ad hoc solutions (such as those that just drop all fragments or packets with extension headers). Tom > There are some DoS attacks where you send a last frag and possibly a > first frag, and the implementation allocates a buffer that would fit the > rest of the missing fragments -- obviously exacerbating the problem a > bit. BUt still i this cases, the size of the first frag is not a big deal. > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > >
- Non-Last Small IPv6 Fragments Timothy Winters
- Re: Non-Last Small IPv6 Fragments Bob Hinden
- Re: Non-Last Small IPv6 Fragments 神明達哉
- Re: Non-Last Small IPv6 Fragments Tom Herbert
- RE: Non-Last Small IPv6 Fragments Ron Bonica
- Re: Non-Last Small IPv6 Fragments Erik Kline
- RE: Non-Last Small IPv6 Fragments Ron Bonica
- Re: Non-Last Small IPv6 Fragments Brian E Carpenter
- RE: Non-Last Small IPv6 Fragments Ron Bonica
- Re: Non-Last Small IPv6 Fragments Tom Herbert
- Re: Non-Last Small IPv6 Fragments Mark Andrews
- Re: Non-Last Small IPv6 Fragments Simon Hobson
- Re: Non-Last Small IPv6 Fragments Erik Kline
- Re: Non-Last Small IPv6 Fragments David Farmer
- Re: Non-Last Small IPv6 Fragments Mark Andrews
- Re: Non-Last Small IPv6 Fragments Tom Herbert
- Re: Non-Last Small IPv6 Fragments Erik Kline
- Re: Non-Last Small IPv6 Fragments Carsten Bormann
- Re: Non-Last Small IPv6 Fragments 神明達哉
- Re: Non-Last Small IPv6 Fragments Brian E Carpenter
- Re: Non-Last Small IPv6 Fragments Brian E Carpenter
- Re: Non-Last Small IPv6 Fragments Fernando Gont
- Re: Non-Last Small IPv6 Fragments Fernando Gont
- Re: Non-Last Small IPv6 Fragments Fernando Gont
- Re: Non-Last Small IPv6 Fragments Mikael Abrahamsson
- Re: Non-Last Small IPv6 Fragments Mark Andrews
- Re: Non-Last Small IPv6 Fragments Bjoern A. Zeeb
- Re: Non-Last Small IPv6 Fragments Bjoern A. Zeeb
- Re: Non-Last Small IPv6 Fragments Timothy Winters
- Re: Non-Last Small IPv6 Fragments Fernando Gont
- Re: Non-Last Small IPv6 Fragments Fernando Gont
- Re: Non-Last Small IPv6 Fragments Ole Troan
- Re: Non-Last Small IPv6 Fragments Timothy Winters
- Re: Non-Last Small IPv6 Fragments Tom Herbert
- Re: Non-Last Small IPv6 Fragments Simon Hobson
- Re: Non-Last Small IPv6 Fragments Fernando Gont
- Re: Non-Last Small IPv6 Fragments Fernando Gont
- Re: Non-Last Small IPv6 Fragments David Farmer
- Re: Non-Last Small IPv6 Fragments Tom Herbert
- RE: Non-Last Small IPv6 Fragments Ron Bonica
- Re: Non-Last Small IPv6 Fragments David Farmer
- Re: Non-Last Small IPv6 Fragments Tom Herbert
- Re: Non-Last Small IPv6 Fragments Bob Hinden
- Re: Non-Last Small IPv6 Fragments David Farmer
- Re: Non-Last Small IPv6 Fragments Tom Herbert
- Re: Non-Last Small IPv6 Fragments Erik Kline
- Re: Non-Last Small IPv6 Fragments Fernando Gont
- Re: Non-Last Small IPv6 Fragments Fernando Gont
- Re: Non-Last Small IPv6 Fragments Tom Herbert
- Re: Non-Last Small IPv6 Fragments Fernando Gont
- Re: Non-Last Small IPv6 Fragments Christian Huitema
- Re: Non-Last Small IPv6 Fragments Ole Troan
- RE: Non-Last Small IPv6 Fragments Lubashev, Igor
- Re: Non-Last Small IPv6 Fragments Tom Herbert
- Re: Non-Last Small IPv6 Fragments Tom Herbert
- Re: Non-Last Small IPv6 Fragments Ole Troan
- Re: Non-Last Small IPv6 Fragments Tom Herbert
- Re: Non-Last Small IPv6 Fragments Ole Troan
- Re: Non-Last Small IPv6 Fragments Nick Hilliard
- Re: Non-Last Small IPv6 Fragments Bob Hinden
- Re: Non-Last Small IPv6 Fragments Brian E Carpenter
- Re: Non-Last Small IPv6 Fragments Tom Herbert
- Re: Non-Last Small IPv6 Fragments Ole Troan
- Re: Non-Last Small IPv6 Fragments Nick Hilliard
- Re: Non-Last Small IPv6 Fragments Ole Troan
- Re: Non-Last Small IPv6 Fragments Tom Herbert
- Re: Non-Last Small IPv6 Fragments Nick Hilliard
- Re: Non-Last Small IPv6 Fragments Tom Herbert
- Re: Non-Last Small IPv6 Fragments Brian E Carpenter
- RE: Non-Last Small IPv6 Fragments Manfredi (US), Albert E
- Re: Non-Last Small IPv6 Fragments Bjoern A. Zeeb
- Re: Non-Last Small IPv6 Fragments Fernando Gont
- Re: Non-Last Small IPv6 Fragments Fernando Gont
- Re: Non-Last Small IPv6 Fragments Fernando Gont
- Re: Non-Last Small IPv6 Fragments Brian E Carpenter
- Re: Non-Last Small IPv6 Fragments Erik Kline
- Re: Non-Last Small IPv6 Fragments Mark Smith
- Re: Non-Last Small IPv6 Fragments Fernando Gont
- Re: Non-Last Small IPv6 Fragments Tom Herbert
- Re: Non-Last Small IPv6 Fragments Simon Hobson
- Re: Non-Last Small IPv6 Fragments Nick Hilliard
- Re: Non-Last Small IPv6 Fragments Fernando Gont
- Re: Non-Last Small IPv6 Fragments Tom Herbert
- Re: Non-Last Small IPv6 Fragments Nick Hilliard
- Re: Non-Last Small IPv6 Fragments Bjoern A. Zeeb
- Re: Non-Last Small IPv6 Fragments Simon Hobson
- Re: Non-Last Small IPv6 Fragments Nick Hilliard
- Re: Non-Last Small IPv6 Fragments Tom Herbert
- Re: Non-Last Small IPv6 Fragments Tom Herbert
- Re: Non-Last Small IPv6 Fragments Brian E Carpenter
- Re: Non-Last Small IPv6 Fragments Mark Andrews
- Re: Non-Last Small IPv6 Fragments Erik Kline
- Re: Non-Last Small IPv6 Fragments Nick Hilliard
- Re: Non-Last Small IPv6 Fragments Ole Troan
- Re: Non-Last Small IPv6 Fragments Erik Kline
- Re: Non-Last Small IPv6 Fragments Fernando Gont
- Re: Non-Last Small IPv6 Fragments Tom Herbert
- End-to-end (was Re: Non-Last Small IPv6 Fragments) Christian Huitema
- Re: End-to-end (was Re: Non-Last Small IPv6 Fragm… Tom Herbert
- Re: End-to-end (was Re: Non-Last Small IPv6 Fragm… Nick Hilliard
- Re: Non-Last Small IPv6 Fragments Warren Kumari
- Re: Non-Last Small IPv6 Fragments Brian E Carpenter
- Re: Non-Last Small IPv6 Fragments Fernando Gont
- Re: Non-Last Small IPv6 Fragments Fernando Gont
- Re: End-to-end (was Re: Non-Last Small IPv6 Fragm… Fernando Gont
- Re: Non-Last Small IPv6 Fragments Mikael Abrahamsson
- Re: Non-Last Small IPv6 Fragments Tim Chown
- Re: Non-Last Small IPv6 Fragments Fernando Gont
- Re: Non-Last Small IPv6 Fragments Warren Kumari
- Re: End-to-end (was Re: Non-Last Small IPv6 Fragm… Tom Herbert
- Re: Non-Last Small IPv6 Fragments Ole Troan
- Re: End-to-end (was Re: Non-Last Small IPv6 Fragm… Fernando Gont
- Re: Non-Last Small IPv6 Fragments Fernando Gont
- Re: Non-Last Small IPv6 Fragments Fred Baker
- Re: Non-Last Small IPv6 Fragments Tim Chown
- Re: End-to-end (was Re: Non-Last Small IPv6 Fragm… Tom Herbert
- Re: End-to-end (was Re: Non-Last Small IPv6 Fragm… Brian E Carpenter
- Re: Non-Last Small IPv6 Fragments Brian E Carpenter
- Re: Non-Last Small IPv6 Fragments Michael Richardson
- Never fragment: getting PMTU info transmitted rel… Michael Richardson
- Re: Never fragment: getting PMTU info transmitted… Joel M. Halpern
- Re: Never fragment: getting PMTU info transmitted… Brian E Carpenter
- Re: Never fragment: getting PMTU info transmitted… Tom Herbert
- Re: Never fragment: getting PMTU info transmitted… Michael Richardson
- Re: Never fragment: getting PMTU info transmitted… Brian E Carpenter
- Re: Never fragment: getting PMTU info transmitted… Mark Smith
- Re: Never fragment: getting PMTU info transmitted… Erik Kline
- Re: Never fragment: getting PMTU info transmitted… Mark Smith
- Re: Never fragment: getting PMTU info transmitted… Tom Herbert
- Re: Never fragment: getting PMTU info transmitted… Brian E Carpenter
- RE: Never fragment: getting PMTU info transmitted… Lubashev, Igor
- Re: Never fragment: getting PMTU info transmitted… Tom Herbert
- RE: Never fragment: getting PMTU info transmitted… Lubashev, Igor
- Re: Never fragment: getting PMTU info transmitted… C. M. Heard
- Re: Never fragment: getting PMTU info transmitted… Christian Huitema