Archive for the ‘wireless’ Category

Yes, I have left Trapeze

Saturday, March 27th, 2010

To answer a common question in my inbox for the last week, yes, I have left Trapeze. I started at Aerohive Networks on Tuesday, March 23.

As predicted, 802.11 is really done

Friday, September 11th, 2009

Back in July, I wrote that the IEEE Standards Board would consider 802.11n for approval on September 11. That meeting has occurred, the votes have been taken, and the standard has been approved. I received notice by e-mail this morning at 11 am Pacific. I didn’t pick it up immediately, since I was in Australia for the Wireless World conference, and the e-mail came in just after 4 am.

TKIP security is not “Gone in 60 Seconds”

Friday, August 28th, 2009

On the train home last night, I read the paper by Ohigashi and Morii that made the news yesterday, and resulted in a good number of electrons being spilled yesterday afternoon.

Before I get started, the key point here is:

If you have concerns about wireless security, JUST USE CCMP.

(CCMP is often referred to as WPA2, but that’s a nomenclature point that I’d rather not get into here.)

I enjoyed reading the paper because the attack is clever, and nicely builds on some work from a year ago by Eric Tews and Martin Beck. Both the Ohigashi/Morii paper and the Tews/Beck paper describe attacks against the TKIP integrity check. Notably, neither attack is able to recover the keys used by TKIP to encrypt frames.

The most important thing to understand about TKIP is that it was intended to be an interim measure. When design work on TKIP started in 2001, there was a two-pronged approach to developing wireless security protocols. The first prong was updating the much-maligned WEP to improve security, but that effort was circumscribed because the design that emerged was constrained by the need to be hardware-compatible with the millions of devices which had already been sold with WEP support. (In technical terms, that restricted TKIP to be based on the RC4 cipher, and prevented development of a message integrity check with significant computational requirements.)

In essence, TKIP is a set of “seat belts” that keep the most vulnerable parts of WEP from being thrown through the windshield or impaled on the steering column. (One of my favorite papers about the weaknesses in WEP is IEEE 802.11 document 11-00/0362, titled Unsafe at Any Key Length, which is where the metaphor comes from.)

I’m not terribly surprised by the increasing number of papers written about flaws in TKIP. Given the severe design constraints, TKIP was a stopgap solution intended to buy time to give wireless LAN users the breathing space to move to the eventual AES-based protocol in development. TKIP had a “design lifetime” of five years, meaning that the intent was to resist cryptanalytic attacks for that length of time. The TKIP specification had matured by 2003, so it is not a surprise that flaws began to be identified last year.

Last year, the Tews/Beck paper exposed a subtle flaw in TKIP’s integrity checking. The attack described in last year’s paper required that a network have quality of service extensions enabled. Ohigashi and Morii did away with that constraint by showing that an attacker clever enough to insinuate himself into the conversation between the network and a client device can perform a similar attack.

The technical impact of this attack is small. Tews and Beck showed that a network with WMM could be subject to attacks against the TKIP integrity check. Ohigashi and Morii have generalized that work to networks in which the attacker does not need WMM to be enabled, but the trade is that the attacker must have a situation in which the victim is outside the range of the AP without relaying. Many vendors developed workarounds a year ago which continue to provide protection against this attack.

What this perceptive paper should do is heighten the disquiet regarding continued use of TKIP. Initial papers on WEP showed flaws that were not fatal, but the accretion of cryptanalytic expertise over time resulted in a complete break of the protocol which enables attackers to swiftly recover encryption keys. TKIP has not suffered this fate yet, but it is difficult to know how far off that day is. The best advice is to start using CCMP today, and make plans to move away from TKIP.

TKIP was intended for use as a stopgap, and it was optimized for use with the existing protocol features at the time of its design. It has not been extended to protect the extended headers defined by 802.11n, which is why the Wi-Fi Alliance has defined tests to prevent the use of TKIP with its 11n certification. It will never provide protection for 802.11 management frames. (To learn more about management frame protection, see the summary video for a talk I’ve submitted to the RSA conference next year.)

