HE.net BGP origin attribute rewriting

Mailman List Mirror (Read Only)
1

Hello,

we discovered, that at least Hurricane Electric (HE, AS 6939) does
rewrite BGP origin attribute unconditionally in all routes traversing
their network. This mandatory, but probably not widely known/used
attribute should not be changed by any speaker except originating router
(RFC 4271, section 5.1.1). HE rewrites origin for all routes.

I tried communicate this issue with HE, but they're not willing change
their configuration and respect mentioned RFC document, and they're
claiming, that another networks (Level3 was mentioned exactly) does
similar thing. In my experience, there're not so many service providers
doing that.

What's your view on this, do you think, that service providers can
simply ignore existing RFCs?

With regards,
Daniel

2

Plenty of providers do it. IIWY, I would universally rewrite origin at
your ingress points to be the same; otherwise you'll find that providers
will merely use it as a means of influencing the bgp best path decision
algorithm so that they end up with more of your traffic, and can
consequently charge you more. There are many useful ways to build a
multi-exit discrimination policy. Using origin is not one of them, in my
opinion.

The problem is that origin is ranked one place higher than MED. So if you
don't rewrite it, you are automatically giving your upstreams an inherent
means of strongly influencing the tie-breaking policy. If this were an
attribute which actually meant something, then maybe there would be some
point in paying attention to it, but it conveys no useful information these
days. IOW, it is completely pointless these days and you almost certainly
want to work the possibility of any upstream tweaking it.

Nick

3

I disagree. Origin is tremendously useful as a multi-AS weighting tool, and isn't the blunt hammer that AS_PATH is. The place where I've gotten the most benefit is large internal networks, where there may be multiple MPLS clouds along with sites cascaded off of them - it provides a way of sending "soft" preferences down the transitive chain. Also useful is "set origin egp XX" - on a route injector, that can post-pend an ASN and limit the spread of a route while still allowing the same transitive properties.

David Barak

4

I disagree. Origin is tremendously useful as a multi-AS weighting
tool, and isn't the blunt hammer that AS_PATH is.

If you think of AS_PATH as a blunt hammer, how would you describe
localpref?

We use AS_PATH in many cases *precisely* because we don't consider it
to be a blunt hammer...

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

5

So you're connected to providers A and B, who in turn connect to C. Additionally, B has customer D.

If you set origin E toward B (leaving origin I toward A) you influence C's decision without affecting either B or D, and you ensure that C still learns both routes to you. It's a more subtle nudge than as-path.

In general, I prefer routinely using attributes that are further down the algorithm so at the big guns can be saved for when they're needed or for special policy issues.

David Barak

6

We're not talking about the same thing here: configuring a policy to use an
interior-generated origin is completely different to depending on what your
upstreams configure their announcements to look like.

If you don't rewrite your transit providers' origin, then you are telling
them that they can directly influence your exit discrimination policy on
the basis of a purely advisory flag which has no real meaning. I.e. if one
of them tweaks origin to be IGP and another leaves everything set at EGP or
incomplete, then the tweaker will end up taking more of your traffic on no
basis whatsoever, other than the fact that they bent the rules of what some
might consider as pair play. This is broken and harmful. Rewriting the
origin on ingress stops this particular line of network abuse.

Nick

7

I have seen providers instruct their upstreams to raise local-pref to
hijack traffic. More than a few ISP's rewrite origin though. Personally I
only consider it a slightly shady practice. I think the problem with BGP
(among other things) is that there is no "blunt hammer". Now that routers
have more than 1G of RAM and more than one core it may be time to add some
more knobs.

8

If you don't rewrite your transit providers' origin, then you are telling
them that they can directly influence your exit discrimination policy on
the basis of a purely advisory flag which has no real meaning.

