draft-ietf-bfd-optimizing-authentication-13 nits

[Jeffrey Haas <[e-mail]>]

Authors,

Since secure sequence numbers is heading toward WGLC, it's time to refresh this document and review it vs. secure sequence numbers, and bfd stability.

-----

From Introduction and some confusion about configuration and operational state:

"This document also proposes that all BFD control packets which signal a significant change MUST be authenticated if the session's bfd.AuthType is non-zero. Other BFD control packets MAY be transmitted and received without the A bit set."

There's a bit of semantic confusion here.  bfd.AuthType is what we use as our state and what we put in our packet.  And similarly, we're trying to say here that "authentication may not be required for some packets".

Part of where this is potentially confusing is that these mechanisms are documenting changes from one auth type to the other.

This means we have, leveraging management framework terminology, configuration state that represents "start with authentication X, which will use method 1 that goes into bfd.AuthType and user method 2 which also goes into bfd.AuthType".  This also has implications when we have this bit of composite configuration with regards to authentication that isn't expected (i.e. NULL when secure seq is configured) needs to be addressed.

For operational state, reflecting the active type may be fine, but reflecting the hybrid configuration state is also necessary.



One way to work through how to adjust the text is consider what the updates to the YANG module might look like.

1.2:
s/a demand model/a demand mode/

"configured interval" probably needs to be more specific to this mechanism.  In particular, this is the interval for how long before we retry strong authentication.

2. Authentication Mode:

The text in this section indicates that there are circumstances where no authentication (a-bit is off) is permissible.  However, the text then moves to discuss NULL authentication, which is authentication that still carries an a-bit, and has contents. This is likely from earlier work prior to realizing we want some form of anti-replay attack.

I suspect the correct thing to do here is move all text toward discussing the "non-authenticated" mode as the less encumbered authentication, of which this document defines the NULL method. 

The text for secure sequence numbers also is now incorrect since the mechanism has evolved.

3. NULL Auth Type.

The main text here in need of updating is the sequence numbers.  As we've worked through in the discussions for secure sequence numbers, we want the sequence numbers to be preserved across authentication mechanisms.

Is the answer to take the text we have in secure sequence numbers covering this detail and move them to this document?

-- Jeff