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

[Jacqui <[e-mail]>]

Hello,


Thank you for the positive engagement with the feedback and prompt updates
to the draft. I have reviewed the latest version
(draft-ietf-cats-metric-definition-10) and am happy to see how it has
developed.


The security considerations section now provides a far better picture of
the overall security aspects. The opening paragraph does a great job of
conveying the importance of the security considerations and sets up the
remainder of the section well. The format used to cover the individual
components (integrity, authenticity, controllability, freshness, and
confidentiality) is clear and concise, helping readers step through the
different aspects. I really appreciate the work that was put into building
this out.


As for the suggestions on the CATS Metric Fields, removing the “optional”
wording from *Source* and adding “Level 0” as an option for *Level* has
cleared up any confusion.


I look forward to seeing how this document continues to develop as it
progresses through the RFC process.


Thanks

Jacqui

On Mon, Jun 22, 2026 at 8:54 PM Yao Kehan <[e-mail]> wrote:

> Hi Jacqueline,
>
>
> We have just uploaded a new revision of CATS metrics definition draft(-10)
> to reflect your valuable comments regarding to security considerations and
> some general parts.
>
>
>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-cats-metric-definition-10
>
>
> Please help further review if this revision is okay.(Sorry that version
> -09 made no change and was uploaded by mistake.)
>
>
> Best regards,
>
> Kehan (on behalf of co-authors)
>
>
>
> 发件人：Jacqueline McCall via Datatracker  <[e-mail]>
> 收件人：secdir <[e-mail]>
> 抄 送: cats <[e-mail]>,"draft-ietf-cats-metric-definition.all" <
> [e-mail]>
> 发送时间：2026-06-09 13:49:01
> 主题：[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]
>
> 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]
>
>