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

Tom Herbert <tom@herbertland.com> Tue, 07 April 2020 15:34 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 E91D93A0CDA for <tsvwg@ietfa.amsl.com>; Tue, 7 Apr 2020 08:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, 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 ZtfQC6BJdcB5 for <tsvwg@ietfa.amsl.com>; Tue, 7 Apr 2020 08:34:48 -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 EB1EA3A0CC4 for <tsvwg@ietf.org>; Tue, 7 Apr 2020 08:34:47 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id e5so4589440edq.5 for <tsvwg@ietf.org>; Tue, 07 Apr 2020 08:34:47 -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=A+aXVfIH65K8sG4q+s05j0tp+Do14bFmiwebPUunsyc=; b=vXpB6SX6zxWFEEwo2z5oerzOsPcPYmq4eS1o2lrLwA7y0DvBYsCYuj9Zsip4u1ceGB mKDRMmFHQvfITsLPz4H9Aa1jx+xmDTDMJllfXxD5R2IFQcjb8LYGcYPGwDObhP624vKI Hsasyngqoa0jkPMd8Zsgxro7gkP2jyAfi5H42p5S/TEBLFG6BCgWvxrIEVRh/bKLJcwX fHYJiU8rxe8XghRvtcfyjWb51laHKjw1WetyHj+JAopxPxX2Y3HIZskc7bIhgDNMf4Y9 2jRIO5jtdirteRJ7IwEZWa83ibT7XEQ7T/FEJ0pwdZbLpBxk+34Tdx4JRtGzRCfNlbMp XxOw==
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=A+aXVfIH65K8sG4q+s05j0tp+Do14bFmiwebPUunsyc=; b=RM0yCwWD4nMvTeD+GBXRT+Q1DMP8qGmwNOUclP9DaiO5/YAqSMaY2cTQmifNMKqfC/ H4U5wrjb4fixCIv8hGlAmt4U2Lq1eXPJ7o2Qnr3mfhRE35Avh+La84xsIY418Myfud9/ gvftgutxoQlurO0uINhlDzsJ+RC/pZ46kf8QpUII45emW9vbPLvaeMh/31/aKJ+SvuEi c7N20OC4Dk57zLr4gtAAhbx4y/GaNHK6eEdj64P5vCVAGaHh51mYnqpe2UlHtj8XCHix RXFAhutKf3gMGNUwjEL2wJ7+TcYkY/PPQ8usqoob+9OXEjLz/iPr4WgTvALpFxNvMzJN yVjg==
X-Gm-Message-State: AGi0PubBVxXVFqXDGgwhXQJ19Bf7/IhDzPNNIq2CHhjDe6o4pHXBJhNj k1bsJ46CcfP9EeLiBtE5kVoVmyuCwTGMw/Cdxeoe3g==
X-Google-Smtp-Source: APiQypLFuy+q7DCU2vzv8dDeM+ctbQCeTP8VktJ5uF3ag2ON+U2O0KbncwmRkScrNGdzorgOZzb7xH8nJnVvVbaUl5Y=
X-Received: by 2002:a17:907:4334:: with SMTP id ni4mr2645313ejb.304.1586273686065; Tue, 07 Apr 2020 08:34:46 -0700 (PDT)
MIME-Version: 1.0
References: <CALx6S345Ta5LjSkZ+XmNmH8dxKnM++VRCej2iGxfdUqDc+M-Jw@mail.gmail.com> <MN2PR19MB4045652C80DB5348A5A3505F83C70@MN2PR19MB4045.namprd19.prod.outlook.com> <CALx6S36yzDTLaxUhWibZjmK5Cxu2zfzxiawFRCbVn9aPF4rs1A@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>
In-Reply-To: <2856BD08-BFCD-476D-AD1E-FE1EA94C92C7@strayalpha.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 07 Apr 2020 08:34:35 -0700
Message-ID: <CALx6S34vazUp+ttxqqJ2S6U_uN8oRNt-MATdGgKvbLRFz=BLsA@mail.gmail.com>
To: Joseph Touch <touch@strayalpha.com>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, 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/tH-GXLyxuURnVIzmvBr5Ncs83-Q>
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 15:34:50 -0000

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. 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).

Also, a corollary should be the hard requirement: "Intermediate nodes
MUST NOT ever modify transport payload". 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). 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
> >
>