June 2000 - Test - lists.nanog.org

Re: public key service
by Randy Bush 26 Jun '00

26 Jun '00

> The boys at www.pgp.net try to keep on top of this and there should be a > link to a working key server on the front page. A network error ocurred. unable to connect to server The server may be down or unreachable. Try connecting again later. > Also www.keysever.net usually works, but it slow today infinitely slow *** localhost can't find www.keysever.net: Non-existent host/domain randy

3 3

Re: public key service
by Matt Braun 26 Jun '00

26 Jun '00

> i have been unable to get useful key lookup for a long time. i have been > trying > <http://pgpkeys.mit.edu/> > at jeff schiller's recommendation, and pgpkeys.mit.edu is really keys.pgp.com. The current MIT run server is pgp.mit.edu and it has been up and running for some time. Matt

1 0

Re: public key service
by Randy Bush 26 Jun '00

26 Jun '00

> The boys at www.pgp.net try to keep on top of this and there should be a > link to a working key server on the front page. Currently this I get: > http://www.uk.pgp.net/pgpnet/wwwkeys.html second time worked randy

1 0

Re: public key service
by Randy Bush 26 Jun '00

26 Jun '00

> wwwkeys.pgp.net seems to be fairly zippy for the last four months. A network error ocurred. unable to connect to server The server may be down or unreachable. Try connecting again later. second try got me a ftp directory listing randy

1 0

Using RPSL in real life with the IRR's
by Julian Eccli 26 Jun '00

26 Jun '00

I am in the process of setting up a peering session at the NASA MAE-WEST exchange on their NAP network and to do this I had to register and create my companies mainter objects, AS, and Policy info. I have read through RFC-2622 and RFC-2650 and find the RPSL language to be powerful, although a tad confusing at times. To help me understand and also ensure I am correct with my interpretation of RPSL I queried the whois.radb.net database and started to examine many of the large carriers objects. What I noticed is not a single one I have run across does more than implement a very basic import and export policy. Considering the posibilities of abuse and mistakes I would assume the larger/medium carriers would have someone dedicated full time to ensure the flood gates aren't open to their networks and their clients. My real question is: Can anyone point me to a policy(s) that use more than the general import/export policies such as import: from AS#### action pref=100; accept AS#### (or usually ANY) AND NOT {0.0.0.0/0}, etc, etc, etc. If I have interpreted RFC-2622 correctly for what the language can do it seems that many of the problems in the discussion 'using IRR tools for BGP route filtering' would be under much tighter policy control. Of course if the IRR databases were more up to date, many of the queries I made had dates that said they had not been changed since 1994. Regards, Julian

4 3

URGENT Need contact from GT-Hosting NOC
by Curtis Maurand 26 Jun '00

26 Jun '00

Hello, Our domain was hijacked over the weekend. We need a slave zone set up ASAP with GTE-Hosting so that we will not be invisible to the rest of the net. If someone from Network Operations @GTE-Hosting would call me we could arange this. I can be reached at (207)283-3627. Thanks in advance Curtis Maurand System Administrator lamere.net Business Center

2 1

[DNS walking]Re: using IRR tools for BGP route filtering
by Mufti Ahmed 26 Jun '00

26 Jun '00

Hi Dana when you talk about DNS walking is this similar to the concept of SNMP Walking? Mufti Nayeem Ahmed Network Systems Engineer Market Data Networks Reuters America Inc. (212)-603-3595 1-800-2REUTER To: Mark Borchers <markb(a)infi.net>, Mark Prior <mrp(a)connect.com.au> cc: nanog(a)merit.edu (bcc: Mufti Ahmed/NYC/US/Reuters) Subject: Re: using IRR tools for BGP route filtering I plan to write a WHOIS client for the RA in Perl as part of Net::Whois. I also plan to have a program that will walk the RA for a given AS (which is why I need the whois client). Eventually I also plan to add ARIN support to Net::Whois I'd like to see a DNS walk to compare the registry to what's out there. Not to mention finding all the bogus records that do things like list ENGLAND as a country code (instead of UK). ----- Original Message ----- From: "Mark Prior" <mrp(a)connect.com.au> To: "Mark Borchers" <markb(a)infi.net> Cc: <nanog(a)merit.edu> Sent: Sunday, June 25, 2000 3:05 AM Subject: Re: using IRR tools for BGP route filtering > > Are there any plans to correlate route registry objects against > address registry databases? > > I believe that one of the roots of this thread is the need to validate > the legitimacy of not only routes, but registered route objects. > Although it is too much to expect that route objects will match up > cleanly with address block assignments at the outset, performing > such a correlation would at least identify the scope of the problem. > > It's not all that simple to do, although certainly some of the trash > could be deleted, since it's not always the organisation "owning" the > address space that announces it. Some process that compares the IR > registry view to the current routing table view might be "better" but > who would take on that task and under what mandate as its one thing to > find the problems but it's an entirely different problem to actually > fix it? > > Mark. ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

1 0

Re: WHOIS source?
by Andrei Robachevsky 26 Jun '00

26 Jun '00

