Re: [Int-area] draft-bonica-intarea-frag-fragile-01

Tom Herbert <tom@herbertland.com> Fri, 01 June 2018 18:47 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0CD12DA48 for <int-area@ietfa.amsl.com>; Fri, 1 Jun 2018 11:47:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] 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 P_RQLHkr-UkM for <int-area@ietfa.amsl.com>; Fri, 1 Jun 2018 11:47:52 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 6962112E3AE for <int-area@ietf.org>; Fri, 1 Jun 2018 11:47:48 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id x34-v6so20090327qtk.5 for <int-area@ietf.org>; Fri, 01 Jun 2018 11:47:48 -0700 (PDT)
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=Wk6O7BmpM5VSZwV5WKu/waqdIjDADSqTNwLiNPNJBo4=; b=W33WSythgeoLGMT5vLPHWEG9KzGD9Lzut44mnjP100ceG6ZlEqxFgL2c/kqkLxl0d8 Z1EDbO3gPUNvQtqTu11BVHF8X3Y78J0kswYjCH9DTjztH8hgaiLbMPC8KxDyKvTJ8Coh B+O7zjxoHQgporYaqZcs6Jo0bFzmK1u0Odsrwv7OugPSN78ysqDH9+EM25ToiAvhKDlr GtFyGErCf3B9IslJfKFfR6T384Gqm2XOwwZ044Qyd4IcDJ941ORLpNKGy2uOgLQq0B+0 HGnKdLJuXUhaV09YVnhERoBpq91vYG4NCXLxH5XlCfO6DnnNyJ53qeVxzyyQEk01fwNr nQLw==
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=Wk6O7BmpM5VSZwV5WKu/waqdIjDADSqTNwLiNPNJBo4=; b=b5i0qorH14YiQUyVZ6JMj/D7sAy/GBwmUOZMNlrROPPGJKdZAYYk57yhJ/Z0D2UyN8 nBJWYnFc+5Ml+k0x3VomhFP6BOSmvN1kVGz3v2on9cX06+xOvE4UAlSLn0PWqcgZpH1x 2Jd4BM1GxrVIFiAV5sKudnG5/MwljUjg3i+Izu/IKR2UaPXyXtSXOyQzJSwBmdDv/rFq jZi8qwSdLYhsTbHewJot4PCAc8AN2mfcxtuCOrVeFr3UrrXrHUfu5uwqB4HmRBAghUeo 5dgN++2Q4L2/aA2vMnrDsoboU9OLmJqxmlG5HR7QhHC/C1VrW3gO50gPdHvAB3AK4PxI CeAw==
X-Gm-Message-State: APt69E2Xjr+fzhDCbVOTZSYdzD5mp6P+Bs4USJCGyAH5uGtT5E9i+8sO zRqpic2CbFBLDFR6p3ea0l6eLbZyhe3wv1nmzmlZGw==
X-Google-Smtp-Source: ADUXVKICvrdeYxrus4R6X++7XGZphQwKv0fkk54Ne4TnZBB3FaI9+JrNRf1TwyaYqGya/KzsQW0J3lqqNXh+eiszACo=
X-Received: by 2002:aed:2512:: with SMTP id v18-v6mr10036864qtc.396.1527878867414; Fri, 01 Jun 2018 11:47:47 -0700 (PDT)
MIME-Version: 1.0
References: <BLUPR0501MB2051C0DCCE28384FCD08F7C4AEDA0@BLUPR0501MB2051.namprd05.prod.outlook.com> <57DFBADC-9064-4DF8-AAC1-8C0DBB41D8A6@strayalpha.com> <76F3B3E5-6FA8-4A27-815C-32415E0D7CB6@gmail.com> <FCE8FC77-3A30-4EE3-B6A1-35969E7DD1E2@strayalpha.com> <SN6PR05MB424048AD14382C38788DE158AE630@SN6PR05MB4240.namprd05.prod.outlook.com> <855AFF4E-F2B7-4C35-ABA5-EFC571AF90F9@strayalpha.com> <alpine.DEB.2.20.1806011150370.17103@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.20.1806011150370.17103@uplift.swm.pp.se>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 01 Jun 2018 11:47:37 -0700
Message-ID: <CALx6S36i_c2yoL_Dz_TR9vtr4=i6dGQpDoFM77XyfH04PKH36Q@mail.gmail.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: Joe Touch <touch@strayalpha.com>, Ronald Bonica <rbonica@juniper.net>, "int-area@ietf.org" <int-area@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000027030a056d9905de"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/qEs1fnvsdfE5haRMYCZzkBi1gus>
Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jun 2018 18:48:04 -0000

On Fri, Jun 1, 2018, 2:54 AM Mikael Abrahamsson <swmike@swm.pp.se> wrote:

> On Thu, 31 May 2018, Joe Touch wrote:
>
> > I disagree.
> >
> > UDP fragmentation has its benefits and uses, but should not be required
> when a transport layer isn’t needed - e.g., for IP tunneling.
> >
> > Fundamentally, IP fragmentation is fragile for only a few reasons:
> > 1) the ID space is small (which shouldn’t matter unless there is a very
> large amount of reordering)
> > 2) loss of fragments creates inefficiencies (true, but routers can
> fate-share fragments they drop sometimes, just as was eventually done for
> ATM AAL5)
> > 3) in-network devices can’t find transport ports in some fragments,
> causing problems for NATs, policy filters and firewalls, etc.
> >
> > Of these, my view is that #3 is the only reason actually driving a claim
> of fragility - and all it tells me is that “the Internet is fragile when
> devices don’t follow the rules”.
> >
> > I do not think it is appropriate to validate that conclusion.
>
> You're fundamentally right, unfortunately operational reality adds lots of
> more points to your list, meaning the end outcome is that IP fragmentation
> doesn't work well in real life.
>
> I am as opposed to letting bad practices win as you probably are, but I
> also don't think this is fixable. This means applications need to have a
> mode where they do not rely on IP fragments for basic operation.
>

I agree with Joe. Would also note that #3 is not a problem with
fragmentation itself, but with middle boxes attempting to parse transport
layer information. That problem potentially exists any time a
"non-standard" IP protocol number is used (ie something other than UDP it
TCP). It would be best if the solution is to use generic mechanisms to
provide functionality, as opposed to discouraging use of protocols or
fragmentation. Using flow label for ECMP is s good example, this eliminates
need for DPI and works with fragmentation or any IP protocol.

I think this draft should distinguish problems inherent in IP fragmentation
and those that have be created by middle boxes that can't deal with
fragments

Tom


> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>