Re: Non-Last Small IPv6 Fragments

Bob Hinden <bob.hinden@gmail.com> Sun, 13 January 2019 18:54 UTC

Return-Path: <bob.hinden@gmail.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 77921129AB8 for <ipv6@ietfa.amsl.com>; Sun, 13 Jan 2019 10:54:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 j2RBXSg1lHVH for <ipv6@ietfa.amsl.com>; Sun, 13 Jan 2019 10:54:56 -0800 (PST)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 A298412870E for <ipv6@ietf.org>; Sun, 13 Jan 2019 10:54:55 -0800 (PST)
Received: by mail-wr1-x42f.google.com with SMTP id c14so20583101wrr.0 for <ipv6@ietf.org>; Sun, 13 Jan 2019 10:54:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=T9LLUdr+wnVUdipUKKebiUQqNt/vzQ3tRYHR3RsXDqw=; b=c7koIRB6+37BsdAAWBsSffK3qJtitaptUpqhQnxXLyAm5CXepEHJuV+ZmFLS+9Q4Jn dkG4uoqgbvTbp1kX9RZs1KrRoo7erLfNIl2BtFbF522WVfWffoSE7KIqKSilfL4Dx2lT 9B/BYkHZ1yTRJuHk5hl27GELrUcPD7RjiYZE55066PDCSN6ku1zNweuvGg8EQXMnmu2I o4uJIJMmCvcMhUSzWqstUIKHkFGdWPT7pGK7FGHkxYFLdODrvQaxRuKVpOT+dR69KWCT J+76VwP3hDT58rewcD+CKyRGiDVi2OUBNapE8cS51T5jvQ4RodndmOL/Vv5a3k6RTb36 KlRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=T9LLUdr+wnVUdipUKKebiUQqNt/vzQ3tRYHR3RsXDqw=; b=R030i9Wz/EBvE+jWSv+sCwY9tlQAwWRODiMK4nRyzErRBiGawSNfhMENI8buWfSyK0 I1NVAHUE6F2SjDIHAhWnqoof6kzEWBBySEEsK4Pnw06L4hmkeLrpYjFt8XpgctvgTx6T wzjABhFp8rMXcUPBjJAcYofKpZNPlF9PRfzU34XzZGwA6yQohXDryWU6xc8ryT6LVUhb nbESnbyi2FRkwE3hMCm2gVGdgtUgA2zMJXl6MJXqJYUMfQ5ShRCiRlVAMCHC4CBN6tGr D9xlbIdmg0gvLsN0To9Ud66t6m8F6NHN0VFw3WN4k09CbPeXc1mND/NFbj5WKyvjMz+S +VzA==
X-Gm-Message-State: AJcUukfjt1b5KcvZc/+vS2pWTd0cO7AnqHlpReO8CNCBBNGOyMqlzRoi Q1MueP3S7/mAO+Bdqerz3njyB/LO
X-Google-Smtp-Source: ALg8bN4XEC4oG7wly3AMNb53JDEFjVYqABuqjE1ImlWbTU0OFf/MOb6ORZ90qwRkZsFyTRBTHvcHDA==
X-Received: by 2002:a5d:4a0c:: with SMTP id m12mr21102177wrq.38.1547405693775; Sun, 13 Jan 2019 10:54:53 -0800 (PST)
Received: from ?IPv6:2601:647:4d01:f3a:e8a3:405b:938a:7f9a? ([2601:647:4d01:f3a:e8a3:405b:938a:7f9a]) by smtp.gmail.com with ESMTPSA id v12sm42228371wmd.27.2019.01.13.10.54.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Jan 2019 10:54:52 -0800 (PST)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <AEA47E27-C0CB-4ABE-8ADE-51E9D599EF8F@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_CE385CB5-043E-4D0D-812C-3968347AFA6E"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Non-Last Small IPv6 Fragments
Date: Sun, 13 Jan 2019 10:54:33 -0800
In-Reply-To: <A3C3F9C0-0A07-41AF-9671-B9E486CB8246@employees.org>
Cc: Bob Hinden <bob.hinden@gmail.com>, Ole Trøan <otroan@employees.org>, Tom Herbert <tom@herbertland.com>
To: IPv6 List <ipv6@ietf.org>
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> <312A771E-9E5B-4E33-926F-EDF46C4CB925@employe es.org> <CALx6S36V7vrVyoTP0G6+S5XeFNB3KWS5UaNnVi20xogRERdCfg@mail.gmail.com> <973A1649-55F6-4D97-A97F-CEF555A4D397@employees.org> <CALx6S34YbBe8xBod3VsWVO33TpZcdxh2uV1vaO8Z_NKnVXp66g@mail.gmail.com> <A3C3F9C0-0A07-41AF-9671-B9E486CB8246@employees.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/WFd1p_cg2bQuYzYlp3UrPxmpJzw>
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: Sun, 13 Jan 2019 18:54:58 -0000

