Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

Tom Herbert <tom@herbertland.com> Fri, 27 July 2018 22:38 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 85DA2130E1D for <int-area@ietfa.amsl.com>; Fri, 27 Jul 2018 15:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 ZUduef3N2bL2 for <int-area@ietfa.amsl.com>; Fri, 27 Jul 2018 15:38:49 -0700 (PDT)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 5349D130DEA for <int-area@ietf.org>; Fri, 27 Jul 2018 15:38:48 -0700 (PDT)
Received: by mail-qt0-x235.google.com with SMTP id q12-v6so6669900qtp.6 for <int-area@ietf.org>; Fri, 27 Jul 2018 15:38:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LjyhMiumRselNbGe3z//T4q927T4n8081yeurMpyuWw=; b=LbAzVQgjtnU4CvjdnWDAU1mhFmzOYrnMGO+hAJrzp6FaKpGsZhueghUsCA1oBTzxAo b3Q+7vJTc1rzVy3m0ZwUKi/Wb3N8Bce+Rddt2UNrD4tgtUMDY1nD/jhxMWHh7TzdTsi9 BKtFUCx5bz1Xvx10e3sBLrrzxFSbD1T3KJCYIb1gnvLTbz6VK0c023zPuAcKbuKuvw7L lorE3vM7aVnXHv5nfy5GHAgUthyymTq5/f4ZmWMN4RfHBcKB65f3jRLRawVp3vrQiiCI 6vGBnvhLaqXHPj6nBdQs340CQ2ABlWEMnnuE6cDc+IXK2nJjKc2BJp9nZlyEQFPOILy+ QTDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LjyhMiumRselNbGe3z//T4q927T4n8081yeurMpyuWw=; b=XW9wfg2jepZyK5vl4zrcPXAMHFvmDrFkGn36uxy1vOogc3HS9ycj6yHYJTLjl21P5L N3jxSOswsbmhqFEC9vDNtZEnfl9lbRPDjMfKVWdSjicMZ1jYAC0HKMW9XL6A25RBYdJ9 rJRoUo16532dJDVMC6/gldqx/llJvCr00GWZ4FJIz4in8bqxY92L+UmMF5II/DQbV69M FwiEin5JPU1SSre+KaohIpZs59OWILC+RIyEMPKRoYjQySfimfT0geY/kxAOZgjWxr5N nNesGeM7JZJRNy9hwmmfZO763q6WQHUV1u38+lRTtUSB+OK1hh1JfcAVBaZBiL0yNwSW RHvw==
X-Gm-Message-State: AOUpUlH8hyDjKCXd6GRHmGylirnIcV1YM5aMJS565WapjnfEUA92yYCR fMf/WFGw+29cZub9mPL6+urBE4PgjdGxF8d7Q5pQqDSH
X-Google-Smtp-Source: AAOMgpdz8RWZ0AF+FpC7uxf2msFCPwXhdHBh6RZES6129nn/SFT+qmiwLmuvOW8IKges/kuEH0/qVQfzGG+zT/AVCXM=
X-Received: by 2002:ac8:22ac:: with SMTP id f41-v6mr8000825qta.197.1532731127392; Fri, 27 Jul 2018 15:38:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 15:38:46 -0700 (PDT)
In-Reply-To: <52f0bf01-fb08-2654-fedf-6b40fe41b0bf@si6networks.com>
References: <F227637E-B12D-45AA-AD69-74C947409012@ericsson.com> <0466770D-C8CA-49BB-AC10-5805CFDFB165@strayalpha.com> <8e5ba0b3-837e-02d1-d9d9-7c5e596c1774@gont.com.ar> <CALx6S34VMeLS7bqL4Zt0xZ+==5hUT7Q2=5m01a14mJ4B3J6G3g@mail.gmail.com> <50a1e177-6b37-b89a-2caf-5caf1cbc955b@gont.com.ar> <CALx6S34LmARXPyooLEq_zT3-UkSryfxHZT2G5C-x3tRtc13A4Q@mail.gmail.com> <52f0bf01-fb08-2654-fedf-6b40fe41b0bf@si6networks.com>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 27 Jul 2018 15:38:46 -0700
Message-ID: <CALx6S35ktGh74_LdjVz2fCYNHLy3qFndN4amc57tdHZUDnhJxg@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: Fernando Gont <fernando@gont.com.ar>, "internet-area@ietf.org" <int-area@ietf.org>, "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/HO75fjPxBX7hwAyu1aAHbxpvtHk>
Subject: Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.27
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, 27 Jul 2018 22:38:54 -0000

