Reviewer: Christian Huitema Review result: Has Nits 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"? -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
