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)" <a...@cisco.com> 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)" <rrah...@cisco.com> 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)" <a...@cisco.com> wrote:
        
            
            
            On 7/10/18, 7:46 PM, "Rtg-bfd on behalf of Jeffrey Haas" 
<rtg-bfd-boun...@ietf.org on behalf of jh...@pfrc.org> 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
                
                
            
            
        
        
    
    

Reply via email to