I usually try to steer clear of political issues.  In areas where politics and technology cross paths, and perhaps collide in a blinding flash of light, I must make my two cents known.

I’m from the great state of Texas.  Until the other day, I had no opinions on one senator from Texas, Senator John Cornyn.  That all changed on Friday when I read this article on CNN.  Sen. Cornyn is the sponsor of Senate bill S.436, a bill to “…amend title 18, United States Code, to protect youth from exploitation by adults using the Internet, and for other purposes.”  While the stated purpose of this bill is fundamentally good, at least one provision in the bill is very bad.  I find child exploitation as utterly despicable as the next person, but I cannot get behind this bill from a technological and pragmatic perspective.  What’s my beef with this bill?  Take a look at Section 5 of the bill, entitled “RETENTION OF RECORDS BY ELECTRONIC COMMUNICATION SERVICE PROVIDERS.”  There has been much buzz going around the Internet since this first came to light, but I wanted to share my thoughts on the issue.

What Section 5 of this proposed bill states is this: “A provider of an electronic communication service or remote computing service shall retain for a period of at least two years all records or other information pertaining to the identity of a user of a temporarily assigned network address the service assigns to that user.”  In non-legalese, what does this mean?  Lets look at three very important parts: “temporarily assigned network address,” “provider of an electronic communcation service,” and the two year requirement.

First up: “a temporarily assigned network address.”  In the context of the bill, this most definitely refers to any IP address assigned temporarily, via DHCP, PPP, PPPoE, or other IP address assignment methods.  OK, so the government is wanting DHCP, etc. logs kept for at least two years.  Why?  Because it is considered “information pertaining to the identity of a user.”  Here’s the catch:  one of those assignment methods, the one in most wide use, may not carry with it the ability to identify a user.  The culprit: DHCP.  DHCP in and of itself is incapable of truly identifying a user.  With PPP or other authentication-based methods, the provider at least has the ability to see what account was used to access the network resource in question.  The only real identifying information with DHCP, though, is the hardware, or MAC address, of the network interface requesting the address.  As most IT professionals and hobbyists know, this information is easily discovered and manipulated.  Take a scenario such as this, a scenario that has long been used by security analysts:  User Joe is going to use the WiFi network at his favorite coffee shop.  He opens his laptop and associates his WiFi adapter to the coffee shop’s WiFi network, which causes his laptop to request an IP address via DHCP.  For ease-of-use, the coffee shop uses a widely deployed method of access: open WiFi network with a web based captive portal for access.  In theory, once User Joe has logged into the captive portal the portal would have a record of his identity from his authentication plus information from his DHCP transaction, including the temporarily assigned network address (IP address) and his MAC address.  Now, lets say that User Bob intends to perform nefarious acts on the Internet and is looking for a way to cover his tracks.  Knowing how easy it is to spoof a MAC address, he sets up his laptop in the same coffee shop as User Joe and begins monitoring the WiFi network.  User Bob’s sniffing activities uncover that User Joe is actively using the Internet from an authenticated account.  Any captive portal worth its spit will make sure that any traffic allowed through it matches what it knows for the MAC address and IP address of an authenticated user.  User Bob knows this.  So User Bob, using software built into many operating systems, sets the MAC address and IP address of his WiFi adapter to match that of User Joe.  User Joe may or may not realize that anything has happened, but most likely unbeknownst to him, User Bob is now masquerading as him performing his nefarious acts.  This is where the identity information breaks down.  User Joe stands to be falsely incriminated for acts he did not commit.  This is also how the vast majority of public access WiFi networks operate.  Those that don’t make use of a captive portal, or any authentication mechanism for that matter, have absolutely no real identity information to go on.  If law enforcement were to obtain DHCP records for such nefarious activity in this case, and even if they were able to track down the MAC address obtained from those records to an actual user, they would have no way of knowing whether the user they tracked down was actually the culprit.  This doesn’t even take into consideration the case where the true culprit does not use DHCP and just manually sets an IP address on the network in question.  No DHCP logs exist in this case.  As I mentioned before, DHCP is the most prevalent method for assigning IP addresses.  It is used on every broadband router on the market to assign addresses to its clients, by many broadband ISPs including cable, WiFi, and DSL, and just about every corporate, private, and government network in existance.  The only other mechanisms in real widespread use are PPP-based methods, such as dialup Internet access and PPPoE as used by broadband ISPs not using DHCP.  The only way around this is for a network that employs DHCP to also employ per-client authentication and encryption mechanisms such as Enterprise-level WPA2.  Now, WPA2 Enterprise, as used in WiFi does not, in and of itself, keep bad people from configuring the IP address manually, therefore not using DHCP, but it does make certain that every user on the network has individually authenticated and that the MAC address tied to that user has not been changed.  Even so, this is only capable of unequivocally identifying a perticular user when combined with logs of actual Internet connections as taken from the local network segment, where the MAC address is available for such logging.  This has been a very technical explanation, but it shows why DHCP records, in and of themselves, are not adequate for proving the identity of a perpetrator.

