Why as-path prepend appends as number when a route-map applied in out direction on originating AS ?

[ashok.net.3026]

Hi BGP Experts,

I am seeing a behaviour where the as-path prepend allows the cisco router to advertise a route with as-path where the originating AS is changed after applying route-map .

As per my understanding the originating AS should not be changed by user configuration . Also as-path prepend is used in the case of when we prepend the as number rather than appending it.

topology :

----------------

R1(gi 0/1)----------------(gi 0/1)R2

Config on R1
-----------------------------
interface gi 0/1
ip address 10.10.20.1 255.255.255.0
no shut
router bgp 200
neighbor 10.10.20.2 remote-as 100
network 1.1.1.0 255.255.255.0
neighbor 10.10.20.2 route-map ABCD out
route-map ABCD permit 10
set as-path prepend 300

ip route 1.1.1.0 255.255.255.0 null0

Config on R2
--------------------------
interface gi0/1
ip address 10.10.20.2 255.255.255.0
no shut
router bgp 100
neighbor 10.10.20.1 remote-as 200
network 2.2.2.0 255.255.255.0

ip route 2.2.2.0 255.255.255.0 null0

--------------------------------------------------------------

The output of "sh ip bgp " shows as given below :

7604-R2302#sh ip bgp

BGP table version is 3, local router ID is 12.18.23.2

Status codes: s suppressed, d damped, h history, * valid, >best, i - internal,

             r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

  Network          NextHop            MetricLocPrf Weight Path

*> 1.1.1.0/24      10.10.20.1              0             0 200 300 i

*> 2.2.2.0/24      0.0.0.0                 0         32768 i

Here AS path is "200 300 i" which does not seem correct. As per my understanding it should have been "300 200 i" as the originating AS is : 200.

Can someone kindly help me to figure out what could be a possible reason for this issue ?

Any suggestion and help is greatly appreciated .

Thanks a ton in advance,

Regards,

Ashok Kumar .

[cadet alain]

Hi Ashok,

You can do it if you will but it wreak havoc on the internet and here you remarked that the original AS_PATH is prepended at last so after the AS_PATH prepend and that's why it isn't working in your case.

Why would you want to prepend another AS as the objective of this feature is to artificially increase the AS-PATH length so the neigh you're advertising the prefix to knows that if it received an update from you on another link it will prefer this one with shorter AS_PATH to send traffic to this prefix and if this path fails it will use the other.But it will also send this update to others and if you set an AS owned by this neighbour then the update will be ignored and so you may be disrupting communication on the internet.

Regards.

Alain.

[ashok.net.3026]

Hi Alain,

I also have the same concern . This configuration should not be allowed in first place.

I just wanted to know if there are any valid use-case where it needs to be allowed such config. if not, we should not be allowed to do such configuration.

Please let me know your thoughts on this.

Thanks & Regards,

Ashok.

[smitesh kharecha]

I think Cisco should consider it or prehaps Ashok you can file a new draft RFC for the same...

After all Ashok has got a very valid point, that there no point in prepending AS which is not configured on mine router; apart from in internet, it can lead to traffic blackholing.

Regards,

Smitesh

[cadet alain]

Hi,

again AS_PATH prepending another AS is not a correct way of doing.Maybe Cisco IOS parser should tell you you are doing something potentionally dangerous but I think this  is another subject.If it had then this interesting discussion wouldn't have taken place, ain't it?

Regards.

Alain.

[ashok.net.3026]

Hi Alain,

I do understand the implementation could be different to handle such situation. In other solution, we should first add originating AS and then add the as-path prepend which will fix this issue.

On Similar notes , There must be a valid reason as why Cisco is allowing such configuration as the soltuion could be easily done if it is such a Threat .

In case someone from Cisco can provide some clarification as why there is such config is allowed  from  BGP dev team , That would be really great help.

Thank you so much to all who tried to help me out.

Thanks Again,

Regards,

Ashok.

[paul driver]

Hi Ashok,

First of all I agree with the other guys responce's regarding the prepending - it doesn't make any sence to use a random number to advertise a longer prefix to your bgp peers, why wouldn't you use the same as number as your bgp session?

I assume the reason you are seeing the prepended route as 200,300 instead of the other way around as you are expecting is the EBGP peer needs to have a Valid as-path and the 200 just that.

R2  see's that route with a next hop of AS200, the 300 has no consequence,  just a longer prefix but the shortest path to reach its destination, but the other away around as you are querying and R2 wouldn't reach it, as the 300 isn't valid.

I hope this helps

res

Paul

[Peter Paluch]

Hi Ashok,

In addition to the responses of the other friends here, let me summarize a couple of points as I see them.