The future of wireless LAN security is CCMP. Let’s bury TKIP, and move away from it before it becomes absolutely necessary.

Stick a fork in 802.11n, it’s almost done!

Monday, July 20th, 2009

Last week, the IEEE 802.11 working group met in San Francisco. Activity on the long-awaited 802.11n standard has been slowly moving through the process for several meetings now. On Friday, we took what is likely to be the final step as the 802.11 working group. We held our final approval vote, requesting that higher layers of the IEEE 802 group approve 11n for publication.

The vote felt somewhat anti-climactic. In a lightly discussed and debated motion to send the 802.11n draft onward, 53 members (including your correspondent) voted in favor, 1 voted against , and 6 abstained.

Following the working group’s approval, the IEEE 802 executive committee voted unanimously (14 for, none against or abstaining) to send 802.11n to “RevCom,” the IEEE Standards Board Review Committee. The IEEE Standards Board next meets on September 11, 2009.

In an interesting twist, September 11 is a date relevant to the history of 802.11n. Bruce Kraemer, the long-time chair of Task Group N and the current chair of the 802.11 working group, noted that the first meeting of the “High Throughput Study Group,” the precursor to TGn, was September 11, 2002.

If approved, the 802.11n effort will have taken exactly seven years, at least by one measure. We are a long way from the first time 802.11n passed the 75% threshold.

The 802.11 working group is already working on the next step. Two task groups (TGac and TGad) are researching and debating methods to create gigabit-capable physical layers.

The Wi-Fi Summer 2008 meeting social

Friday, June 13th, 2008

Sven Mesecke arranged for his employer, Buffalo, to sponsor the social event. Sven showed up with his daughter Abby, proving that we start working on developing wireless engineers young!

Our even was held at Stubbs’s Bar-B-Q, and featured some of the live music that Austin is famous for. I haven’t gone to that many concerts, so it was a bit of an eye-opening experience to be in the room with the enthusiasm and energy of the bands. Young Abby introduced the first band of the night, The Ginn Sisters:

Following a break, Guy Forsyth took the stage. Due to the heat, I had to flee the crowded area downstairs for the relative cool of the less crowded upper floor:

Throughout the evening, people were playing pool. I’m sure that the pool table was attractive in part because it was located inside the air-conditioned area. Here’s Dave Stephenson preparing to break:

It was an awesome event. My only problem was that a meeting the next morning was of interest, and 8:30 am in Austin is 6:30 am for an out-of-state Californian. I had to leave before the second set was done just to get to bed at a reasonable hour.

The difficulties in building a conference wireless network, TERENA TNC edition

Monday, May 19th, 2008

It’s hard to build a conference wireless network. I’ve built a few over the past five years, and it is always a big engineering challenge. As you build the network, you refine your plans. When users arrive and start sending traffic, you refine your plans. As loads ebb and flow, you refine your plans. I won’t say it’s easy, but it is a well traveled path. Every major gathering of networkers requires wireless connectivity.

I’m accustomed to the user experience on wireless LANs built for industry trade groups like the Wi-Fi Alliance, the IEEE 802.11 working group, and the IETF. The Wi-Fi Alliance uses Michael Hijdra and his team at 2Fast4Wireless, and Verilan does work for both IEEE 802.11 and the IETF. This week, I’m speaking at the TERENA NetConnect conference. It’s only the first day, but I’ve had lots of trouble with the network.

First of all, the network uses web “authentication.” All of the conference attendees have been given a unique account, but the use of accounts is enforced by a captive web portal, not WPA. The Wi-Fi Alliance, IEEE 802, and the IETF all run an 802.1X network, though they also offer an option for unauthenticated access. It seems unfortunate to avoid using 802.1X at the TERENA TNC conference because TERENA’s Eduroam project has done a great deal to drive adoption of 802.1X, and many of the attendees are therefore familiar with 802.1X configuration.

