[Cats] Re: draft-ietf-cats-usecases-requirements-11 ietf last call Secdir review

[kehan yao <[e-mail]>]

Dear Daniel,
Thank you very much for your review. Please see my replies inline below.

I will update a revision according to your comments.

Best regards,
Kehan

Daniel Migault via Datatracker <[e-mail]> 于2026年1月6日周二 03:21写道：

> Document: draft-ietf-cats-usecases-requirements
> Title: Computing-Aware Traffic Steering (CATS) Problem Statement, Use
> Cases,
> and Requirements Reviewer: Daniel Migault Review result: Has Nits
>
> Hi,
>
> This document has been reviewed as part of the security area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the
> document's
> authors and WG to allow them to address any issues raised and also to the
> IETF
> discussion list for information.
>
> I do not have specific security concerns regarding the document; however,
> the
> relationship between metrics and routing is not yet clear to me. I
> acknowledge
> that I have not reviewed the other CATS-related documents, which may
> explain my
> limited understanding of the broader context. Nevertheless, I would
> appreciate
> clarification for my own understanding, leaving it to the authors to decide
> whether additional explanation is warranted in the document.
>
> My current understanding is that the considered metrics include both
> system-level parameters (e.g., available CPU resources) and network-related
> metrics such as latency. These metrics would inform decisions on service
> instantiation and traffic assignment. For service dimensioning, relying on
> monitoring data from edge data centers appears reasonable, as such
> information
> can be considered relatively trustworthy.
>
> However, when traffic from different user equipments (e.g., UE1 and UEa) is
> steered toward different service instances, it is unclear to me how this
> differentiation is achieved in practice and what role routing plays in this
> process. While DNS-based mechanisms and anycast can influence instance
> selection, their achievable granularity and level of control remain
> unclear in
> this context.
>
> Given that this work falls within the routing area, I am therefore
> wondering
> whether CATS considers routing-based traffic steering (e.g., à la anycast)
> or
> whether service instances are expected to be distinct and explicitly
> addressable. In the former case, if routing decisions rely on information
> originating from end users, this would significantly increase the attack
> surface. At present, it is unclear whether such scenarios are in scope of
> the
> described use cases.
>
> [KY] Thank you for your question. I would like to briefly explain the CATS
preferred solutions and how to define metrics to influence routing
decisions.
Firstly, the CATS traffic steering scheme does tend to adopt routing-level
steering (such as Anycast extension, or so-called dynamic Anycast). By
extending existing routing protocols (e.g., BGP), it transmits computing
and network metrics to achieve optimized forwarding based on global
resource and status. At this time, service instances are addressed through
a unified Service Identifier, and the routing layer dynamically maps it to
the optimal instance address. As for explicit addressing methods (e.g.,
DNS-based schemes), the working group has not yet reached a consensus and
the discussion is still ongoing. This document does not directly define
relevant requirements either.
Regarding the definition granularity and control level of metrics, as well
as how they correspondingly affect routing steering, the working group has
adopted the CATS metric definition as a working group draft:
draft-ietf-cats-metric-definition. This work defines an abstract model for
CATS metrics, covering from basic resources to normalized metrics, and
comprehensively considers different dimensions such as the stability and
accuracy of metrics on routing steering. Flow-level steering can be
achieved.
During the steering process, CATS routing decisions do not directly rely on
raw information reported by the terminal side, but on aggregated resource
and status metrics of service instances. Terminals only need to provide a
service identifier, and location information can be anonymized (in
compliance with requirement R24).


> Similarly, if traffic steering depends on resource availability at edge
> sites,
> this could leak information about site load conditions. Such information
> could
> potentially be exploited by an attacker, for example to optimize the cost
> of a
> denial-of-service attack. While I understand that service instances may
> share a
> common identifier, there may still be indirect means to infer the physical
> location or load of individual sites.
>
> [KY] Regarding the security requirements related to the leakage of edge
site resources, requirements R25 and R26 currently provide targeted
constraints.
R25 requires that "Service instances MUST be authenticated. 'Service
identifier - instance address' mapping results MUST be encrypted."
R26 requires that metric collection and distribution must be encrypted, and
mechanisms for secondary validation of abnormal metrics must be supported
to identify falsely reported malicious load information.


> Other comments:
>
> 3.2.  Traffic Steering among Edges Sites and Service Instances
>
>    Figure 1 shows a common way to deploy edge sites in the metro.  Edge
>    sites are connected with Provider Edges(PEs).  There is an edge data
>    center for metro area which has high computing resource and provides
>    the service to more User Equipments(UEs) at the working time.
>    Because more office buildings are in the metro area.
>
> mglt: I think the two sentences should be a single sentence.
>
> [KY] Thanks and ACK.


