Hi Jeff, thank you for your thoughtful response. Please find my notes below under the GIM>> tag.
Regards, Greg On Thu, Apr 6, 2023 at 7:36 AM Jeffrey Haas <[email protected]> wrote: > Greg, > > > On Mar 27, 2023, at 1:40 AM, Greg Mirsky <[email protected]> wrote: > > Dear Authors, > I read the latest version of the draft. I appreciate your work on > improving its readability. I have several concerns and appreciate your > consideration: > > - It appears like the document defines the format of the Echo message. > As I understand the RFC 5880, the format of the Echo message is not > specified in the RFC 5880. It seems like by defining the format in this > document, you affect RFC 5880 compliance of implementations that do support > RFC 5880 as it exists today. > > One way to alternatively view this is we're documenting what one > implementation puts in its Echo packets. This draft does not try to > require that all BFD Echo implementations use these procedures. > GIM>> That is an interesting perspective. If that is the purpose of this specification, then the amount of updates it requires seems excessive. On the other hand, if the group agrees to reflect such intention in the draft, it will alleviate my concern. Furthermore, if that is the position explicitly communicated in the draft, making it Experimental seems like the next logical step. > > > - The draft, in my opinion, significantly changes the architecture of > the BFD, as it is defined in RFC 5880. I believe that characterizing Echo > as a function stresses its dependency from a BFD mode, Asynchronous and > Demand. The changes proposed in this draft are very extensive and severely > affect the existing architecture of BFD by setting the Echo function on > par, unrelated with the BFD modes. > > > Interesting. My view has been that this mechanism leverages existing BFD > Async procedures to avoid trying to completely invent new mechanisms for > the unafilliated case. Where I might have some level of agreement with > your point is this "mode" needs to be clearly defined from a configuration > standpoint. For example, how would it manifest in YANG? > GIM>> It seems that we have different views. I consider the limitation of using the Echo function, specified in RFC 5880, only after the session reaches the Up state as a part of the BFD security mechanism. Personally, I would encourage not to use a well-known UDP port for the type of operation described in the draft. I think it would be more secure to use a port number from the dynamic range. Defining that function as a new optional BFD function without severely updating RFC 5880, in my opinion, is a safer path. > > > - Also, I think that the normative language in the last paragraph of > the Secrity Considerations sections are too soft. Currently used > recommendation level, in my opinion, is insufficient and should be brought > to the requirement level. I.e., I propose s/RECOMMENDED/MUST/ and s/SHOULD > NOT/SHALL NOT/ > > > I'd recommend that you show the explicit sections you want updated. > GIM>> Thank you for pointing that out for me. Below are the proposed updates: OLD TEXT: In order to mitigate the potential reflector attack by the remote attackers, or infinite loop of the BFD Unaffiliated Echo packets, it's RECOMMENDED to put two requirements, also known as Generalized TTL Security Mechanism (GTSM) [RFC5082], on the device looping BFD Unaffiliated 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 TEXT: In order to mitigate the potential reflector attack by the remote attackers, or infinite loop of the BFD Unaffiliated Echo packets, this specification puts two requirements, also known as Generalized TTL Security Mechanism (GTSM) [RFC5082], on the device looping BFD Unaffiliated Echo packets, the first one is that a packet MUST 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. Using version -06: > - I would not personally suggest that the RECOMMENDED for authentication > turn into a MUST. BFD Authentication simply isn't used in enough > circumstances to try to turn this into the default case, especially when > the intent of this feature is to deal with systems that don't have a > matching BFD on the opposite side. > - I not super supportive of the SHOULD NOT for the TTL 255 loop being > upgraded to SHALL NOT. This will likely make a number of existing > deployments of this feature non-conformant. > > Please note that I expect to have a repeat of this conversation with the > security AD during review. So, your comments are apropos. > > -- Jeff > >
