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

[Jeffrey Haas <[e-mail]>]

Ben,

On Wed, Dec 18, 2019 at 02:02:46PM -0800, Benjamin Kaduk wrote:
> On Wed, Dec 18, 2019 at 03:24:48PM -0500, Jeffrey Haas wrote:
> > This is a clean summary of the considerations.  At least a portion of the WG
> > seems to be comfortable with "test to the management VNI".  However, another
> > (smaller, I believe) portion were wanting to test one layer further in.
> 
> It is reassuring that I at least managed to summarize the situation
> tolerably.  Is it fair to say that testing "one layer further in" is a
> superset of what "test to the managemenet VNI" can do?

Fundamentally, this is all BFD.  The issue is almost always considerations
related to encapsulation.

The meta concern here is that if you test to the management VNI, the
operator has a lot of control over things that are clean from a security
perspective.

The minute you test one layer deeper, it's still the same thing... but you
now have a lot of sharp edges you have to worry about.

In all of these situations, the main consideration from a security
perspective and an encapsulation perspective is "don't step on the toes of
the user".  But that said, vxlan environments are provided to contain
tenants, have their own provisioning ecosystems, and security considerations
in how they are provisioned and operated.  As long as the security and
operational considerations are understood by the operator, they can decide
whether "testing one layer further in" gives them good benefit vs. the
additional security considerations.

And that said, two fundamental portions of BFD operations and security still
apply here:
- Discriminators need to be known to mess with existing sessions.  This
  means the main consideration for someone not in the tenant environment is
  privacy.  Such privacy is an overall consideration for vxlan environments.
- Authentication mechanisms in BFD may still be deployed which further
  reduce the attack space.

Basically, if your vxlan environment is appropriately operated and secured,
the main attacker of this session is the tenant itself.  And they have all
sorts of bad things they can do to knock down their own reachability from
one VTEP to another.  I.e. it's a stupid attack. :-)


-- Jeff