>    And there are
>    also some remote edge sites which have limited computing resource and
>    provide the service to the UEs close to them.
>
> mglt: Based on my understanding of the scenarios, all UEs are situated
> within
> the same region. UE[1-n] are linked to the nearest data center, which can
> intuitively be regarded as the optimal selection. However, as resources
> become
> limited, UE[a-b] connect to their most suitable server instance located at
> a
> more remote site. Consequently, the figure illustrates that the best
> option is
> the nearest, with Edge Site 1 and Edge Site 2 being the closest locations
> to
> UE[a-b]. I believe the message would be more comprehensible if UE[a-b]
> appeared
> to be co-located with the other UEs [1-n], while maintaining a more distant
> connection to the Edge Sites.
>
>    Applications to meet service demands could be deployed in both the
>    edge data center in metro area and the remote edge sites.  In this
>    case, the service request and the resource are matched well.  Some
>    potential traffic steering may be needed just for special service
>    request or some small scheduling demand.
>
> [...]
>
>         +----------------+    +---+                  +------------+
>       +----------------+ |- - |UE1|                +------------+ |
>       | +-----------+  | |    +---+             +--|    Edge    | |
>       | |Edge server|  | |    +---+       +- - -|PE|            | |
>       | +-----------+  | |- - |UE2|       |     +--|   Site 1   |-+
>       | +-----------+  | |    +---+                +------------+
>       | |Edge server|  | |     ...        |            |
>       | +-----------+  | +--+         Potential      +---+ +---+
>       | +-----------+  | |PE|- - - - - - -+          |UEa| |UEb|
>       | |Edge server|  | +--+         Steering       +---+ +---+
>       | +-----------+  | |    +---+       |                  |
>       | +-----------+  | |- - |UE3|                  +------------+
>       | |  ... ...  |  | |    +---+       |        +------------+ |
>       | +-----------+  | |     ...              +--|    Edge    | |
>       |                | |    +---+       +- - -|PE|            | |
>       |Edge data center|-+- - |UEn|             +--|   Site 2   |-+
>       +----------------+      +---+                +------------+
>       High computing resource              Limited computing resource
>       and more UE at metro area            and less UE at remote area
>
>                  Figure 1: Common Deployment of Edge Sites
>
>         +----------------+                           +------------+
>       +----------------+ |                         +------------+ |
>       | +-----------+  | |  Steering traffic    +--|    Edge    | |
>       | |Edge server|  | |          +-----------|PE|            | |
>       | +-----------+  | |    +---+ |           +--|   Site 1   |-+
>       | +-----------+  | |- - |UEa| |    +----+----+-+----------+
>       | |Edge server|  | |    +---+ |    |           |           |
>       | +-----------+  | +--+       |  +---+ +---+ +---+ +---+ +---+
>       | +-----------+  | |PE|-------+  |UE1| |UE2| |UE3| |...| |UEn|
>       | |Edge server|  | +--+       |  +---+ +---+ +---+ +---+ +---+
>       | +-----------+  | |    +---+ |          |           |
>       | +-----------+  | |- - |UEb| |          +-----+-----+------+
>       | |  ... ...  |  | |    +---+ |              +------------+ |
>       | +-----------+  | |          |           +--|    Edge    | |
>       |                | |          +-----------|PE|            | |
>       |Edge data center|-+  Steering traffic    +--|   Site 2   |-+
>       +----------------+                           +------------+
>       High computing resource              Limited computing resource
>       and less UE at metro area            and more UE at remote area
>
>                 Figure 2: Steering Traffic among Edge Sites
>
>    There will also be the common variable of network and computing
>    resources, for someone who is not moving but get a poor latency
>    sometime.  Because of other UEs moving, a large number of request for
>    temporary events such as vocal concert, shopping festival and so on,
>    and there will also be the normal change of the network and computing
>    resource status.  So for some fixed UEs, it is also expected to steer
>    the traffic to appropriate sites dynamically.
>
> mglt: To my understanding, UE[1-n] are anticipated to be nearer to Edge
> Sites 1
> and 2 during the night, similar to UE[a-b]. If this is accurate, I would
> suggest consolidating all UEs at a single location in the illustration. The
> existing Fig2 appears to indicate that UE[1-n] have transitioned from
> downtown
> to the suburbs, whereas UE[a-b] have shifted from the suburbs to downtown.
>
> [KY] I think your above suggestions are very good. I will appropriately
adjust Figure 1, Figure 2, and the corresponding textual descriptions in
the next version.


> 4.2.  Example 2: Computing-aware Intelligent Transportation
>
>    For the convenience and safety of transportation, more video capture
>    devices need to be deployed as urban infrastructure, and the better
>    video quality is also required to facilitate the content analysis.
>    Therefore, the transmission capacity of the network will need to be
>    further increased, and the collected video data need to be further
>    processed by edge nodes for edge computing, such as for pedestrian
>    face recognition, vehicle tracking, and road accident prediction.
>
> mglt: Facial recognition presents considerable ethical concerns and ought
> to be
> regarded more as a counter-argument for exploring new technology. It also
> indirectly contradicts R24, as I comprehend it. At the very least, it
> should be
> eliminated.
>


> [KY] Thank you for pointing out the ethical issues. I will revise it to:
> _NEW_
> “such as pedestrian flow statistics, vehicle tracking, and road accident
> prediction”.
>
>
> --
> Cats mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>