Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-06.txt

[Gyan Mishra <[e-mail]>]

Hi Jeffrey & Havard

Thank you for the comments.

The goal of 3.1 was to graphically depict the how excess as-path prepending
and how that could yield or exacerbate prefix hijacking impact downstream
consumers of pretending as you stated with ripple effect where a desirable
source origin AS becomes de-preferred or hijacked resulting in a route
leak.  We will also mention using BGP prefix origin validation RFC 6811 to
mitigate prefix hijacking resulting in a route leak.  The goal of 3.1 was
also to shed light on the ripple effects to downstream providers consuming
the prepends resulting in extremely long AS path exceeding the 255 max
as-path.  Also in 3.1 the goal was to depict the impact of “prepend to all”
resulting in prefix hijacking due to de-prefer of origin AS route resulting
in route leaks.

We will make  3.1 more clear in depicting a route leak from prefix
hijacking resulting from “prepend to all” excessive prepending.  Also
remove the 5+1 making it announce six.

Many Thanks

Gyan

On Fri, Feb 18, 2022 at 11:13 AM Jeffrey Haas <[e-mail]> wrote:

> I support Hávard's observations.
>
> I'd also like to comment that the notation of "prepends 5" meaning "5 + 1"
> is a bit confusing for all of the examples.  Consider instead just saying
> what the announced as-path length is.  Operators prepend 5 because their
> intent is "announce 6". :-)
>
> Rather than try to cast the (very contrived) scenario as a form of route
> leaking, I'd suggest the authors focus on the impact of downstream
> consumers of the prepending.  In particular, the example here simply notes
> that the receiving AS had a desire to use one path, but the upstream
> providers in executing their own motivations caused them to not have such a
> preferable path by default.
>
> Sadly, too bad for this downstream operator.  The more hops away you are
> from a given bit of reachability, the less your opinion tends to matter
> over what the announcements look like.  It's likely time for them to form a
> business relationship with the announcing AS or one of their immediate
> service provider ASes.  (And thus, reinforcing business motivations that
> push the AS diameter of the Internet to remain small...)
>
> -- Jeff
>
>
> > On Feb 18, 2022, at 7:28 AM, Havard Eidnes <he=
> [e-mail]> wrote:
> >
> > Hi,
> >
> > here are a few comments about section 3.1 in the draft:
> >
> > Other than the missing comma in the list of routers/ASes, near
> > the end there is talk about a route leak.  However, I don't think
> > what's stated here as a route leak is what's commonly understood
> > to be a route leak.
> >
> > I think a route leak is commonly understood to be when a route is
> > announced to a neighbor in violation of the (intended) routing
> > policy, i.e. a route leak can be the result of an erroneously
> > implemented intended routing policy.  I can't see how that's the
> > case here, because no routing policy has been expressed for "I".
> > This probably means that "I" re-advertises all routes it
> > receives, from any edge on any other edge, and therefore by
> > definition can't have a "route leak".
> >
> > It's another matter that the traffic pattern from B to J in the
> > stated scenario involves a change to a path which traverses I.
> >
> > If we instead of "thinking BGP" in the drawing in 3.1, suppose we
> > think "RIP with max metric 64" instead.  Of course when you
> > adjust metrics on any interface in the topology, traffic flows
> > will shift around.  I can't quite understand when we do the
> > similar thing in BGP it's such a big problem?
> >
> > Admittedly, by prepending outgoing route announcements towards a
> > given peer, you only affect "one end of the link", and there's a
> > fair chance that asymmetric traffic patterns will result if
> > that's the only thing which is done.  But...  Is that a problem?
> >
> > I think the problem desribed in section 3.1 could do with a bit
> > clearer description of why this is problematical.
> >
> > Regards,
> >
> > - Håvard
> >
> > _______________________________________________
> > GROW mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/grow
>
> _______________________________________________
> GROW mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/grow
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*