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. 


´╗┐On 7/11/18, 9:25 AM, "Reshad Rahman (rrahman)" <rrah...@cisco.com> wrote:

    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 
    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.
    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) 
            > > <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 
            > changes are being translated directly into BFD configuration 
            > 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 
            session, you seem to be concerned that BFD can be used to attack a 
            by spoofing that non-BFD client.
            While this is perhaps logically true, it also means that you have a 
            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 
            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 
            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 
            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.
        Acee (LSR WG Co-Chair) 
            -- Jeff

Reply via email to