Re: [babel] Alvaro Retana's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS and COMMENT)

Toke Høiland-Jørgensen <toke@toke.dk> Tue, 03 November 2020 21:45 UTC

Return-Path: <toke@toke.dk>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594693A1213; Tue, 3 Nov 2020 13:45:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=toke.dk
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 WDmEj2A4D_nC; Tue, 3 Nov 2020 13:45:46 -0800 (PST)
Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90D773A120E; Tue, 3 Nov 2020 13:45:44 -0800 (PST)
From: Toke Høiland-Jørgensen <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1604439941; bh=BSqu/N6Qck9YU2QvO5y8NzMbQxEsW/cAiRSSA5JQRe8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=TjSUj4uGaJqdVQKT2v6Hy213m6oW9a8CC7R1JasgQHELWuDlpcjDpMPhq/Tc3yg20 nKQOKQ/IyOE3PSK5TF671JQPYneW3UjwkG7le6+qHVMZrEtDGsH0pZaYLvJDjnsEbB 1ccgg7mrBNFqMzHHhuU6v7LcdlTprPLFyNTA7cfuSJp4tZbA1gu3wnwxjQ2uHSHvJU GDjUyYkoja02aV4zYT5PVBseT2UcmGz+2IimH37P/T47ZIPeJmW2fj86Cq2r7xnwDH BOQQMUwTY51Et0eYITwQvOJTDLIgygQUkPpM4aZyGgkDqjaFO9t2yrga8ix1+btxds ZV9g6C5E7CefA==
To: Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>
Cc: babel-chairs@ietf.org, Donald Eastlake <d3e3e3@gmail.com>, babel@ietf.org, draft-ietf-babel-source-specific@ietf.org
In-Reply-To: <160441631177.15161.14360810315064872038@ietfa.amsl.com>
References: <160441631177.15161.14360810315064872038@ietfa.amsl.com>
Date: Tue, 03 Nov 2020 22:45:40 +0100
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87d00ujerf.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/7_O-b6bN525EonbZu0cf6_hIjKU>
Subject: Re: [babel] Alvaro Retana's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS and COMMENT)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2020 21:45:49 -0000

Alvaro Retana via Datatracker <noreply@ietf.org> writes:

> This draft describes destination-first forwarding.  If I understand correctly,
> for the table in §4:
>
>              destination                source     next-hop
>        2001:DB8:0:1::/64                  ::/0            A
>                     ::/0     2001:DB8:0:2::/64            B

[...]

> ...and the example presented of a "source 2001:DB8:0:2::42 and destination
> 2001:DB8:0:1::57", the result is that the packet is forwarded to A.  Is this
> the correct interpretation?

Yes.

> If so, then I believe there are important assumptions made that are
> not mentioned.
>
> In line with this document being "applicable to small networks" (§1), BCP
> 84/§4.3 recommends the following:
>
>    For smaller edge networks that use provider-based addressing and
>    whose ISPs implement ingress filters (which they should do), the
>    third option is to route traffic being sourced from a given
>    provider's address space to that provider.
>
> Given that the draft provides no details, I assume that being "compatible with
> [BCP84]" (§1) means at least that Babel nodes aim to "route traffic being
> sourced from a given provider's address space to that provider".
>
> (a) While I understand the table above is just an example, it can be
> interpreted as indicating that B is the provider that assigned the
> 2001:DB8:0:2::/64 prefix.  If traffic sourced from that prefix is sent to A,
> then there's a good chance that the packet will be dropped (in line with BCP
> 84, BCP 38, etc.).
>
> Maybe the table is not intended to illustrate the routing table at a multihomed
> edge router.

It's not. Here's a bit of my real routing table (slightly altered to aid
clarity of example), illustrating what a real multi-homing scenario
would look like:

default from 2a00:xxxx::/48 via fe80::feec:daff:fe55:4a3b dev eth1 proto bird metric 32 pref medium
default from 2a0c:yyyy::/48 via fe80::da58:d7ff:fe00:1d2b dev eth1 proto bird metric 32 pref medium
2a0c:yyyy::/64              via fe80::da58:d7ff:fe00:1d2b dev eth1 proto bird metric 32 pref medium
2a0c:yyyy:1::/64            via fe80::da58:d7ff:fe00:1d2b dev eth1 proto bird metric 32 pref medium
2a00:xxxx::/64              via fe80::feec:daff:fe55:4a3b dev eth1 proto bird metric 32 pref medium
2a00:xxxx:1::/64            via fe80::feec:daff:fe55:4a3b dev eth1 proto bird metric 32 pref medium

The first two default routes are from two different upstreams that have
assigned me prefix 2a00:xxxx::/48 and 2a0c:yyyy::/48 respectively. For
the "multi-homed ISP" scenario, the expectation is that an edge router
will announce a default route (or something similarly broad) with a
source prefix of the delegated prefix. This is absolutely compatible
with BCP38; in fact it provides automatic BCP38 filtering at the first
hop, since if a packet is spoofing its source address to something that
is outside the assigned prefix, there will not be any valid route for
that packet to reach the internet at all.

The four other more-specific routes in the snippet above have no source
prefix announced (like in the example in the draft); in this case, they
come from the routers exporting the prefixes used by each of local their
interfaces as separate routes to the local network. This means that a
packet trying to reach a node on the local network would be routed
directly to that router and on to the host, no matter it's source
prefix, instead of going over the internet from ISP to ISP. This is
obviously the correct behaviour in such a multi-homed scenario.

> Still, it shows how easy it is to define a policy that may not result
> in the expected behavior because of the destination-first operation.
> Please add some guidance on the advertisements and how they may
> interact in the routing table.
>
> Note that what I'm asking for may just be a good example of what to do/not to
> do.  rfc8678/§5 presents an example of how the forwarding table is constructed
> based on a set of routes -- something like that would be great!

Since your concern seems to be related to a particular example of what
the source-specific extension can be used for, mentioned in the
introduction, I'm not sure I see how it would improve the document to
write a whole bunch of text addressing this particular operational
concern? I mean, the section you're quoting the example from (section 4)
literally says that the choice of dest first / source first is arbitrary
and all that is required is that it is consistent, before then going
ahead and spelling out the choice.

One small change in the introduction that may make this clearer, was to
amend this sentence in the third paragraph of the introduction:

"When using
   this technique in a network connected to multiple providers, every
   host is assigned multiple addresses, one per provider."

to read something like:

"When using
   this technique in a network connected to multiple providers, every
   host is assigned multiple addresses, one per provider, and each edge
   router exports a default route with a source prefix corresponding to
   the prefix delegated from its upstream."

> (b) How is the source address selected by the host?

[...]

> Even though this document is about Babel and not the host, I would
> like to see a (short) discussion about how the host is expected to
> behave (or what it needs to consider) in light of the
> destination-first operation.

Juliusz can correct me if I'm wrong here, but I believe this is left out
because it really doesn't matter. The host can pick source addresses
however it likes, and packets will make their way to the right upstream
(in the multi-homing scenario).

-Toke