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