When the plenary hall filled up, the performance went down very quickly. In the first eight minutes, I was disconnected four times. At eight minutes, the network connection gave up the ghost and quit working altogether. Before that point, I was seeing round-trip times that I hadn’t seen since the great AT&T frame relay outage of 1998, when round trips were measured in seconds from my then-office to, well, anywhere. Round trip times were also measured in second-plus range here, and are substantially higher even than the GPRS/EDGE network I use when commuting to work:

Reply from 4.2.2.1: bytes=32 time=2964ms TTL=246
Reply from 4.2.2.1: bytes=32 time=1050ms TTL=246
Reply from 4.2.2.1: bytes=32 time=1513ms TTL=246
Reply from 4.2.2.1: bytes=32 time=1464ms TTL=246
Reply from 4.2.2.1: bytes=32 time=3253ms TTL=246
Reply from 4.2.2.1: bytes=32 time=3448ms TTL=246
Reply from 4.2.2.1: bytes=32 time=753ms TTL=246
Reply from 4.2.2.1: bytes=32 time=1575ms TTL=246
Reply from 4.2.2.1: bytes=32 time=1469ms TTL=246
Reply from 4.2.2.1: bytes=32 time=228ms TTL=246
Reply from 4.2.2.1: bytes=32 time=1538ms TTL=246

(4.2.2.1 is one of my favorite test IP addresses. It’s short, quick, easy to type, and it belongs to a highly redundant DNS server so it is almost always there.)

In the plenary, I was sitting towards the back of the room. As it became clear that the network was failing, people closed up their laptops in frustration. In the afternoon session, an attempted demonstration was aborted due to network performance problems. In all of the rooms, Windows reports low signal strength, so some of the performance problems could be due to AP placement constraints.

Last but definitely not least, there are two network names in use. A sign posted at the plenary room indicates that the split is used for load balancing, and instructs us to use the appropriate one based on user name:

I have connected to both networks, and they appear to use the same DHCP server. This is probably a misguided attempt at broadcast containment and/or load balancing. The Wi-Fi/IEEE 802/IETF networks use a single SSID and let the infrastructure figure out load balancing in a way that is transparent to the users.

A pair of funny wireless network names

Monday, May 19th, 2008

I recently had a breakfast meeting in Daly City, and my host picked the location. We met at a restaurant that is right next to a residential area. I arrived first, and when I opened my laptop to start work, I saw several wireless networks available.

I chuckled slightly when I saw the following network name:

A few days later, I was visiting the dentist’s office. Upon opening up a Mac, I was greeted with the following message:

Ahem. Well, I guess it is a matter of trust…

Free Wi-Fi in airport lounges

Monday, May 12th, 2008

Danny McPherson has written about Wi-Fi access in the “refugee camp” that is the SFO Red Carpet Club.

Having independently discovered last week that Red Carpet Club members could now get Internet access for free via T-Mobile, I was eager to get online in an airport without having to drop another $9.95 to T-Mobile…

Although I’m an elite flyer on United, I am a more elite flyer with American. The Admirals Club (American’s counterpart to the Red Carpet Club) has promoted their Internet access much better. Members all received multiple mailings, and guests who buy a day pass get a card with a code on it.

American partnered with MobileStar for access in the Admirals Club in the late 1990s. Until this year, the network continued to operate only as a T-Mobile hotspot. Now, the T-Mobile hot spot operates in parallel with the captive portal for the Admirals Club. Like the Red Carpet Club, all you need is a magic membership number:

To login, all you need is the United Mileage Plus number of the primary Red Carpet Club account holder [Ed note: In the American Admirals Club, it's the AAdvantage number of the account holder]. Now, having long questioned the wisdom of a luggage tag that displays these numbers, be it a “hole-punched” Mileage Plus membership card, or a more obvious oval-shaped Red Carpet Club tag, I’m even more wary now…

Fortunately, the Admirals Club luggage tags don’t have AAdvantage numbers on them. They do have a bar code that I assume can be translated easily into an AAdvantage number by American employees. On the other hand, if somebody is in the club, you can look for a regular luggage tag. Even on the plane, I bet you could do worse than by looking for the right color luggage tag. I would be willing to bet that most people with black elite luggage tags (Executive Platinum) are also Admirals Club members, and the likelihood only increases if you find somebody with a million miler oval.

I’ve yet to explore how difficult it would be to exhaustive search for valid numbers, or if multiple logins are permitted at a given time, or how far outside of the Red Carpet Club these numbers are valid, or…

As to the last point, the numbers are almost certainly valid as long as you can get to an AP. Although it is possible to build a wireless network that attempts to determine location and restrict services to a certain geographic area, the cost is quite high.

My experience is that the signal goes quite a long distance. Even before I forked over the money for an Admirals Club membership, I used their networks frequently. As a non-member, I could almost always sit in a gate area near the entrance and use the network. (I am a long-time T-Mobile hot spot subscriber through my cell phone plan.) In Chicago, I would sit in the hallway joining the H and K concourses, which was especially nice because there were usually unoccupied power plugs. At Los Angeles, I could sit at gate 41 and get a weak signal.

In the past, I tested whether T-Mobile’s hot spot network would support multiple simultaneous logins, and it does not. I have not tested whether the same is true for the captive portal they run for the Admirals Club. I would be surprised if that were the case because club members are allowed to bring guests, and it is likely that travelers with the ability to pay for an airline club membership have friends and family members who also have their own devices.

My favorite 802.11n graph: draft size over time

Monday, April 21st, 2008

My reason for braving the “snowstorm” at Heathrow was to be at the JANET(UK) Networkshop conference. The organizers asked me to present an overview of current wireless standards in development. JANET(UK) is also a founding member of the OpenSEA Alliance, and has arranged for some UK universities to test the supplicant as we develop it.

I impressed (in the older sense of drafting somebody into service) Mark Tysom of JANET(UK) into taking pictures while I spoke. He captured me in front of my favorite slide in the talk, which shows the size of the 802.11n draft over time:

Several interesting vital statistics on the 802.11n draft can be found in this 802.11 working group presentation made by Bruce Kraemer, the long-time chair of TGn who has recently been elected the chair of the entire 802.11 working group.

The venue for my talk was the plenary session, which was held at The Barony Hall at the University of Strathclyde. The Barony Hall was previously a church, and is a wonderful venue for large audiences. As a speaker, it can be slightly intimidating, though!

(Thanks for taking photos, Mark!)

Wi-Fi Rail about to sign a deal with BART

Wednesday, April 9th, 2008

Via Glenn Fleishman, I found this Sacramento Bee article describing a imminent deal between BART and Wi-Fi rail. (I tried the Wi-Fi Rail service, but wasn’t impressed.)

The article has two points worth noting. First, the initial trial will expand from the four downtown San Francisco stations to the big underground areas:

If a deal is struck, Lee says WiFi Rail will install the system on BART’s most heavily traveled underground routes – in Oakland, San Francisco and the Transbay Tube – within 120 days. Coverage for BART’s entire 103-mile system would follow.

The underground core of the BART system runs from the four downtown SF stations, the Transbay Tube, and the Oakland Wye (roughly West Oakland north to 19th Street and west to Lake Merritt).

The article then quotes Wi-Fi Rail’s corporate counsel as adding 45 minutes to a workday:

“Take a BART rider who gets on at Walnut Creek and spends 45 minutes going to downtown San Francisco” and back, says [Gilles] Attia [Wi-Fi Rail's corporate lawyer]. By plugging in, “he’s added 1 1/2 hours to his work day.”

Mr. Attia works in Sacramento, so he may not have first-hand experience with BART. Assuming that I’ve got the bounds of the expanded Wi-Fi Rail deployment right, it’s not that big. Lake Merritt to Civic Center (on my commute) is 16 minutes. 19th Street/Oakland to Civic Center is 18 minutes. 19th Street/Oakland to Lake Merritt is only 5 minutes.

Since my initial report on the unreliability of Wi-Fi Rail a year ago, I haven’t found that the service in train cars has improved. Service is faster and more robust on the platform, but I still find the service on the train spotty.