[Cats] Re: draft-ietf-cats-metric-definition-08 early Secdir review

[Adrian Farrel <[e-mail]>]

Hi Jacqueline,

Many thanks for this really helpful review.
This is exactly the sort of perspective I hoped for when I asked for the review.
I hope the authors will work with this and make a better and more robust solution.

Best,
Adrian

-----Original Message-----
From: Jacqueline McCall via Datatracker <[e-mail]> 
Sent: 09 June 2026 06:49
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: [Cats] draft-ietf-cats-metric-definition-08 early Secdir review

Document: draft-ietf-cats-metric-definition
Title: CATS Metrics Definition
Reviewer: Jacqueline McCall
Review result: Has Issues

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

The summary of the review is “Has Issues”.

Thank you for the opportunity to look over this as an early review. I
appreciate the thought that has been put into the security considerations but
see opportunities to build this out for a more complete view. Some
observations/recommendation from a security point of view include:

* While the security considerations mention sensitivity of metrics, it misses
one of the key points. These metrics are control inputs to steering decisions,
not just telemetry. Incorrect or manipulated metrics could impact service
contact instance selection and forwarding behaviour. Highlighting this would
help frame the section.

* CATS metrics are mentioned in the security considerations as “potentially
sensitive”. This should be greatly strengthened, providing information about
how they might be sensitive (i.e. used to identify), and what unintended
disclosure/access to these metrics could mean.

* This document provides no discussion around handling stale values.
Requirement seven (R7) in draft-ietf-cats-usecases-requirements-14 states that
“CATS systems MUST support staleness handling for CATS metrics and provide
indications of when metrics should be refreshed, so that CATS components can
know if a metric value is valid or not”. Would this require additional metric
fields to achieve? A lack of validation raises security concerns.

* Following on from the previous point, current security considerations states
“False reporting SHOULD be mitigated via secondary validation”. Validation as a
whole seems to be missing at the moment and should be covered, before thinking
about secondary.

* Lack of authorisation handling. It is great that authentication is mentioned
between C-SMA, C-NMA and receivers, but are all values accepted from any
authenticated source?

Outside of the above security points, more general observations include:

4.1.  CATS Metric Fields

*The *Level* field specifies “This field can take two values: 1 for Level 1 and
2 for Level 2”.  What happened to Level 0 as defined in Section 3.1? “Appendix
A. Level 0 Metric Examples” highlight this as a value that can be used.

*The *Source* field is listed as optional.  Section 4. “CATS Metrics Framework
and Specification” states under *Metric provenance and transparency:* that the
“framework explicitly captures the origin and context of metrics by introducing
a "Source" field, following the model defined in [RFC9439]”. Being optional
seems at odds with this. All examples also populate this field.



-- 
Cats mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]