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.

During my time working in the Networking Services department at UT Dallas, I gave a presentation for the EDUCAUSE community about the work I did to transition our wireless LAN security from the static WEP security in place at the time to the more enterprise friendly 802.1X based security that it uses today.  I first gave the presentation live at the EDUCAUSE Southwest Regional Conference held in Austin, Texas in February of 2005.   After the live presentation, I was approached about giving this presentation to the larger international EDUCAUSE body at one of the (then) upcoming EDUCAUSE Live! web seminars they do every month.  I, of course, jumped at the opportunity, and gave the seminar on April 25, 2005.  It’s hard to believe that it’s been just over three years now.

One of the things that I liked about the EDUCAUSE Live! events was that, in addition to being a live web event, they were also archived so that viewers could benefit from the information in previously recorded sessions.  The Live! folks recently switched from the streaming system they were using before, based on Horizon Wimba, to a new system based on Adobe’s Acrobat Connect.  In the process, they unfortunately broke the links to all of the archives from the Horizon Wimba days.  This presentation still comes up when when I talk to folks about network security, as it’s a very good primer to what 802.1X is and how it works, so I still like to refer people to it when I can.  The good news is that the archives are actually still alive, just not readily accessible without instructions, so I thought I’d post the instructions for getting to my presentation here.

First of all, you can get to the information on the presentation and the PowerPoint slides by going to http://www.educause.edu/LIVE058 and clicking on the View Event Archives link at the top left.  To get to the full audio/video archive of the presentation, follow these instructions:

• Point your browser to the EDUCAUSE Live! Horizon Wimba Server
  
• Click on the Participant Login button
• Enter “educause” (without the quotes) in the Login ID field, and put anything in the Name field
• Once logged in, the Wimba service will run through a wizard to make sure you have all of the necessary components installed to run the presentation
• After finishing the wizard, you will be taken to the main Horizon Wimba window, click on the Archives tab
• Scroll down to the link titled “2005/04/25: Mike Griego, Wireless Security with 802.1X” and click on it to begin the presentation

Take a look if you’re at all curious.  If your organization is looking to implement enhanced security for your wireless LAN, whether it’s being required of your organization by privacy statutes such as HIPAA, or you simply need to be assured that your network and data are safe, Nearband Networks can work with you to achieve that goal.  We have years of experience under our belts that we can use to ensure that your wireless network is secure while also making the transition as smooth as possible for your users.

As part of our community network management service offering (a mouthful, I know - we manage a number of community WiFi networks), we sometimes have to employ measures to insure that some users don’t overrun the network with malware infections, peer to peer file sharing applications, etc. Instead of limiting what people are allowed to do on the network, like some ISPs have been getting heat for lately, I tend to prefer limiting how much they can do. I personally don’t care, and I don’t think that other ISPs should care, that a person is using Bittorrent, as such applications do have completely valid uses. I do care, however, if the use of that application, or an infection of some kind, is causing other users of that same network to suffer. So, this week I set out to employ the connlimit iptables match to help limit to some degree how many connections a runaway application can create through the firewall at one of our networks. Unfortunately, the process of getting to the point where I could include connlimit rules in my iptables configuration was not an easy one, so I thought I’d do my own writeup here to help those who may be looking for how to do something similar.

In most of my Linux systems, I use the Fedora distribution. Its free, easy to install, has much of what I need in the stock systems, and usually has a good combination of stability and the newest versions of packages. Unfortunately, as I discovered very quickly after my research in to how to best handle the connection limiting problem in iptables, the stock Fedora systems (Fedora Core 5 in this case, but its still true in Fedora 7 at least) do come with the iptables module for connlimit matching, but they do not come with the matching kernel module. So, I was going to have to roll my own kernel that included the connlimit module. Luckly, kernel building is not something I have to make a habit of since the kernels that come in all recent Linux distributions usually meet my needs. Sometimes, like in this instance, though, I do need to add modules that aren’t included in the stock kernels (and lately, those cases all seem to revolve around various network requirements). The issue here was that patching the kernel was not a simple matter.

The Netfilter folks have put together a system by which people can patch their Linux kernels with any of the netfilter modules they need. It’s called patch-o-matic. Unfortunately, much of the documentation on the Netfilter website relating to patch-o-matic is old and out of date. In fact, they’ve switched to the newer patch-o-matic-ng, but the link for the new patch-o-matic-ng system referenced the Netfilter Extensions HOWTO. This HOWTO, however, says nothing about the new patch-o-matic-ng, instead talking about the old system that no longer works or is even downloadable from what I can tell. It took quite a bit of digging through newsgroups, etc. to discover that the problem is that it appears that the Netfilter folks never started building and publishing new documentation from their source repository after switching to Subversion. The currently published documentation on the Netfilter website still references CVS revision numbers, but the current documentation is now kept in Subversions in it original SGML form and does not appear to be getting built into the HTML and other versions for public consumption. So, if you’re looking for the documentation for patch-o-matic-ng, you’ll have to peruse the original SGML formatted documentation, and the new HOWTO is available here.

