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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 03 Jul 2018 13:21:22 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-bfd-yang-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 2.1 describes a scheme wherein an IGP may generate events that
cause BFD sessions to be created/destroyed; this effectively is proxying
commands from IGP over the local BFD API, which brings the authentication
and authorization of the IGP into scope, even if the local BFD
configuration access is authenticated.  (That is, the proxying component is
always authenticated, but now bears responsibility for performing
authentication/authorization/sanity checks on commands before proxying
them.)  Since IGP security is a topic for elsewhere, the changes to this
document seem scoped to documenting the requirements on the IGP/local proxy
for these checks, and arguably for only allowing authenticated IGP events
to create authenticated BFD sessions (though arguably not as well, for the
latter, since this is a YANG model document and not an architecture
document).

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm not very familiar with YANG notifications; is there a risk that they
can be abused as a DoS attack vector on the notification recipient by an
attacker (e.g., by causing a flapping series of state transition events or
by creating/destroying many sessions)?

Regarding the Security Considerations:

It's unclear whether local-multiplier, the various intervals, and
authentication are the only nodes that merit mention for every
per-forwarding-path-type module.  For example, source/destination addresses
could be modified to direct traffic at unwitting recipients, and the
key-chain and meticulous settings also seem security-related.

Similarly, read-only access to the discriminators (and
key-chain/authentication information) could make it easier for an attacker
to spoof traffic.

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 4 Jul 2018 03:20:42 +0000

Hi,

Thanks for the review. Please see inline <RR>.

On 2018-07-03, 4:21 PM, "Benjamin Kaduk" <[email-masked]> 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?

<RR> To do that an attacker would need to e.g. access the local device or the directly connected devices to cause those BFD state transitions.

    
    Similarly, read-only access to the discriminators (and
    key-chain/authentication information) could make it easier for an attacker
    to spoof traffic.
<RR> Good point. I will add those nodes.

Regards,
Reshad.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 3 Jul 2018 22:56:49 -0500

>     https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/

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).

Probably not the most effective vector available, then.

> <RR> Good point. I will add those nodes.

Thanks!

-Benjamin

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Jul 2018 19:46:22 -0400

> access mechanism (since the boilerplate covers SSH/TLS for

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.

-- Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 11 Jul 2018 02:17:45 +0000

On 7/10/18, 7:46 PM, "Rtg-bfd on behalf of Jeffrey Haas" <[email-masked] on behalf of [email-masked]> wrote:

    

    

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

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 11 Jul 2018 13:25:52 +0000

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)" <[email-masked]> wrote:

    

        

    
    
    Thanks,
    Acee (LSR WG Co-Chair) 

        -- Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 11 Jul 2018 14:10:33 +0000

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)" <[email-masked]> wrote:

    Hi,

    
    Regards,
    Reshad.

        

            

            

        Thanks,
        Acee (LSR WG Co-Chair) 

            -- Jeff

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 11 Jul 2018 14:31:02 +0000

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)" <[email-masked]> wrote:

    Hi Reshad, 

    Thanks,
    Acee 

        Hi,

        
        Regards,
        Reshad.

            

                

                

            Thanks,
            Acee (LSR WG Co-Chair) 

                -- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 11 Jul 2018 10:36:49 -0400

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) <[email-masked]> wrote:
> 
> Hi Acee,
>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 11 Jul 2018 14:57:50 +0000

Jeff, which part do you consider overkill? Is it the statement "NACM rules on IGP BFD configuration be at least as strict as BFD since the IGPs are instantiated BFD sessions"? That should still allow "permit BFD to be de-configured for protocols without also giving operators permission to similarly de-configure the underlying client protocols"?

Regards,
Reshad.

On 2018-07-11, 10:36 AM, "Jeffrey Haas" <[email-masked]> wrote:

    
    
    -- Jeff

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 11 Jul 2018 10:02:41 -0500

"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

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 11 Jul 2018 11:32:18 -0400

Benjamin,

> "may be overkill in some circumstances" sounds exactly like an RFC 2119

Putting it slightly a different way, I am always wary of trying to embed too
much operational and security wisdom in documents for the following reasons:
- What's wise in one set of circumstances may not be in another.  By being
  proscriptive, you may lead to implementations that lack necessary
  flexibility.
- You're imposing a level of fate binding between mechanisms that may
  contravene desired behaviors from some operators that have split
  operational roles.