On Fri, Jul 27, 2018 at 11:54 AM, Fernando Gont <fgont@si6networks.com> wrote:
> Tom,
>
> On 07/27/2018 07:20 PM, Tom Herbert wrote:
> [....]
>>>
>>> For example, what happens with EHs has a lot to do with engineering:
>>> they could be made to work (e.g., remove performance impact), but
>>> devices would probably be more expensive. Folks buying gear wouldn't pay
>>> for something that its not used in practice, and vendors wouldn't just
>>> "improve" the boxes for free. -- yeah, you could argue that "hey, there
>>> shouldn't be penalties for EHs, since they are part of the core IPv6
>>> spec" -- but, while probably correct, that will not change reality.
>>>
>> Fernando,
>>
>> The irony is thatxtension headers (and alternative protocols as well),
>> including fragmentation, aren't supposed to have to "be made to work"
>> in intermediate devices. With the exception of Hop-by-Hop options they
>> are supposed to be ignored by design, and even in the case of
>> Hop-by-Hop options RFC8200 relaxed the requirements so that they can
>> be ignored. Extension headers are considered problematic only because
>> of ad hoc assumptions made for "value add", non-standard features
>> implemented in intermediate devices.
>
> Please see:
> <https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-03>
>
> theory != practice. And no matter how right you might be, that doesn't
> make the theory a reality.
>
>
>
>>> Not that I like the situation, but... I think the least we can do is to
>>> do a reality check wrt how things are supposed to work vs. how they
>>> actually work.
>>>
>>> For this particular case, this I-D makes that point for fragmentation: I
>>> I think we all agree that fragmentation is fragile -- making that point
>>> clear at least raises awareness of the problem, and might trigger some
>>> action on the topic (whether to correct the issue, or to circumvent it).
>>>
>> Right, but I still think that we should be more clear about the root
>> origin of problems and blunt in requesting that non-conformant
>> implementations get fixed.
>
> That is certainly not going to happen. From the pov of the folks
> operating the networks, there's nothing broken.
>
>
>> For instance, as I mentioned the ECMP
>> hasing problem with fragmentation is entriely solvable if only
>> intermediate devices will use flow label instead of trying to find
>> ports for a hash.
>
> Yes and no. There was at least a time in which the flow label wasn't set
> at all, or even was mistaenly set (e value during 3WHS, a different
> value afterwards). That means that you cannot really rely on it. If you
> cannot rely on it, you need a back-up mechanism. And that mechanism is
> inspecting the trasnport port numbers -- from that point of view,
> there's not much sense in dong ECMP with the FL if you cannot rely on it
> and somehow you'd have to be prepared to do it based on addresses and
> port numbers.

The fallback is to only hash over addresses. Hashing over ports is not
reliable and can be problematic in itself. For instance, wrt
fragmentation, some middleboxes will use ports in the first fragment
but fall back to hashing over addresses for rest of fragments. This
mean the first fragment almost always takes a different path which can
wreak havoc on down stream devices that aren't expecting that. So
maybe it's another recommendation in this draft that middleboxes don't
use port information from first fragment to do load balancing. This is
another relatively easy fix.

Tom

>
>
>> Fixing devices to support this reasonable and should
>> be low cost.  IMO, use of flow label for ECMP should be a strong
>> recommendation made in this draft.
>
> I wouldn't mind. However, that doesn't change the fact that
> fragmentation is fragile.
>
> That said, if you look at RFC7872, t all looks like anything that is EHs
> is dropped to some extent (while not included in the RFC, I also mesured
> IPsec, and you get similar numbers). So besides the issues that are
> specific to fragmentation, anything that is EHs gets dropped here an
> there. -- and ding ECMP with the FL will not change that.
>
> (Again: not that I'm happy with the situation... but being unhappy will
> not change reality anyway :-) )
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>