WISPA CALEA Compliance Guide
CALEA Compliance Guide for WISPs
Copyright © 2008 Wireless Internet Service Providers Association (WISPA.org)
by Butch Evans, Mike Erskine and J.C. Utter
May 30, 2007 Initial public release posted to WISPA website
January 25, 2008 Revised and updated to comply with WISPA CALEA IPNA Standard
April 25, 2008 Revised and updated to include overview of general CALEA requirements
October 10, 2008 Final editorial review for publication with WISPA CALEA IPNA Standard
1. Introduction and Usage
1.1 This document provides guidance to WISPs that wish to comply with WISPA-CS-IPNA (WISPA CALEA Standard for Internet Protocol (IP) Network Access – hereafter referred to as “WCS”). The WCS can be used by wireless and wireline service providers for Intercept compliance. However, this guide is targeted toward WISPs who want to achieve CALEA compliance under the WCS. In addition, WISPs that offer VoIP services using a VoIP gateway located on an internal network will have additional compliance requirements that are not addressed by the WCS.
1.2 This document does not constitute or define any compliance standard. In addition, following the guidelines contained in this document does not assure “safe harbor” protection under the WCS.
1.3 While every attempt has been made to ensure that this document is both accurate and complete, it is possible that some network designs are not covered by this guidance. In all cases, it is the WISP’s responsibility to ensure compliance as defined by CALEA and the WCS.
1.4 This document describes “best practices” for CALEA compliance using the WCS, including general intercept methods and techniques, locations within a Network for data Interception, storage specifications, and transmission requirements of the intercepted data.
1.5 This guide explains how to achieve Intercept compliance and why specific steps are required.
1.6 This document describes the kind of equipment required to deliver an Intercept to the Law Enforcement Agency (LEA), as well as the formatting and methods required to support delivery of an Intercept to the LEA in compliance with the WCS.
1.7 This guide covers both technical and non-technical aspects of CALEA compliance. However, it is not an exhaustive reference on CALEA compliance. This document specifically addresses the technical requirements for CALEA compliance using the WCS, including guidance for the design of compliant networks or the redesign of existing networks to comply with the WCS.
2.1 CALEA (Communications Assistance for Law Enforcement Act) – A federal law passed in 1994 under the Clinton administration that defines the statutory obligations of telecommunications carriers (including WISPs) in the United States to ensure that their equipment, facilities and services that provide a customer or subscriber with the ability to originate, terminate or direct communications, are capable, pursuant to Lawful Authorization, of
- isolating and intercepting all of the electronic communications of a subject;
- isolating and intercepting all call-identifying information that is reasonably available in the network contemporaneously with the transmission of electronic communications in a manner that allows it to be associated with the communications to which it pertains; and
- delivering intercepted communications content and call-identifying information to the LEA.
2.2 Call-Identifying Information/Communication-Identifying Information (CII) – Dialing or signaling information that identifies the origin, direction, destination, or termination of each communication generated or received by a subscriber by means of any equipment, facility, or service provided by a telecommunications carrier.
2.3 Communication Content – Any and all information concerning the substance, purport, or meaning of a Subject/Target’s communications.
2.4 Downstream Network – The portion of the network where a WISP’s direct control ends and a customer’s network begins.
2.5 Electronic Surveillance – The monitoring or Interception of communications such as Communication-Identifying Information, Communication Content, or both, for a particular customer/subscriber pursuant to Lawful Authorization.
2.6 Intercept/Interception – See “Electronic Surveillance.”
2.7 Law Enforcement – Any officer of the United States or of a state or political subdivision thereof who is empowered to conduct investigations, make arrests, or otherwise enforce and ensure compliance with the law.
2.8 Law Enforcement Agency (LEA) – Any agency of the United States or of a state or political subdivision thereof that enforces the law, including local or state police, and federal agencies such as the Federal Bureau of Investigation (FBI) and the Drug Enforcement Administration (DEA). It is an LEA that will deliver the Lawful Authorization to a WISP for action.
2.9 Lawful Authorization – An order or other form of legal authorization (e.g., Pen Register/Trap and Trace Order, Title III Order, etc.) issued by a court or other authority with legal jurisdiction to authorize the Interception of all or specific categories of Subject/Target communications. The Lawful Authorization will contain information on the Subject/Target of the Interception, the Subject/Target Facility, Intercept time frame, and other information specific to the investigation.
2.10 Network – The portion of the infrastructure that is controlled by the WISP seeking compliance.
2.11 Network Element – Equipment that is addressable and manageable, provides support or services to the user, and can be managed through an element manager. A group of interconnected network elements form a network.
2.12 Out-of-Band (OOB) Signaling – OOB Signaling is the communication between the Target’s access equipment and the WISP’s Network Elements that occurs before network traffic can begin to flow. OOB Signaling typically consists of the Layer 2 network communications that are required to assign an IP address to the Target’s access equipment.
2.13 Pen Register/Trap and Trace Order – A form of Lawful Authorization that authorizes the Interception of information contained in the electronic communications of a Subject/Target via a Pen Register or Trap and Trace device or process (as defined in 18 U.S.C. §§ 3127(3) and (4)).
2.14 Sniffer/Packet Sniffer – A program that can “capture” network communications and either store them locally, send them via a streaming protocol to a remote server where they can be reviewed immediately or stored, or in some cases both.
2.15 Subject/Target – An individual who is the object of a Law Enforcement or LEA investigation and whose communications have been authorized by a Lawful Authorization to be intercepted and delivered to an LEA.
2.16 Subject/Target Facility – The equipment, facilities or services of a Subject/Target, as identified by a unique identifier (e.g. the Media Access Control (MAC) or IP address associated with the Subject/Target), and listed in the Lawful Authorization that initiated the Interception of the Subject/Target’s communications.
2.17 Subject/Target Traffic – All communications and IP data traffic, included data that is transmitted or received by the Subject/Target, that is transported by the Subject/Target Facility identified in the Lawful Authorization.
2.18 Tap – Historically, a “tap” or “wire tap” was a hardware device used for transparently intercepting and recording communications over an analog telephone circuit. In this document, two types of Taps are described: one is a hardware device that performs the same function on a data network, and the other is a software Tap that performs a similar function using software running on an in-band Network Element. For example, a Packet Sniffer that runs on a Linux-based Network Element (e.g. ImageStream, Mikrotik, StarOS, etc.) is a software Tap. A hardware Tap is a device that connects to the physical network line to passively tap and transmit electronic communications to a recording or relaying device. A passive hardware Tap, such as those produced by ImageStream or Net Optics, are examples of hardware taps.
2.19 Title III Order – A form of Lawful Authorization that authorizes the Interception of any and all information concerning the substance, purport, or meaning of a Subject/Target’s communications.
2.20 Upstream Network – This is the Internet, or more specifically, the upstream service provider’s network. This is the network location known as the demarcation point or “demarc,” where a WISP’s network ends and the WISP no longer has direct control over the Network Elements.
2.21 WISP – A Wireless Internet Service Provider.
2.22 WISPA-CS-IPNA – An intercept standard created by WISPA (with input from the FBI) to provide a “safe harbor” for WISPs who follow this intercept standard for CALEA compliance.
3. CALEA Compliance Overview
CALEA specifies a wide range of compliance mandates that include both technical and administrative requirements. As a result, compliance with the WCS alone is not sufficient to achieve full compliance with CALEA. WISPs should not rely on this guide as their sole reference for CALEA compliance; CALEA itself is the ultimate reference for legal compliance. In addition, WISPA recommends that all WISPs consult competent legal counsel as part of any compliance plan.
Some of the compliance areas addressed by CALEA include confidentiality, authentication, validation, confirmation, transparency, isolation, completeness, compression and encryption, buffering, fan-out, reliability, intercept content, time stamps, warrant ID, and recordkeeping. This section provides a brief overview of these CALEA requirements.
Confidentiality is an important issue for conducting intercepts. CALEA requires that only “authorized” personnel can know that an intercept is being performed, including information in the warrant that identifies the Target of the Intercept. Confidentiality also applies to the LEA, and information provided in a warrant issued by one LEA such as the FBI cannot be shared with another LEA such as the Department of Homeland Security (DHS) or DEA. In addition, if multiple Intercepts are being delivered to multiple LEAs simultaneously, the delivery of one Intercept to one LEA must be confidential so that is cannot be detected or discovered by other LEAs.
Confidentiality can also be an issue when it comes to network configuration and management. The System Security and Integrity (SSI) plan that WISPs must file with the Federal Communications Commission (FCC) identifies the contact that will be used for serving intercept orders to the WISP. This contact person is clearly authorized to have access to Intercept details and the associated equipment configurations.
However, CALEA does not specify how additional individuals can be legally authorized to have access to this information. Therefore, it is not only important for the named SSI contact to keep Intercept details confidential from other LEAs, staff, and private individuals, but it is also important to protect unauthorized system administrators from viewing intercept configurations.
3.2 Authentication, Validation and Confirmation
Authentication, validation, and confirmation are three critical components of the process that ensures an Intercept will be correctly associated with the Target. Dynamic Host Configuration Protocol (DHCP), changes to customer accounts, and other network events can disrupt a Lawfully Authorized Intercept. The WISP is responsible for these potential issues, and must manage them accordingly.
“Authentication” ensures the Target is correctly associated with the IP or MAC address used to identify the Target. Authentication may involve confirmation that the Target correlates to an IP or MAC address by looking at an internal document where static IP or MAC addresses are recorded and assigned, or it may require the use of a Remote Authentication Dial In User Service (RADIUS) server log that keeps track of what IP address is assigned to the Target. The methods for ensuring that an Intercept is associated with the correct Target during Intercept initialization will vary from network to network, but the WISP is responsible for ensuring the Intercept is correctly associated with the Target. “Validation” is similar to authentication except that it ensures the Intercept is correlated to the Target throughout the entire Intercept.
“Confirmation” is used here to mean the WISP can prove the Intercept was correctly associated with the Target of the Intercept after the Intercept has been completed. This process may involve keeping records of the IP or MAC addresses assigned to the Target, or it may involve keeping RADIUS or other authentication logs to confirm that the Intercept was correctly associated with the Target during the entire collection period.
With capture-to-disk Intercepts, such as those required by the WCS, files are also created to ensure the captured content is not modified by someone after the intercept is performed. The names of these hash files must be correlated to the capture files, and records must be kept so it is possible to confirm at a later date that each hash file is associated with the correct capture file or files. Intercept records that include copies of hash files must be kept confidential, and must be stored for at least 5 years, or as specified by the LEA.
“Transparency” under CALEA generally means the Target cannot detect that an Intercept is being performed. Service parameters such as bandwidth, latency, and availability must not be impacted in any way by the Intercept.
In networks with dynamically assigned IP addresses, it is unacceptable to reserve a separate block of IP addresses for Intercepts, and then assign one of those addresses to the Target in response to an Intercept order. It is also unacceptable to change the network configuration in any way that can be observed by the Target. This means you can’t install equipment for an Intercept that changes the number of hops the Target Traffic must traverse to reach the Internet.
There are several “grey areas” of transparency that may or may not be perceived as a compliance issue by the LEA. For example, some WISPs have reported that in the process of working with an LEA, they were allowed to increase the lease on DHCP-assigned IP addresses for all customers to ensure the Target’s lease did not expire during the Intercept period. This example is anecdotal, and may not be allowed by all LEAs because changes in the DHCP lease can be detected by the Target. Another similar approach is to use a mechanism like RADIUS to statically assign the same IP address that the Target is already using under an existing lease to reliably map that IP address to the target. Again, this kind of change to the network configuration could be detected by the Target, so it should only be used if the LEA has specifically approved such a method.
The installation of a hardware Tap is another example of a network modification that may be acceptable to the LEA. Most trusted third parties (TTPs) who offer just-in-time service to support Intercepts are shipping hardware Taps and probes that must be installed on the WISPs network. While the hardware Tap is being installed in response to a court-ordered Intercept, and the network is being interrupted and modified by installing a network Tap and probe, the interruption cannot be identified by the Target as being related to an Intercept, and the Tap and probe that are installed cannot be detected by the Target when installed. This method is used widely and is known to be acceptable to most LEAs. Even so, you should always check with your legal counsel and the FBI before you implement an Intercept plan that includes methods that are not completely transparent, such as just-in-time installation of a passive hardware Tap.
“Isolation” is the process of filtering the Target’s Traffic from other network traffic that is not authorized for Intercept by the court order. Unfiltered network traffic must be filtered down to the Target’s Traffic based on the Target’s MAC or IP address. Different individuals may actually use the Target’s access equipment and account, but the WISP is only required to isolate
the Target’s IP and/or MAC address and correlate it to the Target’s account information.
The WISP is responsible for ensuring that the communications Intercept is complete, and includes all of the Target Traffic that moves to and from the Target during the period of time covered by the Intercept order. Communications with the LEA will need to be established to report any anomalies or failures that may affect the completeness of the Intercept.
3.6 Compression and Encryption
In general, Intercepts must not be compressed or encrypted. If Target Traffic is compressed or encrypted as a normal part of the network services provided by the WISP, then this traffic must be decompressed or decrypted before it is delivered to the LEA.
“Buffering” is used here to mean the ability to retransmit an Intercept should any problems occur with delivery to the LEA. The WCS employs a store-and-forward methodology that ensures the original Intercept will be stored on a local file server, and can be retransmitted to the LEA if there is any problem with delivery.
“Fan-out” is the ability to deliver one or more Intercepts to multiple LEAs simultaneously. Most software Taps support this capability by running on a multitasking operating system that can run multiple instances of the Tap software. Be sure to plan for the additional upstream bandwidth or disk space you will need to support multiple simultaneous Intercepts.
Intercept reliability is vital to the LEA’s ability to utilize Intercepts as evidence in court cases against terrorists and other criminals. Intercept reliability is so important, it cannot be left to rely on the average reliability of the Internet. This is why the WCS adopts a capture-to-disk approach that buffers the Target Traffic on the local Network so a successful Intercept is not reliant on the real-time conditions of the Upstream Network or the Internet.
In addition, Network reliability issues are not limited to the Upstream Network or Internet. Therefore, it is important to understand potential reliability issues on your Network. In general, it is always best to perform an Intercept at an interface on the Network that is closest to the Target. WISPs should be especially careful not to depend on unreliable wireless connections to backhaul traffic to a buffering device at a central location. If the buffering device is not located at the point-of-presence (POP) closest to the Target and the Intercept is incomplete due to data loss, the LEA may determine that the WISP is not CALEA compliant because the Intercept methods aren’t reliable.
3.10 Intercept Content
Intercept content can be broken down to in-band and out-of-band (OOB) traffic. Out-of-band traffic in an IP network generally refers to the communications that take place between the customer and service provider equipment before an IP address is assigned to the customer’s access device. In-band traffic refers to the data stream that can be associated with an IP address.
Some service provider networks use statically assigned IP addresses with no OOB signaling. These networks can perform an intercept based on the target’s IP address without concern for capturing OOB traffic, which is really just Layer 2 traffic. Service provider networks that use DHCP, RADIUS or some other dynamic method for assigning IP addresses to customers must use the Target’s MAC address as the basis for the intercept, otherwise the OOB traffic will not be captured. Depending on the system, Intercepts may be configured to capture traffic based on MAC address and IP address for the same intercept, so this approach is recommended as the most reliable way to set up an Intercept when you know the target’s MAC and IP.
The content of an in-band capture depends on the court order. Some orders will specify the Intercept content to be packet headers only, while others will require the full content of the Target Traffic to be delivered. These different Intercept content options will require different configurations for software Taps like tcpdump and OpenCALEA.
3.11 Time Stamps
To comply with CALEA and the WCS, Intercepts need to be time stamped so they can be correlated to events in the outside world. Compliant software will time stamp each packet as it is received, which makes this function relatively easy to support.
Time stamps are only as accurate as your system clock, so it is recommended that the equipment used to perform the Intercept should be synchronized with a reliable time source such as the U.S. Naval Observatory Directorate of Time, the timekeeper for the U.S. and North America. Most systems will use the Network Time Protocol (NTP) for synchronization. When the clock for the system running a software Tap is synchronized to the Directorate of Time, the time stamps that are provided in your Intercepts will be relevant and useful to law enforcement.
3.12 Warrant ID
When you set up an Intercept, the configuration will require a warrant ID (also known as a “case ID”) that uniquely identifies the Intercept and associates it with the case. When an Intercept is configured to use a warrant ID, the Tap software must embed the warrant ID in the Packet Capture (PCAP) file so the LEA can correlate the Intercept data with the proper law enforcement case.
In general, it is recommended that you keep records of the Intercepts you perform for at least 5 years, unless you negotiate a different period of record retention with the LEA. Records should include court documents, hash files from disk captures, and all written communications to and from the LEA.
There are many reasons why you might be required to communicate with the LEA regarding an Intercept. For example, you may negotiate to report OOB traffic using your DHCP or RADIUS logs. If this is the case, be sure to filter out non-targeted traffic from the OOB reports, and store copies of those reports for the required period of time. Virtual Private Network (VPN) and other types of authentication event logs may also need to be reported, stored, and kept confidential. In addition, Intercept problems, account and service changes, and even Quality of Service (QoS) modifications associated with the target may need to be reported, and these reports should also be stored and kept confidential.
4. Lawful Authorization
An LEA will serve a WISP with the appropriate Lawful Authorization identifying the Intercept Target, the communications and information to be intercepted, and the service areas where the communications and information are to be delivered. Once this Lawful Authorization is served on the WISP, the WISP must perform the specified Interception over the specified period of time, and provide for the delivery of the intercepted communications and other associated information to the LEA storage facilities or equipment. This authorization may require the Interception of all Target Traffic and OOB/CII to and from the subject, or it may only require a subset of this traffic, such as time stamped packet headers.
5. Network Design Considerations
Because CALEA covers a wide range of compliance requirements, every network design choice made by the WISP may be important, and these choices will affect how and where within the Network the specified communications and information can be intercepted and collected.
5.1 Access Point Configuration Considerations
Wireless access points (APs) support direct communications between two wireless clients. To comply with CALEA, WISPs must understand the capabilities of their APs and the supported configuration options.
Most APs have a parameter that will enable or prevent clients on the same AP from communicating with each other directly. Common names for this parameter include interclient communications, interBSS relay (StarOS and some other Linux-based APs), and forwarding (Mikrotik). It is also possible that the AP will refer to this parameter as something else.
For APs that cannot performs Intercepts, this forwarding option must be set to prevent communications between clients, or the WISP will not be able to Intercept Target Traffic between clients using the same AP. The Packet Sniffer in StarOS and Mikrotik will not see data transmitted between two clients on the same AP unless they are on different IP subnets. It may still be difficult to perform Intercepts directly on APs that support it, so it is still recommended that forwarding be turned off so another Network device can be used to perform the Intercept.
5.2 Bridged, Switched, Routed, and Dynamically Routed Networks
5.2.1 Bridged vs. Switched Networks
The term “bridge” can be confusing, so its use here is limited to a MAC-layer bridge that forwards packets based on the MAC addresses of the connected equipment. Under Linux and other operating systems, a MAC-layer bridge broadcasts inbound traffic to all interfaces until one of the devices responds with the destination MAC. Once a device responds on a specific interface, the bridge caches the MAC address of the responding device and associates future traffic destined for that MAC address with the same physical interface.
A Layer 2 Local Area Netework (LAN) switch uses the same logic as a software bridge to forward packets, but it uses special application-specific integrated circuits (ASICs) to forward packets between physical interfaces. This means that both switches and MAC-layer bridges learn about what devices are connected in real time, and then dynamically change the flow of packets based on Layer 2 communications.
A common way to perform an Intercept is to use a mirror port on a LAN switch where the Target Traffic is flowing, and then filter the traffic and package it for delivery to the LEA. Similarly, an operating system like Linux that performs MAC-layer bridging may also support the use of a software Tap that can perform the Intercept. With switched and bridged Networks, it is essential to perform the Intercept at the “first hop” interface, which is the last interface controlled by the WISP that faces the client. Failure to perform the Intercept at the last Target-facing interface can result in Intercept failure when the switch or bridge redirects traffic to another interface that bypasses the Intercept point. In addition, pay close attention to any virtual LANs (VLANs) used on the Network, because VLANs can hide traffic, and they can affect how traffic is forwarded.
The interface closest to the customer is the only interface that can be relied on to carry all Target Traffic. In most WISP networks, this location is the Target-facing AP. If the AP is configured to prevent forwarding between local clients, local traffic on the AP will be routed to the next device, normally via Ethernet. It is this next device that must be capable of performing a lawful Intercept compliant with the WCS. Alternatively, a passive hardware Tap can be installed in this location, and the output from the Tap can be connected to another device that will perform the required filtering and delivery.
5.2.2 Routed Networks
In a routed Network, packets transmitted by interconnected hosts are forwarded by Network Elements called “routers” until the packets reach their final destination. Packets are forwarded to the next upstream, downstream, or peer router, depending on the entries in the router’s routing table. The routing tables are configured to create Network traffic flows that achieve the service provider’s goals for the network.
In statically routed IP networks, each packet follows a predictable path because the routing tables do not change. As long as the Tap point can see 100% of the Target Traffic, that Tap point will provide a valid location to perform the Intercept. With most IP networks, the Target’s IP address can be correlated to the Target at any location throughout the network, and so many different Tap points could theoretically be used.
Service providers should consider the risks and efficiencies associated with performing Intercepts at different locations in the Network. Tap locations including the Network Operations Center (NOC) and the remote POP that provides service to the Target may see 100% of the Target Traffic, but there are always additional risks associated with moving the Tap and storage points away from the Target.
For example, some service providers plan to locate a single Tap at the Internet gateway for their Network. Using an Internet gateway as the Tap location can add several levels of complexity to a successful Intercept. On the surface, many Network designs allow clients to communicate directly with each other over the same AP or between two POPs in the same network. In these Networks, local traffic will never reach an Internet gateway, and the Internet gateway will never see 100% of the Target Traffic, which renders it an invalid Tap point.
It may still be possible for some small Networks with a single POP to perform reliable Intercepts at an Internet gateway. In this case, all Network traffic (i.e. all traffic local to the APs, all traffic between the APs, and all Internet traffic) must be routed across the Tap point. In larger networks, this approach is impractical or impossible. So the ideal plan for most networks is to install Intercept-enabled equipment at the remote POPs to ensure all Target Traffic will be collected before any routing decision is made.
There may also be times when the ideal Intercept location cannot be used. A routed network still makes it possible to use Tap points that are upstream to the Target-facing interface. Depending on the Network topology, IP-based Intercepts performed at the head-end, on a strategic backhaul, or by an Internet gateway could all be CALEA-compliant if 100% of the Target Traffic crosses the collection point, and there are no OOB events like DHCP or Point-to_Point Protocol (PPP) authentication being used by the Target.
Note that with the WCS, a safe harbor can only be achieved when OOB events like DHCP and PPP authentication are reported using the specified Extensible Markup Language (XML) framework. Even so, if you cannot collect OOB traffic from the Target-facing interface, a methodology may be negotiated with the LEA that moves the Tap point upstream, and uses filtered logs to report OOB events. This would not provide a safe harbor under the WCS, but it may still offer an effective compliance option that is acceptable to the LEA.
In most cases, it is either impossible or impractical to move the Intercept location away from the Target-facing interface. Consider a remote tower location or POP where the Target connects. Local traffic across the AP is not being forwarded, so that traffic is routed off the AP where it can be intercepted. If the Tap point is moved away from the POP where the Target connects, then all the local AP traffic would have to be backhauled to the head-end of the network where the Intercept can be performed (before the traffic is finally routed back to the originating POP). This unlikely strategy wastes valuable bandwidth, and it adds new points of failure that could make Intercepts less reliable. A better approach would be to locate the Tap at the POP closest to the Target, and then backhaul the Intercept data to a collection server at the head-end of the Network. This would make Intercept reliability dependent on backhaul reliability, but it puts the Tap point at the best possible location, which eliminates many Intercept pitfalls.
Some WISPs operate networks that have both routed and bridged segments. In all cases, the last customer-facing interface is always the best location to perform an Intercept.
5.2.3 Dynamically Routed Networks
In a dynamically routed Network, packets may follow different paths to multiple Internet gateways depending on the network configuration and prevailing conditions. Like statically routed networks, packets in a dynamically routed network are forwarded to the “next hop” based on the router’s routing table. But with dynamically routed networks, the active routes in the routing table may change depending on different conditions. Therefore, it is always a good idea to understand how dynamic routing works if an Intercept is performed on a dynamically routed Network at a location that is upstream from the Target-facing interface.
In most cases, full mesh networks are dynamically routed using Open Shortest Path First (OSPF), Multi Protocol Label Switching (MPLS), or a similar internal routing protocol. If the Target Traffic can only take two paths out of the associated POP, then it may be possible to set up two Intercept points on the two upstream routers. With more interfaces leaving the POP, more Intercept points might need to be added. This approach introduces unnecessary complexity and points of failure to the Intercept, so it is always best to avoid this when possible.
Whether the Network is switched, bridged, routed, or dynamically routed, lawful Intercepts will always be the most reliable when they are performed at the last Target-facing interface in the Network. Under conditions where it may not be possible to use the last Target-facing interface, the Intercept may still be performed at an upstream location assuming OOB/CII event delivery is also handled in a CALEA-compliant manner. In dynamically routed networks, however, this may require an IP-based Intercept to be set up on each Internet gateway or on multiple backbone routers.
5.3 Tunnels, Virtual Private Networks (VPNs) and Encryption
If the service provider employs tunneling or VPN technologies within the Network, those data treatments must not be present in the Intercept data that is delivered to the LEA. In addition, if WPA is used to encrypt wireless links, the service provider must provide the LEA with decrypted data. Tunnels, VPNs and encrypted connections can render certain Tap locations useless, so the Tap point for an Intercept should be located in a place where the Target Traffic will not be tunneled or encrypted. Tunnels or VPNs that are created and controlled by the Target do not require any special attention by the service provider, other than ensuring that 100% of the Target Traffic is collected.
5.4 Network Address Translation (NAT)
In its most common application, Network Address Translation (NAT) is a firewalling technique that maps multiple private IP addresses to a single public IP address. When NAT is used in a service provider’s network, it is necessary to perform all lawful Intercepts on the private side (or downstream side) of the NAT. All private IPs share a single public IP address on the public side of a NAT point, so it is impossible to filter out a single IP address on the public side.
5.4.1 NAT on Access Points (APs)
An AP that uses NAT can make Intercepts difficult to perform. If the AP does not support lawful Intercepts, and it does not include an option to disable NAT, it may be impossible to perform a compliant Intercept. Alternatively, if the AP supports disabling NAT, then this may be the easiest solution. If the Network must still perform the NAT function, then it may be possible to move the NAT point away from the AP so the NAT can be performed upstream, and the NAT point will not cause problems with the Intercept. In this way, the Intercept can be performed at a location in the Network where the Target can be correlated with a single IP address, and the Network traffic can be filtered down to that IP address.
5.4.2 Hot Spots
Many hot-spot devices use NAT. The same Intercept issues that apply to NAT in a traditional service provider’s Network also apply to hot-spot Networks. For these devices, you may or may not be able to isolate a specific Target, and the “NAT exemption” provided in Version 1 of the WCS may be needed to secure a safe harbor.
In addition to NAT issues, hot-spot Intercepts require the same kind of correlation between the Target and the Target’s MAC or IP address. One exception to this is a Network that provides free public Internet access. Be sure to work closely with the LEA to negotiate an acceptable Intercept methodology when the service you are providing does not require user accounts, as might be the case with a free hot-spot Internet service.
5.4.3 Non-compliant Equipment
Section 106 of CALEA requires equipment manufacturers to support their customers’ CALEA compliance needs. Unfortunately, not all manufacturers are in compliance with Section 106, and some have never developed products or product updates that allow their customers to comply with CALEA.
A common example of this occurs with a franchised Internet service that uses low-cost APs that are hard-wired to perform NAT. NAT cannot be disabled on this AP, and it cannot disable forwarding between local clients either. So there is only one place where a CALEA-compliant Intercept could be performed, and that is onboard the AP itself. In this case, the manufacturer never developed onboard Intercept capabilities for the AP, so there is nothing the WISP can do to make the device compliant beyond lobbying the manufacturer to develop Intercept support for the AP—or replacing the AP altogether.
There is good news for those who operate APs that cannot disable NAT. The WCS comes in two versions that supersede each other: Version 1 provides a safe harbor for service providers with APs that cannot disable NAT, and Version 2 eliminates this special “NAT exemption” after 12 months. Version 1 of the WCS allows Intercepts to be performed on the public side of a NAT point where it is impossible to filter Target Traffic, if and only if the device does not support other compliance options, there is no other location on the Network where a compliant Intercept can be performed, and the only remaining option for compliance is replacement of the non-compliant equipment.
6. Network Management
Service providers must begin preparation in advance of receiving the Lawful Authorization to perform an Intercept. This is particularly important for compliance with CALEA’s transparency requirements, but service providers may also be deemed non-compliant in any area where the service provider is not adequately prepared. There could be many ways to accomplish full CALEA compliance with a given Network, but the service provider must make these preparations before being served.
6.1 MAC Address Records
To properly correlate MAC-based Intercepts to a specific Target, the service provider must record and maintain MAC address information for each customer. Some network management systems can perform this function for the service provider, and will store the MAC address for the equipment provided to each end customer. If the customer uses a manually assigned IP address without PPP authentication, DHCP, or some other IP assignment mechanism, it may be possible to perform a compliant Intercept without knowing the Target’s MAC address.
In most service provider networks, IP addresses are assigned using a Layer 2 mechanism, and the associated Layer 2 events will either need to be captured and delivered in the proper XML format for full compliance with the WCS, or logs for DHCP or RADIUS will have to be filtered and delivered to the LEA as an alternative that is not specified under the WCS. Under these conditions, it is critical that the Target’s MAC address be accurately recorded and available when a Lawful Authorization is received.
6.2 IP Address Records
To properly correlate IP-based Intercepts to a specific Target, the service provider must record and maintain IP address information for all customers. With equipment that has a manually assigned IP address, this can be done by hand in a notebook or in a computer file that gets updated when new IP addresses are assigned to customer equipment.
In most service provider networks, IP addresses are assigned dynamically using DHCP or RADIUS. Even when the XML reporting standard from the WCS is followed, it is recommended that the unfiltered logs from these systems be archived to ensure the intercepted IP address can be correlated with the Target. Changes to the Target’s IP address during an Intercept may cause the Intercept to fail, so it is critical to use sufficiently long lease times or statically assigned IPs to ensure the IP address of the Target is not reassigned to another customer in the middle of an Intercept.
Like MAC address records, IP address assignment events can be reported to the LEA using the WCS XML framework, which is required to provide a safe harbor. Alternatively, the method for reporting IP address assignments to the Target’s equipment can be negotiated with the LEA so that filtered logs can be used to correlate the IP address to the Target. This method does not provide a safe harbor under the WCS, however it may be the easiest solution if you do not have software that reports OOB events in the XML framework specified by the WCS.
Service providers are allowed to alter their Network configuration before receiving a Lawful Authorization. Network alterations may be required to ensure a reliable Intercept of DHCP and other OOB events. The service provider should not expect the LEA to allow reconfiguration of the Network once an Intercept order has been served. This is not allowed in most cases.
6.2.1 DHCP and Dynamically Assigned IP Addresses
Under normal DHCP operation, the DHCP server assigns an IP address from the available IP address pool to the customer premise equipment for a fixed period of time called the “lease.” With this common approach, the DHCP server will only have information on the MAC address of the equipment that was assigned the IP address, so the service provider must have a record of the MAC address associated with each customer. Once the MAC address is documented for all customers, the DHCP server can provide a list of the “current” leases that can be used to determine the IP address of a Target when you receive a Lawful Authorization.
6.2.2 DHCP and Statically Assigned IP Addresses
Most modern DHCP servers support the assignment of a static IP address to a specific MAC address. The main advantage of this method is that the lease for the IP address is effectively permanent, and there is no chance that the DHCP server will be assigning a new IP address to the Target while an Intercept is being performed. With statically assigned IP addresses, the DHCP server still uses the MAC address of the customer’s equipment to assign the IP address, and so this method will still require the service provider to keep records of the MAC address associated with each customer account.
6.2.3 DHCP and RADIUS
Some DHCP servers support the ability to authenticate users and assign an IP address to the Customer Premise Equipment (CPE) using a RADIUS server. A RADIUS server is essentially a database that holds customer account information including a user name and password, and information on how IP addresses will be assigned to customers using DHCP. When DHCP works with a RADIUS server, the RADIUS server determines whether a static or dynamic IP address is assigned to each customer, and how long the lease will be for dynamic IPs.
With DHCP and RADIUS, the IP address space can be managed from a central RADIUS server. In most cases, RADIUS makes it easier to maintain the required Intercept records that are used to associate an IP or MAC address with a specific Target. If the service provider is already running a RADIUS server, and the DHCP server already works with RADIUS, this approach is recommended over other options because of the additional records, control and security the RADIUS server provides.
7. Equipment Selection
Service providers have many different equipment types and manufacturers to choose from as they deploy their networks. Before CALEA, service providers could adopt a network design and the associated equipment without concern for having a Tap point that can see all traffic to and from a specific customer. This is no longer true.
There are many designs and equipment choices available that make compliance easier. The information that follows is not an endorsement of a particular product or manufacturer, but is intended to give some guidance in selecting gear that can be used to build compliant networks.
7.1 Access Points (APs)
The most important AP feature is the ability to Intercept or reroute communications between local clients using the AP. If you can’t Intercept the AP’s local traffic, then your Network and Intercept plan are not compliant with CALEA or the WCS.
If the AP will be bridged, then you can expect all of the APs traffic to be accessible for Intercept at the next device in the Network that is connected to the AP. In most cases, when the Target connects to this AP, the AP or the next connected device is the best location on the Network to perform the Intercept.
If the AP will be configured as a router, you may want to look for a product that directly supports the Intercept function. There are a number of APs currently on the market that already have this feature built in, or are in the process of adding this capability.
If the AP needs to run NAT, then it also needs the ability to run the Intercept directly. WCS Version 1 allows networks that cannot disable NAT on APs to be protected with a safe harbor. However, this exemption is only available for a limited time, and any new equipment that you install should be capable of full compliance with the WCS Version 2 that eliminates this exemption after 12 months.
7.2 Customer Premise Equipment (CPE)
Like APs, some premise gear has the built-in capability to perform a CALEA intercept. Many Linux-based Network devices have this capability today by storing files locally, streaming the data to a storage repository on the Network, or streaming the data directly to an LEA collector.
If the Target does not have administrative access to the CPE and your CPE has a built-in Sniffer, you may want to collect the data directly at the CPE. It is critical that any configuration changes you make do not affect the way the Target perceives the Network. Doing so would break the transparency requirement.
In general, we do not recommend using the CPE Intercept option, because there are additional issues that must be addressed, and many devices do not support this capability. The option is worth mentioning, because for some service providers, it could provide the easiest way to capture of 100% of the Target Traffic without any concern for the Network topology.
7.3 Infrastructure Equipment
The part of your infrastructure that is neither CPE nor AP may also have the ability to perform a CALEA-compliant intercept. If your Network configuration supports the collection of required data at one of your backbone routers, this may be the best plan because these devices will often have more processing power, which may be needed depending on the Network load and packet-processing overhead. An Intercept-enabled router can sit behind the AP, perform the Intercept, and route local traffic back to the AP without wasting any bandwidth over a backhaul link.
8. Data Collection and Delivery
CALEA does not specifically define a data delivery format. The data delivery format is specified in industry standards like the WISPA CALEA Standard for IP Network Access (WISPA-CS-IPNA). The WCS was designed with input from the FBI to provide an Intercept delivery standard and safe harbor for wireless and wireline service providers that do not operate in-network VoIP services.
The following describes the preferred methods for data collection and delivery to the LEA as specified by the WCS. Service providers are reminded that data to be collected in an Intercept must be specified in the Lawful Authorization. How that data is collected and delivered will depend on the Network design and the equipment used in the Network.
As described in earlier sections, the Target Traffic must be filtered so that Network traffic from other users is not delivered to the LEA. This includes OOB and CII event reporting.
8.2 Software, Data Formats, and Final Delivery
When a standard like the WCS is released, there may be no software available that fully complies with the standard. The WCS is already ahead of this curve, because software like the PCAP library and tcpdump are freely available including source code. The WISPA CALEA committee worked very hard to leverage widely deployed software like tcpdump.
Unfortunately, some CALEA requirements were impossible to support with existing software. For example, some versions of tcpdump may need to be updated to support time stamps. The entire XML framework for reporting OOB events may also need to be implemented in relevant applications like dhcpd and pppd, or as part of a Sniffer like tcpdump or OpenCALEA.
So where does this leave WCS compliance? In networks with no OOB or CII events, it is possible to achieve full compliance with a safe harbor. In networks that have OOB and CII events, a safe harbor with the WCS is not possible until the required software is released.
Even so, the WCS can be used as a CALEA compliance standard for those points that can be achieved practically. The remaining points of compliance, like OOB event reporting that is not supported by currently available software, will have to be negotiated with the LEA so both parties can agree on a delivery format and method before the Intercept begins.
8.2.1 Software & Data Formats
For Intercepts of broadband communications under the WCS, the data should be buffered on a file server and collected in the PCAP file format with all CII and OOB events stored in a file that is separate from the Communications Content. Standard Linux distributions, many Linux routers, and many Linux-based APs have a built-in capture facility that can store data in PCAP format.
The PCAP format is an industry standard file format that contains captured network communications. OpenCALEA, tcpdump, and other applications support the required PCAP format, but at the time of this writing, none of these applications could produce the XML required to deliver OOB/CII reports. As a result, this point of compliance would need to be negotiated with the LEA.
As a negotiated alternative for delivery of OOB/CII events, the logs from different systems that generate these events can be filtered to include only those events that pertain to the Target. For example, if an IP address is assigned by a DHCP server, then the logs from that DHCP server would be used. Log filtering may be performed under Linux with custom scripts or a utility such as grep. The LEA should be willing to accept this alternative format, or recommend another format that can be implemented easily.
In addition to reporting the Communications Content and OOB/CII events, an MD5 hash file must also be generated for the PCAP file to ensure the content of the file was not changed after delivery to the LEA. Under Linux, a program called md5sum is commonly used to produce this hash file (refer to http://en.wikipedia.org/wiki/Md5sum for more info). Other programs may be available to accomplish the same results.
To reliably produce the required hash files, you can set up automatic begin and end times for each PCAP file that is created. This can be done on a daily basis during the Intercept, with the previous day’s capture ending at 12:01 am and the next day’s capture starting at 12:00 am, just to provide a few seconds of overlap to ensure that no data is lost. The initial start time and final end time should be specified in the Lawful Authorization for the Intercept. Once you have automated the time when each day’s PCAP file will be initiated and closed, it is then possible to automate md5sum to generate the hash file.
Automation like this under Linux often leverages a scheduling program called cron, which can be used to launch programs like tcpdump, OpenCALEA tap, and md5sum. Other operating systems may provide similar functionality in different applications.
8.2.2 Final Delivery
With the WCS, final delivery to the LEA is not really delivery at all, but instead might be referred to as “pick-up.” In push systems like the ATIS CALEA standards, the Intercept is streamed directly to the LEA in real time. This can be a serious problem when the LEA has more Intercepts running than they have facilities to receive them. The WCS addresses this issue and the issue of reliable delivery over the Internet, by creating a buffer in the form of a file server. The LEA must be given access to this file server so the files can be pulled down at the LEA’s convenience.
The WCS does not specify anything about the file server or the software that is used for the LEA pick up. While most service providers will use a Linux file server to buffer captures, other operating systems could be used to achieve the same results. The WCS also does not specify the method by which the LEA accesses the capture and event files. FTP is commonly used to transfer files like this, but HTTP, NFS, and other file transfer protocols could also be used. The LEA may require an encrypted file transfer, and some service providers will adopt secure FTP for this function. But again, many other network applications could be used to achieve the same results, including secure HTTP, secure copy (scp), and other encrypted file transfer protocols.
The specifics of user name and password for authentication, the file transfer protocol used by the LEA to pick up files, and the security measures such as encryption that might be used, are all left for the service provider and LEA to negotiate. If these methods were specified in the WCS, it would limit the options available to the service provider and LEA for final delivery. Given the existing range of options for file transfer, and the potential for new delivery methods to be developed, the CALEA committee chose the most flexible approach to compliance, which was to leave these final delivery details to be negotiated with the LEA.