First of all, about the AS_PATH prepending itself: the outbound policies in Cisco's BGP implementation are processed and applied before attribute modifications that are performed as a part of advertising a route in BGP. In your case, the route-map is processed first, and only then, the attribute modifications as dictated by eBGP rules will take place. If the route-map says to prepend the ASN 300 while advertising a route then the BGP will do it right away, creating an empty AS_PATH attribute in the process and inserting the ASN 300 into it. After these explicit outbound policies are processed, the eBGP rules will come in, and as the route is advertised to another AS, your own ASN will be prepended again, resulting in AS_PATH of "200 300".

Whether the sequence of ASNs in the update should correctly be "200 300" or "300 200" is a matter of debate. As far as I know, the BGP RFC does not take the AS_PATH prepending into account so formally, the behavior is unspecified.

And to the idea of using a foreign ASN in the AS_PATH prepending configuration - while not correct, it may be usable in some specific circumstances. For example, you may want to advertise a network in such a way that it will be visible to all autonomous systems except a particular AS. That would be very easily accomplished by prepending that ASN into the AS_PATH.

Best regards,

Peter

[ashok.net.3026]

Hi Peter,

Thanks for detailed explanation . However, This introduces a very geniune BGP Attack and as earlier pointed out by Alain that this could lead a black holing of traffic. if you consider that the "shortest path" would be a prevention mechanism in this , There is no guarantee of that .

I am actually concerned about where I am trying to identify who has originated a particular prefix using Internet Route Registry database. Hence, This implementation brings a potential threat(either by mis config or by route Hijacking) which should have been considered while implementing the "as-path prepend".

I hope I have reflected my concern clearly.

Thank you so much,

With Warm Regards,

Ashok.

[Peter Paluch]

Hello Ashok,

However, This introduces a very geniune BGP Attack and as earlier  pointed out by Alain that this could lead a black holing of traffic.

Well, I would not call this an attack. It could cause problems but those problems would be more damaging to you (as the performer of the AS_PATH prepend) than to the foreign system whose ASN you have inadvertently or deliberately used:

• Either you are the ASN in which a set of networks is originated. Prepending a foreign ASN into the AS_PATH will cause that particular AS to reject your networks. It is you who is damaged in this case.
• Or you are a transit AS, and prepending a foreign AS will cause the path through your AS to appear longer and causing the foreign AS to reject it. This may cause problems for all AS-es which are using you as a transit AS, and in final effect, it will damage your reputation as a transit AS. However, note that you as a transit AS can introduce these problems far more effectively using prefix-lists, distribute-lists, as-path ACLs, route-maps etc. - so if you want to do something bad, you have plenty of tools to do it. The AS_PATH prepending, while kind-of obscure in this case, is by far not the only available tool.

It is true that there is little to no regulation as to what the ISPs put into their BGP updates. Can an ISP advertise a network of a different ISP? Technically, absolutely yes - it is so easy to inject a foreign network into our own BGP. Can an ISP modify BGP attributes of networks, both its own and foreign? Technically, absolutely yes - again, the tools are there.

You have to think in terms of having power to do good things. BGP is done according to this particular principle: it is very powerful so that you can do powerful things. IP networks have always been designed this way, assuming that their users are good-willed and do not do malicious things. During the years, it has shown itself that this assumption is not always true and that some regulatory mechanisms are necessary to prevent inadvertent or deliberate negative actions in the IP environment. BGP is no different here. Many of us remember the couple of incidents where an ISP either unintentionally or deliberate overrode some other ISP's routes, trying to perform some kind of filtering. Think of Pakistan hijacking YouTube's address space and causing the entire world to send its YouTube-destined packets to Pakistan:

http://www.ripe.net/internet-coordination/news/industry-developments/youtube-hijacking-a-ripe-ncc-ris-case-study

There are some activities in the field to make BGP more secure - but they have been discussed for long time now and no definitive answer has been brought yet (Secure BGP, Secure Origin BGP, etc.).

So, yes, you have just discovered that the BGP is very powerful but very fragile and dangerous in wrong hands - like the most of IP world

Best regards,

Peter

[milan.kulik]

Hi,

just to add to Peter's ideas:

Don't forget BGP is also used in enterprise environments using private AS numbers.

I personally had used prepending an artificial (different from my own) AS number in two secnarios:

a) marking a special subset of prefixes to be detected by other BGP routers

b) "poisoning" a  special subset of prefixes for one remote AS.

So IMHO, if thinking about any as-prepend restrictions in IOS, it might be reasonable to make it similar way as

remove-private-as command is done - allow to do anything with private AS numbers, but restrict public AS number manipulations?

BR,

Milan