Skip to main content

Telechat Review of draft-ietf-pals-ple-12
review-ietf-pals-ple-12-secdir-telechat-huitema-2024-11-29-00

Request Review of draft-ietf-pals-ple
Requested revision No specific revision (document currently at 13)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2024-12-03
Requested 2024-11-19
Authors Steven Gringeri , Jeremy Whittaker , Nicolai Leymann , Christian Schmutzer , Chris Brown
I-D last updated 2024-11-29
Completed reviews Rtgdir Last Call review of -06 by Tal Mizrahi (diff)
Genart Last Call review of -08 by Joel M. Halpern (diff)
Secdir Last Call review of -08 by Christian Huitema (diff)
Opsdir Last Call review of -10 by Tony Li (diff)
Tsvart Last Call review of -09 by Tommy Pauly (diff)
Secdir Last Call review of -09 by Christian Huitema (diff)
Secdir Telechat review of -12 by Christian Huitema (diff)
Assignment Reviewer Christian Huitema
State Completed
Request Telechat review on draft-ietf-pals-ple by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/weWbOW89FQL02lI-cjh1W2d3DMo
Reviewed revision 12 (document currently at 13)
Result Has nits
Completed 2024-11-29
review-ietf-pals-ple-12-secdir-telechat-huitema-2024-11-29-00
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].