Early Review of draft-ietf-idr-cpr-03
review-ietf-idr-cpr-03-secdir-early-weis-2024-06-12-00

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.

This document introduces Colored Prefix Routing (CPR), which allows
cooperating IPv6 domains  to implement a common “intent” policy for
handling particular IPv6 packets. Examples of “intent” policy  are
low-delay or high-bandwidth. IPv6 segment routing is a key part of
the solution, and “intent” is declared by choosing a particular
IPv6 address for each intent, where the per-intent addresses are
defined within a a subnet associated with a Provider Edge (PE) node.
Thus when a packet is to be routed to that PE using a particular
intent, the initial PE encapsulates that packet in a Segment Header
where the final IPv6 address in the Segment Header is the “intent”
address advertised by the domain containing the destination. It
seems to be expected that each domain in between has a mapping of
the “intent” address and the “intent” and will treat it accordingly.
And if not, then the packet will still be routed properly. (I believe
this is a accurate summary, but apologies if I’ve used imprecise
language.)

Existing BGP and Segment Header definitions are used; this document
proposes no new packet formats or attributes.

One threat is considered in the Security Considerations section,
which is the the fact that routes to the “intent” IPv6 addresses
will add to the size of the routing table, which typically has an
upper bound of routes that can be maintained. This is a valid
Availability issue. The text concludes the impact of adding routes
to the additional IPv6 addresses is acceptable, and I don’t have
any reason to believe otherwise.

There is a potential Privacy issue associated with marking “intent”
using IP addresses. Consider a man-in-the-middle attacker between
domains who ascertains the mapping between “intent” and its IPv6
address. They can then accurately target flows matching that intent
to/from that PE router. By way of example, assume the attacker is
targeting voice calls for a particular domain and the domain shares
an “intent” for telephony (e.g.., “low-delay”). The attacker could
then easily target those phone calls for surveillance and/or
extracting copies of the packet flow for offline analysis.  I would
suggest adding a new paragraph to Security Considerations describing
the attack as something like: “Because there is a mapping between
intent and an SRv6 identifier, and the SRv6 identifier is observable
within the inter-domain path, it is possible for a man-in-the-middle
attacker to identify packets associated with a particular intent.”
I don’t have a suggestion for how to mitigate the attack as I don’t
believe the Segment Header can be encrypted.

The Security Considerations section suggests that it “does not
introduce any additional security considerations than those described
in [RFC4271] and [RFC4272]”. If the issue mentioned above is addressed
it won't be true that the document doesn't introduce any additional
security considerations. I would suggest changing the sentence to
something like “Security Considerations described in [RFC4271] and
[RFC4272] apply.” Also consider adding RFC 8754 (IPv6 Segment Routing
Header) to the list.