Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols
draft-ietf-tsvwg-transport-encrypt-21

** Section 1. Per “This document discusses some implications of transport header  encryption for network operators, researchers, and others …”, who are these “others”?

Section 1.  Editorial.  Make it clearer that this is on-path observation.

OLD
Such transport header encryption makes it
   difficult to observe transport protocol behaviour within the network

NEW
Such transport header encryption makes it
   difficult to observe transport protocol behaviour from the vantage point of the network.

** Section 2.  This sections seems to have a comprehensive treat of various network management functions.  Missing for me is an organized set of references for the “security use case”.  This doesn’t invalidate the other uses cases, but makes this analysis incomplete.  A few examples might be:

* security audit (e.g., compliance with ciphersuites)
* client and application fingerprinting for inventory and anomaly detection
* DDoS mitigation (mentioned as a security consideration)
* Inspection of transport headers for NIDS/NGFW/etc alerting on (mentioned generally as anomaly detection)

** Section 2.1.  Per “When transport header information cannot be observed, this removes  information that could have been used to classify flows by passive observers along the path.”, it might be worth mentioned that it’s common practice to also do various traffic analysis heuristics relying on timing, volumes of information, and correlation between multiple flows to classify protocols too

** Section 2.3.6.  This section seems to be emphasizing that any changes in protocols may incur a cost on operators by requiring new tooling or practices.  The introduction of this document discussed ossification something that presents its own set of costs.  Perhaps this section might be the place to talk about how the lack of header encryption leads to ossification which introduces an another kind of cost for migration cost.

** Section 2.3.6.  Editorial.
OLD
   Changes to the transport, whether to protect the transport headers,
   introduce a new transport protocol, protocol feature, or application
   might require changes to such tools, and so could impact operational
   practice and policies.  

NEW
Any introduction of a new transport protocol, protocol feature, or application might require changes to such tools, and so could impact operational practice and policies.  

** Section 3.  Section 2 used an effective pattern of providing protocol examples.  This section would be strengthened by providing concrete examples of where weakening the security properties of a production protocol to support researchers’ (not operators) need for visibility provided eventual, tangible benefit to operators or users.

** Section 3.1.  I don’t follow the intent of this section.  I understand that the research community needs to make measurements, but I don’t understand what additional measures are used beyond those outlined in Section 2.*.  If those in Section 2.* lose visibility so do the researchers in Section 3.*.  Is it possible to more clearly describe the circumstances where those in Section 2.* keep visibility and the user community of this section does not?  Can the text illuminate how “independent measurement” is different technically than measurement by the “operator”?

** Section 4.
The use of transport header authentication and encryption therefore
   exposes a tussle between middlebox vendors, operators, applications
   developers and users:
   o  On the one hand, future Internet protocols that support transport
      header encryption assist in the restoration of the end-to-end
      nature of the Internet by returning complex processing to the
      endpoints, since middleboxes cannot modify what they cannot see,
      and can improve privacy by reducing leakage of transport metadata.

   o  On the other hand, encryption of transport layer information has
      implications for people who are responsible for operating
      networks, and researchers and analysts seeking to understand the
      dynamics of protocols and traffic patterns.

I agree that the actors in this “tussle” are “middlebox vendors, operators, application developers and users”.  Thanks for making this taxonomy.  For completeness, the researchers to whom Section 3 is devoted is missing.

Please apply this taxonomy and name these actors relative to the subsequent text.  With the lens of these named actors, the framing of the two sub-bullets is vague and duplicative.

Per the first bullet on the E2E principle, middlebox vendors don’t deploy their own systems.  It’s operators who buy them (or build their own middle boxes) to gain visibility/management into the activity of the users and associated services.  The tussle is users who want improved privacy vs. operators/middle-box vendors who want insight into the traffic.

Per the second bullet, is a restatement of the above.  A variety of parties (operators/researchers) want visibility into the traffic patterns of the users.
The trade-off discussed seem pretty limited to only the “user vs. everyone else”.

** Section 4.  The text on Authenticating the Transport Protocol Header mixes integrity and authenticity.  These are different security properties.

** Section 6.  I had difficulty aligning the benefits of this OAM protocol discussion against the pressing challenges outlined in Sections 2 and 3.  Does a protocol with encrypted headers become less concerning per those uses cases as a result of OAM in some way?  The text immediately jumps into architecture concepts of OAM for which the rest of the text (didn’t for me) so easily fit. Is this guidance for operators or protocol designers?