On what precisely do you base the idea that a mandatory transitive attribute of a BGP prefix is a "purely advisory flag which has no real meaning"? I encourage you to reconsider that opinion - it's actually a useful attribute, much the way that MED is a useful attribute. Many providers re-write MED, and apparently some re-write ORIGIN. Neither of those is "network abuse" - it's more accurately described as "network routing policy." As has been stated here before: your network, your rules.

David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com

9

The internet by definition is a network of network so no one entity can
keep traffic segregated to their network. Modifying someone else routing
advertisements without their consent is just as bad as filtering them in my
opinion. Doing so to move traffic into your AS in order to gain an
advantage in peering arrangements and make more money off of the end user
is just dastardly.

The "your network your rules" philosophy doesn't work for something as
large as the internet, or POTS or power grids or RF or anything else that
requires multiple companies to work together. This is why we have debates
on DPI and network neutrality and such. What if some country wants to
block youtube and they start advertising bogus routes for it? What if our
upstreams could shorten our AS paths to 1 or even shorten prefixes to drive
traffic through one AS or another? Giving all control to the network
operators would result in chaos.

10

On what precisely do you base the idea that a mandatory transitive
attribute of a BGP prefix is a "purely advisory flag which has no real
meaning"?

Let's say network A uses cisco kit and injects prefixes into their ibgp
tables using network statements. The default for this is to set
origin=igp. On the other hand, network B also uses cisco kit and uses
"redistribute" to inject static routes from their route reflectors. By
default, these prefixes will have origin=incomplete. Network C uses
juniper kit, which sets origin=igp for all injected prefixes, regardless of
whether it's via an IGP or some other means.

So, the default origin policy is that unless the originator of an prefix
manually tweaks the origin to be consistent with something that is actually
consistent (with what, I don't know - because there is no good definition
of the difference between, say, igp and incomplete), then different
_syntactic_ network configurations will set the parameter differently, even
if there is no _semantic_ difference in those configs.

This is a pretty random mess. I do not wish to operate the networks which
I manage on the basis of a parameter which is basically arbitrary and which
can be tuned by an upstream connectivity provider to their advantage based
on their whims.

I encourage you to reconsider that opinion - it's actually a
useful attribute, much the way that MED is a useful attribute. Many
providers re-write MED, and apparently some re-write ORIGIN. Neither of
those is "network abuse" - it's more accurately described as "network
routing policy."

med is useful in an inter-asn context if you have multiple links into a
specific asn and wish to discriminate between them on the basis of what
that ASN suggests. Same for origin if you trust that the other ASN has
configured origin in a sensible manner.

MED can be trusted in situations where you have a prescribed policy for
trusting med, preferably backed by a contract which defines the MEDs.
Otherwise, thanks but no thanks.

As has been stated here before: your network, your rules.

yep, definitely! :slight_smile:

Nick

11

When provider rewrites MED, they do it, because they don't want peer to
cause them to cold-potato, to which they may have compelling reason.
Then some clever people realise they forgot to rewrite origin, working
around the implicit agreement you had with them.

12

There was one particularly (in)famous network *coughpeer1cough* which
was well known for selectively rewriting the origin codes towards their
peers a few years back. For example, if traffic was going to New York,
they would advertise the prefix with IGP in New York, and Incomplete
everywhere else, forcing other networks to haul the traffic to New York.
This is a violation of most peering agreements, which require consistent
advertisements unless otherwise agreed, but it was just sneaky enough
that it flew under the radar of most folks for quite a while. When it
was finally noticed and they refused to stop doing it when asked, a few
folks just depeered them, but a bunch of others just "solved the
problem" by rewriting the origin codes. This is why you still see a lot
of rewriting happening today by default, to avoid a repeat of the same
issue.

Personally I was of the opinion that the correct solution to this
particular problem was just to terminate the peering relationship, but
honestly Origin code is a pretty useless attribute in the modern
Internet, and it exists today only because it's impossible to take it
out of the protocol. I don't see anyone complaining when we rewrite
someone else's MEDs, sometimes as a trick to move traffic onto your
network (*), or even that big of a complaint when we remove another
networks' communities, so I don't see why anyone cares about this one.

