Benjamin,
On Wed, Jul 11, 2018 at 10:02:41AM -0500, Benjamin Kaduk wrote:
> "may be overkill in some circumstances" sounds exactly like an RFC 2119
> SHOULD, does it not?
Putting it slightly a different way, I am always wary of trying to embed too
much operational and security wisdom in documents
"may be overkill in some circumstances" sounds exactly like an RFC 2119
SHOULD, does it not?
Anyway, we seem to be converging on what I was intending to ask for
(thanks, Reshad!), namely that when evaluating the security considerations
for configuring the BFD module, the security considerations of
Jeff, which part do you consider overkill? Is it the statement "NACM rules on
IGP BFD configuration be at least as strict as BFD since the IGPs are
instantiated BFD sessions"? That should still allow "permit BFD to be
de-configured for protocols without also giving operators permission to
simil
Even that may be overkill in some circumstances.
Consider the case where an operator may decide that they'll permit BFD to be
de-configured for protocols without also giving operators permission to
similarly de-configure the underlying client protocols. Examples of this may
be that BFD is expe
Hi Acee,
That and a statement saying the BFD clients should be authenticated.
Regards,
Reshad.
On 2018-07-11, 10:10 AM, "Acee Lindem (acee)" wrote:
Hi Reshad,
Ok - so are you saying that all that is being asked for is that the NACM
rules on IGP BFD configuration be at least as
Hi Reshad,
Ok - so are you saying that all that is being asked for is that the NACM rules
on IGP BFD configuration be at least as strict as BFD since the IGPs are
instantiated BFD sessions? I'd be ok with that.
Thanks,
Acee
On 7/11/18, 9:25 AM, "Reshad Rahman (rrahman)" wrote:
Hi,
Hi,
My read on the DISCUSS is not just wrt spoofing of BFD clients but also making
sure that the proper access restriction (NACM) is used for the BFD clients.
I didn't interpret Benjamin's comments as requiring a security boundary between
BFD clients (BGP, IPGPs) and BFD running on the same dv
