Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-04.txt

From: [email-masked]
Date: Mon, 18 Feb 2019 12:37:44 -0800

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-04.txt
	Pages           : 43
	Date            : 2019-02-18

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-04
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-transport-encrypt-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-transport-encrypt-04

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/

---

From: Tom Herbert <[email-masked]>
Date: Tue, 19 Feb 2019 09:13:04 -0800

Hello,

I am still having a hard time believing that need for operators to
inspect and process transport layer information in ad hoc ways
remotely outweighs the need for users' security and privacy and to
impede protocol ossification. Regardless of the arguments in the
draft, I believe that the trend will be more use of encryption even in
the transport layer. Consequently, it would be nice if the draft had
more discussion about alternative means for network devices to get the
information about the transport layer that they need. In particular, I
still think possibility of using extension headers is far too easily
dismissed by the draft (please see my previous comments about that).

Tom

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 19 Feb 2019 17:40:44 +0000

On 19/02/2019, 17:13, Tom Herbert wrote:
> impede protocol ossification.
Whatever you c
> Regardless of the arguments in the
> the transport layer.
That certainly is the way it looks, to summarise the draft says:
"

    As seen, different transports use encryption to protect their header
    information to varying degrees.  There is, however, a trend towards
    increased protection with newer transport protocols.

"
> Consequently, it would be nice if the draft had
> information about the transport layer that they need.
Our guidance on scoping means that we can include deployed methods, are 
there examples that you can tell us about?
> In particular, I
I also think there may be potential here in future, and would love to 
see this area explored - it is a topic in which I have research, and I 
believe you also. I can't however point yet to deployment examples in 
this area. Do you know more?

Gorry
> Tom
>
> On Mon, Feb 18, 2019 at 12:38 PM<[email-masked]>  wrote:
>>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 19 Feb 2019 10:10:01 -0800

> there examples that you can tell us about?

Extension headers are one. I know in some proprietary datacenter
networks (like Google) there are whole systems that collect per flow
statistics and state from host endpoints. Getting transport
information from an endpoint is FAR more robust and accurate than
trying to infer the same information from an extremely limited
viewpoint somewhere within the network.

> this area. Do you know more?

draft-hinden-6man-mtu-option, draft-ietf-ippm-ioam-data, draft-herbert-fast

More generally to the need for extension headers to work on the
Internet is demonstrated by segment routing.

Conversely, the draft floats the idea of purposely not encrypting
certain fields of a transport header for the purposes that
intermediate devices can parse them. What is the deployment experience
of that? What transport protocols been retrofitted that do that?

Thanks,
Tom

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 20 Feb 2019 05:16:33 +0000 (UTC)

> of that? What transport protocols been retrofitted that do that?

Examples include:

TLS encryption over unencrypted TCP - the outer TCP wrapper can
be tweaked by intermediate PEPs to advertise larger windows and
increase buffering for faster traversal of satellite links, and
IP address substitution can be done for proxying purposes.
This provides increased performance over e.g. QUIC, where this
transport control/payload content separation cannot be done.
Deployment experience of this is widespread. Really widespread.

The bundle protocol, where completely encrypting the bundle
means that custodial transfer and discarding of damaged
or truncated bundles could not be done well. This is discussed
in detail in A Bundle of Problems, IEEE Aerospace 2009 - see the
worked example in Fig. 1, which is basically analogous to
checking a bridged Ethernet CRC at each hop before forwarding.

The end-to-end principle says that checking reliability at the
endpoints is necessary, but that for increased performance
it may not be sufficient. Those are two examples of that.

Other examples would be unencrypted tunnel headers carrying
encrypted traffic, or the entire TCP/UDP pseudoheader or
SCTP checksum, where intermediate devices protecting a
constrained link will want to have some integrity check
on the entire contents before forwarding, but the Ethernet
frame may only be goo for the local link.

Lloyd Wood
http://lloydwood.users.sf.net/l/dtn

