Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14

Tom Herbert <tom@herbertland.com> Tue, 07 April 2020 19:35 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC763A0FEB for <tsvwg@ietfa.amsl.com>; Tue, 7 Apr 2020 12:35:50 -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, SPF_HELO_NONE=0.001, SPF_NONE=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=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 nAn4LChtp8G3 for <tsvwg@ietfa.amsl.com>; Tue, 7 Apr 2020 12:35:49 -0700 (PDT)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 00E893A087C for <tsvwg@ietf.org>; Tue, 7 Apr 2020 12:35:48 -0700 (PDT)
Received: by mail-ed1-x52d.google.com with SMTP id z65so5595135ede.0 for <tsvwg@ietf.org>; Tue, 07 Apr 2020 12:35:48 -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=uguPSGpghSxNkyWWItkZfm7v7pZ/UBMLnhsgExMMLt0=; b=r2vvZOsnBn1dALFbG59BTVTXtanu6sB4ar0hQD42JrbtF2hqN0Crf0jZ6XF7bW2pzV 7pYBJSO/gMFL5WqPVAy1hlx279mPhoaoMR+c0gBjIqp4KEowgUn+0di8elQv0Pga0cpt 5engLYNldJaiUkiyZII449cQvWgLqRVBbGD2+oa5axDFHOIr6yow5aUeJ4zGfTopf4nM uL21wl6achCsg5MxuHz+3CMDwSzl3EgS0XU/eiSRW3ZAoZY3KgHKn99tArNwByvj3UpM Hw8xnE73+ObSi3GEuuSuGwfOB98zLUsGYuI+g1bGRkK23tGQP/0ur248XGn8IEn3rmRe 9gVQ==
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=uguPSGpghSxNkyWWItkZfm7v7pZ/UBMLnhsgExMMLt0=; b=G0QrXmScrTqY1EnuhGwtz5Se7YaqWfdabbB3LyJi2PDa48EAd1KV+UJ84yrKUdCk+6 4daz/aQZItoinB05izr3eXD5Dk6weIwIN8PTgLXhkDTLUdIzh4RJg4IvtOyTqJw+Lp1G wNbQm2FMQp7abnJ71mzuiGwpr0F9n2FDy34vSeg2/ebE+FrqukWZPlwZMbYN1133Rc4V X8MKe61isylXrMNtko1owk+ghSCkalHXKzvany/8EKqG7ySahUI6irjLuVtWp73lSMEU ab4Zxv+K5aItox3nepsU/FAPqKsllo4nF1i4kyUQAld+ze66SI5LjQhkbaXHd0mvTjwQ Xn0g==
X-Gm-Message-State: AGi0PuZdGskFqweMClMKsyZBVoBU2WmSeEELLjLEXiCJ+8aEKsCUL23R bDcBOjigHZsNFy+4e6NFvTaHJiYooTcLwIVTIRti0g==
X-Google-Smtp-Source: APiQypL5Bj5lIuuFkcj8pvi0LQngx5ksP+8NgbCbfptAICyJfvDQat0CcbAe56IHo/CoJ0yrBOUuru2FjJ1UWuMaag0=
X-Received: by 2002:a05:6402:1a27:: with SMTP id be7mr3280705edb.241.1586288147097; Tue, 07 Apr 2020 12:35:47 -0700 (PDT)
MIME-Version: 1.0
References: <CALx6S345Ta5LjSkZ+XmNmH8dxKnM++VRCej2iGxfdUqDc+M-Jw@mail.gmail.com> <MN2PR19MB4045E873D0908044343F8C2283C40@MN2PR19MB4045.namprd19.prod.outlook.com> <42914e6a-5602-7911-7447-e400d36eb0e6@erg.abdn.ac.uk> <MN2PR19MB404585DB4796DD1EF29FDF0C83C50@MN2PR19MB4045.namprd19.prod.outlook.com> <6CC67993-37FF-4B02-A45A-4F30E9D6686C@strayalpha.com> <fc94ff59-4972-3960-7c25-85f8953463f9@erg.abdn.ac.uk> <62B8E2A9-2347-44E2-8B14-DD3CD81937AB@strayalpha.com> <737cf948-065b-0702-ca15-6cc216d73bc9@erg.abdn.ac.uk> <10E067D5-0C17-400B-BA7F-3CB49C2C94B6@strayalpha.com> <CALx6S36_HGekVYSBTiP-=uDigk+nzf2Yw2AtqopPrK5Y1gozgQ@mail.gmail.com> <2856BD08-BFCD-476D-AD1E-FE1EA94C92C7@strayalpha.com> <CALx6S34vazUp+ttxqqJ2S6U_uN8oRNt-MATdGgKvbLRFz=BLsA@mail.gmail.com> <7CC3D01B-8E86-4898-BED4-A93149D13666@strayalpha.com> <MN2PR19MB404509A876B1A187755202AD83C30@MN2PR19MB4045.namprd19.prod.outlook.com> <CALx6S34B9+0OgSJnqazqK5K1BWAA-oXHPCn8C0PkQwa0O0RJng@mail.gmail.com> <a87dce81-e40a-d283-fedb-be142111cf8e@erg.abdn.ac.uk>
In-Reply-To: <a87dce81-e40a-d283-fedb-be142111cf8e@erg.abdn.ac.uk>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 7 Apr 2020 12:35:35 -0700
Message-ID: <CALx6S353SYsWLQV45aud+H4M597SOf2=FrqMG7r0HrXchJ1AeA@mail.gmail.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: "Black, David" <David.Black@dell.com>, Joseph Touch <touch@strayalpha.com>, tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/tGGaPe4DssS91qo6VLeUA2y7eRY>
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Apr 2020 19:35:51 -0000

