Hi Jeff, thank you for the discussion. Please find my notes below tagged GIM3>>.
Regards, Greg On Fri, Dec 13, 2024 at 9:47 AM Jeffrey Haas <jh...@pfrc.org> wrote: > Greg, > > > On Dec 12, 2024, at 7:22 PM, Greg Mirsky <gregimir...@gmail.com> wrote: > > On Thu, Dec 12, 2024 at 11:55 AM Jeffrey Haas <jh...@pfrc.org> wrote: > >> I think additionally what is needed is to delete the other text about >> what is intended to be inside such echo packets. The reference to >> bfd-unaffiliated covers those procedures and they've had the review of the >> BFD WG. >> > GIM2>> As I understand, draft-ietf-bfd-unaffiliated-echo is applicable > only in an environment in which the sender and reflector of an Unaffiliated > Echo message are one IP hop away from each other. However, that is not > guaranteed to be the case in SR-MPLS (and in MPLS in general) because the > reflector of the Unaffiliated Echo may be several IP hops away. As a > result, TTL check on the sender of the Unaffiliated Echo message will fail. > For that reason, draft-ietf-bfd-unaffiliated-echo is outside the scope of > draft-ietf-spring-bfd. It seems that it could be confusing to a reader if > we reference any part of a document positioned as out of the scope. > Besides, draft-ietf-bfd-unaffiliated-echo, if I understand it correctly, > does not define the content of a BFD Echo message for scenarios that > conform to RFC 5880, i.e., that use three-way handshake and allow > transmission of BFD Echo message only if the session is in Up state. Am I > missing something here? > > > Here's the text in the spring draft: > "A BFD Control packet MAY be used as the payload of Echo BFD. This > specification defines the use of Echo BFD in SR-MPLS network with BFD > Control packet as the payload. The use of other types of Echo BFD payload > is outside the scope of this document. Because the remote BFD system does > not process Echo BFD, the value of the Your Discriminator field MUST be set > to the discriminator the local BFD system assigned to the given BFD > session. My Discriminator field MUST be zeroed. Authentication MUST be set > according to the configuration of the BFD session." > > 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 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. > > 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. > > For any other case, an encapsulation that lets you reach the tested system > directly addresses the same need. I.e., anything that tunnels to it. The > spring mechanism here accomplishes that. > GIM3>> I agree. > > The return path and the security implications are where this conversation > gets ugl. The minute you decide you're tunneling multiple hops away, but > the return path isn't a single hop: > - If the return path is a single hop, the bfd unaffiliated procedures can > be used unchanged. > - 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. > - 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? > > You've certainly seen the security ADs and directorate have deep concerns > over these things. My recommendations are: > - Drop the echo procedures for multi-hop. > GIM3>> BFD over SR-MPLS uses uses single-hop BFD > - Keep the echo procedures for bfd unaffiliated for single hop. > GIM3>> It seems like the WG is interested in the applicability of BFD Echo function in the Asynchronous BFD mode. S-BFD already provides a lighter option. > > You might argue that "bfd unaffiliated works, except for TTL", and that > might argue "pull in the procedures by reference and suggest relaxing the > TTL restriction, but I think you'll find the security discussion unpleasant. > > 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. > > > -- Jeff > >
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