** Section 7.  I don’t follow the substance of the “Supporting Common Specification” bullet item.  The presence or absence of header encryption seems orthogonal to making a “common, open specifications”.   How do encrypted headers breach the “social contract that maintains the stability of the internet”?

** Section 8.  “Open standards motivate a desire for this evaluation to include independent observation …”, I don’t follow how the process used to develop the standard or perhaps its subsequent unrestricted licensing creates any push to then necessarily support evaluation and performance of real-world usage.  If this is a motivation, perhaps “open standard” can be more clearly defined.

Thanks for producing this informative document. This document describes implications on different stakeholders involved and I hope the discussions in this document help all the stakeholders to achieve the balance required while designing transport protocols.

Comments:

  * It has been mentioned number of times that traffic volume, traffic patterns can be used to perform network measurements (section 2.2.1 and section 2.3.6). how solid are these claims? I would expect some reference material or data to support the claims made. 

  * "on-path" and "in-network" both have been used to indicate particular network devices. This creates some confusion to me. If they are interchangeably used in this document and indicate same network devices then I would recommend to use only one. If they are supposed to indicate different devices then please include the definition of those. This will help readers like me.

  * Section 2.2.2 : 

        The utility of these
   measurements depends on the type of bearer and number of mechanisms
   used by network devices.

     I was wondering if term "bearer" is well understood in the context of this document. I would recommend to add a definition or add more clarification text about  it.

Nits:

  * Section 3.2 : what is DCTP? is this  supposed to be DCTCP? Please provide reference to L4S and Data Center TCP.

Thank you for the work put into this document. The document is excellent on the readability, not a surprise from academic authors ;-)

Special thanks for the doc shepherd's write-up as it writes about the WG consensus/discussion, which appears to be be painful (as expected on this topic). Congratulations David !

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

First a generic comment (close to be a DISCUSS): what about the impact on ECMP (or even LAG) ? Many ECMP hashes are based on a 5-tuple and encrypting the transport header will force the use of a 3-tuple. There should be a section on the important of getting some field with entropy per 'flow'.

-- Section 2 --
Unsure whether "Common issues concerning IP address sharing are described in [RFC6269]." should be part of this document but this is just my opinion. Feel free to ignore.

-- Section 2.2.1 --
This is an impressive text by its clarity while being short and dense. 

I just wonder about the absence of in-band/in-situ measurements, only active/passive probing is mentioned (see other IETF works such as draft-ietf-ippm-ioam-data or draft-ietf-6man-ipv6-alt-mark -- the former only briefly cited in section 3.3 and in more details n section 6 but should section 2.2.1 already touch the topic ?)

-- Section 2.2.2 --
About "IP address", this is probably where IP address sharing should be mentioned (rather than in section 2) ?


Should the part about IPv6 extension headers also mention the draft that I referred to in section 2.2.1 ?

-- Section 2.3.4 --
The DoS attack aspect is possibly too brief... (notably because it is only against the infrastructure and not a volumetric DoS attack against a end-user node). How to "scrub" suspicious traffic if the traffic in "uncharacterized" ?

-- Section 2.4 --
Please add LPWAN WG RFC 8724 in the compression section.

For many constrained network, compression is really important as well as QoS/precedence of some traffic. Should there be a dedicated section about such constrained network ? (for header compression and precedence/QoS setting)


-- Section 3 --

Generic comment: refreshing section about R&D ;-)

-- Section 6.1 --
Please consider defining a "Maintenance Domain"

== NITS ==

-- Section 6 --
OAM has already been expanded

Section 2.2.1, paragraph 11, comment:
>    Throughput and Goodput:  Throughput is the amount of payload data
>       sent by a flow per time interval.  Goodput (see Section 2.5 of
>       [RFC7928]) is a measure of useful data exchanged (the ratio of
>       useful data to total volume of traffic sent by a flow).  The

You might want to refer to the definitions in RFC5166 here; especially the
definition of goodput here (once as a measure and then as a ratio) seems off.

-------------------------------------------------------------------------------
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Section 2, paragraph 4, nit:
-    information can support network operations and management, and this
+    information that can support network operations and management, and this
+               +++++

Section 2, paragraph 4, nit:
-    exploited for purposes unrelated to network transport measurement,
-                                                ----------
+    exploited for purposes unrelated to network measurement,

Section 2.1, paragraph 3, nit:
-    used.  Transport protocols, such as TCP and the Stream Control
-    Transport Protocol (SCTP), specify a standard base header that
+    used.  Transport protocols, such as TCP [RFC7414] and the Stream Control
+                                            ++++++++++
+    Transport Protocol (SCTP) [RFC4960], specify a standard base header that
+                             ++++++++++