[babel] Warren Kumari's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS)

Warren Kumari via Datatracker <noreply@ietf.org> Tue, 03 November 2020 23:24 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: babel@ietf.org
Delivered-To: babel@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F40953A1114; Tue, 3 Nov 2020 15:24:56 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-babel-source-specific@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake <d3e3e3@gmail.com>, d3e3e3@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Warren Kumari <warren@kumari.net>
Message-ID: <160444589696.9348.17838097712934982658@ietfa.amsl.com>
Date: Tue, 03 Nov 2020 15:24:56 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/heoNGhOwUTP1dSAuZvYNPVH3KKM>
Subject: [babel] Warren Kumari's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
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 23:24:57 -0000

Warren Kumari has entered the following ballot position for
draft-ietf-babel-source-specific-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


I apologize for being rushed, and not balloting earlier, but I feel like I must
have missed something fundamental here.

The example in Section 4 (Data Forwarding) illustrates an issue, but doesn't
actually *state* which (A or B) next hop will be used. The text then says that:
"A Babel implementation MUST choose routing table entries by using the
so-called destination-first ordering,". I interpret this to mean that the
packet "with source 2001:DB8:0:2::42 and destination 2001:DB8:0:1::57" should
use next-hop A. This means that you will be sending the packet to the
destination with no regard for if the provider connected to next-hop A
carries/announces 2001:DB8:0:2::/64. If if it doesn't, this will look like a
spoofing attack, and the ISP will (rightly) drop it.

The only way that I can see this working is if:
1: destination routes never point "outside" the network (and so will never hit
inbound BCP38 filters) or 2: destination routes always "match" - if you install
x:y:z::/q pointing at next-hop A, you also install the same router pointing at
next-hop B (this is pointless).

Please help me understand what I'm missing here -- routing on destination to an
ISP (which is what I'm assuming based on the "small networks" statement) seems
like it will route packets with ISP B sources addresses to ISP A, running into
BCP38/anti-spoofing filters. BCP84 also covers a number of scenarios - it
sounds like you are referring to Section 4.3.  Send Traffic Using a Provider
Prefix Only to That Provider, but that is exactly what is not happening above.

Again, I'm assuming that I'm just missing something blindingly obvious here,
but it would be good to figure out what, so the document can be clarified and
others don't fall into the same trap...