Thank you for making these changes. On 12/3/2024 1:37 PM, Christian Schmutzer (cschmutz) wrote:
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}}. ChristianOn 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