Maybe a "better" fix would be a local knob to ignore Origin code in the
best path decision without having to modify it. Start asking your
vendors for it now, maybe it'll show up around 2017... :slight_smile:

(*) I've seen a lot of inexperienced BGP speaking customers be very
upset that they can't "send any traffic using natural bgp" (yes, there
appears to be some kind of delusion running around that modifying BGP
attributes to influence path selection is bad... What's next, "organic
routes, not from concentrate"? :P), which in the end turned out to be us
sending the customer MEDs based on our IGP cost, other networks sending
them MEDs of 0, and them not knowing enough to do something useful with
the data or else rewrite it to 0.

13

In a message written on Thu, May 31, 2012 at 12:22:16PM -0500, Richard A Steenbergen wrote:

out of the protocol. I don't see anyone complaining when we rewrite
someone else's MEDs, sometimes as a trick to move traffic onto your
network (*), or even that big of a complaint when we remove another
networks' communities, so I don't see why anyone cares about this one.

Take all the politics and contracts out of it, and look at MED from
a 100% pure engineering perspective, with the traditional view that
MED reflects IGP cost, and origin reflects where the route came
from in the first place.

I would argue the right engineering answer is that each network,
on outbound, should set the MED equal to the IGP cost. Basically
if an ASN gets 4 routes with 4 different MEDS on 4 peering points
and picks the "best", when it passes it on to the next metric the
IGP cost an AS away no longer makes any sense.

If the behavior is for each ASN to inject their own MED on outbound,
then rewriting inbound or outbound is just an extension of the
entirely local policy anyway, no different than changing IGP metrics.
Don't want to reflect IGP metrics, rewrite to a fixed value.

The origin is different, at least conceptually. The origin type
should reflect the state of the route before it went into BGP, a
property which does not change per-AS hop along the way.

That's why with a pure engineer hat on I would be much more
surprised/upset to see someone rewriting origin while I would expect
them to be rewriting MED.

Of course the real world isn't 100% engineering based. ISP's do
all sorts of weird and fun things, and customers can (usually) vote
with their dollars. I don't have a problem with an ISP implementing
pretty much any BGP policy they want /provided they disclose it to
their BGP customers/.

Perhaps if a large number of people were a bit more rational with their
peering policies we wouldn't have enginers dedicated to generating
routing funkyness just to meet peering criteria. It's not helping
anyone get reliable, high performing network access.

14

While this is a nice thought, it's not practical in reality. If you give
someone a knob, they are going to turn it. Someone will look to take
advantage of it.

If you pay me, fine. If you don't pay me, I'm not going to allow you to
potentially cost me significant dollars in infrastructure costs just to
preserve the notion of free love and peering :slight_smile:

-Steve

15

> The internet by definition is a network of network so no one entity
> can keep traffic segregated to their network. Modifying someone else
> routing advertisements without their consent is just as bad as
> filtering them in my opinion. Doing so to move traffic into your AS
> in order to gain an advantage in peering arrangements and make more
> money off of the end user is just dastardly.

There was one particularly (in)famous network *coughpeer1cough* which
was well known for selectively rewriting the origin codes towards their
peers a few years back. For example, if traffic was going to New York,
they would advertise the prefix with IGP in New York, and Incomplete
everywhere else, forcing other networks to haul the traffic to New York.
This is a violation of most peering agreements, which require consistent
advertisements unless otherwise agreed, but it was just sneaky enough
that it flew under the radar of most folks for quite a while. When it
was finally noticed and they refused to stop doing it when asked, a few
folks just depeered them, but a bunch of others just "solved the
problem" by rewriting the origin codes. This is why you still see a lot
of rewriting happening today by default, to avoid a repeat of the same
issue.

