[secdir] draft-ietf-cats-usecases-requirements-11 ietf last call Secdir review

[Daniel Migault via Datatracker <[e-mail]>]

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.

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.

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.

   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.

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.