IETF Last Call Review of draft-ietf-cats-framework-21
review-ietf-cats-framework-21-tsvart-lc-pauly-2026-03-04-00

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

Thanks for sharing this document. Overall, it does a good job of describing
various functions in the architecture and defines its terminology in depth.
Without expertise in the specific area, I don't see problems in these details.

From a transport perspective, and also looking partly at the security and
privacy aspects, however, there are some issues that deserve clarification or
rethinking.

- Classification of traffic
Section 3.4.5 describes the "Traffic Classifier". This is responsible for
classifying client traffic to aid in the routing. There is a reference to
section 5.1 for more details, but I don't actually see many details in 5.1
about how the classifier is provisioned or what it is matching on. I'm assuming
there are aspects of the 5-tuple being observed, and the text explicitly
mentions SNI inspection. Clarifying the nature of this classification and how
it interacts with transports would be good to add. TCP will behave differently
from QUIC; QUIC can migrate paths, and both TCP and QUIC have multipath
variants that may interact in unexpected ways with a naive classifier. Also,
explicitly calling out SNI tracking brings up questions of usage for TLS
encrypted client hello (RFC 9849), which just was standardized. It's worth
thinking about if traffic classification here can be encouraged to rely on more
explicit signals, such as the approach in SCONE
(https://datatracker.ietf.org/wg/scone/about/).

- Privacy
While the goals of the privacy sections are good ("must support preventing
on-path nodes in the underlay infrastructure to fingerprint and track
clients"), I'm concerned about the overall privacy approach. It seems to rely
on policies of networks being benevolent, rather than technical properties to
reduce information disclosure. For example, "personal data must not be exposed
to external parties" is mainly a statement of policy, and should be framed as
such.

The text specifically calls out that "the CATS solution may need to know about
applications, clients, and even user identity". Tracking applications and user
identity is indeed very sensitive, and this raises the question of how this
information about applications being used by a client is shared with the
network. It seems insufficient to say that this information "should be
encrypted"; encrypting the PII is good, but it also needs to be clear which
entities in the architecture get to see that information, and what they are
able to track or correlate to. It is possible to make policy decisions based on
information without having to correlate the data, but I'm concerned that this
document sets the bar too low at just recommending encryption as a solution.
That is necessary, but not necessarily sufficient. The specific solutions are
not in scope for this document, but it would be good to explain what the
architectural privacy goals should be, such that specific protocols can be
judged to conform to those or not.