- Test - lists.nanog.org

Re: Wireless insecurity at NANOG meetings
by Dave Crocker 22 Sep '02

22 Sep '02

At 08:46 PM 9/21/2002 -0400, Sean Donelan wrote: >Is the Nanog confernce network really insecure for its purpose? ... >I don't see much of a need to rely on a volunteer network operator to >provide what I think is the appropriate level of security for my >communications. exactly. seems like the same situation as we have for walk-by hot-spot wireless nets. is anyone suggesting that they should have some special, local privacy mechanisms, rather than each user relying on providing their own, end-to-end mechanisms? >ICANN had armed guards at its meeting to keep the rif-raff out. In fact there was a public disclosure of a trivial circumvention of that mechanism. It was never clear what actual benefit the guards were supposed to provide, either. d/ ---------- Dave Crocker <mailto:dave@tribalwise.com> TribalWise, Inc. <http://www.tribalwise.com> tel +1.408.246.8253; fax +1.408.850.1850

1 0

Re: Wireless insecurity at NANOG meetings
by Tony Rall 21 Sep '02

21 Sep '02

On Saturday, 2002-09-21 at 17:46 AST, Sean Donelan <sean(a)donelan.com> wrote: > I'm waiting for one of the professional security consulting firms to issue > their weekly press release screaming "Network Operator Meeting Fails > Security Test." > > The wireless networks at NANOG meetings never follow what the security > professionals say are mandatory, essential security practices. The NANOG > wireless network doesn't use any authentication, enables broadcast SSID, > has a trivial to guess SSID, doesn't use WEP, doesn't have any perimeter > firewalls, etc, etc, etc. At the last NANOG meeting IIRC over 400 > stations were active on the network. > > Are network operators really that clueless about security, or perhaps we > need to step back and re-think. What are we really trying to protect? I don't have an issue with the meeting use of wireless. To me it is not much different from connecting my machine to the open Internet. My traffic is more sniffable, but I always consider that any Internet traffic is sniffable. There are only 2 exposures with the NANOG wireless setup - compared to using a wired NANOG connection: 1. The traffic is more easily sniffable, and it's sniffable by non-NANOG members (not to say that it wouldn't be hard for a nonmember to use one of NANOG's wired connections and not to say that NANOG members should be more trusted with my network traffic than nonmembers). 2. NANOG bandwidth can be more easily stolen. I protect my usage in 2 ways: a. Traffic that I might rather not be revealed (including all of my email) to sniffers is sent over an encrypted tunnel. b. I use a personal firewall on my machine (in paranoid mode) to provide some protection against the machine itself being attacked. So, someone can steal "NANOG" resources and could sniff my web browsing (for example). I am not concerned. (BTW, the use of an SSID without encryption is useless against an even slightly determined interloper.) Even if NANOG had a good system to provide WEP keys to registered users there isn't really anything to stop malicious folks from registering. Assume there is evil out there and act accordingly. Tony Rall

1 0

Re: Cogent service
by Vadim Antonov 21 Sep '02

21 Sep '02

On Fri, 20 Sep 2002, Joe Abley wrote: > On Fri, Sep 20, 2002 at 06:40:56PM -0700, Vadim Antonov wrote: > > This is all obvious stuff, of course. However, the derived rule of > thumb "long traceroute bad, short traceroute good" is the kind of > thing that can induce marketing people to require engineers to > deploy MPLS, and is hence Evil and Wrong, and Most Not Be Propagated > Without Extreme Caution. Feeding any information to clueless people should be done with Extreme Caution :) A fool with a little knowledge is a lot more dangerous than just a fool. How MPLS

1 0

Re: [nanog-offtopic] Re: Whitehouse Tackels Cybersecurity
by Nathan J. Mehl 21 Sep '02

21 Sep '02

