Hi Jeff,
You noted a couple if great questions. Since there aren't any more fields left
in the BFD packet or TLVs to overload for this function (the AUTH TYPE field,
which is the only usable field for overloading, is being used for defining new
TLVs so we didn't want to use it as this method doesn't change the packet
format), the clean way to configure secure sequence numbers is by coordinating
configuration on the two end-points (the keys will need to be configured on
each end point, so the knob to turn the feature on can reside there as well).
It would have been infinitely simpler if there was an "experimental" or "future
use" field in the BFD packet :)
I'll defer the YANG question to our YANG expert author, Mahesh.
I'll add text to the security considerations.
--
Ashesh
________________________________
From: Rtg-bfd <rtg-bfd-boun...@ietf.org> on behalf of Jeffrey Haas
<jh...@pfrc.org>
Sent: Wednesday, March 28, 2018 10:03:35 AM
To: draft-ietf-bfd-secure-sequence-numb...@ietf.org; rtg-bfd@ietf.org
Subject: Comments on secure sequence number draft
Authors,
A few comments on your draft in no particular order:
Operational Considerations:
- How do you go about enabling this feature?
+ It's independent of, but recommended for, optimizing BFD authentication..
- What are the yang considerations?
+ Similar point - changes to the yang model for optimizing authentication
likely need this as a separate knob.
- The Security Considerations section is empty. That needs to be fixed.
-- Jeff