On Tue, Apr 7, 2020 at 12:09 PM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
>
>
> On 07/04/2020 19:11, Tom Herbert wrote:
> > On Tue, Apr 7, 2020 at 9:20 AM Black, David <David.Black@dell.com> wrote:
> >>>> Also, a corollary should be the hard requirement:
> >>>> "Intermediate nodes MUST NOT ever modify transport payload”.
> >>
> >>
> >>> As a general principle, yes - agreed. There’s always the caveat that it’s always OK
> >>> *with the consent of the endpoints*, e.g., if an enterprise wants to set up the
> >>> network that way for their users. But in the arbitrary “middle” of the network, it
> >>> *should* IMO always be MUST NOT.
> >>
> >>
> >> As a general requirement, that’s fine, but it should be stated somewhere other than in this draft, e.g., as this draft is intended to become an Informational RFC.
> >>
> > David,
> >
> > Changing transport layer header, e.g. for traffic flow optimization
> > such as those devices doing receive window modulation, might also be
> > another use of transport header information that could be included in
> > section 2.1. Currently, the draft only seems to consider uses based on
> > passive observation of transport headers.
>
> Yes, that was the intention to talk about using the information, not
> changing the header.  WE don't discuss methods that modify the transport
> header, some ACK-modification methods, Window Modulation,
> proxy-intercept, PEPs, etc, which can't work if you authenticate the
> headers. We therefore were didn't see the need to call-out methods that
> require changes to the transport header. There are other docs that take
> a  look at a much broader swathe of mechanisms. If you want to read more
> about those, see RFC 8404.

Gorry,

I think it's apropos discussion to this draft, especially if the
recommendation is for protocol designers to selectively choose which
fields to make visible, whereby making something "visible" to the
network might not only mean that intermediate devices can read the
data, but they may write it as well.

Tom