In the immortal words of Gregory Hicks (ghicks(a)cadence.com) > There IS another list that goes to about the same group of people... > > NANOG-OT nanog-offtopic(a)lists.blank.org Indeed. It's rather underutilized these days -- there was a spasm of activity right after 9/11, when I created it -- but it's still there, and I should probably advertise it a bit more often. So, a friendly reminder: help keep NANOG's signal-to-noise ratio high! Please subscribe to nanog-offtopic(a)lists.blank.org, and migrate digressive conversations there. Only you can prevent nonoperational nattering, etc. To subscribe, send mail to nanog-offtopic-subscribe(a)lists.blank.org and reply to the confirm message it will generate. -n ------------------------------------------------------------<memory(a)blank.org> Transported to a surreal landscape, a young girl kills the first woman she meets and then teams up with three complete stangers to kill again. (-- TV listing for the movie, The Wizard of Oz, in the Marin Paper.) <http://blank.org/memory/>----------------------------------------------------

1 0

RE: Cogent service
by Matt Ryan 20 Sep '02

20 Sep '02

I corrected myself to note this figure was us not ns (but I don't see that post yet). When you say 1-2 ms added under load do you mean CPU load or circuit load? Remember anytime the router has to buffer packets you are going to see delay (unless you use a QoS mechanism - but that's a whole other thread). Your example appears to backup my post - when you go a long way around (despite the numbers of routers involved) it takes longer to get there than the short route, but this isn't the routers making it slow, its the distance. Matt. -----Original Message----- From: David Diaz [mailto:davediaz@smoton.net] Sent: 20 September 2002 18:35 To: Matt Ryan; William B. Norton; Ralph Doncaster; nanog(a)merit.edu Cc: ml(a)vayner.net Subject: RE: Cogent service I dont believe that number at all. Not to disagree with you at all Matt. But real world, it would depend on the design. If you are going router to router then it would be closer to accurate. I have seen 1-2ms added per router under load. That also might factor in a hop inside the room between 1 routers or another gear and a router. Coming in one card, having to do a lookup, going out another card to another box then out the layer 1 circuit to the next city. A VPN might not save this time though. But hubbing to a regional center, and then placing this traffic on an express circuit to the next regional city might save some of these ms. In other words LA to San Fran, an express fiber route to Chi, then out a peering connection. This would save 5-8ms compared to LA, San Fran, Portland, Salt Lake, Chi where at each hope 1-2 routers would insert themselves into the process. In my book, 5-8ms is not a real factor.... Dont get me started on speed of light on fiber... At 18:21 +0100 9/20/02, Matt Ryan wrote: >>The hop count question is interesting. Is the consensus that it's >>mostly a customer service issue, where latency isnt affected but >>customer perception is? Or is it a real latency issue as more >>routers take a few CPU cycles to make a routing decision. > >The routers these days make a forwarding decision in ~20 ns - its going to >take a few hops before this becomes significant. Speed of light on long >links is a couple of orders of magnitude more delay inducing. > > >Matt. > >--------------------------------------------------------------------------- --- >Live Life in Broadband >www.telewest.co.uk > > >The information transmitted is intended only for the person or >entity to which it is addressed and may contain confidential and/or >privileged material. >Statements and opinions expressed in this e-mail may not represent >those of the company. Any review, retransmission, dissemination or >other use of, or taking of any action in reliance upon, this >information by persons or entities other than the intended recipient >is prohibited. If you received this in error, please contact the >sender immediately and delete the material from any computer. > > >=========================================================================== === -- David Diaz dave(a)smoton.net [Email] pagedave(a)smoton.net [Pager] Smotons (Smart Photons) trump dumb photons ------------------------------------------------------------------------------ Live Life in Broadband www.telewest.co.uk The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. ==============================================================================

1 0

RE: Cogent service
by David Diaz 20 Sep '02

20 Sep '02

