June 2000 - Test - lists.nanog.org

NSI to make (simple) change to domain-change procedures effective 8Jul00.
by rdobbins＠netmore.net 01 Jul '00

01 Jul '00

It's better than nothing, I guess. Too bad they can't seem to get PGP working. http://www.securityfocus.com/templates/article.html?id=54 ----------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice

2 1

RE: PGP kerserver infrastructure
by Roeland M.J. Meyer 30 Jun '00

30 Jun '00

> From: Albert Levi: Thursday, June 29, 2000 7:35 PM > > "Roeland M.J. Meyer" wrote: > > > Most modern mailers support X.509 certs for encryption. PGP is > > considerd, by many, to be the older technology. Building PKI > > around X.509 is much easier and meets actual existing standards. > > Well, X.509 is as old as PGP (rf. PEM which was X.509 based). I agree > that X.509 based PKIs are easier to built, but easiness does not mean > usability. The trust structures embedded in X.509 certs are not > acceptable for a large number of PGP users. > > I think the large number of PGP users and the current grow rate > determine whether it is old or not. Maybe it is not the > "standard", but > that many PGP users could not be wrong ! It is not an issue of right/wrong. Rather, it is an issue of what is most usable to the most people. SSL certs are certainly more usable to many. PGP works with ancient CLI mailers and older GUI mailers. All modern GUI mailers support X.509 keys for message encryption and even let you use the same cert for SSL protected POP3. PGP, OTOH, only encrypts the message body, this is why it's popularity is reducing. In addition, even you agree that an X.509 PKI is easier to build. Maybe because of the reasons I give here.

6 12

PGP kerserver infrastructure
by Shawn McMahon 30 Jun '00

30 Jun '00

If you guys are serious about being the latest cast and crew to pursue this, here's a resource you might want to be aware of: http://www.imc.org/ietf-openpgp/ You also might want to look at this message from their mailing list archive: http://www.imc.org/ietf-openpgp/mail-archive/msg02132.html They have a pgp-directory mailing list, and all of this has been discussed before, so perhaps it can save you some research.

13 27

RE: Experience with Cybex
by James Smith 30 Jun '00

30 Jun '00