Unleveling a bit.

I think the w.g. should be very cautious about making protocol changes based on what appears to be a fragmentation resource management problem in an implementation.

The fix of “..reject IPv6 fragments less than 1280 that aren't last fragment” seems pretty limited as discussed on the list.   Seems to me that this implementation needs more robust ability to handles it’s reassembly resources.

Bob



> On Jan 12, 2019, at 11:45 AM, Ole Troan <otroan@employees.org> wrote:
> 
> Tom,
> 
>> On 12 Jan 2019, at 20:27, Tom Herbert <tom@herbertland.com> wrote:
>> 
>>> On Sat, Jan 12, 2019 at 10:50 AM Ole Troan <otroan@employees.org> wrote:
>>> 
>>> 
>>> 
>>>>> On 12 Jan 2019, at 18:17, Tom Herbert <tom@herbertland.com> wrote:
>>>>> 
>>>>> On Sat, Jan 12, 2019 at 1:49 AM Ole Troan <otroan@employees.org> wrote:
>>>>> 
>>>>> Fernando said:
>>>>>> 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.
>>>>>> 
>>>>>> 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.
>>>>> 
>>>>> In e.g. VPP limiting fragment size would not help at all.
>>>>> The scarce resource is number of available buffers. One fragment occupies at least one buffer regardless of how much smaller than 2K (default buffer size) it is.
>>>>> 
>>>>> Mitigations against attack is highly likely to be implementation specific.
>>>>> As an example see:
>>>>> https://github.com/FDio/vpp/blob/master/src/vnet/ip/ip6_reassembly.c
>>>>> 
>>>>> Default reassembly timeout is 100ms (constrasting that with the RFC 60s)
>>>>> Maximum consequtive reassemblies in progress is limited to 1024.
>>>>> And in other virtual reassembly algorithms we have also limited maximum allowed number of fragments in chain to 5.
>>>>> 
>>>> Ole,
>>>> 
>>>> I don't know what the protocol requirements are for virtual
>>>> reassembly. Is there an I-D or RFC on this?
>>> 
>>> Virtual reassembly is just an optimization. The protocol requirements are the same.
>>> 
>> The same as what requirements? RFC8200 defines how reassembly occurs
>> at a destination (the addressed node), not how an intermediate node in
>> the network reassembles packets. It is not the same thing. For
>> instance, there is an additional implicit requirement in virtual
>> reassembly that all fragments are routed through the same node. Also,
>> Hop-by-Hop options and Destination options can precede the fragment
>> header, so is the requirement that same that nodes MUST process these
>> before the fragmentation header is processed?
>> 
>> If virtual reassembly is brought up in the context of standard
>> protocol discussion, it would really be nice to have a normative
>> desciption of that protocol mechanism.
> 
> The code example I gave was for host reassembly.
> I didn’t intend with my comment any more than that this is quite implementation specific, that it’s not obvious that the IETF can provide anything useful here, apart from removing network layer fragmentation, and I was absolutely not suggesting we should have a document on in-network reassembly.
> 
> Cheers
> Ole
>> 
>> Tom
>> 
>>> Cheers
>>> Ole
>>> 
>>> 
>>>> 
>>>> Thanks,
>>>> Tom
>>>> 
>>>>> Now, if we in the IETF think we can provide some guidance here, I will second Erik’s suggestion of getting more research.
>>>>> 
>>>>> The packet traces I have looked at in the past, the majority of fragmeted packets looked like attacks. UDP port 80, DNS queries to “thisdomainnamewillgiveaverylongresponsepurelyforthepurposeofattack.org”,
>>>>> didn’t reassemble, 64K size… But it would be interesting to understand fragmentation behaviour in various parts of the network.
>>>>> 
>>>>> - how long are fragment chains (both in packets and in time span)
>>>>> - ratio of out of order fragments
>>>>> - which applications use fragments
>>>>> - ratio of attack traffic using fragments
>>>>> - average/min/maximum sizes, same for numbers of fragments in chain
>>>>> - ratio of complete fragment chain following the same path in the network
>>>>> - ratio of fragments to total traffic
>>>>> 
>>>>> Cheers,
>>>>> Ole
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --------------------------------------------------------------------
>>>>> IETF IPv6 working group mailing list
>>>>> ipv6@ietf.org
>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>> --------------------------------------------------------------------
>>> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------