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.

This document declares itself to be a deployment guide for In-situ
OAM (IOAM). It provides an overview of the different models that
IOAM can have (e.g.,  per-hop tracing), the IOAM protocol encapsulations
that are in development, and deployment considerations. It is well
written, providing a good overview to the use of IOAM.

The Security Considerations section is well-written, but I have
some suggestions on how to more clearly state the threats to IOAM.

1. While there is mention of integrity for the Proof-of-transit
option data, there is no mention of generally needing to protect
IOAM data for integrity within an OAM domain. I understand that
this IOAM deployment document can specify no particular method, and
I see that the Security  Requirements of RFC 9197 does make some
more specific statements about integrity protection at the protocol
level. But it would be good here to state that in some deployments
it is  important for an IOAM transit node and IAOM decapsulating
node to know that the data it received hadn’t been tampered with,
and that in those cases the IOAM data should be integrity protected.

2. Security Considerations says

  “… in order to limit the scope of threats to within the
   current network domain the network operator is expected to enforce
   policies that prevent IOAM traffic from leaking outside of the
   IOAM domain, and prevent IOAM data from outside the domain to
   be processed and used within the domain. “

Filtering IOAM  traffic at the edge of a domain is important. But
I suggest that the text highlight the threats a bit more strongly.
There are two issues mentioned here.

a.  “policies that prevent IOAM traffic from leaking outside of the
IOAM domain”. While there may be little or no threat to the leaking
of timestamps and other network data, there could be actual privacy
issues for an IOAM encapsulating node that is a home gateway in an
operator’s network. A home gateway is often identified with an
individual, and revealing IOAM data such as “IOAM node identifier”
and especially geo-location information outside of the domain could
be catastrophic for that user. If this threat could be incorporated
into that sentence somehow, it would be stronger.

b. “prevent IOAM data from outside the domain to be processed and
used within the domain”. This data “processed and used within the
domain” could be just bad data where a device outside the domain
is accidentally leaking into the domain. But it could also be an
agent introducing IOAM data from outside the domain in an effort
to attack the system. Perhaps this could be worded “prevent an
attacker from introducing malicious or false IOAM data to be processed
and used within the domain”.

3. Similarly, Security Considerations also says:

   “… deployments that are not confined to a single LAN, but span
   multiple inter-connected sites (for example, using an overlay
   network), the inter-site links can be secured (e.g., by IPsec)
   in order to avoid external eavesdropping.”

This is a good advice, but the wording “can be secured” is rather
weak. Considering again the privacy consideration and desire for
accurate data mentioned above, this should at least say “are expected
to be secured” rather than “can be secured. Indeed, I wish that
formal requirements language could be used here but as an Informational
document I’m not sure if that would be appropriate.

Also, a better ending to that sentence would be something like “in
order to avoid external eavesdropping and introduction of malicious
or false data”.