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

["Reshad Rahman (rrahman)" <[e-mail]>]

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