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

[Warren Kumari <[e-mail]>]

On Wed, Nov 4, 2020 at 6:27 AM Toke Høiland-Jørgensen <[e-mail]> wrote:
>
> Warren Kumari via Datatracker <[e-mail]> writes:
>
> > 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...
>
> 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/
>

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


> -Toke



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