On Tuesday, 9 June 2020 01:41:40 UTC Black, David wrote: > This email announces a limited-scope 3rd TSVWG Working Group Last Call > (WGLC) on: > > Considerations around Transport Header Confidentiality, Network > Operations, and the Evolution of Internet Transport Protocols > draft-ietf-tsvwg-transport-encrypt-15 > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/ > > This draft is intended to become an Informational RFC. This WGLC has > been cc:'d to the SAAG and INT-AREA lists courtesy of the breadth of > interest in this draft, but WGLC discussion will take place on the TSVWG > list ([email protected]<mailto:[email protected]>) - please don't remove that list > address if/when replying with WGLC comments.
the goals of "prevention of network ossification" are incompatible with layering exits such as a router using non-routing header information to guide its operations. this isn't a new constraint collision -- consider OSPF ECMP which needs to examine the TCP or UDP header to find a 5-tuple to hash upon. as this draft is informational, objections of the form "it says something that is untrue or at least confrontational" or "it lacks something essential" are in scope and the answer should be "send a pull request". whereas objections of the form shown in the e-mail summary (archival) thread you referenced: (https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU/) > I would like to see this useful content in a BCP document once we have > enough information to actually recommend something. are out of scope because this document isn't making any recommendations, and (ibid) > Having an IETF Consensus RFC that is so heavily weighted on the side of > "this is how encryption inconveniences us" and so light on "these are the > attacks we are preventing" gives a misleading picture of the IETF > community's view of the relative priority of these concerns. are regressive, leading back to the result of "send a pull request" since the consensus being sought isn't about a recommendation but rather a depiction of known considerations. unknown considerations should not concern us, since those always exist and cannot be addressed until they make themselves known. known considerations which are missing, incomplete, or misleading in the text as drafted, should be fixed. i have two objections, both of which are inoperable at this time due to the limited scope of this WGLC. (you're asking for pass/fail, and the time for me to have suggested these changes has passed.) first, section 7.2 could do some real good by enumerating local operating system and local network policy as reasons why a transport protocol should have low-entropy markers. on many endpoints and within many networks, uncharacterized traffic will be dropped. the advance of DoH has caused and will continue to cause broader adoption of required explicit proxies to prevent uncooperative insiders from bypassing DNS policy controls. QUIC is going to cause UDP to become a privileged operation, denied except for classifiable traffic, to prevent similar bypasses. a brief examination of these deployment obstacles to PM-resistant transport deployment would help inform the manageability draft, and may even motivate a secure proxy discovery protocol similar to what the ADD WG is working on for secure RDNS discovery. it's clear that DHCP in its current form will never be used to communicate any endpoint parameter which has security value. a transport protocol which permits an on-path device to authentically deny an unclassifiable flow will be deployed more quickly and more widely, and so a mention of these tensions in section 7.2 might accelerate darwinism here. second, the absence of signaling within the IP and IP6 headers to drive the advancement of congestion management is a form of ossification, and should be blamed here. the needs of L4S or SCE or similar should not have a bearing on QUIC or for that matter even on TCP. so, when discussing anti-ossification as a goal, this document could highlight that previous ossification has created many of the tensions the document will go on to describe in detail. this bit of history won't be known by most readers, and could provoke cognitive dissonance if left untreated. given the inoperable (because: late) nature of my objections, i support publication of this draft. thank you for giving us a chance to comment. vixie _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
