Last Call Review of draft-ietf-pals-ple-08
review-ietf-pals-ple-08-secdir-lc-huitema-2024-10-15-00

Review results: having a standard for sending 100 of Gigabits over pseudo-wires
is awesome, but the security section may need a bit of work.

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 draft defines two "pseudo-wires" encapsulations for "private line
emulation":

1) An MPLS encapsulation in which a frame starts by an MPLS header, possibly
including a stack of labels per
   segment routing, followed by a PLE header and a bit stream payload;

2) An IPv6 packet, in which the IPv6 header includes the segment routing
option. The header that follows the
   SRv6 headers will have the type "BIT-EMU" (to be assigned by IANA per this
   draft), contains the PLE header, and is followed by the bit stream payload.

The bit stream payloads are composed by the sender, and replayed as a bit
stream at the receiver. This obviously requires that there is enough bandwidth
on the selected path, and that the receiver manages a sufficient jitter buffer.
The draft assumes that the paths are carefully engineered, enough bandwidth is
reserved, etc.

The draft specifies how to "fill the holes" and signal errors when a packet
does not arrive in time, and a performance monitoring system.

The draft specifies how to use the PLE service to carry specific "physical"
services like multiple variants of Ethernet, SONET/SDH, Fiber Channel, OTN. I
did not review that part. But I am rather impressed that we can now carry 10 or
100 Gbps links over pseudo-wires. Wow.

Security considerations:

The security considerations state that PLE "relies upon the Packet Switched
Network mechanisms for encryption, integrity, and authentication whenever
required." I am not sure what that implies exactly. Is it possible for example
to combine "PLE/BIT-EMU" and IPSEC? This is hinted to in RFC3985, but does it
require a specific support in PLE?

The draft inherits the security issues with pseudo wire services detailed in
the security considerations of RFC3985. What are the recommended deployment
scenarios and security postures to prevent or mitigate the attacks described in
RFC3985? I assume that the draft is intended for use in places where all the
internal nodes are under a common ownership, or at least a common management.
Could the draft state that "single managed domain" requirement explicitly?

Regarding the "single managed domain" hypothesis, there are obvious exposures
if the attackers do manage to get some access to the domain -- or if parts of
the service are exposed outside of the managed domain. Attackers could for
example send spoofed IPv6 packets to internal routers and try to get these
inserted in the SR path, and then in the pseudo wire. What happens if an attack
like that succeeds? How does the service recover?

The security section mentions RFC 7432, which includes some mitigations. I am
not sure that all these mitigations apply -- for example, the discussion of MAC
addresses in 7432 is probably not relevant here. If some do, should they be
cited explicitly? What about the recommendations in section 8 of RFC 8402?

Typos:

in section 8, QoS and Congestion Control: you write that the data should "be
carried over traffic-engineering paths". Do you mean "traffic-engineered paths"?

in section 9, security considerations: you write that clock synchronization is
sensitive "to various threads and attacked vectors". Do you mean "to various
threats and attack vectors"?