September 2002 - Test - lists.nanog.org

Re: Wireless insecurity at NANOG meetings
by Steven M. Bellovin 23 Sep '02

23 Sep '02

In message <Pine.GSO.4.40.0209221641250.23761-100000(a)clifden.donelan.com>, Sean Donelan writes: > >On Sun, 22 Sep 2002, Randy Bush wrote: >> - the users need to be told how to operate more safely, use >> end-to-end authentication and privacy, etc. it's a matter of >> education. and the education will stand them in good stead >> when they use 802.11 at starbucks, airports, etc. we do this >> at ietf, but it is not allowed at nanog. > >Sunday afternoon is full of tutorials on lots of different subjects. >Has anyone volunteed to conduct a Sunday tutorial on wireless security >for users of "public" wireless networks? > >Although I think it is a mistake to think a wireless network security >is different than using any other network you don't control. Most >wireless security tutorials tend to concentrate on "securing" the >wireless network instead of how to communicate over an untrusted >network. > Precisely -- and it's precisely why I'm not a big fan of "wireless security" as a discipline: my threat model for the wired network has never been any different than for wireless... --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book)

1 0

Re: Wireless insecurity at NANOG meetings
by Steven M. Bellovin 23 Sep '02

23 Sep '02

In message <Pine.GSO.4.40.0209211957580.21971-100000(a)clifden.donelan.com>, Sean Donelan writes: > >On Sat, 21 Sep 2002, Martin J. Levy wrote: >> >I agre security is sadly lacking, but it is probably impossible to >> >implement in a conference environment. >> >> Look this is a very simple issue. Sean's first post really pointed out >> that it's "bad form" for a set of operators to run an insecure network. >> I would believe that it's "good form" to at least try. It was stated >> that the network was not run by the "operators". OK, I accept that, but >> it's run by people with great (actually fantastic) connections to real >> operators (ie: us). > >I feel like a Rorschach Test. > >Is the Nanog confernce network really insecure for its purpose? > This is the real question -- what are you trying to protect? Apart from its (many) other problems, WEP is useful for protecting a single hop at layer 2. It does not protect against attacks at higher layers. (That's true of virtually all security mechanisms, I might add -- and I say "virtually" because I don't really trust my reasoning at at an hour when I really should be asleep, but I think that "all" is correct.) Apart from the problem of attacks from the Internet -- surely we don't want NANOG to run a firewall for us -- there are easy attacks that can bypass WEP. For example, someone could use ARP-spoofing to launch an active attack on even non-sensitive Web traffic. Btw -- that has happened on the wireless network at at least two conferences I've been to in the last few years. And no, these weren't black hat or grey hat conferences. If it weren't for the cryptanalytic attack on RC4 -- the one attack on WEP that wasn't foreseeable -- and if it had been done properly in other respects (i.e, if it had per-user keying, key management, and no "IV" collisions), WEP could provide access control. We could even imagine an AES-based WEP with key management, etc. -- and *all* it would buy us is access control. Is that worth it for NANOG? Again, what are you trying to protect? Is access to the conference net a resource that needs to be protected? Maybe it is, if you're concerned about drive-by spammers. But there's another resource, and that's the reputation of NANOG, or at least of its members, as folk who know how to run a network. Wide-open 802.11 networks are often a bad idea, precisely because access is a resource that needs to be protected. Beyond that, there's sometimes a "good neighbor" issue -- you don't want to accidentally attract folks who want to be on some local net of their own. Maybe a closed net is reasonable for that purpose -- but that's about it. If you want to protect yourself, make sure that your software is fully patched, you expose as few services as possible to the outside, and that you don't send anything unencrypted if it's at all sensitive if intercepted or modified. Beyond that, make sure that you're lucky, because new holes can be found at any time. Note, btw, that I didn't say "do that at conferences", or "do that for 802.11 hosts".... --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book)

1 0

Re: [nanog]software routers
by Vadim Antonov 22 Sep '02

22 Sep '02

On Sun, 22 Sep 2002, Koji Hino wrote: > From: Vadim Antonov <avg(a)exigengroup.com> > Date: Sat, 21 Sep 2002 03:06:56 -0700 (PDT) > :> The CPUs are quite faster nowadays, and you can get things like _quad_ > :> 300MHz PPC core on an FPGA plus 20+ 3.2Gbps serdes I/Os - all on one chip. > :> So building multigigabit software router is a no-brainer. > > Usual PCs don't have such fancy hardware... They have quite fancier stuff inside, actually, from a technology point of view. Your run-of-the-mill Pentium IV requires a lot more advanced technology for design and manufacturing than the "platform FPGA" I referred to. The enormous design costs for those marvels of engineering are only bearable because of high volume. > If you call it software router, then all "network processor based > router" should also be called software router, right? "Software router" in my book is something which relies on programmable general-purpose devices for implementing packet routing functions. Network processors do not qualify (though they're nice, when they are actually available, which is not often - because chip vendors tend to drop niche products pronto when in a bind). One thing I learned well is to keep exotic stuff out of designs, because it never seems to be available w/o high-volume commitments, and even then tends to come a year later and full of "design features". --vadim

4 3

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

22 Sep '02

On Sunday, 2002-09-22 at 17:06 AST, Sean Donelan <sean(a)donelan.com> wrote: > Although I think it is a mistake to think a wireless network security > is different than using any other network you don't control. Most > wireless security tutorials tend to concentrate on "securing" the > wireless network instead of how to communicate over an untrusted > network. There is no way to make the NANOG wireless setup "trusted"; you'd be better off putting effort into securing communications on an untrusted net. Tony Rall

1 0

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

22 Sep '02

At 05:06 PM 9/22/2002 -0400, Sean Donelan wrote: >Has anyone volunteed to conduct a Sunday tutorial on wireless security >for users of "public" wireless networks? > >Although I think it is a mistake to think a wireless network security >is different than using any other network you don't control. In fact, why not make the tutorial oriented towards operators, and be one of designing and providing service for mobile users (no matter what media are used)? In reality, most or all of the "service" that results is run on the end-points, but ISPs can help greatly by providing documentation and, sometimes, software to support this. They also can learn what mechanisms provide real security and what mechanisms do not. 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 Dave Crocker 21 Sep '02

21 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