1、 ATIS-1000075 ATIS Standard on - Cloud Services Impacts on Lawful Interception Study As a leading technology and solutions development organization, the Alliance for Telecommunications Industry Solutions (ATIS) brings together the top global ICT companies to advance the industrys most pressing busin
2、ess priorities. ATIS nearly 200 member companies are currently working to address the All-IP transition, 5G, network functions virtualization, big data analytics, cloud services, device solutions, emergency services, M2M, cyber security, network evolution, quality of service, billing support, operat
3、ions, and much more. These priorities follow a fast-track development lifecycle from design and innovation through standards, specifications, requirements, business use cases, software toolkits, open source solutions, and interoperability testing. ATIS is accredited by the American National Standard
4、s Institute (ANSI). The organization is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a founding Partner of the oneM2M global initiative, a member of and major U.S. contributor to the International Telecommunication Union (ITU), as well as a member of t
5、he Inter-American Telecommunication Commission (CITEL). For more information, visit www.atis.org. Notice of Disclaimer ATIS-0700005-2010a, Supplement A for Lawfully Authorized Electronic Surveillance (LAES) for 3GPP IMS-based VoIP and other Multimedia Services.3025-B J-STD-025-B, Lawfully Authorized
6、 Electronic Surveillance.4500-292 NIST Special Publication 500-292, NIST Cloud Computing Reference Architecture, Recommendations of the National Institute of Standards and Technology, September 2011.5800-145 NIST Special Publication 800-145, The NIST Definition of Cloud Computing, Recommendations of
7、 the National Institute of Standards and Technology, September 2011.5042 ATIS-1000042, Support for Lawfully Authorized Electronic Surveillance (LAES) of Advanced Voice over Packet (VoP) Conferencing.63 Definitions, Acronyms, it uses terminology from the networking and LI environments and assumes the
8、 reader has a basic understanding of both. 4.2 Cloud Services WiFi Hot Spots shopping malls, airports; Mobile access HSPA, LTE, etc. Location perspective: Users may access the service at different locations: home, shopping mall, train, bus, airplane, another country, etc. Protocol perspective: Diffe
9、rent protocols may be used in providing/granting the service to the users: Session Initiation Protocol (SIP), Extensible Markup Language (XML), Hypertext Transfer Protocol (HTTP), or Diameter, RADIUS, etc. Service perspective: Users may access a variety of cloud-based services: playing online games,
10、 chat during a game, watching a video stream, downloading a book, web-based conferencing, web-based chat which may include text, audio, or video, etc. In some situations, LI may only apply to a Telecommunications Service Provider (TSP) that leases the infrastructure; for example, from a cloud servic
11、e provider. For simplicity of argument, the cloud can be divided into two layers, as illustrated in Figure 5.1. The top layer is the User Service Provider (USP), the entity that owns the subscriber relationship, and the bottom is the XaaS Provider (XaaSP), which provides the cloud service to the USP
12、. A Cloud Service Provider (CSP) can be one of many varieties of XaaSP. The USP can provision any number of services on the XaaSP infrastructure, such as telecom, email, or a number of LI modules. The XaaSP is contracted by the USP to physically instantiate the services that the top layer sells to i
13、ndividual users. Figure 5.1 Representation of two layer division within a cloud environment In cloud language, the services are referred to as “Something as a Service”. For example, they can be: Communication as a Service (CaaS) Data as a Service (DaaS) Infrastructure as a Service (IaaS) Network as
14、a Service (NaaS) Platform as a Service (PaaS) Software as a Service (SaaS) Virtual Desktop as a Service (VaaS), etc. User User Service XaaS Provider Subscriber Relationship SLA type B2B agreement ATIS-1000075 8 . 5.2 Intercept Subject In a non-cloud environment, an Intercept Subject is identified in
15、 a number of ways, for example: Telephone Number. SIP/TEL Uniform Resource Identifier (URI). Media Access Control (MAC) Address, International Mobile Station Equipment Identity (IMEI). International Mobile Subscriber Identity (IMSI). Static IP Address. For some LI cases, even a network resource may
16、be identified as the Intercept Subject (e.g., Conference URI). In a cloud environment, an Intercept Subject may have to be identified for lawful interception purposes through the identities used by the Intercept Subject to log in to the cloud-based service. In most situations, this could be a user I
17、D. In some situations, it can also be the telephone number or SIP/TEL URI or even the IP address. 5.3 Distribution of LI Implementation In a cloud environment, there is no single manner in which LI capability is provided, and in fact what is sometimes necessary is the involvement of multiple parties
18、. This will be illustrated with four diagrams in the following Figure 5.2. UserXaaS ProviderUSP UserXaaS ProviderUSP TTPUser USPUser USPXaaS(a)(c)(d)(b)IAPs IAPsDFLEADFLEAXaaS ProviderXaaS ProviderXaaSProviderIAPs DFLEAUSPXaaSProviderIAPs TTPDFLEAATIS-1000075 9 Figure 5.2 Distribution of LI Implemen
19、tation In each of these figures, the USP is the provider of a cloud service to some user that is the potential target of a lawful intercept. The USP is therefore the entity responsible for the execution of a lawful intercept. In Figure 5.2(a), the USP carries out the lawful intercept entirely on its
20、 own. The Delivery Function (DF) box represents the delivery function (of the interception to a law enforcement collection function). Note that in this situation there are three basic ways of implementing the interception: 1. The USP can implement, entirely in its application, the LI capability. 2.
21、The USP can attach certain interfaces within itself to probes, and the probes implement the LI capability. Note that in a virtual environment, this requires some type of “virtual tap”. These points are denoted as IAPs (intercept access points). 3. The USP can implement, in its application, proprieta
22、ry LI interfaces and Application Program Interface (API) which are attached to an LI mediation system within the USP. These interfaces and API are also denoted as IAPs. Any and all information about the presence of the intercept, the intercepts configuration data, and the actual intercepted informat
23、ion for a subject shall not be accessible to any provider or agent not lawfully authorized to participate in this interception and/or delivery. In Figure 5.2(b), the USP uses a separate cloud service to provide at least part of the LI function. The most common situation is the service of a Trusted T
24、hird Party (TTP). In this model, the DF is shown within the TTP. The TTP needs interfaces into the USP (to the IAPs), and these can be of types 2 and 3 above (i.e., passive probe interfaces or active mediation APIs and interfaces). In Figure 5.2(b), the TTP service is most likely running in the same
25、 XaaS environment as the USP. The exact relationship of their two networks is implementation and XaaS dependent. For instance, the USP and TSP could be running in the same virtual private network, or they could have special connections between their two separate networks, sometimes called peering co
26、nnections. Figure 5.2(c) shows the situation where the XaaS provider serving the USP is providing a higher-level service. For instance, this XaaS provider may be providing a VoIP switching and media service, where this USP and perhaps other USPs are providing end VoIP services to individual subscrib
27、ers. For generality two levels of XaaS providers are shown, where the top one is providing service to the USP (e.g., communications as a service) and the bottom one is providing service to this one (e.g., infrastructure as a service). In this situation, the higher-level XaaS provider may need to pro
28、vide most or all of the LI functionality. For instance, in the example where this XaaS is providing VoIP capabilities, it is conceivable that this XaaS might need to provide all of the LI functionality. In fact, LI functions might be part of the business agreement between XaaS and USP. Since the USP
29、 is still the party responsible for lawful interception orders on its subscribers, the USP needs some means to “trigger” these LI services. There are several ways in which this might be provided. For instance, the XaaS provider might define an API or user interface through which the USP can automati
30、cally invoke the LI functionality. Alternatively, the invocation of the LI functionality might require human interaction between the two companies. Note that the three approaches outlined earlier for LI implementation now apply to the XaaS provider. For instance, it might embody the LI functions wit
31、hin its application, use passive probes, or use an API and interfaces to a mediation system. But in all cases, the actual delivery of the interception to law enforcement is carried out by the XaaS provider as a service to the USP. Figure 5.2(d) adds the independent LI service provider, typically a T
32、TP, to the previous case, making three organizations or companies involved in the intercept. Here, the LI service is provided to the USP by the TTP, and thus the TTP has automated or manual interfaces from the USP to invoke an intercept. The TTP carries out the intercept via interfaces to the XaaS p
33、rovider (again, probe-type or mediation-system-type interfaces). ATIS-1000075 10 6 Approaches to Interception of Cloud Services 6.1 Overview The principal type of intercept today is voice a legacy Public Switched Telephone Network (PSTN) or VoIP phone call. A phone call has well-defined properties t
34、hat can be clearly expressed in an LI handover standard (e.g., 025-B, 678). A phone call has the act of calling and answering, a caller and callee, an audio media stream, dialed-digit signaling, and other properties. Thus it is a relatively straightforward to define an LI handover standard. For inst
35、ance, Figure 6.1 below illustrates LI interception of a cloud-based VoIP service. Attached somehow to the VoIP service is intercept logic, and this logic drives the delivery function, which sends VoIP-specific information to the collection function. The Communications Identifying Information (CII) e
36、xpresses specific information relative to the voice service, such as the Origination, Answer, and Bye messages in 678, and clearly identifies the calling and called parties, etc. For a content intercept, the Communications Content (CC) format is specific to this type of (voice) service.Figure 6.1 LI
37、 interception of a cloud-based VoIP serviceIn this type of approach, all of the heavy lifting is done on the left side, and the collection system has little more to do than store the intercept information and display and replay it. This is considered the traditional service-specific approach. The pr
38、oblem with this approach is that the handover interface (the LI standard) is specific to the service (voice calls in this case). It doesnt cover the myriad ways that people can communicate using cloud services, e.g., messaging, email, social networking, online meetings, bulletin boards, blogs, file
39、sharing, photo sharing, multiplayer games, presence, etc. Trying to develop service-specific LI standards for each of these services is very difficult because, unlike the well-standardized public telephone service, each service providers rendition of a particular service can be quite different than
40、that of another service provider. 6.2 Approaches In the search for different strategies that could be used for cloud services, three different approaches are explored below. 6.2.1 The Black-Box Approach An alternative approach is shown in the next diagram. Here the handover uses a generic LI interfa
41、ce with communications identifying information and content labeled Cbb. Cbbis part of a new “black box” LI standard. Messages in this standard contain a few standardized elements, such as case identity and time stamp, but the rest of the message cannot be interpreted out of context. ATIS-1000075 11
42、Figure 6.2 The Black-Box Approach Rather than place the service-specific LI logic on the left, there is just a modest amount of logic that grabs events and traffic relative to an intercept subject. Instead, the service provider provides a module to the collection function that decodes and displays t
43、he CII and CC. In many situations, this module can be very similar to the “app” that the service provider provides to its customers. Because the Cbbis only known to the service-specific logic, there is no definition at the handover-standard level of CII versus CC, but the distinction would exist (as
44、 known to the service-specific LI logic) for the purposes of pen registers when there is no probable cause to warrant receiving content. To explain further, there is something a bit similar to this that goes on in collection systems today. Many collection systems contain add-on functions for interpr
45、eting broadband intercepts. The most common one looks for port 80 HTTP traffic and attempts to recreate the browser session seen by the intercept subject. The dissimilarity is that HTTP traffic to browsers is reasonably standardized so that this can be done independent of the specific web server bei
46、ng browsed. The collection system still receives, correlates, and records the intercept information, but then it needs to interact with the service-specific LI module provided by the service provider to interpret and display the information (in one way, not unlike how a collection system needs the r
47、ight codec to play audio for a VoIP call, but on a much grander scale here). So the above model requires the development of an LI standard with the Cbbinterface, and then requires each cloud service to develop the “light” logic on the left and the heavy-duty code/display module on the right. The sta
48、ndard would be highly generic, with almost no discernable information without the service-providers “decoding module”; i.e., the LI message would consist of a case identifier, timestamp (preferably in binary epoch form as discussed in a separate PTSC LAES contribution), service identifier, and then
49、a body as an octet stream. Conventional ways of transport to the collection system still apply (e.g., Transmission Control Protocol TCP). 6.2.2 The Metadata something like: “when a media message contains RTP and the RTP payload type is , then the media is and codec is ”. Alternatively, it might be possible to have the media-reporting message contain HTTP, because often everything is delivered over HTTP (e.g., audio and video is RTP over HTTP). If audio and video and text are already separated as implied above, a media
