Dear Eric, Thanks for taking this work as the alternate responsible AD for this BFD document. Thanks for the thorough review and thoughtful comments. Please see inline.
Original From: EricVyncke(evyncke) <[email protected]> To: [email protected] <[email protected]>; Cc: John Scudder <[email protected]>;[email protected] <[email protected]>;[email protected] <[email protected]>;肖敏10093570;Reshad Rahman <[email protected]>;[email protected] <[email protected]>;Jeffrey Haas <[email protected]>; Date: 2024年09月20日 17:10 Subject: Alternate AD review of draft-ietf-bfd-unaffiliated-echo-10 Dear BFD, dear authors, To lighten John Scudder’s workload, I will be the alternate responsible AD for draft-ietf-bfd-unaffiliated-echo. As I am an INT AD, please bear with me if I state something wrong about BFD ;-) First of all: thanks to the authors and the WHG for authoring this I-D and to Jeff Haas for being the shepherd. Before proceeding with the publication process, I usually do my AD review before starting the IETF Last Call and *I request either a reply or an action (revised I-D) for all the points below* (some of them are nits); the only goal is to ease the IESG evaluation later. Let’s work together to get this I-D published :-) Regards -éric # Abstract s/ This document proposes a use of the BFD Echo/ This document defines a use of the BFD Echo/ [XM]>>> OK. s/but the neighboring system does/but the adjacent system does/ ? (to be consistent with S1) [XM]>>> OK. Will make this change along the whole document. # Generic The section 1 should include some explanations about how packets are looped back to the source. RFC 5881 says ‘no LLA and not the subnet addresses’, so which addresses are used for source and destination ? The addressing probably deserves one section in the document. [XM]>>> This is a good question and I'm sure it's asked before. So I checked the old versions of this document. In version -07 Section 2 it says: "Regarding the selection of IP address, as specified in Section 4 of [RFC5881], the destination address MUST be chosen in such a way as to cause the remote system to forward the packet back to the local system. The source address MUST be chosen in such a way as to preclude the remote system from generating ICMP or Neighbor Discovery Redirect messages. In particular, the source address SHOULD NOT be part of the subnet bound to the interface over which the BFD Echo packet is being transmitted, and it SHOULD NOT be an IPv6 link-local address, unless it is known by other means that the remote system will not send Redirects." In version -08 Section 2 it's simplified as: "Regarding the selection of IP address, the rules stated in Section 4 of [RFC5881] are applicable to the encapsulation of an Unaffiliated BFD Echo packet." In version -09/-10 Section 2 it's changed to: "An Unaffiliated BFD Echo packet follows the same encapsulation rules as for a BFD Echo packet as specified in Section 4 of [RFC5881]." As far as I know, different implementations used different source address and/or destination address, among them one selection is the loopback address of the local system. So my proposal is to add the above text of version -08 to Section 1, at the same time remain the above text of version -10 as is. # Section 1 s/Full BFD protocol capability with affiliated Echo function/Full BFD protocol capability in the local and adjacent systems/ ? As the term ‘affiliated’ is defined in a subsequent paragraph and is not defined in RFC 5880. [XM]>>> Would "Full BFD protocol capability with adjunct Echo function" resolve the issue? Because in a subsequent paragraph it says "The former scenario is referred to as affiliated BFD Echo", if "Echo function" is removed, then there is inconsistency too. In `BFD Echo-Only method without full BFD protocol capability` should “in the adjacent system” be added ? [XM]>>> Considering "without full BFD protocol capability" applies to the local system too, I suggest to remain it as is. Does it make sense to refer to an expired draft, draft-wang-bfd-one-arm-use-case-00 ? Expiration was in 2020... [XM]>>> Will remove the reference to draft-wang-bfd-one-arm-use-case. s/This document describes the use/This document specifies the use/ It is a standard track document after all ;-) [XM]>>> Make sense. :-) # Section 2 Suggest using aasvg for nicer picture in rendering [XM]>>> It took me some time to figure out how to use aasvg. Now it works. Will include both ASCII-art and SVG in the xml (ASCII-art for plaintext and SVG for HTML/PDF). About figure 1, unsure whether “interface 1” adds anything, suggest removing (same for the top “Device A” and “Device B”). [XM]>>> OK. Will remove "interface 1" and the top "Device A" and "Device B". s/with zeroed "Your Discriminator"/with zeroed "Your Discriminator" field/ [XM]>>> OK. s/which is conformed to/which is conform to/ ? [XM]>>> OK. As I am not an English speaker, I wonder whether “with a certain value” is really the appropriate wording. [XM]>>> Me neither. As I recall, "with a certain value" was suggested by Jeff Haas who is an English speaker. :-) The use of SHOULD should come with explanation of what happens if the SHOULD is bypassed (i.e., the previous issue of memory disclosure should be moved here). [XM]>>> OK. Will copy the previous issue of memory disclosure here. At the end of this section, the BFD fields are not enclosed in double quotes, they should be for clarity as well as to be consistent with the previous text. [XM]>>> OK. Will enclose each BFD field in double quotes. # Section 3 Bear with my lack of expertise in BFD, but can this be achieved `Demand mode MUST NOT be active if the session goes Down`? [XM]>>> I checked the old versions and found this sentence was added in version -03. Then I checked RFC 5880 and didn't find explicit text on this point. So, in order to avoid potential confusion, I propose to change the text as below. OLD: In Asynchronous mode, if the session goes Down, the transmission of Echo packets (if any) ceases, and the transmission of Control packets goes back to the slow rate. Demand mode MUST NOT be active if the session goes Down. NEW: In Asynchronous mode or Demand mode, if the session goes Down, the transmission of Echo packets (if any) ceases, and the transmission of Control packets goes back to the slow rate. # Section 4 Unsure whether it brings any value, either delete this applicability section or move it as a subsection of the introduction ? [XM]>>> Agree to delete this applicability section. # Section 5 As I wrote above, it is unclear for me (and probably many readers) what are the src/dst addresses of the IP packets, i.e., I cannot understand whether uRPF must be disabled or not. => an addressing considerations section is welcome with some examples. [XM]>>> Please see above my proposal. For uRPF, I believe it must be disabled unless it's ensured that the forward link the reverse link between the two systems are different, which is a corner case in my view. About the GSTM, as the technique clearly specifies that the adjacent system does not implement BFD, how can this document require that looping is only done with TTL/HL=255 ? [XM]>>> Good point! I propose to relax the two requirements on the adjacent device as below. OLD: In order to mitigate the potential reflector attack by the remote attackers, or infinite loop of the Unaffiliated BFD Echo packets, it's RECOMMENDED to put two requirements, also known as Generalized TTL Security Mechanism (GTSM) [RFC5082], on the device looping Unaffiliated BFD Echo packets, the first one is that a packet SHOULD NOT be looped unless it has a TTL or Hop Limit value of 255, and the second one is that a packet being looped MUST NOT reset the TTL or Hop Limit value to 255, and MUST use a TTL or Hop Limit value of 254. NEW: In order to mitigate the potential reflector attack by the remote attackers, or infinite loop of the Unaffiliated BFD Echo packets, it's recommended to put two requirements, also known as Generalized TTL Security Mechanism (GTSM) [RFC5082], on the device looping Unaffiliated BFD Echo packets, the first one is that a packet should not be looped unless it has a TTL or Hop Limit value of 255, and the second one is that a packet being looped must not reset the TTL or Hop Limit value to 255, and must use a TTL or Hop Limit value of 254. The two requirements are OPTIONAL for the implementations complied to this specification. And the prerequisite for the two requirements to be achieved is that the adjacent device is able to know what it loops are Unaffiliated BFD Echo packets, by comparing the ingress and egress interface, and necessary provisioning. RFC 8704 does not define a strict mode uRPF, so, remove this reference. [XM]>>> OK. Will remove the reference to RFC 8704. Best Regards, Xiao Min
