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

Tom Herbert <tom@herbertland.com> Fri, 06 September 2019 15:24 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 2DE54120CFE for <int-area@ietfa.amsl.com>; Fri, 6 Sep 2019 08:24:59 -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 B0T-h5eUeIjb for <int-area@ietfa.amsl.com>; Fri, 6 Sep 2019 08:24:55 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 0D54C120CF1 for <int-area@ietf.org>; Fri, 6 Sep 2019 08:24:55 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id o9so6695443edq.0 for <int-area@ietf.org>; Fri, 06 Sep 2019 08:24:54 -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=Z6/J64JwD9c3Q7kh7VX0p8aEICshlqtGOiUW3vk32GU=; b=TYZNLPEken7Zj1zQdd1DNX1f6V+iVyorkvZBPmlNZdzM/1V3WzsWEDduWMplQ7CkSl rCU/ymsI1RVoOZCyVaqDHG5eh05zsopddW94aWv7a+f1id6SFGtY5uV51iK9kC9LGj1t W5unCWnt92A4MZ8q/7CodvYoulEZiOXwSzTHgKLe7tC9PLHo3IGAL1CpYzJ5pUhC5Ki9 1otsY3eJ7JLVfJg1+4dBycfsCwo5hhIr2XkL1gZzSlKw3hB6j3loFFGXPCUMSbgoSOC0 ZsWunBbC7OoNMqz0Wup+CaAcd7VyhjYrhnOvR2u1oS8xEIoTtr9FzfLiQ/p2a6QNQfqb l68g==
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=Z6/J64JwD9c3Q7kh7VX0p8aEICshlqtGOiUW3vk32GU=; b=XNyp7yNyaRzZWve2a/YDSeREIygJ6eBO4lIw+QBUilOvIOj1qvVCiElaA3rk5zmy1S dNYcqcWu1ADIgJuh5tgiq6T195MdxMTN90UNcGoZNSIKXj1VZ11EqR7mLoIS+4Goym3/ CaS5aEDUYDtmoRNQQ1ivz+9fw7SBfdhqEpNKQ9llDNH2BBreiIDsxLGh0ahGZpQELxIV Gh8GnSi37bzjWlCtU8ZDUIMYyA7v9ONfcHnCobQJgHtEXtLVB7s7sn9akonuohlWi1XH naEnasoG1dzM0sUUHh18fz17zwqbAgJ8m5lZJTWapETWryGpbv6q7ezOr2A650LKp8z3 pp/g==
X-Gm-Message-State: APjAAAUddGsmUdAkPJvSSMsm8XJG8hm/PY4ZZkRiuh5lSCGCQYPP67Pt Eql0XJutiE8eeKJKxerVgil5kJnXpG34Dk/rdZLkKQ==
X-Google-Smtp-Source: APXvYqyWIuCfSpXuQY7GZVk1udizqbzp6iNe+jOsJZjIzB8Qs0VuKZIOfVvtPU/gy0sAR5yEODXBmw7ZdPfjocQCo6o=
X-Received: by 2002:a17:906:6792:: with SMTP id q18mr7942453ejp.80.1567783493372; Fri, 06 Sep 2019 08:24:53 -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>
In-Reply-To: <E770BEF0-D901-4CD0-96E6-C626B560DCD6@gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 6 Sep 2019 08:24:39 -0700
Message-ID: <CALx6S34r_e_yD=SRrFOaid2R_NNAf+DVqQEC_Wp=X4YvWkCBWw@mail.gmail.com>
To: Bob Hinden <bob.hinden@gmail.com>
Cc: "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-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/g7KjYwwkbl_uGYMzkOeQyuaVVxQ>
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:24:59 -0000

On Thu, Sep 5, 2019 at 9:05 PM 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.
>
Bob,

Per the statement "It is not recommended that new protocols or
applications be developed that rely on IP fragmentation." I believe
this advice will have little if any impact on applications developers.

Consider that thousands of UDP applications are developed each year.
The vast majority of these are not presented in IETF, and conversely
most application developers don't participate in IETF and many
probably have never even read an RFC. Not everyone is going to get the
memo. Another problem is that this is a layering violation. A
fundamental design point of fragmentation is that it's a networking
layer function that is supposed to be transparent to the application.
The application is not required to care rather it's packets are
fragmented. I expect that the vast of UDP applications written don't
pay any heed whatsoever to fragmentation, as long as their application
is working to their satisfaction they don't care rather their packets
are being fragmented (i.e. they wrote the application for their own
purposes in their specific environment). That is protocols and
implementation working by design.

Conceivably, the host stack itself could modified to advise
applications that their packets are being fragmented and they might
want to reconsider. While host stacks already take several actions to
mitigate known problems related fragmentation (like transmitting first
fragment first and otherwise in order, ensuring flow label is
consistent set for both fragments and non-fragments, various security
and DOS mitigations), I don't believe it is reasonable to ask the host
stack to do anything to enforce the recommendation that new
applications don't rely on fragmentation-- fundamentally,
fragmentation being fragile is a problem in network devices, it's not
the obligation of host stack to "fix" their problems. If a packet is
sent and it's length exceeds MTU, or path MTU, and DONT_FRAGMENT is
not set, then the packet _will_ be fragmented. That's the way it works
today, and the way it will continue to work.

So regardless of what this draft says, there will be new applications
that rely on fragmentation for the foreseeable future (this is why the
previous text was appropriate). Grant it, the recommendation is not
normative, so I suppose that's already a statement on its expected
relevance. My real concern with this recommendation is that middlebox
developers, who do participate in IETF and do read RFCs, might
interpret this to mean that new applications won't be relying on
fragmentation and therefore they assume they don't need to fix bugs or
continue support, thereby making support for fragmentation even worse
than it currently is.

Tom





>    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