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
* [EMAIL PROTECTED] (Charles Sprickman) [Wed 12 Mar 2003, 00:22 CET]: Seriously though, somewhere there is a popular site that is non-profit in nature that would trade say a month of free access for the hassle of being put into a widely-blocked block. Apparently hack.co.za has recently been resurrected; it's within 69.3/16, owned by Cogent. (Fugly traceroute, too.) I'm sure they'll appreciate your offer of another mirror! Regards, -- Niels. -- subvertise me
Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
Can you and he please take the gender debate off-list? Thanks, Owen --On Wednesday, March 12, 2003 17:36 -0800 JC Dill [EMAIL PROTECTED] wrote: Miss Rothschild wrote: On 2003-03-11-21:01:00, JC Dill [EMAIL PROTECTED] wrote: (Note to Mr. Dill, this is not intended to pick on you specifically, it's just a convenient place to butt in) Ahem. It's _MS._ Dill, thank you. Please post with a gender-specific name if you want to take offense when mis-identified. It is offensive to many people (both male and female) when someone automatically assumes that an unknown person is male. Especially since: Females aged 2 and up accounted for 50.4 percent of U.S. Internet users in May, edging out their male counterparts, according to New York-based Internet research firms Media Metrix and Jupiter Communications [...] At Dulles-based America Online Inc., the nation's biggest online services company, 52 percent of its 23.2 million subscribers worldwide are women. [...] Some scholars believe the new-found gender parity is just another reflection of the social changes of the past few decades, when men and women found themselves on more equal footing. That distinction has disappeared, and it is a huge revolution in society, says Michael Maccoby, an anthropologist and psychoanalyst. http://www.washingtonpost.com/ac2/wp-dyn/A137-2000Aug9?language=printer It is doubly offensive when you opine that I have an obligation to create and use [1] a gender-specific name solely to make things easier for you and other sexist jerks^W men^W^W induh^H^Hividuals. What would you do if my name was Pat or Chris? Or if YOUR name was Pat or Chris? Sure you can. You just need content unimportant enough that no one (the end users on a network that is still blocking 69/8, AND the networks that put up the sacrificial target host on a 69/8 IP) is truly hurt if the connection fails, but important enough that the failure will lead to the broken networks being fixed and clue being distributed. How do I configure my routers and web servers for that? ObNanog: Assuming you don't work at Google, if you aren't blocking 69/8 then your network will not be harmed in any way by the implementation of this proposal. Thus you need to do nothing special at all. OTOH, if you are improperly blocking 69/8, obviously you need to fix that when you configure your routers and web servers (sic). I'm suggesting that Google explain why they are doing this on a page linked off their homepage. If this is done, people ARE going to notice, and ARE going to find out why. When it is widely publicised, it WILL be noticed even more. Last I checked, Google was a for-profit business, not a charity house. I'm not sure how doing something that will make them look dumb, and cost them in valuable ad revenue, etc is in their best interests. Perhaps you could fill me in here. If you don't work at Google, then this is none of your concern. p.s. Please don't cc me on replies, or on replies to replies, etc. We have seen time after time that the propagation delays on the NANOG list, most likely resultant from sub-optimal postfix/majordomo configuration and/or an overloaded box, make it unsuitable for realtime communications. With this in mind, I have taken the liberty of cc'ing you in my reply, despite your request to the contrary. I have no urgent need for your reply, I am happy to wait until I receive email from the list. I politely made my request very clear, both in my headers and in the body of my email. You responded by taking extra steps to do the exact opposite of what I politely requested. Then you have the gall to flame me for my polite request. This was very rude of you. If duplicate messages cluttering your inbox are causing you much grief, They are just an annoyance, as is being mistakenly referred to as a male. Since you seem to think that these annoyances must be accepted as part of participating on the net, be prepared to be referred to as Miss Rothschild by me, now and in the future. What goes around comes around, girlfriend. jc [1] JC Dill is my real name. It is the name on my passport and other official documents.
Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
It's probably harder for anyone on this list to take BandyRush seriously than the other posters in question. :-) Owen --On Wednesday, March 12, 2003 22:01 -0500 [EMAIL PROTECTED] wrote: On Wed, 12 Mar 2003 21:27:51 EST, Andy Dills [EMAIL PROTECTED] said: Not be offended if somebody didn't know my gender? Fortunately, none of the simians on the list have objected to being classified as 'banana eaters' ;)
RE: 69/8...this sucks
Iljitsch van Beijnum wrote: On Tue, 11 Mar 2003, Owen DeLong wrote: In short, it doesn't. Longer answer, if the ISP configures his router correctly, he can actually refuse to accept advertisements from other sessions that are longer versions of prefixes received through this session. How??? There is a technically possible (but rather twisted) way you could not use the adverts, but not a way to refuse receiving them that I know of. Consider the connection between ISP X and ISP Y. ISP Y and is the provider who wants to null route any bogon traffic, even if ISP X advertises a more specific route for it. EBGP session between 192.168.0.1/30 and 192.168.0.2/30. ISP Y places 192.168.0.2 into VRF X-Real. Also in VRF X-Real is 192.168.1.1 Now a VRF X-Bogon is created containing 192.168.1.2 and 192.168.2.1. And finally the ISP's Default-IP-Routing-Table or other general internet VRF contains 192.168.2.2. 192.168.1.1/192.168.1.2 and 192.168.2.1/192.168.2.2 are connected. (for example, create virtual interfaces on a GigE representing each side of a pair in the relevant VRFs and then loop the VLANs of each pair of virtual interfaces -- is there a way to create two paired loopback interfaces to interconnect VRFs rather than extending to a physical connection like I always have?) 192.168.1.1 (BGP router in VRF X-Real) and 192.168.2.2 (BGP router in Default-IP-Routing-Table) communicate via IBGP route reflection. Either dynamic or static routing can be used to ensure 192.158.1.1 and 192.168.2.2 know the way to reach each other. BGP router 192.168.2.1 (BGP router in X-Bogon) takes ONLY a bogon feed, and modifies the received routes to set the next hop either into oblivion (eg. out a loopback with no ip unreachables set and a deny ip any any ACL) or to a some kind of DoS/worm tracking server (since almost all of this traffic will be part of some kind of attack or worm, and you will quite probably want to know about it; you can also set your default route in your regular network to such a server that records all traffic received). Policy routing is applied on interface 192.168.1.2 saying set IP default next hop 192.168.2.2 and on interface 192.168.2.1 saying set IP default next hop 192.168.1.1. It would work. I've done things similar to this example in a lab to prove they work. I wouldn't want to let a configuration like this loose on the production internet, though, and anyone who would is probably a _Certifiable_ Cisco Internet Engineer. David.
RE: 69/8...this sucks
Stephen J Wilcox wrote: On Wed, 12 Mar 2003, David Luyer wrote: Iljitsch van Beijnum wrote: On Tue, 11 Mar 2003, Owen DeLong wrote: In short, it doesn't. Longer answer, if the ISP configures his router correctly, he can actually refuse to accept advertisements from other sessions that are longer versions of prefixes received through this session. How??? There is a technically possible (but rather twisted) way you could not use the adverts, but not a way to refuse receiving them that I know of. I think youre mixing up with ingress filtering by prefix list which you can specify prefix length on and hence ignore longer (or smaller) matches. The example I provided achieved both ingress and egress filtering based on routes in a bogon BGP feed, in a way which would even block when a more-specific route is in the provider's BGP table. While it didn't actually prevent the routes being in the routing table (as I said, it doesn't provide a way to stop receiving them), it does prevent traffic from and to the bogon locations, which is a significant part of the reason to use bogon lists. However, yes, it has some deficiencies[1] compared with using the static bogon lists for route filtering (and ingress/egress); it does not prevent routing table bloat, and it does not prevent traffic travelling across your WAN to the point of network egress only to be dropped. If you want to actually not receive into your network at all the BGP routes which match bogons, as I stated earlier, there is no way I know of to do this via a BGP feed. The only way to do it that I know of would be to use either a prefix list or a standard ACL (you can do anything you can do with a prefix list with a compiled extended ACL on BGP routes, it's just less clear to read as an extended ACL). Although, Owen DeLong has stated that it is possible, so maybe we should wait for his response :-) David. [1] Apart from simply being a completely twisted design.
Re: [Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)]
for all of the $adjective schemes and ideas that have been posted, has anyone (besides jon and few others affected) been doing anything substanitive? outreach, more than any technical 'magic' that we can come up with, is the only 'real' solution (subjective real, what is real to me probably doesn't mean sh*t to you, but, hey, wtf). the media might be good, perhaps some online tech sites (someone with a 'big' name in networking would probably be better able to get exposure/contact than a network nobody) - there are/were some reporter-types lurking on nanog (are you out there??), if you are please help. one thing that has been mentioned is the bogon style filtering in various o/s firewall scripts. anyone thought to contact the authors of those scripts, or of the howtos on places like tldp.org? or is everyone too busy reveling in their technical grandeur the problem is simple: outdated filters. the cause is murkier, but lack of clue is probably the biggest, followed closely by lack of documentation on the part of previous admins (but we all document our work carefully right?!?!) the solution is simple: tell people that their filters are out of date the implementation is difficult only in terms of scale. none of us have the time to call/email or otherwise track down every admin out there, so we have to use the tools available to us (unless you really really think that reinventing the wheel again is a good thing) my $0.02 usd - this network nobody is now returning you to your regularly scheduled ego-fest joshua Richard A Steenbergen [EMAIL PROTECTED] wrote: On Tue, Mar 11, 2003 at 04:44:11PM -0800, JC Dill wrote: Charles Sprickman wrote: Seriously though, somewhere there is a popular site that is non-profit in nature that would trade say a month of free access for the hassle of being put into a widely-blocked block. The suggestion of putting Yahoo or Google on a 69/8 IP led me to this idea: Google could put their *beta* sites on a 69/8 IP, without causing them (Google) much Internet reachability/connectivity harm, and benefiting the Internet at large considerably. (Note to Mr. Dill, this is not intended to pick on you specifically, it's just a convenient place to butt in) JESUS H CHRIST ENOUGH ALREADY... Please stop with the hairbrained ideas to put random things in 69/8 space. These goals are mutually exclusive. You can't put important stuff on broken IPs, and you can't fix broken IPs by putting unimportant stuff on them. No one is going to move all of the root servers to try and fix a couple outdated filters, and no one who is still running outdated filters is going to notice it because they can't reach Google beta sites. These are not just bad ideas, they are STUPID ideas. What happened to the days when, before people posted to mailing lists, they thought will this make me look like an idiot in front of engineers across the entire planet? This is quickly not only becoming one of the most all-time useless threads ever, but it is continuing to repell the useful people who can no longer stand to read NANOG because of crap like this. Listen, I have space in 69/8, and it is NOT an epidemic. Back when 64/8 was opened up it destroyed a beautiful 64/3 filter on unallocated space, and yet somehow we all made it through just fine. The people who are stupid enough to filter IPs without a plan on keeping those filters up to date deserve their connectivity problems. Maybe next time they'll give consideration to whether they actually need unallocated bogon filters on every last linux server. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) 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: Put part of Google on 69/8 (was Re: 69/8...this sucks)
Thus spake JC Dill [EMAIL PROTECTED] p.s. Please don't cc me on replies, or on replies to replies, etc. I get the list email just fine and I don't need more than one copy of any given email. Really. 1) nanog can sometimes take hours to forward posts to all members 2) the people directly involved in the thread reasonably expect to get responses immediately 3) seeing your name in the To/Cc line may attach greater importance to the message 4) duplicates can be automatically blocked by procmail with: :0 Wh:.msgid.cache.lock | formail -D 8192 .msgid.cache 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
Thus spake Jack Bates [EMAIL PROTECTED] After the renumber, I'll only have 69/8 space, which means all critical services such as my mail, dns, and web servers will all be affected. I hear it now. I didn't receive mail from so and so! I check the logs and don't see an established connection to my server. So, is the problem that the far mail server lost the message, the user emailed the wrong place, or my new IP addresses weren't accessible by the far mail server or the dns servers that it uses? There's several BCPs that tell you to have at least one DNS server and at least one unfavorable MX off-site. If you did this, your mail would be safe, albeit a little slow from misconfigured sites. 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
I'm trying to get some time to actually put it in a router and test, but I believe there is a way to get similar functionality through a combination of route-map entries. When I have actual router config (I'll be testing on Cisco, but if anyone want's to provide me a Juniper testbed, I'll be happy to try that too), I'll post it. If I can't, I'll post a public apology and start beating on vendors to make it possible. :-) Owen --On Wednesday, March 12, 2003 11:41 PM +1100 David Luyer [EMAIL PROTECTED] wrote: Stephen J Wilcox wrote: On Wed, 12 Mar 2003, David Luyer wrote: Iljitsch van Beijnum wrote: On Tue, 11 Mar 2003, Owen DeLong wrote: In short, it doesn't. Longer answer, if the ISP configures his router correctly, he can actually refuse to accept advertisements from other sessions that are longer versions of prefixes received through this session. How??? There is a technically possible (but rather twisted) way you could not use the adverts, but not a way to refuse receiving them that I know of. I think youre mixing up with ingress filtering by prefix list which you can specify prefix length on and hence ignore longer (or smaller) matches. The example I provided achieved both ingress and egress filtering based on routes in a bogon BGP feed, in a way which would even block when a more-specific route is in the provider's BGP table. While it didn't actually prevent the routes being in the routing table (as I said, it doesn't provide a way to stop receiving them), it does prevent traffic from and to the bogon locations, which is a significant part of the reason to use bogon lists. However, yes, it has some deficiencies[1] compared with using the static bogon lists for route filtering (and ingress/egress); it does not prevent routing table bloat, and it does not prevent traffic travelling across your WAN to the point of network egress only to be dropped. If you want to actually not receive into your network at all the BGP routes which match bogons, as I stated earlier, there is no way I know of to do this via a BGP feed. The only way to do it that I know of would be to use either a prefix list or a standard ACL (you can do anything you can do with a prefix list with a compiled extended ACL on BGP routes, it's just less clear to read as an extended ACL). Although, Owen DeLong has stated that it is possible, so maybe we should wait for his response :-) David. [1] Apart from simply being a completely twisted design.
Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
JC Dill [EMAIL PROTECTED] wrote: Sure you can. You just need content unimportant enough that no one (the end users on a network that is still blocking 69/8, AND the networks that put up the sacrificial target host on a 69/8 IP) is truly hurt if the connection fails, but important enough that the failure will lead to the broken networks being fixed and clue being distributed. With that in mind, perhaps IANA and ICANN can be persuaded to renumber into new space every time some is allocated? Or if you enjoy helpdesk staff abused by end users in their thousands, encourage the use of a .sex tld and house the root in new space. TT
Re: 69/8...this sucks
On Tue, 11 Mar 2003 14:58:10 MST, Alec H. Peterson said: How about if we all chip in to hire a bunch of out of work consultants to fly to the NOCs of the various backbones who are being boneheaded to educate them with a clue-by-four? I suspect the problem isn't the backbones that have a NOC. The problem is small mompop ISPs and companies where the NOC and the senior secretary share a desk, and possibly a name. pgp0.pgp Description: PGP signature
Re: 69/8...this sucks
The problem is small mompop ISPs and companies where the NOC and the senior secretary share a desk, and possibly a name. maybe we should not encourage those who do not have time, talent, and inclination to install bogon route filters that need to be maintained?
Re: 69/8...this sucks
Andy Dills wrote: On Wed, 12 Mar 2003, Randy Bush wrote: maybe we should not encourage those who do not have time, talent, and inclination to install bogon route filters that need to be maintained? Sure. If the NSPs would just filter the bogon routes, nobody else would have to bother. Why is it that they don't? Filter (public, private and transit) peers or customers...? Or themselves? I've had a few customers spontaneously (ahem) come up with remarkably Rob Thomas configs (if any noun can be verbed, can any name be adjectived?) -- I usually convince them to tone down the filters a bit. The funny ones are those who've signed up for a partial table or default. Then again, I suppose you can't be too careful. Peter E. Fry
Re: 69/8...this sucks
On Wed, 12 Mar 2003, Peter E. Fry wrote: Andy Dills wrote: Sure. If the NSPs would just filter the bogon routes, nobody else would have to bother. Why is it that they don't? Filter (public, private and transit) peers or customers...? Or themselves? Yes. Andy Andy Dills 301-682-9972 Xecunet, LLCwww.xecu.net Dialup * Webhosting * E-Commerce * High-Speed Access
Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
Miss Rothschild wrote: On 2003-03-11-21:01:00, JC Dill [EMAIL PROTECTED] wrote: (Note to Mr. Dill, this is not intended to pick on you specifically, it's just a convenient place to butt in) Ahem. It's _MS._ Dill, thank you. Please post with a gender-specific name if you want to take offense when mis-identified. It is offensive to many people (both male and female) when someone automatically assumes that an unknown person is male. Especially since: Females aged 2 and up accounted for 50.4 percent of U.S. Internet users in May, edging out their male counterparts, according to New York-based Internet research firms Media Metrix and Jupiter Communications [...] At Dulles-based America Online Inc., the nation's biggest online services company, 52 percent of its 23.2 million subscribers worldwide are women. [...] Some scholars believe the new-found gender parity is just another reflection of the social changes of the past few decades, when men and women found themselves on more equal footing. That distinction has disappeared, and it is a huge revolution in society, says Michael Maccoby, an anthropologist and psychoanalyst. http://www.washingtonpost.com/ac2/wp-dyn/A137-2000Aug9?language=printer It is doubly offensive when you opine that I have an obligation to create and use [1] a gender-specific name solely to make things easier for you and other sexist jerks^W men^W^W induh^H^Hividuals. What would you do if my name was Pat or Chris? Or if YOUR name was Pat or Chris? Sure you can. You just need content unimportant enough that no one (the end users on a network that is still blocking 69/8, AND the networks that put up the sacrificial target host on a 69/8 IP) is truly hurt if the connection fails, but important enough that the failure will lead to the broken networks being fixed and clue being distributed. How do I configure my routers and web servers for that? ObNanog: Assuming you don't work at Google, if you aren't blocking 69/8 then your network will not be harmed in any way by the implementation of this proposal. Thus you need to do nothing special at all. OTOH, if you are improperly blocking 69/8, obviously you need to fix that when you configure your routers and web servers (sic). I'm suggesting that Google explain why they are doing this on a page linked off their homepage. If this is done, people ARE going to notice, and ARE going to find out why. When it is widely publicised, it WILL be noticed even more. Last I checked, Google was a for-profit business, not a charity house. I'm not sure how doing something that will make them look dumb, and cost them in valuable ad revenue, etc is in their best interests. Perhaps you could fill me in here. If you don't work at Google, then this is none of your concern. p.s. Please don't cc me on replies, or on replies to replies, etc. We have seen time after time that the propagation delays on the NANOG list, most likely resultant from sub-optimal postfix/majordomo configuration and/or an overloaded box, make it unsuitable for realtime communications. With this in mind, I have taken the liberty of cc'ing you in my reply, despite your request to the contrary. I have no urgent need for your reply, I am happy to wait until I receive email from the list. I politely made my request very clear, both in my headers and in the body of my email. You responded by taking extra steps to do the exact opposite of what I politely requested. Then you have the gall to flame me for my polite request. This was very rude of you. If duplicate messages cluttering your inbox are causing you much grief, They are just an annoyance, as is being mistakenly referred to as a male. Since you seem to think that these annoyances must be accepted as part of participating on the net, be prepared to be referred to as Miss Rothschild by me, now and in the future. What goes around comes around, girlfriend. jc [1] JC Dill is my real name. It is the name on my passport and other official documents.
RE: Put part of Google on 69/8 (was Re: 69/8...this sucks)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JC Dill Sent: March 12, 2003 8:37 PM To: [EMAIL PROTECTED] Subject: Re: Put part of Google on 69/8 (was Re: 69/8...this sucks) It is offensive to many people (both male and female) when someone automatically assumes that an unknown person is male. Especially since: [snip] It is doubly offensive when you opine that I have an obligation to create and use [1] a gender-specific name solely to make things easier for you and other sexist jerks^W men^W^W induh^H^Hividuals. What would you do if my name was Pat or Chris? Or if YOUR name was Pat or Chris? I've had the opposite problem (people thinking I'm female, when I'm not...), and it can get quite annoying, I agree. I wonder if perhaps a solution would be doing something I saw a gentleman from China, IIRC, do on this list quite a while ago. He had added (Mr.) to his .sig to make it easy for people to figure out his gender. Perhaps this would be an easyish way to somewhat-subtly warn people of the correct gender? Vivien -- (Mr.) Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
On Wed, 12 Mar 2003, JC Dill wrote: It is offensive to many people (both male and female) when someone automatically assumes that an unknown person is male. Especially since: Females aged 2 and up accounted for 50.4 percent of U.S. Internet users in May, edging out their male counterparts, according to New York-based Internet research firms Media Metrix and Jupiter Communications [...] At Dulles-based America Online Inc., the nation's biggest online services company, 52 percent of its 23.2 million subscribers worldwide are women. [...] Some scholars believe the new-found gender parity is just another reflection of the social changes of the past few decades, when men and women found themselves on more equal footing. That distinction has disappeared, and it is a huge revolution in society, says Michael Maccoby, an anthropologist and psychoanalyst. Got any statistics for the actual demographic in question (NANOG)? Probably not. But if you did, they'd support the assumption that an unknown person is likely male, with extreme statistical significance. It is doubly offensive when you opine that I have an obligation to create and use [1] a gender-specific name solely to make things easier for you and other sexist jerks^W men^W^W induh^H^Hividuals. What would you do if my name was Pat or Chris? Or if YOUR name was Pat or Chris? Not be offended if somebody didn't know my gender? p.s. Please don't cc me on replies, or on replies to replies, etc. We have seen time after time that the propagation delays on the NANOG list, most likely resultant from sub-optimal postfix/majordomo configuration and/or an overloaded box, make it unsuitable for realtime communications. With this in mind, I have taken the liberty of cc'ing you in my reply, despite your request to the contrary. I have no urgent need for your reply, I am happy to wait until I receive email from the list. I politely made my request very clear, both in my headers and in the body of my email. You responded by taking extra steps to do the exact opposite of what I politely requested. Then you have the gall to flame me for my polite request. This was very rude of you. Well, as somebody who rudely runs a mailing list, you should be used to standard mailing list operating procedure. If duplicate messages cluttering your inbox are causing you much grief, They are just an annoyance, as is being mistakenly referred to as a male. Since you seem to think that these annoyances must be accepted as part of participating on the net, be prepared to be referred to as Miss Rothschild by me, now and in the future. What goes around comes around, girlfriend. Except, you know he's male, and he didn't know you were female. So, you end up looking like a petty whiner who siezed upon the ability to be offended, even when there was no cause for it. Get over it. If my name was Andrea, I wouldn't be pissed if people assumed I was a woman. I'd correct them and move on. Andy Andy Dills 301-682-9972 Xecunet, LLCwww.xecu.net Dialup * Webhosting * E-Commerce * High-Speed Access
Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
From: Vivien M. I've had the opposite problem (people thinking I'm female, when I'm not...), and it can get quite annoying, I agree. Is this a pick up list? Find the guy or gal of your dreams that can think too? I figure that you either earn people's respect or admiration or you don't. Mailing-list sex hasn't ever been an interest of mine. :) -Jack
RE: Put part of Google on 69/8 (was Re: 69/8...this sucks)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jack Bates Sent: March 12, 2003 9:29 PM To: [EMAIL PROTECTED] Subject: Re: Put part of Google on 69/8 (was Re: 69/8...this sucks) From: Vivien M. I've had the opposite problem (people thinking I'm female, when I'm not...), and it can get quite annoying, I agree. Is this a pick up list? Find the guy or gal of your dreams that can think too? I figure that you either earn people's respect or admiration or you don't. Mailing-list sex hasn't ever been an interest of mine. :) Well, I've gotten [non-serious, I hope] marriage proposals from guys on Usenet before... I wouldn't go as far as Ms. Dill and saying it's offensive, but it is annoying that whenever you call some company and they look you up in their database, they say ma'am instead of sir (or, in Ms. Dill's case, presumably the opposite), and whenever you start posting in a new forum (Usenet, mailing list, etc), you inevitably have to correct the first person who refers to you with the wrong gender pronouns, etc, which is always embarassing for both you and the person who made the mistake... That said, this is getting horribly off-topic... though perhaps we should ask whether sex mailing lists are hosted on networks that filter 69/8? :) (Yes, I know, that wasn't a good attempt at being on topic...) Vivien -- (Mr.) Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
On Wed, 12 Mar 2003 21:27:51 EST, Andy Dills [EMAIL PROTECTED] said: Not be offended if somebody didn't know my gender? Fortunately, none of the simians on the list have objected to being classified as 'banana eaters' ;) pgp0.pgp Description: PGP signature
Re: 69/8...this sucks
At 05:16 PM 10-03-03 -0800, Owen DeLong wrote: OK... I'm late to this discussion (been mostly ignoring it due to volume in other places), but, Sean's 911-855 mail makes me wonder... It seems to me that it would be relatively simple to solve this problem by doing the following: 1. ICANN (or an ICANN designee, such as ARIN) shall issue an ASN range of 20 ASNs to be used as BOGON-ORIGINATE. 2. Each RIR should operate one or more routers with an open peering policy which will perform the following functions: A. Advertise all unissued space allocated to the RIR as originating from an ASN allocated to RIR-BOGON. B. Peer with the corresponding routers at each of the other RIRs and accept and readvertise their BOGON list through BGP. C. Provide a full BOGON feed to any router that chooses to peer, but not accept any routes or non-BGP traffic from those routers. 3. Any provider which wishes to filter BOGONs could peer with the closest one or two of these and set up route maps that modify the next-hop for all BOGONs to be an address which is statically routed to NULL0 on each of their routers. Apologies if this has been discussed before, but, it seems to me that this is the easiest way to make the data readily available to the community directly from the maintainers of the databases in a fashion which is automatically up to date. As suggested, it has been discussed before. See: http://www.ripe.net/ripe/mail-archives/lir-wg/2002/msg00815.html Unfortunately, the answer I got from RIPE was that they will never do this. -Hank Owen
Re: 69/8...this sucks
On Mon, 10 Mar 2003, E.B. Dreger wrote: The suggestion is to move ALL root, and as many TLD as possible, servers into the new space. Nobody has said move one or two, which indeed would be ineffective. So, you cant get people to fix bogons but you can get them all to fix their dns cache files overnight. I dont think so. And you want to push all the critical servers into a narrow set of IPs, that surely must have some implications for DoS more so than a well spread out set. I dont think your being realistic here and thinking thro properly.. Steve
Re: 69/8...this sucks
On Mon, 10 Mar 2003, Owen DeLong wrote: It seems to me that it would be relatively simple to solve this problem by doing the following: 1.ICANN (or an ICANN designee, such as ARIN) shall issue an ASN range of 20 ASNs to be used as BOGON-ORIGINATE. Why not just one or private/reserved? 2.Each RIR should operate one or more routers with an open peering policy which will perform the following functions: A. Advertise all unissued space allocated to the RIR as originating from an ASN allocated to RIR-BOGON. B. Peer with the corresponding routers at each of the other RIRs and accept and readvertise their BOGON list through BGP. C. Provide a full BOGON feed to any router that chooses to peer, but not accept any routes or non-BGP traffic from those routers. Of course, configure it wrong and you would end up sending all the junk that you would have null routed to your RIR. Sounds messy. Whats more I can see potential whenever we start creating these kind of self propagating blackholes for hackers to introduce genuine address blocks to create a DDoS. 3.Any provider which wishes to filter BOGONs could peer with the closest one or two of these and set up route maps that modify the next-hop for all BOGONs to be an address which is statically routed to NULL0 on each of their routers. How many ebgp sessions do the RIRs need to maintain?? A lot.. and the maintenance would be a nightmare. Dont think this will work purely because of that overhead you create!! Steve Apologies if this has been discussed before, but, it seems to me that this is the easiest way to make the data readily available to the community directly from the maintainers of the databases in a fashion which is automatically up to date. There are other ways that dont use BGP peering to create lists that are more suitable Steve
Re: 69/8...this sucks
2. Each RIR should operate one or more routers with an open peering policy which will perform the following functions: I agree that the RIR is the right source for the data but I think that BGP is the wrong protocol for publishing the data. Would you give a BGP feed to all of your customers so that they can inject up-to-date bogons into their firewall configs? Probably not and besides, the enterprise folks wouldn't have a clue what to do with BGP in the first place. That's why I have suggested using LDAP to publish the data. Apologies if this has been discussed before, but, it seems to me that this is the easiest way to make the data readily available to the community directly from the maintainers of the databases in a fashion which is automatically up to date. At this point a lot if people agree that the data needs to come directly from the database maintainers, in our case that's ARIN. And people also seem to agree that keeping the data automatically up to date is a good thing. We still have some discussion as to which protocol to use for publishing the data. I suggest that what is needed now is to engage ARIN in the discussion and get this on the agenda with them. Technical details can be worked out later, but now we need a commitment from ARIN that they can and will make this data available and keep it up to date. --Michael Dillon
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
On Mon, 10 Mar 2003, Owen DeLong wrote: It seems to me that it would be relatively simple to solve this problem by doing the following: 1. ICANN (or an ICANN designee, such as ARIN) shall issue an ASN range of 20 ASNs to be used as BOGON-ORIGINATE. Why not just one or private/reserved? Because I think there is value in each RIR having their own AS to peer EBGP with the other RIR's. I have no problem with this comming from reserved ASN space (that would be up to ICANN where they pull it from). As to private, it would have two problems. One, it would violate the RFC for private ASNs, and, two, it would likely conflict with existing internal uses of private ASNs at some carriers. 2. Each RIR should operate one or more routers with an open peering policy which will perform the following functions: A. Advertise all unissued space allocated to the RIR as originating from an ASN allocated to RIR-BOGON. B. Peer with the corresponding routers at each of the other RIRs and accept and readvertise their BOGON list through BGP. C. Provide a full BOGON feed to any router that chooses to peer, but not accept any routes or non-BGP traffic from those routers. Of course, configure it wrong and you would end up sending all the junk that you would have null routed to your RIR. Sounds messy. I think there are ways for the RIR to protect themselves from this. Whats more I can see potential whenever we start creating these kind of self propagating blackholes for hackers to introduce genuine address blocks to create a DDoS. Only if the hacker manages to own one or more of the RIR routers providing the feed. Remember, they will be configured not to listen to _ANY_ advertisement from any routers other than the other RIR routers that are known to provide equivalant service for the other RIRs. As such, assuming the RIRs run the routers with reasonable security precautions, I don't see this as being any more of a DDoS risk than any large backbone provider you can name today. 3. Any provider which wishes to filter BOGONs could peer with the closest one or two of these and set up route maps that modify the next-hop for all BOGONs to be an address which is statically routed to NULL0 on each of their routers. How many ebgp sessions do the RIRs need to maintain?? A lot.. and the maintenance would be a nightmare. Dont think this will work purely because of that overhead you create!! Nope... Yes, there would be _ALOT_ of ebgp sessions, but they wouldn't be full-table sessions. They'd be send-only with a small number of prefixes representing the bogon space. Also, it is possible to configure most routers to peer with all comers and assign the ones that don't have a specific configuration to a default peer group. That peer group would be configured to advertise-only the bogon list and accept nothing. With that configuration, the maintenance is near nil. Owen Steve Apologies if this has been discussed before, but, it seems to me that this is the easiest way to make the data readily available to the community directly from the maintainers of the databases in a fashion which is automatically up to date. There are other ways that dont use BGP peering to create lists that are more suitable Steve
Re: 69/8...this sucks
--On Tuesday, March 11, 2003 11:18 AM + [EMAIL PROTECTED] wrote: 2. Each RIR should operate one or more routers with an open peering policy which will perform the following functions: I agree that the RIR is the right source for the data but I think that BGP is the wrong protocol for publishing the data. Would you give a BGP feed to all of your customers so that they can inject up-to-date bogons into their firewall configs? Probably not and besides, the enterprise folks wouldn't have a clue what to do with BGP in the first place. That's why I have suggested using LDAP to publish the data. Nothing in my proposal precludes the data from being published via LDAP, but, if you think the enterprise wouldn't know how to handle the data via BGP, I gotta tell you, LDAP is much more difficult in my experience. As to publishing the data to customers, sure. Why not. See my previous post about all-comers BGP peer-groups. Apologies if this has been discussed before, but, it seems to me that this is the easiest way to make the data readily available to the community directly from the maintainers of the databases in a fashion which is automatically up to date. At this point a lot if people agree that the data needs to come directly from the database maintainers, in our case that's ARIN. And people also seem to agree that keeping the data automatically up to date is a good thing. We still have some discussion as to which protocol to use for publishing the data. I suggest that what is needed now is to engage ARIN in the discussion and get this on the agenda with them. Technical details can be worked out later, but now we need a commitment from ARIN that they can and will make this data available and keep it up to date. I don't see any reason we have to pick _A_ protocol. As far as I'm concerned, it could easily be published via LDAP, DNS, _AND_ BGP. I am already working on drafting a policy proposal. Owen --Michael Dillon
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
Er, guys... How does this fix the problem of a Malicious user advertising a more specific bogon route? -Original Message- From: Owen DeLong [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 11:22 AM To: Stephen J. Wilcox Cc: [EMAIL PROTECTED] Subject: Re: 69/8...this sucks On Mon, 10 Mar 2003, Owen DeLong wrote: It seems to me that it would be relatively simple to solve this problem by doing the following: 1. ICANN (or an ICANN designee, such as ARIN) shall issue an ASN range of 20 ASNs to be used as BOGON-ORIGINATE. Why not just one or private/reserved? Because I think there is value in each RIR having their own AS to peer EBGP with the other RIR's. I have no problem with this comming from reserved ASN space (that would be up to ICANN where they pull it from). As to private, it would have two problems. One, it would violate the RFC for private ASNs, and, two, it would likely conflict with existing internal uses of private ASNs at some carriers. 2. Each RIR should operate one or more routers with an open peering policy which will perform the following functions: A. Advertise all unissued space allocated to the RIR as originating from an ASN allocated to RIR-BOGON. B. Peer with the corresponding routers at each of the other RIRs and accept and readvertise their BOGON list through BGP. C. Provide a full BOGON feed to any router that chooses to peer, but not accept any routes or non-BGP traffic from those routers. Of course, configure it wrong and you would end up sending all the junk that you would have null routed to your RIR. Sounds messy. I think there are ways for the RIR to protect themselves from this. Whats more I can see potential whenever we start creating these kind of self propagating blackholes for hackers to introduce genuine address blocks to create a DDoS. Only if the hacker manages to own one or more of the RIR routers providing the feed. Remember, they will be configured not to listen to _ANY_ advertisement from any routers other than the other RIR routers that are known to provide equivalant service for the other RIRs. As such, assuming the RIRs run the routers with reasonable security precautions, I don't see this as being any more of a DDoS risk than any large backbone provider you can name today. 3. Any provider which wishes to filter BOGONs could peer with the closest one or two of these and set up route maps that modify the next-hop for all BOGONs to be an address which is statically routed to NULL0 on each of their routers. How many ebgp sessions do the RIRs need to maintain?? A lot.. and the maintenance would be a nightmare. Dont think this will work purely because of that overhead you create!! Nope... Yes, there would be _ALOT_ of ebgp sessions, but they wouldn't be full-table sessions. They'd be send-only with a small number of prefixes representing the bogon space. Also, it is possible to configure most routers to peer with all comers and assign the ones that don't have a specific configuration to a default peer group. That peer group would be configured to advertise-only the bogon list and accept nothing. With that configuration, the maintenance is near nil. Owen Steve Apologies if this has been discussed before, but, it seems to me that this is the easiest way to make the data readily available to the community directly from the maintainers of the databases in a fashion which is automatically up to date. There are other ways that dont use BGP peering to create lists that are more suitable Steve
RE: 69/8...this sucks
On Tue, 11 Mar 2003, Ejay Hire wrote: Er, guys... How does this fix the problem of a Malicious user advertising a more specific bogon route? Come on...clearly you haven't been paying attention. You need LDAP filters. LDAP filters and a South Vietnamese revolution against the IRRs for being fragmented and greedy. And if that doesn't poison your inverse arp, then multiplex a private bogon server with a centralized host scanner-based DNSBL. Don't forget the trailing dot! And don't forget to invert the subnet mask! Andy Andy Dills 301-682-9972 Xecunet, LLCwww.xecu.net Dialup * Webhosting * E-Commerce * High-Speed Access
RE: 69/8...this sucks
In short, it doesn't. Longer answer, if the ISP configures his router correctly, he can actually refuse to accept advertisements from other sessions that are longer versions of prefixes received through this session. However, it's primarily intended to solve the non-malicious, but somewhat malignant problem of out-of-date bogon filters by people trying to do the right thing. Owen Er, guys... How does this fix the problem of a Malicious user advertising a more specific bogon route? -Original Message- From: Owen DeLong [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 11:22 AM To: Stephen J. Wilcox Cc: [EMAIL PROTECTED] Subject: Re: 69/8...this sucks On Mon, 10 Mar 2003, Owen DeLong wrote: It seems to me that it would be relatively simple to solve this problem by doing the following: 1. ICANN (or an ICANN designee, such as ARIN) shall issue an ASN range of 20 ASNs to be used as BOGON-ORIGINATE. Why not just one or private/reserved? Because I think there is value in each RIR having their own AS to peer EBGP with the other RIR's. I have no problem with this comming from reserved ASN space (that would be up to ICANN where they pull it from). As to private, it would have two problems. One, it would violate the RFC for private ASNs, and, two, it would likely conflict with existing internal uses of private ASNs at some carriers. 2. Each RIR should operate one or more routers with an open peering policy which will perform the following functions: A. Advertise all unissued space allocated to the RIR as originating from an ASN allocated to RIR-BOGON. B. Peer with the corresponding routers at each of the other RIRs and accept and readvertise their BOGON list through BGP. C. Provide a full BOGON feed to any router that chooses to peer, but not accept any routes or non-BGP traffic from those routers. Of course, configure it wrong and you would end up sending all the junk that you would have null routed to your RIR. Sounds messy. I think there are ways for the RIR to protect themselves from this. Whats more I can see potential whenever we start creating these kind of self propagating blackholes for hackers to introduce genuine address blocks to create a DDoS. Only if the hacker manages to own one or more of the RIR routers providing the feed. Remember, they will be configured not to listen to _ANY_ advertisement from any routers other than the other RIR routers that are known to provide equivalant service for the other RIRs. As such, assuming the RIRs run the routers with reasonable security precautions, I don't see this as being any more of a DDoS risk than any large backbone provider you can name today. 3. Any provider which wishes to filter BOGONs could peer with the closest one or two of these and set up route maps that modify the next-hop for all BOGONs to be an address which is statically routed to NULL0 on each of their routers. How many ebgp sessions do the RIRs need to maintain?? A lot.. and the maintenance would be a nightmare. Dont think this will work purely because of that overhead you create!! Nope... Yes, there would be _ALOT_ of ebgp sessions, but they wouldn't be full-table sessions. They'd be send-only with a small number of prefixes representing the bogon space. Also, it is possible to configure most routers to peer with all comers and assign the ones that don't have a specific configuration to a default peer group. That peer group would be configured to advertise-only the bogon list and accept nothing. With that configuration, the maintenance is near nil. Owen Steve Apologies if this has been discussed before, but, it seems to me that this is the easiest way to make the data readily available to the community directly from the maintainers of the databases in a fashion which is automatically up to date. There are other ways that dont use BGP peering to create lists that are more suitable Steve
Re: 69/8...this sucks
Monday, March 10, 2003, 7:44:43 PM, you wrote: H Well... I am pretty sure Tier1 backbones are up-to-date on the bogon H filters :-) H As we've already discussed, it's really the smaller networks with outdated H bogons or with admins who don't know what they are doing.. Bingo. No silly bgp feed will fix this problem. The problem is all of the small customer networks that have been setup where the admin at the time installed a slick firewall using what was then current information and then walked away. I only see three ways to deal with this issue: 1. Contact each customer net that we find that is filtering on outdated information. I'm sure only the operators that have been assigned 69/8 space will start doing this (and have), since we are in fact responding to customer complaints. This process should be complete in say, oh, ten years or so. That should give us enough time to track them all down. Oh while we are at that, we might want to contact every operator of websites that are displaying sample firewalls using ipchains, iptables or ipfw that show 69/8 as a bogon network. We'll need to get them to change those webpages to show correct information. I mean, why have that information out there so some other clueless admin can simply start a fresh problem for us. I figure a couple of years to fix this too. 2. Find a way to break all of those customers networks that filter 69/8 so that the response time to fix it is much less than the time to contact each and every operator. The only way to do that is to move something like the root servers into this space. Yes it's crazy but it's the only way to break smaller networks. But once joe sixpack wonders why he can't get to Yahoo this morning and calls his consultant, the problem would be resolved a lot faster than it will take us to track them down and do option 1. 3. Have us 69/8 address assignees simply live with the problem and stop complaining in forums such as this. We're the ones dealing with the end user complaints about lost connectivity to sites once we've renumbering a link into this range. This goes back to option number 1, we'll simply bite the bullet and live with the problem and fix them as we find them. I'll admit, I run a small network and was quite happy to receive my first ARIN assignment some months ago. I wasn't so happy to find out that once I renumbered our internal office workstations into this range I had complaints from other employees about sites they could not reach (starting with *.ca.gov). I haven't even put one customer net into this new range yet and I've already reacted to a couple of dozen problems that less than 20 employees have found. I'm honestly scared to death about renumbering all of my customers now. H I think we are just going around the circle/preaching to the choir on the H same topic here.. Is this like what... 3rd time we are discussing H this whole 69/8 issue :-D? Really, someone needs to get out this 69/8 H issue on the press.. Just a thought.. heh I had an email sent to me from a writer from circleid.com (Joe Baptista) back in late December regarding this issue when the problem first popped up on Nanog. As far as I can remember he was going to write up an article on this situation. I have no idea what became of that. Regards, Joe Boyce --- InterStar, Inc. - Shasta.com Internet Phone: +1 (530) 224-6866 x105 Email: [EMAIL PROTECTED]
RE: 69/8...this sucks
On Tue, 11 Mar 2003, Owen DeLong wrote: In short, it doesn't. Longer answer, if the ISP configures his router correctly, he can actually refuse to accept advertisements from other sessions that are longer versions of prefixes received through this session. However, it's primarily intended to solve the non-malicious, but somewhat malignant problem of out-of-date bogon filters by people trying to do the right thing. So why does it need to be done by somebody official? Why make organizations who don't have route servers do this? I've been peering with Rob's bogon server for a little while, and it works great. All of my customers get routes that point the bogons to a traffic sink on my network. If they were so inclined, they could sink that traffic before leaving their network. Andy Andy Dills 301-682-9972 Xecunet, LLCwww.xecu.net Dialup * Webhosting * E-Commerce * High-Speed Access
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
Look, there's no quick fix solution here. It's going to take real effort and real work. However, the _REASON_ all those pages reference sample bogon filters is because there isn't a global bogon filter that is dynamically updated available. If there was, and people were aware of it, they'd use it. (At least a significant percentage would). As such, is a BGP feed a panacea? No. Is it a step in the right direction? Yes. Will it solve the problem by itself? No. Will it improve the situation? Yes. Moving the root servers into that space may expidite solving the problem, but at a _VERY_ significant cost. Moving the GTLD servers might make a little more sense (at least then, you aren't requireing _EVERYONE_ to update their hint files), but I still don't think that's a good idea. Others have suggested that it needs to be available in LDAP. Some have suggested DNS. As far as I'm concerned, the same servers or some group of servers could easily be set up to publish the authoritative BOGON list via DNS, BGP, LDAP, HTTP(XML), FTP, and possibly other protocols. Getting bogged down in the protocol isn't helpful. Finding a way to make an authoritative global BOGON list (Note: BOGONS are the UNALLOCATED/UNASSIGNED/ RESERVED/INVALID _LARGE_ blocks, _NOT_ every little hole in the allocation space) that is dynamically updated _IS_ the most practical solution for the long haul. Renumbering multiple global resources every time an RIR starts issuing from a new /8 isn't feasible. Publishing the data over the net is. Owen --On Tuesday, March 11, 2003 10:06 AM -0800 Joe Boyce [EMAIL PROTECTED] wrote: Monday, March 10, 2003, 7:44:43 PM, you wrote: H Well... I am pretty sure Tier1 backbones are up-to-date on the bogon H filters :-) H As we've already discussed, it's really the smaller networks with outdated H bogons or with admins who don't know what they are doing.. Bingo. No silly bgp feed will fix this problem. The problem is all of the small customer networks that have been setup where the admin at the time installed a slick firewall using what was then current information and then walked away. I only see three ways to deal with this issue: 1. Contact each customer net that we find that is filtering on outdated information. I'm sure only the operators that have been assigned 69/8 space will start doing this (and have), since we are in fact responding to customer complaints. This process should be complete in say, oh, ten years or so. That should give us enough time to track them all down. Oh while we are at that, we might want to contact every operator of websites that are displaying sample firewalls using ipchains, iptables or ipfw that show 69/8 as a bogon network. We'll need to get them to change those webpages to show correct information. I mean, why have that information out there so some other clueless admin can simply start a fresh problem for us. I figure a couple of years to fix this too. 2. Find a way to break all of those customers networks that filter 69/8 so that the response time to fix it is much less than the time to contact each and every operator. The only way to do that is to move something like the root servers into this space. Yes it's crazy but it's the only way to break smaller networks. But once joe sixpack wonders why he can't get to Yahoo this morning and calls his consultant, the problem would be resolved a lot faster than it will take us to track them down and do option 1. 3. Have us 69/8 address assignees simply live with the problem and stop complaining in forums such as this. We're the ones dealing with the end user complaints about lost connectivity to sites once we've renumbering a link into this range. This goes back to option number 1, we'll simply bite the bullet and live with the problem and fix them as we find them. I'll admit, I run a small network and was quite happy to receive my first ARIN assignment some months ago. I wasn't so happy to find out that once I renumbered our internal office workstations into this range I had complaints from other employees about sites they could not reach (starting with *.ca.gov). I haven't even put one customer net into this new range yet and I've already reacted to a couple of dozen problems that less than 20 employees have found. I'm honestly scared to death about renumbering all of my customers now. H I think we are just going around the circle/preaching to the choir on the H same topic here.. Is this like what... 3rd time we are discussing H this whole 69/8 issue :-D? Really, someone needs to get out this 69/8 H issue on the press.. Just a thought.. heh I had an email sent to me from a writer from circleid.com (Joe Baptista) back in late December regarding this issue when the problem first popped up on Nanog. As far as I can remember he was going to write up an article on this situation. I have no idea what became of that. Regards, Joe Boyce --- InterStar, Inc. - Shasta.com Internet Phone: +1 (530)
RE: 69/8...this sucks
Great. If you can get _EVERYONE_ to listen to Rob's server, I'm all for it. Frankly, I was unaware of Rob's server. However, I think it makes more sense to have the people maintaining the data distribute the data directly from the source. Right now, I'm betting that Rob's server requires someone in Rob's organization to keep up to date on all the RIRs and manually tweak the contents of his list. What is the perceived advantage to the extra layer of indirection? Owen --On Tuesday, March 11, 2003 1:11 PM -0500 Andy Dills [EMAIL PROTECTED] wrote: On Tue, 11 Mar 2003, Owen DeLong wrote: In short, it doesn't. Longer answer, if the ISP configures his router correctly, he can actually refuse to accept advertisements from other sessions that are longer versions of prefixes received through this session. However, it's primarily intended to solve the non-malicious, but somewhat malignant problem of out-of-date bogon filters by people trying to do the right thing. So why does it need to be done by somebody official? Why make organizations who don't have route servers do this? I've been peering with Rob's bogon server for a little while, and it works great. All of my customers get routes that point the bogons to a traffic sink on my network. If they were so inclined, they could sink that traffic before leaving their network. Andy Andy Dills 301-682-9972 Xecunet, LLCwww.xecu.net Dialup * Webhosting * E-Commerce * High-Speed Access
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
On Tue, 11 Mar 2003, Ejay Hire wrote: Er, guys... How does this fix the problem of a Malicious user advertising a more specific bogon route? Come on...clearly you haven't been paying attention. You need LDAP filters. LDAP filters and a South Vietnamese revolution against the IRRs for being fragmented and greedy. Careful. We are watching and are prepared to ruthlessly squash any attempted rebellion. And if that doesn't poison your inverse arp, then multiplex a private bogon server with a centralized host scanner-based DNSBL. Don't forget the trailing dot! And don't forget to invert the subnet mask! Hey, I've already thought of all that and captured it in an XML schema (with ASN.1 encoding)! I will be presenting an Internet Draft next week at the IETF in the CRISP/RPSEC/GROW/IDR meetings. Seriously... As has been suggested, I think we need to do a better job of identifying the population and type of devices that are filtering these prefixes. Are they really predominately BGP speaking routers, or largely some mishmash of non-BGP speaking firewalls/proxies/NAT's? If it's the former, then a BGP based solution has some merit. If the latter, I think it unreasonable to expect these firewalls to speak BGP. What's needed is a canonical represention of the bogon list and some tools to generate the filter list in the appropriate config format for a number target devices. There's already a canonical list maintained by Rob Thomas in the RADB (see fltr-martian, fltr-unallocated, and fltr-bogons). I've suggested to Rob that he may want to include a PGP signature in a remarks section of the object to provide a greater level of confidence (hopefully with a key that's escrowed somehow -- god forbid anything should happen to Rob). I should also note that some of the RIR's have indicated they will be providing more precise information on their unallocated space. As far as tools go, while IRRToolSet has extensive support for RPSL, it may be too complex for a novice Net admin. Perhaps some simple Perl scripts to generate filter configs from RPSL filter objects would be useful? Larry Blunk Merit
RE: 69/8...this sucks
I've never posted to the list, just lurk, for over a year now, but this has to be said. Can we please take this discussion off-list to private conversation. It's gotten worse then spam. I see a nanog message and just start deleting them now. -rd -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Larry J. Blunk Sent: Tuesday, March 11, 2003 1:01 PM To: Andy Dills Cc: Ejay Hire; [EMAIL PROTECTED] Subject: Re: 69/8...this sucks On Tue, 11 Mar 2003, Ejay Hire wrote: Er, guys... How does this fix the problem of a Malicious user advertising a more specific bogon route? Come on...clearly you haven't been paying attention. You need LDAP filters. LDAP filters and a South Vietnamese revolution against the IRRs for being fragmented and greedy. Careful. We are watching and are prepared to ruthlessly squash any attempted rebellion. And if that doesn't poison your inverse arp, then multiplex a private bogon server with a centralized host scanner-based DNSBL. Don't forget the trailing dot! And don't forget to invert the subnet mask! Hey, I've already thought of all that and captured it in an XML schema (with ASN.1 encoding)! I will be presenting an Internet Draft next week at the IETF in the CRISP/RPSEC/GROW/IDR meetings. Seriously... As has been suggested, I think we need to do a better job of identifying the population and type of devices that are filtering these prefixes. Are they really predominately BGP speaking routers, or largely some mishmash of non-BGP speaking firewalls/proxies/NAT's? If it's the former, then a BGP based solution has some merit. If the latter, I think it unreasonable to expect these firewalls to speak BGP. What's needed is a canonical represention of the bogon list and some tools to generate the filter list in the appropriate config format for a number target devices. There's already a canonical list maintained by Rob Thomas in the RADB (see fltr-martian, fltr-unallocated, and fltr-bogons). I've suggested to Rob that he may want to include a PGP signature in a remarks section of the object to provide a greater level of confidence (hopefully with a key that's escrowed somehow -- god forbid anything should happen to Rob). I should also note that some of the RIR's have indicated they will be providing more precise information on their unallocated space. As far as tools go, while IRRToolSet has extensive support for RPSL, it may be too complex for a novice Net admin. Perhaps some simple Perl scripts to generate filter configs from RPSL filter objects would be useful? Larry Blunk Merit
Re: 69/8...this sucks
Appologies for the poor attempt at humor... However, there is some useful content at the end of the message. Essentially, I think this is one of those problems that can never fully be solved. Just as we will never get every last worm-infected host off the network. The best that we can do is provide procedures for those who filter on unallocated space so than can keep their filters updated on a timely and accurate basis. For those who do not wish to use such procedures, we should stridently urge them to filter only on martians, not unallocated space. -Larry Blunk Merit I agree. -Original Message- From: Rick Duff [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 2:09 PM To: 'Larry J. Blunk'; 'Andy Dills' Cc: 'Ejay Hire'; [EMAIL PROTECTED] Subject: RE: 69/8...this sucks I've never posted to the list, just lurk, for over a year now, but this has to be said. Can we please take this discussion off-list to private conversation. It's gotten worse then spam. I see a nanog message and just start deleting them now. -rd -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Larry J. Blunk Sent: Tuesday, March 11, 2003 1:01 PM To: Andy Dills Cc: Ejay Hire; [EMAIL PROTECTED] Subject: Re: 69/8...this sucks On Tue, 11 Mar 2003, Ejay Hire wrote: Er, guys... How does this fix the problem of a Malicious user advertising a more specific bogon route? Come on...clearly you haven't been paying attention. You need LDAP filters. LDAP filters and a South Vietnamese revolution against the IRRs for being fragmented and greedy. Careful. We are watching and are prepared to ruthlessly squash any attempted rebellion. And if that doesn't poison your inverse arp, then multiplex a private bogon server with a centralized host scanner-based DNSBL. Don't forget the trailing dot! And don't forget to invert the subnet mask! Hey, I've already thought of all that and captured it in an XML schema (with ASN.1 encoding)! I will be presenting an Internet Draft next week at the IETF in the CRISP/RPSEC/GROW/IDR meetings. Seriously... As has been suggested, I think we need to do a better job of identifying the population and type of devices that are filtering these prefixes. Are they really predominately BGP speaking routers, or largely some mishmash of non-BGP speaking firewalls/proxies/NAT's? If it's the former, then a BGP based solution has some merit. If the latter, I think it unreasonable to expect these firewalls to speak BGP. What's needed is a canonical represention of the bogon list and some tools to generate the filter list in the appropriate config format for a number target devices. There's already a canonical list maintained by Rob Thomas in the RADB (see fltr-martian, fltr-unallocated, and fltr-bogons). I've suggested to Rob that he may want to include a PGP signature in a remarks section of the object to provide a greater level of confidence (hopefully with a key that's escrowed somehow -- god forbid anything should happen to Rob). I should also note that some of the RIR's have indicated they will be providing more precise information on their unallocated space. As far as tools go, while IRRToolSet has extensive support for RPSL, it may be too complex for a novice Net admin. Perhaps some simple Perl scripts to generate filter configs from RPSL filter objects would be useful? Larry Blunk Merit
Re: 69/8...this sucks
On Tue, Mar 11, 2003 at 11:38:23AM -0800, Owen DeLong wrote: As such, is a BGP feed a panacea? No. Is it a step in the right direction? Yes. Will it solve the problem by itself? No. Will it improve the So, someone feel free to smack me if I'm mentioning something which has been discussed already (there isn't enough masochism in the world to make me read this entire thread), but... How exactly is a BGP feed of bogons useful in any way shape form of fashion? It doesn't prevent people from announcing more specifics, it doesn't do anything about source address bogons, it can't be used to packet filter... How exactly would it do anything other than simply not having the route at all? If and when some vendor adds support for taking the routes from a bgp feed and using them in a packet filter, sign me up. Until then, I must be missing something. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
RE: 69/8...this sucks
On Tue, 11 Mar 2003, Rick Duff wrote: I've never posted to the list, just lurk, for over a year now, but this has to be said. Can we please take this discussion off-list to private conversation. It's gotten worse then spam. I see a nanog message and just start deleting them now. Come on...everybody takes turns being the nanog nazi, but it isn't your turn yet. Two suggestions: Number one, you'll probably find your list reading experience to be far more pleasurable if you filter. If nothing else, filter each mailing list you're on into its own box. It allows you to look at nanog mail only when you want to look at nanog mail. But then you can take it a step further, and plonk threads or individual posters into the bit bucket (whatever the Outlook Express equivalent of /dev/null is). I'm being nice; some would simply shout man procmail and stick YOU in their .procmailrc. Number two, don't complain about posts which are essentially complaints themselves (albeit with a sense of humor). My post wasn't just a silly gesture, it was an attempt to point out the ridiculous extremes and insane overlapping the threads have denegerated into, without falling into the shut up and go away. why I can't ping sublimedirectory.com? cliche. At the minute, the following concerns and ideas are being tossed about, which all overlap slightly but not totally, resulting in a ridiculous mishmash of ideas that have begun to feed on itself (note that these have all been brought up in different ways, and are not all parts of a single thread): sBGP bogon filtering centralized scanning for the prevention of abuse idealistic segmentation of the net into the pure and impure lack of reachibility from 69/8 If you step back on some high level, the threads are all about lazy and or nonexistent network administration, and ways to cope with the impact on the net we all have to run. But if you read every post, it has degenerated into an argument over whether or not everything is ready to be a nail for the LDAP hammer and whether or not people actually understand how sBGP is proposed to work. But at the same time, I can't think of a place this stuff would be more relevant. Which is why it's good to filter...so you still be subscribed to the list AND not be annoyed. Andy Andy Dills 301-682-9972 Xecunet, LLCwww.xecu.net Dialup * Webhosting * E-Commerce * High-Speed Access
Re: 69/8...this sucks
Look, there's no quick fix solution here. so let's see how much of a kludge we can make to show how clever we are. randy
Re: 69/8...this sucks
--On Tuesday, March 11, 2003 16:47 -0500 Randy Bush [EMAIL PROTECTED] wrote: so let's see how much of a kludge we can make to show how clever we are. How about if we all chip in to hire a bunch of out of work consultants to fly to the NOCs of the various backbones who are being boneheaded to educate them with a clue-by-four? Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
RE: 69/8...this sucks
On Tue, 11 Mar 2003, Owen DeLong wrote: In short, it doesn't. Longer answer, if the ISP configures his router correctly, he can actually refuse to accept advertisements from other sessions that are longer versions of prefixes received through this session. How???
Re: 69/8...this sucks
On Tue, 11 Mar 2003, Randy Bush wrote: so let's see how much of a kludge we can make to show how clever we are. Hey, I already came up with the slashdot idea. Seriously though, somewhere there is a popular site that is non-profit in nature that would trade say a month of free access for the hassle of being put into a widely-blocked block. Like anything else, until end users complain, nothing happens. Charles randy
Re: 69/8...this sucks
To a degree the problem is ability to reach proper persons. I'd like to be able to enter as# or ip and immediatly get email for a tech who knows what to do. Radb is supposed to provide some of these functionalities, so does ip whois, so does dns whois. Usually one of these will get you what you need or if nothing else, youd'd look at AS traceroute and contact the upstream. Reality is we do have hierchical structure in ip as assignments/allocations: IANA-RIR-LIR-ISP-END-USER but currect information exchange is only possible at one level (i.e RIR should know how to contact LIR, ISP should know how to contact END-USER). A lot smaller hierchy is with AS numbers - IANA-RIR-END-USER. I guess I forgot about all this in my proposal but I'll be sure to clarify that when new assignment is received ARIN should notify not only their IP subscriber members and end-users (ip assignments) customers but also all those listed as contacts for ASNs (removing duplicate emails gathered from all the sources, of course). Unfortunetly ASN contact information is one of the least maintained as far as ARIN data goes. And too bad... In my opinion fairly good way to solve the problem would be to make sure that ASN contact info is up to date for all RIRs and when new global assignments are made than IANA makes the announcement and RIRs pass it along to their AS contacts and as backup through longer ip path. I'm fairly certain if info on who to contact was up to date at RIRs, the reachibility of this would be well over 99% and number of blackholes for users of new ip block would be very small. On Tue, 11 Mar 2003, Alec H. Peterson wrote: --On Tuesday, March 11, 2003 16:47 -0500 Randy Bush [EMAIL PROTECTED] wrote: so let's see how much of a kludge we can make to show how clever we are. How about if we all chip in to hire a bunch of out of work consultants to fly to the NOCs of the various backbones who are being boneheaded to educate them with a clue-by-four? Alec -- Alec H. Peterson -- [EMAIL PROTECTED] Chief Technology Officer Catbird Networks, http://www.catbird.com
Re: 69/8...this sucks
On Tue, 11 Mar 2003, Randy Bush wrote: Look, there's no quick fix solution here. so let's see how much of a kludge we can make to show how clever we are. Excellent point...but then, what to do? Have we given up and decided that addressing the 69/8 (and similar, future issues) is a social problem that can't be fixed via technical means? Are you ok with a solution of patiently waiting for some sort of critical mass to occur with each new /8 that gets allocated? Sooner or later, enough content will be in 69/8 (and other commonly filtered /8s) that people will be forced to fix their filters. But is that the only way? And would your answer change if you were one of the first networks to be assigned space in the new range? Andy Andy Dills 301-682-9972 Xecunet, LLCwww.xecu.net Dialup * Webhosting * E-Commerce * High-Speed Access
Put part of Google on 69/8 (was Re: 69/8...this sucks)
Charles Sprickman wrote: Seriously though, somewhere there is a popular site that is non-profit in nature that would trade say a month of free access for the hassle of being put into a widely-blocked block. The suggestion of putting Yahoo or Google on a 69/8 IP led me to this idea: Google could put their *beta* sites on a 69/8 IP, without causing them (Google) much Internet reachability/connectivity harm, and benefiting the Internet at large considerably. Set up a page (hopefully linked from www.google.com) that lists all of Google's present beta sites. On this page, inform the user that the beta sites are hosted on newly allocated IP addresses and that if the said user can't reach the beta sites, it most likely means that their ISP/Company is improperly filtering these newly valid IP addresses, Instruct these affected users to contact their IPS's support desk or their company's IS department and alert them that they need to update their IP filter set to avoid filtering newly released and valid IPs. Then also link to a site such as http://www.cymru.com/Bogons/ which explains bogon filters, shows how to find the latest lists, and educates the filter-clueless on how to subscribe to appropriate announcement lists to become aware of updates/changes in what IPs can be safely filtered. Google could also explain that they are doing this to help the Internet community fix this problem, and perhaps explain why it is a problem. They would get tons of good press which would help advertise Google and their beta projects. Froogle is a very kewl site that gets better by the day (thanks guys, I use it all the time!), and I bet it also gets more traffic by the day. This would be a good way for Google to get free publicity for Froogle and other beta sites, and get big Internet community good guy points for helping fix the 69/8 bogon filter problem, without outright breaking the highly popular Google websearch site itself. Is there anyone from Google lurking here on nanog? jc (Googling on: google beta, I discovered that Google itself went beta in February of 1999, just 4 years ago. My, how time flies!)
RE: Put part of Google on 69/8 (was Re: 69/8...this sucks)
Idea #2.. CNN.com-- Put some of their content.. They would probrably really enjoy the publicity.. And that would really be an educational point.. Anybody here from there??? Jim The suggestion of putting Yahoo or Google on a 69/8 IP led me to this idea: Google could put their *beta* sites on a 69/8 IP, without causing them (Google) much Internet reachability/connectivity harm, and benefiting the Internet at large considerably. Set up a page (hopefully linked from www.google.com) that lists all of Google's present beta sites.
Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
On Tue, Mar 11, 2003 at 04:44:11PM -0800, JC Dill wrote: Charles Sprickman wrote: Seriously though, somewhere there is a popular site that is non-profit in nature that would trade say a month of free access for the hassle of being put into a widely-blocked block. The suggestion of putting Yahoo or Google on a 69/8 IP led me to this idea: Google could put their *beta* sites on a 69/8 IP, without causing them (Google) much Internet reachability/connectivity harm, and benefiting the Internet at large considerably. (Note to Mr. Dill, this is not intended to pick on you specifically, it's just a convenient place to butt in) JESUS H CHRIST ENOUGH ALREADY... Please stop with the hairbrained ideas to put random things in 69/8 space. These goals are mutually exclusive. You can't put important stuff on broken IPs, and you can't fix broken IPs by putting unimportant stuff on them. No one is going to move all of the root servers to try and fix a couple outdated filters, and no one who is still running outdated filters is going to notice it because they can't reach Google beta sites. These are not just bad ideas, they are STUPID ideas. What happened to the days when, before people posted to mailing lists, they thought will this make me look like an idiot in front of engineers across the entire planet? This is quickly not only becoming one of the most all-time useless threads ever, but it is continuing to repell the useful people who can no longer stand to read NANOG because of crap like this. Listen, I have space in 69/8, and it is NOT an epidemic. Back when 64/8 was opened up it destroyed a beautiful 64/3 filter on unallocated space, and yet somehow we all made it through just fine. The people who are stupid enough to filter IPs without a plan on keeping those filters up to date deserve their connectivity problems. Maybe next time they'll give consideration to whether they actually need unallocated bogon filters on every last linux server. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
And I'd like to add I agree. The problems were wide at first, they have definitely dropped off. Everyone important, is reachable now it seems. I can think of maybe one or two small islands who might still be unreachable but hey if I lived in the troopics I'd be outside with an umbrella drink too, not changing filters. Bottom line is that the only way to fix this problem is to move in to the space, use the space, and contact people when its broken. Nanog although perhaps not the best place for this, has helped in this goal for me at least 4 or 5 times and its fixed for everyone not just me. With all of us pounding away the problems clear quickly. - Original Message - From: Richard A Steenbergen [EMAIL PROTECTED] To: JC Dill [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 5:17 PM Subject: Re: Put part of Google on 69/8 (was Re: 69/8...this sucks) On Tue, Mar 11, 2003 at 04:44:11PM -0800, JC Dill wrote: Charles Sprickman wrote: Seriously though, somewhere there is a popular site that is non-profit in nature that would trade say a month of free access for the hassle of being put into a widely-blocked block. The suggestion of putting Yahoo or Google on a 69/8 IP led me to this idea: Google could put their *beta* sites on a 69/8 IP, without causing them (Google) much Internet reachability/connectivity harm, and benefiting the Internet at large considerably. (Note to Mr. Dill, this is not intended to pick on you specifically, it's just a convenient place to butt in) JESUS H CHRIST ENOUGH ALREADY... Please stop with the hairbrained ideas to put random things in 69/8 space. These goals are mutually exclusive. You can't put important stuff on broken IPs, and you can't fix broken IPs by putting unimportant stuff on them. No one is going to move all of the root servers to try and fix a couple outdated filters, and no one who is still running outdated filters is going to notice it because they can't reach Google beta sites. These are not just bad ideas, they are STUPID ideas. What happened to the days when, before people posted to mailing lists, they thought will this make me look like an idiot in front of engineers across the entire planet? This is quickly not only becoming one of the most all-time useless threads ever, but it is continuing to repell the useful people who can no longer stand to read NANOG because of crap like this. Listen, I have space in 69/8, and it is NOT an epidemic. Back when 64/8 was opened up it destroyed a beautiful 64/3 filter on unallocated space, and yet somehow we all made it through just fine. The people who are stupid enough to filter IPs without a plan on keeping those filters up to date deserve their connectivity problems. Maybe next time they'll give consideration to whether they actually need unallocated bogon filters on every last linux server. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
RE: Put part of Google on 69/8 (was Re: 69/8...this sucks)
Wanting to continue to be a part of the solution, and not part of the problem, I just want to post publicly to the list that we would gladly donate some IP space from our ARIN direct assignment (which lives in the 69/8 CIDR) to the cause. If anyone is interested, please contact me off list. Sincerely, Todd A. Blank CTO IPOutlet LLC 614.207.5853 -Original Message- From: McBurnett, Jim [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 8:00 PM To: JC Dill; [EMAIL PROTECTED] Subject: RE: Put part of Google on 69/8 (was Re: 69/8...this sucks) Idea #2.. CNN.com-- Put some of their content.. They would probrably really enjoy the publicity.. And that would really be an educational point.. Anybody here from there??? Jim The suggestion of putting Yahoo or Google on a 69/8 IP led me to this idea: Google could put their *beta* sites on a 69/8 IP, without causing them (Google) much Internet reachability/connectivity harm, and benefiting the Internet at large considerably. Set up a page (hopefully linked from www.google.com) that lists all of Google's present beta sites.
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: Put part of Google on 69/8 (was Re: 69/8...this sucks)
On Tue, Mar 11, 2003 at 06:01:00PM -0800, JC Dill wrote: Ahem. It's _MS._ Dill, thank you. Woops, my apologies _MS._ Dill. The JC is ambiguous. Maybe next time you will stop and think will this make me look like a sexist idiot in front of engineers across the entire planet? before posting to a mailing list. (If the shoe fits, wear it.) Sexist? Now that's just absurd. I took a guess and lost, big deal. If anything, that proves my opinion of your idea has nothing to do with your gender. Get over it. p.s. Please don't cc me on replies, or on replies to replies, etc. I get the list email just fine and I don't need more than one copy of any given email. Really. I believe you'll find reply-all is commonly used, get over it. Really. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Put part of Google on 69/8 (was Re: 69/8...this sucks)
On 2003-03-11-21:01:00, JC Dill [EMAIL PROTECTED] wrote: [...] (Note to Mr. Dill, this is not intended to pick on you specifically, it's just a convenient place to butt in) Ahem. It's _MS._ Dill, thank you. Please post with a gender-specific name if you want to take offense when mis-identified. Sure you can. You just need content unimportant enough that no one (the end users on a network that is still blocking 69/8, AND the networks that put up the sacrificial target host on a 69/8 IP) is truly hurt if the connection fails, but important enough that the failure will lead to the broken networks being fixed and clue being distributed. How do I configure my routers and web servers for that? I'm suggesting that Google explain why they are doing this on a page linked off their homepage. If this is done, people ARE going to notice, and ARE going to find out why. When it is widely publicised, it WILL be noticed even more. Last I checked, Google was a for-profit business, not a charity house. I'm not sure how doing something that will make them look dumb, and cost them in valuable ad revenue, etc is in their best interests. Perhaps you could fill me in here. p.s. Please don't cc me on replies, or on replies to replies, etc. We have seen time after time that the propagation delays on the NANOG list, most likely resultant from sub-optimal postfix/majordomo configuration and/or an overloaded box, make it unsuitable for realtime communications. With this in mind, I have taken the liberty of cc'ing you in my reply, despite your request to the contrary. If duplicate messages cluttering your inbox are causing you much grief, prehaps it's time to read up on message filtering using procmail, formail, and friends. Regards, -a
Re: 69/8...this sucks
In addition, sometimes the problem is that my user just needs to put the crack pipe down. I just don't feel comfortable with this last one anymore, though. I can't be sure it's the crack. It could be the IPs. How do I know? I'm not a major router admin. I manage a couple dozen /24's and the supporting gear, but... It seems one purpose (perhaps remote) of bogon filters is security. Why not get someone like CERT to broadcast changes in allocations? I'd bet a cup of Dunkin' Donuts coffee that the news would quickly get to the right people. My $two_cents for very large values of $two_cents. (back to my hole) -ed - [EMAIL PROTECTED]
Re: 69/8...this sucks
According to ARIN's whois server, there are 95 subdelegations for NET-69-0-0-0-0...we're the 95th. Clearly this problem is going to get a lot worse before it gets better. And since most network operators are not on NANOG or USENET or any other mailing list, there are really only two means of contact. Either every affected party probes the net, identifies misconfigured networks and contacts them one by one using email, phone and letters. Or we use the press to make the problem and solution widely visible. In either case, I think it would be a mistake to just fix the immediate problem of a few ISPs needed full reachability from 69/8 space. Since we have to put the effort into this problem, let's try to fix the general problem, not just a small part of it. The general problem is that ever large numbers of devices are getting IPv4 address ranges hard-coded into their configurations with no process in place for reviewing and changing those configurations. These devices are not just routers but also firewalls and application servers. In order to solve the general problem we need to make it easy for people to review and change their configurations. This is not a lot different from the problems that DNS solved. When you configure a device with a domain name, the device will dynamically review and update the IP address that it uses for communication. No human intervention is necessary. Essentially, what we need is something that provides a capability similar to DNS except that it works for IP address ranges, not for individual IP addresses. This is where ARIN comes in. Because ARIN has the top-level authority for IP address ranges in North America, they are the *ONLY* organization that can authoritatively identify who an IP address range is delegated to. I have suggested that ARIN should set up an LDAP server to publish the delegation of all their IP address space updated on a daily basis. And that organizations which sub-delegate space, i.e. ISPs, should also run LDAP servers as part of a delegation hierarchy similar to DNS. This type of referral LDAP is part of the IETF standard and has been implemented by most LDAP software vendors. Because LDAP is a widespread technology that is used in the enterprise for identification and authentication, there is a high likelihood that the suppliers of firewalls and application servers will build in support for querying the ARIN delegation hierarchy. I realize ARIN can't guarantee global routability of IP space, but should they continue to give out IP blocks they absolutely know are not fully routable on the internet today? ISPs make addresses routable. ARIN is not an ISP. ARIN members are ISPs. ARIN does not compete with its members. Therefore, ARIN should focus on the problem of how to publish authoritative data about which IP addresses should be routable. The appropriate technology combined with the appropriate publicity will create demand from enterprise network admins which will drive all ISPs and device vendors to fix the problem. If anyone wants to discuss this further, then I suggest that the upcoming ARIN meeting in Memphis is the ideal venue to do so. --Michael Dillon
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..
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
On Fri, 2003-03-07 at 23:15, Jack Bates wrote: In defense of ARIN, the ice on a net block has to be broken at some point. They could wait 3 years and notify every list every hour of every day for those 3 years and there would still be many networks filtering those networks. The only way to catch it is to notice the block and make contact with the network. In many cases, personal contact is necessary as emails are often misunderstood or ignored. I repeat my suggestion that a number of DNS root-servers or gtld-servers be renumbered into 69/8 space. If the DNS breaks for these neglected networks, I suspect they will quickly get enough clue to fix their ACLs. Add Eddy's suggestion that the addresses all end in .0 or .255 and you have a fine machine for cleaning up a few old, irritating problems. -- Jeff S Wheeler [EMAIL PROTECTED]
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
On 10 Mar 2003, Jeff S Wheeler wrote: I repeat my suggestion that a number of DNS root-servers or gtld-servers be renumbered into 69/8 space. If the DNS breaks for these neglected networks, I suspect they will quickly get enough clue to fix their ACLs. Moving a number of them won't do anything. Broken networks would just use the ones they can reach. Moving the root-servers isn't a good option anyway since lots of Bind setups are distributed with a . hints file containing A records for the root-servers, and these hints files are updated probably less frequently than bogon filters. Since the root-servers have been reduced to refering queries to the gtld-servers and nstld servers and perhaps others, these latter servers would be the ones to move that would cause no pain for networks that work, and immediate notification and motivation to fix filters for networks with outdated filters. I don't suppose there's even a slim chance of this happening? -- 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
JSW Date: 10 Mar 2003 15:23:52 -0500 JSW From: Jeff S Wheeler JSW I repeat my suggestion that a number of DNS root-servers or JSW gtld-servers be renumbered into 69/8 space. If the DNS JSW breaks for these neglected networks, I suspect they will JSW quickly get enough clue to fix their ACLs. JSW JSW Add Eddy's suggestion that the addresses all end in .0 or JSW .255 and you have a fine machine for cleaning up a few old, JSW irritating problems. I suggest a rotation like so: Jan-Apr: 69.w.w.0 Apr-Jul: 69.x.x.255 Jul-Oct: 70.y.y.0 Oct-Jan: 70.z.z.255 where the middle two octets are predetermined ahead of time. IIRC, some RFC recommends updating the root zone cache monthly... following this would ensure one had proper root/gTLD addresses. The above also would break DNS for broken networks for a two month stretch... long enough to flush out bad rules. 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
SJW Date: Mon, 10 Mar 2003 20:35:51 + (GMT) SJW From: Stephen J. Wilcox SJW Nice idea in principal (from a purist point of view) but its No? SJW not practical, I hope your not serious..! I am. 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
On Mon, Mar 10, 2003 at 08:49:04PM +, E.B. Dreger wrote: JSW Date: 10 Mar 2003 15:23:52 -0500 JSW From: Jeff S Wheeler JSW I repeat my suggestion that a number of DNS root-servers or JSW gtld-servers be renumbered into 69/8 space. If the DNS JSW breaks for these neglected networks, I suspect they will JSW quickly get enough clue to fix their ACLs. JSW JSW Add Eddy's suggestion that the addresses all end in .0 or JSW .255 and you have a fine machine for cleaning up a few old, JSW irritating problems. I suggest a rotation like so: Jan-Apr: 69.w.w.0 Apr-Jul: 69.x.x.255 Jul-Oct: 70.y.y.0 Oct-Jan: 70.z.z.255 where the middle two octets are predetermined ahead of time. IIRC, some RFC recommends updating the root zone cache monthly... following this would ensure one had proper root/gTLD addresses. The above also would break DNS for broken networks for a two month stretch... long enough to flush out bad rules. You want to move things like gtld servers, yahoo/google (and other 'important' things), including things like oscar.toc.aol.com into these. This will leave the clueless to buy a clue and stimulate the economy ;-) - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
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
From EB Dreger I suggest a rotation like so: Jan-Apr: 69.w.w.0 Apr-Jul: 69.x.x.255 Jul-Oct: 70.y.y.0 Oct-Jan: 70.z.z.255 where the middle two octets are predetermined ahead of time. IIRC, some RFC recommends updating the root zone cache monthly... following this would ensure one had proper root/gTLD addresses. The above also would break DNS for broken networks for a two month stretch... long enough to flush out bad rules. Eddy Okay, let's assume that we all agree to this.. Who are the players? ARIN, gTLD Owners, and who else? Let's get some emails fired off.. Who is going to ARIN in Memphis? Jack? Dr Race? Volunteers to broach this? Any gTLD owners on list? Let's go for it.. I think this is a great Idea... Maybe we need to look at applying this elsewhere J
Re: 69/8...this sucks
On Mon, 10 Mar 2003, E.B. Dreger wrote: JSW Date: 10 Mar 2003 15:23:52 -0500 JSW From: Jeff S Wheeler JSW I repeat my suggestion that a number of DNS root-servers or JSW gtld-servers be renumbered into 69/8 space. If the DNS JSW breaks for these neglected networks, I suspect they will JSW quickly get enough clue to fix their ACLs. JSW JSW Add Eddy's suggestion that the addresses all end in .0 or JSW .255 and you have a fine machine for cleaning up a few old, JSW irritating problems. I suggest a rotation like so: Jan-Apr: 69.w.w.0 Apr-Jul: 69.x.x.255 Jul-Oct: 70.y.y.0 Oct-Jan: 70.z.z.255 This wouldn't actually accomplish what you're trying to do. The resolvers that couldn't reach those root and/or TLD servers that are behind the 'broken' networks would simply shift their traffic to the ones that they could reach. The only thing you'd accomplish by this is an increased load on the root/TLD servers that are in their normal locations. Doug -- If it's moving, encrypt it. If it's not moving, encrypt it till it moves, then encrypt it some more.
RE: 69/8...this sucks
IIRC, some RFC recommends updating the root zone cache monthly... following this would ensure one had proper root/gTLD addresses. The above also would break DNS for broken networks for a two month stretch... long enough to flush out bad rules. You want to move things like gtld servers, yahoo/google (and other 'important' things), including things like oscar.toc.aol.com into these. This will leave the clueless to buy a clue and stimulate the economy ;-) - jared Hey if it will be a great Stimulas package I bet we could get congressional research funding to try it. ;) J
Re: 69/8...this sucks
On Mon, 10 Mar 2003 16:00:01 EST, McBurnett, Jim said: This will leave the clueless to buy a clue and stimulate the economy ;-) Hey if it will be a great Stimulas package I bet we could get congressional research funding to try it. ;) Note the obvious bootstrapping problem with most Congresscritters :) pgp0.pgp Description: PGP signature
Re: 69/8...this sucks
DB Date: Mon, 10 Mar 2003 13:00:15 -0800 (PST) DB From: Doug Barton DB This wouldn't actually accomplish what you're trying to do. No? DB The resolvers that couldn't reach those root and/or TLD DB servers that are behind the 'broken' networks would simply DB shift their traffic to the ones that they could reach. The And which would those reachable ones be? DB only thing you'd accomplish by this is an increased load DB on the root/TLD servers that are in their normal locations. A: 69.0.1.255 B: 69.22.233.255 C: 69.87.152.255 : : : M: 69.255.254.255 The suggestion is to move ALL root, and as many TLD as possible, servers into the new space. Nobody has said move one or two, which indeed would be ineffective. 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
Stephen J. Wilcox wrote: I repeat my suggestion that a number of DNS root-servers or gtld-servers be renumbered into 69/8 space. If the DNS breaks for these neglected networks, I suspect they will quickly get enough clue to fix their ACLs. Nice idea in principal (from a purist point of view) but its not practical, I hope your not serious..! How about making *temporary* allocations to content providers who vounteer to move some/all content to net-69? Use an initial page on your regular net to alert users to contact their ISP and have them fix their bogon filter if the below link doesn't work. If done right, it might speed up the clean-up. The only problem would be finding volunteers with sufficient traffic who are willing to break their site. I could do this on some of my sites. They're not Ebay, but they do get hit from about 40K unique IP's per day, with a very global distribution. If ARIN is interested, contact me privately. KL
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
