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

From: Warren Kumari via Datatracker <[email-masked]>
Date: Tue, 03 Nov 2020 15:24:56 -0800

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:
https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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...

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 04 Nov 2020 12:27:27 +0100

> https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/

Please see my reply to Alvaro, where I describe how the multi-provider
use case is supposed to work:

https://mailarchive.ietf.org/arch/msg/babel/7_O-b6bN525EonbZu0cf6_hIjKU/

-Toke

---

From: Warren Kumari <[email-masked]>
Date: Thu, 5 Nov 2020 15:15:15 -0500

> https://mailarchive.ietf.org/arch/msg/babel/7_O-b6bN525EonbZu0cf6_hIjKU/

So, that text certainly helps, but it ain't clear **from the document
itself** - I think that it would be helpful to include something along
these lines in the document, and a general warning of the "this should
be used carefully". I also think that it would be useful to explicitly
state which (A or B) is the result of the rules applied.

Thank you for addressing my concerns; I'm trying to make sure that
readers understand the intent and don't shoot themselves in the
foot...
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 05 Nov 2020 22:51:12 +0100

> itself**

I think you may very well be right.  Our work on source-specific was
described in detail in [SS-ROUTING], and while we did try to repeat the
necessary background in the I-D, we may have been a little too terse.

-- Juliusz