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

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

Hi, Jeff,

> 2019/12/18 午後4:41、Jeffrey Haas <[e-mail]>のメール:
> 
> 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
>