I dont believe that number at all. Not to disagree with you at all Matt. But real world, it would depend on the design. If you are going router to router then it would be closer to accurate. I have seen 1-2ms added per router under load. That also might factor in a hop inside the room between 1 routers or another gear and a router. Coming in one card, having to do a lookup, going out another card to another box then out the layer 1 circuit to the next city. A VPN might not save this time though. But hubbing to a regional center, and then placing this traffic on an express circuit to the next regional city might save some of these ms. In other words LA to San Fran, an express fiber route to Chi, then out a peering connection. This would save 5-8ms compared to LA, San Fran, Portland, Salt Lake, Chi where at each hope 1-2 routers would insert themselves into the process. In my book, 5-8ms is not a real factor.... Dont get me started on speed of light on fiber... At 18:21 +0100 9/20/02, Matt Ryan wrote: >>The hop count question is interesting. Is the consensus that it's >>mostly a customer service issue, where latency isnt affected but >>customer perception is? Or is it a real latency issue as more >>routers take a few CPU cycles to make a routing decision. > >The routers these days make a forwarding decision in ~20 ns - its going to >take a few hops before this becomes significant. Speed of light on long >links is a couple of orders of magnitude more delay inducing. > > >Matt. > >------------------------------------------------------------------------------ >Live Life in Broadband >www.telewest.co.uk > > >The information transmitted is intended only for the person or >entity to which it is addressed and may contain confidential and/or >privileged material. >Statements and opinions expressed in this e-mail may not represent >those of the company. Any review, retransmission, dissemination or >other use of, or taking of any action in reliance upon, this >information by persons or entities other than the intended recipient >is prohibited. If you received this in error, please contact the >sender immediately and delete the material from any computer. > > >============================================================================== -- David Diaz dave(a)smoton.net [Email] pagedave(a)smoton.net [Pager] Smotons (Smart Photons) trump dumb photons

1 0

Re: Whitehouse Tackels Cybersecurity
by Gregory Hicks 20 Sep '02

20 Sep '02

There IS another list that goes to about the same group of people... NANOG-OT nanog-offtopic(a)lists.blank.org Just a thought... Regards, Gregory Hicks > Date: Fri, 20 Sep 2002 14:39:08 +0200 > From: Brad Knowles <brad.knowles(a)skynet.be> > > At 8:05 AM -0400 2002/09/20, Susan Harris wrote: > > > Brad, this message contains no technical content. Please keep political > > commentary in private email. Refer to the NANOG list AUP: > > > > http://www.nanog.org/aup.html > > > > Upon your next AUP violation, we'll need to remove your posting priveleges > > from the list. > > > > Susan Harris, Ph.D. > > Merit Network/Univ. of Mich. > > If I'm going to get one of these messages every time I submit > something to the list, then you might as well go ahead and > unsubscribe me now. > > If the list isn't about discussion, and other people continue to > post on the same subjects but don't get treated the same way, then > you have some very serious personal issues that you need to resolve. > > -- > Brad Knowles, <brad.knowles(a)skynet.be> > > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." > -Benjamin Franklin, Historical Review of Pennsylvania. > > GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- > O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) > tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) ------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3400 San Jose, CA 95134 | Internet: ghicks(a)cadence.com "The trouble with doing anything right the first time is that nobody appreciates how difficult it was." When a team of dedicated individuals makes a commitment to act as one... the sky's the limit. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff You can have it done good, fast, or cheap -- pick any two.

1 0

Re: Whitehouse Tackels Cybersecurity
by Brad Knowles 20 Sep '02

20 Sep '02

At 8:05 AM -0400 2002/09/20, Susan Harris wrote: > Brad, this message contains no technical content. Please keep political > commentary in private email. Refer to the NANOG list AUP: > > http://www.nanog.org/aup.html > > Upon your next AUP violation, we'll need to remove your posting priveleges > from the list. > > Susan Harris, Ph.D. > Merit Network/Univ. of Mich. If I'm going to get one of these messages every time I submit something to the list, then you might as well go ahead and unsubscribe me now. If the list isn't about discussion, and other people continue to post on the same subjects but don't get treated the same way, then you have some very serious personal issues that you need to resolve. -- Brad Knowles, <brad.knowles(a)skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

1 0

The Cidr Report
by cidr-report＠potaroo.net 20 Sep '02

20 Sep '02

