Hi Jeff, On Wed, Dec 18, 2019 at 05:18:24PM -0500, Jeffrey Haas wrote: > 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. :-)
I think in this message you've managed to get a pithy form of both main flavors of my concern: "don't step on the toes of the user" and "[the tenant has] all sorts of bad things they can do to knock down their own reachability" :) Less pithily, to keep the isolation between tenant and infrastructure, the tenant can't send stuff that gets interpreted by the infrastructure [as directed at the infrastructure], and the infrastructure can't intercept and parse as directed at itself tenant traffic. As you note, the former is likely not a terribly interesting attack, as the scope ought to be limited to just knocking out the tenant's own connection. So I'm more concerned about the latter case -- making sure the infrastructure doesn't eat up something the tenant wanted to send over the tunnel. That includes all sorts of weird things tenants might try to do, that might not even be fully in spec (depending on what the contract between tenant and provider looks like, I suppose). There's several technologies involved here that I don't have a great handle on, so I'm hoping to see an explanation of how that's prevented, in a simple enough fashion for my tiny brain to take in. -Ben
