Networking: May 2008 Archives


May 27, 2008

I'm in Boston today for the IETF P2P Infrastructure workshop. Anyway, we land and as usual, as soon as we land they tell us that we're allowed to use our cell phones but other electronic devices have to stay off until they open the aircraft doors. So, wait a second. I can't use an iPod, but if it's an iPhone that's totally different and I can use it? Do cell phones emit some sort of protective radiation that I'm blissfully unaware of? Is it different between CDMA and GSM? If I have a laptop and it's got a cell modem in it, is that OK? Does it have to be built in or does a USB cell modem provide the magic safetyfying effect? Would it work if I just duct taped my cell phone to my laptop? Outstanding!

May 10, 2008

Danny McPherson posts about his experience with the free WiFi in the Unied Red Carpet Club:
More interesting is perhaps the access model they employ. To login, all you need is the United Mileage Plus number of the primary Red Carpet Club 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. But if you're in bind and need your airport wireless fix, odds are you won't have to walk far to find one available for the taking. As a matter of fact, I see two from where I'm sitting right now.

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... I also wonder how long it'll be until some poor schmuck is arrested for allegedly downloading child porn from an airport wireless network...

If this were a wired network this wouldn't be a security problem. After all, if you're inside the RCC, presumably you're an RCC member (unless you bought a day pass), in which case you should be entitled to use the network. But as Danny indicates, the wireless AP is probably accessible from outside the RCC, so if you sit outside the club, you should be able to get on the network, making it just a matter of having a valid mileage plus number, which you can get off of someone's luggage tag.

As far as exhaustive search goes, MP numbers are 11 digits long, but the first digit seems to always be zero, so this is a 10 digit space. I don't know how many RCC members there are, but Wikipedia claims that there are about 750,000 Premier and Premier Executive members, so let's say there are on the order of 200,000 RCC members, or 2*10^{-5} of the space. If the numbers are randomly distributed, you'd need to search about 100,000 numbers in order to find one. This could take quite some time (over a day at one per second). You might be able to get some leverage because the distribution isn't random. They seem to be issued in some kind of increasing sequence, though there seem to be too many numbers for it to be strictly sequential. If there's a check digit like in credit card numbers this would make the space a lot easier to search. (If someone knows the actual algorithm, please write in.) Of course, you only need to know a few valid numbers, so this might not be a totally prohibitive attack if reading it off someone's tag weren't so easy.

Three more thoughts:

  • RCC entry itself is a lot more valuable than access to the wireless, since the wireless access doesn't cost United much, but access to the club costs them food and (in the International terminal), free drinks. I assume it's not hard forge an MP card once you know a valid number. I'm not an RCC member so usually when I'm there it's on the "international ticket" + Star Alliance Gold exception, so they check my ticket, which is hard to forge. Do they insist on seeing your ticket if you're an RCC member? If not, this is actually a new attack vector on the RCC, since it would let you extract numbers even if it weren't easy to read them off other people's luggage.
  • There's actually a fairly easy way to secure the system against remote attacks (ones that don't involve somehow gaining access to the RCC interior) that wouldn't require lining the RCC walls with copper sheeting. For the first login to the RCC network, require not just your RCC #, but also a random passcode given to people on entrance (or maybe posted on the wall). After that, you can install a cookie on their computers and just let them on without a new login. 1
  • I'm a bit curious how the system checks for RCC number validity. Does it have a local copy of the RCC database? Is it connected to United's central systems? That could be interesting.

1 See draft-rescorla-stateless-tokens for a description of some techniques for avoiding the need for a centralized cookie database.


May 9, 2008

In preparation for the IETF P2P Infrastructure Workshop, I've revised and expanded this post into a "position paper submission.


In mid-2007 it was revealed [4] that Comcast was blocking peer-to-peer traffic (most famously BitTorrent) on their network by injecting RST packets to terminate TCP [7] connections. The BitTorrent community almost immediately discovered carrying BitTorrent over an encrypted tunnel (VPN or SSH) was not subject to blocking, thus completing another cycle of the ongoing arms race between peer-to-peer implementors and network operators. This paper explores some predictable next moves in the game and their consequences for the network.

This isn't intended to be comprehensive, because the request was for short papers, but I think it hits the high points. You can find the full note here.


May 2, 2008

George Ou made this argument at the FCC En Banc hearing at Stanford on 4/25 (A/V here).
It's actually quite common throughout the world that TCP RSTs are used.


Speaking of the 1:45 AM resets, ISPs all over the world, they've found that up to 12% of sessions get reset, all over the world. It's almost like there's this 12% of background noise of TCP resets that are happening that may not be coming from comcast but could be coming from any device on the Internet, all routers, all firewalls support that feature and we don't really know where it's coming from.

