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.