Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols
draft-ietf-tsvwg-transport-encrypt-21
Yes
(Martin Duke)
No Objection
(Alvaro Retana)
No Record
Note: This ballot was opened for revision 20 and is now closed.
Erik Kline
Yes
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. 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.
É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, 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
Martin Duke Former IESG member
Yes
Yes
(for -20)
Unknown
Robert Wilton Former IESG member
Yes
Yes
(2021-04-05 for -20)
Sent
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
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 + ++++++++++
Zaheduzzaman Sarker Former IESG member
No Objection
No Objection
(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. 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.
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 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".