So, finally having the correct documentation in hand, I proceeded. Given that the machine in question was still running Fedora Core 5 and was located on the west coast, making an update to a newer revision not completely feasible, it took some digging to find a mirror for the older distro’s source RPMs. Upon finding one, I grabbed the source RPMs for the latest kernel and iptables, as you’ll need both to work with patch-o-matic-ng. Here’s where the documentation’s usefulness comes to something of an end. If you, like me, are going to build a new RPM to apply to the system, you’ll have to apply the netfilter patches to a kernel, then use that to create a patch suitable for the RPM building process. To do this, you’ll need to run through several steps:

1. Install the kernel and iptables source RPMs, then run an rpmbuild -bp <specfile> on each of the kernel and iptables rpm spec files. This runs through the RPM build “prep” stage which unpacks the stock source and applies the patches that come with the source RPM. This is important so that you come away with clean patches for building your RPM. If you were to patch against a stock kernel, your patches may be difficult to apply when combined with the source from the source RPM that has already been somewhat patched.
2. Now that you have a fully prepped source tree, which will be located in /usr/src/redhat/BUILD/kernel-<version>/linux-<version>, make a backup copy in the /usr/src/redhat/BUILD/kernel-<version> directory, so that you have an original tree with which to make your own patches from.
3. Armed with the fully prepped source tree and a pristine backup of it, run through the patch-o-matic-ng instructions to apply the patches you need to the kernel tree. Be sure to feed it the paths to your prepped kernel and iptables sources in the BUILD directory. Also, if you’re looking for the connlimit patch, as I was, you’ll have to perform a ./runme –download followed by a ./runme external, a procedure which isn’t really documented in the HOWTO.
4. Now that you’ve patched your kernel tree with the Netfilter patches, create your patch files by running diffs between your backup tree and your newly patched tree. For me, this was a two step process, since the netfilter patching created some new files. Here’s what I ran (my backup/pristine source tree was in /usr/src/redhat/BUILD/kernel-2.6.20/linux-2.6.20.i386.old, and I had cd’d into the patched source directory of /usr/src/redhat/BUILD/kernel-2.6.20/linux-2.6.20.i386):
   1. for i in `find . -type f`; do diff -u ../linux-2.6.20.i386.old/$i $i; done > /tmp/connlimit.patch
   2. diff -u /dev/null net/ipv4/netfilter/ipt_connlimit.c >> /tmp/connlimit.patch
   3. diff -u /dev/null include/linux/netfilter_ipv4/ipt_connlimit.h >> /tmp/connlimit.patch
5. You now have a patchfile that can be used with your RPM building. You may have to doctor your patch just a bit to insure the directories referenced will work with your Patch statements you add to the spec file. Do any doctoring you need, then move the patch into the /usr/src/redhat/SOURCES directory.
6. Next, you’ll need to edit the .config files that are used to configure each kernel build (because there are a number of kernels that are built from that one source RPM). They’re located in the SOURCES directory, and each has a name similar to kernel-2.6.20-i586.config. In each one, add the line CONFIG_IP_NF_MATCH_CONNLIMIT=m. This will cause the new connlimit module to be compiled as a module.
7. Now you’re done. You can try to build your new kernel. You’ll need to specify your architecture on the rpmbuild line, so, in my case, I ran rpmbuild -bb –target i686 /usr/src/redhat/SPECS/kernel-2.6.spec. The i686 target for this kernel builds 19 separate RPMs, so the process takes quite a while (like 6 or so hours in my case). When its done, though, you should have the kernel you are looking for with your new iptables match modules in place.

The effort required was more than it should have been, in my opinion, but it was well worth it. I’m now able to limit the number of connections each user can create. The iptables man pages included some information to get you started, but there are some things that aren’t completely intuitive. First, each iptables rule does its own connection counting. You might figure this out if you look at other people’s rulesets, but no one seems to come out and say that. What this means is that you can set up rules for, say, different ports and the connlimit module only does matching in that case for that rule. The connection matching for that rule does not affect matching for any other connlimit rules. This was nice for me, because I was able to severely limit the number of outbound SMTP connections (to stop spambots from being able to create hundreds of simultaneous connections), but kind of lump everything else into a “you get so many connections before you can’t create anymore”. One other gotcha to keep in mind is that the connlimit kernel module keeps its own cache of connections (part of the reason you can apply different connection limits to each rule). As such, though, if a machine currently has a high number of connections prior to applying the connlimit rules, those pre-existing connections will not get counted against the limit for that client.

In the end, as I mentioned before, it took more effort to get this working than it should have, but it was well worth it, and tt has been satisfying to see the rules, especially the SMTP rules, have a positive affect on the availability of network resources - and hopefully cut down on the number of spam complaints we get.