Oops, social faux pas! :) Here are my finds: Our criteria are the following: - A KVM switch system. - Must support PCs, SUNs, and any serial devices. (We have several Cisco's and APC's) - Must be expandable to large number of devices, for investment protection. (We have 17 devices to start off with, and who knows where we'll end up in the future.) - Must support multiple users. I started looking at Cybex, since we have a little 4 port Cybex already. The 4040 model looked like it would suit our needs. We need 6 PC connections with PS/2, 3 Sun connections with video, and 8 serial connections (2 Suns, 4 Ciscos and 2 APCs). Since there are 17 devices, we needed two of the 4040 models, with a communications card in between. Then, with some help from this list, I identified other competitors. I looked at Rose Electronics (www.rosel.com) Their stuff looked good, but I couldn't find anything on support for serial devices. I didn't look at them further after that. I also looked at Apex (www.apex.com) but again I didn't see anything for serial support. (Besides, their press releases said something about just finishing a merger with Cybex.) Raritan has a similar offering to Cybex, with their MX4. We priced out a similar configuration and the price of the Raritan was the same as the Cybex. (About $12,000 CDN). The deciding factor was that since we are expanding, and most of our new systems are Suns and Ciscos with serial ports, we chose the Cybex. -- James Smith, CCNA Chief Network/System Administrator DXSTORM.COM http://www.dxstorm.com/ DXSTORM Inc. 2395 Speakman Drive, Suite 2200 Mississauga, ON, L5K 1B3 CANADA Tel: 905-822-1957 (email preferred) Fax: 905-822-0680 1-877-DXSTORM (1-877-397-8676) "Feeling 'connected' with carbon-based dolts holds all the joy of being handcuffed to a dead zebra - it sounds special, but it can get old fast." - The Dilbert Principle - Engineers, Scientists, Programmers and Other Odd People On Fri, 30 Jun 2000, Jamie Rishaw wrote: > Usually in situations like this when you solicit replies privately from a > list, you post your findings/reply summary to the list. :) > > I'm interested in what you found out. > > -jamie > > > | -----Original Message----- > | From: James Smith [mailto:jsmith@dxstorm.com] > | Sent: Thursday, June 29, 2000 10:20 PM > | To: 'nanog(a)merit.edu' > | Subject: Re: Experience with Cybex > | > | > | > | Thank you everyone for all the responses about the Cybex > | products! :) It > | been a lot of help in justifying the purchase. > | > | > | -- > | James Smith, CCNA > | Chief Network/System Administrator > | DXSTORM.COM > | > | http://www.dxstorm.com/ > | > | DXSTORM Inc. > | 2395 Speakman Drive, Suite 2200 > | Mississauga, ON, L5K 1B3 CANADA > | Tel: 905-822-1957 (email preferred) > | Fax: 905-822-0680 > | 1-877-DXSTORM (1-877-397-8676) > | > | "Feeling 'connected' with carbon-based dolts holds all the > | joy of being > | handcuffed to a dead zebra - it sounds special, but it can get old > | fast." > | > | - The Dilbert Principle > | - Engineers, Scientists, Programmers and Other Odd People > | > | > | On Wed, 28 Jun 2000, James Smith wrote: > | > | > > | > I'm look at purchasing a Cybex KVM switch system (XP4040) and was > | > wondering if anyone had any good or bad experiences to > | share, or opinions > | > about other similar products. Is Cybex widely used in NOCs? > | > > | > > | > -- > | > James Smith, CCNA > | > Chief Network/System Administrator > | > DXSTORM.COM > | > > | > http://www.dxstorm.com/ > | > > | > DXSTORM Inc. > | > 2395 Speakman Drive, Suite 2200 > | > Mississauga, ON, L5K 1B3 CANADA > | > Tel: 905-822-1957 (email preferred) > | > Fax: 905-822-0680 > | > 1-877-DXSTORM (1-877-397-8676) > | > > | > "Feeling 'connected' with carbon-based dolts holds all the > | joy of being > | > handcuffed to a dead zebra - it sounds special, but it can get old > | > fast." > | > > | > - The Dilbert Principle > | > - Engineers, Scientists, Programmers and Other Odd People > | > > | > > | > > | > > | > | >

1 0

The Cidr Report
by Tony Bates 30 Jun '00

30 Jun '00

This is an auto-generated mail on Fri Jun 30 12:00:00 PDT 2000 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 30Jun00 0) General Status Table History ------------- Date Prefixes 230600 80236 240600 80187 250600 80366 260600 80526 270600 80814 280600 80884 290600 80973 300600 80928 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 65.56.64.0/21 from AS2941 AS Summary ---------- Number of ASes in routing system: 7777 Number of ASes announcing only one prefix: 4376 (2400 cidr, 1976 classful) Largest number of cidr routes: 964 announced by AS701 Largest number of classful routes: 1070 announced by AS701 1) Gains by aggregating at the origin AS level --- 30Jun00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 436 149 287 65.8% BCnet Backbone AS1221 645 445 200 31.0% TELSTRA-AS AS7046 534 360 174 32.6% COQUI-NET PRTC Internet AS9269 183 55 128 69.9% Hong Kong CTI AS9706 152 26 126 82.9% Pusan Metropolitan City Office of AS2609 127 12 115 90.6% EUnet-TN AS9304 122 18 104 85.2% Hutchcity AS7657 293 190 103 35.2% The Internet Group Limited AS7545 153 55 98 64.1% TPG Internet Pty Ltd AS6429 210 118 92 43.8% RDC-INTERNET AS174 563 471 92 16.3% Performance Systems International AS7496 127 42 85 66.9% Power Up AS4293 328 243 85 25.9% Internal ASN for C&W AS705 343 263 80 23.3% ALTERNET-AS AS701 1070 998 72 6.7% Alternet AS577 250 178 72 28.8% Bell Backbone AS724 229 158 71 31.0% DLA-ASNBLOCK-AS AS3908 274 205 69 25.2% Supernet, Inc. AS1727 152 83 69 45.4% MRMS-WEST AS9557 95 28 67 70.5% Pakistan Telecommunication Compan AS3602 304 245 59 19.4% Sprint Canada Inc. AS6595 108 50 58 53.7% DODDSEUR AS5106 88 30 58 65.9% AADS-COLUMBUS AS7568 81 24 57 70.4% C.S. Communications Co., Ltd. AS4740 331 275 56 16.9% Ozemail Pty Ltd (ASN-OZEMAIL) AS3749 112 56 56 50.0% TECNET AS7018 545 492 53 9.7% AT&T WorldNet Service Backbone AS1785 361 312 49 13.6% NYSERNet Backbone AS209 257 209 48 18.7% Qwest Communications AS14562 80 35 45 56.2% UNKNOWN For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: PGP kerserver infrastructure
by Randy Bush 30 Jun '00

30 Jun '00

> What we do have are UI problems for clients. There are some server > problems brought on by not really having much of a protocol to begin with. > There are some server problems that result from having a distributed service > with no tools or protocol to manage those relationships. it is the last one which brought me into this maze of twisty peop^h^h^assages. randy

1 0

RE: PGP kerserver infrastructure
by Eric M. Carroll 30 Jun '00

30 Jun '00

