Subject: Re: Comments on secure sequence number draft

From: Ashesh Mishra <[email-masked]>
Date: Sun, 1 Apr 2018 14:07:03 +0000

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 <[email-masked]> on behalf of Jeffrey Haas <[email-masked]>
Sent: Wednesday, March 28, 2018 10:03:35 AM
To: [email-masked]; [email-masked]
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