Re: 69/8...this sucks -- Centralizing filtering..
[ apologies for the long post ] On 2003-03-11 19:57:04 +, [EMAIL PROTECTED] wrote: Also, on a side rant hereWhy do all the RIR's have to give out whois data in different, incompatible, referal-breaking formats? The reason for the different formats is partly historical, and partially a result of the fundamental differences between the RIR's. The historical reason is that each RIR has a different origin, and the databases and Whois software comes from that origin. The RIPE NCC started with nothing, evolved to RIPE-181, then RPSL, and is now moving to RPSLng + extensions. APNIC adopted RIPE NCC software, and is very nearly compatible. ARIN's database was inherited from the InterNIC, and has since evolved into a new, organisation-based model. I believe LACNIC's database is inherited from the Brazil domain name registry, so it uses that format (this is the one I am least familiar with - so I may be in error). The formats remain different because the RIR's have evolved their databases to solve problems that are most important in their regions. For instance, ARIN has chosen a model that reflects registration in a straightforward way, whereas RPSL is useful for operators wanting to document policy. The next step in my work once my ping sweep is complete (looks like that'll be today) is going to be to take a list of what looks like it'll be ~1000 IPs and generate a list of the unique networks that are broken. To do this, it'd be nice if there were some key I could get from whois, store in a column, select a unique set from, then reuse to lookup POCs from whois, and send off the emails. registro.br and LACNIC entries start with inetnum: using what I'll call brief CIDR, i.e. inetnum: 200.198.128/19 APNIC and RIPE entries start with inetnum:, but use range format. i.e. inetnum: 203.145.160.0 - 203.145.191.255 ARIN entries include fields like NetRange: 128.63.0.0 - 128.63.255.255 CIDR: 128.63.0.0/16 The APNIC and RIPE NetRange/inetnum fields are easy enough to deal with, but send a whois request for 200.198.128/19 to whois.arin.net and you get No match found. Send it as 200.198.128, and whois.arin.net will refer you to whois.lacnic.net. Send it to whois.lacnic.net as 200.198.128, and you get Invalid IP or CIDR block. I realize programming around all this is by no means an insurmountable task, but it is a pain. It'd be ideal if there were a unique key field, say Net-ID included in the whois output from all the RIR whois servers that could be used to identify the network and the appropriate whois server. i.e. NetID: [EMAIL PROTECTED] In the current situation, users must query up to 4 servers (whois.apnic.net, whois.arin.net, whois.lacnic.net, and whois.ripe.net) to find information about an IP address, in some cases without any way of knowing which RIR has allocated the space. Each RIR parses queries and presents results in a different format. This is not ideal - to put it mildly. The good news is that we are aware of the problem, and not sitting on our laurels. The eventual goal is to answer a query for IP or AS space at each RIR, using the native query and result format, and get the best possible answer. We've completed part of the mapping between schemas, and after that is finished it's just a matter of writing some software. ;) There is also a technology that might come out of the CRISP IETF working group: http://www.ietf.org/html.charters/crisp-charter.html We (the RIR's) are tracking this work. Since this involves an actual protocol difference from our beloved Whois protocol, if it is adopted it will certainly take longer to adopt. But there is no reason the two protocols can't co-exist and complement each other. If you have any interest in participating in RIPE Database-related issues, please feel free to join the mailing list: http://www.ripe.net/ripe/wg/db/index.html We (meaning the RIPE NCC, especially the database group) take a lot of our direction from the DB working group. It's open to all. -- Shane Kerr Database Group Manager RIPE NCC
RE: 69/8...this sucks -- Centralizing filtering..
On Mon, 10 Mar 2003, Todd A. Blank wrote: I continue to agree that moving critical resources (see below) to these new blocks is the best approach I have seen or heard in the months since I made the original post. This approach punishes the clueless instead of the people that already know what the problem is (and have to live with it every day). I think this illustrates very well that the concept of filtering on statically configured IP address ranges is severely broken and needs to be replaced with something better. Fortunately, in this particular case there is a solution on the horizon: S-BGP or soBGP. These BGP extensions authenticate all prefix announcements, so there is no longer any need to perform bogon filtering on routing information. uRPF can then be used to filter packets based on the contents of the routing table. In the mean time, I think we need a good best practices document. Way too many people simply don't know about these kinds of issues, or worse, know only half, and having a single, authorative set of guidelines would be extremely helpful, even if it doesn't magically make the problem disappear. I have seen this suggestion once before (maybe even by Jon) and I still think it is the best way things will get resolved quickly. Maybe we should suggest that ARIN also host some of their stuff on this block :-) Or maybe list the offending IP addresses/ranges in the anti-spam lists? This should get people's attention without breaking too much important stuff (who needs email anyway).
Re: 69/8...this sucks -- Centralizing filtering..
From: Iljitsch van Beijnum Fortunately, in this particular case there is a solution on the horizon: S-BGP or soBGP. These BGP extensions authenticate all prefix announcements, so there is no longer any need to perform bogon filtering on routing information. uRPF can then be used to filter packets based on the contents of the routing table. A majority of the filters in place are not BGP filters. They are firewall rulesets designed to filter out hijacked and spoofed IP addresses to limit DOS and illegitimate connections. S-BGP and soBGP will not solve the problem for these people. -Jack
RE: 69/8...this sucks -- Centralizing filtering..
Well Jon, I spent some time reading your message below, and trying to look at if I experienced the issue, just what I would have done differently, or what would have been more meaningful in your initial email blast... Here are some of my thoughts... First since you are taking the time to explore where your routes are reaching, why not send the end user (yes your approach contacts the end user of the IP addres block not the network provider) a traceroute showing where the problem is first encountered? Now granted some places may filter ICMP messages, but it is some more information from which the end user can start addressing the problem? Next I would suggest that you look at the tone of your message to make sure that the reader understands that you have an issue and that you would like his assistance. Sometimes emails can be viewed as HARSH when they are meant to be informative and helpful in getting the issue corrected. I would personally have run a traceroute with the NANOG traceroute and also copied the Network ASN where the packets seems to have stopped. After all that is the most likely source of the filter, right? When I received your original message that is the first think that I did from an off network account. You mention that we should update our ARIN listing... well I do not disagree, but the subnet where the packets stopped would have had a noc email with 24x7 number to call. Then again so would have the ASN where the traceroute stopped. Yes I think that there is interest in understanding new subnet allocations have universal routing. Clearly in this case when addressing was first allocted in Aug 2002 this should have become and issue by now... You suggest that ARIN should do more (lets expand this to any RR), what would you suggest they do? Do you plan to be at the ARIN meeting in April? We would welcome your views on this topic be addressed... Take it to a ARIN advisory council member if you do not plan to attend, they can champion your cause... they do it well... On Mon, 10 Mar 2003 [EMAIL PROTECTED] wrote: On Mon, 10 Mar 2003, Michael Whisenant wrote: First I appreciate your message that you sent to us at NASA late Friday regarding a new address block that you received from ARIN. In that message you suggest that the issue was a BOGON route filter that had not been updated. Then without allowing sufficient time to respond to your message (you sent it to an administrative account and not the NOC) you decided to flame NASA. My mention of NASA wasn't meant at all as a flame. It was just an example that not all the networks with outdated filters are remote nets in far away countries that my customers wouldn't care about. A few I've found are. I had to look up the country code to find that .al is Albania. I had actually planned to mention at some point that NASA was the first (only so far) network to respond to the few messages I sent out late last friday, and that their reported network has already been fixed. I can only assume that none of the previous 94 allocation holders of 69/8 space noticed or complained to the right people. If you feel that you have any issue reaching a NASA resource then you can send a message to [EMAIL PROTECTED] and/or the tech/org/noc POC on any address space. NISN is NASA's ISP and as such announce via AS297 that address space. As for sending the message to the wrong addresses, I can only suggest updating your ARIN info. I sent the message to all the POCs (except the abuse one) for the relevant NetRange. This is what I'll be doing when I send out the automated messages. The ones sent friday were done by hand. Can you elaborate on how a firewall config was the problem? If whatever was done there is commonly done, it may be worth revising my form message before I send out a large number of them. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: 69/8...this sucks -- Centralizing filtering..
Thanks for your support Jim. I've gotten mixed feedback to my proposal here for a centralized bogon filter from the RIRs via BGP, but I will say there's been more support than opposition. (Most of the support has been sent to me, not the list, while most of the opposition has been to the list, however). I know it's too late to get it into the Memphis meeting, but I think, based on the amount of support it has received, that I will submit a policy proposal to ARIN in support of creating the requisite BGP feeds. I realize that an ARIN policy alone won't do this (the other RIRs would have to follow suit), but, if ARIN adopts it, I don't think it will be too hard to get the other RIRs to follow. I'm also not familiar with the policy process in the other RIRs. I absolutely agree with you about the whois contact stuff. I think it might make sense eventually to put a similar requirement for current information on the admin and tech contact, although I don't see putting the same response and performance strictures on them. For now, I'm trying to address large issues in small enogh pieces to get rough consensus around the solution to each small piece. Trying to solve the big problems all at once never seems to achieve rough consensus. Owen --On Monday, March 10, 2003 11:19 PM -0500 McBurnett, Jim [EMAIL PROTECTED] wrote: From Chris Adams: This isn't meant to be a pick on you (we've got some SWIPs filed incorrectly that we are working on). I've just run into more and more cases where ARIN (or other RIR, but I'm typically interested in ARIN info) info is out of date. Maybe ARIN should periodically send an are you there type email to contacts (like some mailing lists do). If that fails, mail a letter with instructions on how to update your contact info, and if that fails, delete the invalid contact info - I'd rather see no contact info than bogus info. Chris, If you read PPML, there is a HUGE push via Owen DeLong's Policy 2003-1a to help with some aspects of the whois Contact.. his policy is mainly based on the abuse contact, But I think may get extended to all contacts eventually... Owen- Wanta jump in here??? And-- if you feel strong enough to be flamed on the ARIN PPML list propose a Policy based on your comments.. I for one agree with you.. just give 2 or 3 tries.. If it fails once - retry 24 hours if it fails again retry 48 hours. If it fails again.. 3 strikes and your out in the old ball game (add in the music from take me out to the ballgame) Later, J That's my 10 cents worth- ya know inflation gets us everywhere...
Re: 69/8...this sucks -- Centralizing filtering..
On Tue, 11 Mar 2003, Jack Bates wrote: Fortunately, in this particular case there is a solution on the horizon: S-BGP or soBGP. These BGP extensions authenticate all prefix announcements, so there is no longer any need to perform bogon filtering on routing information. uRPF can then be used to filter packets based on the contents of the routing table. A majority of the filters in place are not BGP filters. Let's stay focussed on the problem at hand. Or are you saying that most of the _bogon_ filters aren't BGP filters? They are firewall rulesets designed to filter out hijacked and spoofed IP addresses to limit DOS and illegitimate connections. S-BGP and soBGP will not solve the problem for these people. If all routes in the routing table are good (which soBGP and S-BGP can do for you) and routers filter based on the contents of the routing table, hosts will not see any bogon packets except locally generated ones so they shouldn't have bogon filters of their own. So this will indeed solve the problem for these people.
Re: 69/8...this sucks -- Centralizing filtering..
If all routes in the routing table are good (which soBGP and S-BGP can do for you) and routers filter based on the contents of the routing table, hosts will not see any bogon packets except locally generated ones so they shouldn't have bogon filters of their own. So this will indeed solve the problem for these people. I believe you are confusing authentication with authorisation. Having authentic routes does not imply that all the traffic will be 'correct'. Various networks will always fail to filter customer traffic at ingress etc. and then source address spoofing becomes trivial. Peter
Re: 69/8...this sucks -- Centralizing filtering..
Thus spake Ray Bellis [EMAIL PROTECTED] Most people seem to think it would be impractical to put the root name servers in 69.0.0.0/8 Why not persuade ARIN to put whois.arin.net in there instead? It shouldn't take the people with the broken filters *too* long to figure out why they can't do IP assignment lookups... I'd bet most of the people with broken filters have never heard of ARIN and still think the InterNIC assigns addresses. We're talking about people with no network staff; directing technical solutions at the people oblivious to technology is difficult stuff. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: 69/8...this sucks -- Centralizing filtering..
On Tue, 11 Mar 2003, Peter Galbavy wrote: If all routes in the routing table are good (which soBGP and S-BGP can do for you) and routers filter based on the contents of the routing table, hosts will not see any bogon packets except locally generated ones so they shouldn't have bogon filters of their own. I believe you are confusing authentication with authorisation. I don't think I am. Having authentic routes does not imply that all the traffic will be 'correct'. Various networks will always fail to filter customer traffic at ingress etc. and then source address spoofing becomes trivial. I don't see your point. Packets with bogon sources are just one class of spoofed packets. As I've explained earlier S-BGP or soBGP with uRPF will get rid of bogons. Neither this or bogon filters on the host will do anything against non-bogon spoofed packets.
Re: 69/8...this sucks -- Centralizing filtering..
On Mon, 10 Mar 2003, Ray Bellis wrote: Most people seem to think it would be impractical to put the root name servers in 69.0.0.0/8 Why not persuade ARIN to put whois.arin.net in there instead? It shouldn't take the people with the broken filters *too* long to figure out why they can't do IP assignment lookups... The vast majority of broken networks won't care/notice. A few will assume ARIN's whois server is broken. How often do people on forgotten networks in China and Albania use ARIN's whois server? Take away the western Internet (all of gtld-servers.net) and they will notice the problem. From a whois, it appears Verisign owns gtld-servers.net. Do they own just the domain or all 13 gtld-servers as well? Anyone from Verisign reading NANOG care to comment on the odds of Verisign cooperating and helping with the breaking in of new IP ranges? Also, on a side rant hereWhy do all the RIR's have to give out whois data in different, incompatible, referal-breaking formats? The next step in my work once my ping sweep is complete (looks like that'll be today) is going to be to take a list of what looks like it'll be ~1000 IPs and generate a list of the unique networks that are broken. To do this, it'd be nice if there were some key I could get from whois, store in a column, select a unique set from, then reuse to lookup POCs from whois, and send off the emails. registro.br and LACNIC entries start with inetnum: using what I'll call brief CIDR, i.e. inetnum: 200.198.128/19 APNIC and RIPE entries start with inetnum:, but use range format. i.e. inetnum: 203.145.160.0 - 203.145.191.255 ARIN entries include fields like NetRange: 128.63.0.0 - 128.63.255.255 CIDR: 128.63.0.0/16 The APNIC and RIPE NetRange/inetnum fields are easy enough to deal with, but send a whois request for 200.198.128/19 to whois.arin.net and you get No match found. Send it as 200.198.128, and whois.arin.net will refer you to whois.lacnic.net. Send it to whois.lacnic.net as 200.198.128, and you get Invalid IP or CIDR block. I realize programming around all this is by no means an insurmountable task, but it is a pain. It'd be ideal if there were a unique key field, say Net-ID included in the whois output from all the RIR whois servers that could be used to identify the network and the appropriate whois server. i.e. NetID: [EMAIL PROTECTED] -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: 69/8...this sucks -- Centralizing filtering..
From: Iljitsch van Beijnum I don't see your point. Packets with bogon sources are just one class of spoofed packets. As I've explained earlier S-BGP or soBGP with uRPF will get rid of bogons. Neither this or bogon filters on the host will do anything against non-bogon spoofed packets. You're thinking technical. The problem isn't bogon filters per say. The problem is that someone got it in their head that if you filter packets using a bogon list, you'll limit the number of possible spoofed packets allowed into your network. Given than many bots use randomizers, and bogon networks do cover a large amount of the netspace, this may be true. Then again, perhaps not. It doesn't matter in the end. The fact remains that while people may protect the routes from being advertised, many large providers do not drop packets that do not have valid routes. Because of this, many firewalls (which don't run BGP) filter based on bogon lists. Only 1 of the last 6 people I contacted for blocking 69/8 actually had BGP. -Jack
RE: 69/8...this sucks -- Centralizing filtering..
What surprises me most about this entire thread is the lack of centralized filtering. Since most service providers should be thinking about a sink hole network for security auditing (and backscatter), why not have ONE place where you advertise all unreachable, or better yet -- a default (ie everything NOT learned through BGP peers), and just forward the packets to a bit bucket.. Which is better than an access list since, now we are forwarding packets instead of sending them to a CPU to increase router load. I don't think ARIN can help the situation. ISPs just need to remove the access lists from each router in the network and centralize them. Regards, mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570 -Original Message- From: E.B. Dreger [mailto:[EMAIL PROTECTED] Sent: March 10, 2003 10:17 AM To: [EMAIL PROTECTED] Subject: Re: 69/8...this sucks Date: Mon, 10 Mar 2003 09:46:33 + From: Michael.Dillon I have suggested that ARIN should set up an LDAP server to publish the delegation of all their IP address space updated Not bad, but will the lazy ISPs set up an LDAP server to track changes they aren't tracking now? Will those with erroneous filters magically change simply because of LDAP? I still contend the answer is is a boot to the head that screams to them, Update your freaking filters! Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked.
RE: 69/8...this sucks -- Centralizing filtering..
MS Date: Mon, 10 Mar 2003 10:27:35 -0500 MS From: Mark Segal MS Since most service providers should be thinking about a sink MS hole network for security auditing (and backscatter), why MS not have ONE place where you advertise all unreachable, or MS better yet -- a default (ie everything NOT learned through MS BGP peers), and just forward the packets to a bit bucket.. MS Which is better than an access list since, now we are MS forwarding packets instead of sending them to a CPU to MS increase router load. Chris Morrow and Brian Gemberling (a.k.a. dies) have some fine instructions on how to do just that. Rob Thomas has a bogon route server that comes in handy. The problem with only a default: Think when a rogue ISP decides to advertise an unused netblock and utilize that IP space for malicious purposes. A route exists... do we trust it? MS I don't think ARIN can help the situation. ISPs just need to Probably not. Nor should they need to. Although perhaps they could allocate other netblocks, and they _do_ charge a fair amount for PI space... ;-) MS remove the access lists from each router in the network and MS centralize them. Now, how can we force that? Sufficient reward for doing so, or pain for failure. Evidently some people can't reach you isn't enough pain, and having full reachability isn't enough reward. I'm looking forward to Jon Lewis (or others) providing some stats about just how bad the problem is... being fortunate enough not to have [any clients in] 69/8 space I can't comment first-hand on the severity of the problem. Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked.
RE: 69/8...this sucks -- Centralizing filtering..
Since most service providers should be thinking about a sink hole network for security auditing (and backscatter), why not have ONE place where you advertise all unreachable, or better yet -- a default (ie everything NOT learned through BGP peers), and just forward the packets to a bit bucket.. Which is better than an access list since, now we are forwarding packets instead of sending them to a CPU to increase router load. I don't think ARIN can help the situation. ISPs just need to remove the access lists from each router in the network and centralize them. I totally agree with you. However, as always, centralized systems, while ease management and scalability, everything becomes a trust issue and a single point of failure or source of problems... May be, this could be a subscription based type of service, something like RADB, where everyone subscribes into a central filtering list that is managed by a seperate organization? I really like the Rob's bogon route-server setup. -hc Regards, mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570 -Original Message- From: E.B. Dreger [mailto:[EMAIL PROTECTED] Sent: March 10, 2003 10:17 AM To: [EMAIL PROTECTED] Subject: Re: 69/8...this sucks Date: Mon, 10 Mar 2003 09:46:33 + From: Michael.Dillon I have suggested that ARIN should set up an LDAP server to publish the delegation of all their IP address space updated Not bad, but will the lazy ISPs set up an LDAP server to track changes they aren't tracking now? Will those with erroneous filters magically change simply because of LDAP? I still contend the answer is is a boot to the head that screams to them, Update your freaking filters! Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked.
RE: 69/8...this sucks -- Centralizing filtering..
From: E.B. Dreger [mailto:[EMAIL PROTECTED] The problem with only a default: Think when a rogue ISP decides to advertise an unused netblock and utilize that IP space for malicious purposes. A route exists... do we trust it? But that kinda filtering should be done at BGP route ingress by, you, or the transit provider of choice. I'm not suggesting that a default is the only way. It just happens to be a good lazy way for the people who can't seem to find the time to check the IANA web page at least once a quarter.. :). Regards, Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570
RE: 69/8...this sucks -- Centralizing filtering..
Perhaps I should have been more clear on what I was saying.. Sorry about that.. What I really meant by single pt. of failure was... problems of losing the filtering list if the central system is down... Granted, this would not cause any network issues.. -hc On Mon, 10 Mar 2003, Mark Segal wrote: -Original Message- From: Haesu [mailto:[EMAIL PROTECTED] I totally agree with you. However, as always, centralized systems, while ease management and scalability, everything becomes a trust issue and a single point of failure or source of problems... Single point of failure? Not sure I agree with you.. What happens if your sink hole disapears? Your filtering goes out.. O no.. Please not that. Hardley think that is even a reason for a noc to page you... :). Regards, Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570
Re: 69/8...this sucks -- Centralizing filtering..
On Monday, Mar 10, 2003, at 10:54 Canada/Eastern, Haesu wrote: Since most service providers should be thinking about a sink hole network for security auditing (and backscatter), why not have ONE place where you advertise all unreachable, or better yet -- a default (ie everything NOT learned through BGP peers), and just forward the packets to a bit bucket.. Which is better than an access list since, now we are forwarding packets instead of sending them to a CPU to increase router load. I don't think ARIN can help the situation. ISPs just need to remove the access lists from each router in the network and centralize them. I totally agree with you. However, as always, centralized systems, while ease management and scalability, everything becomes a trust issue and a single point of failure or source of problems... I can think of two organisations which could probably take care of a good chunk of the problem, if people were prepared to leave it up to them. The routing system is already largely dependent on the interoperability of bugs produced by these people, and so arguably no additional trust would be required. One organisation has a name starting with j, and the other starts with c. Joe
RE: 69/8...this sucks -- Centralizing filtering..
On Mon, 10 Mar 2003, Mark Segal wrote: What surprises me most about this entire thread is the lack of centralized filtering. Central as in 'ALL INTERNET USES MY FILTERING SERVICE' or... 'My network uses my filter service and your network uses yours'? Since most service providers should be thinking about a sink hole network for security auditing (and backscatter), why not have ONE place where you advertise all unreachable, or better yet -- a default (ie everything NOT learned through BGP peers), and just forward the packets to a bit bucket.. This can be VERY dangerous, the default part atleast. At one point we, as an experiment in stupidity (it turns out) announced 0/1 (almost default). We quickly recieved well over 600kpps to that announcement. This in a very steady stream... When one announces a very large block like this there are always unintended consequences :( There is alot of traffic spewed out to non-available address space, this traffic is very large when aggregated :) Which is better than an access list since, now we are forwarding packets instead of sending them to a CPU to increase router load. Yes, routes to null0 or to a dead interface/collection host are much nicer than acls. So, for this perhaps instead of acls uRPF would be a solution for the implementor? I don't think ARIN can help the situation. ISPs just need to remove the access lists from each router in the network and centralize them. Or, have an 'automated' manner to deploy/audit/change said acls? RAT perhaps or some other 'automated' router config checking/deployment tool? Regards, mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570 -Original Message- From: E.B. Dreger [mailto:[EMAIL PROTECTED] Sent: March 10, 2003 10:17 AM To: [EMAIL PROTECTED] Subject: Re: 69/8...this sucks Date: Mon, 10 Mar 2003 09:46:33 + From: Michael.Dillon I have suggested that ARIN should set up an LDAP server to publish the delegation of all their IP address space updated Not bad, but will the lazy ISPs set up an LDAP server to track changes they aren't tracking now? Will those with erroneous filters magically change simply because of LDAP? I still contend the answer is is a boot to the head that screams to them, Update your freaking filters! Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked.
Re: [Re: 69/8...this sucks -- Centralizing filtering..]
interesting idea, enable it by default, with the option to turn it off (i hope)... my-big-fat-router# conf t my-big-fat-router(config)# no ip clueless Joe Abley [EMAIL PROTECTED] wrote: On Monday, Mar 10, 2003, at 10:54 Canada/Eastern, Haesu wrote: Since most service providers should be thinking about a sink hole network for security auditing (and backscatter), why not have ONE place where you advertise all unreachable, or better yet -- a default (ie everything NOT learned through BGP peers), and just forward the packets to a bit bucket.. Which is better than an access list since, now we are forwarding packets instead of sending them to a CPU to increase router load. I don't think ARIN can help the situation. ISPs just need to remove the access lists from each router in the network and centralize them. I totally agree with you. However, as always, centralized systems, while ease management and scalability, everything becomes a trust issue and a single point of failure or source of problems... I can think of two organisations which could probably take care of a good chunk of the problem, if people were prepared to leave it up to them. The routing system is already largely dependent on the interoperability of bugs produced by these people, and so arguably no additional trust would be required. One organisation has a name starting with j, and the other starts with c. Joe Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence. - Stephen Hawking -
RE: 69/8...this sucks -- Centralizing filtering..
CLM Date: Mon, 10 Mar 2003 17:30:27 + (GMT) CLM From: Christopher L. Morrow CLM This can be VERY dangerous, the default part atleast. At one CLM point we, as an experiment in stupidity (it turns out) CLM announced 0/1 (almost default). We quickly recieved well CLM over 600kpps to that announcement. This in a very steady Announced via IGP or BGP? I hope/assume the former, but am somewhat surprised at the traffic volume... even for UUNet. Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked.
RE: 69/8...this sucks -- Centralizing filtering..
On Mon, 10 Mar 2003, E.B. Dreger wrote: Now, how can we force that? Sufficient reward for doing so, or pain for failure. Evidently some people can't reach you isn't enough pain, and having full reachability isn't enough reward. I think the only way that's relatively guaranteed to be effective is to move a critical resource (like the gtld-servers) into new IP blocks when previously reserved blocks are assigned to RIR's. I still have a couple hundred thousand IPs to check (I'm going to step up the pace and see if I can get through the list today), but I already have a list of several hundred IPs in networks that ignore 69/8. The list includes such networks as NASA, the US DoD, and networks in China, Russia, and Poland. Those are just a few that I've done manual whois's for. I haven't decided yet whether I'll send automated messages to all the broken networks and give them time to respond and fix their filters, or just post them all to NANOG when the list is complete. Are people interested in seeing the full list (at least the ones I find) of networks that filter 69/8? Does Atlantic.Net get an ARIN discount for doing all this leg work? :) -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: 69/8...this sucks -- Centralizing filtering..
I don't think ARIN can help the situation. ISPs just need to remove the access lists from each router in the network and centralize them. I totally agree with you. However, as always, centralized systems, while ease management and scalability, everything becomes a trust issue and a single point of failure or source of problems... Yeah, who would you trust to maintain a centralized database of IP address ranges? May be, this could be a subscription based type of service, something like RADB, where everyone subscribes into a central filtering list that is managed by a seperate organization? Yup, you're right. This should be done by a 3rd party organization, not an ISP. I wonder whether there are any 3rd party organizations trusted by ISPs that have experience in maintaining a database of IP address ranges? ARIN, perhaps? I really like the Rob's bogon route-server setup. That's probably because you are a router geek. I have nothing against Rob's setup but I know that the vast majority of geeks know nothing about route-servers and have no incentive to learn about them. But they all know what LDAP is, some of them already run LDAP servers and the rest probably plan to learn more about LDAP some day. We could leverage that widespread knowledge of LDAP by publishing route data (or any other data regarding attributes of IP address ranges) using the IETF standard LDAPv3 protocol. In fact, I know that Rob is considering setting up an LDAP server as an alternative way to offer bogon data. I think this is a great idea as a testbed, i.e. offer the data through many protocols and see which is most popular. Howevere, I think that when it does become popular, it needs to be integrated with ARIN's authoritative database of IP address delegations. -- Michael Dillon
RE: 69/8...this sucks -- Centralizing filtering..
What I really meant by single pt. of failure was... problems of losing the filtering list if the central system is down... Granted, this would not cause any network issues.. We know how to set up central authorities without central systems or obvious single points of failure. For instance, the DNS has a single root authority but there are 13 distributed servers publishing authoritative data. And not all of those servers are single systems. For some time now Vixie's root server has been at least two systems using his own FreeBSD kernel hack to handle load balancing and failover. Also, people are beginning to realize that having a local cache of authoritative data is a wise thing and is not very difficult to do. That's why ISC is now offering a replica service for network operators to set up local copies of Vixie's F root server. I would expect that the LDAP service for IP address range attributes would leverage all of this knowledge about architecture. LDAP may a more versatile protocol than DNS but it is clearly from the same family tree of directory service protocols and there are no major roadblocks preventing it from being deployed in a sane fashion. --Michael Dillon
RE: 69/8...this sucks -- Centralizing filtering..
Hi, NANOGers. ] But they all know what LDAP is... I don't know that I'd say that. I'll bet they all are more familiar with HTTP and DNS (both have bogon feeds available). I view LDAP as yet another way to share the data, not the ultimate way to share the data. I'm not trying to start a flame war here, just pointing out that a variety of feeds meet many more requirements, and that there are several types of data feeds available now. This includes the recently added pure text bogon files, suitable for easy parsing. http://www.cymru.com/Bogons/ ] In fact, I know that Rob is considering setting up an LDAP server as an Yep, it is high on my burgeoning to-do list. :) Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: 69/8...this sucks -- Centralizing filtering..
I can think of two organisations which could probably take care of a good chunk of the problem, if people were prepared to leave it up to them. The routing system is already largely dependent on the interoperability of bugs produced by these people, and so arguably no additional trust would be required. Cisco is already a member of ARIN. If anyone out there buys Juniper routers, perhaps you might suggest that they also join ARIN and work together with Cisco and the network operators to move this forward. --Michael Dillon
Re: 69/8...this sucks -- Centralizing filtering..
Monday, March 10, 2003, 9:52:06 AM, you wrote: jlo I think the only way that's relatively guaranteed to be effective is to jlo move a critical resource (like the gtld-servers) into new IP blocks when jlo previously reserved blocks are assigned to RIR's. I agree with you. But then since I've been allocated 69/8 I guess you can say I'm a bit biased. jlo I still have a couple hundred thousand IPs to check (I'm going to step up jlo the pace and see if I can get through the list today), but I already have jlo a list of several hundred IPs in networks that ignore 69/8. The list jlo includes such networks as NASA, the US DoD, and networks in China, Russia, jlo and Poland. Those are just a few that I've done manual whois's for. jlo I haven't decided yet whether I'll send automated messages to all the jlo broken networks and give them time to respond and fix their filters, or jlo just post them all to NANOG when the list is complete. jlo Are people interested in seeing the full list (at least the ones I find) jlo of networks that filter 69/8? Again, since I've been recently allocated in the 69/8 range, I'd love to see this completed list. We've only renumbered our internal workstations into this range, so no customer nets are affected as of yet. But we are about to plunge into our renumbering, so I'm sure customers are going to start yelling then. However, I think this is going to be an on-going problem, even if the gtld-servers were renumbered into 69/8. Do a simple Google search on ip firewalling. You'll find lots of examples using ipchains, iptables, etc, that show example configs. These example configs usually show 69/8 as a bogon network and recommends filtering them. So, in my opinion it's only going to be a matter of time before some network administrator looking to implement a firewall stumbles across one of these broken sample configs and breaks connectivity to me again. In essence, it's going to be an ongoing problem, sure we can fix networks now that we know are broken, but it's going to be an ongoing problem that we are going to have to deal with. Regards, Joe Boyce --- InterStar, Inc. - Shasta.com Internet Phone: +1 (530) 224-6866 x105 Email: [EMAIL PROTECTED]
Re: 69/8...this sucks -- Centralizing filtering..
From: Mark Segal Since most service providers should be thinking about a sink hole network for security auditing (and backscatter), why not have ONE place where you advertise all unreachable, or better yet -- a default (ie everything NOT learned through BGP peers), and just forward the packets to a bit bucket.. Which is better than an access list since, now we are forwarding packets instead of sending them to a CPU to increase router load. It would be nice if vendors had a variant to (in cisco terms) ip verify unicast reverse-path that would work in asymmetrical networks. If you only have a single link to the internet, the command works well, but then why would you ever run bgp for a single uplink? -Jack
RE: 69/8...this sucks -- Centralizing filtering..
CLM From: Christopher L. Morrow CLM This can be VERY dangerous, the default part atleast. At one CLM point we, as an experiment in stupidity (it turns out) CLM announced 0/1 (almost default). We quickly recieved well CLM over 600kpps to that announcement. This in a very steady Announced via IGP or BGP? I hope/assume the former, but am somewhat surprised at the traffic volume... even for UUNet. I'm not surprised. My experience with defaults in ISPs is the same. The router advertising the default (or any large prefix) becomes a packet vacuum for any spoofed source packet returning backscatter and all those other auto-bots and worms looking for vulnerable machines. It turns the router into a sink hole. What saves many providers today is that these large route injections are spread across all their peering routers. This is like anycasting the prefix advertisements. People are discussing is putting these advertisements on anycasted Sink Holes. So instead of having the CIDR prefixes and the Null 0 lock-ups on the peering routers, you would put them on anycast Sink Hole routers. The anycast spreads the packet black hole load over several sink holes spread over the network. Barry
RE: 69/8...this sucks -- Centralizing filtering..
I saw it version of this earlier: Enter configuration commands, one per line. End with CNTL/Z. Router(config)#ip route clueless No seriously.. What if that customer has a VPN design with a dial backup behind their firewall. Using BGP to suck down a default route from the provider, when that default route goes away, then the internal router initiates the dial backup solution to the remote network. They should not be sending out any BGP routes though.. But.. See example above... OR They are in the process of preparing for Multi-homeing and just have not got it up yet... You know one provider is toiling with the T-1 facility FOC etc.. Sure this is somewhat unusual, but I have seen it, and corrected it... Jim It would be nice if vendors had a variant to (in cisco terms) ip verify unicast reverse-path that would work in asymmetrical networks. If you only have a single link to the internet, the command works well, but then why would you ever run bgp for a single uplink? -Jack
Re: 69/8...this sucks -- Centralizing filtering..
From: McBurnett, Jim No seriously.. What if that customer has a VPN design with a dial backup behind their firewall. Using BGP to suck down a default route from the provider, when that default route goes away, then the internal router initiates the dial backup solution to the remote network. They should not be sending out any BGP routes though.. But.. See example above... snip other method Sure this is somewhat unusual, but I have seen it, and corrected it... Oh, I agree that there are times when BGP is used in a single uplink scenario, but it is not common. However, someone pointed me to ip verify unicast source reachable-via any which seems to be available on some of the cisco Service provider releases. It's an interesting concept and I'm itching to play with it. If you aren't in my routing table, then why accept the IP address? -Jack
RE: 69/8...this sucks -- Centralizing filtering..
SNIP Oh, I agree that there are times when BGP is used in a single uplink scenario, but it is not common. However, someone pointed me to ip verify unicast source reachable-via any which seems to be available on some of the cisco Service provider releases. It's an interesting concept and I'm itching to play with it. If you aren't in my routing table, then why accept the IP address? -Jack Well, If you don't access my address and I happen to be a poor ole 69/8 or FILL IN NEW NET BLOCK HERE then your customers may not be able to get to me... But there are an aweful lot of ifs to this ^^. And I don't remember that command syntax at all Yea, I want to test that too.. Maybe I can make a visit to the local Cisco office and borrow some time in the Lab I want to see this is action, and how it may affect my routing... or maybe I can get a quick answer from the local CCIEs... Hey have you checked the Feature Navigator and seen which versions it is in? Catch me off-list Later, J
RE: 69/8...this sucks -- Centralizing filtering..
Jon et al, First I appreciate your message that you sent to us at NASA late Friday regarding a new address block that you received from ARIN. In that message you suggest that the issue was a BOGON route filter that had not been updated. Then without allowing sufficient time to respond to your message (you sent it to an administrative account and not the NOC) you decided to flame NASA. You could reach MANY NASA locations, but those at one particular center, and that issue was related to a firewall update at ONLY one particular center. This filter was placed in after August when the cental bogon was removed at the ingress to the network. If you feel that you have any issue reaching a NASA resource then you can send a message to [EMAIL PROTECTED] and/or the tech/org/noc POC on any address space. NISN is NASA's ISP and as such announce via AS297 that address space. Now, how can we force that? Sufficient reward for doing so, or pain for failure. Evidently some people can't reach you isn't enough pain, and having full reachability isn't enough reward. I think the only way that's relatively guaranteed to be effective is to move a critical resource (like the gtld-servers) into new IP blocks when previously reserved blocks are assigned to RIR's. I still have a couple hundred thousand IPs to check (I'm going to step up the pace and see if I can get through the list today), but I already have a list of several hundred IPs in networks that ignore 69/8. The list includes such networks as NASA, the US DoD, and networks in China, Russia, and Poland. Those are just a few that I've done manual whois's for. I haven't decided yet whether I'll send automated messages to all the broken networks and give them time to respond and fix their filters, or just post them all to NANOG when the list is complete. Are people interested in seeing the full list (at least the ones I find) of networks that filter 69/8? Does Atlantic.Net get an ARIN discount for doing all this leg work? :) -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: 69/8...this sucks -- Centralizing filtering..
BRG Date: Mon, 10 Mar 2003 11:17:55 -0800 BRG From: Barry Raveendran Greene BRG EBD Announced via IGP or BGP? I hope/assume the former, BRG EBD but am somewhat surprised at the traffic volume... even BRG EBD for UUNet. BRG I'm not surprised. My experience with defaults in ISPs is BRG the same. The router advertising the default (or any large BRG prefix) becomes a packet vacuum for any spoofed source BRG packet returning backscatter and all those other auto-bots BRG and worms looking for vulnerable machines. It turns the BRG router into a sink hole. Assuming one's upstreams and peers lack 'deny le 7'. BRG What saves many providers today is that these large route BRG injections are spread across all their peering routers. This BRG is like anycasting the prefix advertisements. People are BRG discussing is putting these advertisements on anycasted Sink BRG Holes. So instead of having the CIDR prefixes and the Null 0 BRG lock-ups on the peering routers, you would put them on BRG anycast Sink Hole routers. The anycast spreads the packet BRG black hole load over several sink holes spread over the BRG network. IMHO, this is a good thing. Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked.
RE: 69/8...this sucks -- Centralizing filtering..
On Mon, 10 Mar 2003, Michael Whisenant wrote: First I appreciate your message that you sent to us at NASA late Friday regarding a new address block that you received from ARIN. In that message you suggest that the issue was a BOGON route filter that had not been updated. Then without allowing sufficient time to respond to your message (you sent it to an administrative account and not the NOC) you decided to flame NASA. My mention of NASA wasn't meant at all as a flame. It was just an example that not all the networks with outdated filters are remote nets in far away countries that my customers wouldn't care about. A few I've found are. I had to look up the country code to find that .al is Albania. I had actually planned to mention at some point that NASA was the first (only so far) network to respond to the few messages I sent out late last friday, and that their reported network has already been fixed. I can only assume that none of the previous 94 allocation holders of 69/8 space noticed or complained to the right people. If you feel that you have any issue reaching a NASA resource then you can send a message to [EMAIL PROTECTED] and/or the tech/org/noc POC on any address space. NISN is NASA's ISP and as such announce via AS297 that address space. As for sending the message to the wrong addresses, I can only suggest updating your ARIN info. I sent the message to all the POCs (except the abuse one) for the relevant NetRange. This is what I'll be doing when I send out the automated messages. The ones sent friday were done by hand. Can you elaborate on how a firewall config was the problem? If whatever was done there is commonly done, it may be worth revising my form message before I send out a large number of them. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: 69/8...this sucks -- Centralizing filtering..
On Mon, Mar 10, 2003 at 01:39:26PM -0600, Jack Bates wrote: Oh, I agree that there are times when BGP is used in a single uplink scenario, but it is not common. However, someone pointed me to ip verify unicast source reachable-via any which seems to be available on some of the cisco Service provider releases. It's an interesting concept and I'm itching to play with it. If you aren't in my routing table, then why accept the IP address? I've been using this method to do loose source verification for a while now, and it's certainly better than nothing, but it doesn't really do as much as it should when you only receive a partial table from a peer. I've been toying with the idea of supporting strict reverse path verification on peering links by using vrfs. It works really well in the Lab, but migrating the whole network into an MPLS VPN just to get some extra source filtering ability seems a little extreme to me for some reason... ;) It'd work really well if Cisco allowed the global table as a vrf import/export target though. -- Russell Heilling http://www.ccie.org.uk PGP: finger [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
RE: 69/8...this sucks -- Centralizing filtering..
I continue to agree that moving critical resources (see below) to these new blocks is the best approach I have seen or heard in the months since I made the original post. This approach punishes the clueless instead of the people that already know what the problem is (and have to live with it every day). I can't begin to calculate the amount of support time we have burned contacting the offending networks. I know the cost has been prohibitive at best. I have seen this suggestion once before (maybe even by Jon) and I still think it is the best way things will get resolved quickly. Maybe we should suggest that ARIN also host some of their stuff on this block :-) Todd IPOutlet LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, March 10, 2003 12:52 PM To: E.B. Dreger Cc: [EMAIL PROTECTED] Subject: RE: 69/8...this sucks -- Centralizing filtering.. On Mon, 10 Mar 2003, E.B. Dreger wrote: Now, how can we force that? Sufficient reward for doing so, or pain for failure. Evidently some people can't reach you isn't enough pain, and having full reachability isn't enough reward. I think the only way that's relatively guaranteed to be effective is to move a critical resource (like the gtld-servers) into new IP blocks when previously reserved blocks are assigned to RIR's. I still have a couple hundred thousand IPs to check (I'm going to step up the pace and see if I can get through the list today), but I already have a list of several hundred IPs in networks that ignore 69/8. The list includes such networks as NASA, the US DoD, and networks in China, Russia, and Poland. Those are just a few that I've done manual whois's for. I haven't decided yet whether I'll send automated messages to all the broken networks and give them time to respond and fix their filters, or just post them all to NANOG when the list is complete. Are people interested in seeing the full list (at least the ones I find) of networks that filter 69/8? Does Atlantic.Net get an ARIN discount for doing all this leg work? :) -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: 69/8...this sucks -- Centralizing filtering..
On Mon, Mar 10, 2003 at 08:28:23PM +, E.B. Dreger wrote: Assuming one's upstreams and peers lack 'deny le 7'. Can you point out where the rule is written that noone is to announce a prefix with length le 7? Just we don't see it now doesn't mean we won't see it sometime in the future... Regards, Daniel
RE: 69/8...this sucks -- Centralizing filtering..
On Mon, 10 Mar 2003, Todd A. Blank wrote: I continue to agree that moving critical resources (see below) to these new blocks is the best approach I have seen or heard in the months since I made the original post. This approach punishes the clueless instead of the people that already know what the problem is (and have to live with it every day) After this 69.0.0.0/8 thing is sorted out I guess we can move the critical resources over to 202.0.0.0/7 to track down all the idiots blocking that range (trying to decide if I should put a smilie here). I nominate the arin.net nameservers. Could someone publish a name of a valid resource (or even pingable ip) in 69/8 space? This would allow people to test their (and their upsteams) filters quickly while we wait for the list to come out. -- Simon Lyall.| Newsmaster | Work: [EMAIL PROTECTED] Senior Network/System Admin | Postmaster | Home: [EMAIL PROTECTED] Ihug Ltd, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz
Re: 69/8...this sucks -- Centralizing filtering..
DR Date: Mon, 10 Mar 2003 23:10:35 +0100 DR From: Daniel Roesen DR Can you point out where the rule is written that noone is to DR announce a prefix with length le 7? Just we don't see it now DR doesn't mean we won't see it sometime in the future... Ditto ge 25. I might have missed the RFC where that was specified; AFAIK, it's a de facto standard. Here's a big difference: Assume all /8 (except for 0/8, 127/8, and 224/3) could be aggregated. How many announcements would be saved? I could live with 200-some /8 announcements as a result of shorter prefixes being deaggregated. I suspect announcing uebershort prefixes isn't a big concern. Let's first address the issue of stray /24 prefixes. Your question is interesting in theory, but has little applicability to operational practices. It shouldn't be forgotten, and anyone using an le 7 filter should stay on top of things... but I don't see it as a pressing issue. Better yet, let RIRs allocate based on prefix length. Then Verio-style filters would work great, save for small multihomed networks. However, if said multihomed nets used IRRs... Uhoh. Combining a handful on NANOG threads probably is a dangerous thing to do. Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked.
Re: 69/8...this sucks -- Centralizing filtering..
From: Simon Lyall Could someone publish a name of a valid resource (or even pingable ip) in 69/8 space? This would allow people to test their (and their upsteams) filters quickly while we wait for the list to come out. The BrightNet nameservers are both in 69.8.2.0/24 for now. ns.brightok.net:69.8.2.15 ns2.brightok.net:69.8.2.12 -Jack
RE: 69/8...this sucks -- Centralizing filtering..
On Tue, 11 Mar 2003, Simon Lyall wrote: Could someone publish a name of a valid resource (or even pingable ip) in 69/8 space? This would allow people to test their (and their upsteams) filters quickly while we wait for the list to come out. 69.atlantic.net (69.28.64.8) is a loopback on our Gainesville, FL office router. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
202/7 (RE: 69/8...this sucks -- Centralizing filtering..)
SL Date: Tue, 11 Mar 2003 11:28:55 +1300 (NZDT) SL From: Simon Lyall SL After this 69.0.0.0/8 thing is sorted out I guess we can move SL the critical resources over to 202.0.0.0/7 to track down SL all the idiots blocking that range (trying to decide if I SL should put a smilie here). Agree. I had the pleasure of dealing with someone locally who decided to 5.x.x all mail from 216/8. At least they were responsive... I pity people in 202/7. :-( Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked.
Re: 69/8...this sucks -- Centralizing filtering..
After this 69.0.0.0/8 thing is sorted out I guess we can move the critical resources over to 202.0.0.0/7 to track down all the idiots blocking that range (trying to decide if I should put a smilie here). I nominate the arin.net nameservers. Most people seem to think it would be impractical to put the root name servers in 69.0.0.0/8 Why not persuade ARIN to put whois.arin.net in there instead? It shouldn't take the people with the broken filters *too* long to figure out why they can't do IP assignment lookups... Ray -- Ray Bellis, MA(Oxon) - Technical Director community internet plc - ts.com Ltd Windsor House, 12 High Street, Kidlington, Oxford, OX5 2PJ tel: +44 1865 856000 email: [EMAIL PROTECTED] fax: +44 1865 856001 web: http://www.community.net.uk/
Re: 69/8...this sucks -- Centralizing filtering..
From: Ray Bellis Why not persuade ARIN to put whois.arin.net in there instead? It shouldn't take the people with the broken filters *too* long to figure out why they can't do IP assignment lookups... You are presuming that people are doing IP assignment lookups from the affected network, sometimes just an affected server. Further more, you presume that people do IP assignment lookups at all. Clueless people often don't even know what ARIN is. Just the other day I was asked what Aaron had to do with the problem I was describing. -Jack
Re: 69/8...this sucks -- Centralizing filtering..
Once upon a time, Michael Whisenant [EMAIL PROTECTED] said: You could reach MANY NASA locations, but those at one particular center, and that issue was related to a firewall update at ONLY one particular center. This filter was placed in after August when the cental bogon was removed at the ingress to the network. The same can be said of many large organizations. If you feel that you have any issue reaching a NASA resource then you can send a message to [EMAIL PROTECTED] and/or the tech/org/noc POC on any address space. NISN is NASA's ISP and as such announce via AS297 that address space. ARIN shows some rather outdated information for some NASA blocks. For example, 192.112.230.0/24 still has area code 205 and lists an email address with a server that no longer exists. The info listed for 192.112.220.0/22 192.112.224.0/20 lists [EMAIL PROTECTED] for the tech contact. When doing work like this, people are not likely to look in BGP to find the AS announcing a block and then contact that AS; many ISPs announce blocks on behalf of their customers and are not necessarily interested in hearing that a customer has a bogus bogon list. This isn't meant to be a pick on you (we've got some SWIPs filed incorrectly that we are working on). I've just run into more and more cases where ARIN (or other RIR, but I'm typically interested in ARIN info) info is out of date. Maybe ARIN should periodically send an are you there type email to contacts (like some mailing lists do). If that fails, mail a letter with instructions on how to update your contact info, and if that fails, delete the invalid contact info - I'd rather see no contact info than bogus info. -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
RE: 69/8...this sucks -- Centralizing filtering..
From Chris Adams: This isn't meant to be a pick on you (we've got some SWIPs filed incorrectly that we are working on). I've just run into more and more cases where ARIN (or other RIR, but I'm typically interested in ARIN info) info is out of date. Maybe ARIN should periodically send an are you there type email to contacts (like some mailing lists do). If that fails, mail a letter with instructions on how to update your contact info, and if that fails, delete the invalid contact info - I'd rather see no contact info than bogus info. Chris, If you read PPML, there is a HUGE push via Owen DeLong's Policy 2003-1a to help with some aspects of the whois Contact.. his policy is mainly based on the abuse contact, But I think may get extended to all contacts eventually... Owen- Wanta jump in here??? And-- if you feel strong enough to be flamed on the ARIN PPML list propose a Policy based on your comments.. I for one agree with you.. just give 2 or 3 tries.. If it fails once - retry 24 hours if it fails again retry 48 hours. If it fails again.. 3 strikes and your out in the old ball game (add in the music from take me out to the ballgame) Later, J That's my 10 cents worth- ya know inflation gets us everywhere...
RE: 69/8...this sucks -- Centralizing filtering..
On Mon, 10 Mar 2003 23:19:38 -0500, McBurnett, Jim wrote: If you read PPML, there is a HUGE push via Owen DeLong's Policy 2003-1a to help with some aspects of the whois Contact.. his policy is mainly based on the abuse contact, But I think may get extended to all contacts eventually... Owen- Wanta jump in here??? And-- if you feel strong enough to be flamed on the ARIN PPML list propose a Policy based on your comments.. I for one agree with you.. Cleaning up the database, establishing good abuse contacts, and purging the abusers is the essential first step to the strategy I draft-outline in http://www.camblab.com/misc/univ_std.txt. I hope volunteers will replicate Owen's efforts at RIPE, APNIC and LACNIC. As for subject above, all those whose miserable life needs a little uplift, please turn to http://www.camblab.com/nugget/slang2.pdf for your delectation :) Jeffrey Race
