[secdir] Secdir review of draft-ietf-ippm-ioam-ipv6-options

[Radia Perlman <[e-mail]>]

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 concerns embedding In-situ Operations, Administration, and
Maintenance (IOAM) data in IPv6 extension headers. IOAM data is telemetry
data added by routers to packets as they transit a network, and sometimes
removed by routers if the packets leave an "IOAM domain". IOAM extensions
can be either Hop-by-Hop options or Destination options. The IOAM data
itself is defined in another document (RFC9197).



This document has a lot of jargon that makes it difficult to parse for the
uninitiated (and I count myself among them). My one concern with respect to
security comes from the statement in section 5.1:



"OAM data leaks can affect the forwarding behavior and state of network
elements outside an IOAM domain. IOAM domains SHOULD provide a mechanism to
prevent data leaks or be able to ensure that if a leak occurs, network
elements outside the domain are not affected (i.e., they continue to
process other valid packets)."



The concern is that IOAM domains should be clearly delimited and IOAM
extensions should be stripped before a packet leaves the domain and/or as
it enters a domain.



My concern is that this could be difficult to enforce when IPv6 packets are
encapsulated - in particular by IPsec. AH needs to understand which
extensions are mutable and which are immutable. I don't know whether the
defaults cover these extensions adequately or whether additional
specification in necessary. ESP needs to know whether the other end of the
security association is in the same IOAM domain so that it knows whether to
encapsulate IOAM extensions or drop them. All of this may require
additional configuration and may not behave correctly with implementations
that are not aware of IOAM data. There may also be a matter of merging IOAM
data from an outer envelope with IOAM data from an inner envelope when
doing decapsulation.



I'm not an expert on either IOAM or IPsec's handling of IPv6 extensions,
but someone who is should look at this specification and make sure it is
not going to create problems.


Radia