Hi Christian,
I am glad to hear that the changes improved the security considerations section and addressed most of your concerns.
Building on top of your proposal below I have made the following change that streamlines this part of the security section and at the same time is more concrete / strong in its language
OLD
The PSN is assumed to be trusted and secure. Considerations about the MPLS core network outlined in [RFC4381] are applicable.
For MPLS based PSNs, one of the requirements for protecting the data plane is that the MPLS packets be accepted only from valid interfaces. For a PE, valid interfaces comprise links from other routers in the PE's own AS. For an ASBR, valid interfaces comprise links from other routers in the ASBR's own AS, and links from other ASBRs in ASes that have instances of a given PLE PWs. It is especially important in the case of multi-AS PLE PWs that one accepts PLE packets only from valid interfaces.
When a Segment Routing (SR) based PSN is used (MPLS or SRv6) the considerations in Section 8 of [RFC8402] and Section 9.3 of [RFC9252] are applicable.
NEW
The PSN (MPLS or SRv6) is assumed to be trusted and secure. Attackers who manage to send spoofed packets into the PSN could easily disrupt the PLE service. This MUST be prevented by following best practices for the isolation of the PSN. These protections are described in the considerations in {{Section 3.4 of RFC4381}}, {{Section 4.2 of RFC5920}} in {{Section 8 of RFC8402}} and {{Section 9.3 of RFC9252}}.
Christian
> On 29.11.2024, at 20:49, Christian Huitema via Datatracker <noreply@xxxxxxxx> wrote:
>
> Reviewer: Christian Huitema
> Review result: Has Nits
>
> I previously reviewed draft-09. The authors have addressed a lot of the
> concerns that I expressed in that review. For example, I appreciate the
> recommendation to randomize the initial sequence number in RTP packets, which
> adds some protection against off-path attackers. But I am still concerned by
> the possibility of attackers sending spoofed IPv6 packets and disrupting the
> operations of Private Line Emulation. The security section does address this
> concern, but in a rather elliptic way, by saying "When a Segment Routing (SR)
> based PSN is used (MPLS or SRv6) the considerations in Section 8 of [RFC8402]
> and Section 9.3 of [RFC9252] are applicable." My main concern is that "are
> applicable" is a rather weak statement.
>
> The other concern is that the reader who wants to follow this weak
> recommendation has to engage in a bit of a treasure hunt. Go read RFC 8402, or
> at least its security section. Find out that it refers to RFC3209 (Extensions
> to RSVP for LSP Tunnels), RFC4381 (analysis of security for BGP/MPLS IP VPN),
> RFC5920 (Security Framework for MPLS and GMPLS Networks), and RFC5095
> (deprecation of the original routing header). Go read RFC 9252, which specifies
> BGP Overlay Services Based on SRv6. Find out that it refers to BGP security,
> and cites for that RFC4271 (BGP), RFC4272 (security analysis for BGP), TCP
> Authentication Option (RFC5925), BGP Keying and authentication (RFC6952),
> security considerations for the BGP services, such as BGP IPv4 over IPv6 NH
> [RFC8950], BGP IPv6 L3VPN [RFC4659], BGP IPv6 [RFC2545], BGP EVPN [RFC7432],
> and IP EVPN [RFC9136]. That's hundred of pages to analyze. It would require
> quite a bit of motivation!
>
> One way to obtain such motivation is to make the wording much stronger. Plainly
> speaking, the security of the system relies on the isolation of a segment of
> the Internet, a segment that the draft refers to as "the Packet Switched
> Network". If that isolation fails, the service becomes vulnerable. How about
> replacing the paragraph that I quoted by something like:
>
> When a Segment Routing (SR) based PSN is used (MPLS or SRv6), attackers who
> manage to send spoofed packets into the PSN could easily disrupt the PLE
> service. This MUST be prevented by following best practices for the isolation
> of the PSN. These protections are described in the considerations in Section 8
> of [RFC8402] and Section 9.3 of [RFC9252].
>
>
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
