(Apologies if this is flogging a dead horse, but some messages are worth repeating, if for no other reason than to illustrate the down side of not understanding the proper rationale for CIDR.)
I thought the dead horse was the conclusion that small ISPs should use whatever means the ARIN rules allow in order to get PI space. Having used provider-assigned space for a couple years, I can firmly say it sucks. Even if I had to talk to every tier-1 to get my de-aggregates accepted, it would be MUCH less hastle than having PA IP space. And your suggestion has technical deficiencies as well. I have a leased line between Toronto and Ottawa, so I want to announce my Ottawa IPs to my Toronto transit provider as well as an Ottawa transit provider. And the reverse for the Toronto IPs. My understand is trying to punch holes in PA space is much more difficult than de-aggregating ARIN PI space. -Ralph
On Thu, 18 Jul 2002, Ralph Doncaster wrote:
And your suggestion has technical deficiencies as well. I have a leased line between Toronto and Ottawa, so I want to announce my Ottawa IPs to my Toronto transit provider as well as an Ottawa transit provider. And the reverse for the Toronto IPs. My understand is trying to punch holes in PA space is much more difficult than de-aggregating ARIN PI space.
I can't really see why, as long as the provider has punched the appropriate hole for your aggregate in their filters. More specific routes always win out. Or am I missing your point? James Smallacombe PlantageNet, Inc. CEO and Janitor up@3.am http://3.am =========================================================================
On Thu, 18 Jul 2002, Ralph Doncaster wrote:
And your suggestion has technical deficiencies as well. I have a leased line between Toronto and Ottawa, so I want to announce my Ottawa IPs to my Toronto transit provider as well as an Ottawa transit provider. And the reverse for the Toronto IPs. My understand is trying to punch holes in PA space is much more difficult than de-aggregating ARIN PI space.
I can't really see why, as long as the provider has punched the appropriate hole for your aggregate in their filters. More specific routes always win out. Or am I missing your point?
If the block isn't assigned to you by ARIN, I've encountered cases where network operators request an LOA before accepting the announcement, even if there is an RADB entry for it. As well, if you have PA space and your upstream allocates you a 66.x for example, then you're back to square one. -Ralph
RADB is largely meaningless, in terms of authorization or authority to advertise. However, if you have a properly delegated SWIP entry for the block, few providers will request LOA. Those who do, should probably be avoided. I still like the idea of using the DNS system for this, since there are already authoritative reverse delegations. (i.e. AS to IP block mapping) - Daniel Golding
On Thu, 18 Jul 2002, Ralph Doncaster wrote:
And your suggestion has technical deficiencies as well. I have a leased line between Toronto and Ottawa, so I want to announce my Ottawa IPs to my Toronto transit provider as well as an Ottawa transit provider. And the reverse for the Toronto IPs. My understand is trying to punch holes in PA space is much more difficult than de-aggregating ARIN PI space.
I can't really see why, as long as the provider has punched the appropriate hole for your aggregate in their filters. More specific routes always win out. Or am I missing your point?
If the block isn't assigned to you by ARIN, I've encountered cases where network operators request an LOA before accepting the announcement, even if there is an RADB entry for it. As well, if you have PA space and your upstream allocates you a 66.x for example, then you're back to square one.
-Ralph
Daniel Golding wrote:
RADB is largely meaningless, in terms of authorization or authority to advertise. However, if you have a properly delegated SWIP entry for the block, few providers will request LOA. Those who do, should probably be avoided.
Largely? I like to see the SWIP, but it's not always provided. Regardless, I want to see an announcement originating from my customer directly to the owner of the block. De facto authorization. [...] Peter E. Fry
How's THIS for Verio arrogance, going to a whole new level: http://www.monkeys.com/anti-spam/filtering/verio-demand.ps Details were on the SPAM-L list Wed, 17 Jul 2002 15:51:05 EDT: Verio threatens to sue Ron Guilmette over the IP 208.55.91.59 appearing on his FormMail.pl open-proxy/formmail server DNSBL. And given the ever-increasing number of spammers now hopping onto Verio tells me that Verio must be well down the spiral of death (spammers seem to be attracted by NSP's going chapter 7/11, or who are getting close), or else the dozen-or-so automated messages going to abuse@verio.net every week complaining about connections (real or attempted) to hosts under my control, and originating from their spamming customers would have shown any results over time. I don't need connectivity to 208.55.0.0/16. I really don't, and I have not the slightest tolerance for litigious, small-minded, panic-lawyer-dialling scum like this. /etc/mail$ grep 208.55 access.local 208.55 550 Access for FormMail spam and litigious scum denied - XXXX Verio in their XXXXXXXX XXX - we block more than just 208.55.91.59 - Spammers must die - see http://www.monkeys.com/anti-spam/filtering/verio-demand.ps /etc/mail$ PS: I also have zero tolerance for Nadine-type spam-generating, "single-opt-in", "87% permission-based" emailers nowadays: 2 bounces or a single mail to a never-existing account, and all your /24's are off into gated.conf as a next-hop route to 127.0.0.1. And no, they won't get around that by advertising /25's. Good-bye route-prefix-filtering wars, and welcome to the war on spam, where Null0'd /28's for filtering 'undesirables' just doesn't cut it any more. Casualties like 10-15 bystanding rackspace.com customers with a "Nadine- type" mailer in neighboring IP space be damned: "move your servers into a different slum, cause da landlord's running down 'da neighborhood". -- "Just say No" to Spam Kai Schlichting New York, Palo Alto, You name it Sophisticated Technical Peon Kai's SpamShield <tm> is FREE! http://www.SpamShield.org | | LeasedLines-FrameRelay-IPLs-ISDN-PPP-Cisco-Consulting-VoiceFax-Data-Muxes WorldWideWebAnything-Intranets-NetAdmin-UnixAdmin-Security-ReallyHardMath
How is it arrogant? I read that as: a customer set up an exploitable FormMail. Verio received notice about it. Verio removed the FormMail in question. Verio asked to be removed since they corrected the problem. Verio was ignored. Verio may have some problems with not terminating spammers, and I believe this to be the truth -- I buy from verio, and Don't spam, and whenever one of my clients spam, they get terminated for it. I receive plenty of spam from verio ips, and no matter how much I complain, it never gets terminated. This is probably a scenario of asking sales rep "If I want to spam, but I pay more per meg -- Is this OK?" and getting a positive answer. That is why the NANAE people don't like verio. But, nonetheless, I don't think that putting verio's mailserver on a formmail list is accomplishing anything good, since they fixed THAT problem... --Phil -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Kai Schlichting Sent: Thursday, July 18, 2002 6:37 PM To: nanog@merit.edu Cc: Kai Schlichting Subject: Re: verio arrogance How's THIS for Verio arrogance, going to a whole new level: http://www.monkeys.com/anti-spam/filtering/verio-demand.ps Details were on the SPAM-L list Wed, 17 Jul 2002 15:51:05 EDT: Verio threatens to sue Ron Guilmette over the IP 208.55.91.59 appearing on his FormMail.pl open-proxy/formmail server DNSBL. And given the ever-increasing number of spammers now hopping onto Verio tells me that Verio must be well down the spiral of death (spammers seem to be attracted by NSP's going chapter 7/11, or who are getting close), or else the dozen-or-so automated messages going to abuse@verio.net every week complaining about connections (real or attempted) to hosts under my control, and originating from their spamming customers would have shown any results over time. I don't need connectivity to 208.55.0.0/16. I really don't, and I have not the slightest tolerance for litigious, small-minded, panic-lawyer-dialling scum like this. /etc/mail$ grep 208.55 access.local 208.55 550 Access for FormMail spam and litigious scum denied - XXXX Verio in their XXXXXXXX XXX - we block more than just 208.55.91.59 - Spammers must die - see http://www.monkeys.com/anti-spam/filtering/verio-demand.ps /etc/mail$ PS: I also have zero tolerance for Nadine-type spam-generating, "single-opt-in", "87% permission-based" emailers nowadays: 2 bounces or a single mail to a never-existing account, and all your /24's are off into gated.conf as a next-hop route to 127.0.0.1. And no, they won't get around that by advertising /25's. Good-bye route-prefix-filtering wars, and welcome to the war on spam, where Null0'd /28's for filtering 'undesirables' just doesn't cut it any more. Casualties like 10-15 bystanding rackspace.com customers with a "Nadine- type" mailer in neighboring IP space be damned: "move your servers into a different slum, cause da landlord's running down 'da neighborhood". -- "Just say No" to Spam Kai Schlichting New York, Palo Alto, You name it Sophisticated Technical Peon Kai's SpamShield <tm> is FREE! http://www.SpamShield.org | | | LeasedLines-FrameRelay-IPLs-ISDN-PPP-Cisco-Consulting-VoiceFax-Data-Muxe s WorldWideWebAnything-Intranets-NetAdmin-UnixAdmin-Security-ReallyHardMat h
I can't really see why, as long as the provider has punched the appropriate hole for your aggregate in their filters. More specific routes always win out. Or am I missing your point?
The point, I think, is the effort involved in using global route announcements to solve your traffic engineering problems. When you use provider-assigned space, you have to coordinate your intent to add entries to the global routing table with the provider who assigned the space and the providers that you want to accept the new routes. When you use provider-independent space, you get to decide to add entries to the global routing table pretty much all by yourself, modulo running afoul of the occasional provider that does not, by default, buy into solving local traffic engineering problems in other people's networks using global routing table entries. Stephen
In the referenced message, Stephen Stuart said:
I can't really see why, as long as the provider has punched the appropriate hole for your aggregate in their filters. More specific routes always win out. Or am I missing your point?
The point, I think, is the effort involved in using global route announcements to solve your traffic engineering problems.
When you use provider-assigned space, you have to coordinate your intent to add entries to the global routing table with the provider who assigned the space and the providers that you want to accept the new routes.
When you use provider-independent space, you get to decide to add entries to the global routing table pretty much all by yourself, modulo running afoul of the occasional provider that does not, by default, buy into solving local traffic engineering problems in other people's networks using global routing table entries.
Stephen
Not to mention that the common retort is that everyone else in the world should upgrade their CPU and memory to solve a third parties traffic engineering problem. Thereby transferring the cost to others. The verio (and others) mechanism involves a stated policy soundly derived based upon RiR allocation policy. A policy which, if everyone announced their aggregates would lead to no blackholes during steady-state. If parties feel the need to exchange long prefixes, they can do so privately, without infecting everyone. In fact, many providers exchange regional routes, tagged no-export, for such mutual agreed-upon optimal traffic exchange purposes. This should, however, be constrained to those parties who mutually agree upon it. However, there are some who want to handle their traffic engineering needs preferably by transferring the costs to others. This is just shady, even if it makes perfect "business sense" from a capitalistic "maximize profit no matter what the consequences" mind set. I wonder how the anti-filter folks would feel if all of their providers/peers ceased filtering out iBGP routes on the sessions facing them. Would they begin scrambling to filter? If so, where would the line be drawn? Some arbitrary prefix-length, or based upon a published length obtained from some allocation authority? What about if everyone ceased filtering out their iBGP routes, and just leaked it all? Looking at only a single router, I could add another 8538 prefixes into the routing system. Certainly everyone could handle 9k more prefixes, right? Ok, then we get to do that across all my routers. Then across all providers. This is all in the name of optimal routing, right? What's a couple million routes between friends?
This is all great and wonderful, except for one thing - the RIR allocation boundaries were never really meant to be used as "official" filtering prefix length limits. I certainly support Verio's right to filter on whichever boundaries make business sense to them. However, there is no denying that they have long been on the conservative side of filtering, and that this has caused problems for their peer's customers. Their policy causes a certain amount of difficulty for smaller multihomers, who may not have a RIR allocation. Currently, RIR's will issue an AS and will allow the issuance of a /24 to a multihomed enterprise, simply on the basis of being multihomed. From this point of view, it's easy to make the case that the proper "RIR-approved" boundary for prefix filtering should be at the /24 level. At any rate, Verio has been slowly liberalizing their filtering policy, and bring it into line with the rest of the industry. Two other things to consider, when discussing the economic impact of routing table size. When a carrier already is buying routers with sufficient memory to handle a very large routing table, the "cost savings" of a smaller routing table are illusory. The other thing to consider is that technically intensive support calls are relatively expensive to the provider receiving them, so that policies which encourage such calls should be looked at very carefully. This cuts both ways right now, as having enough routes to break BGP on a customer's 3640 will generate a support call, while causing reachability problems to people who lack clue to properly advertise their routes will also generate support calls. - Daniel Golding
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Stephen Griffin Sent: Friday, July 26, 2002 10:24 PM To: Stephen Stuart Cc: nanog@merit.edu Subject: Re: verio arrogance
In the referenced message, Stephen Stuart said:
I can't really see why, as long as the provider has punched the appropriate hole for your aggregate in their filters. More specific routes always win out. Or am I missing your point?
The point, I think, is the effort involved in using global route announcements to solve your traffic engineering problems.
When you use provider-assigned space, you have to coordinate your intent to add entries to the global routing table with the provider who assigned the space and the providers that you want to accept the new routes.
When you use provider-independent space, you get to decide to add entries to the global routing table pretty much all by yourself, modulo running afoul of the occasional provider that does not, by default, buy into solving local traffic engineering problems in other people's networks using global routing table entries.
Stephen
Not to mention that the common retort is that everyone else in the world should upgrade their CPU and memory to solve a third parties traffic engineering problem. Thereby transferring the cost to others.
The verio (and others) mechanism involves a stated policy soundly derived based upon RiR allocation policy. A policy which, if everyone announced their aggregates would lead to no blackholes during steady-state.
If parties feel the need to exchange long prefixes, they can do so privately, without infecting everyone. In fact, many providers exchange regional routes, tagged no-export, for such mutual agreed-upon optimal traffic exchange purposes. This should, however, be constrained to those parties who mutually agree upon it.
However, there are some who want to handle their traffic engineering needs preferably by transferring the costs to others. This is just shady, even if it makes perfect "business sense" from a capitalistic "maximize profit no matter what the consequences" mind set.
I wonder how the anti-filter folks would feel if all of their providers/peers ceased filtering out iBGP routes on the sessions facing them. Would they begin scrambling to filter? If so, where would the line be drawn? Some arbitrary prefix-length, or based upon a published length obtained from some allocation authority? What about if everyone ceased filtering out their iBGP routes, and just leaked it all? Looking at only a single router, I could add another 8538 prefixes into the routing system. Certainly everyone could handle 9k more prefixes, right? Ok, then we get to do that across all my routers. Then across all providers. This is all in the name of optimal routing, right? What's a couple million routes between friends?
This is all great and wonderful, except for one thing - the RIR allocation boundaries were never really meant to be used as "official" filtering prefix length limits. I certainly support Verio's right to filter on whichever boundaries make business sense to them. However, there is no denying that they have long been on the conservative side of filtering, and that this has caused problems for their peer's customers. Their policy causes a certain amount of difficulty for smaller multihomers, who may not have a RIR allocation.
It only causes problems, under the majority of circumstances, when people fail to announce their largest aggregate. If they announce their RIR provided aggregates, then there is no problem. The RIRs provide lists of their smallest allocation sizes, which facilitates locking into a certain expected prefix-length. While it may not be "official", it is certainly a good cross-pollination of data, which is probably why the RIRs send notifications here when they change their allocation policies. Everyone I've seen who bases their filters off of RIR allocation guidelines does so slightly more loosely than the guidelines themselves. IMHO, this is better than simply drawing a one-size-fits-all line in the sand. If you permit /24 across the board, you may as well not filter, as that is where the greatest amount of crap is (according to what I've seen). If you permit /23 across the board, you'll filter out those folks living in chunks where the RIRs have assigned /24s leading to blackholes of the cluefull. As such, some correspondence to RIR policy is advantageous in fine-tuning the filtering to make sure you don't filter out legitimate folks for which there is no greater aggregate, while filtering out those who (un)intentionally abuse BGP. If the RIRs were to begin allocating space from specially designated "multihomer" blocks, for such small multihomers, I don't see that those who presently filter based upon RIR policy would have a problem. Also, the small multihomer wouldn't have a problem, and the present degree of dishonesty expressed to get "large PI blocks" would hopefully subside. I believe RIPE is presently doing just this type of thing. However, RIR policy is up to the RIRs. The only drawback I've seen is the unfortunate case where a small multihomer can be partitioned away when their connectivity to the provider who allocated them some PA space goes away. However, there are means through which the small multihomer may use to rectify that situation (which don't involve dishonesty). RFC2260 is one such way. Again, if there were a range dedicated purely to the small multihomer, the filters could be updated to account for that policy, and there would be no issue even outside steady-state. Between permitting small PI blocks to small multihomers, and slightly looser than RIR guidelines for the remainder, there would be few innocent victims, there would still be controls over folks attempting to use BGP to offset their TE, and well the clueless would remain clueless, but there's not much you can do about them.
Currently, RIR's will issue an AS and will allow the issuance of a /24 to a multihomed enterprise, simply on the basis of being multihomed. From this point of view, it's easy to make the case that the proper "RIR-approved" boundary for prefix filtering should be at the /24 level. At any rate, Verio has been slowly liberalizing their filtering policy, and bring it into line with the rest of the industry.
If the RIR is issuing /24s, then they denote such on their minimum allocation lists, allowing providers to accept /24s from such blocks.
(SNIP)
Currently, RIR's will issue an AS and will allow the issuance of a /24 to a multihomed enterprise, simply on the basis of being multihomed. From this point of view, it's easy to make the case that the proper "RIR-approved" boundary for prefix filtering should be at the /24 level. At any rate, Verio has been slowly liberalizing their filtering policy, and bring it into line with the rest of the industry.
If the RIR is issuing /24s, then they denote such on their minimum allocation lists, allowing providers to accept /24s from such blocks.
I think you may have misread my comment. ARIN ALLOWS the issuance of /24s to multihomed enterprises. The recent policy decision was made to allow upstreams to do this sort of allocation, without having to receive any other justification, other than multihomed status. This could seem to be RIR recognition of /24 as the globally routed "common denominator" - for those who insist on basing their filter policies on ARIN guidelines. :) It's often comforting to believe that there is a little more order than chaos on the internet, that there are standards or professional bodies out there to make law or proscribe best practice. However, this is simply not the case. ARIN and it's brethren are simply there to hand out numbers, not to provide a guideline on or even suggestion how to filter prefixes. Of course, we can all decide on our own, based on business imperatives, the best way to do that. I just hate to see people thinking that there is some sort of unspoken correlation between ARIN issuance guidelines and "best practice" filtering. - Dan
I think you may have misread my comment. ARIN ALLOWS the issuance of /24s to multihomed enterprises. The recent policy decision was made to allow upstreams to do this sort of allocation, without having to receive any other justification, other than multihomed status. This could seem to be RIR recognition of /24 as the globally routed "common denominator" - for those who insist on basing their filter policies on ARIN guidelines. :)
ARIN also _allows_ the issuance of /32s to anyone. They, however, do not issue /32s directly, nor do they issue /24s to multihomed entities directly, without heavy justification. As such, the ARIN allocation would be the larger aggregate from which the /24 is carved. If ARIN were to (as I believe RIPE is presently doing or trialing) begin assigning controlled amounts of small multihomer space from a specific netblock, then we could filter knowing roughly what the longest prefix is which contains the largest aggregates of all assignments. However, this would be up to the RIR, and they certainly don't have to do it. The RIR published data provides just that: They say for a specific range what the longest prefix is which is expected to not be further aggregatable. As such, responsible filterers will know: 1) at what point, if they were to filter, they would be likely to filter away folks who CAN NOT further aggregate (which is bad) 2) at what point, if they were to cease filtering, they would be receiving ONLY more-specifics. The onus then moves to the assignees to announce their largest aggregates, and should they choose to deaggregate beyond that to /32, becomes a moot point (except to those who don't filter). Anyway, I'm done, if anyone wants to discuss this further with me, mail me direct.
participants (10)
-
bdragon＠gweep.net -
Daniel Golding -
Daniel Golding -
Kai Schlichting -
Peter E. Fry -
Phil Rosenthal -
Ralph Doncaster -
Stephen Griffin -
Stephen Stuart -
up＠3.am