On Wednesday, 20 February 2019, 05:10:36 GMT+11, Tom Herbert <[email-masked]> wrote: 

Thanks,

Tom

---

From: Colin Perkins <[email-masked]>
Date: Wed, 20 Feb 2019 12:18:19 +0000

> On 19 Feb 2019, at 18:10, Tom Herbert <[email-masked]> wrote:
…
> of that? What transport protocols been retrofitted that do that?

Secure RTP is one example, where the payload is encrypted but the headers are left in the clear. One of the main motivations for that was to support hop-by-hop RTP/UDP/IP header compression, but it also allows middleboxes to monitor flow QoE.

-- 
Colin Perkins
https://csperkins.org/

---

From: <[email-masked]>
Date: Wed, 20 Feb 2019 12:51:50 +0000

I support Colin's view. Estimation of application QoE based on lower layer QoS measurements in general benefits from transport layer information. As an example, IP layer performance measurements are insufficient to estimate streaming QoE. QoE estimation based on TCP/TLS is challenging already.  As far as I can judge, the result is that QoE monitoring solutions which are based on applications running on consumer equipment are promoted. To gain representative data, the number of involved active receivers must be sufficiently high in any network section to be monitored. 

I welcome content encryption. I personally doubt that consumer security is improved by applications on consumer devices which "call home". To me, finding a reasonable balance between commodity network provider concerns like flow QoS based QoE estimation and encryption of contents would be helpful, if security is the concern.

Regards,

Ruediger 

-----Ursprüngliche Nachricht-----
Von: tsvwg <[email-masked]> Im Auftrag von Colin Perkins
Gesendet: Mittwoch, 20. Februar 2019 13:18
An: Tom Herbert <[email-masked]>
Cc: Gorry Fairhurst <[email-masked]>; tsvwg <[email-masked]>
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-04.txt

…

--
Colin Perkins
https://csperkins.org/

---

From: Tom Herbert <[email-masked]>
Date: Wed, 20 Feb 2019 07:33:44 -0800

> I support Colin's view. Estimation of application QoE based on lower layer QoS measurements in general benefits from transport layer information. As an example, IP layer performance measurements ar…

That reflects the myopic view of some network operators that TCP is
the only protocol you'll ever need. Or more specifically, that the
world is compose of simple TCP over IP packets without options. It
discounts the possibility of using SCTP, QUIC, DCCP, UDP applications,
etc. or at least the possiblility for using them with advanced network
services like measurement monitoring that need transport layer info.
Furthermore, a TCP packet that is encpasulated or encrypted in a
tunnel won't be visible to the network anyone, so that case doesn't
get the good service as well.

If QoE, receive window manipulation, timing packet in a flow, etc. is
important and potentially valuable to users then that's great. But
please, consider how to make these a generic protocol so that ALL
transport protocols, ALL use cases of TCP, and in the end ALL users
can take advantage of these features. The best answer is put the
necessary transport information in Hop-by-Hop or modifiable Hop-by-Hop
options. As an example, see
https://tools.ietf.org/html/draft-ioametal-ippm-6man-ioam-ipv6-options-01
which would provide in-situ OAM for IPv6 regardless of transport
protocol being carried.

Tom

---

From: <[email-masked]>
Date: Wed, 20 Feb 2019 16:07:14 +0000

I've been describing the general state of the art of QoE measurements based on network QoS parameters. I've been picking TCP as an example. The change from unencrypted TCP transport to TLS is a fair example how to increase the difficulties to judge QoE based on network QoS parameters. QUIC has been encrypted from start on.

Please briefly describe how to reliably determine per packet end-to-end RTT as could be done by TCP Ack screening replacing the latter by IOAM. I didn't follow IOAM closely. Is that generally possible by now or does it depend on options which have to be supported by equipment owned by different stakeholders?

Network QoS based QoE estimation us done for the mass market, if a network provider serves it. SCTP and tunnels and the like are corner case transport options. Further, I don't recollect that research cared too much about different TCP dialects.

