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

[Ballot comment]
[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
statement.

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
      [RFC6438].

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

Section 2.3.4

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

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

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

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

[Ballot comment]
[remaining at No Record as I did not have time to complete my review.]

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

[Ballot comment]
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

Closed request for Telechat review by INTDIR with state 'Withdrawn': The document is on the IESG telechat today. No need anymore for a review (still welcome by the authors probably).

[Ballot comment]
** 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.

[Ballot comment]
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.

[Ballot comment]
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.

  * Section 4 : s/motive/motivation ??

[Ballot comment]
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.
  * Section 4 : s/motive/motivation ??

[Ballot comment]
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
+                            ++++++++++

[Ballot comment]
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"?

[Ballot comment]
Hi,

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

Regards,
Rob

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-tsvwg-transport-encrypt-19, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-02-19):

From: The IESG
To: IETF-Announce
CC: David Black , david.black@dell.com, draft-ietf-tsvwg-transport-encrypt@ietf.org, martin.h.duke@gmail.com, tsvwg-chairs@ietf.org, tsvwg@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document: - 'Considerations around
Transport Header Confidentiality, Network
  Operations, and the Evolution of Internet Transport Protocols'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-02-19. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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, mitigate attacks against the transport
  protocol, and protect 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 or features.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/



No IPR declarations have been submitted directly on this I-D.

Document shepherd write-up:

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

1. Summary

Document Shepherd: David Black
Responsible AD: Martin Duke

  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 or features.  These
  considerations arise from concerns such as network operations,
  prevention of network ossification, enabling transport protocol
  evolution and respect for user privacy.

This draft is a discussion of design considerations that is intended
"for the general information of the Internet community" making
Informational RFC publication appropriate, as indicated by those words
quoted from Section 4.2.2 of RFC 2026.

While this draft was being developed, RFC 8789 was published which
updates RFC 2026 to require IETF consensus for publication of all
IETF Stream RFCs, including Informational RFCs.

2. Review and Consensus

