Comments on draft-ietf-bfd-generic-crypto-auth

["Nobo Akiya (nobo)" <[e-mail]>]

Hi Authors,

I have reviewed your draft (draft-ietf-bfd-generic-crypto-auth ), comments below.
Since document is nearing expiration, perhaps you can address some of these comments and re-publish?


(1) Abstract

s/arbitary/arbitrary/


(2) Section 2

Before listing "Not Before Time" and "Not After Time", it'll be great if the document can provide some words to better transition from previous paragraph. 


(3) Section 3.3

[snip]
   The device MUST fill the Auth Type and the Auth Len fields before the
   authentication data is computed.  The Sequence Number field MUST be
   set to bfd.XmitAuthSeq.
[snip]

The paragraph is slightly confusing wrt whether Sequence Number field need to be set before or after authentication data is computed. It'll be good to clarify this.


(4) Section 3.4, second paragraph

[snip]
   If the Authentication Present (A) bit is set in the packet header and
   the receiver will try to find a appropriate BFD SA in its local key
   table to process the packet.
[snip]

I believe you meant to say:

   If the Authentication Present (A) bit is set in the packet header and
   Auth Type is TBD1 or TBD2, the receiver is to find an appropriate BFD
   SA in its local key table to process the packet.

See below for usage of TBD1/TBD2.


(5) Section 3.4, fourth paragraph

Is it better to say "unsigned 64 bit circular number space" here, or keep it as "unsigned 32 bit circular number space"? If latter, then the document should clarify that it's low order 32 bits.


(6) Section 3.4, sixth paragraph

[snip]
  In such a case, an error event SHOULD be logged.
[snip]

Such log could become DoS attack point? Rate limiting of such log is outside the scope of this document, but it could be beneficial to explain this in the Security Considerations section ... optional comment though.


(7) IANA Considerations

Indeed values 6 and 7 are next, but it's technically not correct to just use them [yet].
Can we use TBD1 and TBD2? If someone is implementing and early allocation is required, then we can do that.

Also it'll be beneficial for this section to clearly describe what is needed from where. Maybe something like:

  IANA is requested to assign two authentication types from the
  "BFD Authentication Types" sub-registry within the "Bidirectional
  Forwarding Detection (BFD) Parameters" registry.

  Address  BFD Authentication Type Name             Reference
  -------  ---------------------------------------  -------------
     TBD1  Cryptographic Authentication             this document
     TBD2  Meticulous Cryptographic Authentication  this document


(8) Security Considerations

s/reestablishing/re-establishing/


(9) References

RFC5880 should be a normative reference instead of informative, as document is even referencing a variable from RFC5880 (ex: bfd.XmitAuthSeq).


-Nobo