Re: [tsvwg] Roman Danyliw's No Objection on draft-ietf-tsvwg-transport-encrypt-20: (with COMMENT)

[Gorry Fairhurst <[e-mail]>]

On 08/04/2021 01:58, Roman Danyliw via Datatracker wrote:
> Roman Danyliw has entered the following ballot position for
> draft-ietf-tsvwg-transport-encrypt-20: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------

Thanks again for your feedback. We saw many comments were simple and 
likely uncontroversial to resolve. These changes are hopefully reflected 
in -21, which was just posted. Some comments though were longer and so 
the context to our edit is provided below, to help you comment further 
if you think more is needed.

Best wishes,

Gorry & Colin

(as document editors)

---

> ** Section 1. Per “This document discusses some implications of transport
> header  encryption for network operators, researchers, and others …”, who are
> these “others”?
- Thanks: This was a part of original intro, we removed the unkown "others".
>
> Section 1.  Editorial.  Make it clearer that this is on-path observation.
- Changes in many places. Done.
> 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.
- Done.
> ** 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)
- Done: Very helpful and some of this text was added.
> ** 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
- Done and some of this text was added.
> ** 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.
- Wider awareness of how headers had previously been used would likely 
have helped in the design of protocols. We were unsure that this really 
explicitly leads to ossification of tools, that seems like an argument 
that encrypting forces better tools: I'm unsure this is necessarilly 
true - it might result in more weird or unpredictable methods, we do not 
know, of course it could be nice to have common tooling.
> ** 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.
  - Done.  These words were used.
> ** 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”?

- The ID did already mention the way ICCRG etc is being used by the 
transport area. We added more on this.

> ** 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”.
  - We made role of R&D in the IETF transport area more evident. We were 
unsure of what further change is helpful: We'd agree that 
research/development and SDOs have to live with the realities of what is 
deployed, and already agree that Individuals desire increased privacy 
from the network and content providers.
> ** Section 4.  The text on Authenticating the Transport Protocol Header mixes
> integrity and authenticity.  These are different security properties.
- We think we did this: But, we'd really happy to update if from a 
security perspective the terms need more refinement.
> ** 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?
- Done.  Also dded that OAM and IOAM enable the set of things listed in 
section 2, based on other AD comments.
> ** 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”?
- Added now more focus on transport.
> ** 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.
>
- Added to section 3, so does this address the issue?  Is this 
interaction between the link,network and transpprt something that is 
seen differently in the transport area, what additional should be said?

---