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

[Jeffrey Haas <[e-mail]>]

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