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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Fri, 06 September 2019 22:28 UTC

Return-Path: <Fred.L.Templin@boeing.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 B5C56120E0E; Fri, 6 Sep 2019 15:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 hpfK4LslBTmE; Fri, 6 Sep 2019 15:28:18 -0700 (PDT)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 7138B120DFA; Fri, 6 Sep 2019 15:28:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id x86MSGXS011139; Fri, 6 Sep 2019 18:28:16 -0400
Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id x86MSBan009999 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 6 Sep 2019 18:28:11 -0400
Received: from XCH16-07-07.nos.boeing.com (144.115.66.109) by XCH16-07-07.nos.boeing.com (144.115.66.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1713.5; Fri, 6 Sep 2019 15:28:09 -0700
Received: from XCH16-07-07.nos.boeing.com ([fe80::7897:2974:6af3:208e]) by XCH16-07-07.nos.boeing.com ([fe80::7897:2974:6af3:208e%6]) with mapi id 15.01.1713.004; Fri, 6 Sep 2019 15:28:09 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Tom Herbert <tom@herbertland.com>
CC: Ole Troan <otroan@employees.org>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "int-area@ietf.org" <int-area@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>
Thread-Topic: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
Thread-Index: AQHVZPaFqcueY9bbbkKMLOh+/fHm66cfo9KA//+NDnA=
Date: Fri, 6 Sep 2019 22:28:09 +0000
Message-ID: <f4fe59daaabd4888b8b361fa8321eefd@boeing.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> <CALx6S37yqj=7LBxPTgE9Vz9P_eAvhfoj7csNn6cz1Wn0YXycQQ@mail.gmail.com> <862ab385eb004e3cb5beda1b7a9f7856@boeing.com> <CALx6S35O=TAtOoTZA8Z7udd86fRFV4ds2zj2xg-RPHNdr-AgKg@mail.gmail.com>
In-Reply-To: <CALx6S35O=TAtOoTZA8Z7udd86fRFV4ds2zj2xg-RPHNdr-AgKg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: D78C1336EBF2DB78FC003F1A3499302F04D7AD76B689BE31F839DE4F7C57240F2000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/vImvtBEEYWfqs3yM_RmxqfvUfW4>
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 22:28:23 -0000

Tom,

> -----Original Message-----
> From: Tom Herbert [mailto:tom@herbertland.com]
> Sent: Friday, September 06, 2019 2:44 PM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: Ole Troan <otroan@employees.org>rg>; Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>rg>; int-area@ietf.org; IESG
> <iesg@ietf.org>rg>; Joel Halpern <joel.halpern@ericsson.com>om>; draft-ietf-intarea-frag-fragile@ietf.org; Suresh Krishnan
> <suresh@kaloom.com>om>; intarea-chairs@ietf.org
> Subject: Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
> 
> On Fri, Sep 6, 2019 at 2:03 PM Templin (US), Fred L
> <Fred.L.Templin@boeing.com> wrote:
> >
> > Hi Tom,
> >
> > > -----Original Message-----
> > > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Tom Herbert
> > > Sent: Friday, September 06, 2019 11:21 AM
> > > To: Ole Troan <otroan@employees.org>
> > > Cc: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>rg>; int-area@ietf.org; IESG <iesg@ietf.org>rg>; Joel Halpern
> > > <joel.halpern@ericsson.com>om>; draft-ietf-intarea-frag-fragile@ietf.org; Suresh Krishnan <suresh@kaloom.com>om>; intarea-
> > > chairs@ietf.org
> > > Subject: Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
> > >
> > > On Thu, 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.
> > > >
> > > > 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. IP fragmentation is a general solution to all hosts,
> > > >    encapsulation is certainly not in every host, and has different
> > > >    properties with regards to NAT traversal etc. Also if encapsulation
> > > >    was the answer, other segmentation / reassembly that were tunnel
> > > >    specific could be developed. 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.
> > > >    Suggest deletion.
> > > >
> > > Ole,
> > >
> > > This also makes the implicit and seemingly unproven assumption that
> > > encapsulation is less fragile than IP fragmentation on the Internet.
> >
> > With the rise of the middle and network-based (deep) packet inspection, I
> > think the statement could be considered that all things on the Internet are
> > potentially fragile or could become so in the future. Certainly we know that
> > naked IP fragments are filtered over many paths, and we have a strong
> > intuition that if we clothe them in "innocent-looking" clothing that they will
> > be far more likely to get through. For example, I don't think UDP port 6080
> > (or even 8060) are on many middlebox blacklists yet.
> 
> Fred,
> 
> I suspect a lot of firewalls whitelist UDP ports (e.g. DNS and maybe
> QUIC might be the only UDP applications that commonly pass firewalls).

But, how that came about is through some sort of successful marketing of
those protocols - a good reputation. The current draft at hand smacks of
spreading an unqualified bad reputation and we need to make sure that
the good applications of fragmentation don't get swept up in that. And,
IP fragmentation for tunnels is a good application. 

> > > Without the data that shows otherwise, I don't believe there is any
> > > basis to say that encapsulation is generally a viable alternative.
> >
> > I don't think gathering data in a snapshot of time today could serve as a
> > predictor of the state of affairs a few weeks/months/years down the
> > road from now. But, what we believe is that right here; right now we
> > are far more likely to get a whole IP/UDP packet that contains an IP
> > fragment through than we are to get a naked IP fragment through.
> >
> Where is the data to show that? It's a bit paradoxical that we have
> declared IP fragmentation to be fragile based because the data "shows"
> that and we assume that is a predictor of the future for IP
> fragmentation, but yet in the same breath the draft would suggest
> alternatives that with no deployment experience on the Internet and no
> data to support that they will fare any better than fragmentation.

It's like I said both above and below - all data can show is a snapshot in time,
but what really matters going forward is word-of-mouth reputation. Declare
X as evil, and everyone will block it; declare the opposite and everyone will
accept it. And word-of-mouth reputation in our field comes from RFCs.

> > I think if we deployed on the Internet today in innocuous headers like
> > UDP port 6080/8060 we could start getting the word out that IP fragments
> > carried in these protocols are good - not evil - and the proper way to
> > transport them. It's like anything else in the Internet in terms of what
> > middleboxes will pass vs. block; reputation is everything.
> >
> > > Also, I would note that there was similar text in early versions of
> > > RFC8200 that encapsulation could be used as a method of allowing
> > > extension header insertion. That text was taken out because
> > > encapsulation is not sufficiently standardized or ubiquitous to be
> > > considered a direct replacement for an IP network layer protocol
> > > function. The same is true here, encapsulation is not a drop-in
> > > replacement for IP fragmentation.
> >
> > No; not a replacement for IP fragmentation but rather a vehicle for
> > carrying IP fragments. It is still good old IP fragmentation.
>
> But, it's NOT IP fragmentation. Support for IP reassembly is a host
> requirement. From RFC1122: "The Internet model requires that every
> host support reassembly". The implication of this requirement is that
> if I send a fragmented packet to any host on the Internet the
> expectation is that the receiving host can reassemble the packet.
> Support for IP reassembly has long been is ubiquitous in host
> implementations, and as long as the network doesn't interfere
> fragmentation will work and packets will be reassembled. This is true
> for IPv4 and IPv6. There is no requirement that any encapsulation must
> be processed by a receiving host. So if someone sends an encapsulated
> packet (via GUE, IPIP, GRE, etc.) with fragments to some random
> destination, there's no guarantee at all that the receiving host will
> do anything with. Encapsulation requires coordination between senders
> and receivers which does not exist in any general sense in the
> Internet.

I don't understand the point you are trying to make. The tunnel ingress
certainly needs to know that the egress is capable of removing the outer
encapsulations and reassemble - no one is suggesting otherwise. But, it
is still IP fragmentation and reassembly.

> This discussion underscores a flaw of this draft I believe. While
> there is a recommendation to avoid fragmentation, there really is no
> robust substitute offered to replace the functionality. All the
> alternatives either only work in narrow circumstances, may or may not
> themselves be fragile, or place undue burden on application and
> protocol developers to deal with something they have previously been
> told they weren't supposed to worry about.

Fragmentation is needed for tunnels. Else, a tunnel that traverses a 1280 link
will black hole. But, we should do better than that; call the tunnel MTU 9180
and use IP fragmentation in a link adaptation fashion, i.e., just like AAL5
except with a larger frame size.

Fred

> Tom
> 
> >
> > Fred
> >
> > > Tom
> > >
> > > > New text:
> > > >
> > > > 6.1.  For Application and Protocol Developers
> > > >
> > > >   Developers SHOULD NOT develop new protocols or applications that rely
> > > >   on IP fragmentation.  When a new protocol or application is deployed
> > > >   in an environment that does not fully support IP fragmentation, it
> > > >   SHOULD operate correctly, either in its default configuration or in a
> > > >   specified alternative configuration.
> > > >
> > > >   While there may be controlled environments where IP fragmentation
> > > >   works reliably, this is a deployment issue and can not be known to
> > > >   someone developing a new protocol or application.  It is not
> > > >   recommended that new protocols or applications be developed that rely
> > > >   on IP fragmentation.  Protocols and applications that rely on IP
> > > >   fragmentation will work less reliably on the Internet.
> > > >
> > > >   Legacy protocols that depend upon IP fragmentation SHOULD be updated
> > > >   to break that dependency.  However, in some cases, there may be no
> > > >   viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP-
> > > >   in-IP encapsulation).  Applications and protocols cannot necessarily
> > > >   know or control whether they use lower layers or network paths that
> > > >   rely on such fragmentation.  In these cases, the protocol will
> > > >   continue to rely on IP fragmentation but should only be used in
> > > >   environments where IP fragmentation is known to be supported.
> > > >
> > > >   Protocols may be able to avoid IP fragmentation by using a
> > > >   sufficiently small MTU (e.g.  The protocol minimum link MTU),
> > > >   disabling IP fragmentation, and ensuring that the transport protocol
> > > >   in use adapts its segment size to the MTU.  Other protocols may
> > > >   deploy a sufficiently reliable PMTU discovery mechanism
> > > >   (e.g.,PLMPTUD).
> > > >
> > > >   UDP applications SHOULD abide by the recommendations stated in
> > > >   Section 3.2 of [RFC8085].
> > > >
> > > >
> > > > Cheers,
> > > > Ole
> > > >
> > > > > On 6 Sep 2019, at 06:05, Bob Hinden <bob.hinden@gmail.com> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Joe and I talked off list.   The result is below.  Changes were to add a sentence in the forth and fifth paragraphs.
> > > > >
> > > > > Please review.
> > > > >
> > > > > Bob
> > > > >
> > > > > ----------
> > > > >
> > > > > 6.1.  For Application and Protocol Developers
> > > > >
> > > > >   Developers SHOULD NOT develop new protocols or applications that rely
> > > > >   on IP fragmentation.  When a new protocol or application is deployed
> > > > >   in an environment that does not fully support IP fragmentation, it
> > > > >   SHOULD operate correctly, either in its default configuration or in a
> > > > >   specified alternative configuration.
> > > > >
> > > > >   While there may be controlled environments where IP fragmentation
> > > > >   works reliably, this is a deployment issue and can not be known to
> > > > >   someone developing a new protocol or application.  It is not
> > > > >   recommended that new protocols or applications be developed that rely
> > > > >   on IP fragmentation.  Protocols and applications that rely on IP
> > > > >   fragmentation will work less reliably on the Internet unless they
> > > > >   also include mechanisms to detect that IP fragmentation isn't working
> > > > >   reliably.
> > > > >
> > > > >   Legacy protocols that depend upon IP fragmentation SHOULD be updated
> > > > >   to break that dependency.  However, in some cases, there may be no
> > > > >   viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP-
> > > > >   in-IP encapsulation).  Applications and protocols cannot necessarily
> > > > >   know or control whether they use lower layers or network paths that
> > > > >   rely on such fragmentation.  In these cases, the protocol will
> > > > >   continue to rely on IP fragmentation but should only be used in
> > > > >   environments where IP fragmentation is known to be supported.
> > > > >
> > > > >   Protocols may be able to avoid IP fragmentation by using a
> > > > >   sufficiently small MTU (e.g.  The protocol minimum link MTU),
> > > > >   disabling IP fragmentation, and ensuring that the transport protocol
> > > > >   in use adapts its segment size to the MTU.  Other protocols may
> > > > >   deploy a sufficiently reliable PMTU discovery mechanism
> > > > >   (e.g.,PLMPTUD).  The risks of IP fragmentation can also be mitigated
> > > > >   through the use of encapsulation, e.g., by transmitting IP fragments
> > > > >   as payloads.
> > > > >
> > > > >   UDP applications SHOULD abide by the recommendations stated in
> > > > >   Section 3.2 of [RFC8085].
> > > > >
> > > > > —————
> > > > >
> > > > >
> > > > >
> > > > >> On Sep 5, 2019, at 6:18 PM, Joe Touch <touch@strayalpha.com> wrote:
> > > > >>
> > > > >> Although this is close, it misses the mark a little on the issue that
> > > > >> the app may not actually have any control here - or know how or when to
> > > > >> reduce its MTU. That might be a minor point to add, but is worth adding.
> > > > >> This isn't just an app layer issue.
> > > > >>
> > > > >> Joe
> > > > >>
> > > > >> On 9/5/2019 4:45 PM, Ron Bonica wrote:
> > > > >>> Bob,
> > > > >>>
> > > > >>> I think that this is a close to consensus as we are going to get.
> > > > >>>
> > > > >>>                                          Ron
> > > > >>>
> > > > >>>
> > > > >>> Juniper Business Use Only
> > > > >>>
> > > > >>> -----Original Message-----
> > > > >>> From: Bob Hinden <bob.hinden@gmail.com>
> > > > >>> Sent: Thursday, September 5, 2019 2:29 PM
> > > > >>> To: int-area@ietf.org
> > > > >>> Cc: Bob Hinden <bob.hinden@gmail.com>om>; Alissa Cooper <alissa@cooperw.in>in>; IESG <iesg@ietf.org>rg>; Joel Halpern
> > > <joel.halpern@ericsson.com>om>; draft-ietf-intarea-frag-fragile@ietf.org; intarea-chairs@ietf.org; Suresh Krishnan
> > > <suresh@kaloom.com>
> > > > >>> Subject: Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
> > > > >>>
> > > > >>> Hi,
> > > > >>>
> > > > >>> Based on the discussion, I would like to propose to see if this will resolve the issues raised.   It attempts to cover the issues
> > > raised.
> > > > >>>
> > > > >>> The full section 6.1 is included below, but only the last sentence in the second paragraph changed.
> > > > >>>
> > > > >>> Please review and comment.
> > > > >>>
> > > > >>> Thanks,
> > > > >>> Bob
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> 6.1.  For Application and Protocol Developers
> > > > >>>
> > > > >>>  Developers SHOULD NOT develop new protocols or applications that rely
> > > > >>>  on IP fragmentation.  When a new protocol or application is deployed
> > > > >>>  in an environment that does not fully support IP fragmentation, it
> > > > >>>  SHOULD operate correctly, either in its default configuration or in a
> > > > >>>  specified alternative configuration.
> > > > >>>
> > > > >>>  While there may be controlled environments where IP fragmentation
> > > > >>>  works reliably, this is a deployment issue and can not be known to
> > > > >>>  someone developing a new protocol or application.  It is not
> > > > >>>  recommended that new protocols or applications be developed that rely
> > > > >>>  on IP fragmentation.  Protocols and applications that rely on IP
> > > > >>>  fragmentation will work less reliably on the Internet unless they
> > > > >>>  also include mechanisms to detect that IP fragmentation isn't working
> > > > >>>  reliably.
> > > > >>>
> > > > >>>  Legacy protocols that depend upon IP fragmentation SHOULD be updated
> > > > >>>  to break that dependency.  However, in some cases, there may be no
> > > > >>>  viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP-
> > > > >>>  in-IP encapsulation).  In these cases, the protocol will continue to
> > > > >>>  rely on IP fragmentation but should only be used in environments
> > > > >>>  where IP fragmentation is known to be supported.
> > > > >>>
> > > > >>>  Protocols may be able to avoid IP fragmentation by using a
> > > > >>>  sufficiently small MTU (e.g.  The protocol minimum link MTU),
> > > > >>>  disabling IP fragmentation, and ensuring that the transport protocol
> > > > >>>  in use adapts its segment size to the MTU.  Other protocols may
> > > > >>>  deploy a sufficiently reliable PMTU discovery mechanism
> > > > >>>  (e.g.,PLMPTUD).
> > > > >>>
> > > > >>>  UDP applications SHOULD abide by the recommendations stated in
> > > > >>>  Section 3.2 of [RFC8085].
> > > > >>>
> > > > >>> _______________________________________________
> > > > >>> Int-area mailing list
> > > > >>> Int-area@ietf.org
> > > > >>> https://www.ietf.org/mailman/listinfo/int-area
> > > > >
> > > >
> > > > _______________________________________________
> > > > Int-area mailing list
> > > > Int-area@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/int-area
> > >
> > > _______________________________________________
> > > Int-area mailing list
> > > Int-area@ietf.org
> > > https://www.ietf.org/mailman/listinfo/int-area