Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-11.txt

Tom Herbert <tom@herbertland.com> Fri, 31 January 2020 19:10 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 D73AE120838 for <tsvwg@ietfa.amsl.com>; Fri, 31 Jan 2020 11:10:59 -0800 (PST)
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=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 iADch29xwGrW for <tsvwg@ietfa.amsl.com>; Fri, 31 Jan 2020 11:10:58 -0800 (PST)
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 B852D1200F6 for <tsvwg@ietf.org>; Fri, 31 Jan 2020 11:10:57 -0800 (PST)
Received: by mail-ed1-x52d.google.com with SMTP id f8so8970573edv.2 for <tsvwg@ietf.org>; Fri, 31 Jan 2020 11:10:57 -0800 (PST)
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; bh=oMWcp8yNY+59vf9VTop8gkiNcqxAtTMt9TlqanfzOhw=; b=vsIk9aqqjJZo1cSgefTuXzMZmdLrDogzyy6gdqI2PiphyB/smW5YheBK/pu0fe4ONf XxSHcN9P5Kgl4I2QlJRBj5X2XySmY90lqHWC/WgPHOJVK7hZY+k8xLokZpwQ3Zyuui9b mxUkj5Fo3XE0fOjPa3oBZh1HH4sA7vJ4UwoSBDyFr1MwDAvOUn2juWtNzM0QVwSKEg4n fAAPs4jGM6CEKgA3fdhMnVasfWdKtdelVrn1zlcpY/ENMEJUiAiex0qmfew94/Um4hUs d4w4waYiPdBtz9G4obvhCUiPP9K+H6CVw+nu0UOu9RtcO+QePqn40yf8GMbRI1bodune VYIQ==
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=oMWcp8yNY+59vf9VTop8gkiNcqxAtTMt9TlqanfzOhw=; b=rwidCkhQ9MJpa9bopHuTUTzAZk+p+KBmcKCPOrXvhKXPZbEFFcCJGA9yA2uNrquDs4 1XQhKJ9wftjjIJmWUrLQgsiKkCMWfUDUzuFoP4SIM/HN+DviZCjZS7YpIaGacUKtPExz GPIRRQSqgC/qB+r92klrpHQTAfJogsyWD+9fagR0VCaXdeBhwFp78CzdkdS+R+QjCDbd /6ALeaUBuEcbbi6uVkupTieyQVjnQtOzLwW/GEvxDwJl2htL4of0/FGQzpdMQLiPJ7ug 0i4mebrBsf9yGq4/lJVse9ZGwqo+3sOV/LDz5dpJMslqTHHC3ro9SkOK6yTvK0SlTVck kXVg==
X-Gm-Message-State: APjAAAVbq81tbUUpt1Sygrf9EyouwpT+VWzugWpl6C9FGgZxRwvymuaN SioMX64AN176gO+BqtUANYqteOjPDcPOeIHlB4AqkiPH
X-Google-Smtp-Source: APXvYqwfVkmaKm28cSPJVJxSacIlwtc9vB7VsrefFgl8HrIdjVHj1gUgJRHUNhkZNZJ0U1vynw1l97hNeGsmwieWfPg=
X-Received: by 2002:a05:6402:3132:: with SMTP id dd18mr1875824edb.118.1580497856142; Fri, 31 Jan 2020 11:10:56 -0800 (PST)
MIME-Version: 1.0
References: <158049570624.21112.7310029071899308381@ietfa.amsl.com> <CALx6S34jyNth7cK81A+jOdjnQjW1wFTs5qgHmO--T7MLAmKwaA@mail.gmail.com> <e31ecff2-7bf1-5912-8842-f32b3c711aa9@erg.abdn.ac.uk>
In-Reply-To: <e31ecff2-7bf1-5912-8842-f32b3c711aa9@erg.abdn.ac.uk>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 31 Jan 2020 11:10:43 -0800
Message-ID: <CALx6S37v0cBqd3imFzrj5=7-V-QEA1eJYdG-sNz4vYyr6ViwqQ@mail.gmail.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/TgDA2GSbAvqukD2XJ4M_O7Bd3is>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-11.txt
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: Fri, 31 Jan 2020 19:11:00 -0000

On Fri, Jan 31, 2020 at 10:56 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
>
>
> On 31/01/2020 18:48, Tom Herbert wrote:
> > One comment:
> >
> > >From the draft:
> >
> > "Observing the protocol sequence number pattern of network usage.
> > Measurements can be per endpoint or for and packet size offers one way
> > to meausre this (e.g., measurements an endpoint aggregate (e.g., to
> > assess subscriber usage). observing counters in periodic reports such
> > as RTCP"
> >
> > Misspelling measure.
> Ah - thanks for noting - we edited after spell-check, so we'll make sure
> to fix that.
> > Note that tracking sequence numbers in the
> > network, flow tracking general, typically presumes that all packets
> > for a flow take the same path and consistently traverse the node
> > tracking transport state information. There's no requirement in IP for
> > that to hold.
>
> True. I assume this appears as jitter or loss, but yes any view from the
> middle
>
> wouldn't know that other packets have taken a different path; and similarly
>
> wouldn't know whether any packets were later reodered/lost/etc after
>
> the measurement point. I'd expect people to understand this sort of thing.
>
Gorry,

A host can influence the path a packet takes in several ways. For
instance, one method is to modulate the flow label used for an IPv6
flow. We've implemented this in Linux where if we see a connection is
failing, i.e. multiple retransmits seen, it will change the flow label
used for the flow in hopes of finding a better path by ECMP. This
causes problems if the network maintains state for flows and when a
different path is taken no state is encountered (for instances packet,
might just be dropped in case of a stateful firewall).

The problem is that not only does the sending host not know a priori
what transport information the network might need, it doesn't know
what the implicit requirements the network has assumed with regards to
how it uses the transport information (like requirement for consistent
routing through a stateful device).

Tom

> Gorry
>
> > Tom
> >
> > On Fri, Jan 31, 2020 at 10:35 AM <internet-drafts@ietf.org> wrote:
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >> This draft is a work item of the Transport Area Working Group WG of the IETF.
> >>
> >>          Title           : Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols
> >>          Authors         : Godred Fairhurst
> >>                            Colin Perkins
> >>          Filename        : draft-ietf-tsvwg-transport-encrypt-11.txt
> >>          Pages           : 48
> >>          Date            : 2020-01-31
> >>
> >> Abstract:
> >>     To protect user data and privacy, Internet transport protocols have
> >>     supported payload encryption and authentication for some time.  Such
> >>     encryption and authentication is now also starting to be applied to
> >>     the transport protocol headers.  This helps avoid transport protocol
> >>     ossification by middleboxes, while also protecting metadata about the
> >>     communication.  Current operational practice in some networks inspect
> >>     transport header information within the network, but this is no
> >>     longer possible when those transport headers are encrypted.  This
> >>     document discusses the possible impact when network traffic uses a
> >>     protocol with an encrypted transport header.  It suggests issues to
> >>     consider when designing new transport protocols, to account for
> >>     network operations, prevent network ossification, enable transport
> >>     evolution, and respect user privacy.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-tsvwg-transport-encrypt-11
> >> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-transport-encrypt-11
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-transport-encrypt-11
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>