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

Tom Herbert <tom@herbertland.com> Fri, 06 September 2019 18:21 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 82C54120073 for <int-area@ietfa.amsl.com>; Fri, 6 Sep 2019 11:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 VsdrVfNASgx7 for <int-area@ietfa.amsl.com>; Fri, 6 Sep 2019 11:21:08 -0700 (PDT)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 CAE4B120046 for <int-area@ietf.org>; Fri, 6 Sep 2019 11:21:07 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id c19so7073896edy.10 for <int-area@ietf.org>; Fri, 06 Sep 2019 11:21:07 -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:content-transfer-encoding; bh=Hi1hVtGRYbfS79RfhbCLlk2kmtSdalBv/oyeC6S0v48=; b=K+9UiaUI1z6C0sNQ4bt4s2jpHDijjplJ7Feeh07Nk/jpMrVAML6R/3NaOFop7Mbf1D ycUSihlsml1BS0i+McZ38S2w9otagYxEwsek9UlpXFf2GeYd3IyGIkCxJ8anAb8bi/xB iXnlt8PIj4SEHl3jxZovpRuHqqthx7BN1QlHi6bj8IQBOJ4muDfhXtAaWsBvk/Y3hAPQ geSo2ETOnEmcsEhhxir8l/hBWMq7y8QxBlYnaXXX15QJFSF7fo+t9zh2BD6GK7EbZAUp fXViOpkjwMcpVP6ZUlvc77EfB+G7gFbgLSAiznS01GT7noPtCw1pN8deu0Yrbe5Dwbxv zjoQ==
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:content-transfer-encoding; bh=Hi1hVtGRYbfS79RfhbCLlk2kmtSdalBv/oyeC6S0v48=; b=VnGO180sUAmFTQDaR+pAln94tmvinzTnHO6JVI7dbdVclQLU4BqCaDrdUkV0nNyK/e XH9J/hLfFlcpI7DBCePwtMU6m4Hex0F6RXRQUdiZRA++brBwUUtZgknDRSbVy6eh9Ll5 jTfLJKAJ9Pjh4L2wgL4Ewth+xeORIC9fyg+b1oSWZ+BfCDQx7FdOmVqMa/jmBLCQLuoB JFHpciMblMkqevX5QVVQHOd9+fRdin7EPTBDTgqR2WLen+DQ+0WxQ4mZCYlmOfYx0zzO a6BpB4b3gqEDSP7242HwjNPVIia97lY/ZtA75s/TBhevskakcpou5mSezMbIkoLD9c9U dqrQ==
X-Gm-Message-State: APjAAAU6hSXFpvRNwpZEJINYyJlPEMn+SykSNP1iJtRV4pqvdhxuA3Ye zPDQVNkntmSNEkQP4dzdjxsbN79znzSdfL8Sgi2/2w==
X-Google-Smtp-Source: APXvYqzrIRJAKm8IxCHSfc90NYzboc8Y4Dhb7I0/Xffs9GlYz4mORKeYXWusYt9yHvxgIXDRaLdP+0IPPHPmEIh9P3s=
X-Received: by 2002:aa7:d694:: with SMTP id d20mr3963877edr.226.1567794066241; Fri, 06 Sep 2019 11:21:06 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <163CD364-2975-467A-8925-F114FFD9C422@employees.org>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 6 Sep 2019 11:20:54 -0700
Message-ID: <CALx6S37yqj=7LBxPTgE9Vz9P_eAvhfoj7csNn6cz1Wn0YXycQQ@mail.gmail.com>
To: Ole Troan <otroan@employees.org>
Cc: Bob Hinden <bob.hinden@gmail.com>, 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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/JtvjIUdl8OCl3YUMkjGy6qgG3g4>
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 18:21:11 -0000

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.
Without the data that shows otherwise, I don't believe there is any
basis to say that encapsulation is generally a viable alternative.
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.

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