RE: Get as much IP space as you ever dreamed of, was: Re: Looking to buy IPv4 addresses from class C swamp
Better yet... Have then redistribute to Rob via a private AS and an access-list that could be pushed out via TACACS etc.. HMM Thoughts anyone? Jim
-----Original Message----- From: Jack Bates [mailto:jbates@brightok.net] Sent: Monday, April 28, 2003 6:33 PM To: McBurnett, Jim Cc: Stephen Sprunk; Daniel Golding; Kai Schlichting; North American Noise and Off-topic Gripes Subject: Re: Get as much IP space as you ever dreamed of, was: Re: Looking to buy IPv4 addresses from class C swamp
McBurnett, Jim wrote:
Better IDEA: Rob can you add them to the BOGON Filters?
What a wakeup call that would be.... Maybe...
Actually, that would be something to push. Get companies that don't route their addresses publicly to declare it and work with Rob to make sure they are on the BOGON list.
-Jack
McBurnett, Jim wrote:
Better yet... Have then redistribute to Rob via a private AS and an access-list that could be pushed out via TACACS etc..
I like all of Rob's current methods just fine. I think he just needs to be informed by companies of what ISN'T routable. Of course, such things could also be placed as non-routable networks in the routing registries as well. My trust there is limited, though. Rob, on the other hand, has gained a lot of trust in maintaining a highly accurate list. -Jack
Hi, Jack. ] Rob, on the other hand, has gained a lot of trust in maintaining ] a highly accurate list. Thanks very much. :) I can't accept all the credit though. My thanks go out to all the members of Team Cymru. <http://www.cymru.com/About/teamcymru.html> Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
On Mon, 28 Apr 2003, Rob Thomas wrote:
] Rob, on the other hand, has gained a lot of trust in maintaining ] a highly accurate list. Thanks very much. :) I can't accept all the credit though. My thanks go out to all the members of Team Cymru.
Unfortunately, no good deed goes unpunished. Jon Postel did a great job maintaining the list of IP addresses. Paul Vixie did a great job with the first Real-Time Blackhole List. But people move on, and things change. But my real question is why are negative bogon lists necessary? If you ask providers, they all say they implement positive prefix list filters on all their customers. So who is injecting the bogons? And why do they still have a network connection? Should we be spending time teaching people how to do positive prefix filters, or trying to explain to them why the negative prefix filter the last network administrator installed 2 years ago is out of date. What is the cross-over point? When does the number of lines in a bogon list become larger than the positive prefix filter? If you are going to list every sub-allocation which isn't routed, why not just list the allocations which should be routed?
Hey, Sean. ] But people move on, and things change. That is exactly why I formed a team of folks. If I move on, which is very unlikely, then someone else takes it on. Reliance on a single person, no matter how well intentioned, isn't wise. I agree that positive prefix filters are a better idea. Unfortunately there isn't much I can do about that beyond rave. :) I try to catch such things as they occur, but it is really up to each network to do that work. The filters I have come across aren't always consistently applied, are not always well maintained, etc. Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
On 29 Apr 2003 1:15 (UT), Sean Donelan <sean@donelan.com> wrote: | If you ask providers, they all say they implement positive prefix | list filters on all their customers. That isn't my (recent) experience at all. Quite the reverse, in fact! -- Richard Cox (in the "real" Cymru)
Hi, all. ] | If you ask providers, they all say they implement positive prefix ] | list filters on all their customers. ] ] That isn't my (recent) experience at all. Quite the reverse, in fact! Agreed. When I was working for a hosting provider, the filters were inconsistently applied even within the disparate pipes purchased from the same provider. It really depended entirely on the ISP engineer who configured the link. This was the case with multiple providers. ] (in the "real" Cymru) I hope to visit again soon. :) Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
On Mon, 28 Apr 2003, Rob Thomas wrote:
] | If you ask providers, they all say they implement positive prefix ] | list filters on all their customers. ] ] That isn't my (recent) experience at all. Quite the reverse, in fact!
Agreed. When I was working for a hosting provider, the filters were inconsistently applied even within the disparate pipes purchased from the same provider. It really depended entirely on the ISP engineer who configured the link. This was the case with multiple providers.
Why do we expect the same ISP engineers to be better at configuring negative lists or keeping them up to date? According to Craig Labovitz's study published at Microsoft http://www.research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2... 100% of the ISP's surveyed filter inbound customer route announcements.
On Mon, 28 Apr 2003, Rob Thomas wrote:
] | If you ask providers, they all say they implement positive prefix ] | list filters on all their customers. ] ] That isn't my (recent) experience at all. Quite the reverse, in fact!
Agreed. When I was working for a hosting provider, the filters were inconsistently applied even within the disparate pipes purchased from the same provider. It really depended entirely on the ISP engineer who configured the link. This was the case with multiple providers.
Why do we expect the same ISP engineers to be better at configuring negative lists or keeping them up to date?
According to Craig Labovitz's study published at Microsoft http://www.research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2... 100% of the ISP's surveyed filter inbound customer route announcements.
Ahhh, but that was not the correct question to ask (I have not read the study). It is not whether ISP's filter inbound customer route announcements. It is how they filter them. If the customer goes and says I am going to announce 4.0.0.0/8 and the ISP just blindly adds that to the filter, we have a problem, but the ISP did answer that question truthfully. They are filtering. jon
Ahhh, but that was not the correct question to ask (I have not read the study). It is not whether ISP's filter inbound customer route announcements. It is how they filter them. If the customer goes and says I am going to announce 4.0.0.0/8 and the ISP just blindly adds that to the filter, we have a problem, but the ISP did answer that question truthfully. They are filtering.
That's one important question, but another other question is, are _ALL_ customers prefix filtered? How about major peers? Sure, the default, new, small customer is prefix filtered. In 2000 -- the same year that study was done -- we were adding prefixes so quickly that iHug unfiltered us, and EPOCH unfiltered iHug, to prevent the need for us to notify them of every single route change. At any one time we only had around 150 prefixes maximum - there's just a lot of 203.* space which goes back and forward between ISPs in Australia resulting in a lot of filter updates. _After_ our circuit had been disconnected from iHug, for a brief period long before 66.0.0.0/8 was allocated, I tested pushing the /8 to their BGP peer we had in the US (multihop BGP as it was a satellite service). In theory: 0. Our BGP session should have been shut down anyway, when our satellite service was cancelled 1. Bogon filtering would catch it 2. Anyone using RADB would catch it 3. It wouldn't get far as no major network would pick it up The result - all test sites I tried either saw the route, or default routed to someone who saw the route. Here's an example of the non-optimal route taken from one site, but the fact is it still made it to hop #16, after which it would have gone to us if our satellite PVC was still active, and just from this example AARNet, Optus, UUnet, BBN, EPOCH, Netgate and iHug all in some way would reach that clearly bogus advertisement. Which says to me that at least in 2000, the big guys weren't even applying simple bogon filters on routes received between each other. typhaon; traceroute 66.0.0.1 traceroute to 66.0.0.1 (66.0.0.1), 30 hops max, 40 byte packets 1 muchacho.uwa.edu.au (130.95.128.128) 1.515 ms 0.88 ms 1.702 ms 2 parnet-uwa.parnet.edu.au (203.19.110.17) 2.848 ms 2.664 ms 2.353 ms 3 ATM9-0-0-2.ia5.optus.net.au (192.65.88.189) 57.681 ms 57.819 ms 59.205 ms 4 GigEth12-0-0.rr2.optus.net.au (202.139.191.22) 57.83 ms 57.787 ms 57.658 ms 5 POS5-0-0.la1.optus.net.au (192.65.89.214) 368.02 ms 367.933 ms 368.018 ms 6 34.ATM0-0-0.GW1.LAX4.ALTER.NET (157.130.227.181) 373.831 ms 373.879 ms 374.79 ms 7 121.ATM3-0.XR2.LAX4.ALTER.NET (146.188.248.110) 375.665 ms 374.306 ms 373.71 ms 8 193.at-1-1-0.TR1.LAX9.ALTER.NET (152.63.112.174) 373.284 ms 373.43 ms 372.938 ms 9 131.at-5-0-0.TR1.DFW9.ALTER.NET (152.63.3.161) 408.254 ms 429.138 ms 404.189 ms 10 289.at-1-0-0.XR1.DFW9.ALTER.NET (152.63.98.29) 404.381 ms 407.777 ms 410.8 ms 11 185.ATM6-0.BR3.DFW9.ALTER.NET (152.63.100.169) 406.129 ms 404.228 ms 404.08 ms 12 137.39.93.10 (137.39.93.10) 433.381 ms 415.909 ms 413.664 ms 13 pos10-0-0.lax-c100.gw.epoch.net (155.229.123.125) 416.909 ms 414 ms 416.23 ms 14 pos4-1.pao-c000.gw.epoch.net (155.229.120.49) 414.646 ms 416.578 ms 414.258 ms 15 pos8-0-0.npa-m100.gw.epoch.net (155.229.57.74) 417.329 ms 421.818 ms 600.575 ms 16 tig-us-pas-1.ihug.net (207.214.25.225) 420.169 ms 417.283 ms 417.213 ms 17 202-49-88-201.ihug.net (202.49.88.201) 531.449 ms 532.27 ms 530.245 ms 18 atm-5-0-0-2-netgate-akl.ihug.net (202.49.88.42) 531.121 ms 531.005 ms 530.884 ms 19 a0-0-0-2.tkbr1.netgate.net.nz (202.37.246.121) 534.236 ms 532.467 ms 530.545 ms 20 s1-1-1.labr1.netgate.net.nz (202.37.245.170) 767.038 ms 734.685 ms 768.571 ms 21 s5-0-0.lsanca1-cr1.bbnplanet.net (4.24.24.17) 681.512 ms 733.892 ms 751.962 ms 22 p2-1.lsanca1-ba1.bbnplanet.net (4.24.4.5) 765.545 ms 755.466 ms 680.472 ms 23 p7-0.lsanca1-br1.bbnplanet.net (4.24.4.2) 679.542 ms 766.558 ms 752.332 ms 24 p2-0.lsanca1-br2.bbnplanet.net (4.24.4.14) 750.405 ms 680.72 ms 765.398 ms 25 p1-0.crtntx1-ba1.bbnplanet.net (4.24.6.78) 808.366 ms 792.82 ms 806.672 ms 26 p1-0.crtntx1-ba2.bbnplanet.net (4.24.4.242) 786.897 ms 790.172 ms 770.245 ms 27 4.24.147.38 (4.24.147.38) 781.226 ms 782.357 ms 785.577 ms 28 pos10-0-0.lax-c100.gw.epoch.net (155.229.123.125) 850.728 ms 782.862 ms 782.42 ms 29 pos4-1.pao-c000.gw.epoch.net (155.229.120.49) 788.301 ms 782.932 ms 786.786 ms 30 pos8-0-0.npa-m100.gw.epoch.net (155.229.57.74) 840.266 ms 841.006 ms 785.38 ms 2000 isn't very long ago. It would be interesting to see what a similar unallocated route leaked into a significant provider would achieve today. David.
babylon@egenius.org writes:
Why do we expect the same ISP engineers to be better at configuring negative lists or keeping them up to date?
According to Craig Labovitz's study published at Microsoft http://www.research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2... 100% of the ISP's surveyed filter inbound customer route announcements.
Ahhh, but that was not the correct question to ask (I have not read the study). It is not whether ISP's filter inbound customer route announcements. It is how they filter them. If the customer goes and says I am going to announce 4.0.0.0/8 and the ISP just blindly adds that to the filter, we have a problem, but the ISP did answer that question truthfully. They are filtering.
Many ISPs use AS path filters for customers with a large number of announcements. Some implement netblock filters that are not exact matches. Both of these are examples where the ISP would honestly say they filter but holes exist. -Hank
Hey, Sean. ] Why do we expect the same ISP engineers to be better at configuring ] negative lists or keeping them up to date? Excellent point. I don't. However, I can make some of it automatic, e.g. setup one (or two) BGP feeds and be done with it. That level of automation does make the negative filtering more likely to occur. The positive filtering, at least at the edge, is likely different for each customer. Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Sean Donelan wrote:
But my real question is why are negative bogon lists necessary? If you ask providers, they all say they implement positive prefix list filters on all their customers. So who is injecting the bogons? And why do they still have a network connection?
This is true. Case in point: During this last month, a large provider not only routed a /16 network for their customer, they also sent in radb templates on behalf of their customer. The customer is a known rogue AS, but they still exist. This wasn't the first network they stole. They are US based, yet the network was registered to a company over seas. Untold numbers of spam were sent from that network for the hours that it was up. I only escaped because the spammers used a single word in the helo/ehlo parameter without a period and my server are in strict RFC mode.
Should we be spending time teaching people how to do positive prefix filters, or trying to explain to them why the negative prefix filter the last network administrator installed 2 years ago is out of date.
Both. Knowledge is power. It is the only thing everyone can agree upon. We need to educate people. We need to stop being tolerant to servers, services and networks that are not RFC complaint. We need to teach people how to use their network. We need to inform people that there are communication channels on the Internet. Teach them about the various mailing lists and resources that they need. Open their eyes to the truth about the Internet and how fragile it truely is.
What is the cross-over point? When does the number of lines in a bogon list become larger than the positive prefix filter? If you are going to list every sub-allocation which isn't routed, why not just list the allocations which should be routed?
It's been tried. See the routing registries. Yet, what do you do when it's not used or unverified data? What's to keep someone from registering 9.5.0.0/16 in RADB and being considered "legitimate" even though the network belongs to IBM? There are networks that demand trust, and yet they are untrustworthy. Education is the key. -Jack
sean@donelan.com (Sean Donelan) writes:
Unfortunately, no good deed goes unpunished. Jon Postel did a great job maintaining the list of IP addresses. Paul Vixie did a great job with the first Real-Time Blackhole List. But people move on, and things change.
note that while i moved on, MAPS didn't change. in the early days, MAPS listed all unallocated /8's, and to this day, dave or margie has to go in and remove them from the database as they're handed out to various RIR's. i'm fairly sure that dave would agree to list other pirateable space if there was demand. the spammer trick of latching onto old/dead class B's has only become popular recently. (he's still dlr@bungi.com -- ask him.) the fun part is watching the bgp announce/withdraws in unallocated space. (no matter what microsoft may have learned from their survey, most isp's don't seem to care which prefixes their bgp-speaking customers advertise.) -- Paul Vixie
--On Tuesday, April 29, 2003 3:17 AM +0000 Paul Vixie <vixie@vix.com> wrote:
note that while i moved on, MAPS didn't change. in the early days, MAPS listed all unallocated /8's,
We still do.
and to this day, dave or margie has to go in and remove them from the database as they're handed out to various RIR's.
We also add them back if, as in a few recent cases, they revert back to Reserved or unallocated space. Normally the additions or deletions are done within a few minutes of the announcement to NANOG. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Margie Arbon Mail Abuse Prevention System, LLC margie@mail-abuse.org http://mail-abuse.org
On 29 Apr 2003, Paul Vixie wrote:
the fun part is watching the bgp announce/withdraws in unallocated space. (no matter what microsoft may have learned from their survey, most isp's don't seem to care which prefixes their bgp-speaking customers advertise.)
So which ISPs are confused? Bogon's don't spontaneously occur in BGP. Some ASN must originate them, and ASNs must pass them to other ASNs. BGP helpfully includes the ASNs in the path. What should be done about ASNs which repeatedly announce false or unauthorized routes?
On 4/29/2003 at 3:10 AM, Sean Donelan wrote on NANOG-L:
So which ISPs are confused? Bogon's don't spontaneously occur in BGP. Some ASN must originate them, and ASNs must pass them to other ASNs. BGP helpfully includes the ASNs in the path.
What should be done about ASNs which repeatedly announce false or unauthorized routes?
Like: AS 15188 (rogue) ? We call them "rogue AS's" around here - AS's that are not to be trusted under any circumstances, any routes announced from them should be blocked or dropped, and complaints about them should be sent to ALL AS upstreams of the 'rogue' at all times, unless the upstream itself is rogue (in which case complaints should also go to all non-rogue upstreams of the rogue upstream, you get the idea) And to live up to Joe Provo's "Kai's post is not fiction." comment, oh, more true words have not been spoken lately. Here you have it RED HOT, for everyone to see, *in your face* : I received 2 blank emails to stolen ARIN POCs a few minutes ago, presumably to scan if they are valid: a more primitive method (and one that sets off alarm bells) than required to establish (in-)validity of registered contacts for ARIN objects: Received: from setsllg (mx110.freshnewideas.net [144.128.130.110]) by speedus.com (8.9.3p2/8.9.3) with SMTP id LAA23999 for <STOLEN_POC_FOR_AS15349>; Tue, 29 Apr 2003 11:44:53 -0400 (EDT) Received-Date: Tue, 29 Apr 2003 11:44:55 -0400 (EDT) From: Stacie <Beulafxv@24hr-savings.com> To: <STOLEN_POC_FOR_AS15349> Subject: Date: Tue, 29 Apr 2003 10:46:08 -0400 Content-Type: text/plain Received: from olfrrtg (mx219.freshnewideas.net [144.128.130.219]) by conti.nu (8.9.3p2/8.9.3) with SMTP id LAA05363 for <STOLEN_POC_FOR_KHS-ARIN>; Tue, 29 Apr 2003 11:56:53 -0400 (EDT) Received-Date: Tue, 29 Apr 2003 11:56:53 -0400 (EDT) X-Mailer-RCPT-To: <STOLEN_POC_FOR_KHS-ARIN> From: Contessa <Carinaobn@24hr-savings.com> To: <STOLEN_POC_FOR_KHS-ARIN> Subject: Date: Tue, 29 Apr 2003 10:58:03 -0400 Content-Type: text/plain And this is coming from: CIDR: 144.128.0.0/16 NameServer: NS1.DSI-NET.NET NameServer: NS2.DSI-NET.NET RegDate: 1990-12-13 Updated: 2003-04-27 Freshly updated (2 days ago). And the domain: Domain name: DSI-NET.NET Registrar of Record: TUCOWS, INC. Record last updated on 19-Apr-2003. Record expires on 19-Apr-2004. Record Created on 19-Apr-2003. Brand-spanking new, days before. And Tucows: again and again and again and again (insiders will know what I mean). Announcing AS is AS 15188: Routes transiting through or originating from AS 15188 : 128.13.0.0/24 from AS: 15188 (upstreams: 12124) 128.13.1.0/24 from AS: 15188 (upstreams: 12124) 128.13.64.0/20 from AS: 15188 (upstreams: 12124) 128.13.96.0/19 from AS: 15188 (upstreams: 12124) 144.128.64.0/20 from AS: 15188 (upstreams: 12124) 144.128.128.0/19 from AS: 15188 (upstreams: 12124) Woah. that's *TWO* stolen/hijacked /16's now. Sole upstream: thorn.net (AS 12124) - courtesy CC:'d here, so that noone can say later "you didn't tell them". http://www.ris.ripe.net shows (using RRC00): - space in 144.128.0.0/16 first announced on: 2003-04-27 - no routes from AS 15188 from 2003-01-04 until 2003-04-22, when they started announcing out of 128.13.0.0/16 An unused AS that suddenly springs to life? Suspicion: AS is hijacked. ASNumber: 15188 ASName: DIALI-INTERNETWORK-01 ASHandle: AS15188 Comment: RegDate: 2000-03-31 Updated: 2000-03-31 TechHandle: BL374-ARIN This handle however: RegDate: 2000-03-31 Updated: 2003-04-21 Phone: +1-212-284-0189 (Office) Email: bob_lowry@ureach.com Updated the day before, and the email is a drop-box at an email/communications solutions provider, the phone number is an 'all circuits busy' (fast busy). A courtesy copy is going to abuse@ureach.com here. Too bad ARIN's 'historic' records are not open for public inspection. A search for "ureach.com +abuse" on Google Groups results in 1,850 hits. Certainly a popular "destination" for people wanting a "front" to hide behind. We are giving this 9 out of 10 votes for "hijacked AS with no credibility". But hey, we got more! A quick Google search for historic records of 128.13.0.0/16 (the SECOND stolen/hijacked /16 this AS is announcing) turns up: http://www.geocities.com/alias_faq/whois.htm : NetHandle: NET-128-13-0-0-1 Parent: NET-128-0-0-0-0 NetType: Direct Assignment NameServer: NIC.DSI.NET NameServer: NOC.DSI.NET Comment: RegDate: 1983-02-24 Updated: 1992-07-17 DSI.net seems to have had new owners for quite a while, but this fits the scheme of using "similarly named" entities pretending to be the original entity owning the ARIN object(s). However, that record also shows: TechHandle: SM73-ARIN TechName: Miller, Steve TechPhone: +1-617-873-3427 TechEmail: twb_help@bbn.com And SM73-ARIN is now, you guessed it: the POC for both CIDR: 128.13.0.0/16 RegDate: 1983-02-24 Updated: 2003-04-20 and CIDR: 144.128.0.0/16 RegDate: 1990-12-13 Updated: 2003-04-27 With the SM73-ARIN handle now being: Name: Miller, Steve Handle: SM73-ARIN Company: Address: 30 west 32nd st City: New York StateProv: NY PostalCode: 10016 Country: US Comment: RegDate: 1992-05-14 Updated: 2003-04-19 Phone: +1-212-431-4321 (Office) Email: hostmaster@dsi-net.net bbn.com (Genuity) most certainly wants to find out who twb_help@bbn.com was going to in recent times. That phone number (212-431-4321) sure looks bogus as well, and the fact that it's ring-no-answer in the middle of the business day in New York certainly shows that it's not an "Office" number. A quick Google search turns up the phone number as the fax number of mouse.org, the "NYC Schools Volunteer Organizaton". Everything covered? That leaves a few more suspects: any and all domain names that follow have been registered in the last few days: freshnewideas.net aka digitalstore-network.net with nameservers in the stolen/hijacked space: NS1.DIGITALSTORE-NETWORK.NET 128.13.0.90 NS2.DIGITALSTORE-NETWORK.NET 128.13.0.92 And that is: Rita Lee Marketing Inc 901 Parkview Drive King of Prussia, PA 19406 Lee, Rita funnelcake@rock.com Lee, Rita gallopinto@rock.com 781.394.5655 (and remember, if it's "optin" by name, you can *really trust them* !) Courtesy copy to rock.com (free email), to see if they really want to be implicated in a hijacked/stolen network case. And the two domains: well, HELLO WORLD! Nice to see you! (reg'd 2/7 days ago) And always and again, the favorite registrar of IP space hijackers: Tucows. Domain name: FRESHNEWIDEAS.NET Registrar of Record: TUCOWS, INC. Record last updated on 26-Apr-2003. Record expires on 26-Apr-2004. Record Created on 26-Apr-2003. Domain name: DIGITALSTORE-NETWORK.NET Registrar of Record: TUCOWS, INC. Record last updated on 25-Apr-2003. Record expires on 21-Apr-2004. Record Created on 21-Apr-2003. And now a little rDNS-scanning: 144.128.129.1 mx1.freshgoods-2urdoorstep.com through 144.128.129.254 mx254.freshgoods-2urdoorstep.com Domain name: FRESHGOODS-2URDOORSTEP.COM Registrar of Record: TUCOWS, INC. Record last updated on 26-Apr-2003. Record expires on 26-Apr-2004. Record Created on 26-Apr-2003. And: 144.128.130.1 mx1.freshnewideas.net through 144.128.130.254 mx254.freshnewideas.net And: 144.128.131.1 mx1.hightech-goods.com through 144.128.131.254 mx254.hightech-goods.com Domain name: HIGHTECH-GOODS.COM Registrar of Record: TUCOWS, INC. Record last updated on 26-Apr-2003. Record expires on 26-Apr-2004. Record Created on 26-Apr-2003. 144.128.65.2 server2.digital-superstore.net Domain name: DIGITAL-SUPERSTORE.NET Registrar of Record: TUCOWS, INC. Record last updated on 25-Apr-2003. Record expires on 21-Apr-2004. Record Created on 21-Apr-2003. And now for the 128.13.0.0/16 space: 128.13.0.1 router.dsi-net.net 128.13.0.2 one.dsi-net.net 128.13.0.3 ns1.infinite-hosting.net 128.13.0.4 dnscache.dsi-net.net 128.13.0.5 mail.dsi-net.net 128.13.0.6 ns2.infinite-hosting.net Domain name: INFINITE-HOSTING.NET Hartford, Harry admin@infinite-hosting.com 732 Marysville Dr. Jersey City, NJ 07305 US 201-239-6725 Registrar of Record: TUCOWS, INC. Record last updated on 19-Apr-2003. Record expires on 19-Apr-2004. Record Created on 19-Apr-2003. "Infinite", eh? Yeah, with 2 /16's under the belt, it certainly feels that way - until sometime later this afternoon, I am sure! 128.13.0.30 ns1.hosted-here.com 128.13.0.32 ns2.hosted-here.com Domain name: HOSTED-HERE.COM Gee, there's Lee, Rita funnelcake@rock.com again! Registrar of Record: TUCOWS, INC. Record last updated on 25-Apr-2003. Record expires on 25-Apr-2004. Record Created on 25-Apr-2003. There's certainly a party here: 128.13.64.128 mail.infinite-hosting.net 128.13.64.130 mail.hosted-here.com 128.13.64.132 mail.digital-superstore.net 128.13.64.134 mail.digitalstore-network.net And a 2 very lonely hosts: 128.13.96.7 server1.digital-superstore.net 128.13.126.7 test1.digital-superstore.net Last but not least: the domain used for the From: address of the probing mails: 24hr-savings.com Domain name: 24HR-SAVINGS.COM Registrar of Record: TUCOWS, INC. Record last updated on 10-Apr-2003. Record expires on 10-Apr-2004. Record Created on 10-Apr-2003. NS1.INFINITE-HOSTING.COM 144.2.0.101 NS2.INFINITE-HOSTING.COM 144.2.0.102 Henderson, Dave contact@ultimate-savings.com Ultimate Savings 1321 Mill Creek Drive Cincinnati, OH 45221 513-261-1254 This is a bogus address, as far as Mapquest.com and Mapsonus.com are concerned. This is one very big forged-identity, throwaway-domains fest here. AS 15188 routes off into Null0 ....
On Tue, 29 Apr 2003 kai@pac-rim.net wrote:
On 4/29/2003 at 3:10 AM, Sean Donelan wrote on NANOG-L:
So which ISPs are confused? Bogon's don't spontaneously occur in BGP. Some ASN must originate them, and ASNs must pass them to other ASNs. BGP helpfully includes the ASNs in the path.
What should be done about ASNs which repeatedly announce false or unauthorized routes?
Like: AS 15188 (rogue) ?
It appears this AS is on the tail of 7018 10910 12124 15188 701 10910 12124 15188 AT&T (7018) InterNAP (10910) Thorn.net (12124) UUNET (701) Who isn't filtering?
Sean Donelan wrote:
It appears this AS is on the tail of
7018 10910 12124 15188 701 10910 12124 15188
AT&T (7018) InterNAP (10910) Thorn.net (12124) UUNET (701)
Who isn't filtering?
InterNAP. They are large enough that their transits usually don't filter them, yet they have had several problems in the past with their customers and not validating the information they've been given. It's even possible that InterNAP is filtering but took Thorn's word for it. I'm unfamiliar with 12124's history. -Jack
On Tue, Apr 29, 2003 at 05:04:28PM -0500, Jack Bates wrote:
InterNAP. They are large enough that their transits usually don't filter them, yet they have had several problems in the past with their customers and not validating the information they've been given. It's even possible that InterNAP is filtering but took Thorn's word for it. I'm unfamiliar with 12124's history.
Inap is filtered by almost every one of their transits, both manually and with IRR entries. In fact, cleaning up all the IRR entry mess created by proxy registered routes from inap and their transits can be a full time job. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Back in the day when we had InterNAP transit, I can attest that they were filtered at _least_ by prefix, by mostly all of the folks who they acquired transit from. On Tue, 29 Apr 2003, Richard A Steenbergen wrote:
On Tue, Apr 29, 2003 at 05:04:28PM -0500, Jack Bates wrote:
InterNAP. They are large enough that their transits usually don't filter them, yet they have had several problems in the past with their customers and not validating the information they've been given. It's even possible that InterNAP is filtering but took Thorn's word for it. I'm unfamiliar with 12124's history.
Inap is filtered by almost every one of their transits, both manually and with IRR entries. In fact, cleaning up all the IRR entry mess created by proxy registered routes from inap and their transits can be a full time job.
-- Alex Rubenstein, AR97, K2AHR, alex@nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
On Wed, 30 Apr 2003, Alex Rubenstein wrote:
Back in the day when we had InterNAP transit, I can attest that they were filtered at _least_ by prefix, by mostly all of the folks who they acquired transit from.
(I'm about to step into a big hole... but really I'm asking a question, not being mean) That may be true, but what does a provider do when they are presented with written 'authority to use address space' from a customer? Certianly if the customer provides 'proper' documentation that the ip space is available for them to route, and that they have authority from the 'owner' to do this... what is an ISP to do? Aside from route the blocks?
On Tue, 29 Apr 2003, Richard A Steenbergen wrote:
On Tue, Apr 29, 2003 at 05:04:28PM -0500, Jack Bates wrote:
InterNAP. They are large enough that their transits usually don't filter them, yet they have had several problems in the past with their customers and not validating the information they've been given. It's even possible that InterNAP is filtering but took Thorn's word for it. I'm unfamiliar with 12124's history.
Inap is filtered by almost every one of their transits, both manually and with IRR entries. In fact, cleaning up all the IRR entry mess created by proxy registered routes from inap and their transits can be a full time job.
-- Alex Rubenstein, AR97, K2AHR, alex@nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
--- "Christopher L. Morrow" <chris@UU.NET> wrote:
That may be true, but what does a provider do when they are presented with written 'authority to use address space' from a customer? Certianly if the customer provides 'proper' documentation that the ip space is available for them to route, and that they have authority from the 'owner' to do this... what is an ISP to do? Aside from route the blocks?
When I worked for $LARGE_ISP and regularly updated prefix-lists for BGP customers, I remember that we would give smaller customers a harder time about having permission to route new netblocks than we gave big ones: the assumption was that the bug customers would be ISPs, and could be providing backup transit or some such, while small customers were assumed to be enterprises which would only route their own space. ===== David Barak -fully RFC 1925 compliant- __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
In the immortal words of kai@pac-rim.net (kai@pac-rim.net):
However, that record also shows: TechHandle: SM73-ARIN TechName: Miller, Steve TechPhone: +1-617-873-3427 TechEmail: twb_help@bbn.com
Whoa. That one sorta jumped out at me. Steve Miller was BBN/BBNplanet's NOC manager, circa 1987-1994, and my boss during my time at BBN. Last I heard, he was happily employed at WebTV, so I strongly suspect that this is not him. :)
bbn.com (Genuity) most certainly wants to find out who twb_help@bbn.com was going to in recent times.
I think that the bbn.com domain is currently under the control of Verizon, not Genuity/Level3. The domain, along with most of the divisions housed at 10 Moulton Street (Hark, etc) became part of the "BBN Labs" entity which is a wholly owned subsidiary of GTE-now-Verizon. -n -------------------------------------------------------------<memory@blank.org> "Would I have invented PCR if I hadn't taken LSD? I seriously doubt it." (--Dr. Kary Mullis, Nobel Prize winning inventor of Polymerase Chain Reaction) <http://blank.org/memory/>-----------------------------------------------------
TechPhone: +1-617-873-3427 TechEmail: twb_help@bbn.com
twb_help@bbn.com shades of the past... :) Terrestrial Wideband network anyone? 28.0.0.0/8 documented in IEN-162 - October 1980 clarified in IEN-165, January 1981 interesting reading, as is IEN-159, "Notes on the "Worm" Programs - Some Early Experience with a Distributed Computation" --bill
...
Three such trunks, terminated at sites where Arpanet and Wideband Network nodes are physically collocated, were established during the first week of May, 1988: BBN to ISI, DCEC to ISI and DCEC to SRI. The intervening weeks have been spent tuning their performance.
Things were more interesting then.
On Mon, 28 Apr 2003, Sean Donelan wrote:
On Mon, 28 Apr 2003, Rob Thomas wrote:
] Rob, on the other hand, has gained a lot of trust in maintaining ] a highly accurate list. Thanks very much. :) I can't accept all the credit though. My thanks go out to all the members of Team Cymru.
Unfortunately, no good deed goes unpunished. Jon Postel did a great job maintaining the list of IP addresses. Paul Vixie did a great job with the first Real-Time Blackhole List. But people move on, and things change.
But my real question is why are negative bogon lists necessary? If you ask providers, they all say they implement positive prefix list filters on all their customers. So who is injecting the bogons? And why do they still have a network connection?
Should we be spending time teaching people how to do positive prefix filters, or trying to explain to them why the negative prefix filter the last network administrator installed 2 years ago is out of date.
What is the cross-over point? When does the number of lines in a bogon list become larger than the positive prefix filter? If you are going to list every sub-allocation which isn't routed, why not just list the allocations which should be routed?
Alternatively monitor the BGP table and pull out the bogons then produce a list of them along with AS path info, possibly sending out to the list to the upstreams as well as nanog. Steve
Hi, all. Sorry for my tardy response. I'm starting a new job today, so things are hectic. :) ] Better yet... Have then redistribute to Rob ] via a private AS and an access-list that could be pushed out via TACACS etc.. Can do. ] Actually, that would be something to push. Get companies that don't ] route their addresses publicly to declare it and work with Rob to make ] sure they are on the BOGON list. I'm happy to work with anyone who would like to have this done. We would need to ensure that the data is good and the source credible, but I'm happy to accomodate. Alternately I can make available route servers specifically for this purpose. I would also love to announce, with a different community, the unallocated space within the allocations of each RIR. That would be updated rather more frequently, and folks could decide if it is something they would want. FYI, I will be adding two more bogon route-servers very soon. This will make the configuration more reliable. Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
participants (19)
-
Alex Rubenstein -
babylon＠egenius.org -
bmanning＠karoshi.com -
Christopher L. Morrow -
David Barak -
David Luyer -
Eric Brunner-Williams in Portland Maine -
Henry Kilmer -
Jack Bates -
kai＠pac-rim.net -
Margie -
McBurnett, Jim -
Nathan J. Mehl -
Paul Vixie -
Richard A Steenbergen -
Richard Cox -
Rob Thomas -
Sean Donelan -
Stephen J. Wilcox