After this mail, we contacted Above.net again. They basically told us it was for our own protection
no.
because that traffic from that host does not comply to their AUP.
yes.
We specifically told them we really don't mind them blackholing that host but *announcing* a route for it. So far no response.
you expect abovenet to cut uunet's /16 into pieces so as to avoid sending to its customers the parts which violate abovenet's acceptable use guidelines? even if this were a scalable approach (considering the number of /16's which have violating /32's inside them, or will in the future), it's something i'd expect the owner of the /16 to take issue with. why are we discussing this on nanog? Paul Vixie <pvixie@mmfn.com> CTO and SVP, MFN (NASDAQ: MFNX)
On Tue, 9 Jan 2001, Paul A Vixie wrote: (you reply fast ;)
After this mail, we contacted Above.net again. They basically told us it was for our own protection
no.
Yes, on the phone actually by the women who contacted you in the first place...
because that traffic from that host does not comply to their AUP.
yes.
I can live with that. But stop announcing it...
We specifically told them we really don't mind them blackholing that host but *announcing* a route for it. So far no response.
you expect abovenet to cut uunet's /16 into pieces so as to avoid sending to its customers the parts which violate abovenet's acceptable use guidelines? even if this were a scalable approach (considering the number of /16's which have violating /32's inside them, or will in the future), it's something i'd expect the owner of the /16 to take issue with.
What I would expect is that you would choose between two things: 1. you blackhole but do NOT announce those netblocks; 2. you annonce AND deliver traffic to every host in it; Don't you agree that announcing means delivering traffic? Especially for customers.
why are we discussing this on nanog?
Because Above.net seems violates the first thing needed in internetworking: trust. If you tell me you will deliver traffic to $blah, I think I may expect you to do so. That's my whole point. Nullroute as much as you want but don't announce it on your border routers... -- /* Sabri Berisha, non-interesting network dude. * * CCNA, BOFH, Systems admin Linux/FreeBSD */
On Tue, 9 Jan 2001, Sabri Berisha wrote: :I can live with that. But stop announcing it... : Stop listening to the announcement. Or, are you upset that others are copasetic with Abovenet's policy?
Filter out any /24 - /32 announcement you hear from above.net. It's ugly but will help keep the route out of your table. - Jared On Tue, Jan 09, 2001 at 08:29:44AM -0500, Brian Wallingford wrote:
On Tue, 9 Jan 2001, Sabri Berisha wrote: :I can live with that. But stop announcing it... :
Stop listening to the announcement.
Or, are you upset that others are copasetic with Abovenet's policy?
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE | Manager of IP networks built within my own home
I would say that filtering anything longer than a /24 from another provider is probably standard practice, or at least should be. Brian Whalen On Tue, 9 Jan 2001, Jared Mauch wrote:
Filter out any /24 - /32 announcement you hear from above.net.
It's ugly but will help keep the route out of your table.
- Jared
On Tue, Jan 09, 2001 at 08:29:44AM -0500, Brian Wallingford wrote:
On Tue, 9 Jan 2001, Sabri Berisha wrote: :I can live with that. But stop announcing it... :
Stop listening to the announcement.
Or, are you upset that others are copasetic with Abovenet's policy?
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE | Manager of IP networks built within my own home
On Tue, 9 Jan 2001, Jared Mauch wrote:
Filter out any /24 - /32 announcement you hear from above.net.
It's ugly but will help keep the route out of your table.
From what I understand of this silly business, the /32 blackhole route
isn't being advertised by Abovenet and so isn't in the local table at all. The /16 being propagated IS, however, and traffic for that host is following that route via his Abovenet upstream connection (at which point it's then discarded within Abovenet's network). I wasn't aware Abovenet were forcing anyone to buy transit from then, or forcing any of their downstreams to not use filters to block that particular /16 announcement - is there something in the T&Cs I've not noticed?? Of course, if Abovenet's policy is so abhorrent, I'm sure when they lose their last paying transit customer they'll wake up to their longtime folly ;) -- Patrick Evans - Net bloke, indie kid and lemonade drinker pre at pre dot org www dot pre dot org
Because it seems we have denigrated to finger pointing and attacking members of the list, in spite of the condenses opinion that we would not do this to each other. net.terrorism is a very poor choice of word since no carrier is required to carry traffic that is deemed harmful to its downstream client's and to use this list to blackmail or harm anyone's interest violates the operational fabric of the entire group. This is shameful and unprofessional in my humble opinion and should cease now. Paul A Vixie wrote:
After this mail, we contacted Above.net again. They basically told us it was for our own protection
no.
because that traffic from that host does not comply to their AUP.
yes.
We specifically told them we really don't mind them blackholing that host but *announcing* a route for it. So far no response.
you expect abovenet to cut uunet's /16 into pieces so as to avoid sending to its customers the parts which violate abovenet's acceptable use guidelines? even if this were a scalable approach (considering the number of /16's which have violating /32's inside them, or will in the future), it's something i'd expect the owner of the /16 to take issue with.
why are we discussing this on nanog?
Paul Vixie <pvixie@mmfn.com> CTO and SVP, MFN (NASDAQ: MFNX)
-- Thank you; |--------------------------------| | Thinking is a learned process. | | ICANN member @large | | Gigabit over IP, ieee 802.17 | | working group | | Resilient Packet Transport | |--------------------------------| Henry R. Linneweh
"Henry R. Linneweh" wrote:
Because it seems we have denigrated to finger pointing and attacking members of the list, in spite of the concenses opinion that we would not do this to each other. net.terrorism is a very poor choice of words since no carrier is required to carry traffic that is deemed harmful to its downstream client's and to use this list to blackmail or harm anyone's interest violates the operational fabric of the entire group.
This is shameful and unprofessional in my humble opinion and should cease now.
Paul A Vixie wrote:
After this mail, we contacted Above.net again. They basically told us it was for our own protection
no.
because that traffic from that host does not comply to their AUP.
yes.
We specifically told them we really don't mind them blackholing that host but *announcing* a route for it. So far no response.
you expect abovenet to cut uunet's /16 into pieces so as to avoid sending to its customers the parts which violate abovenet's acceptable use guidelines? even if this were a scalable approach (considering the number of /16's which have violating /32's inside them, or will in the future), it's something i'd expect the owner of the /16 to take issue with.
why are we discussing this on nanog?
Paul Vixie <pvixie@mmfn.com> CTO and SVP, MFN (NASDAQ: MFNX)
--
Thank you; |--------------------------------| | Thinking is a learned process. | | ICANN member @large | | Gigabit over IP, ieee 802.17 | | working group | | Resilient Packet Transport | |--------------------------------| Henry R. Linneweh
-- Thank you; |--------------------------------| | Thinking is a learned process. | | ICANN member @large | | Gigabit over IP, ieee 802.17 | | working group | | Resilient Packet Transport | |--------------------------------| Henry R. Linneweh
Subject: Re: net.terrorism Date: Tue, 09 Jan 2001 04:37:37 -0800 From: Paul A Vixie <vixie@mfnx.net> [...] why are we discussing this on nanog?
Well, it sounds like an operational issue. As described in the original post, a group is disrupting Internet connectivity to some destinations to achieve certain policy objectives. This has a number of adverse implications. o Policy-based "disconnectivity", like any other source of connectivity problems, makes the Internet appear less reliable and less predictable to the end user. Only a relatively sophisticated end user can differentiate broken connectivity caused by policies from other sources of connectivity problems. Adding yet another cause of difficult-to-diagnose connectivity problems hardly seems like a good thing. o Whatever the official marketing literature may say, the effectiveness of routing-based disconnectivity is generally based to a large extent on inflicting pain on third parties. That is, if the policy-based disconnectivity causes enough pain to enough people, then the originating network or ISP will have an incentive ("be forced") to remove the activity that violates the policy. This basic strategy hardly seems like a good thing. o Policy-based disconnectivity techniques would appear to set a bad precedent. That is, this activity tends to legitimize the use by ISPs of black-hole routing to enforce various acceptable use policies. To the extent that the network community endorses black-hole routing as an acceptable tool for enforcing anti-spam policies, the technique is more likely to be applied in the enforcement of other policies. For example, French courts could conceivably decree a policy-based disconnectivity solution to protect users in France from auction sites selling Nazi memorabilia (i.e., Yahoo). (After all, if the technique is acceptable for relatively minor social ills like spam, then surely it is acceptable to use it for more significant social problems). German courts could conceivably require German ISPs to black-hole foreign "hate" sites. (By the way, I believe that a number of prominent organizations have taken stands against the filtering based on content of certain foreign sites by some totalitarian countries. I don't think these organizations are are saying that it is wrong to filter based on political content, but OK to filter on, for example, less-political content such as spam. ) I believe that legitimizing the use of "disconnectivity" techniques (whether they are routing-based or filter-based and whether they are "voluntary" [voluntary to whom?] or mandatory) to further policy objectives is a really bad thing. It is not altogether obvious to me that the cure is not worse than the disease in this case. -tjs
"Timothy J. Salo" wrote:
Well, it sounds like an operational issue.
As described in the original post, a group is disrupting Internet connectivity to some destinations to achieve certain policy objectives. This has a number of adverse implications.
And goes on to list somewhat irrelevant issues, none of which are applicable in this case. Look here -- we are talking about violation of "acceptable-use policy" (AUP for short). In this matter, we are talking about harm to our operations (specifically, our mail servers). Now, last year, we had virus problem(s) -- remember? And that virus queried a web site for its update -- remember? I don't know what you folks did, but I had my staff quickly hand code an addition to the access lists, and apply it to every POP router in our net. And then, I called my upstreams and asked that they add a block in front of us. I'm sure that some users were confused by any badly worded notices in their MUAs about lack of connectivity. But not as many as would have complained that mail was down! And I'd rather that it was pain on irresponsible third parties, than on my support staff. That costs money. I'd be willing to bet that site is still blocked in our lists. I've never checked. And it may not be the sites' fault that irresponsible users targeted the site for the virus update. But the effect will last for a long long time. The ORBS sites were frequently polling my mail servers. It costs bandwidth and processing time. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
On Wed, Jan 10, 2001 at 01:41:39PM -0600, Timothy J. Salo wrote:
I believe that legitimizing the use of "disconnectivity" techniques (whether they are routing-based or filter-based and whether they are "voluntary" [voluntary to whom?] or mandatory) to further policy objectives is a really bad thing.
It is not altogether obvious to me that the cure is not worse than the disease in this case.
What I find interesting is how different the technique is viewed based on the nature of the "problem" or "violation". For instance, "null routing" a small bit of address space is a well known way to do all of the following: * Stop part of a flooding attack. * Stop runway/resource hogging machines. * Temporarily disable "owned" machines. * Block open mail relays. * Block servers originating spam. * Block web servers supporting illegal/unacceptable content. * Be vindictive against the people who flamed you on nanog. * Attempt to persecute groups you don't like. If someone called their provider because they were being flooded in a smurf attack, or syn-flood, or similar and the provider told them they couldn't null route, filter, or otherwise alter the traffic that customer would probably be rather unhappy. As we've seen from this flood of e-mail, there are clearly people who view using the same techniques of null routing or filtering with the same distain as murder when applied to an abusive open relay scanner. "Disconnectivity" techniques are quite necessary, and legitimate in day to day operations. The problem is not with the technique, but with some of the content decisions made, and how well people are notified that they might be made. Many ISP's filter port 25 on all their dial ups, except to their own mail servers to cut down on spam. They generally also clearly state that they do this in their T&C's. If you want port 25 to go through, don't sign up with someone who does this for you. One thing that is very clear is that there is no consensus on where the lines in the sand should be drawn. Some people get paranoid of you send them a single packet, others will let you flood all day as acceptable behavior. For some, filtering mail servers is "content filtering", for others it is "infrastructure protection". Most of the arguments one way or another are pretty subjective, and colored by people's personal experiences. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
participants (10)
-
Brian W. -
Brian Wallingford -
Henry R. Linneweh -
Jared Mauch -
Leo Bicknell -
Patrick Evans -
Paul A Vixie -
Sabri Berisha -
Timothy J. Salo -
William Allen Simpson