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

[Yao Kehan <[e-mail]>]

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 reviewDocument: draft-ietf-cats-metric-definitionTitle: CATS Metrics DefinitionReviewer: Jacqueline McCallReview result: Has IssuesI have reviewed this document as part of the security directorate39s ongoingeffort to review all IETF documents being processed by the IESG. These commentswere written primarily for the benefit of the security area directors. Documenteditors and WG chairs should treat these comments just like any other last callcomments.The summary of the review is “Has Issues”.Thank you for the opportunity to look over this as an early review. Iappreciate the thought that has been put into the security considerations butsee opportunities to build this out for a more complete view. Someobservations/recommendation from a security point of view include:* While the security considerations mention sensitivity of metrics, it missesone of the key points. These metrics are control inputs to steering decisions,not just telemetry. Incorrect or manipulated metrics could impact servicecontact instance selection and forwarding behaviour. Highlighting this wouldhelp frame the section.* CATS metrics are mentioned in the security considerations as “potentiallysensitive”. This should be greatly strengthened, providing information abouthow they might be sensitive (i.e. used to identify), and what unintendeddisclosure/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 provideindications of when metrics should be refreshed, so that CATS components canknow if a metric value is valid or not”. Would this require additional metricfields 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 awhole seems to be missing at the moment and should be covered, before thinkingabout secondary.* Lack of authorisation handling. It is great that authentication is mentionedbetween C-SMA, C-NMA and receivers, but are all values accepted from anyauthenticated 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 and2 for Level 2”.  What happened to Level 0 as defined in Section 3.1? “AppendixA. Level 0 Metric Examples” highlight this as a value that can be used.*The *Source* field is listed as optional.  Section 4. “CATS Metrics Frameworkand Specification” states under *Metric provenance and transparency:* that the“framework explicitly captures the origin and context of metrics by introducinga "Source" field, following the model defined in [RFC9439]”. Being optionalseems at odds with this. All examples also populate this field.-- Cats mailing list -- [e-mail] unsubscribe send an email to [e-mail]：[Cats] draft-ietf-cats-metric-definition-08 early Secdir reviewDocument: draft-ietf-cats-metric-definitionTitle: CATS Metrics DefinitionReviewer: Jacqueline McCallReview result: Has IssuesI have reviewed this document as part of the security directorate39s ongoingeffort to review all IETF documents being processed by the IESG. These commentswere written primarily for the benefit of the security area directors. Documenteditors and WG chairs should treat these comments just like any other last callcomments.The summary of the review is “Has Issues”.Thank you for the opportunity to look over this as an early review. Iappreciate the thought that has been put into the security considerations butsee opportunities to build this out for a more complete view. Someobservations/recommendation from a security point of view include:* While the security considerations mention sensitivity of metrics, it missesone of the key points. These metrics are control inputs to steering decisions,not just telemetry. Incorrect or manipulated metrics could impact servicecontact instance selection and forwarding behaviour. Highlighting this wouldhelp frame the section.* CATS metrics are mentioned in the security considerations as “potentiallysensitive”. This should be greatly strengthened, providing information abouthow they might be sensitive (i.e. used to identify), and what unintendeddisclosure/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 provideindications of when metrics should be refreshed, so that CATS components canknow if a metric value is valid or not”. Would this require additional metricfields 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 awhole seems to be missing at the moment and should be covered, before thinkingabout secondary.* Lack of authorisation handling. It is great that authentication is mentionedbetween C-SMA, C-NMA and receivers, but are all values accepted from anyauthenticated 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 and2 for Level 2”.  What happened to Level 0 as defined in Section 3.1? “AppendixA. Level 0 Metric Examples” highlight this as a value that can be used.*The *Source* field is listed as optional.  Section 4. “CATS Metrics Frameworkand Specification” states under *Metric provenance and transparency:* that the“framework explicitly captures the origin and context of metrics by introducinga "Source" field, following the model defined in [RFC9439]”. Being optionalseems at odds with this. All examples also populate this field.-- Cats mailing list -- [e-mail] unsubscribe send an email to [e-mail]