Re: Éric Vyncke's Discuss on draft-ietf-bfd-vxlan-09: (with DISCUSS and COMMENT)

[Jeffrey Haas <[e-mail]>]

Carlos,

On Thu, Dec 19, 2019 at 08:12:56PM +0000, Carlos Pignataro (cpignata) wrote:
> > 2019/12/19 午後1:06、Jeffrey Haas <[e-mail]>のメール:

Interesting.  You're a bit more multi-lingual that I knew. :-)

> > The encapsulated packet's outer IP header, if single hop, could certainly
> > benefit from GTSM procedures.
> > 
> > But once you're more than one hop away, and you're vulnerable to general
> > attacks against packet insertion that the base vxlan PDUs have, how exactly
> > does setting the TTL one way or the other provide protection?
> 
> Think of the VXLAN tunnel as a sigle-hop link. Yes, midpoint/in-transit packet insertion is an attack vector not covered by GTSM-ing the inner IP. However, traffic from outside the VXLAN (i.e., from outside the infrastructure) routed into the tunnel could not have a 255 TTL/HL.

Right.  That was the host attack from within tenant space that I was talking
about earlier.  But as you note here, that can also be an external insertion
attack as well.

> However, I am not ambivalent about comments being simply ignored. I would like the Editors and pen-holders of this document to actually respond to comments.

As Shepherd, you have my apologies then.  When I was reviewing the last set
of comments, I thought I had caught all flagged messages with your open
issues.  But as you may note, the threads went very long.

> I am not looking for a specific answer, but I am looking for a thoughtful, deliberate, explicit, and intentional decision, shared on the list. That’s the role of Editors.
> 
> For example, see comment #2 in this note from June 2019 https://mailarchive.ietf.org/arch/msg/rtg-bfd/BL9Ob66Yxie4wX13yZJELbYPLJs 

Specifically covering this issue.

> 
> That comment, as well as others on that same note, were not ever responded to or acknowledged.
> 
> I reminded the editor that some comments were not being answered to: https://mailarchive.ietf.org/arch/msg/rtg-bfd/uzAtld-P7qB3B5z3NViFx83oaGA

That one did go to list traffic and I did take time to cover what I believed
was reasonable justification for not mentioning it.

> > If my observation above above about insertion attacks is valid, then using
> > GTSM for the inner IP packet isn't helpful for protecting against what GTSM
> > is intended for.  This leave us with roughly two modes:
> 
> Yes, it is valid, but it is not the only attack vector.

I'm unclear what you're flagging here.  Yes, we can attack all sorts of
things here, but we're discussing very specifically TTL and its use in
mitigating attacks viz. GTSM.

> > - With GTSM, enforce the usual related BFD procedure.  If packets aren't
> >  "caught" by BFD, they have the potential to bounce around until they
> >  expire.  Either way, BFD should go Down and the max damage is a number of
> >  BFD packets eventually settling back to the 1/sec timer.
> > - Without GTSM, exactly the same, just with less distance.
> > 
> > So, presuming my observation is valid:
> > It doesn't help.
> > It doesn't hurt (much).
> > If we want to require it, go for it.
> > 
> 
> I have the same question as before though.
> 
> To me the real vector of questions is: If the base GTSM spec requires it, why is that requirement relaxed? Where is it explained in the document?

See my prior ambivalence. :-)  It's reasonable modulo one of the two prior
implementations saying "this is a big deal!" to say "for our purposes, we
wish to use the security considerations of 5881".  As I noted for the IESG,
the considerations we have currently reflect 5884.  And while your
explanation for 5884's situation was helpful, I'm not entirely clear why the
vxlan encapsulation is so entirely different with regard to its impact vs.
MPLS and thus the 5884 scenario.

> > But it doesn't help your security story at all and using it perhaps confuses
> > people about it actually helping.  So, don't insist on it for security
> > reasons.
> 
> I would say “don’t insist on it for every possible security reason”. The fact that there are some cases not covered does not imply that there are none.

If there's at least one well articulated one, that's sufficient.  What I'm
trying to get talked into is that there is such reason where this really
helps.

If that's protecting vs. traffic that originates in the tenant's networking
space that hits the tunnel and happens to be destined to an inner-IP address
that is the tenant assigned address space that is not in the loopback
network address space, that'll do.  But it also feeds into my related
commentary on some considerations are scenario specific.  In particular, if
we're using the 5884 loopback network trick, you can't originate such
traffic from the tenant network.  (Hopefully the IESG reviewers have noted
this.)

-- Jeff