I don't think the approach to have a single solution to monitor all transport options is feasible. It will likely be too generic to provide useful input if it works end-to-end or it will be too specific to work end-to-end in a majority of cases, I guess. It's also a little hard to understand why an extra overhead should to be attached to a packet if the same information could be exposed within existing packet headers. I'm not talking about breaking consumer privacy here. 

Regards,

Ruediger 

-----Ursprüngliche Nachricht-----
Von: Tom Herbert <[email-masked]> 
Gesendet: Mittwoch, 20. Februar 2019 16:34
An: Geib, Rüdiger <[email-masked]>
Cc: Gorry Fairhurst <[email-masked]>; tsvwg <[email-masked]>
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-04.txt

> I support Colin's view. Estimation of application QoE based on lower layer QoS measurements in general benefits from transport layer information. As an example, IP layer performance measurements ar…

That reflects the myopic view of some network operators that TCP is the only protocol you'll ever need. Or more specifically, that the world is compose of simple TCP over IP packets without options. It discounts the possibility of using SCTP, QUIC, DCCP, UDP applications, etc. or at least the possiblility for using them with advanced network services like measurement monitoring that need transport layer info.
Furthermore, a TCP packet that is encpasulated or encrypted in a tunnel won't be visible to the network anyone, so that case doesn't get the good service as well.

If QoE, receive window manipulation, timing packet in a flow, etc. is important and potentially valuable to users then that's great. But please, consider how to make these a generic protocol so that ALL transport protocols, ALL use cases of TCP, and in the end ALL users can take advantage of these features. The best answer is put the necessary transport information in Hop-by-Hop or modifiable Hop-by-Hop options. As an example, see
https://tools.ietf.org/html/draft-ioametal-ippm-6man-ioam-ipv6-options-01
which would provide in-situ OAM for IPv6 regardless of transport protocol being carried.

Tom

> Betreff: Re: [tsvwg] I-D Action: 
> draft-ietf-tsvwg-transport-encrypt-04.txt
>
> > intermediate devices can parse them. What is the deployment 
> > experience of that? What transport protocols been retrofitted that do that?
>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 20 Feb 2019 08:59:56 -0800

> I've been describing the general state of the art of QoE measurements based on network QoS parameters. I've been picking TCP as an example. The change from unencrypted TCP transport to TLS is a fai…
Okay, TCP was just an example. So if I'm using another protocol like
SCTP, QUIC, TCP in a tunnel then how do I get the same features and
network services like plain TCP/IP gets?

> Please briefly describe how to reliably determine per packet end-to-end RTT as could be done by TCP Ack screening replacing the latter by IOAM. I didn't follow IOAM closely. Is that generally possi…
Connection oriented protocols, like TCP and QUIC, track RTT per flow.
If this information is interesting to the network it can be provided
in HBH option. IOAM should carry a variant usable for RTT measurement.

> Network QoS based QoE estimation us done for the mass market, if a network provider serves it. SCTP and tunnels and the like are corner case transport options. Further, I don't recollect that resea…

I do not know what "corner case transport options" are. Can you please
define that term?

>
> I don't think the approach to have a single solution to monitor all transport options is feasible.

It's not the intent to expose all transport options. As an application
and transport protocol developer I am only willing to expose
information to the network in plaintext that is absolutely necessary
for viable communications, not one bit more than that. I have no
interest in exposing everything just on the off chance that some
random device in the network might find it useful. I may be willing to
provide specific pieces of information if I know how it will be used
and an who will use it. This is the reallly the only resonable
security model for my users.

> It will likely be too generic to provide useful input if it works end-to-end or it will be too specific to work end-to-end in a majority of cases, I guess. It's also a little hard to understand why an extra overhead should to be attached to a packet if the same information could be exposed within existing packet headers. I'm not talking about breaking consumer privacy here.

Again, by "existing packet headers" you are implying that plain TCP/IP
is the the only thing that exists and needs to be supported. If the
Internet is to move evolve, we need to get beyond this limited view.

