Re: [saag] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

Ian Swett <ianswett@google.com> Sun, 24 November 2019 01:48 UTC

Return-Path: <ianswett@google.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E60120045 for <saag@ietfa.amsl.com>; Sat, 23 Nov 2019 17:48:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 eGrJoEtdLR-O for <saag@ietfa.amsl.com>; Sat, 23 Nov 2019 17:48:32 -0800 (PST)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 CE5FD120073 for <saag@ietf.org>; Sat, 23 Nov 2019 17:48:31 -0800 (PST)
Received: by mail-vs1-xe2f.google.com with SMTP id i13so2720461vso.13 for <saag@ietf.org>; Sat, 23 Nov 2019 17:48:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bOR6UovPst7G2nTFYlF/FvrqxJCHgfoBtmK4NOKgzWs=; b=NHDNX6FNyzF87nn6YywhLlL+2VWrvb3IUG6HYll4JvSwLQcYKg0d2NT2knmwqP34UT P3DoGvFTfWQLwmNYP80G9Qyqq2gIHC/72NfrwzDXZoOfFRagqqStp/HWWi6UwOVVc5Ld 0UElOEIz4XPjpuGRl+8M65hW+bp/hPJSy3ALLUhEfba9ueSM/08m7hAtsf1/SHHo9Ej7 sJ3tk4HxIrE1nAI+1CFzsM4/as3sZrpn7K9F/Jfmx5P/3I5tk2oLlRCOUPgAYW6/bB1B PnQ1m8/Ltc/3uhvcUfvPdtT2uxAJp1RKodFGJ9P8J16471mxw+feFwNgql03u40GXVOO tRPQ==
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; bh=bOR6UovPst7G2nTFYlF/FvrqxJCHgfoBtmK4NOKgzWs=; b=h2ONH4V7CDwR6vXCU+WHdOBB5NGnb0pwsd0LUR4I9jMkgUcvgWnMgKdxPDXVeOrC3h f7JIy5fY3o+RsUJvpljN82dPxLyVkK5inACK+cXkm2SpRrAk9zTeaw3V9fRDiHFpPzBk tmhNS8qOcgGYHDlkVbIlzwwOrnUQPGCUqkfqF+kri1shEml1291LLKsdz6bDmJx3fQGT yT5ARF8gdn07gMXNoGmVx5V/LLcC6eOFmNFKZ+G9oxoxfDmW/X+ukdrFHGR3KDTv5K3r v8/5liP3FG+jd87DFBEHlw5TU+7zvLxBt8GG019KegMdzumwzpaaQZpCpfvz3cKx4UpA wFzg==
X-Gm-Message-State: APjAAAXd9T7Y7dkiRoSgYMEQo7Kf3dSP1xQoGPoRa1UKDbvYxkKAIocV ZXhwG1wTmD2GeLcbNSRHQ278tqKzzHCvqfqkZBIhPA==
X-Google-Smtp-Source: APXvYqxvLW0PLf/sKrZNLuLeJU/D8CBoPmVlWHCNElECLku/2qKzAyRXjmPFGjZwxfEFny9bI0gOaXMl/skruv93KmI=
X-Received: by 2002:a67:e417:: with SMTP id d23mr4093118vsf.208.1574560109944; Sat, 23 Nov 2019 17:48:29 -0800 (PST)
MIME-Version: 1.0
References: <CE03DB3D7B45C245BCA0D2432779493630766752@MX307CL04.corp.emc.com> <4460_1571933453_5DB1CD0D_4460_57_4_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0@OPEXCAUBM44.corporate.adroot.infra.ftgroup> <1572918247420.10381@cs.auckland.ac.nz> <CABcZeBPy_39o37snzy8F6iyLQMg1aGkYbhy0A1N-PxFUmAmB0g@mail.gmail.com> <f2b1f803-b559-a166-8009-baff551bec5c@joelhalpern.com> <5df30dd2-6841-7140-43bf-8c1b9603653f@erg.abdn.ac.uk>
In-Reply-To: <5df30dd2-6841-7140-43bf-8c1b9603653f@erg.abdn.ac.uk>
From: Ian Swett <ianswett@google.com>
Date: Sat, 23 Nov 2019 20:48:17 -0500
Message-ID: <CAKcm_gM33z6njR1U5f8Lh3=cMzEnQQVWLVYui9zHHqz0kPc2Nw@mail.gmail.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "IETF IPPM WG (ippm@ietf.org)" <ippm@ietf.org>, tsvwg-chairs <tsvwg-chairs@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>, "quic@ietf.org" <quic@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000008409405980dd87a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/xInoDiKoIsRTRp_EDKlh-T9PLoc>
Subject: Re: [saag] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Nov 2019 01:48:35 -0000

