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

[Benjamin Kaduk <[e-mail]>]

On Wed, Jul 04, 2018 at 03:20:42AM +0000, Reshad Rahman (rrahman) wrote:
> Hi,
> 
> Thanks for the review. Please see inline <RR>.
> 
> 
> On 2018-07-03, 4:21 PM, "Benjamin Kaduk" <[e-mail]> wrote:
> 
>     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).
> <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).

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

Probably not the most effective vector available, then.

>  
>     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.
> <RR> Good point. I will add those nodes.

Thanks!

-Benjamin