Re: Adam Roach's No Objection on draft-ietf-bfd-vxlan-09: (with COMMENT)

Jeffrey Haas <jhaas@pfrc.org> Thu, 19 December 2019 19:14 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 60359120BF6; Thu, 19 Dec 2019 11:14:44 -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 CYlk770tr01r; Thu, 19 Dec 2019 11:14:40 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A0C74120B68; Thu, 19 Dec 2019 11:14:40 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id AD68C1E2F6; Thu, 19 Dec 2019 14:19:10 -0500 (EST)
Date: Thu, 19 Dec 2019 14:19:10 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Adam Roach <adam@nostrum.com>
Cc: Greg Mirsky <gregimirsky@gmail.com>, The IESG <iesg@ietf.org>, draft-ietf-bfd-vxlan@ietf.org, bfd-chairs@ietf.org, rtg-bfd WG <rtg-bfd@ietf.org>
Subject: Re: Adam Roach's No Objection on draft-ietf-bfd-vxlan-09: (with COMMENT)
Message-ID: <20191219191910.GA31892@pfrc.org>
References: <157656670090.24465.17703971379844970449.idtracker@ietfa.amsl.com> <CA+RyBmXq2ZmLm0CfOcykSPowQrx6TYfWNyVi9gPvXgDpnZY4Ow@mail.gmail.com> <9b1ec49d-6797-e9e9-eef5-2085f7a0dcce@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9b1ec49d-6797-e9e9-eef5-2085f7a0dcce@nostrum.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/k5jRKEnMzl0cmjQgdIxRW9IZK1s>
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 19:14:44 -0000

Adam,

[re: directing packets to the loopback network]

On Wed, Dec 18, 2019 at 08:37:03PM -0600, Adam Roach wrote:
> I'm a little unclear about the scope of leakage that is causing
> concern here. If you simply want to prevent the packets from making
> it to an end host, there are a lot of choices you can make that
> guarantee an address that has no ultimate destination.
> 
> If the concern is, instead, that the packet might be sent to one or
> more other routers when the tunnel is broken (even if it never
> reaches a host), then what you're doing here is unlikely to achieve
> your goals. As I attempted to highlight below, there is no reason to
> believe that an IPv6 router is going to treat ::ffff:127.0.0.0/104
> any differently than any other IPv4-mapped address. Unless you're in
> the default-free zone, It's either heading towards a default router
> or a v6/v4 gateway, and probably won't be dropped until it reaches
> an ingress to the v4 network.
> 
> On the other hand, if you *are* in the DFZ, my my understanding (and
> I'm not a routing person, so it's kind of a lay understanding) is
> that guaranteeing a packet drop in the default-free zone simply
> requires that the corresponding prefix isn't configured or
> announced. The IETF protocol IP blocks I mention below have that
> property.
> 
> In short, I don't think your solution addresses your implied threat
> model (regardless of which of the preceding two situations apply),
> and at the same time is an abuse of the semantic meaning of loopback
> addresses.
> 
> I'm feeling like I might not understand the problem being addressed
> by this approach. Perhaps if you explained the exact nature of the
> bad things that might happen when a tunnel breaks and some other
> inner address is used (with the assumption that such inner address
> would never correspond to a real host, and would never correspond to
> an advertised route, as would be true for my suggestions below), it
> would help.

Tersely:
In RFC 5884, BFD PDUs are carried in IP/UDP and are intended to be delivered
over a MPLS tunnel directly to the relevant endpoint.

The destination IP address is irrelevant - we're trying to talk to that
endpoint.

The mechanism used in 5884 was to choose something from the loopback network
as a place to put _something_ for IP that had the semantics of "the thing
I'm talking to".  Yes, it's a bit of a hack.  But it's a deployed hack.

And very similar, the ::FFFF:127.0.0.0/104 network was leveraged.

I believe you can draw the following conclusions:
- The tunnel decapsulation infrastructure can look for BFD encapsulated
  packets and ensure that BFD is what ends up dealing with such packets.
  This style of practice is fairly common in routers.
- In the absence of a decapsulation mechanism, an address still needs to be
  chosen.  But this now increases the provisioning overhead.  And even so,
  carrying of that provisioning information to the necessary session state for
  BFD is out of scope of the spec - we just care that there's an address.

If you don't like this practice, deployed as it is, please feel free to
suggest an alternative that accomplishes the same goals.  

And be mindful, there's running code here.

-- Jeff