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

[Kehan Yao <[e-mail]>]

Hi Jacqueline,

Thank you so much for your detailed feedback, especially on security
considerations.
Based on your feedback, I have proposed some updates here,
https://github.com/ietf-wg-cats/draft-ietf-cats-metric-definition/pull/38/changes

Please also see my detailed reply inline below.

Best regards,
Kehan

Adrian Farrel <[e-mail]> 于2026年6月9日周二 17:56写道：

> 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.
>
> [KY] Thanks. Indeed, it is necessary to add a statement at the beginning
of the Security Considerations section to clearly highlight the critical
role of CATS metrics. Would the following text be suitable as an opening
paragraph?
_NEW_
CATS metrics are not merely telemetry data, but are important inputs to the
traffic steering selection logic. Incorrect or manipulated metrics can
directly affect forwarding behaviour, potentially leading to service
disruption or policy violation. CATS metrics are dynamic and sensitive.
They may indirectly expose physical locations, health status, or service
topology information of CATS service instances. Attackers could sample or
correlate metrics to infer internal service instance states and mount
targeted attacks. Therefore, the security properties of CATS metric -
integrity, authenticity, controllability, freshness, and confidentiality,
are of critical importance.

* 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.
>
> [KY] Thank you for your feedback on sensitivity. We have also added
relevant text in the first paragraph of the Security Considerations
section, as shown in the reply to the previous question.


> * 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.
>
> [KY] Thank you. We have now included metric freshness and staleness
handling as one of the key properties of CATS metric security
considerations, and have supplemented the document with the following
content:
_NEW_

*Freshness*: ensures that metrics are not stale or replayed; only
sufficiently recent metrics are used for decision-making.

SEC-4: Each metric MUST include a precise timestamp and SHOULD include an
explicit validity interval or lifetime. Receivers and C-PS MUST enforce
freshness checks.

--

Regarding whether a dedicated extra field is required for staleness
marking: at this point, I do not see it as a MUST, because applications can
implement their own staleness logic based on timestamps and local policies.


> * 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.
>
> [KY]Thank you. We have also added authentication-related descriptions,
mainly in the context of metric authenticity. Some description of
verification requirements has also been added for metric integrity.

_NEW_

*Authenticity*: ensures that a metric genuinely originates from the claimed
service instance or trusted publisher.

SEC-2: Each metric publisher MUST be authenticated using strong
cryptographic credentials. Metrics MUST carry a verifiable proof of origin
that binds the metric to the publisher's identity. Receivers MUST reject
metrics that cannot be authenticated, regardless of their content.


> * 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?
>
> [KY] I have added a property - "controllability" - to describe the
requirements related to authorization and access control policies.
_NEW_

*Controllability*: ensures that only explicitly authorized entities are
allowed to publish metrics.

SEC-3: The CATS system MUST enforce fine-grained control policies that
authorize which publishers can report metrics for which service instances.
Unauthorized publication attempts MUST be rejected and logged.


> 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.
>
> [KY] Thank you. That has been updated.


> *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.
>
> [KY] The "optional" wording has been removed.

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