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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 28 July 2018 02:32 UTC

Return-Path: <brian.e.carpenter@gmail.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 039E912F1A5; Fri, 27 Jul 2018 19:32:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 KwD5dhibJtp6; Fri, 27 Jul 2018 19:32:18 -0700 (PDT)
Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (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 8C8A4130E32; Fri, 27 Jul 2018 19:32:18 -0700 (PDT)
Received: by mail-pg1-x543.google.com with SMTP id r1-v6so4210435pgp.11; Fri, 27 Jul 2018 19:32:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=YX/2p2HsEBCf/bNayXW9iwYrHxcDJGuERgvv4YyQjHQ=; b=Y9cr/hkYVXmqOvET5STdfkCTbWprz0PqxuIvQRdCeL/tQaJ1nZKe8x8NYHRjhIwAwf 3wrdH1/ly5I+KKi7NYdMlGqfFgo5g91JoEZMbFDGxqSGrbhkIlHz5MG+WRcntKuSLKk8 aEDLA45eL3jvshUHAEqLqHdzK49AIGvVVxY1Nyz3wnmHG6z/OpTdq8RFeJrro0svS+BH OD5b6Dn9YYT4252dgKUd4b504fBJR2wJjafoychiLZSKQLYxQPpHK7YRWcoFqiRIq6Ru kWimgNxQTSThTQJ/sLGT0IbmxfFhQ8T1wkysVE89WHO37ORd9sEVODN3lJspfSwp/zzT miTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YX/2p2HsEBCf/bNayXW9iwYrHxcDJGuERgvv4YyQjHQ=; b=tl8jyAxQZN9dTSo9YWP1aKfR8b3fEDStP8tA/lOjVyF9+212JcOMQBHT8aEaQOoBgJ pcqYeZO0YQfDMkEoWrb+vs3oBYsFNNlUTsqEYJJ2Bou5tD2y/5rAM3dqtGGvJAcj41Ex EFZj2dGiQ65yGjgf73hmZf5FGo5ajNVEA/vpaocyyZq9CXI/zooLXxZPP8VUzgI/0Fbk VgS0PogJZba+2PTe6MAvIy/KKIFngS2RnyWg9M7OieQd7hNnfNFB5e2pq3+Kt3K99JNF T9J485/+bZTOK8yrTWOoURua7NbaO4KNldn9+iLhq0oTdAQSdGqDS2ih5k23BQX9ngXg gWNw==
X-Gm-Message-State: AOUpUlHAlNG852LrklItCZyANnl0JXsMkp3BtXKc56gs3TrZ6wB9C6iU BAjDZ78Oal3PjkYlUPDRmLBv60f8
X-Google-Smtp-Source: AAOMgpcSo16hA+aq/kUHLbxC2qBxkNEIkYrdE18feP8YisZH3sSEQ8kT1pOQe28aKLCA6sTGhKgPgw==
X-Received: by 2002:a63:4b5a:: with SMTP id k26-v6mr7970736pgl.384.1532745137701; Fri, 27 Jul 2018 19:32:17 -0700 (PDT)
Received: from [192.168.178.40] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id c85-v6sm10643433pfd.110.2018.07.27.19.32.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jul 2018 19:32:16 -0700 (PDT)
To: Tom Herbert <tom@herbertland.com>, Fernando Gont <fgont@si6networks.com>
Cc: "internet-area@ietf.org" <int-area@ietf.org>, Fernando Gont <fernando@gont.com.ar>, "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>
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> <CALx6S35ktGh74_LdjVz2fCYNHLy3qFndN4amc57tdHZUDnhJxg@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <ce3fc953-5250-0d99-369e-c178ca34f414@gmail.com>
Date: Sat, 28 Jul 2018 14:32:22 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CALx6S35ktGh74_LdjVz2fCYNHLy3qFndN4amc57tdHZUDnhJxg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/3hBSkJGNXqwUqKADErRyP8OBKMk>
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: Sat, 28 Jul 2018 02:32:23 -0000

> The fallback is to only hash over addresses.

Hashing over addresses+flow-label is fine too. If the flow label
is zero, it's the same thing. If the flow label is set properly,
it's a better hash.

I believe this is covered in the various relevant RFCs already
(6437, 6438 and 7098).

Regards
   Brian

On 28/07/2018 10:38, Tom Herbert wrote:
> 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
>>
>>
>>
>>
> 
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>