Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

Joe Touch <touch@strayalpha.com> Fri, 06 September 2019 15:32 UTC

Return-Path: <touch@strayalpha.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 F281D120D56; Fri, 6 Sep 2019 08:32:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.219
X-Spam-Level:
X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 7AKtNbX7vVLN; Fri, 6 Sep 2019 08:32:08 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7133B120D55; Fri, 6 Sep 2019 08:32:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Q4709jO7XvKi+t4/7BfJUkf5VJqGtbbc/Z+UIjaSbSQ=; b=butDEiR3KQ19aS9UcC5baSWSl s+mrHULUKqWLlUyUbf/zNr43KDFqe0LnGBKOawGojyRJziJ9RSWmD0ZrsOpdBbp0gm+0JC23ZudBH tfjGdHWDfFF8/zEAe6tn4urTygZPwVqHpq/n759onyNQNjypCjVO9iVbsRocIK68uBy03HInAbe4z hy16w8KSSfdIjRH7K0ZgzH0pxhKU5llm68GznnJaihOHV7drfs8PBQzk97NwEhPoxGC8hlS8ROdAx y6gffP/Ect16BU/RD4InWC8oNbLT/6U6FG2cJ6nhylD49E0I46pkLA0BIdoB1qnteVup6uWZfLtmL qcTT8mxig==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:50754 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1i6GDT-000jdO-BL; Fri, 06 Sep 2019 11:32:07 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <3764D860-BC6F-441A-86EF-59E1742D7654@employees.org>
Date: Fri, 6 Sep 2019 08:32:02 -0700
Cc: Bob Hinden <bob.hinden@gmail.com>, "int-area@ietf.org" <int-area@ietf.org>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, IESG <iesg@ietf.org>, Joel Halpern <joel.halpern@ericsson.com>, "draft-ietf-intarea-frag-fragile@ietf.org" <draft-ietf-intarea-frag-fragile@ietf.org>, Suresh Krishnan <suresh@kaloom.com>, "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <939AFA6F-4C75-4532-82DE-77D14ABC41ED@strayalpha.com>
References: <efabc7c9f72c4cd9a31f56de24669640@boeing.com> <2EB90A57-9BBD-417C-AEDB-AFBFBB906956@gmail.com> <CAHw9_iKozCAC+8TGS0fSxVZ_3pJW7rnhoKy=Y3AxLqWEXvemcA@mail.gmail.com> <4C8FE1C4-0054-4DA1-BC6E-EBBE78695F1B@gmail.com> <BYAPR05MB5463F112A3FFA8CE6378F3D3AEBB0@BYAPR05MB5463.namprd05.prod.outlook.com> <ab0d5600-d71c-9f0b-2955-64074e040bc6@strayalpha.com> <E770BEF0-D901-4CD0-96E6-C626B560DCD6@gmail.com> <163CD364-2975-467A-8925-F114FFD9C422@employees.org> <E00B6159-2771-42D8-B5E8-7750E0B828DE@strayalpha.com> <3764D860-BC6F-441A-86EF-59E1742D7654@employees.org>
To: Ole Troan <otroan@employees.org>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/Ps5GTBW8uvZCCxB_lKds8VCrBIU>
Subject: Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
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, 06 Sep 2019 15:32:10 -0000


> On Sep 6, 2019, at 7:50 AM, Ole Troan <otroan@employees.org> wrote:
> 
> Joe,
> 
>> Comments below. 
>> 
>>> On Sep 5, 2019, at 11:33 PM, Ole Troan <otroan@employees.org> wrote:
>>> 
>>> Bob, et al,
>>> 
>>> I have two issues with this text.
>>> 
>>> 1) It introduces something new and undescribed in paragraph 2.
>>> "unless they also include mechanisms to detect that IP fragmentation isn't working
>>> reliably."
>>> That seems like hand-waving to me. Suggest deleting.
>> 
>> Fragmentation success or failure is directly testable. Any feedback mechanism will work and specific ones are mentioned elsewhere (PLPMTUD).
>> 
>> This differs from ICMP black-holing in path MTU detection.
> 
> Can you please point me to where in the PLPMTUD document testing for IP fragmentation is described?

Any feedback mechanism will detect when fragmentation - or anything else - prevents delivery.

> I thought PLPMTUD found the largest unfragmented size of a datagram.

It does - by trying larger sizes and telling the next layer down not to fragment. But if there are layers below that either ignore that or aren’t directly controlled that do fragment and those fragments don’t get through, it will back off.

> 
>>> 2) Paragraph 4:
>>> "The risks of IP fragmentation can also be mitigated
>>> through the use of encapsulation, e.g., by transmitting IP fragments
>>> as payloads."
>>> 
>>> This seems like proposing new unspecified solutions with it's own set
>>> of considerations.
>> 
>> Specific widely-deployed methods are mentioned elsewhere in the doc, including GRE and UDP.
> 
> Sorry, I couldn't find those either.
> Inner fragmentation, firstly is only applicable to IPv4. And only applicable to tunnels.
> And both those specs go to great length in avoiding fragmentation.

If you fragment and put the result inside GRE or UDP, the impact of the fragment (interfering with flow-based multi path routing, nat traversal, etc) is overcome.

> 
>>> IP fragmentation is a general solution to all hosts,
>>> encapsulation is certainly not in every host,
>> 
>> Actually, it is - unless you’re claiming hosts don’t support UDP.
> 
> Sorry, I don't understand what you mean.
> Are you saying that a new UDP applications should support the following stack:
> 
> IPv6 + UDP + IPv6 + FH + UDP + Applcation data

Yes - if they need FH and can’t do it any other way.

> So to be able to hide IP fragments from the network?

Yes - and again, this already happens for things like IPsec tunnels over UDP.

> While still having to do the full PLPMTUD to function correctly?

No; those would be used in different contexts. PLPMTUD is intended to avoid fragmentation but was given above as one of many examples of ways to determine when fragmentation caused a problem. E.g. (not that anyone needs to do this, but it’s reasonable):

	- test using PLPMTUD
	- if that fails, the app can decide what to do next
		a) use a smaller MTU
		b) fragment and encapsulate

Others have pointed out that there are measurements that indicate that (b) can be more efficient; regardless, it’s a choice.

> 
>>> and has different
>>> properties with regards to NAT traversal etc.
>> 
>> If by “different” you mean “much more likely to succeed”, agreed.
> 
> I need to see numbers of that. But regardless I don't see the relevance to this document.

It’s the defining reason that IPsec over UDP was developed and is widely deployed. Just look at RFCs or the IANA list of assigned ports for how many protocols are “over UDP” simply to traverse NATs.

> 
>>> vAlso if encapsulation
>>> was the answer, other segmentation / reassembly that were tunnel
>>> specific could be developed.
>> 
>> It is and is widely used - IPsec tunnels over UDP, e.g.
> 
> That's a encapsulated solution to start with.

IPsec wasn’t encapsulated. Adding encapsulation is the way it traverses tunnels.

> 
>>> Regardless this also amounts of hand-waving
>>> and doesn't seem to offer any advice that can be heeded now.
>>> And of course encapsulation can also exacerbate the problem
>>> by increasing packet size.
>> 
>> Yes, it makes the fragments smaller, which may be additional effort/performance impact, but it completely hides its impact on successful forwarding.
> 
> You may be making a point. I'm afraid I don't get it.

You keep saying this doesn’t help but it’s widely deployed and used already. 

joe