[Idr] Re: Secdir early review of draft-ietf-idr-cpr-03

["Dongjie (Jimmy)" <[e-mail]>]

Hi Brian, 

Thanks for your review and comments. 

Please see some replies inline: 

> -----Original Message-----
> From: Brian Weis via Datatracker [mailto:[e-mail]]
> Sent: Thursday, June 13, 2024 8:11 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Secdir early review of draft-ietf-idr-cpr-03
> 
> Reviewer: Brian Weis
> Review result: Has Issues
> 
> 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.

Thanks for pointing out this. I agree that the mapping relationship between the intent and the IPv6 prefix are observable since the BGP messages are not encrypted, thus there is risk with the man-in-the-middle attack. We will add a new paragraph as you suggested. 

While this is similar to other intent-based routing mechanisms, such as BGP CAR/CT and or inter-domain SR Policy, since the packets will also be encapsulated with an SRH to fulfil the intent.


> 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.

Thanks for the suggestion, I agree with the proposed change and will update the draft accordingly. 

Best regards,
Jie

>