Hi, My name is Sabri. I'm just another dude involved in internetworking and I work for a small isp in The Netherlands. I am concerned. Concerned about people and companies who think they are in the position to be net.gods and for political reasons destroy the free character of the internet. In the history of the internet, people have been trusting each other. On the lower technical levels, great things like peering have been developed. At the various IX'es, commercial and non-profit companies exchange information about each others routes using BGP4 and various other routing protocols. In my opinion, announcing a netblock using BGP4 is making a promise to carry traffic to a destination within that netblock. If you feel that parts of that network are against your ethics or AUP, you should not be announcing such a netblock. If you do so, you will make a promise which you do not forfill. That is not a nice thing to do in a world which is based on trust and agreements between parties. I was shocked to find out that one of the larger transit providers (which the company I work for buys transit from) is actively violating the trust it has been given by the internetworld. Above.net is blocking a host in UUnet IP space. After finding out about this we notified Above.net in The Netherlands and asked what it was about and requested them to stop announcing the netblock if they would continue to nullroute the host involved. After various contacts about this matter, Above.net answered with the following statements (according to the salesdroid it came from Paul Vixie himself):
194.178.232.55/32. --> this tester is part of a /16 belonging to uunet, and sends traffic which is in violation of our AUG. we complained to uunet without any effect. if we have blocked access from this /32 to our backbone, we are within our rights.
After this mail, we contacted Above.net again. They basically told us it was for our own protection because that traffic from that host does not comply to their AUP. We specifically told them we really don't mind them blackholing that host but *announcing* a route for it. So far no response. More information and logs on http://www.bit.nl/~sabri/above/ -- /* Sabri Berisha * * CCNA, BOFH, Systems admin Linux/FreeBSD */
Sabri Berisha wrote:
I am concerned. Concerned about people and companies who think they are in the position to be net.gods and for political reasons destroy the free character of the internet.
I've been involved for over 20 years, and don't remember this "free character". Perhaps there is a language translation problem? That also applies to the use of the word "terrorism"?
In the history of the internet, people have been trusting each other.
When? I remember the RFCs on policy based routing over a decade ago. Have you read them?
In my opinion, announcing a netblock using BGP4 is making a promise to carry traffic to a destination within that netblock. If you feel that parts of that network are against your ethics or AUP, you should not be announcing such a netblock.
Announcing a netblock doesn't promise that every address in that block exists or is reachable. A network that is blocked for AUP violations doesn't "exist", and usually returns the ICMP message "Unreachable -- Administratively Prohibited" specifically designed for such situations. Have you read "Router Requirements"?
Above.net is blocking a host in UUnet IP space. ...
194.178.232.55/32. --> this tester is part of a /16 belonging to uunet, and sends traffic which is in violation of our AUG. we complained to uunet without any effect. if we have blocked access from this /32 to our backbone, we are within our rights.
After this mail, we contacted Above.net again. They basically told us it was for our own protection because that traffic from that host does not comply to their AUP. We specifically told them we really don't mind them blackholing that host but *announcing* a route for it. So far no response.
Where did they announce a "host route"? I thought you said they announce a route to an netblock -- an entire /16? It seems from the email that they clearly stated that the traffic was in violation of the AUP. We all block specific sites that harm our networks. Otherwise, there would be no capacity left for our customers. It's the "policy" part, for which BGP was designed. Go read the design RFCs. If you are participating in tests with 194.178.232.55 (relaytest.orbs.vuurwerk.nl), then you need a private connection to that specific site, just as many academic sites test unstable network software. Expensive, but shouldn't be too bad considering that both of you are in the Netherlands.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
On Tue, 9 Jan 2001, William Allen Simpson wrote:
Sabri Berisha wrote:
I am concerned. Concerned about people and companies who think they are in the position to be net.gods and for political reasons destroy the free character of the internet.
I've been involved for over 20 years, and don't remember this "free character". Perhaps there is a language translation problem? That also applies to the use of the word "terrorism"?
"Free" as in everybody decides their own policies. "Terrorism" as in forcing your policies on someone elses network.
In the history of the internet, people have been trusting each other.
When? I remember the RFCs on policy based routing over a decade ago. Have you read them?
No. But if it makes you feel better, I will.
In my opinion, announcing a netblock using BGP4 is making a promise to carry traffic to a destination within that netblock. If you feel that parts of that network are against your ethics or AUP, you should not be announcing such a netblock.
Announcing a netblock doesn't promise that every address in that block exists or is reachable. A network that is blocked for AUP violations doesn't "exist", and usually returns the ICMP message "Unreachable -- Administratively Prohibited" specifically designed for such situations. Have you read "Router Requirements"?
Why do you want me to have read everything you have read? My point is not policy based routing or which ICMP message I get. My point is not to announce something you won't route.
Above.net is blocking a host in UUnet IP space. ...
194.178.232.55/32. --> this tester is part of a /16 belonging to uunet, and sends traffic which is in violation of our AUG. we complained to uunet without any effect. if we have blocked access from this /32 to our backbone, we are within our rights.
After this mail, we contacted Above.net again. They basically told us it was for our own protection because that traffic from that host does not comply to their AUP. We specifically told them we really don't mind them blackholing that host but *announcing* a route for it. So far no response.
Where did they announce a "host route"? I thought you said they announce a route to an netblock -- an entire /16?
Yes, they announced a /16.
It seems from the email that they clearly stated that the traffic was in violation of the AUP. We all block specific sites that harm our networks. Otherwise, there would be no capacity left for our customers. It's the "policy" part, for which BGP was designed. Go read the design RFCs.
Read read read... I'm pretty familiair with BGP.
If you are participating in tests with 194.178.232.55 (relaytest.orbs.vuurwerk.nl), then you need a private connection to that specific site, just as many academic sites test unstable network software. Expensive, but shouldn't be too bad considering that both of you are in the Netherlands....
If I want to make sure my traffic gets to that host, I can set up a static route to our second uplink. But it's not *me* who should be filtering. How do I know which other hosts are being announced and blackholed? -- /* Sabri Berisha, non-interesting network dude. * * CCNA, BOFH, Systems admin Linux/FreeBSD */
"Free" as in everybody decides their own policies. "Terrorism" as in forcing your policies on someone elses network.
That is not the definition of "terrorism".
From Webster's Revised Unabridged Dictionary (1913) [web1913]:
Terrorism \Ter"ror*ism\, n. [Cf. F. terrorisme.] The act of terrorizing, or state of being terrorized; a mode of government by terror or intimidation. --Jefferson. And if you agree to use my service, then you agree to my "forcing" my policies on that agreement, just as I agree to your "forcing" your policies on me. ... Thats not intimidation, thats a business services contract.
My point is not to announce something you won't route.
If I want to make sure my traffic gets to that host, I can set up a static route to our second uplink. But it's not *me* who should be filtering. How do I know which other hosts are being announced and blackholed?
-- /* Sabri Berisha, non-interesting network dude.
Why should'nt you (or your suppliers) filter? (hint.. more RFC reading) And please review your service contracts. If your suppliers promise reachability to the "whole" Internet, its time to apply the cluebat. As usual, YMMV. --bill
On Tue, Jan 09, 2001, Sabri Berisha wrote:
(relaytest.orbs.vuurwerk.nl), then you need a private connection to that specific site, just as many academic sites test unstable network software. Expensive, but shouldn't be too bad considering that both of you are in the Netherlands....
If I want to make sure my traffic gets to that host, I can set up a static route to our second uplink. But it's not *me* who should be filtering. How do I know which other hosts are being announced and blackholed?
I was just about to say the same thing. I don't quite think of it as terrorism, I just think its not nice for someone to decide part of a net block they're passing the announcements for is being selectively filtered inside their own network. the host in question isn't even an above.net client - its a uunet client. If you have a problem with it, drop announcing the /16 to customers. When customers complain about unreachability to a site, tell them that uunet (note *uunet*, not vuurwerk) are breaking their AUP and they should complain to uunet. You're still 'protecting' your customers. I'd rather get partial announcements than traffic-filtered announcements. That way, my other network pipes (which hopefully have a path without above.net in it to vuurwerk) will take over. above.net are happy. vuurwerk is happy. life is good. no bitching or extra configuration. (oh, and note: this opinion has nothing to do with my employer, interpersonal relationships or my opinion of orbs. You might be surprised how unrelated it is.) Adrian -- Adrian Chadd "Sex Change: a simple job of inside <adrian@creative.net.au> to outside plumbing." - Some random movie
On Tue, 9 Jan 2001, Adrian Chadd wrote:
I'd rather get partial announcements than traffic-filtered announcements. That way, my other network pipes (which hopefully have a path without above.net in it to vuurwerk) will take over. above.net are happy. vuurwerk is happy. life is good. no bitching or extra configuration.
Isn't this just the kind of thing BGP communities can be used for? Perhaps rfc 1998 is applicable here, depending on Sabri's architecture, although one would probably have to go beyond the NOC frontline to have 6461 tag the blackhole announcements. Without having an above feed to hand, I couldn't say if they already do. joshua
On Tue, Jan 09, 2001, Joshua Goodall wrote:
On Tue, 9 Jan 2001, Adrian Chadd wrote:
I'd rather get partial announcements than traffic-filtered announcements. That way, my other network pipes (which hopefully have a path without above.net in it to vuurwerk) will take over. above.net are happy. vuurwerk is happy. life is good. no bitching or extra configuration.
Isn't this just the kind of thing BGP communities can be used for?
Perhaps rfc 1998 is applicable here, depending on Sabri's architecture, although one would probably have to go beyond the NOC frontline to have 6461 tag the blackhole announcements.
Without having an above feed to hand, I couldn't say if they already do.
The problem with communities here is that: * bgp communities apply to a route announcement, not an arbitrary network. The /16 is being announced here and passing through above.net, and if above.net wanted to tag the specific host they'd have to announce the /32. * besides the few well-known ones, each router participating needs to know what the community maps to. So unless I've missed something here, you can't use BGP communities. Adrian -- Adrian Chadd "Sex Change: a simple job of outside <adrian@creative.net.au> to inside plumbing." - Some random movie
On Tue, 9 Jan 2001, Adrian Chadd wrote:
The problem with communities here is that:
* bgp communities apply to a route announcement, not an arbitrary network. The /16 is being announced here and passing through above.net, and if above.net wanted to tag the specific host they'd have to announce the /32.
Which shouldn't be a problem for transit customers, and I'd have a hard time believing that Above's European edges don't have the CPU/memory to carry the set of blackholes.
* besides the few well-known ones, each router participating needs to know what the community maps to.
Hopefully not a major configuration issue for either party. Why would anyone want to do this, given that blackholing is generally only against abusive hosts? Here's one hypothetical: Let's say you run a database of known open relays. You have transit from a stable, well-maintained provider. However... you don't want your transit RBLd (etc), or your system may return false negatives. Perhaps there are other reasons. For example, that reverse lookup "relaytest.orbs.vuurwerk.nl" indicates experimentation, not abuse. How's that for a more positive suggestion. joshua
On Tue, Jan 09, 2001 at 09:49:50PM +0800, Adrian Chadd wrote:
I'd rather get partial announcements than traffic-filtered announcements. That way, my other network pipes (which hopefully have a path without above.net in it to vuurwerk) will take over. above.net are happy. vuurwerk is happy. life is good. no bitching or extra configuration.
personally speaking, and no disrespect to any abovenet network engineers, or anyone else, but I would *MUCH* rather a solution which doesn't involve them logging onto several routers to block 1 route (I don't know how many places abovenet peer with uunet, but I'll bet that its more than 1 place) a) Add a blackhole route (1 config change) b) Tag/block route on ingress (X config changes) c) block route on egress (Y config changes) -- John Payne http://www.sackheads.org/jpayne/ john@sackheads.org http://www.sackheads.org/uce/ Fax: +44 870 0547954 To send me mail, use the address in the From: header
On Tue, Jan 09, 2001, John Payne wrote:
On Tue, Jan 09, 2001 at 09:49:50PM +0800, Adrian Chadd wrote:
I'd rather get partial announcements than traffic-filtered announcements. That way, my other network pipes (which hopefully have a path without above.net in it to vuurwerk) will take over. above.net are happy. vuurwerk is happy. life is good. no bitching or extra configuration.
personally speaking, and no disrespect to any abovenet network engineers, or anyone else, but I would *MUCH* rather a solution which doesn't involve them logging onto several routers to block 1 route (I don't know how many places abovenet peer with uunet, but I'll bet that its more than 1 place)
a) Add a blackhole route (1 config change) b) Tag/block route on ingress (X config changes) c) block route on egress (Y config changes)
That in itself is bogus. How many MXes do you run? Can you seriously tell me that every time you add a domain to your MX servers you consider the updates "too difficult" ? I mean, going by what you said above, we might as well run open relays. That way, whenever we add new domains, thats 1 config change to your primary MX host to accept mail, and bewm! it works! Thats what scripts and other automata are for. Adrian -- Adrian Chadd "Sex Change: a simple job of outside <adrian@creative.net.au> to inside plumbing." - Some random movie
On Wed, 10 Jan 2001, Adrian Chadd wrote:
On Tue, Jan 09, 2001, John Payne wrote:
personally speaking, and no disrespect to any abovenet network engineers, or anyone else, but I would *MUCH* rather a solution which doesn't involve them logging onto several routers to block 1 route (I don't know how many places abovenet peer with uunet, but I'll bet that its more than 1 place)
a) Add a blackhole route (1 config change) b) Tag/block route on ingress (X config changes) c) block route on egress (Y config changes)
That in itself is bogus. How many MXes do you run? Can you seriously tell me that every time you add a domain to your MX servers you consider the updates "too difficult" ?
I mean, going by what you said above, we might as well run open relays. That way, whenever we add new domains, thats 1 config change to your primary MX host to accept mail, and bewm! it works!
Thats what scripts and other automata are for.
Adrian
-- Adrian Chadd "Sex Change: a simple job of outside <adrian@creative.net.au> to inside plumbing." - Some random movie
Adrian, rsync is your friend when it comes to updating mailserver configs. I'll stick to doing it manually on our routers though, thankyou. If it is important enough to an operator that they block traffic to-from something that violates some policy they have, it is important enough for them to update X number of routers. --- John Fraizer EnterZone, Inc
On Wed, Jan 10, 2001 at 03:12:44PM +0800, Adrian Chadd wrote:
On Tue, Jan 09, 2001, John Payne wrote:
On Tue, Jan 09, 2001 at 09:49:50PM +0800, Adrian Chadd wrote:
I'd rather get partial announcements than traffic-filtered announcements. That way, my other network pipes (which hopefully have a path without above.net in it to vuurwerk) will take over. above.net are happy. vuurwerk is happy. life is good. no bitching or extra configuration.
personally speaking, and no disrespect to any abovenet network engineers, or anyone else, but I would *MUCH* rather a solution which doesn't involve them logging onto several routers to block 1 route (I don't know how many places abovenet peer with uunet, but I'll bet that its more than 1 place)
a) Add a blackhole route (1 config change) b) Tag/block route on ingress (X config changes) c) block route on egress (Y config changes)
That in itself is bogus. How many MXes do you run? Can you seriously tell me that every time you add a domain to your MX servers you consider the updates "too difficult" ?
I mean, going by what you said above, we might as well run open relays. That way, whenever we add new domains, thats 1 config change to your primary MX host to accept mail, and bewm! it works!
No, I updated the list of domains in one place and its automatically taken care of on the other boxes.
Thats what scripts and other automata are for.
I trust scripts to update mailservers which nobody else can be trying to configure at the same time (and name servers for that matter). Injecting a blackhole route and letting IBGP propogate it is the same idea. (as long as it stays inside your network ;) -- John Payne http://www.sackheads.org/jpayne/ john@sackheads.org http://www.sackheads.org/uce/ Fax: +44 870 0547954 To send me mail, use the address in the From: header
On Wed, Jan 10, 2001, John Payne wrote:
Thats what scripts and other automata are for.
I trust scripts to update mailservers which nobody else can be trying to configure at the same time (and name servers for that matter).
Injecting a blackhole route and letting IBGP propogate it is the same idea. (as long as it stays inside your network ;)
NOnono.. *sigh* I think after this I'm going to knock off this thread. I'm simply saying that the easiest method (null routing, open relays) isn't always the most "correct" method. I think that its nicer to simply drop the entire netblock (or even deaggregate it like someone suggests, which I hate doing, but ..) rather than null any traffic. That stops the traffic crossing your network (and if you find people policy routing it at multiple places, THEN you filter :) and lets it flow through any alternate links people might have without having to manually configure anything. Thats all I'm saying. Nice and simple. I'm not going to get drawn into a long discussion (well, a longer discussion) about something which should be simple. I don't like the idea of traffic being blackholed like that. I'd prefer it to simply be not announced. Grr, I repeated it again. You get the idea. Adrian -- Adrian Chadd "Sex Change: a simple job of outside <adrian@creative.net.au> to inside plumbing." - Some random movie
Sabri, did you not understand this...
Announcing a netblock doesn't promise that every address in that block exists or is reachable. A network that is blocked for AUP violations doesn't "exist", and usually returns the ICMP message "Unreachable -- Administratively Prohibited" specifically designed for such situations. Have you read "Router Requirements"?
It specifically states that a block can be announced but that does not guarantee that all hosts will be reachable. You buy transit from abovenet, the block in question goes against their AUP, live with it. And furthermore, how can you even begin to take part in this conversation if you haven't read all the relevant literature? I also strongly suggest you think twice before you accuse a company of "terrorism" in the future. -John Belcher
On Tue, 9 Jan 2001, John Belcher wrote:
Sabri, did you not understand this...
I am far from perfect.
Announcing a netblock doesn't promise that every address in that block exists or is reachable. A network that is blocked for AUP violations doesn't "exist", and usually returns the ICMP message "Unreachable -- Administratively Prohibited" specifically designed for such situations. Have you read "Router Requirements"?
It specifically states that a block can be announced but that does not guarantee that all hosts will be reachable. You buy transit from abovenet, the block in question goes against their AUP, live with it.
I can live with the fact that they don't route that traffic. But they should not tell me that they will...
And furthermore, how can you even begin to take part in this conversation if you haven't read all the relevant literature?
Forgive my arrogancy but I don't need "relevant literature" for an ethical question like this.
I also strongly suggest you think twice before you accuse a company of "terrorism" in the future.
What would you call it then? -- /* Sabri Berisha, non-interesting network dude. * * CCNA, BOFH, Systems admin Linux/FreeBSD */
On Tue, 9 Jan 2001, Sabri Berisha wrote:
I can live with the fact that they don't route that traffic. But they should not tell me that they will...
Did they specifically state that they would announce the particular host in question, or just the netblock itself? Because the two are very different. If you are unhappy with abovenet's policies you should switch providers, and you should not bring issues like this on a public forum...
Forgive my arrogancy but I don't need "relevant literature" for an ethical question like this.
How exactly is this an ethical question? Did you not read your terms of agreement with abovenet? I'm sorry to say but this is your problem to deal with, not abovenet's.
What would you call it then?
I suggest you go to dictionary.com and look up the word terrorism, infact let me help you out. ter.ror.ism (tr-rzm) n. The unlawful use or threatened use of force or violence by a person or an organized group against people or property with the intention of intimidating or coercing societies or governments, often for ideological or political reasons. What abovenet has done is not unlawful, all they have done is uphold their policies concerning networks they believe to be harmful, and they have not threatened force or *or* violence. Making allegations of terrorism is a very serious thing, and you could get yourself into trouble making them publicly. -John Belcher
On Tue, Jan 09, 2001, John Belcher wrote:
I can live with the fact that they don't route that traffic. But they should not tell me that they will...
Did they specifically state that they would announce the particular host in question, or just the netblock itself? Because the two are very different. If you are unhappy with abovenet's policies you should switch providers, and you should not bring issues like this on a public forum...
Forgive my arrogancy but I don't need "relevant literature" for an ethical question like this.
How exactly is this an ethical question? Did you not read your terms of agreement with abovenet? I'm sorry to say but this is your problem to deal with, not abovenet's.
[snip]
What abovenet has done is not unlawful, all they have done is uphold their policies concerning networks they believe to be harmful, and they have not threatened force or *or* violence. Making allegations of terrorism is a very serious thing, and you could get yourself into trouble making them publicly.
The question here is whether above.net are within their rights to enforce their AUP upon non-customers. vuurwerk aren't a customer. vuurwerk are a customer of uunet, not above.net . Now, if above.net are filtering someone's network who isn't a directly connected customer, that doesn't come across as "simply enforcing their AUP." I'm reading what I found at http://www.above.net/services/aug.html and it mentions "Abovenet Customers". If someone at above.net wants to point me at another document which covers their arragement with uunet, and whether they've contacted uunet or not, I'll concede. Yes, its above.net's network. They can do what they want. But guys, the box in question isn't at an _above.net customer_. Think about this before you think Sabri is smoking crack. Adrian -- Adrian Chadd "Sex Change: a simple job of outside <adrian@creative.net.au> to inside plumbing." - Some random movie
On Tue, Jan 09, 2001, Adrian Chadd wrote:
The question here is whether above.net are within their rights to enforce their AUP upon non-customers. vuurwerk aren't a customer. vuurwerk are a customer of uunet, not above.net . Now, if above.net are filtering someone's network who isn't a directly connected customer, that doesn't come across as "simply enforcing their AUP."
I understand what you are saying, but regardless, if he is a UUnet customer he should take this up with UUnet and let them deal with it. Just because he isn't a customer does not mean that abovenet should make changes to their policies. -John
sabri@bit.nl said:
ethical question like this.
I was under the misconception the 'O' in NANOG stood for 'Operations' not 'Ethics'. But this would explain lots of other posts here which I had previously considered off topic. -- Alex Bligh VP Core Network, XO Communications - http://www.xo.com/ (formerly Nextlink Inc, Concentric Network Corporation GX Networks, Xara Networks)
On Tue, 9 Jan 2001, Sabri Berisha wrote:
On Tue, 9 Jan 2001, William Allen Simpson wrote:
Sabri Berisha wrote:
I am concerned. Concerned about people and companies who think they are in the position to be net.gods and for political reasons destroy the free character of the internet.
I've been involved for over 20 years, and don't remember this "free character". Perhaps there is a language translation problem? That also applies to the use of the word "terrorism"?
"Free" as in everybody decides their own policies. "Terrorism" as in forcing your policies on someone elses network.
OK. You are obviously mistaken about how routing policy works so, lets give you a little education, free of charge. Abovenet enforces policy which blocks 194.178.232.55/32. You are a CUSTOMER of Abovenet, you obtain transit to the prefixes that pass their particular routing policy. Customers of YOURS obtain transit to prefixes that pass YOUR policy and the policies of your transit providers. If you don't like the particular routing policy of your transit provider, you are "Free" to find a new provider. It is just that simple.
Why do you want me to have read everything you have read? My point is not policy based routing or which ICMP message I get. My point is not to announce something you won't route.
It's your contention that Abovenet shouldn't announce 194.178.0.0/16 just because they are NULL routing 194.178.232.55/32 for policy reasons? You ARE confused, aren't you?
If I want to make sure my traffic gets to that host, I can set up a static route to our second uplink. But it's not *me* who should be filtering. How do I know which other hosts are being announced and blackholed?
Perhaps as a customer, instead of jousting windmills on NANOG, you should contact a sales engineer at Abovenet and request information on their routing policy. It will be much more productive. --- John Fraizer EnterZone, Inc
On Tue, 9 Jan 2001, John Fraizer wrote:
It's your contention that Abovenet shouldn't announce 194.178.0.0/16 just because they are NULL routing 194.178.232.55/32 for policy reasons? You ARE confused, aren't you?
If I receive a route from someone I presume that the whole block being announced for transit is going to be reachable, unless the actual owner of the block thinks and does otherwise. This presumtion is obviously wrong in above.net:s case, but the only way to make above.net stop doing this is obviously to stop being the customer of above.net, or stop being the customer of a customer of above.net. An interesting question is whether above.net only nullroutes 194.178.232.55/32, or do they filter packets coming FROM this IP as well, going to other destinations? That would be worse in my book. I can choose to not send my packets going to 194.178.232.55/32 thru above.net, but I have much less power in whether packets coming from 194.178.232.55/32 to my network transits above.net:s network. Personally I believe that vuurwerk.nl should ask UUNET (their upstream) top stop announcing their netblock to above, or at least prepend it a lot. That would stop above.net from transiting that /16 more than absolutely neccessary. -- Mikael Abrahamsson email: swmike@swm.pp.se
In the history of the internet, people have been trusting each other.
When? I remember the RFCs on policy based routing over a decade ago. Have you read them?
Thats rediculous. Every time you setup a peer without a access-list (and don't everyone go saying you don't do that!), you're trusting the other party not to be AS7007.
Announcing a netblock doesn't promise that every address in that block exists or is reachable. A network that is blocked for AUP violations doesn't "exist", and usually returns the ICMP message "Unreachable -- Administratively Prohibited" specifically designed for such situations. Have you read "Router Requirements"?
It's commonly accepted that if you announce a route, you can carry the packet to the intended and correct destination. Existence of the host is irrelevant; 'owning' (and I use that term loosely, ARIN) the block and delivering it to where that netblock exists. If said 'owner' wants to block, drop, blackhole, whatever the packet, then it is their option. I applaud Above for trying to cut down on the Spam. But, shouldn't that be up to UU to do, since this is a UU customer?
It seems from the email that they clearly stated that the traffic was in violation of the AUP. We all block specific sites that harm our networks. Otherwise, there would be no capacity left for our customers. It's the "policy" part, for which BGP was designed. Go read the design RFCs.
From what I can tell, it can't be in violaton of Above's AUP because that enduser isn't subscribed to a service that the Above AUP applies to; also, I doubt that UU subscribes to Above's AUP as well.
On Tue, Jan 09, 2001 at 08:31:40AM -0500, Alex wrote:
It's commonly accepted that if you announce a route, you can carry the packet to the intended and correct destination.
As much as I disagree with many of Sabri's opinions, the statement above is what one normally thinks announcing a network means: You originate it, you'll carry it. If you propogate the announcement, you'll carry it. If some party decides that they're not going to route traffic for a particular block, they should de-aggregate the announcement. Yes, I realize what this does to the routing table size. Yes, I realize what this does to reachability (generating more specifics by proxy). But you're at least being honest what you're doing with the network in question. It would be convenient if there was an agreed upon methodology for networks that filter certain hosts can inject informational routes to let people know that announcements from them are "poisoned". Perhaps this kind of thing belongs in the IRR. But forcing people to proxy deaggregate internally to deal with messy routes is just rude. Perhaps this whole thread can be summarized as, "How does one make not playing nice with each other scale?" -- Jeffrey Haas - Merit RSng project - jeffhaas@merit.edu
Hi, There is no need to deaggregate the /16 that contain nullrouted /32's. This information is (in this case) already available from AS7777 as a multihop eBGP feed. The information obtained from this feed could be used to route blocked traffic to other transit providers then abovenet. - marcel #include <disclaimer.std> On Tue, 9 Jan 2001, Jeff Haas wrote:
On Tue, Jan 09, 2001 at 08:31:40AM -0500, Alex wrote:
It's commonly accepted that if you announce a route, you can carry the packet to the intended and correct destination.
As much as I disagree with many of Sabri's opinions, the statement above is what one normally thinks announcing a network means: You originate it, you'll carry it. If you propogate the announcement, you'll carry it.
If some party decides that they're not going to route traffic for a particular block, they should de-aggregate the announcement.
Yes, I realize what this does to the routing table size. Yes, I realize what this does to reachability (generating more specifics by proxy). But you're at least being honest what you're doing with the network in question.
It would be convenient if there was an agreed upon methodology for networks that filter certain hosts can inject informational routes to let people know that announcements from them are "poisoned". Perhaps this kind of thing belongs in the IRR. But forcing people to proxy deaggregate internally to deal with messy routes is just rude.
Perhaps this whole thread can be summarized as, "How does one make not playing nice with each other scale?"
On Tue, Jan 09, 2001 at 08:07:48AM -0500, William Allen Simpson wrote:
the position to be net.gods and for political reasons destroy the free character of the internet.
I've been involved for over 20 years, and don't remember this "free character". Perhaps there is a language translation problem? That
Yeah, last time I checked, the Internet was primarily made up of privately- owned pieces of cable, hooked together through privately-owned pieces of equipment, residing in privately-owned buildings, monitored and maintained by employees of privately and shareholder-owned companies. Information may want to be free, but fiber optic cable wants to be a million US dollars per mile.
That's the idea (i.e. make it as inconvenient as possible for those who hurt the rest of the 'net). The fact that you're upset proves that it works. Don't complain here - complain to UUNet. The procedure to be removed from their filters is fairly simple, IIRC. If you expect sympathy here, you may as well bathe in honey and dive head-first into a bees'-nest. Once UUNet removes or corrects the offending user/network, you'll have the connectivity you expect, and the rest of us will have one less a-hole to worry about. :My name is Sabri. I'm just another dude involved in internetworking and I :work for a small isp in The Netherlands. : :I am concerned. Concerned about people and companies who think they are in :the position to be net.gods and for political reasons destroy the free :character of the internet. s/destroy/preserve/ :In the history of the internet, people have been trusting each other. On :the lower technical levels, great things like peering have been developed. :At the various IX'es, commercial and non-profit companies exchange :information about each others routes using BGP4 and various other routing :protocols. Exactly. :In my opinion, announcing a netblock using BGP4 is making a promise to :carry traffic to a destination within that netblock. If you feel that :parts of that network are against your ethics or AUP, you should not be :announcing such a netblock. If you do so, you will make a promise which :you do not forfill. That is not a nice thing to do in a world which is :based on trust and agreements between parties. Using any routing protocol is a promise to be able to deliver packets to a given destination. It's not just your opinion, it's rfc-documented. Above only makes such announements to those who *WANT* to listen. :I was shocked to find out that one of the larger transit providers (which :the company I work for buys transit from) is actively violating the trust :it has been given by the internetworld. Most folks at the "larger transit providers" agree with Above's approach. You wouldn't happen to be in marketing, would you? :Above.net is blocking a host in UUnet IP space. After finding out about :this we notified Above.net in The Netherlands and asked what it was about :and requested them to stop announcing the netblock if they would continue :to nullroute the host involved. After various contacts about this matter, :Above.net answered with the following statements (according to the :salesdroid it came from Paul Vixie himself): If you expect sympathy, nanog is probably not the best place to bitch about Vixie. :> 194.178.232.55/32. --> this tester is part of a /16 belonging to :> uunet, and sends traffic which is in violation of our AUG. we :> complained to uunet without any effect. if we have blocked access :> from this /32 to our backbone, we are within our rights. : :After this mail, we contacted Above.net again. They basically told us it :was for our own protection because that traffic from that host does not :comply to their AUP. We specifically told them we really don't mind them :blackholing that host but *announcing* a route for it. So far no response. Again, only those who want to listen will hear the route. Talk to your own noc.
On Tue, Jan 09, 2001 at 01:16:17PM +0100, Sabri Berisha wrote:
After this mail, we contacted Above.net again. They basically told us it was for our own protection because that traffic from that host does not comply to their AUP. We specifically told them we really don't mind them blackholing that host but *announcing* a route for it. So far no response.
More information and logs on http://www.bit.nl/~sabri/above/
bwahahaha dude, get a clue. You're learning this route because you pay abovenet to send you all the routes that they know about (transit). If you don't like abovenet's decision not to allow traffic to a certain host to pass across their network, you have three simple choices: 1) filter the route from abovenet 2) change providers 3) do nothing whinging here isn't going to do anything -- John Payne http://www.sackheads.org/jpayne/ john@sackheads.org http://www.sackheads.org/uce/ Fax: +44 870 0547954 To send me mail, use the address in the From: header
On Tue, 9 Jan 2001, John Payne wrote: [snip /32 blocked]
dude, get a clue. You're learning this route because you pay abovenet to send you all the routes that they know about (transit).
We pay Abovenet to send traffic, not to throw it away.
If you don't like abovenet's decision not to allow traffic to a certain host to pass across their network, you have three simple choices:
1) filter the route from abovenet
They should not be announcing in the first place.
2) change providers
We have multiple providers.
3) do nothing
That's always an option. Hey, they are killing all asian people, let's look the other way... Hey, they are killing russians now, let's look the other way... Hey, they are killing americans now, let's look the other way... Hey, they are killing europea EOF -- /* Sabri Berisha, non-interesting network dude. * * CCNA, BOFH, Systems admin Linux/FreeBSD */
On Tue, 9 Jan 2001, Sabri Berisha wrote:
We pay Abovenet to send traffic, not to throw it away.
And if you know they can't/won't send traffic to certain destinations, you can static route those destinations to another carrier.
1) filter the route from abovenet
They should not be announcing in the first place.
They're not really announcing...they're propogating a route someone else announced. As Vixie said, it's highly impractical to carve up a /16 (especially if it's not their space) just to avoid propogating a route for a host they don't want to carry traffic to.
That's always an option. Hey, they are killing all asian people, let's look the other way... Hey, they are killing russians now, let's look the other way... Hey, they are killing americans now, let's look the other way... Hey, they are killing europea EOF
And you're saying Above should look the other way while ORBS abuses their network? I think it's just about procmail time if this thread continues. -- ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Tue, 9 Jan 2001 jlewis@lewis.org wrote:
On Tue, 9 Jan 2001, Sabri Berisha wrote:
We pay Abovenet to send traffic, not to throw it away.
And if you know they can't/won't send traffic to certain destinations, you can static route those destinations to another carrier.
That's my point. How do I know? Do they provide a static listing with host they blackhole? Not that I know of. I only see *some* of my traffic ending up in /dev/null...
1) filter the route from abovenet
They should not be announcing in the first place.
They're not really announcing...they're propogating a route someone else announced. As Vixie said, it's highly impractical to carve up a /16 (especially if it's not their space) just to avoid propogating a route for a host they don't want to carry traffic to.
If they are able to route the host to /dev/null, they will probably be able to filter that advertisement out...
And you're saying Above should look the other way while ORBS abuses their network?
No. Why do we keep getting the ORBS discussion in this? This is about announcing and nullrouting, not mailrelaytesting.
I think it's just about procmail time if this thread continues.
That's also a nullroute ;) -- /* Sabri Berisha, non-interesting network dude. * * CCNA, BOFH, Systems admin Linux/FreeBSD */
On Tue, 9 Jan 2001, Sabri Berisha wrote:
That's my point. How do I know? Do they provide a static listing with host they blackhole? Not that I know of. I only see *some* of my traffic ending up in /dev/null...
Probably the same way you found out about this one. Somebody notices a site seems to be down only from your network and they complain. You look into it, and find that someone is filtering your traffic.
If they are able to route the host to /dev/null, they will probably be able to filter that advertisement out...
Please show us the config necessary to do that. Assume they'll be using Cisco routers running any recent version of IOS.
And you're saying Above should look the other way while ORBS abuses their network?
No. Why do we keep getting the ORBS discussion in this? This is about announcing and nullrouting, not mailrelaytesting.
Because the behavior of ORBS is the reason (I'm assuming that...I don't actually know it) that Above has null routed that IP.
I think it's just about procmail time if this thread continues.
That's also a nullroute ;)
But it's my mail, and I get to decide how to process it. :0 * ^From:.*<sabri@bit\.nl> /dev/null -- ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Tue, 09 Jan 2001 09:12:31 EST, jlewis@lewis.org said:
They're not really announcing...they're propogating a route someone else announced. As Vixie said, it's highly impractical to carve up a /16 (especially if it's not their space) just to avoid propogating a route for a host they don't want to carry traffic to.
OK.. I'll bite. Who's originally announcing the route? Is the route in question the original announcement for the ORBS site, which above.net is then passing along because it's a pain to punch a hole in a /16, but above.net then blackholes the actual traffic internal to their net? Or is the route in question a blackhole route announced by somebody else to cause routing of traffic to a blackhole? If it's the first, then it's time for procmail filters - I disagree with above.net's policy, but as long as they are up-front about it, I'll not have a religious war about it (btw - is above.net blackholing anybody else officially, and is there an on-line list of what's being blackholed?). As has been pointed out, you can always change providers or play routing games if you multi-home - but it would make it a lot easier if your providers tell you "We blackhole X Y and Z, find alternate routes yourself" so you can avoid trouble-shooting a non-problem. If it's the second, then words escape me. Although black-hole routes are an accepted part of doing business (witness Vixies's RBL BGP4 feed), they shouldn't be passed along to non-consenting peers. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
Sabri Berisha wrote:
They should not be announcing in the first place.
They aren't. Above.net has an internal blackhole route for 194.178.232.55/32, but they do not advertise it. They are within their rights for maintaining this route internally. They are not exporting the host route. I don't think this can be made any clearer. What Above.net is passing you is a route for the 194.178.0.0/16 network that they receive from UUNet. The decision to make use of this route or not is yours. You are paying them to carry your traffic, they haven't made any promises that they can't keep. They haven't tried to manipulate your routing decision by sending you a more-specific. You can't complain because you send them something that they drop for policy reasons. You agreed to their terms when you signed up. Even so, I can understand your frustration over this incident, but you've got another route, so use it. I think everyone agrees that this matter is closed. I'll let you have the last word if you'd like, but at this point, it's just going to be more noise. Mark
On Tue, 9 Jan 2001, Sabri Berisha wrote: > I am concerned about people and companies who think they are in > the position to be net.gods and for political reasons destroy the > free character of the internet. Inasmuch as there exists a "free character of the Internet," you're complaining about one of its principal promulgators and defenders. If Paul did not feel that he were free to respond to threats to his network, the quality of the internet would decline. Not just because AboveNet would be less able to preserve its ability to deliver traffic to sites which _do_ meet its AUP, but much more importantly because other people, those who don't think quite so much for themselves, would follow suit, not take an activist position, and would fail to protect their customers from threats. I don't think you're taking the side of this argument that you believe you're taking. And I think you probably want to stop replying to this thread before your name makes too permanent an impression in the minds of your peers. Cross posting something to NANOG and UUNet abuse was not good judgement. -Bill
participants (20)
-
Adrian Chadd -
Alex -
Alex Bligh -
Anne Marcel -
Bill Woodcock -
bmanning＠vacation.karoshi.com -
Brian Wallingford -
Jeff Haas -
jlewis＠lewis.org -
John Belcher -
John Fraizer -
John Payne -
Joshua Goodall -
Mark Mentovai -
Mikael Abrahamsson -
Randy Bush -
Sabri Berisha -
Shawn McMahon -
Valdis.Kletnieks＠vt.edu -
William Allen Simpson