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

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi, Jeff,

Thanks for the dailogue and please see inline some follow-ups.

> 2019/12/19 午後3:38、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. :-)

I can read Emoji :-) 

> 
>>> 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.

Oh, no, no need. I think there’s shared responsibility between the editors, shepherd, and WG as a whole. But it really starts with the editors.

Not having an agreed-upon tracking system in the IETF does not help either…

While at it, though, out of the 6 issues brought up on that email, I only saw a response to issue #4 (and not we are discussing Issue #2). I would not mind the authors responding to the others :-) 

> 
>> 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.

This is a most useful clarification and perhaps goes to the core of the different in perspective.

To me, RFC 5884 is not the most similar scenario to VXLAN. RFC 5884 concerns itself with a uni-directional label-swapping-or-popping-hop-by-hop paradigm where popping too many Label Stack Entries (LSEs) in-flight mid-tunnel would expose the inner packet to the point of being mis-forwarded and let loose in the core infrastructure. 

The same is not the case for VXLAN, which really seems more similar to RFC 5885 or 5881, the former saying:
      The Time to
      Live/Hop Limit and Generalized TTL Security Mechanism (GTSM)
      procedures from Section 5 of [RFC5881] apply to this
      encapsulation, and hence the TTL/Hop Limit is set to 255.


And while looking at this, the document seems to show further confusion around this.

S9 of https://tools.ietf.org/html/draft-ietf-bfd-vxlan-09 says:

   This document recommends using an address from the Internal host
   loopback addresses (127/8 range for IPv4 and
   0:0:0:0:0:FFFF:7F00:0/104 range for IPv6) as the destination IP
   address in the inner IP header.  Using such address prevents the
   forwarding of the encapsulated BFD control message by a transient
   node in case the VXLAN tunnel is broken as according to [RFC1812]:


However, a transient node cannot expose the Inner header since it does not understand VXLAN or the context of VXLAN… that’s the difference with MPLS... 

> 
>>> 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.)
> 

That’s exactly the case — traffic on the tenant’s network being tunneled. They are scenario-specific and thinner but non-null.

Your comment about the destination address being a loopback is useful. The document says SHOULD, not MUST use 127/8 or ::FFFF:127.0.0.0/104.

Thank you,

Carlos.

> -- Jeff