[...]
> mechanism (IGP) for a subset of the YANG module,

This is perhaps my personal disconnect.

Much of the point of providing a common configuration grouping for BFD for
client protocols was to encapsulate, "I'm a client of BFD, here's my
parameters".  An implementation is free to use the "please use bfd with
these parameters for my protocol" or perhaps ignore them.  But in
circumstances that an operator may wish to limit access to protocol BFD
behavior, it has the existing ability in NACM to enforce its policy on those
BFD nodes within the protocol tree.

What I feel you're saying is we need to call special attention to these
instantiations that may be imported by some module.  

What I'm confused about is why such an import is any more special than any
other import from another module.

-- Jeff

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 15 Jul 2018 08:04:50 -0500

>   proscriptive, you may lead to implementations that lack necessary

In my opinion, including guidance with the supporting motivation suffices
to leave flexibility for unanticipated future cases with differing needs.

>   contravene desired behaviors from some operators that have split

If the stated motivation does not apply to operators with such split roles,
do we not think they are smart enough to see that the prerequisite is not
met and ignore the advice?

> other import from another module.

I've been trying to wrap my head around your explanation for the past few
days, and I'm not sure I'm succeeding at it.  The only reason I'm raising
this point with this document is because there is text in the document like
"[f]or example, when a new IGP peer is discovered, the IGP would create a
BFD session to the newly discovered peer and similarly when an IGP peer
goes away, the IGP would remove the BFD session to that peer."  Imagine if
I was writing a document about a device that controls a physical door, and
the usual way to operate the device is to manually enter a PIN while
physically in front of the door.  If I also said "some people expose this
door-unlocking device to the internet and accept unlock requests over
HTTP", that would be incredibly unresponsible of me unless I added some
extra qualifier.  Perhaps it would be "and these people are crazy", or
perhaps "but HTTP itself is insecure, so in such situations TLS ought to be
used with mutual authentication, authorization checks for the party
requesting unlocking, and the best practices from RFC 7525".

So, in my head, I see this document as using a not-quite-throwaway example
to make a point about the limitations of the main focus of the document,
and should properly qualify the different security properties of that
example.  Your description above still reads to me as if it's focusing on
YANG modules not specified in this document but that also use the same BFD
grouping.  In such a case, when the NACM applies, isn't that still going
through normal management paths for that respective YANG module?  I'm still
trapped in a rut thinking about "received IGP packet from the network that
instantiates a new IGP session; as a side effect instantiate a BFD session
as well", where the incoming IGP packet is just the IGP implementation and
not a "management function" per se.

-Benjamin

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 26 Jul 2018 00:16:05 +0000

Hi Benjamin and Jeff,

Following our discussion in Montreal, would the following, or something along these lines, be OK with you in the Security Considerations section.

   When BFD clients are used to modify BFD configuration (as described
   in Section 2.1), any authentication and authorization for the BFD
   configuration changes have to take place in the BFD clients.  For
   example, if the BFD client is an IGP then the IGP SHOULD be
   authenticated. Also, consideration should be given to the access control of
   the BFD clients.

Regards,
Reshad.

On 2018-07-15, 9:05 AM, "Benjamin Kaduk" <[email-masked]> wrote:

    

    

    -Benjamin

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 30 Jul 2018 09:41:41 -0500

Hi Reshad,

>    authenticated. Also, consideration should be given to the access control of

I can't speak for Jeff, but I think this is edging closer to the bits he
doesn't like.  (It seems to capture the topics I had in mind just fine,
though.)

>From our discussion in Montreal, it seemed like we might end up at
something more like:

When BFD clients are used to modify BFD configuration (as described
in Section 2.1), the BFD clients need to be included in an analysis of
the security properties of the BFD-using system (e.g., when considering the
authentication and authorization of control actions).  In many cases, BFD
is not the most vulnerable portion of such a composite system, since BFD is
limited to generating well-defined traffic at a fixed rate on a given path;
in the case of an IGP as BFD client, attacking the IGP could cause more
broad-scale disruption than (de)configuring a BFD session could cause.

-Benjamin

---

From: PFFC JHAAS <[email-masked]>
Date: Mon, 30 Jul 2018 16:45:35 -0400

Benjamin,

Your proposal would be fine. It basically says be mindful of the relationship. 

Jeff

> On Jul 30, 2018, at 10:41, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi Reshad,
>