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

[Tom Herbert <[e-mail]>]

On Mon, Nov 26, 2018 at 9:32 AM Gorry Fairhurst <[e-mail]> wrote:
>
> On 26/11/2018, 16:28, Tom Herbert wrote:
> > Hi, here's a few comments on the latest draft.
> >
> > > From the introduction:
> >
> > "These benefits have been widely discussed [RFC7258], [RFC7624], and
> > them. There are also, however, some costs, in that the wide use of
> > this document strongly supports the increased use of encryption in
> > transport encryption requires changes to network operations, and
> > transport protocols."
> >
> > I am not exactly sure what this means, but if this saying that the
> > document strongly supports increased use of transport header
> > encryption can transport header encryption be a RECOMMENDED
> > requirement.
> The document doesn't use RFC2119 language, and the goal is not to
> make best current practice recommendations - its infromation to capture
> what we know.
> > > From the draft:
> >
> > "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])."
> >
> > The two referenced RFCs are hardly recent (1991, 2000). Is there
> > something more recent that describes how the transport community is
> > "heavily" relying on transport layer measurements from the networking
> > community?
> > I'd point out that we've made substantial changes to TCP
> > like ICWD=10, TFO, and BBR without needing input about the transport
> > layer from network operators. Host endpoints have the necessary
> > statistics and measurements to develop and validate such features. It
> > seems the only time we needed to specifically consider the network was
> > when packets for new transport layer features are blocked (like in the
> > case of TFO when SYN packets with data were being dropped).
> Excellent point about BBR and TFO - there were indeed many many
> presentations and many papers about  the protocol developments used by
> TFO. BBR is evolving. Recently BBR within TCP has been subject to quite
> a bit of analysis by people other than the authors. Hopefully there will
> also be analysis of how this interacts with AQM, etc. It's a bit hard to
> get third-party analysis of the use within QUIC. There's been some
> analysis of how BBR interacts with policiers and other-in network
> management (but I'm not sure how up to date this is). Is it safe for use
> in the general Internet? - I'll punt that question to ICCRG, where
> doubtless there will be more analysis to come.
> > > From the draft:
> >
> > "transport designers have often ignored the implications of whether
> > the protocol designers have often ignored the implications of whether
> > the information in transport header fields can or will be used by in-
> > information in transport header fields can or will be used by in-
> > network devices"
> >
> > Actually, I believe the the opposite is true. Host developers and
> > protocol designers are very much aware of the implications of
> > intermediate devices consuming transport layer information. This is
> > not because we're trying to help the network mechanisms, it's because
> > we need to work around protocol ossification caused by non-conformant
> > devices in order to maximize the chances of packet delivery.
>
> The chances of a strandard TCP segment being delivered are still often
> higher than that of a new protocol using UDP. There are types of network
> where you will find performance is quite different - and can be better
> for TCP (see this IETF's proceedings), and places such as from within an
> enterprise (or some other controlled environment) where you may still be
> unable to use UDP without some form of proxy. This may be why QUIC is
> often seen as falling back to TCP.
>
> To me, none of this is important to understanding why currently some
> network operators have and continue to use information from transport
> headers to help operate their service.

Gorry,

Understanding that is relevant only if a list of requirements can be
derived as to what transport layer information needs to be exposed to
the network and what the correct mechanism is to expose such
information.

Tom

>
> Gorry
> > Tom
> >
> > On Sun, Nov 25, 2018 at 11:46 AM<[e-mail]>  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           : The Impact of Transport Header Confidentiality on Network Operation and Evolution of the Internet
> >>          Authors         : Godred Fairhurst
> >>                            Colin Perkins
> >>          Filename        : draft-ietf-tsvwg-transport-encrypt-03.txt
> >>          Pages           : 41
> >>          Date            : 2018-11-25
> >>
> >> Abstract:
> >>     This document describes implications of applying end-to-end
> >>     encryption at the transport layer.  It identifies in-network uses of
> >>     transport layer header information.  It then reviews the implications
> >>     of developing end-to-end transport protocols that use authentication
> >>     to protect the integrity of transport information or encryption to
> >>     provide confidentiality of the transport protocol header and expected
> >>     implications of transport protocol design and network operation.
> >>     Since transport measurement and analysis of the impact of network
> >>     characteristics have been important to the design of current
> >>     transport protocols, it also considers the impact on transport and
> >>     application evolution.
> >>
> >>
> >> 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-03
> >> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-transport-encrypt-03
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-transport-encrypt-03
> >>
> >>
> >> 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/
> >>
>