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

Jeffrey Haas <jhaas@pfrc.org> Wed, 18 December 2019 21:36 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBAB120236; Wed, 18 Dec 2019 13:36:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqkmO4FZjLRc; Wed, 18 Dec 2019 13:36:32 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 809CA12001A; Wed, 18 Dec 2019 13:36:32 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 725D51E2F6; Wed, 18 Dec 2019 16:41:02 -0500 (EST)
Date: Wed, 18 Dec 2019 16:41:02 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Cc: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, The IESG <iesg@ietf.org>, "draft-ietf-bfd-vxlan@ietf.org" <draft-ietf-bfd-vxlan@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "bfd-chairs@ietf.org" <bfd-chairs@ietf.org>
Subject: Re: =?iso-8859-1?Q?=C9ric_Vyncke's_Discus?= =?iso-8859-1?Q?s?= on draft-ietf-bfd-vxlan-09: (with DISCUSS and COMMENT)
Message-ID: <20191218214102.GF6488@pfrc.org>
References: <157657269782.26511.12421406428553874826.idtracker@ietfa.amsl.com> <CED2B858-AC55-4B0A-ADA2-AC46B628E6DA@cisco.com> <20191218203145.GD6488@pfrc.org> <FE5AEE55-9F03-49E9-89C3-6C9700C8683E@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <FE5AEE55-9F03-49E9-89C3-6C9700C8683E@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/IAnN0-ja2v-id14xyn3j8dFyHXY>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Dec 2019 21:36:34 -0000

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