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
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, 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.
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.
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.
That isn't my (recent) experience at all. Quite the reverse, in fact!
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
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.
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-2000-74
100% of the ISP's surveyed filter inbound customer route announcements.
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.
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.)
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.
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?
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
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)
Subject:
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>
Subject:
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 ....
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 15188AT&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
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.
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.