Hi Jeff,
Many thanks for your insightful review and comments Please see inline my responses tagged with <XM>. Sorry for the late response. Best Regards, Xiao Min 原始邮件 发件人：JeffreyHaas 收件人：draft-ietf-bfd-unaffiliated-e...@ietf.org; 抄送人：rtg-bfd@ietf.org; 日 期 ：2021年04月06日 05:41 主 题 ：Comments on draft-ietf-bfd-unaffiliated-echo-01 [Speaking as an individual contributor] Authors, Attached, please find an rfcdiff containing some suggested edits to your draft. The intent is to try to add clarity to the document. If you would find it helpful, I can also forward a patch vs. the published -01 xml. <XM> I find it very helpful. Much appreciated if you can forward a patch. If you're interested to be co-author of this draft, please let the authors know. --- Additionally, there are several points of discussion for you and perhaps the Working Group about this proposal: The changes recommended in section 2 are clear, but difficult to see what content each change brings. IETF has a mixed culture about how to implement such changes in a document. This draft does so by copy, paste, and change. If we can collectively find a better way to highlight the differences without being so wordy, that would be good. <XM> I did some study on this issue. Currently what I can suggest is to add some flags like <Del> </Del> <Add> </Add> into the text, avoiding copy paste. Of course it would be better if we can find a way to add strikethrough and italic/bold text. Alternatively, I know some people will be thrilled with the format you have chosen. :-) --- In section 3, the proposal effectively says that the BFD speaker is originating BFD Control packets in the Echo Packet mode. Since RFC 5880/5881 keeps the details about how Echo packets are made out of scope, but does provide some guidance for security, this is acceptable. <XM> Thanks for your understanding. I would suggest highlighting that the validation procedures of RFC 5880 are used. <XM> Will add some text as you suggest. The intent appears to be "re-use existing BFD Control procedure as much as possible", which means re-use of code. Good! However, this leads to some interesting issues. One example is that since a BFD speaker is "hearing itself" rather than having the remote device actually speaking BFD, some things are wrong. As an example, the Discriminator procedures in the BFD Async mode can't apply. The remote won't pick its own and swap it! I'd thus recommend some text about this. <XM> Will add some text as you recommend. RFC 5880, section 5, has the following to say about authentication: : Some form of authentication SHOULD be included, since Echo packets : may be spoofed. Some procedural text related to authentication and the contents of the packets is needed. <XM> Will add some text as you require. The desired min TX and required min RX intervals should be populated with something, even if it's 1 second. And perhaps some advice that we're ignoring the values in these fields. <XM> Will add some text as you suggest. --- Your last set of changes in section 2 attempts to adjust the text covering sending Echo packets. When the implementation transitions to sending them at the desired echo speed is a little ambiguous since the role of Control packets is on the Echo port and in Echo packets. One possible solution is that the Echo rate is not used until the BFD state machine moves to the Up stage as per normal RFC 5880 procedures. However, that involves running the state machine from its usual slow rate of 1 second until we transition to Up, and reverting to the slow rate when it goes to Down/AdminDown. <XM> Agree to your proposed solution which follows the normal RFC 5880 procedures. Will add some text on that. This text will be tricky to do since we're blending the Control mode in the Echo packets. <XM> Yes, you're right. Will provide some text for your further review. A strong goal of this is what happens when the remote is not echoing packets back to us properly. We do not want the BFD echo sender to transition directly to a denial-of-service condition, especially since the TTL is set to 255. The usual slow rate until Up at least mitigates the sender's role in this problem. Note that the TTL receive check on the receiver will be at least 254 due to the loop. This reduces the effectiveness of GTSM, and potentially is an issue for the loop procedure. --- Does this mechanism ever go AdminDown? What does it do, if so? <XM> Prefer to leave AdminDown out of Unaffiliated BFD Echo, in which scenario AdminDown effectively means removal of BFD echo session. If you agree, we'll add some text on it. --- Suggestion: Move the following text in some form to the top of section 3: : After receiving the BFD Echo packets sent from device A, the one-hop- : away BFD peer device B immediately loops them back by normal IP : forwarding, this allows device A to rapidly detect a connectivity : loss to device B. Being able to do this is a requirement for the feature, and the easy one to articulate. It provides the motivations for the rest of the section. <XM> Will do as you suggest --- Security Considerations: The URPF comments in the security considerations is really intended to say "you can't do urpf for this feature". It might be easy to just say that more directly. <XM> OK, will tweak the text to make it concise. The requirement for this feature is that the receiver is willing to loop UDP packets on port 3785. In the simplest possible implementation, this can become an open reflector attack and is probably one of the larger security considerations our Transport and Security Area Directors and their Directorates will flag. There are two mitigations that can help with this, although it's an open question whether the host stacks supplying the loop beheaviors can support them: - A packet SHOULD NOT be looped unless it has a TTL of 255. - A packet being looped MUST NOT reset the TTL to 255, and SHOULD use a TTL of 254. The motivation for this is firstly to respect GTSM procedures on reception and prevent remote attackers from exploiting the loop. This should be able to be implemented using a firewall at the very least. Secondly, retransmiting with a fresh TTL of 255 can potentially cause a set of looping devices to infinitely loop traffic. A TTL of 254 is the largest TTL that can prevent such infinite loops. A lower TTL widens the window for targeting attack traffic to the BFD speaker originating the Echo traffic. <XM> Agree to the two mitigations, it seems work, although I have no idea whether the host stacks can support them. Will add text on it, and then ask for more review and discussion. --- Comment to note for later purposes: the BFD state variables for the yang module will need to be defined for these changes. Oddly, we never got around to doing a central IANA registry for such things. -- Jeff
