Hi, Jeff, > 2019/12/18 午後4:41、Jeffrey Haas <jh...@pfrc.org>のメール: > > Carlos, > > On Wed, Dec 18, 2019 at 09:28:30PM +0000, Carlos Pignataro (cpignata) wrote: >> The TTL of 1 recommended for RFC 4379 / RFC 8029 S4.3 is because if the MPLS >> packet is mis-routed, or there's a forwarding mis-programming, then an MPLS >> LSE pop would expose the BFD packet and so that the BFD is not further >> mis-forwarded. >> >> In the VXLAN case an intermediate router would not remove the VXLAN encap >> because the outer encap is IP (with a destination address, not an MPLS Label >> that can be mis-interpreted in context) and a mid-point router would not >> understand VXLAN. > > Explained, that now seems obvious. Thanks. :-) > > 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 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? Thanks, Carlos. > > -- Jeff >
