Prepending with another ASN you don't own

Mailman List Mirror (Read Only)
1

Is it acceptable to prepend using another networks ASN as long as your
ASN is the last one in the path? I can think of a few scenarios where
this is helpful.

One scenario: Anycast content provider with an ISP (who you aren't
directly peering with) is choosing to send all traffic to a PoP on
another
continent.

Solution:
Prepend at the geographically-distant PoP so that the AS path looks
like <ACME> <BAD-ISP> <ACME>, and thus that service provider
(<BAD-ISP>)
views it as a routing loop and chooses one of your other PoPs. Sure
there are better solutions like communities, but why (if it is) would
this
be "bad?"

2

Even in that case I believe you should encapsulate between two instances of
your own ASN. Your example follows this but the text says only about the
last one in the path, while having both last and at least one previous is
better since you won't be implying that some other AS has connection to yet
another AS, it's just you doing this.

Rubens

3

this is called path poisoning. an italian friend used it in his phd
thesis. a few friends and i used it to detect use of default across
the internet.

but 42 people will scream "that's my AS!" of course, as it is your
prefix, that is ASinine :slight_smile:

ramdu

4

Hi Andrew,

Is it acceptable to prepend using another networks ASN as long as your
ASN is the last one in the path? I can think of a few scenarios where
this is helpful.

Your milage may vary. You risk introducing breakage instead of the
desired optimisation. There are providers who inspect the AS_PATH's
contents and make decisions to reject (ignore) a route announcement or
not based on the presence of certain values.

An example: If NTT's backbone (AS 2914) receives a route announcement
from any of its adjacent ASN (customers and peering partners alike)
which contains AT&T's ASN (7018), _anywhere_ in the AS_PATH, the
announcement is considered invalid and rejected (except on the direct
2914 <> 7018 BGP sessions of course).

This concept is called 'Peerlocking'. NTT has enabled this for an
undisclosed number of ASNs. This is a highly effective measure against
route leaks. More information: https://www.youtube.com/watch?v=CSLpWBrHy10

So, where you initially targetted to manipulate one ASN's best path
selection, you could end up being unreachable from mulitple seemingly
unrelated ASNs because they consider the announcement part of a route
leak!

One scenario: Anycast content provider with an ISP (who you aren't
directly peering with) is choosing to send all traffic to a PoP on
another continent.

Solution:
Prepend at the geographically-distant PoP so that the AS path looks
like <ACME> <BAD-ISP> <ACME>, and thus that service provider
(<BAD-ISP>) views it as a routing loop and chooses one of your other
PoPs. Sure there are better solutions like communities, but why (if it
is) would this be "bad?"

You are right that BGP Communities usually are a better method,
especially BGP Communities which are acted upon on "ibgp-in" rather then
"ebgp-out" (with per-region granularity). Communities which manipulate
the intermediate provider's best path selection can have a better effect
on keeping traffic local for anycasters then just suppressing
announcements on the far-end.

For instance, the community to "set lowest local preference, but only on
routers located outside the country I'm connected in" (2914:435 in NTT's
network) can in many cases replace the need for forging AS_PATHs. Such a
method also provides a safetynet: there always is a route, but during
normal operations its just highly unattractive. With AS_PATH forging you
don't automatically protect yourself against certain outage scenarios.

Finally, keep in mind that there are networks which have disabled
AS_PATH Loop Detection, or point default somewhere, so the forged
AS_PATH kludge might be in-effective.

Kine regards,

Job

ps. Eric Loos once shared this piece of wisdom with me: "Whenever in doubt, use BGP Communities." :wink:

5

+1

6

I've done this in the past as a work-around for insufficient BGP community support. Just prepending the AS I wanted to ignore the paths.

But, if the problem is an anycast CDN choosing a sub-optimal path to reach you, you might try reaching out to them. They're probably just as, if not more interested, in getting their traffic to you as efficiently as possible.

7

this is called path poisoning. an italian friend used it in his phd
thesis. a few friends and i used it to detect use of default across
the internet.

I've done this in the past as a work-around for insufficient BGP
community support. Just prepending the AS I wanted to ignore the
paths.

But, if the problem is an anycast CDN choosing a sub-optimal path to
reach you, you might try reaching out to them. They're probably just
as, if not more interested, in getting their traffic to you as
efficiently as possible.

apologies. i should have been more explicit. both of the examples
were using path poisoning for routing research. it is not a technique
i would reccommend in normal operations.

randy