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
