May 10, 2008

Red Carpet Club WiFi

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:

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

Posted by ekr at 8:56 PM | Comments (3)

May 9, 2008

Notes on P2P Blocking and Evasion

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

Introduction

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.

Posted by ekr at 10:19 AM | Comments (0)

May 2, 2008

Yes, many TCP connections end in RSTs

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:

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.

Posted by ekr at 7:36 AM | Comments (1)

April 18, 2008

Metered Internet?

At the FCC hearing yesterday, there was a lot of talk about metered Internet. (See also Rob Malan Rob Malan arguing that net neutrality legislation will inevitable result in metered Internet service). It's certainly true that metered Internet is one possible outcome of network neutrality regulation, but I'm not convinced that it's the only one. It's interesting to note that at the same time as we're arguing about this, all the major wireless service providers (which have historically been incredibly stingy about per-minute charging) have recently rolled out unlimited voice offerings.

Now, you could certainly argue (as Rob's argument implies) that there's an upper limit on how much bandwidth can be used by voice and so as the technology has improved, it's become cost effective to offer unlimited voice service, but that the bandwidth consumed by video will be much greater. On the other hand, just last year Apple pushed Cingular/AT&T into offering an unmetered data plan for the iPhone, and apps like YouTube for iPhone clearly encourage users to consume larger amounts of bandwidth than they would if just checking their email. Now, obviously the cell providers have a lot of latitude to manage the data portions of their network, but it still seems to me that there are a lot of factors in play here and that metered Internet is not the only possible outcome, even in a more highly regulated regime.

Posted by ekr at 8:52 PM | Comments (2)

April 10, 2008

So, basically ISPs hate video

UK ISPs say that the the BBC's iPlayer video service is "threatening to bring the network to a halt":
The success of the BBC's iPlayer is putting the internet under severe strain and threatening to bring the network to a halt, internet service providers claimed yesterday.

They want the corporation to share the cost of upgrading the network - estimated at £831 million - to cope with the increased workload. Viewers are now watching more than one million BBC programmes online each week.

The BBC said yesterday that its iPlayer service, an archive of programmes shown over the previous seven days, was accounting for between 3 and 5 per cent of all internet traffic in Britain, with the first episode of The Apprentice watched more than 100,000 times via a computer.

Huh?

The whole reason I get Internet service is so I can download stuff off the Intertubes, which means that whenever I find something cool and want to suck it down I don't want my ISP complaining that I'm using too much bandwidth. Now, it's true that it's true that when there is a lot of data flowing from a server on ISP A to ISP B, it's a bit confusing whether A should pay B, B should pay A, or whether money should change hands at all. Note that these aren't networking issues, but pure economic issues—issues like this have been relevant ever since the days of paper mail. (In the Internet world, a lot of this is social. The amount of money you have to pay in settlements sort of scales with bandwidth until you get big enough that people want to peer with you, at which point you don't pay). And I'm not saying there isn't a need for the ISPs to upgrade their infrastructure and figure out who's rates to jack up in order to pay for it. But these issues aren't really effectively solved by every ISP trying to hold up any service that gets popular.

Posted by ekr at 9:08 PM | Comments (2)

April 8, 2008

Comcast traffic shaping^H^H^H^H^H^H^H^H^H^H^HNATs

A group in Colorado recently reported that Comcast had introduced a new traffic shaping mechanism which was blocking even non-P2P TCP connections:
Recently, it has been observed that Comcast is disrupting TCP connections using forged TCP reset (RST) packets [1]. These reset packets were originally targeted at TCP connections associated with the BitTorrent file-sharing protocol. However, Comcast has stated that they are transitioning to a more "protocol neutral" traffic shaping approach [2]. We have recently observed this shift in policy, and have collected network traffic traces to demonstrate the behavior of their traffic shaping. In particular, we are able (during peak usage times) to synthetically generate a relatively large number of TCP reset packets aimed at any new TCP connection regardless of the application-level protocol. Surprisingly, this traffic shaping even disrupts normal web browsing and e-mail applications. Specifically, we observe two different types of packet forgery and packets being discarded.

...

We synthetically generated TCP SYN packets at a rate of 100 SYN packets per second using the hping utility [3]. The packets were destined for the reserved IP address 2.2.2.2, on which no host is present. We simultaneously collect network traces using tcpdump [4]. This data collection process was repeated at various times throughout multiple days. In addition, we could monitor a destination host to determine if outgoing packets reached their destination, and to determine if responses are generated by the destination host or by a third-party. Finally, this data collection was conducted from multiple Comcast accounts, all within close geographical proximity.

My initial reaction was that 100 SYN packets per second is a pretty pathological load, especially when these packets are being sent to a bogus net block (2/8 is unallocated by IANA) and that this sounded a lot more like some sort of anti-DoS measure, not really traffic shaping. The answer seems out to be even simpler:

A note regarding our findings: Further experiments have led us to believe that our initial conclusions that indicated Comcast's responsibility for dropping TCP SYN packets and forging TCP SYN, ACK and RST (reset) packets was incorrect. Our experiments were conducted from behind a network address translator (NAT). The anomalous packets were generated when the outbound TCP SYN packets exceeded the NAT's resources available in it's state table. In this case, TCP SYN, ACK and RST packets were sent. We would like to thank Don Bowman, Robb Topolski, Neal Krawetz, and Comcast engineers for bringing this to our attention. We sincerely apologize for any inconvenience that this posting may have caused.

This sounds pretty plausible to me; NATs often have fairly small state tables and 100 cps could definitely overload a residential NAT pretty quickly, and it's certainly easy enough to forget that the NAT box you're sitting behind is anything other than transparent. One thing that surprises me a bit is that the researchers claim to be seeing two kinds of anomalies: RSTs and spoofed SYN/ACKs. One would generally expect to see only one kind of response to overload. Maybe they have more than one NAT, though. It would certainly be interesting to hear what exact network gear they are using.

Posted by ekr at 9:53 PM | Comments (0)

February 28, 2008

Yeah, that's going to work...

One of the main reasons to have a blog is to call a bad idea a bad idea. Here's one. Former FBI Agent Patrick J. Dempsey suggests:
It's obvious that the Internet requires some type of governance. But it is just as obvious that trying to establish this governance through the numerous legal systems might not be practical. The other possibility for governing the Internet, and, more specifically, the criminal activity that occurs on the Internet, would be to change the structure of the Internet. Although I don't support ideas like the "national firewalls" put in place by some countries, this type of solution does afford some level of control over Internet traffic flowing through said country.

However, knowing all the possibilities with disguising or "spoofing" one's information on the Web, I'm not sure that there is a way to truly "protect our borders" when it comes to the Internet. The solution might be to establish two Internets -- the current Internet and a new, more secure Internet where users would be required to register prior to gaining access. Once again, though, we're confronted with the issue of what would be the governing body that would manage the user registrations? Would it be an organization similar to the IANA (Internet Assigned Numbers Authority) or InterNIC that would manage user registrations on the "new" Internet, or do we need to establish an entirely new entity to manage a more secure Internet?

The problem with this idea is it's totally confused about the security problem with the Internet, which has a lot more to do with stupid users and insecure software than it does with failing to authenticate everyone with a modem.

Let's play this out: you set up your new secure Internet. There's already an Internet 2, so let's call it Internet 3 or I3. Anyway, we've got I3 up and running and before they'll give you a connection you have to give them your fingerprint, irisprint, a blood sample and the keys to your car. Of course, if if you want I3 to be useful, you have to let pretty much anyone on, so just like the Internet, I3 is full of hackers. And since your software isn't any more secure than it was before, you're still just as likely to have your machine compromised. Now, it's true that having positive identification for each user might forensics a tiny bit easier: once you've managed to track the user down to the account they initially logged in from, you know who to arrest. But of course, hackers use compromised machines as stepping stones, so tracking them down isn't easy, and of course it's not exactly difficult to steal people's account information and log in as them instead of yourself.

Even if we somehow were able to create an I3 without any hackers on it, it wouldn't stay that way for long. I3 is one big sterile area, so as soon as any significant number of compromises happen it's game over. Initially, I3 is going to be pretty lame, so people are going to use both the Internet and I3. And since the Internet is full of hackers and their machines are compromised and they're going to use the same machines for both the Internet and I3, it's not going to be long before plenty of I3 credentials are circulating in the hacker community. Creating isolated networks is really hard even when you're working in real high security environments. It's basically impossible when you're dealing with millions of people, many of whom are willing to run any random .exe file you send them.

Posted by ekr at 8:31 PM | Comments (4)

February 20, 2008

Wikileaks shut down

Cayman bank Julius Baer Bank and Trust has convinced a federal judge to shut down DNS service for wikileaks.org.
On Friday, Judge Jeffrey S. White of Federal District Court in San Francisco granted a permanent injunction ordering Dynadot, the site's domain name registrar, to disable the Wikileaks.org domain name. The order had the effect of locking the front door to the site -- a largely ineffectual action that kept back doors to the site, and several copies of it, available to sophisticated Web users who knew where to look.

Domain registrars like Dynadot, Register.com and GoDaddy .com provide domain names -- the Web addresses users type into browsers -- to Web site operators for a monthly fee. Judge White ordered Dynadot to disable the Wikileaks.org address and "lock" it to prevent the organization from transferring the name to another registrar.

The feebleness of the action suggests that the bank, and the judge, did not understand how the domain system works, or how quickly Web communities will move to counter actions they see as hostile to free speech online.

The site itself could still be accessed at its Internet Protocol address (http://88.80.13.160/) -- the unique number that specifies a Web site's location on the Internet. Wikileaks also maintained "mirror sites," or copies usually produced to ensure against failures and this kind of legal action. Some sites were registered in Belgium (http://wikileaks.be/), Germany (http://wikileaks.de) and the Christmas Islands (http://wikileaks.cx) through domain registrars other than Dynadot, and so were not affected by the injunction.

There's also a mirror at cryptome.

For those of you who don't know how this all works, there's registries, who actually run the domain name (.org in this case) and then there are registrars, who actually deal with the customers. Any given top level domain typically has multiple registrars that service it, all of whom populate the same database, operated by the registry. So, the locking thing stops Wikileaks from transferring their domain to another registrar who would then reactivate it.

OK, so this order controls the registrar. But can Wikileaks just go to the registry and get them to move it to some other registrar, locking notwithstanding? In this case, Wikileaks is under .org, which is run by the Public Interest Registry. Operationally, the PIR is run by Afilias. Both of these are based in the US, so presumably the injunction could be expanded to include them as well. On the other hand, as the article notes, there are plenty of registries with no US connection and the only way for a US judge to take down them domains under them would be to go after ICANN, which, despite complaints about the US running the DNS seems pretty unlikely.

As you may be gathering at this point, this is all pretty pointless. It's basically impossible to censor stuff like this once it gets out. We're seeing the first level of countermeasure here, but even if by some miracle the judge managed to shut down every domain name serving the contraband material (and since the decision loop for spreading those domain names is a lot faster than your average judge's decision making process), people can just move to IP addresses published by some other means (like other people's web sites). And there are about three levels of escalation up from there, all of which are progressively harder to censor.

It will be interesting to see if JBBT goes after cryptome.org, though.

Posted by ekr at 9:42 PM | Comments (0)

February 16, 2008

Overproduction

The EFF has obtained a document under FOIA describing an incident in which an email provider which was served by an NSL for some email communications and accidentally sent far too much information to the FBI:
In late February 2006, a surge in data being collected by the FBI's Engineering Research Facility (ERF) was identified by ERF personnel. As a result ERF investigated the issue and recognized that the collection tools used to collect email communication from the subject of the investigation were improperly set and appeared to be collecting data from the entire email domain. due to an apparent miscommunication, the private internet provider accidentally collected mail from the entire domain and subsequently conveyed the email to ERF.
(NYT story here).

I'm sort of curious what kind of tools the ISPs are using here. You certainly can reconfigure your mailer to forward copies of emails to certain addresses to somewhere else, though mail going out is a little trickier. In any case, I'd be a little surprised if the FBI expected something quite so DIY. Maybe when they send you an NSL it comes with a pamphlet telling you how to reconfigure Outlook.

Apparently, this happens reasonably often. The FBI calls it "overproduction":

A report in 2006 by the Justice Department inspector general found more than 100 violations of federal wiretap law in the two prior years by the Federal Bureau of Investigation, many of them considered technical and inadvertent.

...

In the warrantless wiretapping program approved by President Bush after the Sept. 11 terrorist attacks, technical errors led officials at the National Security Agency on some occasions to monitor communications entirely within the United States -- in apparent violation of the program's protocols -- because communications problems made it difficult to tell initially whether the targets were in the country or not.

Past violations by the government have also included continuing a wiretap for days or weeks beyond what was authorized by a court, or seeking records beyond what were authorized. The 2006 case appears to be a particularly egregious example of what intelligence officials refer to as "overproduction" -- in which a telecommunications provider gives the government more data than it was ordered to provide.

The problem of overproduction is particularly common, F.B.I. officials said. In testimony before Congress in March 2007 regarding abuses of national security letters, Valerie E. Caproni, the bureau's general counsel, said that in one small sample, 10 out of 20 violations were a result of "third-party error," in which a private company "provided the F.B.I. information we did not seek."

To quote Broken Arrow, " I don't know what's scarier, losing a nuclear weapon or that it happens so often there's actually a term for it." Outstanding!

Posted by ekr at 9:19 PM | Comments (0)

February 1, 2008

The Internet is the computer

Writing about Microsoft's acquisition offer for Yahoo (everyone has a clever proposed name for this, mine is MiHoo, pronounced my-hoo), Chris Wilson says:
As access to the Internet has become ubiquitous, computer users have increasingly gone to the Web for what were once offline tasks. In the near-future, it will become more efficient to run an application, like a word processing program, off of a central network of computers rather than an individual hard drive. The concept is known as "cloud computing": Documents will begin and end their lives on a server rather than a personal computer, and users will be able to access their personal documents and favorite programs wherever they are with any networked device.

Wilson is certainly right to observe that there is real interest in moving functionality from the machines on people's desks to servers, but of course we've been around this cycle a number of times before (remember mainframes? minis? XTerminals? the SunRay?) so it's not like conditions here are unique. What's semi-unique is that the we're returning to the really early days of computing where (at least sometimes) clients from multiple organizations connect to a central server owned by some other organization. Back in the day, it was because computers were so expensive, now it's driven by networks and computers being cheap, but management being expensive. (As Tech Ennui observes, this is related to, but not the same as Myers and Sutherland's wheel of reincarnation).

It's also not really clear how much Web apps like the ones Google is building are really going to take off. People are really pretty committed to their desktop word processing apps, spreadsheets, etc. It remains to be seen if they're really going to be willing to outsource them to Google, Microsoft, whatever.

Interestingly, in order to move the nominal location of services into the cloud, we're moving processing onto the desktop (this is different from say XTerminals, where nearly all the processing was on the server (the X client)). Classic Web apps use the client as a dumb display engine but Web 2.0 AJAX-style apps move processing onto the client using JavaScript. In fact, if you squint hard enough, AJAX looks a tiny bit like NeWS.

Posted by ekr at 10:01 PM | Comments (0)

January 29, 2008

Sex offender? Welcome to registering your email address

MySpace has been under a lot of pressure to do something about the alleged threat from "sexual predators" using their service. As I've observed before, there's not really much they can do unilaterally. They appear to have decided to deal with this problem New York Attorney General Cuomo has proposed legislation to restrict sex offenders use of the Internet:
MySpace and Facebook, said Cuomo, asked for new legislation to help them make their social networks safe. And that's what the E-STOP Act aims to provide. Cuomo described it as a Megan's Law for the age of the Internet. Megan's Law, named after murdered seven-year-old Megan Kanka, refers to a collection of state and federal laws enacted in the 1990s that require sex offenders to register so that communities can be informed of their presence.

"The law that we're talking about today does two things," said Cuomo. "First, as a mandatory condition of parole or probation for serious sex offenders, it will prohibit them from going on social networking sites that attract young people or from communicating on the Internet with any person under 18 years old. Second, it sets up an e-mail registry where every parolee will have to give their e-mail or their on-screen identities to a state registry. And it establishes a process whereby the social networking sites or Internet sites can take that Internet registry, run it against their site, and screen or delete the users who are on both lists. It also allows Internet service companies to notify law enforcement, who can then take the appropriate action."

...

"Rather than treating the online and offline worlds differently, our goal at MySpace has been and will continue to be to make our virtual neighborhood as safe as our real one," said Hemanshu Nigam, chief security officer of Fox Interactive, which owns MySpace. "We keep a watchful eye on predators who leave our jails and prisons into our physical world. If we fail to do so in our online world, we unwittingly provide an advantage to these predators, an advantage that they can and they will exploit."

OK, so at some level this isn't completely insane. As I said earlier, clearly MySpace can't do this alone, so if your plan is to keep sex offenders off MySpace, then you're going to need some kind of legislation to let you identify them. That said, it's not really clear why this is thought to be valuable. Presumably if you get busted for being a sex offender it's not like you're not going to be overconcerned about whatever odditional penalty you're going to get for failing to register your email address or illegally using MySpace.

Nigam makes the analogy to having to register your physical address, but this doesn't really make much sense. You've got to live somewhere, so it's kind of noticeable if you don't register your physical address, and the parole officer can come by and check up on where you live. So, to the extent to which you think it's important to figure out where sex offenders live (again, it's not clear it really is), it's fairly doable. By contrast, you can have as many email addresses as you want and it's not particularly difficult to get yourself an untraceable or at least hard to trace email address, so it's extremely hard to verify that sex offenders have actually registered their addresses if they make any attempt to evade this law.

And of course this assumes that it's particularly useful to be able to keep sex offenders off of services like MySpace and Facebook. That's not really clear. I'd be interested to see if there is any good data on how many sex offenses actually result from solicitations on services like this.

Posted by ekr at 9:28 PM | Comments (3)

January 22, 2008

Uh, yeah IP addresses are identifying

The EU has decided that IP addresses need to be treated as personally identifying information.
Google and other companies maintain that I.P. addresses are not personally identifiable information. One part of the argument is that I.P. addresses identify a computer, not the person using it. True. But that’s the same as a telephone; just because a call was made from a number doesn’t tell you exactly who was talking. Nonetheless, I suspect that most people believe their phone number is quite personal.

The other part of the argument has to do with dynamic I.P. addresses, the practice by Internet providers of switching the I.P. address of home users. Even there, I.P. addresses are not as anonymous as they would appear. Internet service providers keep records of what I.P. addresses are assigned to which customers at what times. Combine these I.S.P. records with a log file from a Web site, and you have a map to who has done what on the Internet.

Look, this isn't even close. It's certainly true that many home users have IP addresses that are assigned via DHCP, so in principle they're dynamic, but that doesn't mean that you don't regularly get the same IP. From what I hear, common practice for full-time Internet connections is to regularly assign the same IP addresses to the same host. The IP addresses change occasionally, but mostly they're semi-static, so the IP address is generally a pretty useful identifier. And of course, even if your IP address does change regularly, it's still possible to cross-correlate activities at multiple sites at the same time.

Of course, this doesn't tell you how IP address information should be handled. Web servers routinely log client IP addresses and your average small Web site has zilcho in the way of policies or mechanisms for purging this kind of information from their logs. So, saying that IP addresses need to be kept confidential would entail pretty significant changes to operational practice. So, it's a balancing act, but it's certainly not true that there's no privacy risk from IP information leaking; quite the contrary.

Posted by ekr at 10:05 PM | Comments (0)

October 22, 2007

First thoughts on Comcast's BitTorrent (and others) blocking

It's now been pretty widely reported that Comcast is blocking BitTorrent (as well as other apps such as Gnutella and allegedly Lotus Notes) traffic. (Good summary by Ars Technica here and here).

The technical issue here is pretty straightforward; Comcast seems to be forging TCP RST (Reset) segments from one side of the connection to the other, causing the receiving TCP implementation to terminate its side of the connection. The evidence here is that people have taken packet dumps on both sides of the connection and neither peer is generating the RSTs, so it's clearly someone in the middle, and the pattern of which subscribers are affected looks like it implicates Comcast. Note: I'm going purely by others reports. I have Comcast myself, but I haven't tested this.

More interesting is the pattern of what is being blocked. According to TorrentFreak, Comcast is only blocking people seeding files:

Unfortunately, these more aggressive throttling methods can't be circumvented by simply enabling encryption in your BitTorrent client. It is reported that Comcast is using an application from Sandvine to throttle BitTorrent traffic. Sandvine breaks every (seed) connection with new peers after a few seconds if it's not a Comcast user. This makes it virtually impossible to seed a file, especially in small swarms without any Comcast users. Some users report that they can still connect to a few peers, but most of the Comcast customers see a significant drop in their upload speed.

The throttling works like this: A few seconds after you connect to someone in the swarm the Sandvine application sends a peer reset message (RST flag) and the upload immediately stops. Most vulnerable are users in a relatively small swarm where you only have a couple of peers you can upload the file to. Only seeding seems to be prevented, most users are able to upload to others while the download is still going, but once the download is finished, the upload speed drops to 0. Some users also report a significant drop in their download speeds, but this seems to be less widespread. Worse on private trackers, likely that this is because of the smaller swarm size

Assuming this is correct, Comcast is targetting files which Comcast users are serving to non-Comcast users. This mostly doesn't degrade your perceived performance if you're a Comcast user downloading content, but if you're (1) a non-Comcast customer trying to download traffic from a Comcast customer or (2) actually trying to push something into the P2P network, then this is going to seriously impact your experience. Since most customers are probably in the downloader category, this is actually a pretty attractive way to reduce network traffic without overly annoying too many of your users. By contrast, if Comcast just blocked all BitTorrent, then everyone trying to download the next episode of Lost would be pretty unhappy and would most likely be pretty intolerable to a sizable enough percentage of customers that you couldn't just stonewall.

Posted by ekr at 6:05 PM | Comments (1)

October 1, 2007

Why does RBDS suck so much?

My Audi's builtin radio is fitted with an Radio Broadcast Data System (Radio Data System in Europe) receiver. In theory, the broadcasters can use this to tell you what you're listening to. In practice, not so much. First, support is spotty at best. Out of the 6 presets on my dial, no more than 3 actually tell you anything useful, like what song is playing. This is particularly baffling since I believe all of them actually do broadcast at least the call sign of the station, so broadcasting program-relevant information wouldn't seem to be much of a stretch. But no. Moreover, even the stations that do broadcast it don't em to do so consistently.

Second, the error rate is unbelievably high. Several times, I've been informed that I'm listening to PUBIC RADIO, which I'm pretty sure is only available on SIRIUS. I don't have a good explanation for this because RDS allegedly has error correction and given that the usable bit rate is supposed to be over 1 kbps, and your average song name is <<100 characters and the scrolling seems to happen about once ever 2-3 seconds, there's plenty of room for error correcting codes out the wazoo. And don't even get me started on the scrolling, which looks hideous.

Even once you get past transmission errors, RBDS still sucks. Today it inexplicably informed me that Tom Petty's Mary Jane's Last Dance was the Rolling Stones "Horses" (or rather the ROLLING STONES "HORSES"—I guess the extra bit per character for lower-case letters would have chewed up too much bandwidth), a song, which as far as I know doesn't exist. My guess here is that it was trying for Wild Horses (not to be confused with Wild Stallyns) and there was some transmission glitch, but I don't have any good explanation for how the radio station software got this confused.

Anyway, this seems like something that could be executed a lot more competently.

Posted by ekr at 8:18 PM | Comments (2)

September 27, 2007

What do you expect from centralized messaging systems?

Yes, yes, Verizon sucks for refusing to allow blast SMSes from NARAL, even if they did eventually recant. But fundamentally what you should be objecting to is a system in which you need permission from Verizon for this kind of activity ( this was opt-in so NARAL wasn't spamming). But that's what you get when you have a centralized messaging system going through some provider choke point instead of a transparent data bearer service. You'll note that I can make some Internet mailing list without asking Comcast or permission.

Posted by ekr at 9:14 PM | Comments (4)

September 8, 2007

Sorry about all the "Test" posts

Sorry if you're seeing a lot of test posts, especially in your RSS feed. I was trying to figure out why my Emacs-based posting software wasn't working. Looks like what happened here is that Dreamhost upgraded to some version of Apache (Apache2?) with automatic response compression and the version of xml-rpc.el I was using couldn't handle it (w3 doesn't seem to uncompress automatically in all cases). I think I've got it fixed now.

Posted by ekr at 8:04 AM | Comments (1)

September 5, 2007

Why can't we find Steve Fossett?

"Millionaire Adventurer" Steve Fossett has now been missing for three days after his plane went down over Nevada. Search and Rescue seems to be having a lot of trouble finding him, which is a bit surprising. I had just assumed that he wasn't carrying a locator beacon for some reason (I don't think that PLBs are required, but I admit I'm not sure), but according to this he was:
"This is kind of strange because these aircrafts have transponders and emergency locators and you can usually readily find them anywhere in the world, including under the sea," said Ross Aimer, CEO of Aviation Experts, a San Clemente, California-based aviation consulting firm.

"This guy is totally lost.... So far, nobody's heard the electronic location beacon," said Aimer, who has flown the region several times. "That sounds to me very, very strange. There's all kinds of possibilities."

...

Officials say there's been no detection of the emergency locator beacon that would automatically go off in the event of a crash or could have been enabled by Fossett himself if he were capable. Fossett did not file a flight plan and didn't carry extra radio equipment because he was only planning to be gone for a short while, Ryan said.

Weird.

Posted by ekr at 8:44 PM | Comments (5)

September 1, 2007

iPhone unlocking

These guys claim that they have a program to unlock the iPhone. For those of you who aren't mobile phone wonks, here's how things work. In principle, the iPhone can work with two networks in the US: AT&T (formerly Cingular) and T-Mobile. Sprint and Verizon use a different cellular technology. The iPhone uses the European standard, GSM. One of the nice features of GSM is that the caller's information is contained on a chip called a Subscriber Identity Module (SIM). This has two implications:

For our purposes the second property is more interesting, because it allows consumers to mix and match phones and networks, forcing mobile phone carriers to compete on the basis of network quality rather than of who offers the coolest phones. Obviously, phone companies would prefer not to have to compete on these grounds; if you have to pay for a new phone whenever you want to switch carriers this disincentivizes switching. 1 One technique for stopping switching is to SIM lock the phone. The carrier (or more likely the vendor) programs the phone so it only works with a SIM from that carrier. However, generally the information about how to unlock the phone leaks somehow and it's pretty common for there to be third-party unlocking services. Sometimes the carrier will even do it for you; T-Mobile will if you've had the phone for more than 90 days.

This brings us to the topic of the iPhone. The iPhone is sold at the Apple store (and, of course, the AT&T store, but you have to be kind of nuts to go to the AT&T store) but SIM locked to AT&T. Naturally there's been some interest in unlocking it. An unlocked iPhone could also be used with T-Mobile in the US (a modest advantage in terms of coverage but a big advantage in terms of price) but could also be used with a non-US carrier.

A number of different techniques have been found for unlocking the iPhone (summary here) but all the readily available ones are either expensive (requiring some new hardware) or somewhat scary (opening it up and soldering some stuff). As noted above, there have been claims of software-only solutions but as of yet there doesn't appear to be any such software publicly available. Obviously something like this would be better than having to screw with the hardware.

This is all a basically separate issue from the question of running arbitrary software on the iPhone. As everyone knows, the iPhone is a closed platform, so, unlike your computer, you can't (officially) just load whatever software you want onto it. That protection has been broken for some time now (see here) and I have several friends who are running arbitrary software on their iPhones. Of course, it may be the case that being able to break that protection is important to making a software unlocking solution work. I don't think we'll know that till we see such a solution in action.

Oh, one more thing: the only people who claim to be offering unlocking software intend to sell you the software. However, I would expect that very shortly after such software is released, it will be reverse engineered and a free solution will be produced.

1. An additional complication is that in the US, at least, many carriers subsidize the initial purchase of the cell phone and require a contract with a cancellation fee, but that's just another way of making you pay to switch.

Posted by ekr at 7:42 AM | Comments (1)

August 20, 2007

More on the Skype outage

Here's Skype's official word on what caused their outage:
In an update to users on Skype's Heartbeat blog, employee Villu Arak said the disruption was not because of hackers or any other malicious activity.

Instead, he said that the disruption "was triggered by a massive restart of our users' computers across the globe within a very short timeframe as they re-booted after receiving a routine set of patches through Windows Update," Arak wrote.

Microsoft Corp. released its monthly patches last Tuesday, and many computers are set to automatically download and install them. Installation requires a computer restart.

"The high number of restarts affected Skype's network resources. This caused a flood of log-in requests, which, combined with the lack of peer-to-peer network resources, prompted a chain reaction that had a critical impact," Arak wrote.

Arak did not blame Microsoft for the troubles and said the outage ultimately rested with Skype. Arak said Skype's network normally has an ability to heal itself in such cases, but a previously unknown glitch in Skype's software prevented that from occurring quickly enough.

Some thoughts:

Posted by ekr at 9:46 PM | Comments (3)

August 19, 2007

The Skype outage and centralized systems

Skype suffered an extended service outage last week. There were a lot of rumors about how this was the result of some sort of attack, though Skype denies it. Here's what they say:
Apologies for the delay, but we can now update you on the Skype sign-on issue. As we continue to work hard at resolving the problem, we wanted to dispel some of the concerns that you may have. The Skype system has not crashed or been victim of a cyber attack. We love our customers too much to let that happen. This problem occurred because of a deficiency in an algorithm within Skype networking software. This controls the interaction between the user's own Skype client and the rest of the Skype network.

I don't have any more information about this than anyone else, so it could be either an attack or just a simple error. In either case, even if you believe Skype's story, it suggests that the Skype system is fairly brittle. Basically, any problem with Skype's central servers, whether through attack or error, has the potential to bring down Skype as a whole. By contrast, in a more distributed/decentralized system, global outages tend to be a lot less common. For instance, if I have an account with SIP server Atlanta and you have an account with SIP server Biloxi, an outage at server Chicago doesn't affect us at all. Of course, if there's some sort of large-scale Internet outage, this can affect us, but such issues aren't that common and of course Skype is just as vulnerable to such issues.

I'm not arguing that SIP is somehow inherently superior to Skype. It's quite possible to build a SIP-based system which is just as centralized and fragile—if Vonage's servers go down, then no Vonage customer will be able to make phone calls. On the other hand, there are other SIP providers and they aren't affected by Vonage outages. The difference here is that Skype is inherently centralized, and you basically can't use Skype without talking to their servers somehow. 1. By contrast, SIP was specifically designed to be used in a decentralized environment, much like e-mail is now, and clients and servers from separate vendors more or less interoperate—though of course some network operators won't allow direct SIP connections so you sometimes (often?) need to go through the PSTN for SIP UA A to talk to SIP UA B.

This isn't to say that decentralized systems are inherently better, of course, but they are generally more resistant to this particular failure mode.

1. Yes, the Skype protocol has been reverse engineered, but as far as I know there aren't any compatible clients or servers, and Skype's implementation is deliberately designed to be closed—you shouldn't expect to be able to use Skype's clients with such a service, which significantly decreases the value of using the Skype protocol.

Posted by ekr at 9:05 PM | Comments (1)

August 17, 2007

Sorry for the outage

Dreamhost was down. Hopefully we're back on the air now.

Posted by ekr at 11:20 AM

August 8, 2007

Infrant SSH backdoor

Infrant (makers of ReadyNAS, now owned by Netgear) just released a security advisory for remote root SSH access to their box:
NETGEAR has released an add-on to toggle SSH support for the ReadyNAS systems based on a potential exploit to obtain root user access to the ReadyNAS RAIDiator OS. Each ReadyNAS system incorporates a different root password that can be used by NETGEAR Support to understand and/or fix a ReadyNAS system remotely using the ReadyNAS serial number as a key. An attacker that has obtained the algorithm (and your serial number) to generate the root password would be able to remotely access the ReadyNAS and view, change, or delete data on the ReadyNAS.

ReadyNAS installation most vulnerable to this attack is in an unsecure LAN and where the ReadyNAS SSH port (22) is accessible by untrusting clients. Typical home environments are safe if a firewall is utilized and port 22 is not forwarded to the ReadyNAS from the router. We do advise that all ReadyNAS users perform this add-on installation regardless.

Installation of the ToggleSSH add-on will disable remote SSH access and thus close the vulnerability. At the same time, if you need remote access assistance from NETGEAR Support, you can install the ToggleSSH add-on again to re-enable SSH access during the time when the remote access is needed.

In other words, NETGEAR support can remotely log into any ReadyNAS box as root and manage it. A few notes:

Oh, and what were they thinking having this on by default? Outstanding!

Posted by ekr at 9:45 PM | Comments (5)

August 6, 2007

Fail-what?

In my previous post about SWORDS robots, I referred to "fail-safe" and "fail-unsafe" strategies. Now, clearly, if you're a civilian in the line of fire of a killer robot, you'd think a strategy in which the robot shut itself down when it couldn't communicate with base to be "safe", you might feel a little differently if you were a soldier who had to go out into enemy fire because a minor communication glitch caused your robot to shut down.

As another example, take a system like Wireless Access in Vehicular Networks (WAVE), which provides for communications between vehicles and between vehicles and road-side units. WAVE can be used for safety messages, such as the Curve Speed Warning message, which allows a station at the side of the road to broadcast the maximum safe speed for a given curve. Obviously, you'd like there to be some message integrity here to prevent an attacker from broadcasting a fake speed. Now, what happens when the integrity check fails; do you ignore the message?

A decent argument could be made that either ignoring or trusting such messages was "fail-safe". Obviously, ignoring them appears safe in the sense that your vehicle reverts to what it was without the WAVE functionality, so you haven't been damaged. On the other hand, the curve speed warning is designed to help safety (that's why it's being broadcast) so ignoring it is arguably failing unsafe! I don't really have a position on what's right or wrong here, but it should be clear that the terminology is confusing.

I've heard people substitute the terms "fail-open" or "fail-closed", but those are even worse. If you're an electrical engineer, a closed circuit means current flows and an open circuit means current doesn't. On the other hand, an open firewall means that data flows but a closed one means it doesn't.

I don't know of any really good terms, unfortunately.

Posted by ekr at 8:45 PM | Comments (5)

July 23, 2007

Why would I want contiguous addresses?

ARIN (the American Internet Registry)'s recent statement on v4 address allocation has generated a bit of a stir. The important text is:
WHEREAS, community access to Internet Protocol (IP) numbering Resources has proved essential to the successful growth of the Internet; and,

WHEREAS, ongoing community access to Internet Protocol version 4 (IPv4) numbering resources can not be assured indefinitely; and,

WHEREAS, Internet Protocol version 6 (IPv6) numbering resources are available and suitable for many Internet applications,

BE IT RESOLVED, that this Board of Trustees hereby advises the Internet community that migration to IPv6 numbering resources is necessary for any applications which require ongoing availability from ARIN of contiguous IP numbering resources; and,

BE IT ORDERED, that this Board of Trustees hereby directs ARIN staff to take any and all measures necessary to assure veracity of applications to ARIN for IPv4 numbering resources; and,

BE IT RESOLVED, that this Board of Trustees hereby requests the ARIN Advisory Council to consider Internet Numbering Resource Policy changes advisable to encourage migration to IPv6 numbering resources where possible.

Obviously, this is written in some sort of legal-speak, but the important bit is the section about "ongoing availability of contiguous IP numbering resources." Here's how to understand this: remember that IPv4 addresses are 32-bit numbers. If you only have one IP address, it doesn't much matter what it is, as long as it's valid. But if you have more than one, it's extremely convenient for all the numbers to be contiguous. Why? Because it's easier to talk about them.

This is pretty easy to see in the context of routing. Say I've just been assigned addresses A, B, and C. I want to tell all the links on which I'm connected to others "hey, if you want to talk to A, B, and C", talk to me. This requires me to send three separate data items and them to store three separate items. That's not so bad when I only have three addresses, but starts to get a little unwieldy if I have 3 million. It's much more convenient to have addresses which are sequential and then I can say "I have addresses A through A+2" (or A through "A+2000"). But you can only do this if your addresses are contiguous.1

In the IP address world, we actually want something a little more than contiguous. We want bit alignment. IP addresses are 32-bit numbers and the way that blocks are expressed isn't by simple ranges but by prefixes. This is easier to write up with 8-bit addresses (0-255). So, when I get a block of addresses in this space, it looks like this: 240/5, which means "all the addresses with the first 5 bits the same as 240. When we write 240 in binary we get: 11110000 (I'm showing the fixed bits in red.). So, this leaves us with 3 bits to play with and they can take on any possible value. I.e.:

11110000
11110001
11110010
11110011
11110100
11110101
11110110
11110111

So, contiguous addresses are good, but packing them efficiently turns out to be a tricky problem, for two reasons:

The end result is that as you start to run out of room you reach a state where you still have empty space but that you can't assign it in as big blocks as you'd like. Incidentally, this situation isn't that different from what happens with dynamic memory allocation for software, although the time scale is a lot shorter in that case.

1. For much the same reason, you see kidnappers in movies asking for nonsequential, unmarked bills.

Posted by ekr at 8:20 AM | Comments (2)

May 20, 2007

Steelcape and Firewall Traversing VPNs

A while back, I received a spam with the following contents:
Send data without opening your ports.

Steelcape has taken an innovative approach to security, instead of trying to repair TCP/IP, we have built a solution inside the TCP/IP protocol. This method allows Steelcape to secure environments without opening ports on the firewall.

The packets are encrypted at 256 bits and signed with a 48 bit digital signature. Also works with IPv6. Please take a look at our website www.steelcape.com

This rang in at about 10W40 on my snake-oil-ometer, but seeing as they'd been kind enough to give me their information, I figured I'd check it out and if it was snake oil, make fun of them publicly.

First, you can check out their Web site, which reiterates their basic claims:

This doesn't really tell you how the thing works, though. Points 2-4 are easily understood, but what does point 1 mean? Not opening any ports? It's not TCP/IP? How does the data get through? Figuring that out required reading their somewhat confusing WP (link omitted because you don't want to give them your name and email address any more than I do), an exchange of emails, and finally a con call with one of the sales/marketing guys and some technical guys.

Making sense of this requires some background on how Enterprise networks, firewalls, and VPNs work. Figure 1 shows the world's simplest firewalled Enterprise network.


Figure 1: A basic firewall configuration

You've got a bunch of hosts on an internal network separated from the Internet via a firewall, which also doubles as the Internet access router. The firewall prevents all connections to the internal hosts from the Internet. Defining what an internal connection is turns out to be a bit tricky, so, let's just talk about TCP here. Your classic firewall forbids incoming TCP connections but allows outgoing ones, at least to some ports. This works fine if you only want to have client machines, but if you want to have servers (e.g., a Web server), you need to do something else. To a first order, you can either punch a hole in your firewall or put the mail server outside your firewall. Actually, people often do both; they run two firewalls, with the web server in between them in what's called the DMZ. The outside firewall has a hole punched in it to allow access to the Web server, but because it's outside the inner firewall there's no need to punch a hole there. Figure 2 shows what I'm talking about.


Figure 2: Firewall with DMZ

This DMZ strategy of course works less well if you want to allow VPN access to your network, since the whole point of a VPN is to allow remote—albeit secured;access to the internal network. Either you make the firewall and VPN access router one and the same or you place the VPN access router inside the firewall, i.e.,


Figure 3: Firewall with VPN router

And, of course you need to have a hole in the firewall in order to let packets to/from the VPN router.

So, this gives us the background for understanding the "no holes in the firewall" claim. The first thing you need to understand is that this is a VPN-only solution: you can't use it to secure access to your public mail server or Web server. Those need to have open firewall ports. So, the idea is that you install Steelcape's stuff on both sides of the system, for instance as an appliance on your home network and then on the laptops of your remote users.

But I've just said that the VPN server needs to be able to talk directly to the Internet. So, how does Steelcape work? There WP says:

In TCP/IP, data is sent though ports, over a network, to a firewall or other network device, and sent on to listening hosts within a businesses infrastructure. This a potential point of exposure, since unwanted packets could end up on host systems. Steelcape leaves hostile data behind at the firewall as enabled by a "pull" architecture. Steelcape-enabled hosts pull packets from the firewall, validate them, and route them on to host systems. If Steelcape does not qualify the packets, they are kept at arm's length from the system and dropped at the firewall. This is accomplished without any sacrifice network bandwidth.

This description sounds initially coherent, but doesn't make sense in light of the claim (in e-mail) that it works with commodity firewalls, which don't have any such buffering or pull built into them. You can't really get this out of the WP, but it turns out that what's going on is that you have a topology like that shown in Figure 4.


Figure 4: Basic Steelcape installation

Whereas your classic VPN installation requires one box at each site, the Steelcape design requires two, one inside and one outside the firewall. The way that this works is that the gateway has a permanent connection tied up to the enterprise server (ES). This connection traverses the firewall. When a remote user wants to VPN in, he contacts the ES and authenticates. The ES sends a message to the gateway over this permanent signalling channel telling the ES that a client wants to come in and the client's IP address. The gateway then uses NAT/firewall hole-punching techniques (like ICE but the Steelcape guys say it's not ICE) to let the remote agent talk to the VPN server (it helps here that Steelcape pushes their traffic over UDP). If this strategy sounds familiar to you, it should. It's exactly the topology used by VoIP systems, with the SIP proxy taking the place of the ES.2 It should also now be clear why this can't work with generic Internet services: they're not set up to contact Steelcape's ES.

This approach has two claimed advantages: security and ease of installation (the other claimed advantages of Steelcape's stuff come from different techniques). In terms of security, it doesn't require that the VPN server be accessible from arbitrary Internet hosts all the time. Holes only get punched for hosts which have been authorized by the ES. Think of this as decreasing the surface area of attack. Of course, the flip side of this is that the ES does have to be accessible from any host. However, it's true that in order to attack the internal network you do need to compromise two hosts instead of one, so if implemented properly this could give you a measure of defense in depth. I'm not really confident it's that enormous, but all other things being equal (i.e., Steelcape's software being equally secure to other people's software), it probably does give you a measure of defense in depth.

In terms of ease of installation, it's certainly true that you should be able to install a Steelcape system without the cooperation of the firewall administrator. This is of course the kind of feature that users love and firewall administrators hate, because (from their perspective) it's far too often used to bypass enterprise security policies.1. Certainly, I would think that most enterprises would want any VPN appliances to have the approval of the firewall admin, so getting him to punch a hole hardly seems that onerous. And on the downside, of course, now you have two machines to maintain, which increases your maintenance effort.

The other major claim, increased performance, derives from Steelcape's use of a proprietary protocol which is allegedly faster than TCP. It was a little hard to work out what the optimizations were, but it sounded like principally it was that they didn't use compression and maybe that they had more aggressive congestion control3 It's certainly the case that you can get improved network performance via link-layer compression, so that sounds plausible, though hardly proprietary. That can of course be done within standard TCP/IP (see IPComp) so there's not likely to be anything proprietary there. And of course as soon as you are doing TCP/IP translation on Steelcape's boxes rather than TCP end-to-end there's lots of opportunity for things to go wrong. So, the "replaces TCP/IP" stuff looks mostly like marketing special sauce to me.

The other thing that probably should make you seriously nervous here is that Steelcape isn't using a standard security protocol (e.g., IPsec, SSL/TLS) but rather something they designed themselves. I didn't drill down on this too far, but apparently it uses Blowfish (a fine algorithm, but generally not a sign of crypto sophistication; the pros use AES) with (according to their product overview) a "48 bit digital signature") which is "randomized every few milliseconds". Since the security of a VPN system fundamentally depends on the crypto in use, using an unevaluated protocol isn't exactly confidence inspiring.

It should be obvious here that it's possible to design a standards-based system that uses the same firewall/NAT traversal techniques used by Steelcape. That would have some advantages and disadvantages vis-a-vis ordinary VPN approaches, plus you'd have a high level of confidence that the security protocol was secure. It doesn't look to me like that's what Steelcape is providing, however.

1. See also draft-saito-mmusic-sdp-ike-00 for a very similar standards-based approach.
2. It's interesting to note that in this case there's no requirement that the ES actually be in the DMZ. It could be some entirely different third party server on the network—after all, this is how SIP works—which puts a somewhat different spin on the above security argument.
3. They also told me that they eliminate the TCP checksum computation so that this sped up intermediate routers. As far as I know, checksum computatations are not a significant part of packet processing overhead.

UPDATE: Ed Felten hypothesizes that the 48-bit "digital signature" is actually a MAC. Another possibility is that it's not data dependent at all; it's just a secret value that gets appended to the packet. That would be consistent with the "randomized every few milliseconds" claim, since a MAC would be different for every packet. Needless to say, if that's what it is, it's not adequate.

Posted by ekr at 8:37 AM | Comments (2)

April 21, 2007

Fanboyism is not a crime!

Apparently the City of Boston's free wireless service has some kind of censorware on it, since it's blocking Boing Boing:

Jake tried to access Boing Boing from Boston's free WiFi network and got this notice -- topped by the seal of the Mayor of Boston no less! Banned in Boston -- first they came for the Mooninites, then they came for the Boingers.

Want to defeat censorware? Let freedom ring!

Update: Seth sez, "The phrase 'Banned combination phrase found' is a characteristic message of the censorware Dan's Guardian. It seems some combination of words has triggered the 'isItNaughty' flag (that's what they call it). It would be an interesting legal case to see if you had the right to file a Freedom Of Information Act for the settings and block logs to find out the exact reason you got censorware'd."

This seems like a not particularly attractive development. Ubiquitous Internet (free or otherwise) is a really cool thing and is going to enable all sorts of applications we've just begun to experience (and of which today's low-speed cellular Internet access is just a pale shadow). But it's going to be pretty lame if that network can be arbitrarily censored by random bureaucrats. I know, I know, this is just the free network: you can always pay for some sort of commercial wireless. That's not really true, though; a taxpayer subsidized free WiFi network is going to make it pretty unattractive for commercial providers to enter the market, so you'll just be stuck with the censored version unless you're willing to plug in somewhere.

Moreover, I'm not a constitutional lawyer (or indeed any kind of lawyer), but it's not entirely clear to me that this is constitutional. The First Amendment requires that government fora have viewpoint neutrality (as a somewhat strained analogy, consider the situation with advertisements in subways, where the government has been forced in at least some cases to allow pro-marijuana reform advertisements once they allowed any advertisements). Given that unlike subway advertisements Web access doesn't require subjecting others to your speech, it would seem that there would be a stronger case that censorship was impermissible here. Stepping back from the constitutional question, it's pretty hard to understand what the rationale for banning Boing Boing is (though I've heard it suggested that it was for making fun of the Great Comedy Central Boston Bomb Scare of 2007, which I suppose is possible, but isn't something you'd want to get out of you were the guy who made this decision.

Posted by ekr at 10:18 PM | Comments (1)

April 19, 2007

On securing (or not) your wireless network

Matthew Yglesias links to Tim Lee's post about wireless networks:
As I argued in an op-ed last year, this is silly. Accessing someone else's wireless network, especially for casual activities like checking your email, is the very definition of a victimless crime. I've done the same thing on numerous occasions, and I deliberately leave my wireless network open in the hopes that it will prove useful to my neighbors.

The only concrete harm opponents of "piggy-backing" can come up with is that the piggy-backer might commit a crime, such as downloading pirated content or child pornography, with your connection. But remember that there are now thousands of coffee shops, hotels, and other commercial locations that offer free WiFi access, and most of them don't make any effort to verify identities or monitor usage. So someone who wants to get untraceable Internet access can go to any one of those establishments just as well as they can park outside your house.

Which isn't to say that there are no reasons people might not want to share their network connections with the world. If sharing your Internet access creeps you out, by all means set a password. And there's almost certainly work to be done educating users so that people are fully informed of the risks and know how to close their network if they want to do so.

So, I certainly agree that piggy-backing isn't much to worry about [*], but that doesn't mean that it's a great idea to run your wireless network completely open. Most home access points are some kind of NAT, which provides a substantial amount of security againt attacks from the Internet, at least primitive port-scanning type attacks. If your machines are properly secured, this isn't necessary, but if they're not—as is reasonably common—then it provides a useful backup.

On the other hand, if someone is on your wireless network, then they will get a private address on the same network block as you and be able to talk directly to your machines, which is a substantially inferior security situation. So, as a belt and suspenders move, it's certainly understandable why one would want to keep people off one's wireless network. This becomes even more true as people start moving hardware that would usually be physically wired onto wireless networks as an alternative to running Cat5 through the entire house.

Posted by ekr at 9:04 PM | Comments (2)

April 4, 2007

Two cheers for universal service

Hillary Clinton is pushing some sort of rural broadband service plan:

The Rural Broadband Initiatives Act. This legislation will extend and improve access to broadband services in small towns across America. It creates a policy and action framework to ensure that the federal government employs an effective and comprehensive strategy to deploy broadband service and access in the rural areas of the United States. The bill will also establish a Rural Broadband Innovation fund to explore and develop cutting edge broadband delivery technologies to reach underserved rural areas. The Rural Broadband Initiatives Act has been endorsed by the Communications Workers of America.

Speaking as someone who suffered with ISDN for years and just cut over to (my only real option) Comcast "business" service at $120/month (a significant savings) in order to get decent speed and some static IP addresses, I've just gone one question: "Palo Alto is rural, right?"

Posted by ekr at 6:36 AM | Comments (4)

April 3, 2007

Airborne WiFi

This is interesting. Aircell is going to offer airborne WiFi:
AirCell paid $31.3 million at an FCC auction last year to take over radio frequency once used for expensive air-phone service and reallocate it to Internet and cellphone service. The Internet service already has the approval of both the FCC and the Federal Aviation Administration. Mr. Blumenstein says AirCell, a closely held Colorado company that provides communications for private jets, is building out its network of 80 to 100 ground towers and talking to multiple airlines. No customers have been named yet.

"It can't happen soon enough," said Henry Harteveldt, a travel technology analyst at Forrester Research Inc.

AirCell will install equipment on airliners that will act as a WiFi hotspot in the cabin and connect to laptop computers and devices like BlackBerrys that have WiFi chips. In all, it will cost about $100,000 to outfit a plane with less than 100 pounds of equipment, and the work can be done overnight by airline maintenance workers, AirCell says.

What makes the service particularly attractive to airlines is that they will share revenue with AirCell. The service will cost about the same as existing WiFi offerings. Mr. Blumenstein says it will charge no more than $10 a day to passengers. It will also offer discounted options for customers and tie into existing service programs like T-Mobile, iPass and Boingo. Speeds will be equivalent to WiFi service on the ground.

At some level this is super-convenient and $10/day is pretty good. I've certainly had plenty of times when I was on the plane and realized I'd forgotten some file and wished I had Internet access. Even lousy Internet access would be pretty convenient in such cases. On the other hand, one of the nice things about being on a plane is that it forces you to actually work on whatever it it is you're supposed to be working on rather than surfing the net. AirCell says they're planning to block VoIP service (it would be sort of interesting to hear exactly how they're going to do that...) but of course there is plenty of interest in cell service, especially in Europe:

OnAir and AeroMobile both install "pico cell" receivers on planes that connect to cellular phones, allowing them to operate at low power to minimize technical problems. The pico cell then routes calls to cellular networks through a satellite link.

Only about 14 calls or fewer can be successfully made at a time per flight, and airline crews can turn the system off during takeoff and landing. If you make the 15th call, you'll get some kind of indication of "no service."

Apparently they're going with a circuit-switched model with admission control, which is pretty old-school PSTN. If people were using Skype, they'd get a quite different experience: as the network got more loaded people would just get worse call quality (dropouts, etc.), but nobody would ever be told "no". This is of course the way that traditional telephony networks work, but as far as I know there's no technical reason you couldn't offer a packet-switched type service that interfaced to the airplane picocell and then bridged back to the GSM network (though you'd need to do something more sophisticated than just pass the media packets back and forth, silence suppression, etc.) That's probably a primarily cultural issue—the providers seem fairly closely tied to the cell phone providers, who are big on this kind of reserved bandwidth system (typically under the name of quality of service).

Posted by ekr at 10:05 PM

March 9, 2007

Remote control airplanes

According to this article Boeing is designing an "Uninterruptible Autopilot System". The idea here is that if the plane is being hijacked you trigger the UAS. Once it's engaged, the plane can't be controlled by the pilot but is remotely controllable from the ground.

It's important to remember here that there are two kinds of hijacking:

This seems to be mostly targeted at the second type of hijacking, since the first type depends principally on people complying under a threat and this threat is at least 95% as credible when the pilot is on the ground as if they're in the air with you. You just threaten someone on the plane instead of the pilot. On the other hand, if your objective is to fly the plane into some building, presumably the flight controllers on the ground won't allow that no matter how much you threaten to kill passengers.

That said, it's not entirely clear that 9/11-style hijacking can work even without this technology. If you're a passenger on a hijacked plane and you expect the hijackers to fly it into a building you've got a pretty good incentive to try to take back the plane regardless of what weapons the hijackers have. As has been often observed, 9/11 was successful because people's responses to hijacking were predicated on the assumption that it was the first type—who had heard of the second?

From a security guy's perspective, the interesting question is what safeguards are in place to prevent accidental activation and control by attackers? Imagine you get your hands on the control unit for an aircraft and can somehow get it put into UAS mode. Congratulations, you've got yourself a remote controlled, manned cruise missile. Presumably there are safeguards in place to defend against this sort of attack. Minimally, one would hope that some sort of cryptography is used to limit control to authorized units. The COMSEC techniques here are of course relatively straightforward.

The second thing you would like would is for it to be impossible to remotely put the plane into UAS mode, thus minimizing the damage from any compromise of a control unit/control unit keying material. For instance, the UAS radio receiver could be physically disconnected until engaged onboard the plane.

Even if proper COMSEC techniques are used, there still is a residual risk if it's possible to jam the signal. In order for the system to work, it needs to be fairly sensitive so that any attempt to take over the cockpit triggers it (hence the proposed pressure sensors on the cockpit door). But this potentially enables an attacker onboard to trigger the UAS while a confederate on the ground holds the plane hostage by jamming the control signal. Again, there are techniques to make signals harder to jam (though the authentication techniques you're likely to use make the control channel very sensitive to errors so you'd need a lot of forward error correction).

I'd certainly be interested in hearing more about the design of the proposed system. p

Posted by ekr at 10:15 PM | Comments (2)

February 25, 2007

Skype and cellular networks (II)

On the Skype/FCC thread on I-P, Brett Glass writes:
The key thing that one must understand -- and this is a bit technical -- is that Skype works by "robbing" bandwidth from its users and their ISPs. Skype does not buy enough bandwidth to route or connect all of the calls placed via its network. At any time, a Skype user who merely has the software running -- but is not making a call -- may be using bandwidth to connect a call that involves neither the user's ISP nor any of that ISP's customers. This is a moderate concern on a land-based network, but is of GREAT concern on wireless networks, which are severely constrained by tower capacity and the scarcity of radio spectrum.

If Skype, by operating on the wireless provider's network, would in effect be consuming the provider's valuable bandwidth and airtime without compensation (which really does seem to be the case), the cell phone company is perfectly justified in saying, "No." We operate a terrestrial broadband network (not a cell phone network), which has more capacity. Nonetheless, we do find that we're impacted by bandwidth-robbing applications and do find that it is necessary to rein them in (though we do not currently ban them).

OK, this is a little technical, but it's not too complicated to explain. VoIP media requires two-way communication flows over UDP. Unfortunately, your average firewall or NAT is not set up to conveniently allow such flows by default. Skype (like SIP VoIP stacks and other P2P applications) includes fairly extensive NAT traversal techniques to let you punch a hole in the NAT/firewall. Unfortunately, those techniques don't always work, especially when both sides are behind NATs. The last ditch approach in such situations is to tunnel all the traffic through a media relay, a publicy accessible machine which is not behind a NAT. In the IETF VoIP universe, it's generally expected that service providers (either ISPs or the voice service provider) will prove the media relay.

Skype has the unusual feature that not some of the clients themselves act as media relays. At least in theory, the system automatically detects that a client has a public IP address and has it advertise itself as a media relay.1 (Because the traffic is encrypted the people making the call aren't supposed to have to worry about this.) The advantage of this technique is that Skype Inc., doesn't need to use as many servers (or as much bandwidth) to operate their own media relays. Obviously, if you have a client which is acting as a media relay, it consumes bandwidth when you're not making a call, which is what Glass is referring to.

That said it's unlikely that a Skype client on a cellular network would end up being a media relay. A good media relay needs reliable high speed connectivity and unfiltered, public, Internet access. None of these really apply to cellular phones. So, while in principle Skype could chew up cellular radio capacity over and above that required to transmit to/from the calling stations, it seems unlikely in practice.

1. I say in theory because a friend of mine set up a Skype client with good connectivity and a public address and didn't get selected as a relay.

UPDATE: Rewrote the last graf for added clarity.

Posted by ekr at 9:02 PM

Skype and cellular networks (I)

Skype has asked the FCC (þ Robert Berger via Interesting People) to require cellular providers to carry their VoIP traffic:
Skype yesterday petitioned the FCC to lay the smack down on wireless phone carriers who "limit subscribers' right to run software communications applications of their choosing" (read: Skype software). Skype wants the agency to more stringently apply the famous 1968 Carterfone decision that allowed consumers to hook any device up to the phone network, so long as it did not harm the network. In Skype's eyes, that means allowing any software or applications to run on any devices that access the network.

The reason for Skype's interest in the issue is obvious: they want to force network operators to allow Skype-enabled calling across their networks, something currently prohibited on wireless data plans. In its filing, Skype argues that this capability would offer "tremendous new sources of price competition provided by entities such as Skype," and that's exactly why wireless operators will fight the plan tooth and nail.

The standard perception here is that there's a generic network and the providers use QoS to block third-party VoIP applications. There's an element of truth here, especially for conventional wireline Internet services. But for cellular the situation isn't as simple as that.

So, the first thing you need to know is that older digital cellular networks (pretty much everything before 3GPP IP Multimedia Subsystem) aren't generic packet switch networks like the Internet. They're specialized voice channels. They do have some generic Internet functionality, but it's mostly an add-on overlay on the older voice network—the same way that you layer IP traffic over an old voice network with PPP (except that this is digital-on-digital).

Performance of these systems isn't that great. First, the bandwidth is really inconsistent (even when you nominally get 14.4k it's bursty). Second, it consumes a lot of power. The reason for this is a but subtle: voice transmission is extremely predictable and the phones and networks are able to make a bunch of channel control optimizations (slotted scheduling and variable-width channels being big ones) to minimize power consumption. This sort of tight control requires having the part of the system close to the radio having a lot of knowledge of the network dynamics of the protocols being run over top. In my Treo, for instance, you get 3+ days in voice mode and less than a day in Internet mode, even if you're sending and receiving almost no data.

IMS is a little different, but the problems are similar. In principle 3G phones have more or less generic IP service and provide it to the applications on the phone. IMS is VoIP (SIP + RTP + some custom IMS stuff) and runs over that service. That's true, but in order to make this work efficiently there's actually tight integration between the VoIP system and the IP stack in order to efficiently make use of the air interface. While there is a lot of QoS on 3G networks, it's not solely for the purpose of blocking 3rd party applications, but also for making the native applications work well. So, while in principle you could run generic VoIP over the IP network, it's not clear how well it would really work.

So, if all this is right and Skype wouldn't work well anyway over a neutral channel, what's Skype really want? That's not clear. One possible theory is that it's negotiating leverage. Of the four major wireless carriers, Cingular/ATT and Verizon both operate wireline Internet service and T-Mobile operates a network of hotspots. Requiring neutrality through those networks would be valuable and asking for a lot more might be a way to get it.

Ackowledgement: Thanks to Cullen Jennings for discussions and explanations of some of the issues in this post.

Posted by ekr at 8:40 PM

December 29, 2006

Where to find the Internets in YVR

Sitting in the YVR Maple Leaf Lounge this morning I reflexively looked for wireless access, but of course it way a pay hotspot. But on my way to the bathroom I noticed that they have a table with a bunch of chairs and Cat 5 cables attached. Plugging in, it turns out that there's quite workable—though a bit slow—Internet access. Worth knowing.

Posted by ekr at 8:41 PM | Comments (1)

December 13, 2006

More quantum cryptography hype

Hack report has an interview with MagiQ CEO Bob Gelfond in which he claims that quantum cryptography is almost ready for prime time:
What's the standard price for the appliance and what is included?

For a point-to-point encryption you need a system that consists of 2 appliances - sender and receiver. The cost is around $100k, plus support depending on your needs.

When do you think we'll see service providers offer quantum cryptography services to their end-customers?

This will happen within one year and we'll see fairly wide adoption within the next three years. We are working with big carriers such as Verizon and AT&T as well as some companies that own fiber networks. The goal is to embed quantum cryptography into the technology infrastructure so it becomes totally transparent to the end-user. For example, if you are already leasing a fiber line, you can then add an extra level of security by activating the quantum service. The whole thing won't be disruptive to your infrastructure and it can sit on top of whatever you are using now. Since it won't interfere with your existing technology you can have a fall back mechanisms to switch back to whatever you have today.

The important thing to remember is that the security guarantees of quantum key exchange (such as they are) only apply when you have a direct link between point A and point B--i.e., if you're renting a fiber from AT&T between two offices. They don't apply if the data is being packet switched, such as in the kind of MPLS-style virtual cirtuit that people typically buy (because buying a dedicated fiber is too expensive). So, if AT&T sells you a QC-protected line, it just goes to one of their routers. Of course, AT&T could have a QC-link for each hop, but that's not an end-to-end security guarantee. You now have to trust each router in every data center.

Moreover, the current limit on a QC link is about 120 km. After that you have to use repeaters, which creates another potential point of compromise.

Apart from the usual high assurance customers, do you see any other industries that can benefit from (and justify) a quantum cryptography solution?

I think so, anyone who has to store and secure records for a number of years will benefit from it. One strategy eavesdroppers can deploy is to capture everything they can get their hands on. Even if they can't decrypt it today, they might be able to do that in a few years down the road. So the only way to defend against that is to use quantum cryptography. You have to make sure it's not just secure today but also going forward. Take healthcare for example, they have an obligation to protect my healthcare data forever. The real threat is that while theoretically current systems might be impossible to crack, the reality is that keys are not flipped frequently enough or might not be stored securely. All that can be used by an attacker to start a brute force attack. So if you have enough repeats it might just take them a couple of days to break them. And many companies do not flip their keys very frequently since it's a time-consuming task. In contrast if you deploy our system -- keys get flipped every few seconds -- automatically.

This argument confuses several points. What you have to know is that quantum cryptography systems like MagiQ's are actually used as what's called "quantum key exchange" mode. The bit rate of the quantum cryptography system isn't high enough to carry data so you use it to exchange keys which are then used in a conventional cipher like AES to encrypt the actual data. So, in that respect, QC systems are quite a bit like a conventional cryptographic protocol like SSL/TLS or IPsec, but with the QKE replacing the Diffie-Hellman/RSA/whatever.

Gelford's claim here is that the attackers are going to get their hands on (either by capturing off the network or getting access to your stored data) your encrypted data and mount a brute force attack on it in the future. In order for this to be plausible, one has to assume one of three things:

Case 1 is exactly the same for QKE and conventional systems, since however you exchanged the keys you have to store them somehow. In fact, if you establish a lot of unrelated keys frequently then in some sense this makes the situation worse because you need to store them somewhere that has a lot of space which makes using really secure storage methods more difficult. This is one reason people tend to store their keys under some master key. So, there's a tradeoff here that doesn't clearly favor QC.

Cases 2 and 3 are sort of the same. In both cases we assume you don't have the keys but you do have the ciphertext. Now, there are two major reasons why in this attack model you might want to use a lot of keys rather than one. The first is that old-style ciphers (e.g., Enigma) were often easier to attack if you had a large amount of ciphertext or ciphertext/plaintext pairs. I think this is what Gelford means when he talks about repeats. This isn't really true for any modern algorithm except when the amount of ciphertext gets really huge (~1010 bytes for DES, ~1020 bytes for AES). This only really applied to analytic attacks in any case. In a brute force attack, one or two plaintext/ciphertext pairs are enough. The other reason you'd want to use a large number of keys is to slightly increase the attacker's work factor. If he has to attack 100 keys rather than 1, then it's 100 times harder for him. Mostly, if you get to the point where the cipher is so weak (case 3) that you have to worry abot this you need a new cipher and QKE isn't going to help you much.

The other weird thing about this argument is that conventional systems are quite capable of rekeying frequently and if you use Diffie-Hellman, there's no real concern about exposure of long-term keys. Sure, people don't typically rekey their IPsec or SSL connections frequently, but it's a simple software change and certainly quite a bit more convenient than buying a bunch of gear from MagiQ.

Posted by ekr at 10:26 AM | Comments (1)