Greg, On Fri, Dec 13, 2024 at 04:48:41PM -0800, Greg Mirsky wrote: > On Fri, Dec 13, 2024 at 9:47 AM Jeffrey Haas <jh...@pfrc.org> wrote: > > The first issue is the contents are left up to the implementor in RFC > > 5880. It's an easy argument to say that this draft has no business > > specifying echo contents. :-) > > > GIM3>> As I understand it, the WG has demonstrated interest in specifying > the applicability of BFD Echo function in an SR-MPLS network.
That's distinct from saying "we're going to define undefined BFD echo procedures". But since we're talking about doing such definition... > > That said, the reason we're having this conversation is similar to > > unaffiliated BFD: If you're not using BFD async and want to use echo, are > > there suggested contents and procedure? > > > GIM3>> The intention of this specification is to define the applicability > of BFD Echo function as part of the Asynchronous BFD mode. Thus, I don't > see the analogy with the Unaffiliated Echo. In spite of the fact that you're largely "reinventing" (or perhaps more politely, "borrowing") similar procedures? The spring chairs and AD should make note of this. I'm not going to argue with you on this bit of semantic handwaving. > > A thing that remains true for BFD echo is that you need to address the > > echo packet to the destination in such a way that it loops back to > > yourself. For basic IP forwarding, that's single hop - it won't loop > > through the remote system if it's more than one hop away. > > > GIM3>> For SR-MPLS that can be achieved using Binding SID. Thus, there's no > IP forwarding involved. I didn't argue against this point. What I'm pointing out is that if the SID in question isn't part of the expected test of the forwarding path, you've invented a forwarding semantic to test BFD, not testing the endpoint with BFD. > - If the return path isn't a single hop, in the absence of appropriate > > authentication on the contents of the echo packet, you can't tell if BFD is > > being talked to by an active attacker or not. > > > GIM3>> It seems that the recommendation in Section 7 BFD for Use with > Tunnels of RFC 5881 is also applicable to BFD Echo function in SR-MPLS: > The BFD authentication mechanism SHOULD be > used and is strongly encouraged. Indeed. > > - If you're permitting your echo implementation to talk to things more > > than one hop away, you're opening yourself up to multi-hop attacks. > > > GIM3>> A Sender will use the value in Your Discriminator field to > demultiplex echoed packets it receives on UDP port 3875 for BFD sessions > that are in Up state. Am I missing something here? Perhaps that the TTL protective mechanisms for IP BFD break down in an SR environment in some circumstances. This document specifies SR-MPLS. It's probably fine here. Those safety mechanisms will further break down for SRv6. Part of the motivation in pointing out this consideration is SR-MPLS mechanisms usually get leveraged for SRv6. But largely this points are highlighted because you're setting this document up for the same scrutiny that BFD unaffiliated did. The spring WG is perhaps fortunate that that review was completed recently so that any such considerations are fresh in the IESG's mind. > > - Drop the echo procedures for multi-hop. > > > GIM3>> BFD over SR-MPLS uses uses single-hop BFD Then why are you objecting to the GTSM TTL procedures? > > The last point about bfd echo procedures for 5880 being not applicable... > > the whole point is it's up to the implementation and bfd unaffiliated is > > just suggesting what to do with it. It works fine even for 5880. > > > GIM3>> I think that the Unaffiliated Echo works only for RFC 5881 over IP. > It seems that the TTL check of the sender of the Unaffiliated Echo makes it > unusuable in the RFC 5884 scenario. Which argues it's not single-hop. -- Jeff _______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