>Can someone point me to the source for a whois server... I don't know >why, but I haven't been able to find any sources.... You may want to look at the RIPE whois server at: ftp://ftp.ripe.net/ripe/dbase/software/ We are also working on new implementation of the server. Early beta releases are available at: ftp://ftp.ripe.net/ripe/dbase/reimp/ > >Thanks >-- >North Shore Technologies, Cleveland, OH >http://NorthShoreTechnologies.net >Steve Sobol, BOFH - President, Chief Website Architect and Janitor >Spammers and Net-abusers: Don't bother asking me for service. See >http://NorthShoreTechnologies.net/go/policy/ for more information. Regards, -- Andrei Robachevsky DB Group Manager RIPE NCC

1 0

virus spreader from ptt.ru
by Dana Hudes 25 Jun '00

25 Jun '00

Hello. A dialup user in ptt.ru is sending out mass mail with a virus attached; tonight was the second time in as many days. The ISP has been notified but has not responded. You may wish to black hole their dialup port range to protect your network's mail systems. Return-Path: <> Received: from mail1.panix.com (mail1.panix.com [166.84.0.212]) by harmony.hudes.org (8.9.3/8.9.3) with ESMTP id MAA01055 for <dhudes(a)hudes.org>; Sun, 25 Jun 2000 12:05:53 -0400 Received: by mail1.panix.com (Postfix) id 903E530F93; Sun, 25 Jun 2000 12:05:27 -0400 (EDT) Delivered-To: dhudes(a)panix.com Received: from dialup.ptt.ru (dialup.ptt.ru [195.34.0.100]) by mail1.panix.com (Postfix) with SMTP id 21A6730EC5 for <dhudes(a)panix.com>; Sun, 25 Jun 2000 12:05:07 -0400 (EDT) Received: (qmail 13626 invoked from network); 25 Jun 2000 15:37:06 -0000 Received: from dialup-27028.dialup.ptt.ru (HELO pink) (195.34.27.28) by dialup.ptt.ru with SMTP; 25 Jun 2000 15:37:06 -0000 To: web(a)download.ru From: Âàø(a)panix.com, çàêàç(a)panix.com Subject: Mission(download) Date: Sun, 25 Jun 2000 19:37:47 +0300 Message-Id: <36702.817908564815300.290@localhost> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=juhbchtmlnhbclru Status: --juhbchtmlnhbclru Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Âàø çàêàç îò DOWNLOAD.RU Http://www.download.ru Ñïàñèáî çà âàø âûáîð. --juhbchtmlnhbclru Content-Type: application/x-zip-compressed; name="Mission(download).zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Mission(download).zip" (Virus attachment deleted; if you really want it e-mail me a request) --juhbchtmlnhbclru-- inetnum: 195.34.0.0 - 195.34.0.127 netname: PTT-1 descr: PTT-Teleport Moscow, JSC descr: Russia, Moscow country: RU admin-c: SK6742-RIPE tech-c: AVM1-RIPE status: ASSIGNED PA changed: netmst(a)ptt.ru 20000323 source: RIPE route: 195.34.0.0/19 descr: PTTNET's first /19 block origin: AS6795 notify: netmst(a)ptt.ru mnt-by: PTTNET-RIPE-MNT changed: netmst(a)ptt.ru 19980206 source: RIPE

1 0

Re: using IRR tools for BGP route filtering
by Danny McPherson 25 Jun '00

25 Jun '00

> > I agree totally with prefix-list filtering customers and we have done so > from the very beginning. (Who wants to blemish the reputation of their > ASN as result of a customer being a bonehead and announcing default, etc?) > Provider<->Provider prefix-list filtering becomes much more involved > however. When a provider has 400+ bilateral peering relationships, the > time it takes to bring a new customer online who has their own address > space grows substantially. It is no different when a provider obtains > additional address space. If their peers are prefix-list filtering, they > have to contact every peer to have them blast a hole in the filters for > the new address block. If a provider performed prefix filtering on their peers, the policies would need to be auto-generated from some database, a la IRR or the like. This used to be a problem not long ago, when things such as sequenced prefix lists (with incremental update support), and BGP route refresh didn't exist. Today, however, they do. The problem is that the data in the IRRs is stale -- at best, the associated infrastructure isn't necessarily production quality, the routers can't store the policies, much less perform matches in a reasonable manner, and they certainly can't perform any type of forwarding plane functions such as SA verification. Of course, a bit of latency introduced would perhaps encourage correct aggregation and use of provider-allocated space, which, of course, is yet another rathole in and of itself. > In a perfect world, we would not need to filter, period. Filtering > customers has become necessary to survival. I see Provider<->Provider > filtering as a major hurdle to jump anytime your (or anyone elses) network > expands in relation to prefixes being legitimately announced. Though I'm certain you'll agree that hurdle isn't nearly as high as the one that providers must jump when another provider begins advertsing more-specifics of their customers address space. For example, I recall a provider announcing a /24 which contained www.cisco.com a few months back, and every peer gladly accepted the announcment .. including Cisco's service provider! As you can imagine, this caused a bit of a problem for a number of folks. Fortunately, Cisco doesn't rely wholly on web-generated revenue, as some folks do. The lobbying for this isn't simply because we think it's cool or that it would be trivial to accomplish .. it's because the lack of inter-provider filtering and SA verification mechanisms are by far one of the most vulnerable components of today's Internet. Support for these two components alone would clearly improve the Internet as a whole, significantly increasing reliability, while decreasing vulnerability to things such a DoS attacks. -danny

6 6