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 > <mailto: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. :-) 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? 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. 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. 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. - 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. 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. - Keep the echo procedures for bfd unaffiliated for single hop. 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. -- Jeff
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
