Skip to main content

Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols


(Martin Duke)

No Objection

(Alvaro Retana)

No Record

Note: This ballot was opened for revision 20 and is now closed.

Erik Kline
Comment (2021-04-05 for -20) Sent
Just nits.

[ section 1 ]

* "Current uses of transport header information in the network are
   explained, which can be beneficial or malicious."

  I suppose it's the "uses of..." that might be seen as beneficial or
  malicious, but I briefly read it as the explanation that was beneficial
  or malicious.


[ section 2 ]

* "provide information can support" ->
  "provide information that can support"?

[ section 2.2.1 ]

* "inferred from a measure the variation" ->
  "inferred from a measure of the variation", perhaps

[ section 2.2.2 ]

* "that they does not recognise" -> "that they do not recognise"

[ section 2.3.4 ]

* "the network the path" -> "the network path"

[ section 2.3.6 ]

* "A variety and open source and proprietary tools" ->
  "A variety of open source and proprietary tools"

[ section 2.4 ]

* "to cause the header compression to a fall back" ->
  "to cause the header compression to fall back"

[ section 3 ]

* "provides data need to" -> "provides data needed to"?

[ section 4 ]

* "In some case," -> "In some cases,", I think

[ section 6.1 ]

* "part of encapsulation protocol" ->
  "part of the encapsulation protocol", perhaps

[ section 7 ]

* "make informed choice" -> "make informed choices"?
Roman Danyliw
No Objection
Comment (2021-04-07 for -20) Sent
** 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.

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

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.
   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.  

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.
Zaheduzzaman Sarker
No Objection
Comment (2021-04-06 for -20) Sent
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.


  * 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.


  * Section 3.2 : what is DCTP? is this  supposed to be DCTCP? Please provide reference to L4S and Data Center TCP.
Éric Vyncke
No Objection
Comment (2021-04-08 for -20) Sent
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,




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
Martin Duke Former IESG member
Yes (for -20) Unknown

Robert Wilton Former IESG member
Yes (2021-04-05 for -20) Sent

Thank you for this document, I found it to be an interesting and informative read.  I also think that this is an important area for the IETF (and IRTF) to monitor the operational impact of more widespread transport header encryption.

Section 5.3 on "Considerations for Exposing Transport Information" is interesting, particularly the observations from RFC 8558 regarding the veracity of explicit signals that are independent from the underlying protocol state machines.  I do wonder whether there could be more text to cover this in the conclusions (section 7).

A couple of other minor nits that I spotted:
caries -> carries
example considered -> example that considered

Alvaro Retana Former IESG member
No Objection
No Objection (for -20) Not sent

Lars Eggert Former IESG member
No Objection
No Objection (2021-04-06 for -20) Sent
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
+                             ++++++++++
Benjamin Kaduk Former IESG member
No Record
No Record (2021-04-09 for -20) Not sent
[remaining at No Record as I did complete my review in time.]

Section 2.2.1

      and policing (traffic management [RFC2475]).  Understanding flow
      loss rates requires either observing sequence numbers in network
      or transport headers, or maintaining per-flow packet counters
      (flow identification often requires transport layer information).

I'm not sure I understand the difference in state requirements between
the "observing sequence numbers in transport [not network] headers" and
"maintainin per-flow packet counters" cases.  Don't you still need
per-flow state to track the last-seen sequence number even if you are
not tracking the count of packets explicitly?

      to tune deployed services.  Latency metrics are key to evaluating
      and deploying AQM [RFC7567], DiffServ [RFC2474], and Explicit
      Congestion Notification (ECN) [RFC3168] [RFC8087].  Measurements

While this seems intuitively true, only the AQM reference seems to
explicitly talk about measuring latency while tuning that mechanism.
So some additional references might be helpful to support this

Section 2.2.2

      Once set, a flow label can provide information that can help
      inform network-layer queueing and forwarding [RFC6438], for
      example with Equal Cost Multi-Path routing and Link Aggregation
      [RFC6294].  RFC 6438 describes considerations when using IPsec

It does?  The string "IPsec" appears only once in RFC 6438 that I could

Section 2.3.4

   Traffic that cannot be classified, typically receives a default
   treatment.  Some networks block or rate-limit traffic that cannot be

While this is no doubt a true statement, I feel like we also have some
IETF statements on open networks (i.e., in contrast to this behavior)
that might be worth mentioning.

Section 3.2

   mechanisms and development of new mechanisms and protocols.  This
   helps understand the interactions between cooperating protocols and
   network mechanisms, the implications of sharing capacity with other
   traffic and the impact of different patterns of usage.  The ability

nit: The verb "understand" doesn't seem to have a subject at the moment.
I'm not sure whether it's better to add one or switch to "aids
understanding" or similar.

Section 4

   Security work typically employs a design technique that seeks to
   expose only what is needed [RFC3552].  This approach provides
   incentives to not reveal any information that is not necessary for
   the end-to-end communication.  The IAB has provided guidelines for
   writing Security Considerations for IETF specifications [RFC3552].

RFC 3552 is an IETF BCP; it is not an IAB document.

      The IPsec Authentication Header (AH) [RFC4302] was designed to
      work at the network layer and authenticate the IP payload.  This
      approach authenticates all transport headers, and verifies their
      integrity at the receiver, preventing in-network modification.
      The IPsec Encapsulating Security Payload (ESP) [RFC4303] can also
      provide authentication and integrity without confidentiality using
      the NULL encryption algorithm [RFC2410].  [...]

(side note?) the consensus of the IPSECME WG is that ESP with NULL
encryption is preferred to AH.  I would have to check whether this is
written down in a useful reference, though.

   Optional Encryption of Header Information:  There are implications to
      the use of optional header encryption in the design of a transport
      protocol, where support of optional mechanisms can increase the
      complexity of the protocol and its implementation, and in the
      management decisions that are have to be made to use variable
      format fields.  Instead, fields of a specific type ought to always
      be sent with the same level of confidentiality or integrity

This is rather veering into "advice" at the end (though I agree with

Section 5.3

      [RFC8558].  The value of this information would be enhanced if the
      exposed information could be verified to match the protocol's
      observed behavior.

Value to whom?

   The motivation to reflect actual transport header information and the
   implications of network devices using this information has to be
   considered when proposing such a method.  [...]

(nit) the word "reflect" here feels slightly out of place; is it
intended to be the same or similar as the term "expose" that we use
earlier in the section and in the section heading?

Section 8

   One mitigation to off-path attack is to deny knowledge of what header
   information is accepted by a receiver or obfuscate the accepted
   header information, e.g., setting a non-predictable initial value for
   a sequence number during a protocol handshake, as in [RFC3550] and
   [RFC6056], or a port value that cannot be predicted (see Section 5.1
   of [RFC8085]).  [...]

This sounds like the sort of thing that
draft-gont-numeric-ids-sec-considerations tries to give guidance about.
(I am, unfortunately, behind schedule in progressing that one.)

   Open standards motivate a desire for this evaluation to include
   independent observation and evaluation of performance data, which in
   turn suggests control over where and when measurement samples are
   collected.  This requires consideration of the appropriate balance

(nit) I'm not sure that we've introduced much of a useful referent for
"this evaluation" that justifies use of "this".