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

["Acee Lindem (acee)" <[e-mail]>]

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