-----Original Message----- From: Berislav Todorovic [mailto:beri@kpnqwest.net] Sent: Wednesday, July 10, 2002 6:38 AM To: Hank Nussbacher Cc: Christopher Sharp; lir-wg@ripe.net Subject: Re: [lir-wg] AS Number Policy
On Wed, 10 Jul 2002, Hank Nussbacher wrote:
I'd like to make a suggestion. Since these ASNs and IP blocks are the property of the RIRs, and since organizations are cybersquatting on these resources why shouldn't these RIRs advertise these IP blocks and ASNs themselves and blackhole them to their routers?
I'd like to back this idea!
However, even if ICANN itself suddenly gets stroken by lightning of technical wisdom and starts announcing unused /8's - that won't prevent offenders from announcing more specific routes, will it? On the other hand, announcing /24's will really pollute the global routing table, which is big enough anyway.
I don't think to blackholing traffic is a good idea, especially when bandwidth means money in today's internet. RIRs should publish a list to include all the offending prefixes and the major ISPs will be more than happy to apply the prefix filter to block transit to those prefixes. There is already an IANA bogon filter floating around. RIPE NCC could add a filter-set object, let's say FLTR-RIPE-RESERVED-IPV4 and ARIN should have a FLTR-ARIN-RESERVED-IPV4 object, APNIC also should have a FLTR-APNIC-RESERVED-IPV4 object. Then all major ISPs could apply these filter to block transit traffic for these prefixes.
Still, having a service like Paul Vixie's AS7777 would help a lot: an ISP willing to receive blackhole routes would bring a route server on their backbone, establish a peering session with "IANA blackhole AS" and use the routes to construct filters etc.
Regards, Beri
Blocking is a better idea than blackholing.... Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu@cw.net
On Wed, 10 Jul 2002 11:22:29 -0400, "Lu, Ping" <PLu@cw.net> wrote:
I don't think to blackholing traffic is a good idea, especially when bandwidth means money in today's internet.
I agree. Neither do I think the community should be paying to provide the bandwidth for such a service. Encouraging people to filter out these netblocks/ASNs does make it very hard to re-allocate them in the short term. However, most people who maintain good bogon filters also update them frequently, so hopefully would remove any such filters in plenty of time for ASNs to be re-allocated after 12/24/36 months.
RIRs should publish a list to include all the offending prefixes and the major ISPs will be more than happy to apply the prefix filter to block transit to those prefixes. There is already an IANA bogon filter floating around.
This was my suggestion in a nutshell. I believe the most commonly observed bogon list is maintained by Rob Thomas (http://www.cymru.com/Documents/bogon-list.html). draft-iana-special-ipv4-03 is IANA's most comprehensive list of special use netblocks (http://www.ietf.org/internet-drafts/draft-iana-special-ipv4-03.txt).
RIPE NCC could add a filter-set object, let's say FLTR-RIPE-RESERVED-IPV4 and ARIN should have a FLTR-ARIN-RESERVED-IPV4 object, APNIC also should have a FLTR-APNIC-RESERVED-IPV4 object. Then all major ISPs could apply these filter to block transit traffic for these prefixes.
This sounds excellent but doesn't cover prefixes IANA have not yet allocated to an RIR. This is why I would encourage frequent sharing of this data with the networking community and especially the maintainers of public bogon lists on which many people filter.
Blocking is a better idea than blackholing....
C.
--On Wednesday, July 10, 2002 15:32:02 +0000 Christopher Sharp <ripe-lir-wg@chriss.net> wrote:
Then all major ISPs could apply these filter to block transit traffic for these prefixes.
This sounds excellent but doesn't cover prefixes IANA have not yet allocated to an RIR. This is why I would encourage frequent sharing of this data with the networking community and especially the maintainers of public bogon lists on which many people filter.
On a side note - can we also get those major ISPs to filter packets received from their customers based on the from address? Best regards, - kurtis -
On Thu, 11 Jul 2002 11:31:57 +0200, Kurt Erik Lindqvist <kurtis@kurtis.pp.se> wrote:
On a side note - can we also get those major ISPs to filter packets received from their customers based on the from address?
You could try :-) The argument I normally hear is that people want to be lenient to customers but tough on outsiders. Hence bogon filters invariably get placed on ingress peering points rather than customer interfaces of which there are far more. C.
--On Thursday, July 11, 2002 11:23:59 +0000 Christopher Sharp <ripe-lir-wg@chriss.net> wrote:
On Thu, 11 Jul 2002 11:31:57 +0200, Kurt Erik Lindqvist <kurtis@kurtis.pp.se> wrote:
On a side note - can we also get those major ISPs to filter packets received from their customers based on the from address?
You could try :-)
The argument I normally hear is that people want to be lenient to customers but tough on outsiders. Hence bogon filters invariably get placed on ingress peering points rather than customer interfaces of which there are far more.
Interesting thing is that I am pretty sure that those large ISPs abuse groups are probaly more busy with dealing with the effects of not filtering customers, than their NOCs are with dealing with the effects from not filtering bogon routes... - kurtis -
On Thu, 11 Jul 2002, Kurt Erik Lindqvist wrote:
--On Thursday, July 11, 2002 11:23:59 +0000 Christopher Sharp <ripe-lir-wg@chriss.net> wrote:
On Thu, 11 Jul 2002 11:31:57 +0200, Kurt Erik Lindqvist <kurtis@kurtis.pp.se> wrote:
On a side note - can we also get those major ISPs to filter packets received from their customers based on the from address?
You could try :-)
The argument I normally hear is that people want to be lenient to customers but tough on outsiders. Hence bogon filters invariably get placed on ingress peering points rather than customer interfaces of which there are far more.
Interesting thing is that I am pretty sure that those large ISPs abuse groups are probaly more busy with dealing with the effects of not filtering customers, than their NOCs are with dealing with the effects from not filtering bogon routes...
In addition, I fail to see what _leniency_ here is. If the ISP doesn't do ingress filtering from the direction of the customer, it will be done somewhere in the internet anyway. Is it not _better_ for the customer to get the block immediately (e.g. in the case of misconfigured addresses), rather than have to wait for someone distant to do it. They won't be getting return packets _anyway_... -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
If the ISP doesn't do ingress filtering from the direction of the customer, it will be done somewhere in the internet anyway. Is it not _better_ for the customer to get the block immediately (e.g. in the case of misconfigured addresses), rather than have to wait for someone distant to do it. They won't be getting return packets _anyway_...
Well, if all those packets get filtered somewhere else in the network, that part has surely never been in the path to the networks I worked for. We have always seen DoS attacks with forged source addresses. ...and I think that having the customer wait is better than have a few networks cripple under load. - kurtis -
On Thu, 11 Jul 2002, Kurt Erik Lindqvist wrote:
If the ISP doesn't do ingress filtering from the direction of the customer, it will be done somewhere in the internet anyway. Is it not
^^^
_better_ for the customer to get the block immediately (e.g. in the case of misconfigured addresses), rather than have to wait for someone distant to do it. They won't be getting return packets _anyway_...
Oops, I made a drastic typo when editing the message. Cut off that 'not', so we agree.
Well, if all those packets get filtered somewhere else in the network, that part has surely never been in the path to the networks I worked for. We have always seen DoS attacks with forged source addresses.
We perform additional form of filtering at our border routers to upstreams and peerings (for ingress, check that our addresses are not listed; for egress, we drop packets with private and other martian addresses just to be sure). This does not, naturally help with identifying spoofed DoS attacks reliably. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
Hi, On Thu, Jul 11, 2002 at 11:23:59AM +0000, Christopher Sharp wrote:
The argument I normally hear is that people want to be lenient to customers but tough on outsiders. Hence bogon filters invariably get placed on ingress peering points rather than customer interfaces of which there are far more.
Crappy argument. You can't do reverse path filtering on peering points (after all, most of the world's IP range is "outside"). The *only* thing that works is strict anti-spoofing filters on all customer lines. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45809 (45931) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Thu, 11 Jul 2002 15:07:23 +0200, Gert Doering <gert@space.net> wrote:
On Thu, Jul 11, 2002 at 11:23:59AM +0000, Christopher Sharp wrote:
The argument I normally hear is that people want to be lenient to customers but tough on outsiders. Hence bogon filters invariably get placed on ingress peering points rather than customer interfaces of which there are far more.
Crappy argument. You can't do reverse path filtering on peering points (after all, most of the world's IP range is "outside").
The *only* thing that works is strict anti-spoofing filters on all customer lines.
We all know that it's a crappy argument, but lots of people try using it. Especially those who have large legacy implementations that either don't have or don't support filters on customer lines. Over the years I have seen a lot of providers who let their customers advertise whatever they want into their internal route tables. I've seen customers of "tier-1" providers with multiple circuits routing RFC1918 space between their offices, across 1000s of miles over the providers cloud. Sure it's caught by egress filters on the ISPs borders (in most cases) and most ISPs filter their new customer interfaces, but there are plenty of legacy configurations out there that the older players are frightened to break. Bogon filtering at ingress points is something that people are doing. There might be plenty of other things they should be doing, but many people aren't. In my experience customer line filters (where they exist) are rarely updated, whilst ingress bogon filters on peering connections are well maintained. If you want to encourage people to add filters and maintain them responsibly then this is the best place for them. Filtering these renegade addresses should only be a last resort. It will make re-allocation of them a lot harder. The threat of such filters would be an excellent incentive for people to return ASNs and address space when requested though. C.
We all know that it's a crappy argument, but lots of people try using it. Especially those who have large legacy implementations that either don't have or don't support filters on customer lines.
I agree with you. Still, the common argument is that it's to complex to maintain and to expensive to install. But again, I am sure the cost of dealing with the effects is close to the same amount. But few people realise this.
Over the years I have seen a lot of providers who let their customers advertise whatever they want into their internal route tables. I've seen
Well that is one thing. And that is plain stupidity of the operator who are putting their own network at risk. Starting to do sourceed packet filtering on ingress from customers is something else, and probably a larger task and problem. Best regards, - kurtis -
Hi, On Thu, Jul 11, 2002 at 05:39:41PM +0200, Kurt Erik Lindqvist wrote:
We all know that it's a crappy argument, but lots of people try using it. Especially those who have large legacy implementations that either don't have or don't support filters on customer lines.
I agree with you. Still, the common argument is that it's to complex to maintain and to expensive to install.
With more recent vendor software versions, it's nearly always possible to automatically filter single-homed customers ("ip verify unicast reverse" in Cisco speak). It's *easy*, and maintenance effort is zero. For multi-homed customers, you need plain old access-lists, which isn' that easy, but hopefully *they* will do anti-spoofing filters then (assuming a higher clue level for multi-homing customers).
But again, I am sure the cost of dealing with the effects is close to the same amount. But few people realise this.
Tell 'em about it, repeat it again and again... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 45809 (45931) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Thu, 11 Jul 2002 17:39:41 +0200, Kurt Erik Lindqvist <kurtis@kurtis.pp.se> wrote:
We all know that it's a crappy argument, but lots of people try using it. Especially those who have large legacy implementations that either don't have or don't support filters on customer lines.
I agree with you. Still, the common argument is that it's to complex to maintain and to expensive to install. But again, I am sure the cost of dealing with the effects is close to the same amount. But few people realise this.
I'm not entirely convinced that everyone has this choice. Some providers have legacy access kit that simply doesn't support filters on a per-interface basis. Many are starting to filter on ingress/egress to each PoP which is a good start. Part of the problem is raw router processing power. If you've only got enough processing power to filter inbound *or* outbound, you're more likely to want to filter inbound (to stop your customers being DoSed) than outbound. Providers are filtering outbound, but it's inbound filters that have all the effort invested in them. They also tend to be a lot more dynamic thus are a lot better maintained. C.
I'm not entirely convinced that everyone has this choice. Some providers have legacy access kit that simply doesn't support filters on a per-interface basis. Many are starting to filter on ingress/egress to each PoP which is a good start.
I built and ISP with everything from 25xx to GSRs. I seriously doubt someone has PE devices that can't forward the packets AND do rudimentary filtering on addresses. But maybe you are right...then again, as you say - filtering per POP is as good. Actually it doesn't matter that much where you filter as long as you do it right - AND....
Part of the problem is raw router processing power. If you've only got
...you have the CPU cycles...
enough processing power to filter inbound *or* outbound, you're more likely to want to filter inbound (to stop your customers being DoSed)
What is "worse"? Your customers beeing DoSes, or you beeing the source of a DoS? Unless we are talking a really small ISP, where there is little difference between ingress and egress routers, this is not that much of an issue. And in that case, I doubt the traffic levels are that high...
than outbound. Providers are filtering outbound, but it's inbound filters that have all the effort invested in them. They also tend to be a lot more dynamic thus are a lot better maintained.
I don't think any providers are doing outbound source filtering? Not to any large extent, at least that I know of. But I might be wrong...and people dream up the most strange solution nowadays - I am sure that if I where using MPWhateverS this would not be an issue..:) - kurtis -
At 15:32 10/07/2002 +0000, Christopher Sharp wrote:
This was my suggestion in a nutshell. I believe the most commonly observed bogon list is maintained by Rob Thomas (http://www.cymru.com/Documents/bogon-list.html). draft-iana-special-ipv4-03 is IANA's most comprehensive list of special use netblocks (http://www.ietf.org/internet-drafts/draft-iana-special-ipv4-03.txt).
There is also Bill Manning's list (http://www.ietf.org/internet-drafts/draft-manning-dsua-08.txt). For those of you at the last RIPE meeting, recall that in the Routing Working Group I presented Geoff Huston's proposal that the registries make available a list of their unallocated addresses within their /8 blocks. And I believe all three intend to do that rsn.
This sounds excellent but doesn't cover prefixes IANA have not yet allocated to an RIR. This is why I would encourage frequent sharing of this data with the networking community and especially the maintainers of public bogon lists on which many people filter.
For anyone who is a masochist, I've put together a complete list of all the addresses which are marked in the three registry databases as being unallocated. I use this list for the Routing Report which I post to various lists once a week - and it's the basis for figuring out how much IPv4 address space is left (45.9%). The list is sitting on a router in my lab at the moment - comes to about 1500 entries once they are completely aggregated. Once the registries produce the lists for their blocks, I'll see how easy it would be to merge the two... I could make this publicly available if folks are interested... It would be a BGP feed - exercise left to the reader to figure out how to convert this into a dynamically updated routing and packet filter... ;-) Bigger question would be whether anyone would even want to do it... philip --
participants (6)
-
Christopher Sharp -
Gert Doering -
Kurt Erik Lindqvist -
Lu, Ping -
Pekka Savola -
Philip Smith