Hi, Jeff, > 2019/12/19 午後1:06、Jeffrey Haas <jh...@pfrc.org>のメール: > > Carlos, > > On Thu, Dec 19, 2019 at 03:22:28AM +0000, Carlos Pignataro (cpignata) wrote: >>> 2019/12/18 午後4:41、Jeffrey Haas <jh...@pfrc.org>のメール: >>> But given that point, what precisely is the objection to the inner IP header >>> of the BFD for vxlan having a TTL of 1? >> >> The intent would be to protect of potential attacks beyond the encapsulating >> endpoint (i.e., packet coming into the VTEP vs. sourced, off-link spoofing). > > I'm sorry if I'm seeing oblivious, but I'm missing something. >
No need to be sorry — useful dialogue! Thank you! > 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. > >>> I think this is partially a matter of attack spaces varying depending on >>> whether we're targeting the management VNI vs. a tenant. In the case of the >>> management VNI, we (should) have very strong control over what BFD traffic >>> is getting encapsulated. >>> >>> However, for tenant VNI mode, is the argument that depending on what the >>> other vxlan PDU parameters look like, tenant sourced BFD PDUs may be >>> indistinguishable from ones sourced by the management infrastructure? And >>> if so, how would GTSM help us here? >> >> Tenant sourced BFD PDUs would not use host loopback dest addresses. Scanning >> through S6 of draft-ietf-bfd-vxlan-09, "MAY support the use of the >> Management VNI”. >> >> And if there are already protections for not over-forwarding the BFD pak, >> the flip-question is “what does TTL = 1 bug you?” >> >> My assumption was that if the base BFD specs say “GSTM is useful”, why not >> here? > > Personally, I'm mostly ambivalent if it helps. > I am also not fixated in any solution. 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. 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 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 Still, that thread did not even attempt to answer my question #2. > 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. > > - 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? > 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. > > -- Jeff