Here's ATT's response to Vuze's claim that they use RSTs for "network management purposes" (i.e., terminating connections they don't like):

In response to your specific question about AT&T's network management practices, AT&T does not use "false reset messages" to manage its network. We agree with Vuze that the use of the Vuze Plug-In to measure network traffic has numerous limitations and deficiencies, and does not demonstrate whether any particular network providers or their customers are using TCP Reset messages for network management purposes. Given that Vuze itself has recognized these problems with the measurements generated by its Plug-In, we believe that Vuze should not have published these misleading measurements, nor filed them with the FCC. Moreover, as Vuze and others have acknowledged, TCP resets are generated for many reasons wholly unrelated to the network management practices of broadband network providers, which explains why resets may appear on networks of companies such as AT&T who do not use TCP resets for network management (see, e.g., An Analysis ofTCP Reset Behaviour on the Internet, University of Calgary (2004)).

I've reviewed the paper by Arlitt and Williamson to which AT&T is referring (Ou didn't cite his sources), and while it's interesting work, I don't think it really speaks to Ou's argument. The RSTs that Arlitt and Williamson are talking about are primarily ungraceful terminations of TCP connections that would be ending anyway. The authors suggest a number of cases here:

  • Servers aggressively closing connections after short idle times, but the client already has a request in flight and the server responds with an RST.
  • Clients responding to FINs from the server with an RST. The reasons for this are a bit unclear.
  • Servers closing connections with RSTs.
  • Connections to servers which aren't listening on a given port and so are rejecting it.

In all of these cases but the last, though, the Web transactions are actually over, so while there may be some negative effects from not going through the correct TCP finish handshake (cf. RFC 1337), neither side perceives this as failed transactions. And in the final case, the server explicitly is rejecting the connection, so this seems appropriate as well. It's also fairly straightforward to distinguish these cases as a passive observer (as the authors have done) with the appropriate tools.

What Comcast has done, however, is something different: they were (are?) using RSTs to abort other people's transactions. The base rate of normal RSTs isn't really that useful for assessing the appropriateness of third party RSTs as a network traffic management technique. As a hypothetical, imagine that Comcast were forging FINs instead of RSTs. One could expand Ou's argument to say "FINs are a natural feature of the Internet", but it doesn't really follow that it's desirable to have third parties forging FINs on your connections.

It does bear, on the other hand, on what we can infer from Vuze's data. Vuze hasn't really published that many details of their methodology, but they claim to be measuring the total number of RSTs, not just those of Azureus/Bittorrent connections (Incidentally, I'm not sure how I'd feel as a user about installing some app that sniffed all the traffic on my network and sent statistics to Vuze)[-- see update below; EKR]:

The Vuze Plug\u2010In constantly monitors the rate of network interruptions occurring from RST ("reset") packets by measuring the total number of attempted network connections and the total number of network connections that were interrupted by a reset message. By comparing these two values, one can calculate the ratio of network connections interrupted by reset messages. We have chosen to reflect the median ratio in order to reduce variability in the data given the sample size.

The Plug\u2010In collects data for all Internet connections, not just connections occurring due to use of the Vuze application, and logs it every ten minutes Then, at the top of the hour, the Plug\u2010In aggregates the data into one\u2010hour blocks and transmits it to Vuze, Inc.. By definition, each source of data had the Vuze application installed and launched in order connections.

But if you're measuring all RSTs and not attempting to determine which ones are "normal" and which ones represent connection failure, then it's not clear how representative your data is. It is sort of interesting how much variation (about an order of magnitude from 2.5% to 24%) there is in terms the rate of RSTs, but as Iljitsch van Beijnum observes, this could be the result of caching proxies and the like in the network. You may not particularly want your ISP interposing a proxy, but that's a different question than whether they're actually blocking your P2P traffic.

This isn't the only possible reason, either. For instance, users might just have different software profiles. Given that Vuze claims to have 8000 users on 1200 ASs (with the data being reported for ASs with greater than 20 users, there could well just be a lot of statistical variation. Some evidence of this is that the results from Comcast alone span from 14% to 24%). In order to really make sense of data like Vuze's we'd need to try to distinguish normal RSTs from those injected in the network, which requires more forensics (TTL inspection, IP ID, etc.) than Vuze's paper describes.

UPDATE (8:49 AM): I was wrong about this needing to be a packet sniffer. I just read the source (here; thanks to Danny McPherson for pointing out that I could download it.) They're just using netstat to read the network statistics and grabbing the reset counter out of the results. On the other hand, this means that they're not even in principle able to differentiate between RSTs generated on Azureus connections and those on other connections or between those generated by some man in the middle or by endpoints. While the variation in reported RSTs remains interesting, you'd need a significantly more advanced tool than this to really diagnose what's going on.