Greg,
Thank you for the new text but I still believe that forwarding in the data
plane a packet with TTL/HL=254 (assuming TTL/HL=255 at source) is less an issue
than forcing the control plane of a VNI/gateway to reply to a remote BFD (the
whole idea behind GTSM is to accept only local traffic). Moreover, a bad
behaving routers is probably less probable than a bad behaving VM (although I
am unsure about the threat model in this case).
Else, please s/ removes the VXLAN header/ removes the outer IP + UDP + VXLAN
headers/
Also, note that IPv6 packets with HL=0 but with a matching dest addr will be
accepted by IPv6 nodes.
-éric
From: Greg Mirsky <gregimir...@gmail.com>
Date: Thursday, 19 December 2019 at 03:20
To: Jeffrey Haas <jh...@pfrc.org>
Cc: "Carlos Pignataro (cpignata)" <cpign...@cisco.com>, Eric Vyncke
<evyn...@cisco.com>, The IESG <i...@ietf.org>, "draft-ietf-bfd-vx...@ietf.org"
<draft-ietf-bfd-vx...@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>,
"bfd-cha...@ietf.org" <bfd-cha...@ietf.org>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bfd-vxlan-09: (with DISCUSS
and COMMENT)
Hi Carlos, Jeff, et al.,
thank you for a very insightful discussion.
Based on the input from the experts familiar with VXLAN deployment scenario the
following text was added to justify the requirement to set TTL or Hop Limit to
1:
TTL or Hop Limit: MUST be set to 1 to ensure that the BFD
packet is not routed within the Layer 3 underlay network. This
addresses the scenario when the inner IP destination address is
of VXLAN gateway and there is a router in underlay which
removes the VXLAN header, then it is possible to route the
packet as VXLAN gateway address is routable address.
Best regards,
Greg
On Wed, Dec 18, 2019 at 1:36 PM Jeffrey Haas
<jh...@pfrc.org<mailto:jh...@pfrc.org>> wrote:
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?
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?
-- Jeff
