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

Greg Mirsky <gregimirsky@gmail.com> Thu, 19 December 2019 02:20 UTC

Return-Path: <gregimirsky@gmail.com>
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 9E283120026; Wed, 18 Dec 2019 18:20:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 xMVQshCqeS7x; Wed, 18 Dec 2019 18:19:58 -0800 (PST)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63EBC120018; Wed, 18 Dec 2019 18:19:58 -0800 (PST)
Received: by mail-lf1-x130.google.com with SMTP id 9so3150165lfq.10; Wed, 18 Dec 2019 18:19:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tT7dVRvjOlAbdg9QAR4jk70JZXUZzR+dkra9DnH2z2Q=; b=mC+L42FpxL/pn613WE5n3snwkHCWBiJZqLGMcPVH07UPZ7F4Om06w9fhy4IKVr+6Ta 5JGszsQpc0g1rpEwJnpwq9ExJoLwkYzKb0p3sTxz9Vh3amRCDMfMsPwzvyjPM3E+7yek HNKQ15hWfxlVjFMdN7COr6yorgn4Nblydwi0OR58n8utINNuNKLw7ZaoiaoT8i0TONnM hsuaeDo6qGa+MzxSWKvxEqCqU3kjada3iQzY9CQQNaKHvAFBVMTNGfpX+HZ3Iu3oHgGf bOsv8HJYobl31s38hcK8yjjNTh3Nuw3g/JE7CaeZAOI54bSSug1wT/vP/LpWSFCY9aG5 MlnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tT7dVRvjOlAbdg9QAR4jk70JZXUZzR+dkra9DnH2z2Q=; b=b5c46NjAMZrtOZ6Fpt/M4ZyYwqpjRSwXCce2cJ57a47S8J3giI6vVwJ2eIU9x0+aoq +Nf4WZqFDsn1yHLDgZwXGDqGCafgEqsqQgji+BW5tNmvcSlkvu3J+QCu9ndgtzDFvlP+ wi6LfOTF2LHZuAWRkOHlk7s6QabculwfeqfHHOEAAueRE0xjS91p8NfTlTVlFIPRkHEG FKPx8YA/TUkl1MQSJh1lEC6mK/4KFkrFQ4+0MIOWy7ztlRRGkkOgd1z27TXTGbiwlfpE bTf+RWlRmjjiQ4Jf5ivY/arQvy/EDeynTygY70F+IaIUGnoU/NeMAzugYINbB89tppti d+gQ==
X-Gm-Message-State: APjAAAUBEiA7sNTgMhDdR9OS6Z370GpDmdVuuMKkEOZwP9vPhEOYtCYl YeOO2KYcBq/diwkwcAFb15D90W8/45sQbK1CA+4=
X-Google-Smtp-Source: APXvYqwRFwes+xgVIi49CQSJsUz5/sESxQno+OmunxIpxI6U45lARDFV7mLLKREAA/Wnaf9mVZ7LG+b4Zs4gKUv2pDc=
X-Received: by 2002:a19:f00d:: with SMTP id p13mr3803360lfc.37.1576721996661; Wed, 18 Dec 2019 18:19:56 -0800 (PST)
MIME-Version: 1.0
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> <20191218214102.GF6488@pfrc.org>
In-Reply-To: <20191218214102.GF6488@pfrc.org>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 18 Dec 2019 18:19:45 -0800
Message-ID: <CA+RyBmVc6t8K2UgZfFQoaCghmGQi0yOS1ZvB7r+E32sRS=vSxA@mail.gmail.com>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bfd-vxlan-09: (with DISCUSS and COMMENT)
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, "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>
Content-Type: multipart/alternative; boundary="000000000000854ae1059a05322b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/yOAVv35xoCxdyq9It9YDmLk5JFM>
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: Thu, 19 Dec 2019 02:20:01 -0000

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 <jhaas@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
>
>