This report has been generated at Mon Sep 16 18:33:13 2002 AEST. The report analyses the BGP Routing Table of the Route-Views router and generates a report on aggregation potential within the table. Check http://bgp.potaroo.net/cidr for a current version of this report. Recent Table History Date Prefixes CIDR Agg 09-09-02 121168 88703 10-09-02 121129 88787 11-09-02 121290 88946 12-09-02 121145 87146 13-09-02 121338 87745 14-09-02 121318 87720 15-09-02 121238 87859 16-09-02 122134 87830 Possible Bogus Routes 39.0.0.0/8 AS4554 EP0-BLK-ASNBLOCK-4 Exchange Point Blocks AS Summary 13914 Number of ASes in routing system 5301 Number of ASes announcing only one prefix 1804 Largest number of prefixes announced by an AS AS209 : ASN-QWEST Qwest 73154816 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is not proposed across non-advertised address space ('holes'). --- 16Sep02 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 121976 88656 33320 27.3% All ASes AS209 1804 1042 762 42.2% ASN-QWEST Qwest AS3908 1133 650 483 42.6% SUPERNETASBLK SuperNet, Inc. AS2548 1581 1127 454 28.7% ICIX-MD-AS Business Internet, Inc. AS7132 601 183 418 69.6% SBIS-AS Southwestern Bell Internet Services AS701 1762 1351 411 23.3% ALTERNET-AS UUNET Technologies, Inc. AS7018 1349 959 390 28.9% ATT-INTERNET4 AT&T WorldNet Services AS1221 1301 939 362 27.8% ASN-TELSTRA Telstra Pty Ltd AS4323 645 307 338 52.4% TW-COMM Time Warner Communications, Inc. AS7046 607 312 295 48.6% UUNET-CUSTOMER UUNET Technologies, Inc. AS6197 383 97 286 74.7% BATI-ATL BellSouth Network Solutions, Inc AS852 737 456 281 38.1% ASN852 Telus Advanced Communications AS7843 664 386 278 41.9% ADELPHIA-AS Adelphia Corp. AS18566 270 4 266 98.5% COVAD Covad Communications AS4151 284 32 252 88.7% USDA-1 USDA AS1 682 449 233 34.2% GNTY-1 Genuity AS6347 396 180 216 54.5% DIAMOND SAVVIS Communications Corporation AS4814 233 34 199 85.4% CHINANET-BEIJING-AP China Telecom (Group)Beijing Telecom CompanyBeijing China AS690 519 326 193 37.2% NSFNET-T3-RT-AS Merit Network Inc. AS4355 360 170 190 52.8% ERMS-EARTHLNK EARTHLINK, INC AS1239 851 662 189 22.2% SprintLink Sprint AS2386 418 233 185 44.3% INS-AS AT&T Data Communications Services AS4134 302 118 184 60.9% ERX-CHINALINK Data Communications Bureau AS6595 244 74 170 69.7% DODDSEUR DoD Education Activity Network Assistance Center AS3356 392 226 166 42.3% LEVEL3 Level 3 Communications, LLC AS1791 186 23 163 87.6% SPRINTLINK3 Sprint Government Systems Division AS11371 169 7 162 95.9% UUNET-AS-11371 UUNET Technologies, Inc. AS376 341 184 157 46.0% RISQ-AS Reseau Interordinateurs Scientique Quebecois (RISQ) AS17676 220 65 155 70.5% GIGAINFRA APNIC ASN block AS6539 350 200 150 42.9% GROUPTLCOM GT Group Telecom Services Corp. AS577 424 275 149 35.1% BACOM Bell Advanced Communications Inc. Total 19208 11071 8137 42.4% Top 30 total Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)lists.apnic.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

Re: Cogent service
by Michael L. Barrow 20 Sep '02

20 Sep '02

> wouldn't affect anyone but us. They admitted we needed it and couldn't get > the affect any other way, but just couldn't do it. "That's not the product we > offer." Yeah -- those types of things suck, but from their perspective this kind of policy allows them to keep their service level consistent. One-offs can end up being expensive in the long run. "If I do it for you, everyone will want the same thing!" -- Michael L. Barrow E: michael(a)mlbarrow.com P: 805-566-0885

3 2