Reviewer: Adrian Farrel Review result: Has Issues Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Cheers, Adrian Document: draft-ietf-bfd-unaffiliated-echo Reviewer: Adrian Farrel Review Date: 2024-09-26 IETF LC End Date: 2024-10-09 Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. This draft is generally in a good condition and is readable. There are a few issues of English usage that the RFC Editor will clean up. Include anything else that you think will be helpful toward understanding your review. I wish that there was discussion of implementation status in the draft. = Minor Issues = The Abstract helpfully says "updates 5800", but it also needs to say how. For example... This document updates RFC 5880 by defining a new method BFD Echo-Only method without requiring an implementation to support the full BFD protocol. --- Similar to the previous point, the Introduction needs to indicate the update. For example... OLD This document specifies the use of the Unaffiliated BFD Echo over IPv4 and IPv6 for single IP hop. NEW This document updates [RFC5880] by defining a new method BFD Echo-Only method without requiring an implementation to support the full BFD protocol. It describes the use of the Unaffiliated BFD Echo over IPv4 and IPv6 for a single IP hop. A full description of the updates to [RFC5800] is provided in Section 3. END --- I know where you are going with the idea of an "Unaffiliated BFD Echo Session", but I find the concept a little peculiar because, well, it isn't really a session (especially as shown in Figure 1) because the remote end of the "session" doesn't even know that it exists. I think, therefore, you may need some explanatory text to say something like... An Unaffiliated BFD Echo Session is not actually a BFD session because there is no coordination of BFD protocol state between the two link ends: the remote end does not support BFD and so cannot engage in a BFD session. The initiator may regard the Unaffiliated BFD Echo Session as a BFD session within its implementation. [I know that the second paragraph of section 2 can imply the above, but I don't think it is explicit enough. So you might just insert my suggested text (with any edits you consider appropriate) before that paragraph.] Corresponding to this, I suggest you update Figure 1 as: Node A Node B +----------------+ +----------------+ | | | | | ------------| | | | |Unaffiliated| | | | | BFD Echo ---> | | | | Session | | | | | | Unaffiliated BFD Echo | | | | ------------------------------- BFD | | | | | packets | | | <------------------------------- looped | | ------------| | | | | | | | | | | +----------------+ +----------------+ BFD supported BFD not supported --- In section 2, I had to read a piece of text many times and then re-read RFC 5800 before I understood what you are saying. You have... For unaffiliated echo, a Unaffiliated BFD Echo session is created on device A, and the Unaffiliated BFD Echo session MUST follow the BFD state machine defined in Section 6.2 of [RFC5880], except that the received state is not sent but looped back from the remote system. Unaffiliated BFD Echo does not use the AdminDown state. I think the point is that the state transition events do not arise from BFD messages initiated by the peer BFD speaker, but come from BFD messages initiated at the local node and looped back by the remote node. So... For unaffiliated echo, a Unaffiliated BFD Echo session is created on device A, and the Unaffiliated BFD Echo session MUST follow the BFD state machine defined in Section 6.2 of [RFC5880], except that the received state is not extracted from BFD messages originated by the remote system, but from messages originated by the local system and looped back from the remote system. Therefore, Unaffiliated BFD Echo does not use the AdminDown state. Except (!) there is not an AdminDown state in the FSM in 5800. There is a DOWN state and an AdminDown state-transition event. I think it is the event that is not used because you would not send an unaffiliated echo to say "admin down". However: - I don't think you would send an unaffiliated echo to say "down" either - A timer pop would still put you into DOWN from INIT or UP - There has to be a way for the local operator to put the session into DOWN (that seems to be absent from the state machine in 5800), so it can probably stay absent here. --- Section 4, question... Could an attacker interpose themselves between the two nodes and perform loopback? Loopback is an easy function with no requirement to generate any additional security, so it is easier than impersonating a full BFD implementation. You should call out this as an attack vector. What would it cause to happen? I think it would mean that traffic would continue to be dropped until the IGP noticed the failure. Is there any way to protect against this? = Nits = Using "(s)" for optional plurals is unnecessary. English allows the plural to include the singular, so you can say, for example,... The faults can be on interfaces, data links, and even the forwarding engines. --- OLD BFD defines Asynchronous and Demand modes to satisfy various deployment scenarios. NEW BFD defines the Asynchronous mode and the Demand mode to satisfy various deployment scenarios. END --- OLD It also supports an Echo function to reduce the device requirement for BFD. NEW (I think) It also supports an Echo function to that reduces the level of BFD support required in device implementations. END --- OLD The former scenario is referred to as affiliated BFD Echo, which is not changed by this document in any way. The latter scenario is referred to as Unaffiliated BFD Echo, which is specified in this document. NEW The former scenario is referred to as "Affiliated BFD Echo", which is not changed by this document in any way. The latter scenario is referred to as "Unaffiliated BFD Echo", which is specified in this document. END --- It would be nice if Section 2 began with text, not direct into the figure. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