Next up is the “Who”:  “A provider of an electronic communication service or remote computing service.”  It took me some time to locate any even semi-accurate definition of this term.  Unfortunately, the original section of Title 18 that this bill is trying to amend does not define what or who a “provider of an electronic communication service” is.  To find a definition, I had to look to court rulings.  According to this page in the EFF’s Internet Law Treatise, referencing several court cases on the matter, including United States v. Mullins, 992 F.2d 1472, 1478 (9th Cir. 1993), a “provider of an electronic communcation service” is not limited to a traditional service provider, such as a Telco or ISP.  It covers any entity who may provide access to these services.  It is still unclear for certain whether individuals fall under this moniker, but given the wide definition used by the courts in various cases, it is entirely likely that individuals who provide Internet access do indeed fall under the umbrella of such a provider.  What does this mean in real terms?  Anyone who has a Internet connection and uses an off-the-shelf broadband router, or any Internet connection sharing technology (such as the Internet connection sharing features built in to Windows, Mac OS X, Linux, or even such a device as an iPhone with the briefly-available Netshare application) would be required to comply with this new records retention law.

Finally, we come to the two year requirement.  For Internet usage records (logs), especially in situations where the service is provided for free, two years is an extremely long retention requirement.  Most true ISPs will have no real trouble complying with such a requirement, since the logs can be compressed and archived to save storage space, and ISP equipment is designed to generate and keep such logs.  Given the above, however, requiring such logs for the purpose of identification may not even make any sense since such logs may not be capable of proving, beyond a reasonable doubt, the identity of a perpetrator.  Beyond that, though, is the fact that most equipment in use by smaller entities, such as home users, libraries, coffee shops, and most small businesses, is not even capable of keeping such records, or, if it is, configuring the equipment to do such retention is beyond the technical capabilities of the users of such equipment.

When I put all of this together, I came to a very unfortunate conclusion.  Most people or businesses that could potentially be affected by this law will actually be completely incapable of complying with it.  By enacting this bill into law, the lawmakers have essentially placed almost every broadband user in the United States in danger of being incriminated by not complying with this law.  And for what?  Will this portion of the bill truly assist in capturing those that would exploit innocent children?  No, unfortunately not.  This portion of the bill will actually serve to incriminate more innocent citizens than it will catch pedophiles.

This is a prime example of why poorly-researched laws can be problematic for everyone.  Such ludicrous requirements can also have the unintended side effect of stifling broadband deployment.  If would-be broadband providers are unduly burdened by such ineffective laws, they will be less likely to roll out new broadband services.  In a way, this may even fly in the face of President Obama’s broadband deployment initiatives.

Maybe its just me, but I expect any tier 1 data center that I or my clients use to be able to handle a power outage, and I mean a full power outage. As you may or may not know, Rackspace experienced a severe outage yesterday. A truck collided with the main power transformer outside their building severing them from the grid. According to their statement, they switched over to their backup power feed, but the power company was turning that feed on and off in order to assist the first responders trying to rescue people from the accident scene - totally understandable. What’s not understandable is why Rackspace didn’t have enough generator capacity to run its chillers as well as the machines, or if they did, why they didn’t execute on that. Anyone who runs equipment rooms knows they must have proper cooling, or the machines located in that room will self destruct in very short order. So, it stands to reason that it does no good to have generator backup in case the power is cut if you can’t run your chillers off of that generator system as well. You’ll just be running your machines literally to death.