Tom

---

From: Colin Perkins <[email-masked]>
Date: Wed, 20 Feb 2019 22:04:17 +0000

> On 20 Feb 2019, at 16:59, Tom Herbert <[email-masked]> wrote:
> 

The example I gave was a UDP-based transport protocol…

-- 
Colin Perkins
https://csperkins.org/

---

From: Tom Herbert <[email-masked]>
Date: Wed, 20 Feb 2019 14:31:50 -0800

> The example I gave was a UDP-based transport protocol…
Colin,

Right, but as you said "Secure RTP is one example, where the payload
is encrypted but the headers are left in the clear.". That's true for
any payload encryption-- the headers are all in the clear as they were
in other examples. The draft states:

"One scenario is when transport protocols provide consistent
information to the network by intentionally exposing a part of the
transport header."

My interpretation of that is that a transport protocol developer would
encrypt some parts of the transport header and leave other parts in
the clear. An example of that would be the spin bit in QUIC. So QUIC
may be the best example, and assuming it hasn't yet been relegated to
the "corner case transport options" bucket by network operators, it
makes for a good case study.

Consider Lloyd's example where receive windows are modified in flight
to optimize a flow. As he mentioned, in some scenarios this
optimization allows TCP to dramatically outperform QUIC. It seems
unlikely that people are going to abandon using QUIC just because of
this, so the obvious question is how can QUIC take advantage of the
same optimization.

The naive approach would just be to expose a receive window field in
the QUIC header and have network devices process it like a receive
window in TCP. This doesn't work! The network identifies QUIC packets
by UDP port number, and as described in RFC7605 port numbers only have
meaning at the endpoints. So if intermediate devices are modifying
some UDP payload that isn't actually QUIC, then this is systematic
silent data corruption. This is not robust protocol and the offered
benefits of the feature don't justify changing fundamental semantics
transport port numbers.

The correct approach is to create a "Receive window guidance"
modifiable Hop-by-Hop option. This could contain a receive window that
the network can modify in flight. The QUIC implementation would be
modified to send and process the option accordingly. Of course, since
the information is no longer in the transport layer, the protocol can
be used with any transport layer protocol or TCP in an encrypted
tunnel.

Tom

---

From: <[email-masked]>
Date: Thu, 21 Feb 2019 07:46:44 +0000

To find a definition for bulk usage transport and set apart corner cases (like tunnels, SCTP and so on), please have a read into state-of-the-art QoE estimation research. There's ample literature on that. In the recent years, QoE research is mostly based on the evaluation of several thousand flows. In many cases captured by commodity terminals connected to consumer Internet products.