>
> Gorry
>
> > Tom
> >
> >>
> >> Thanks, --David (as draft shepherd)
> >>
> >>
> >>
> >> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Joseph Touch
> >> Sent: Tuesday, April 7, 2020 11:43 AM
> >> To: Tom Herbert
> >> Cc: Gorry Fairhurst; tsvwg
> >> Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14
> >>
> >>
> >>
> >> [EXTERNAL EMAIL]
> >>
> >>
> >>
> >>
> >>
> >> On Apr 7, 2020, at 8:34 AM, Tom Herbert <tom@herbertland.com> wrote:
> >>
> >>
> >>
> >> On Tue, Apr 7, 2020 at 8:12 AM Joseph Touch <touch@strayalpha.com> wrote:
> >>
> >>
> >> Hi, Tom,
> >>
> >>
> >> On Apr 7, 2020, at 7:40 AM, Tom Herbert <tom@herbertland.com> wrote:
> >>
> >> On Mon, Apr 6, 2020 at 6:42 PM Joseph Touch <touch@strayalpha.com> wrote:
> >>
> >>
> >> Hi, Gorry,
> >>
> >> I’d suggest as follows (just to follow through on the changes):
> >>
> >>
> >> In some uses, an assigned transport port (e.g., 0..49151) can identify the protocol [RFC7605]. However, port information alone is not sufficient to guarantee identification. Applications can use arbitrary ports and do not need to use assigned port numbers. The use of an assigned port number is also not limited to the protocol for which the port is intended.
> >>
> >>
> >> Joe,
> >>
> >> RFC7605 acknowledges that port numbers are used to identify the
> >> application protocol, but clearly doesn't condone the practice. I
> >> suggest the text should just paraphrase RFC7605:’
> >>
> >>
> >> I don’t quite understand the above, esp. the use of “condone”. Port numbers are assigned *exactly* for endpoints to identify application protocols *in the absence of any other more explicit coordination* (the draft doesn’t say it so directly, but that’s the summary).
> >>
> >> Joe,
> >>
> >> I meant by using port numbers at intermediate nodes for identifying
> >> application protocols.
> >>
> >>
> >>
> >> Oh, sorry. I didn’t get that from the text, but agreed.
> >>
> >>
> >>
> >> For example, QUIC is assigned UDP port number
> >> 80 and the spinbit was created to be visible and processed by
> >> intermediate nodes. The only generic way intermediate nodes can
> >> identify QUIC is by matching the assigned UDP port number. RFC7605
> >> says that such matching may not be correct, so consideration needs to
> >> be taken what happens if things are misinterpreted (IIRC, processing
> >> of spinbit for a packet misinterpreted as being QUIC is considered
> >> innocuous).
> >>
> >>
> >>
> >> Agreed.
> >>
> >>
> >>
> >> Also, a corollary should be the hard requirement: "Intermediate nodes
> >> MUST NOT ever modify transport payload”.
> >>
> >>
> >>
> >> As a general principle, yes - agreed. There’s always the caveat that it’s always OK *with the consent of the endpoints*, e.g., if an enterprise wants to set up the network that way for their users. But in the arbitrary “middle” of the network, it *should* IMO always be MUST NOT.
> >>
> >>
> >>
> >> I don't believe this draft
> >> mentions the fact that some intermediate nodes modify unencrypted
> >> transport layer headers in flight, but this does happen. For instance,
> >> there are devices that will modify the TCP receive window to optimize
> >> traffic flow (I believe there are some routers for satellite links
> >> that do this).
> >>
> >>
> >>
> >> Yes, and they then complain that mechanisms like IPsec “interfere” with that “feature”. Some of what they do might be relatively innocuous, but some - esp. forging ACKs to reduce endpoint-perceived RTT - runs a significant risk of undermining TCP semantics of reliable delivery.
> >>
> >>
> >>
> >> If this technique were applied to QUIC where the
> >> network modified some "exposed" fields in the QUIC header then this
> >> would risk systematic data corruption for UDP packets misinterpreted
> >> as QUIC (putting the transport layer in a modifiable HBH option would
> >> not have this problem).
> >>
> >> Tom
> >>
> >>
> >>
> >> That said, I was OK with the resolved text I had suggested, with or without the text below - which is also fine.
> >>
> >> Joe
> >>
> >>
> >>
> >> "Port numbers are sometimes used by intermediate devices on a network
> >> path to interpret transport protocol payload, however any
> >> interpretation of port numbers -- except at the endpoints -- may be
> >> incorrect, because port numbers are
> >> meaningful only at the endpoints [RFC7605]."
> >>
> >> Tom
> >>
> >>
> >>
> >>
> >> Joe
> >>
> >>