Comments on the Smith Report By C. H. Lindsey. Introduction ------------ Public discussion of the ramifications of this report seems to have generated more heat than light. All sorts of scenarios have been posited based on the "vacuum cleaner" facilities alleged to be included in the report, and backed up by quotations of sound-bites which have been far removed from their contexts. A model ISP ----------- Let us postulate an ISP Isaac, who has 4 routers, 1 in Aberdeen, 1 in Glasgow and 2 in London. He has 3 NASs (Network Access Systems), one in each of those cities. He has an authentication server in London. He has a direct line to a large company Dodge in Glasgow. Clearly, this is a very simple minded ISP setup (reality is much more complex), but it will do for illustration purposes. Interceptions ------------- The interception warrant may just say "catch all emails (or IP packets) to/from Bob". For practical purposes, this needs to be translated into all traffic to/from whoever logs in to an Isaac NAS with Bob's userid and password, or perhaps any login on a telephone line which exhibits the CLI of Bob's telephone, or if Bob has a direct line (or if Isaac has provided him with a static IP address) then any IP traffic to/from Bob's IP address. Precisely how Bob is associated with one of those "interception targets" is a matter for discussion between Plod and Isaac's interception officer. Smith does not address this (merely hints at it). When Bob dials in to Isaac (usually, but not necessarily, to the NAS in Aberdeen), Isaac sends the login data to its authentication server in London, and back comes Accept or Reject, plus an IP number to be used for the ensuing communications. Mostly, this IP number will be dynamically allocated from the London server, but sometimes (and always with some ISPs) it will be a static one permanently associated with Bob. It may be more complex if Bob is located inside Dodge. Smith seems to suggest (3.8.12) that Dodge has just one IP address. This is nonsense. Dodge likely has a large intranet with an IP address for each machine on it. So Plod will need to identify the IP address of the machine on Bob's desk, and tell Isaac to intercept on that. But then again, Dodge may allocate internal IP addresses dynamically, or translate them dynamically as they pass through its firewall. But all of that is Plod's problem, not Isaac's (Plod can always try serving the warrant on Dodge, but Dodge is unlikely to have the facilities to do much about it, unlike Isaac who has been required to install such facilities by the Secretary of State). Smith proposes three possible interception regimes which an ISP might (be required to) implement, known as "active", "semi-active" and "passive". These names have been carefully chosen to sow the greatest confusion in the minds of conspiracy theorists. Active interception ------------------- This is the cheap and cheerful option, aimed at catching Bob's email only (but that is probably 95% of what Plod is likely to want). Suppose Isaac runs a couple of email servers in London (punt1.isaac.net and punt2.isaac.net) and suppose that they run sendmail (yech!). Then, to intercept Bob's email, you "just" edit the sendmail.cf on punt[12] to single out mail to/from Bob and divert it via a special mailer that takes a copy of it and forwards it to Plod. Quite simple really :-) . Or similarly for other MTAs, or maybe you do the active interception at the point where Bob's mail enters the POP3 mailbox system (though his outgoing mail would not pass that way). Observe that if Bob does not want his mail to be caught, he just has to arrange that his correspondents use direct SMTP to his machine (not easy with incoming mail, especially with dynamic IP addresses, but quite straightforward with outgoing mail). Smith appears to believe (Table 6.3) that there will be zero cost to the ISP in writing the necessary scripts to cause Bob's details to be entered into sendmail.cf. Experienced sendmail.cf hackers might find this a little surprising. Observe one benefit of the Active system (which Smith did not note) is that it will be much easier to intercept Bob's traffic in this way than when Bob is otherwise hidden inside Dodge's firewall. But then, again, if Dodge is permanently connected, then Bob's email will probably go straight to Dodge by SMTP, bypassing punt[12]. Semi-active interception ------------------------ This is intended to catch all Bob's IP traffic, including everything that was missed in the Active system. But it still won't work when Bob is inside Dodge, unless Plod is able to obtain a warrant to access everything to/from Dodge's main email server(s). One snooping box will be attached to, or close by to, one of Isaac's London routers. This will select IP packets to/from identified IP addresses and send them down a secure line to GTAC. It is then Plod's problem to inspect the IP packets, look at their port numbers, discover what TCP connections have been made using what protocols, and choose those bits he is interested in. There is a working figure of 1 in 10,000 of Isaac's customers being liable to interception, so the pipe to GTAC need only be fat enough to carry one ten thousandth of Isaac's total throughput. Smith seems to be thinking in terms of 6 ISDN lines-worth even for the largest ISPs (Table 6-7, 6-8). The question is how do you get all the "selected" traffic to pass by that one router in London? The answer is that you hack your routing tables so that the targeted traffic is always routed that way or, equivalently, you use Policy Based Routing (PBR) in your routers, if they offer that option, and if it includes the ability to choose routing based on both source and destination addresses in packets. So if Bob (in Aberdeen) contacts www.dodge.co.uk (in GLasgow), his packet is routed Aberdeen - Glasgow - London - Glasgow (I assume Isaac has no direct line from Aberdeen to London, and that he somehow manages to avoid looping on the Glasgow - London - Glasgow bit). Smith estimates that implementing the necessary facilities to configure such PBR on an ISPs routers would take one man month (MM) (Table 6-7). Some might argue that units of MMM would be more appropriate :-) . The next question is how you make this work if Bob's IP address is dynamically allocated (there is no problem if it is static). For this, Isaac has to hack his authentication server so that, whenever it allocates an IP address to a targeted subscriber such as Bob, it immediately informs all the relevant routers (notably those adjacent to each NAS) to start routing that IP address via London. Or, more likely, it allocates the IP address from a special pool of IP addresses that are permanently routed via London. It also needs to notify the snooping box, so that Bob's packets can be filtered out of the total stream. It will be ensured that subscribers are not able to determine whether or not their traffic is being forced past the snooping box (5.5.8). Smith allows 2 man weeks (MW) for hacking the authentication server (Table 6-3 footnote 3, and Table 6-7). Passive interception -------------------- This is similar to the above, except that it does not involve doing anything special at the authentication server, hence the oft-quoted and as oft-misunderstood phrase "the selected subscriber traffic identification component is included within the interception unit and has no interface with CSP systems", which simply means "no interface with the authentication server". Thus leaks of sensitive warrant information are less likely to occur, though it is admitted that it will miss some of Bob's packets that would have been caught by the semi-active method. When Bob has a static IP address, this scheme is no different from the previous one. It is the handling of the dynamic IP addresses that is different. First, it requires a lot more snooping boxes - at least one at each NAS. And the snooping boxes now listen, not only to the targeted addresses, but also to the traffic between the NAS and the authentication server (which, of course, also consists of IP packets, most likely using the RADIUS protocol). And so the snooping box now gets to know what the authentication server has decided, without ever having had direct contact with it. And, armed with this information, it can arrange what packets to intercept. It seems to be the case that there is already some software around (somewhere between here and the West Country, I dare say) that can be adapted to do this job. BUT this snooping box is still only extracting one ten thousandth of the IP packets passing it by, and the total bandwidth between Isaac and GTAC is still only about 6 ISDN lines-worth. So this is no vacuum cleaner. And it still has to be parametrized with the identity of the targets to be intercepted, and an interface with some part of the CSP's systems WILL still be needed to set up those parameters. Smith seem to think that a high end UltraSPARC fitted with a couple of ATM cards will be sufficient to scan all the IP traffic passing a given point and to extract the one ten thousandth required. Perhaps someone else might care to comment upon this. Smith also seem to think that the passive method will be too cumbersome for large ISPs (too many snooping boxes to watch over) and they think that the semi-active approach is better in those situations (7.5.3.6, 7.5.4.7). For a small ISP, the passive approach is thought to be better insofar as you just connect the snooping box beside the main NAS and leave it to get on with the job (no need to tinker with the authentication server). Selection --------- It is quite clear throughout the Smith report that the snooping boxes only "select" what they have been told to select. Their primary function is filtering. So who controls them? Again, in spite of the conspiracy theorists, and in spite of whatever the government might actually do on the night, the Smith report clearly intends that the ISPs should control them. It is fully envisaged that warrants will come into the ISP's sphere of responsibility (Fig 5-1). ISP staff will be involved in handling warrants (6.6.26); "ISP administration staff will be responsible for warrant implementation, updates to tasking information and feasibility checks". There is budgetary provision of one man day (MD) to set up and administer each warrant (Table 6-12) - that is the only effort estimate in the whole report that I actually believe. Moreover, as I have pointed out elsewhere (Scenario 24), it would be unlawful for an ISP _not_ to be in control of the selection parameters for the snooping boxes. Communication Data ------------------ The Smith report is totally silent on this issue (it was not in their remit). As to whether the semi-active and passive mechanisms could help in achieving the collection of such data, there has been much wild speculation. But, as I have indicated, snooping boxes can only do what they have been told to do (by the ISP). In particular, if Plod wants real time access to who Bob is sending packets to, then the snooping box could do this, but it would have to be programmed to strip out the content of the IP packets, leaving just the address data. Note also that the Smith report is concerned solely with IP packets and their addresses. The only mention of looking inside at the TCP/UDP/port information is in connection with identifying RADIUS packets for the purposes of the passive method (5.5.1.2).