This draft is one of a number of documents that discuss considerations
and consequences of network header and traffic encryption.  Such documents
have been controversial, e.g., RFC 8404 ("Effects of Pervasive Encryption
on Operators") and RFC 8517 ("An Inventory of Transport-Centric Functions
Provided by Middleboxes: An Operator Perspective"), and this draft has not
been an exception.  The current draft version is the result of 3 Working
Group Last Calls (WGLCs) to achieve rough consensus in the Working Group
(WG), and that rough consensus includes an open issue to be carried forward
for resolution at IETF Last Call - whether or not this draft is consistent
with IETF consensus on encryption usage, e.g., as reflected in prior RFCs
such as RFC 7258 ("Pervasive Monitoring Is an Attack") and RFC 7624
("Confidentiality in the Face of Pervasive Surveillance: A Threat Model
and Problem Statement").  Whether or not this draft is consistent with
IETF consensus is itself a matter of IETF consensus that is appropriate
to determine at IETF Last Call.

From the outset, this draft has been intended as a discussion of design
considerations that refrains from making protocol design recommendations.

WG development of this draft was uneventful until the first WGLC on the
-08 version of the draft.  That WGLC was cross-posted to the Internet
and Security Areas, inviting their comments, and extensive input was
received from both areas.  The first WGLC showed significant support
for RFC publication of the draft and recognition of the usefulness of
its contents, although the first WGLC was not successful.

The crucial conclusion of the first WGLC was that the draft was overly
critical of transport header encryption - to quote one of the commenters
(Christian Huitema):
Much of the draft reads like a lamentation of the horrible
consequences of encrypting transport headers ...
(https://mailarchive.ietf.org/arch/msg/tsvwg/ctPi-nysGSrUNRl_slM8HNYNl60/)

In light of this outcome, the draft was extensively rewritten in
consultation with a number of the commenters to better balance the draft
with an overall goal of taking a roughly neutral stance on transport
header encryption - neither in favor of nor opposed to, but rather with
a primary purpose of explaining some design considerations.  Numerous
other WGLC suggestions for improved text were also incorporated.

The resulting -12 version of the draft was sent to a second WGLC, again
cross-posted to the Internet and Security Areas to invite comments.
The results of the second WGLC were generally positive - overall support
for the draft and significant suggestions for improved text, but with two
significant issues raised against publication of the draft:

  1. No useful guidance to protocol designers (David Schinazi)
  2. Not consistent with IETF consensus on encryption (Eric Rescorla)
(https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU/)

The announcement of the intended conclusion of this second WGLC during
an interim meeting resulted in a process concern being raised to the
Area Director (AD) that in light of those two issues having been raised,
the second WGLC did not demonstrate sufficient WG rough consensus for
RFC publication of the draft to proceed.

In consultation with the AD and the individual who raised the process
concern, after suggestions for improved text were incorporated, a limited
scope 3rd WGLC was conducted to address the process concern and the two
underlying significant issues on which it was based, as well as check
text improvements made in response to comments during the second WGLC:
https://mailarchive.ietf.org/arch/msg/tsvwg/UIw6tgdSs3AzOc3CFZgwR7HKk7A/

The 3rd WGLC demonstrated WG rough consensus for RFC publication of the
draft and WG rough consensus to dismiss the first significant issue
("No useful guidance") as requesting (in the WG's view) unwarranted
scope expansion of the draft, as announced here:
https://mailarchive.ietf.org/arch/msg/tsvwg/Y0Kw-gL33aa7FLki5Et31oqKajM/ .

The second significant issue noted above on consistency with IETF consensus
is more involved, as described in the conclusion of the 3rd WGLC:

  The issue of this draft not being consistent with IETF consensus on
  encryption usage is long-standing, having been raised at the first
  WGLC on this draft, and it is also equally long-disputed, likewise
  since the first WGLC on this draft.

Resolving that issue entails determining the IETF consensus with respect
to this draft, as announced in the conclusion of the 3rd WGLC:

  In consultation with the responsible Area Director (Martin Duke), the
  chosen path forward to a conclusion on this issue is to consult the
  IETF community on IETF consensus via an IETF Last Call.  The fact that
  IETF consensus (or lack thereof) on this draft is unknown and needs
  to be determined will be explicitly noted in the shepherd writeup
  for this draft and should be explicitly mentioned in the IETF Last
  Call announcement for this draft.

This shepherd writeup hereby takes explicit note of that issue and
requests that it be explicitly mentioned in the IETF Last Call announcement.

Resolution of this issue should keep in mind that the 3rd WGLC clearly
demonstrated WG rough consensus in favor of RFC publication of this draft.
See the announcement of the 3rd WGLC conclusion for details:
https://mailarchive.ietf.org/arch/msg/tsvwg/Y0Kw-gL33aa7FLki5Et31oqKajM/

3. Intellectual Property

The draft authors have stated their direct, personal knowledge that any
IPR related to this document has already been disclosed, in conformance
with BCPs 78 and 79.

4. Other Points

idnits found an RFC 2119 keyword in text quoted from another RFC, although
this draft contains neither the requisite boilerplate nor a reference
to RFC 2119.  That is not a problem for text quoted from another RFC.

idnits also found an Internet-Draft that has been updated, which is also
not a problem.

This draft informatively references draft-ietf-tsvwg-rtcweb-qos, part of
the infamous cluster 238 at the RFC Editor.  The shepherd looks forward
to seeing an idnits complaint that the referenced rtcweb-qos draft has
been published as an RFC :-).

A concern has been raised privately that RFC 8789 changed the publication
rules and requirements for this draft rather late in the game, as publication
of RFC 8789 occurred during the 3rd WGLC of this draft.

Document shepherd write-up:

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

1. Summary

Document Shepherd: David Black
Responsible AD: Martin Duke

  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 or features.  These
  considerations arise from concerns such as network operations,
  prevention of network ossification, enabling transport protocol
  evolution and respect for user privacy.

This draft is a discussion of design considerations that is intended
"for the general information of the Internet community" making
Informational RFC publication appropriate, as indicated by those words
quoted from Section 4.2.2 of RFC 2026.

While this draft was being developed, RFC 8789 was published which
updates RFC 2026 to require IETF consensus for publication of all
IETF Stream RFCs, including Informational RFCs.

2. Review and Consensus

This draft is one of a number of documents that discuss considerations
and consequences of network header and traffic encryption.  Such documents
have been controversial, e.g., RFC 8404 ("Effects of Pervasive Encryption
on Operators") and RFC 8517 ("An Inventory of Transport-Centric Functions
Provided by Middleboxes: An Operator Perspective"), and this draft has not
been an exception.  The current draft version is the result of 3 Working
Group Last Calls (WGLCs) to achieve rough consensus in the Working Group
(WG), and that rough consensus includes an open issue to be carried forward
for resolution at IETF Last Call - whether or not this draft is consistent
with IETF consensus on encryption usage, e.g., as reflected in prior RFCs
such as RFC 7258 ("Pervasive Monitoring Is an Attack") and RFC 7624
("Confidentiality in the Face of Pervasive Surveillance: A Threat Model
and Problem Statement").  Whether or not this draft is consistent with
IETF consensus is itself a matter of IETF consensus that is appropriate
to determine at IETF Last Call.

From the outset, this draft has been intended as a discussion of design
considerations that refrains from making protocol design recommendations.

WG development of this draft was uneventful until the first WGLC on the
-08 version of the draft.  That WGLC was cross-posted to the Internet
and Security Areas, inviting their comments, and extensive input was
received from both areas.  The first WGLC showed significant support
for RFC publication of the draft and recognition of the usefulness of
its contents, although the first WGLC was not successful.

The crucial conclusion of the first WGLC was that the draft was overly
critical of transport header encryption - to quote one of the commenters
(Christian Huitema):
Much of the draft reads like a lamentation of the horrible
consequences of encrypting transport headers ...
(https://mailarchive.ietf.org/arch/msg/tsvwg/ctPi-nysGSrUNRl_slM8HNYNl60/)

In light of this outcome, the draft was extensively rewritten in
consultation with a number of the commenters to better balance the draft
with an overall goal of taking a roughly neutral stance on transport
header encryption - neither in favor of nor opposed to, but rather with
a primary purpose of explaining some design considerations.  Numerous
other WGLC suggestions for improved text were also incorporated.

The resulting -12 version of the draft was sent to a second WGLC, again
cross-posted to the Internet and Security Areas to invite comments.
The results of the second WGLC were generally positive - overall support
for the draft and significant suggestions for improved text, but with two
significant issues raised against publication of the draft:

  1. No useful guidance to protocol designers (David Schinazi)
  2. Not consistent with IETF consensus on encryption (Eric Rescorla)
(https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU/)

The announcement of the intended conclusion of this second WGLC during
an interim meeting resulted in a process concern being raised to the
Area Director (AD) that in light of those two issues having been raised,
the second WGLC did not demonstrate sufficient WG rough consensus for
RFC publication of the draft to proceed.

In consultation with the AD and the individual who raised the process
concern, after suggestions for improved text were incorporated, a limited
scope 3rd WGLC was conducted to address the process concern and the two
underlying significant issues on which it was based, as well as check
text improvements made in response to comments during the second WGLC:
https://mailarchive.ietf.org/arch/msg/tsvwg/UIw6tgdSs3AzOc3CFZgwR7HKk7A/

The 3rd WGLC demonstrated WG rough consensus for RFC publication of the
draft and WG rough consensus to dismiss the first significant issue
("No useful guidance") as requesting (in the WG's view) unwarranted
scope expansion of the draft, as announced here:
https://mailarchive.ietf.org/arch/msg/tsvwg/Y0Kw-gL33aa7FLki5Et31oqKajM/ .

The second issue noted above on consistency with IETF consensus is more
involved, as described in the conclusion of the 3rd WGLC:

  The issue of this draft not being consistent with IETF consensus on
  encryption usage is long-standing, having been raised at the first
  WGLC on this draft, and it is also equally long-disputed, likewise
  since the first WGLC on this draft.

Resolving that issue entails determining the IETF consensus with respect
to this draft, as announced in the conclusion of the 3rd WGLC:

  In consultation with the responsible Area Director (Martin Duke), the
  chosen path forward to a conclusion on this issue is to consult the
  IETF community on IETF consensus via an IETF Last Call.  The fact that
  IETF consensus (or lack thereof) on this draft is unknown and needs
  to be determined will be explicitly noted in the shepherd writeup
  for this draft and should be explicitly mentioned in the IETF Last
  Call announcement for this draft.

This shepherd writeup hereby takes explicity note of that issue and
requests that it be explicitly mentioned in the IETF Last Call announcement.

Resolution of this issue should keep in mind that the 3rd WGLC clearly
demonstrated WG rough consensus in favor of RFC publication of this draft.
See the announcement of the 3rd WGLC conclusion for details:
https://mailarchive.ietf.org/arch/msg/tsvwg/Y0Kw-gL33aa7FLki5Et31oqKajM/

3. Intellectual Property

The draft authors have stated their direct, personal knowledge that any
IPR related to this document has already been disclosed, in conformance
with BCPs 78 and 79.

4. Other Points

idnits found an RFC 2119 keyword in text quoted from another RFC, although
this draft contains neither the requisite boilerplate nor a reference
to RFC 2119.  That is not a problem for text quoted from another RFC.

idnits also found an Internet-Draft that has been updated, which is also
not a problem.

This draft informatively references draft-ietf-tsvwg-rtcweb-qos, part of
the infamous cluster 238 at the RFC Editor.  The shepherd looks forward
to seeing an idnits complaint that the referenced rtcweb-qos draft has
been published as an RFC :-).

A concern has been raised privately that RFC 8789 changed the publication
rules and requirements for this draft rather late in the game, as publication
of RFC 8789 occurred during the 3rd WGLC of this draft.

Document shepherd write-up:

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

1. Summary

Document Shepherd: David Black
Responsible AD: Martin Duke

  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 or features.  These
  considerations arise from concerns such as network operations,
  prevention of network ossification, enabling transport protocol
  evolution and respect for user privacy.

This draft is a discussion of design considerations that is intended
"for the general information of the Internet community" making
Informational RFC publication appropriate, as indicated by those words
quoted from Section 4.2.2 of RFC 2026.

While this draft was being developed, RFC 8789 was published which
updates RFC 2026 to require IETF consensus for publication of all
IETF Stream RFCs, including Informational RFCs.

2. Review and Consensus

This draft is one of a number of documents that discuss considerations
and consequences of network header and traffic encryption.  Such documents
have been controversial, e.g., RFC 8404 ("Effects of Pervasive Encryption
on Operators") and RFC 8517 ("An Inventory of Transport-Centric Functions
Provided by Middleboxes: An Operator Perspective"), and this draft has not
been an exception.  The current draft version is the result of 3 Working
Group Last Calls (WGLCs) to achieve rough consensus in the Working Group
(WG), and that rough consensus includes an open issue to be carried forward
for resolution at IETF Last Call - whether or not this draft is consistent
with IETF consensus on encryption usage, e.g., as reflected in prior RFCs
such as RFC 7258 ("Pervasive Monitoring Is an Attack") and RFC 7624
("Confidentiality in the Face of Pervasive Surveillance: A Threat Model
and Problem Statement").  Whether or not this draft is consistent with
IETF consensus is itself a matter of IETF consensus that is appropriate
to determine at IETF Last Call.

From the outset, this draft has been intended as a discussion of design
considerations that refrains from making protocol design recommendations.

WG development of this draft was uneventful until the first WGLC on the
-08 version of the draft.  That WGLC was cross-posted to the Internet
and Security Areas, inviting their comments, and extensive input was
received from both areas.  The first WGLC showed significant support
for RFC publication of the draft and recognition of the usefulness of
its contents, although the first WGLC was not successful.

The crucial conclusion of the first WGLC was that the draft was overly
critical of transport header encryption - to quote one of the commenters
(Christian Huitema):
Much of the draft reads like a lamentation of the horrible
consequences of encrypting transport headers ...
(https://mailarchive.ietf.org/arch/msg/tsvwg/ctPi-nysGSrUNRl_slM8HNYNl60/)

In light of this outcome, the draft was extensively rewritten in
consultation with a number of the commenters to better balance the draft
with an overall goal of taking a roughly neutral stance on transport
header encryption - neither in favor of nor opposed to, but rather with
a primary purpose of explaining some design considerations.  Numerous
other WGLC suggestions for improved text were also incorporated.

The resulting -12 version of the draft was sent to a second WGLC, again
cross-posted to the Internet and Security Areas to invite comments.
The results of the second WGLC were generally positive - overall support
for the draft and significant suggestions for improved text, but with two
significant issues raised against publication of the draft:

  1. No useful guidance to protocol designers (David Schinazi)
  2. Not consistent with IETF consensus on encryption (Eric Rescorla)
(https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU/)

The announcement of the intended conclusion of this second WGLC during
an interim meeting resulted in a process concern being raised to the
Area Director (AD) that in light of those two issues having been raised,
the second WGLC did not demonstrate sufficient WG rough consensus for
RFC publication of the draft to proceed.

In consultation with the AD and the individual who raised the process
concern, after suggestions for improved text were incorporated, a limited
scope 3rd WGLC was conducted to address the process concern and the two
underlying significant issues on which it was based, as well as check
text improvements made in response to comments during the second WGLC:
https://mailarchive.ietf.org/arch/msg/tsvwg/UIw6tgdSs3AzOc3CFZgwR7HKk7A/

The 3rd WGLC demonstrated WG rough consensus for RFC publication of the
draft and WG rough consensus to dismiss the first significant issue
("No useful guidance") as requesting (in the WG's view) unwarranted
scope expansion of the draft, as announced here:
https://mailarchive.ietf.org/arch/msg/tsvwg/Y0Kw-gL33aa7FLki5Et31oqKajM/ .

The second issue noted above on consistency with IETF consensus is more
involved, as described in the conclusion of the 3rd WGLC:

  The issue of this draft not being consistent with IETF consensus on
  encryption usage is long-standing, having been raised at the first
  WGLC on this draft, and it is also equally long-disputed, likewise
  since the first WGLC on this draft.

Resolving that issue entails determining the IETF consensus with respect
to this draft, as announced in the conclusion of the 3rd WGLC:

  In consultation with the responsible Area Director (Martin Duke), the
  chosen path forward to a conclusion on this issue is to consult the
  IETF community on IETF consensus via an IETF Last Call.  The fact that
  IETF consensus (or lack thereof) on this draft is unknown and needs
  to be determined will be explicitly noted in the shepherd writeup
  for this draft and should be explicitly mentioned in the IETF Last
  Call announcement for this draft.

This shepherd writeup hereby takes explicity note of that issue and
requests that it be explicitly mentioned in the IETF Last Call announcement.

Resolution of this issue should keep in mind that the 3rd WGLC clearly
demonstrated WG rough consensus in favor of RFC publication of this draft.
See the announcement of the 3rd WGLC conclusion for details:
https://mailarchive.ietf.org/arch/msg/tsvwg/Y0Kw-gL33aa7FLki5Et31oqKajM/

3. Intellectual Property

The draft authors have stated their direct, personal knowledge that any
IPR related to this document has already been disclosed, in conformance
with BCPs 78 and 79.

4. Other Points

idnits found an RFC 2119 keyword in text quoted from another RFC, although
this draft contains neither the requisite boilerplate nor a reference
to RFC 2119.  That is not a problem for text quoted from another RFC.

idnits also found an Internet-Draft that has been updated, which is also
not a problem.

This draft informatively references draft-ietf-tsvwg-rtcweb-qos, part of
the infamous cluster 238 at the RFC Editor.  The shepherd looks forward
to seeing an idnits complaint that the referenced rtcweb-qos draft has
been published as an RFC :-).

A concern has been raised privately that RFC 8789 changed the publication
rules and requirements for this draft rather late in the game, as publication
of RFC 8789 occurred during the 3rd WGLC of this draft.