- NANOG - lists.nanog.org

Re: Using RPSL in real life with the IRR's
by Michael Shields 27 Jun '00

27 Jun '00

In article <200006261357.JAA17553(a)outtolunch.merit.edu>, <gerald(a)merit.edu> wrote: > relies on the user to put in a value. The software only checks to > dissallow dates in the future (much to the detriment of our friends > on the other side of the international date line). Since no time zone is specified, surely the only correct interpretation is that the datestamp is UTC. -- Shields.

1 0

Re: FW: public key service
by L. Sassaman 26 Jun '00

26 Jun '00

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > I'm willing to run one, or at the very least put up a site with > > information on them. If anyone is interested in discussing this feel > > free to email me off list. Any good resources for keyserver information? Would it be possible to take this thread to the keyserver-folks list? I'm not subscribed to NANOG anymore, and have to have these messages forwarded to me. Additionally, that list has a high Clue Quotent, and discussing the specifics of setting up a server and joining the keyserver network might be more productive there. __ L. Sassaman System Administrator | "Everything looks bad Technology Consultant | if you remember it." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Homer Simpson -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5V9PTPYrxsgmsCmoRAkhwAJ9fjdcKd6SaKfQDCdJ04RYVj1OSCgCfRpyr 3J4Mt9nKKeieqDgwbBFSkjo= =sUUd -----END PGP SIGNATURE-----

1 0

Re: public key service
by Joseph Birthisel 26 Jun '00

26 Jun '00

> One thing I would like to see is more ISPs running keyservers for the use > of their customers. A few of them do. Thre are other ways that companies > could provide services that involve keyserver access, but I can't go into > that here. > > I attended the Keyserver Managers Symposium in Holland last month. A lot > of great ideas were presented, and a lot of problems discussed. One thing > is clear, and that is that the current PGP keyserver network needs to be > redesigned if it is to scale to another order of magnitude as far as > capacity. I expect that we will see good things happen in this regard in > the next year or so. I'm willing to run one, or at the very least put up a site with information on them. If anyone is interested in discussing this feel free to email me off list. Any good resources for keyserver information? Joseph

1 0

Re: public key service
by L. Sassaman 26 Jun '00

26 Jun '00

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI, certserver.pgp.com, keys.pgp.com, keyserver.pgp.com, pgpkeys.mit.edu, and keys.nai.com are all the same server (208.228.228.80), listening on port 11371 (HTTP) and 389 (LDAP) and 689 (LDAPS). If one doesn't work, the rest of the above probably won't either. The server I tend to use in cases when keyserver.pgp.com is not functioning properly is horowitz.surfnet.nl:11371. It also listens to LDAP on 11370 and LDAPS on 11369. pgp.ai.mit.edu is BAL's server, home of the original PGP keyserver. It isn't as zippy as the other two, but has a decent uptime ratio. It only listens on 11371, and you can't do the advanced LDAP queries that you can do with the other servers. www.keyserver.net has a cool web interface for searching for keys, but it sometimes takes a little work to find a server that is up and responding in a timely fashion. This network group uses Highware's OpenKeyserver. There is no LDAP support. I don't use pgp.net, so I can't comment one way or another on that group of servers. I believe they are mainly using the older pksd software by Marc Horowitz. Theoretically, all the servers syncronize with each other and there is no difference in the data contained on them. However, the server that tends to have the most up to date data is keyserver.pgp.com. Second to that is horowitz.surfnet.nl. If you want more info on the keyserver network, you should check out the keyserver mailing list. There is subscription info at http://www.highware.com/main-oks.html (it's the list hosted at flame.org) - --Len. > > -----Original Message----- > > From: Valdis.Kletnieks(a)vt.edu [SMTP:Valdis.Kletnieks@vt.edu] > > Sent: Monday, June 26, 2000 1:25 PM > > To: Randy Bush > > Cc: nanog(a)nanog.org > > Subject: Re: public key service > > > > On Mon, 26 Jun 2000 11:25:43 PDT, Randy Bush <randy(a)psg.com> said: > > > > > > pgp public key service is becoming critical infrastructure. > > unfortunately, > > > 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 > > > <http://bs.mit.edu:8001/pks-toplev.html> > > > which used to work once upon a time. neither work for me. > > > > EXMH 2.1.2 and later shipped with http://keys.pgp.com:11371/pks/lookup > > as the URL to check by default. I would have put www.pgp.net as the > > server, > > but of the 5 servers I checked, 2 were net-unreachable and one tossed a > > 404. > > -- > > Valdis Kletnieks > > Operating Systems Analyst > > Virginia Tech > > > __ L. Sassaman System Administrator | "Everything looks bad Technology Consultant | if you remember it." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Homer Simpson -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5V8UKPYrxsgmsCmoRAu9gAKC2JKN6b1B+y2bsN813XJaFqP6UpwCdFrHb 7Fp3uDw+VgVdoSuiUwTQyww= =dDMM -----END PGP SIGNATURE-----

1 0

RE: public key service
by ktsolis＠mindspring.com 26 Jun '00

26 Jun '00

Fairly reliable key servers horowitz.surfnet.nl:11371 certserver.pgp.com pgp.ai.mit.edu:11371 Thanks to Len Sassaman at PGP for the heads-up. cheers, Kristen -----Original Message----- From: Robert M. Enger [SMTP:enger@seka.erols.net] Sent: Monday, June 26, 2000 12:14 PM To: Randy Bush; nanog(a)nanog.org Subject: Re: public key service Randy: I have been using: http://wwwkeys.us.pgp.net It does not seem to be as heavily loaded as many of the other servers. (This posting is now likely to destroy that advantage :-) Having said that, it still takes 10 seconds or more to get a response. It would be good to have a set of servers that had enough horsepower to return answers more promptly. Bob At 11:25 AM 6/26/00 -0700, Randy Bush wrote: >pgp public key service is becoming critical infrastructure. unfortunately, >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 > <http://bs.mit.edu:8001/pks-toplev.html> >which used to work once upon a time. neither work for me. > >what are people using? > >and, if no one else is succeeding, is it time for the isp community to field >a reliable service? > >randy

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. 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