Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

"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 the IGP
scheme(s) (if any) that are used for BFD configuration are also included in
the evaulation.  This doesn't imply an adversarial relationship between two
things running on the same box -- it just means that if I want to impose a
policy about who can make what BFD changes (or similar), then I have to
consider the interactions with the IGP as well as the direct on-box change
mechanisms.

To frame the same idea in a different fashion, we have this nice security
considerations boilerplate for YANG modules, talking about how the usual
access methods are NETCONF/RESTCONF, with MTI secure transport of ssh/TLS.
The scheme being described here is effectively providing a new access
mechanism (IGP) for a subset of the YANG module, and so the security
considerations should talk about the corresponding "secure transport"
options for that new access mechanism, at least to mention that there
exist considerations regarding security of transport for the IGP access
mechanism.  (The "MTI secure transport" options for IGPs are not really
something I want to bring into scope here, because this document has to
work with what's available.)

-Benjamin


On Wed, Jul 11, 2018 at 10:36:49AM -0400, Jeffrey Haas wrote:
> 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 experiencing issues that are leading to false negatives and tearing down valid sessions.
> 
> While the above example would seem unusual, it was more of a concern in the more subtle use cases for BFD-on-LAG where links may be managed by one provisioning group and protocols by another.
> 
> -- Jeff
> 
> > On Jul 11, 2018, at 10:31 AM, Reshad Rahman (rrahman) <[e-mail]> wrote:
> > 
> > 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)" <[e-mail]> 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 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)" <[e-mail]> wrote:
> > 
> >        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 dveice, which I agree would be preposterous.
> > 
> >        Regards,
> >        Reshad.
> > 
> >        On 2018-07-10, 10:17 PM, "Acee Lindem (acee)" <[e-mail]> wrote:
> > 
> > 
> > 
> >            On 7/10/18, 7:46 PM, "Rtg-bfd on behalf of Jeffrey Haas" <[e-mail] on behalf of [e-mail]> wrote:
> > 
> >                On Tue, Jul 03, 2018 at 10:56:49PM -0500, Benjamin Kaduk wrote:
> >> On Wed, Jul 04, 2018 at 03:20:42AM +0000, Reshad Rahman (rrahman) wrote:
> >>> <RR> I am not 100% sure I understand the point being made. Is it a question of underlying the importance of having the IGPs authenticated since the IGPs can create/destroy BFD sessions via the local API?
> >> 
> >> That's the crux of the matter, yes.  Since (in this case) the IGP state
> >> changes are being translated directly into BFD configuration changes,
> >> the NETCONF/RESTCONF authentication is not really used.  So, any
> >> authentication/authorization decisions that are made must be on the basis
> >> of authentication at the IGP level.  This does not necessarily mean a hard
> >> requirement for IGP authentication, though using unauthenticated IGP would
> >> then be equivalent (for the purposes of this document) to allowing
> >> anonymous NETCONF/RESTCONF access.
> >> 
> >> I'd be happy to just have a note in the security considerations that "when
> >> BFD clients such as IGPs are used to modify BFD configuration, any
> >> authentication and authorization for the configuration changes take place
> >> in the BFD client, such as by using authenticated IGPs".  But feel free to
> >> reword in a better fashion; this is really just about acknowledging the new
> >> access mechanism (since the boilerplate covers SSH/TLS for
> >> NETCONF/RESTCONF).
> > 
> >                I must admit to being somewhat perplexed by the request here.
> > 
> >                In the cases where BFD as a top level module is not the creator of a BFD
> >                session, you seem to be concerned that BFD can be used to attack a resource
> >                by spoofing that non-BFD client.
> > 
> >                While this is perhaps logically true, it also means that you have a far
> >                greater problem of being able to spoof the underlying BFD clients.  To give
> >                some real-world examples:
> >                - BGP typically requires explicit configuration for its endpoints.
> >                - Both OSPF and ISIS will require a matched speaker with acceptable
> >                  configuration parameters for a session to come up.
> >                - Static routes with BFD sessions will require explicit configuration.
> > 
> >                In each of these cases, a client protocol that also wants to use BFD, the
> >                simple spoofing of the protocol endpoints is already a massive disaster
> >                since it will allow injection of control plane or forwarding state into the
> >                device.  This is so much worse than convincing a BFD session to try to come
> >                up with its default one packet per mode that ... well, I'm boggled we're
> >                even talking about this. :-)
> > 
> >                My request would be that we not complicate the security considerations of
> >                this module for such cases.
> > 
> >            I agree. This is DISCUSS is just preposterous - imposing some sort of security boundary between the IGP modules and the BFD module running on the same networking device.
> > 
> >            Thanks,
> >            Acee (LSR WG Co-Chair) 
> > 
> > 
> > 
> >                -- Jeff
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
>