TCP or QUIC measure RTT by design. As we all know, RTT can easily be measured by evaluating transport protocol information, if exposed. This information helps to optimize provider networks.  What you recommend is to add an extra header to have a surrogate RTT measurement (if standardisation works out well, IOAM isn't  commodity network feature). I prefer simple solutions. The RTT information can be extracted from the transport layer, as we all know.

The solutions you advocate result in monitoring strategies requiring monitoring applications on consumer terminals. To me, that threatens security of those consumers willing to support such an approach more that exposing some network related information in transport headers. IOAM is an approach which might work some day. QoS and QoE monitoring based on applications in consumer terminals is deployed today. I expect the latter to spread, and to spread faster, the less network related information is exposed to network operators.

I don't think that TCP/IP is the one and only and I don't think that things never change, as I'm changing them myself. I prefer to create win-win solution based on solutions which are as simple as possible. In my experience solutions with these properties work best.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Tom Herbert <[email-masked]> 
Gesendet: Mittwoch, 20. Februar 2019 18:00
An: Geib, Rüdiger <[email-masked]>
Cc: Gorry Fairhurst <[email-masked]>; tsvwg <[email-masked]>
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-04.txt

> I've been describing the general state of the art of QoE measurements based on network QoS parameters. I've been picking TCP as an example. The change from unencrypted TCP transport to TLS is a fai…
Okay, TCP was just an example. So if I'm using another protocol like SCTP, QUIC, TCP in a tunnel then how do I get the same features and network services like plain TCP/IP gets?

Connection oriented protocols, like TCP and QUIC, track RTT per flow.
If this information is interesting to the network it can be provided in HBH option. IOAM should carry a variant usable for RTT measurement.

> Network QoS based QoE estimation us done for the mass market, if a network provider serves it. SCTP and tunnels and the like are corner case transport options. Further, I don't recollect that resea…

I do not know what "corner case transport options" are. Can you please define that term?

> I don't think the approach to have a single solution to monitor all transport options is feasible.

It's not the intent to expose all transport options. As an application and transport protocol developer I am only willing to expose information to the network in plaintext that is absolutely necessary for viable communications, not one bit more than that. I have no interest in exposing everything just on the off chance that some random device in the network might find it useful. I may be willing to provide specific pieces of information if I know how it will be used and an who will use it. This is the reallly the only resonable security model for my users.

> It will likely be too generic to provide useful input if it works end-to-end or it will be too specific to work end-to-end in a majority of cases, I guess. It's also a little hard to understand why…

Again, by "existing packet headers" you are implying that plain TCP/IP is the the only thing that exists and needs to be supported. If the Internet is to move evolve, we need to get beyond this limited view.

Tom

> https://tools.ietf.org/html/draft-ioametal-ippm-6man-ioam-ipv6-options
> -01 which would provide in-situ OAM for IPv6 regardless of transport 
> protocol being carried.
>
> Tom
>
> >

---

From: Tom Herbert <[email-masked]>
Date: Thu, 21 Feb 2019 07:45:34 -0800

On Wed, Feb 20, 2019 at 11:46 PM <[email-masked]> wrote:
>
> To find a definition for bulk usage transport and set apart corner cases (like tunnels, SCTP and so on),

I still don't understand what "corner case" means with respect to
standard IETF protocols. Can you please define this? What are the
requirments for a protocol being a corner case on the Internet or not?
Who makes this determination?

> please have a read into state-of-the-art QoE estimation research. There's ample literature on that. In the recent years, QoE research is mostly based on the evaluation of several thousand flows. In many cases captured by commodity terminals connected to consumer Internet products.
>

No, we don't all know that. The RTT and other information can only be
extracted from transport layer headers under very specific
circumstances (header has the right fields, transport header is
visible and in cleartext, intermediate devices can parse the transport
layer protocol, etc.).
>
> The solutions you advocate result in monitoring strategies requiring monitoring applications on consumer terminals. To me, that threatens security of those consumers willing to support such an

Applications are already heavily monitored as endpoints. The
information that can be gathered about an application from some random
point in the network is extremely limited. Application developers rely
on the data collected at endpoints to make their decisions. The only
time we need drill down to see what is happening in the network is
when we see particular networks are messing things up (for instance,
when we noticed that some  network devices we're drop SYNs with data
when TFO was being developed).

> approach more that exposing some network related information in transport headers. IOAM is an approach which might work some day. QoS and QoE monitoring based on applications in consumer terminals is deployed today. I expect the latter to spread, and to spread faster, the less network related information is exposed to network operators.
>

If you want a win-win than provide a solution that works with all
protocols, promotes security, minimizes effort, and ends protocol
ossification. I don't see that this draft proposes anything resembling
such a solution. The idea seems to be that transport protocol
designers should consider purposely sending some fields in the clear.
Okay, but what exactly are the requirements? How is it simple if this
needs to be done independently for every transport protocol? What are
the realities of that to be feasible? Is the requirements and
assumption that all transport protocols have to provide the same
information as TCP? What about network mechanisms that want to modify
fields like the receive window-- how does that work robustly in other
transport protocols?

Tom

---

From: <[email-masked]>
Date: Fri, 22 Feb 2019 07:33:26 +0000

[TH]  The RTT and other information can only be extracted from transport layer headers under very specific circumstances (header has the right fields, transport header is visible and in cleartext, intermediate devices can parse the transport layer protocol, etc.).

[RG] Agree. By chance TCP allows to determine RTT within the network. RTT monitoring allows network providers optimize router buffers and supports QoE estimates. I'm out for simple solutions. My take is, IETF should provide hints to transport  protocol designers. If transport protocol features are impacted by network properties, then allow the network to detect these. Transport depending on determination of the bandwidth delay product is impacted network features. Classic TCP shows (by chance) that exposing RTT information is feasible and it is beneficial for endpoints as well as for network providers.

[RG] As general guidance I suggest: if a new transport protocol depends on bandwidth delay product optimization then expose the relevant information by design to those partys in your chain operation, which may impact the bandwidth-delay-product. 

[TH] If you want a win-win than provide a solution that works with all protocols, promotes security, minimizes effort, and ends protocol ossification. I don't see that this draft proposes anything resembling such a solution. The idea seems to be that transport protocol designers should consider purposely sending some fields in the clear.
Okay, but what exactly are the requirements? How is it simple if this needs to be done independently for every transport protocol? What are the realities of that to be feasible? Is the requirements and assumption that all transport protocols have to provide the same information as TCP? What about network mechanisms that want to modify fields like the receive window-- how does that work robustly in other transport protocols?

[RG] Requirements: see above. I don't advocate to recommend RTT communication exactly like it is done for TCP - I'm open for discussion between involved experts. I prefer a single recommended approach. As you note yourself, "works with all protocols" and "independently for every transport" - the networks of today can't do per transport protocol or per flow optimization. Fast forwarding and some generic filter edge policies, that's it. Measurements for QoS based QoE estimation and RTT are done passive. I'm not aware of any approach distinguishing transport protocols down to every detail (UDP, TCP, the latter TLS or not and QUIC ... ). Router buffer dimensioning isn't done per transport protocol. A commercial provider network is optimized to service the majority of the users fairly well. "Corner cases" are all those transport protocols which have a share of, say, a low single digit percentage in a commercial network.

[TH] What about network mechanisms that want to modify fields like the receive window-- how does that work robustly in other transport protocols?

[RG] Above I talk about passive measurements. Here you talk about a kind of active communication between routers and of transport protocols (if I get you right - I got no expertise). To me, you mix things which need to be discussed separately. If routers are to support transport features actively, mechanisms need to be standardized to a high degree. Let's take ECN is an example. Two well defined IP layer bits. It took years to switch from the early standardized interpretation to experimental ones. I think, well defined fields and a simple general standard support are the only way to enable routers to communicate information to transport protocols (apart for communicating by "packet drop").

Regards, Ruediger

-----Ursprüngliche Nachricht-----
Von: Tom Herbert <[email-masked]> 
Gesendet: Donnerstag, 21. Februar 2019 16:46
An: Geib, Rüdiger <[email-masked]>
Cc: Gorry Fairhurst <[email-masked]>; tsvwg <[email-masked]>
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-04.txt

> cases (like tunnels, SCTP and so on),

I still don't understand what "corner case" means with respect to standard IETF protocols. Can you please define this? What are the requirments for a protocol being a corner case on the Internet or not?
Who makes this determination?

> TCP or QUIC measure RTT by design. As we all know, RTT can easily be measured by evaluating transport protocol information, if exposed. This information helps to optimize provider networks.  What y…

No, we don't all know that. The RTT and other information can only be extracted from transport layer headers under very specific circumstances (header has the right fields, transport header is visible and in cleartext, intermediate devices can parse the transport layer protocol, etc.).
>
> The solutions you advocate result in monitoring strategies requiring 
> monitoring applications on consumer terminals. To me, that threatens 
> security of those consumers willing to support such an

Applications are already heavily monitored as endpoints. The information that can be gathered about an application from some random point in the network is extremely limited. Application developers rely on the data collected at endpoints to make their decisions. The only time we need drill down to see what is happening in the network is when we see particular networks are messing things up (for instance, when we noticed that some  network devices we're drop SYNs with data when TFO was being developed).

> I don't think that TCP/IP is the one and only and I don't think that things never change, as I'm changing them myself. I prefer to create win-win solution based on solutions which are as simple as…

If you want a win-win than provide a solution that works with all protocols, promotes security, minimizes effort, and ends protocol ossification. I don't see that this draft proposes anything resembling such a solution. The idea seems to be that transport protocol designers should consider purposely sending some fields in the clear.
Okay, but what exactly are the requirements? How is it simple if this needs to be done independently for every transport protocol? What are the realities of that to be feasible? Is the requirements and assumption that all transport protocols have to provide the same information as TCP? What about network mechanisms that want to modify fields like the receive window-- how does that work robustly in other transport protocols?

Tom

> > If QoE, receive window manipulation, timing packet in a flow, etc. 
> > is important and potentially valuable to users then that's great. 
> > But please, consider how to make these a generic protocol so that 
> > ALL transport protocols, ALL use cases of TCP, and in the end ALL 
> > users can take advantage of these features. The best answer is put 
> > the necessary transport information in Hop-by-Hop or modifiable 
> > Hop-by-Hop options. As an example, see 
> > > > Conversely, the draft floats the idea of purposely not 
> > > > encrypting certain fields of a transport header for the purposes 
> > > > that intermediate devices can parse them. What is the deployment

---

From: Tom Herbert <[email-masked]>
Date: Fri, 22 Feb 2019 08:32:37 -0800

> [RG] Above I talk about passive measurements. Here you talk about a kind of active communication between routers and of transport protocols (if I get you right - I got no expertise). To me, you mix…
Ruediger,

Yes, ECN is good example of an IP layer mechanism that carries
information of interest to various transport layer protocols. A router
can set ECN with no regard to the transport or payload so the
mechanism works with TCP, QUIC, SCTP, etc. But, ECN bits are in the IP
header and there really are no reserved bits in either IPv4 or IPv6
headers and no bits that can be easily repurposed for other uses
(people have tried, there have been several proposals to repurpose
bits in the IPv6 flow label for instance).

The correct solution is put the exposed transport information, or more
generally host to network signals, in an extensible lower protocol
(i.e. in the network layer). In IPv6 that would be Hop-by-Hop options.
For IPv4, it's a little more difficult to find a good solution, some
sort of shim header might work (SPUD was proposed for that). The third
high order bit of Hop-by-Hop options indicates whether the option can
be modified in-flight and non-modifiable data can be authenticated so
it is robust. There are other considerations such as ensuring that
signals can't be spoofed to gain an unfair advantage and that exposed
data might need to be scoped somehow (for instance I might be willing
to share information with my local provider, but not to the whole
Internet).

Tom

---

From: <[email-masked]>
Date: Mon, 25 Feb 2019 07:52:56 +0000

Tom,

if consensus and a standard on your proposals for IPv4 and IPv6 can be reached, I'm ok. I'm not a transport protocol expert however (my expertise is QoS and network/transport QoS related QoE - I use the information to be gathered). Others can judge transport protocol related aspects better.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
From: Tom Herbert <[email-masked]> 

[RG] I've re-ordered that, Tom's response above my last mail now... 

Ruediger,

Yes, ECN is good example of an IP layer mechanism that carries information of interest to various transport layer protocols. A router can set ECN with no regard to the transport or payload so the mechanism works with TCP, QUIC, SCTP, etc. But, ECN bits are in the IP header and there really are no reserved bits in either IPv4 or IPv6 headers and no bits that can be easily repurposed for other uses (people have tried, there have been several proposals to repurpose bits in the IPv6 flow label for instance).

The correct solution is put the exposed transport information, or more generally host to network signals, in an extensible lower protocol (i.e. in the network layer). In IPv6 that would be Hop-by-Hop options.
For IPv4, it's a little more difficult to find a good solution, some sort of shim header might work (SPUD was proposed for that). The third high order bit of Hop-by-Hop options indicates whether the option can be modified in-flight and non-modifiable data can be authenticated so it is robust. There are other considerations such as ensuring that signals can't be spoofed to gain an unfair advantage and that exposed data might need to be scoped somehow (for instance I might be willing to share information with my local provider, but not to the whole Internet).

Tom

> Okay, but what exactly are the requirements? How is it simple if this needs to be done independently for every transport protocol? What are the realities of that to be feasible? Is the requirements…
[snip]

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 25 Feb 2019 14:48:54 +0100

hi Tom, all,

We’re way down the rabbit hole here, but you seem to be placing a lot of faith in the deployability of v6 HBH based signaling. Last I checked the story here was pretty bleak: most routers slow-path these (because silicon to handle HBH on the fast path is not economical to ship) so most networks block it. The replacement cycles for kit that does this is tied to capex depreciation (timescales in decades). Admittedly I last looked into this when we were putting together PLUS (so three-four years ago), which would do most of what you’re talking about here in a transport-independent way (and in general I think this goal is a good one). 

Has anything changed here? If not, what’s the transition plan for working v6 HBH?

Thanks, cheers,

Brian

Sent from my iPhone

> On 22 Feb 2019, at 17:32, Tom Herbert <[email-masked]> wrote:
> 
>> [TH] If you want a win-win than provide a solution that works with all protocols, promotes security, minimizes effort, and ends protocol ossification. I don't see that this draft proposes anything resembling such a solution.. The idea seems to be that transport protocol designers should consider purposely sending some fields in the clear.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 27 Feb 2019 13:43:52 -0800

> if consensus and a standard on your proposals for IPv4 and IPv6 can be reached, I'm ok. I'm not a transport protocol expert however (my expertise is QoS and network/transport QoS related QoE - I us…

Hi Ruediger,

My proposal is to put network signaling and transport layer
information an node wishes to expose in the common network layer.
Extension headers have been designed for this purpose, but they are
only defined for IPv6 and some intermediate nodes don't like them
anyway. I posted  draft-herbert-ipv4-udpencap-eh-00 as a proposed
solution.

Tom

---

From: <[email-masked]>
Date: Thu, 28 Feb 2019 08:54:36 +0000

Hi Tom

what I'd prefer is a standardized default exposure of the discussed information by $transport_protocol. Something that's reliably part of commodity code. Evaluation of RTT information is passive, the nodes don't have to read the information, it's to be forwarded unchanged.

The window size optimization is a different story, as it requires active communication of nodes and terminals along a path. Got no expertise. My guts feeling is, that a simplistic generic mechanism may be feasible (not a perfect one).

As I mentioned, my transport know how is limited and I rely on others to judge, whether your draft and other proposals may find consent. It would be great to solve the issues once and maintain some generic design guidance, so that we don't have to have the whole discussion with every new transport protocol. 

Regards,

Ruediger

Hi Ruediger,

My proposal is to put network signaling and transport layer information an node wishes to expose in the common network layer.
Extension headers have been designed for this purpose, but they are only defined for IPv6 and some intermediate nodes don't like them anyway. I posted  draft-herbert-ipv4-udpencap-eh-00 as a proposed solution.

Tom

> > > The solutions you advocate result in monitoring strategies 
> > > requiring monitoring applications on consumer terminals. To me, 
> > > that threatens security of those consumers willing to support such 
> > > an
> >

---

From: Tom Herbert <[email-masked]>
Date: Thu, 28 Feb 2019 09:34:03 -0800

Ruediger,

That's the goal. Allow optional exposure of generic transport layer
information in the network layer. This works with any transport
protocol or any encapsulation, network devices no longer need to do
expensive DPI, and encryption of the transport layer headers becomes a
non-issue. This is the simplest approach!

Tom