I think it's ok to publish a document with the stated goals, but I think
this needs to be done with great care and the current document implies some
value judgements and implications I don't think are fully justified by the
document.  A 3rd author with a slightly different perspective may help
achieve the right balance.

In section 2, I believe you should note that the reason transport headers
have been exposed in the past is largely an accident, and what is exposed
may not be optimal for network monitoring and management purposes.  For
example, TCPs ACKs are a suboptimal way to measure network RTT unless
timestamps are available. And tracking losses requires substantial state
and assumptions about the loss detection algorithm on the part of the
observer.

The section(2.1) on transport ossification and middleboxes is well done,
thanks!


*Detailed points: *

2: Context and Rationale
 "To achieve stable Internet operations, the IETF transport community
   has to date relied heavily on the results of measurements and the
   insights of the network operations.."

The use of 'stable' here implies that without these measurements the
internet would be unstable.  I understand what you're trying to say, but
this needs a reword to avoid the implied collapse of the internet.  I'd
suggest you remove the word stable from this document, as it occurs 2 other
times in similar context.

2.3

I think this section is too vague.  The phrase "can be used" is used
frequently, but without a clear understanding of what the transport headers
are used for.  After reading further, some of this is defined in section
3.1.2, so maybe a forward reference is in order.

3.1.2:

"Throughput and Goodput" - Throughput seems to overlap with "Traffic Rate
and Volume".   I'd suggest reorganizing these into two items, one for
Goodput and one for Throughput/Traffic Rate/etc.

6.5:

"Concealing transport header..." Do you mean encrypting, or is there some
other method you have in mind?  This word is used 9 times in the document
and I don't think it's a good word choice.

7:

 "To achieve stable Internet operations, the IETF transport community
   has, to date, relied heavily on measurement and insights of the
   network operations community to understand the trade-offs, and to
   inform selection of appropriate mechanisms, to ensure a safe,
   reliable, and robust Internet (e.g., [RFC1273],[RFC2914])."

I don't believe RFC2914 should be grouped with RFC1273.  2914 is about
principles, and 1273 is about measurement.  Based on my reading, 2914 does
not provide evidence that measurement is necessary in order to achieve the
desired principles.

Also, one of these RFCs is almost 20 years old and the other is almost 30.
I don't think these are good support for the thesis that network operators
measurement abilities have been critical to what you're claiming, even if
it is still true today.

Thanks, Ian


On Tue, Nov 5, 2019 at 5:27 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk>; wrote:

> Thanks for the various comments on process.
>
> I expect both editors and the Chairs to work with our AD to confirm the
> intended scope, and then to decide on the next steps. This author wants
> to clarify how IETF transport protocols have been designed and have
> been/are being used.
>
> Gorry (as one of the editors of this document).
>
>
> On 05/11/2019 02:39, Joel M. Halpern wrote:
> > If the authors want to publish it as an RFC so as to comment on other
> > RFCs, they could approach the Independent Stream Editor.  That sort of
> > publication is one of the explicit purposes of the Independent Stream.
> >
> > Yours,
> > Joel
> >
> > On 11/4/2019 9:34 PM, Eric Rescorla wrote:
> >>
> >>
> >> On Mon, Nov 4, 2019 at 5:44 PM Peter Gutmann
> >> <pgut001@cs.auckland.ac.nz <mailto:pgut001@cs.auckland.ac.nz>> wrote:
> >>
> >>     I actually think it's a pretty good summary, and delivers exactly
> >> what's
> >>     promised in the title.  OTOH I can also see that it's going to get
> >>     bikeshedded
> >>     to death, and will probably never be editable into a form where
> >>     people won't
> >>     complain about it no matter how many changes are made.
> >> Alternatively, it'll
> >>     end up watered down to a point where no-one can complain any more
> >>     but it won't
> >>     say anything terribly useful by then.
> >>
> >>     Perhaps it could be published as is with a comment that it
> >>     represents the
> >>     opinions of the authors?  Although given that it's Informational
> >> and not
> >>     Standards-track or a BCP, that should be a given anyway.
> >>
> >>
> >> Actually, no. Most IETF documents, even informational ones, bear a
> >> statement that they have IETF Consensus.
> >>
> >> See: https://tools.ietf.org/html/rfc5741#section-3.2.1
> >> <https://tools.ietf.org/html/rfc5741#section-3..2.1>
> >>
> >> -Ekr
> >>
> >>
> >>     Peter.
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> OPSAWG mailing list
> >> OPSAWG@ietf.org
> >> https://www.ietf.org/mailman/listinfo/opsawg
> >>
>
>