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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 07 Apr 2021 17:58:43 -0700

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

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 20 Apr 2021 09:41:54 +0100

The editors have just posted a new revision of the draft on 
Considerations around Transport Header Confidentiality, Network 
Operations, and the Evolution of Internet Transport Protocols.

Revision 21 follows the IESG review and includes revised text after 
comments from Zahed, Erik Kline, Rob Wilton, Eric Vyncke, Roman Danyliw, 
and Benjamin Kaduk. We're greatful for the comments and the new 
suggestions and think we have new text which might address these 
comments. A checklist follows, in case those making comments wish to 
also follow-up.

Besy wishes,

Gorry and Colin

---

    Erik Kline:

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

    * "provide information can support" -> "provide information that can
    support" - Changed.

    [ section 2.2.1 ] * "inferred from a measure the variation" ->
    "inferred from a measure of the variation", - changed.

    [ section 2.2.2 ] * "that they does not recognise" -> "that they do
    not recognise" - Changed.

    [ section 2.3.4 ] * "the network the path" -> "the network path" -
    changed.

    [ section 2.3.6 ] * "A variety and open source and proprietary tools"
    -> "A variety of open source and proprietary tools" - changed,
    updated also by BK.

    [ section 2.4 ] * "to cause the header compression to a fall back" ->
    "to cause the header compression to fall back" - changed.

    [ section 3 ] * "provides data need to" -> "provides data needed to"
    - changed.

    [ section 4 ] * "In some case," -> "In some cases,"- changed.

    [ section 6.1 ] * "part of encapsulation protocol" -> "part of the
    encapsulation protocol", - Changed.

    [ section 7 ] * "make informed choice" -> "make informed choices"-
    Changed.

    Lars/Joel: - Already resolved.

    Rob Wilton:

    * A couple of other minor nits that I spotted: caries -> carries -
    Changed.

    * Example considered -> example that considered - Changed.

    Eric Vyncke:

    * 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'.  ECMP looks for ports but aren't port
    part of the (encrypted) transport header ? This is the ambiguity that
    concerns me.  IPv6 flow labels can be used (section 2.2.2 text is
    good on this), then ECMP problem is solved but 1) not all traffic is
    IPv6 (and I regret it).  - Done.

    * "Common issues concerning IP address sharing are described in
    [RFC6269]." - Done.  Moved.

    * 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 in section 6, but should section 2.2.1 already
    touch the topic ?) - Done. added intro to iOAM.

    * Section 2.2.1 -- Should the part about IPv6 extension headers
    mention draft-ietf-ippm-ioam-data? - Done

    * Section 2.2.1 -- Should the part about IPv6 extension headers
    mention draft-ietf-6man-ipv6-alt-mark? - Done.

    *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" ? - Done.
    Added a sentence.

    * Section 2.4 --- 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) -Done.  Added a section.

    * -- Please add LPWAN WG RFC 8724 in the compression section - Done.

    * Section 6.1 -- Please consider defining a "Maintenance Domain" - Done

    * OAM has already been expanded - Done in -21.

    Roman Danyliw :

     - Slightly longer list - covered by another email.

    Benjamin Kaduk:

    - All NiTs accepted and applied.

    - Comments incorporated, except where questions raised that could not
    be answered.

Zahed:

    * 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? - We did not add text
    on ML, and other methods.

    * "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. - Done. 
reviewed use
    of "network" and clarified to remove one term and consistently say
    when devices need to be on path.

    * Section 2.2.2 : The utility of these measurements depends on the
    type of bearer and number of mechanisms used by network devices. -
  Done  replaced /bearer/ with segment/link.

    * Section 3.2 : what is DCTP? /DCTCP/ - Done.

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 20 Apr 2021 10:02:07 +0100

> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/

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)

---

> header  encryption for network operators, researchers, and others …”, who are
- 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.
>     difficult to observe transport protocol behaviour from the vantage point of
- Done.
> generally as anomaly detection)
- Done: Very helpful and some of this text was added.
> timing, volumes of information, and correlation between multiple flows to
- Done and some of this text was added.
> 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.
> might require changes to such tools, and so could impact operational practice
  - Done.  These words were used.
> 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.

> The trade-off discussed seem pretty limited to only the “user vs. everyone
  - 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.
> 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.
> 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.
> headers breach the “social contract that maintains the stability of the
- Added now more focus on transport.
> 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?

---