My answer was deliberately naive as Randy alluded to in a follow-up email. When you look at this issue, there are three competing subproblems: 1) How do I find the X server for domain Y that domain Y is running? 1A) How do I find the X server that proxies for domain Y (a subcase of 1) 2) How do I find user Z in domain Y when no server (proxy or native) is available? 3) How do I find user Z in a list of user registries? (and how do I find the definitive list of user registries?) To get a service that scales, you have to eventually get to (1). It is essential. We all agree on this: noone seriously suggests there should be one or a small number of http or email servers. As a network administrator, I (eventually) will want to run (or control the management of) the server, especially if it is critical enough. Clearly, problem (1) can and should use the DNS. And leverage the SRV records. It is the system that can be leveraged that will make the service scale. This implies, in some way, that the service uses user identifiers that are related to the domain name in some way (e.g. email address). One issue is that protocol developers often do not define the mechanism to relate service to DNS name in the protocol spec. People are left to develop it by consensus or not at all (e.g. www.domainname) To be effective, server software developers must implement it as the first action the server takes (although there may be others) so that scaling is gained by default if someone implements the option. Of course, this is necessary, but not sufficient to attracting a user base, to bootstrap the community and reach critical mass necessary to be viewed as a critical service. Thus, option 2 is necessary. A default, global context where I can register my service information on a per user basis (since I don't have a domain specific server in the early days by assumption). If you think of email, for example, we do that all the time too (hotmail, ldap, etc etc). So both solutions are necessary. Its just that new service deployment seems to ALWAYS start with option 2. Then, once you are big, it is a huge problem to change to option 1. In fact, what happens in the wild is option 2 is implemented, then people try to figure out how to instantiate a flat namespace across many user registries (where registration is at the discretion of the user, so there is NO obvious binding between user and registry - anyone ever try to actually find a user of MS Netmeeting?). If the PGP key servers implemented both option 1 and option 2 as a fall-back, then Randy could bang on the people whose keys are mission critical (and he can't get), and encourage them to register their own server. Otherwise, you live with the default. The risk with PGP key servers now appears to be that option 2 was selected, and in trying to scale the system, people are trying to grapple with instantiating a single flat registry instance structure (and operate it on the scale necessary to support per-user registration). Scaling a point user registry without hierarchy is no different than trying to scale a flat network addressing space (and we know how that worked out). If you have many flat user registries, then you have a whole other problem - how do I find user Z across many user-selected registries. And how to I find (and register) the canonical list of registries. That is in effect saying the key to look up user Z is flat - there is no hierarchy. My assertion is that such a system cannot scale anyway, so no point in trying to fix it. To speak to Randy's point - the server structure is different than the key relationships. I believe a PGP key is associated to an email address, right? If so, then what's wrong with first looking in the domain to find the keyserver, and walking up the domain tree? If nothing is found, *then* check the default (flat) user registry? (But I am not a PGP expert, so someone else pick this up if I am wrong). It gives the administrator of domain Y the option of scaling without the problem of figuring how to run a flat registry and restrict it to their community of user Zs and ensure everyone can find user Z in domain Y on server X (which really is not obvious at all). Using the DNS, of course, assumes the service has a server that has a port that can be mapped to srv records... (S/N check: This might be drifting from nanog...) Regards, Eric Carroll

2 1

RE: PGP kerserver infrastructure
by Randy Bush 30 Jun '00

30 Jun '00

> As far as DNSSEC, a trust model following the domain hierarchy is > currently being pushed did dnssec drop cross-auth? cross-auth specifically allows non-hierarchic trust which allows one to 'subvert' the hierarchic model. randy

1 0

Re: Internet Routing Problems
by Aleksi Suhonen 30 Jun '00

30 Jun '00

Randy Bush wrote: > this has been going on for many days. it would be helpful if the folk > making these continuing messes would clean them up so that it does not > prevent those of us who try to make only occasional messes from seeing > our errors (note the last line). This is in fact a prolonged distributed denial of service attack of sorts. > Reserved Network and Host Announcements > --------------------------------------- > 128.88.250.0/27 at Mae-East from BBN-Planet (AS1) ASPATH=1 5727 2915 151 IGP ... > ***** Too many entries. List Truncated! ***** -- Aleksi Suhonen Network Specialist Axu TM Oy http://www.axu.tm/

1 0

Experience with Cybex
by James Smith 30 Jun '00

30 Jun '00

I'm look at purchasing a Cybex KVM switch system (XP4040) and was wondering if anyone had any good or bad experiences to share, or opinions about other similar products. Is Cybex widely used in NOCs? -- James Smith, CCNA Chief Network/System Administrator DXSTORM.COM http://www.dxstorm.com/ DXSTORM Inc. 2395 Speakman Drive, Suite 2200 Mississauga, ON, L5K 1B3 CANADA Tel: 905-822-1957 (email preferred) Fax: 905-822-0680 1-877-DXSTORM (1-877-397-8676) "Feeling 'connected' with carbon-based dolts holds all the joy of being handcuffed to a dead zebra - it sounds special, but it can get old fast." - The Dilbert Principle - Engineers, Scientists, Programmers and Other Odd People

1 1