|
Hi Christian
Thank you for your comments and I share your excitement about PLE being able to emulate high speed interfaces such as 100GE or higher ;-)
Let me try to address your comments inline via [cs]
I also included respective changes in the new -09 version I just uploaded
Regards
Christian
On 16.10.2024, at 07:56, Christian Huitema via Datatracker <noreply@xxxxxxxx> wrote:
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?
[cs] We are following the lead of similar technologies from the past such as SATOP (RFC4533) where I got the text from. Yes you can run PLE over SRv6 and leverage IPsec. Nothing special required from PLE side, it is just a matter of an implementation combining
the technologies. As encryption technologies for IP and MPLS continuously evolve I think it is good to not be too specific.
I also adopted now two more sentences from RFC4553 that I think make sense in context of 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?
[cs] Agree on the thought here. I have added a sentence that states the assumption of the network being trusted and secure and a pointer to RFC4381. RFC8402 did the same, so I think this wording makes sense.
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?
[cs] you will get sequence errors, payloads will be dropped and the service gets degraded for goes down. I tried to address this with this sentence
A data plane attack may force PLE packets to be dropped, re-ordered or delayed beyond the limit of the CE-bound IWF's dejitter buffer leading to either degradation or service disruption. Considerations outlined in {{?RFC9055}} are a good reference.
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?
[cs] I added a reference to RFC7432 because control plane wise PLE PWs are expected to leverage EVPN-VPWS. You have a good point that most considerations in this RFC don’t apply to PLE, I removed the pointer and rather adopted just one paragraph which
is applicable and data plane relate
What about the recommendations in section 8 of RFC 8402?
[cs] that is a great consideration. I added a sentence pointing to it for cases where SR is used in the PSN
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"?
[cs] thanks for catching, corrected
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”?
[cs] thanks for catching, corrected
|