Personally I was of the opinion that the correct solution to this
particular problem was just to terminate the peering relationship, but
honestly Origin code is a pretty useless attribute in the modern
Internet, and it exists today only because it's impossible to take it
out of the protocol. I don't see anyone complaining when we rewrite
someone else's MEDs, sometimes as a trick to move traffic onto your
network (*), or even that big of a complaint when we remove another
networks' communities, so I don't see why anyone cares about this one.

It's hard to catch when someone is modifying your advertisements. Also, I

don't expect MED to be compared globally since different networks will
handle it differently so chances are I'm just using it to contol traffic to
and from a directly connected ISP. If you rewrite it to do the same thing
with your upstreams I probably won't care as long as latency and hop count
remain reasonable. That being said I've seen an upstream mess with
local-pref in their AS and then again upstream from them and began pulling
traffic literally into a different country. That IMHO is egregious.

Maybe a "better" fix would be a local knob to ignore Origin code in the
best path decision without having to modify it. Start asking your
vendors for it now, maybe it'll show up around 2017... :slight_smile:

I still think it would cool if BGP had an AS topology database of some
sort, but that's too expensive. Most BGP policies are not very
deterministic in my experience.

(*) I've seen a lot of inexperienced BGP speaking customers be very
upset that they can't "send any traffic using natural bgp" (yes, there
appears to be some kind of delusion running around that modifying BGP
attributes to influence path selection is bad... What's next, "organic
routes, not from concentrate"? :P), which in the end turned out to be us
sending the customer MEDs based on our IGP cost, other networks sending
them MEDs of 0, and them not knowing enough to do something useful with
the data or else rewrite it to 0.

Well less than ten years ago I remember hearing that BGP was only for ISP's
or very large enterprises and most people should try to run an IGP only. I
still hear from companies who are nervous about running BGP with a private
MPLS provider. Old habits die hard I guess..

16

If you consider not mucking with my advertisements and those of my
customers "free love" then I hope you don't work for one of my upstreams.
Likewise, if you consider not hijacking my traffic to drive up revenue as
"cost". Anything to make a buck I suppose. sigh..

17

If you consider not mucking with my advertisements and those of my
customers "free love" then I hope you don't work for one of my upstreams.
Likewise, if you consider not hijacking my traffic to drive up revenue as
"cost". Anything to make a buck I suppose. sigh..

solution:

route-map rm-transit-in permit 1
continue
set origin igp
route-map rm-transit-in permit 10
[...]

It sucks slightly, but not very much. For sure, a lot less than the
suckage that happens when your transit provider stomps around with origin
from their learned prefixes.

Nick

18

I never encountered someone I paid doing this, but infrastructure-cheap
peers who stretched virtual circuits to meet peering point requirements
then tried to attract traffic away from those links were doing it for
years. I had the policy to overwrite peer's origin if they were
inconsistant at will for 6079 in the early 2000s.

19

You CAN rewrite MED, as stated in RFC 4271, section 5.1.4 - but you
SHOULD NOT change origin attribute, as stated in section 5.1.1. So, in
terms of rewriting, MED is not comparable to origin.

I think RFC 4271 (http://tools.ietf.org/html/rfc4271) is very clear
here. Back to the standard, why condone it's violation? Yes, statement
about origin is here since January 2006 - older RFC 1771 didn't contain
similar rule. But 6 years after publishing I think everyone had enough
time to implement this correctly.

I still think, that professionals shoult follow RFC and not insert their
own creativity to places, where's not expected - just because they
decide that as a "cool" idea. For local routing policy - there're still
lot of knobs, which can be used internally (typically MED, LOCPREF) to
enforce expected policy and there's technically no reason to change origin.

20

It's extremely hard to find RFC which does not contain incorrect
information or practically undeployable data. Many things if reading RFC
anally are not standard compliant, like no one does IPv6 in the world and
no one does MPLS VPNs etc.

I'm repeating myself, but if you reset MED, you do it because you have
reason why you do not allow peer to force you to cold-potato. There is
little point in resetting MED and not resetting origin, as what you tried
to stop from occurring still occurs.