idnits 2.17.1 draft-baker-slem-architecture-02.txt: -(355): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 38 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2003) is 7498 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '14' on line 695 looks like a reference -- Missing reference section? '13' on line 693 looks like a reference -- Missing reference section? '1' on line 664 looks like a reference -- Missing reference section? '2' on line 666 looks like a reference -- Missing reference section? '12' on line 690 looks like a reference -- Missing reference section? '6' on line 677 looks like a reference -- Missing reference section? '9' on line 684 looks like a reference -- Missing reference section? '7' on line 680 looks like a reference -- Missing reference section? '8' on line 682 looks like a reference -- Missing reference section? '11' on line 688 looks like a reference -- Missing reference section? '10' on line 686 looks like a reference -- Missing reference section? '5' on line 674 looks like a reference -- Missing reference section? '3' on line 668 looks like a reference -- Missing reference section? '4' on line 671 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Fred Baker 2 Internet Draft Bill Foster 3 Document: Chip Sharp 4 Category: Informational October 2003 6 Cisco Architecture for Lawful Intercept In IP Networks 8 Status of this Document 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet- Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 For the purposes of this document, lawful intercept is the lawfully 31 authorized interception and monitoring of communications. Service 32 providers are being asked to meet legal and regulatory requirements 33 for the interception of voice as well as data communications in IP 34 networks in a variety of countries worldwide. Although requirements 35 vary from country to country, some requirements remain common even 36 though details such as delivery formats may differ. This document 37 describes Cisco's Architecture for supporting lawful intercept in IP 38 networks. It provides a general solution that has a minimum set of 39 common interfaces. This document does not attempt to address any of 40 the specific legal requirements or obligations that may exist in a 41 particular country. 43 Architecture for Lawful Intercept October 2003 45 Table of Contents 47 Abstract..............................................................1 48 1. Introduction.......................................................2 49 1.1. Requirements Motivating the Architecture........................3 50 1.2. Document Organization...........................................4 51 2.0. Reference Model..................................................5 52 2.1. Reference Model Components......................................6 53 2.2. Operational Considerations......................................7 54 3.0. Interfaces.......................................................9 55 3.1. Content Intercept Request Interface.............................9 56 3.2. Intercept Content Interface (f)................................10 57 4.1. Voice over IP networks.........................................10 58 4.1.1. Interception of Voice over IP Services.....................10 59 4.1.2. Local Voice Services.......................................11 60 4.2. Data Services..................................................12 61 5.0. Security Considerations.........................................13 62 5.1. Content Request Interface (d) - SNMPv3 Control.................13 63 6.0. References......................................................14 64 7.0. Acronyms........................................................15 65 8.0. Authors' Addresses..............................................15 67 1. Introduction 69 For the purposes of this document, lawful intercept is the lawfully 70 authorized interception and monitoring of communications of an 71 intercept subject. The term "intercept subject", "subject", "target 72 subscriber" or "target" in this document refers to the subscriber of 73 a telecommunications service whose communications and/or intercept 74 related information (IRI) has been lawfully authorized to be 75 intercepted and delivered to some agency. Note that although the term 76 "Law Enforcement Agency" (LEA) is used throughout this document, this 77 may refer to any agency that is able to request lawfully authorized 78 interception. 80 By intercept related information (IRI) we mean information related to 81 the IP traffic of interest. There is currently no standardized 82 definition for IRI for IP traffic. IRI has been defined for a few 83 services that might run over IP (e.g., Voice over IP) or that IP runs 84 on top of (e.g., GPRS). For example, IRI for voice over IP could be 85 the called and calling phone numbers. The definition of IRI from [14] 86 is shown below: 88 Intercept Related Information: collection of 89 information or data associated with 90 telecommunication services involving the target 91 Architecture for Lawful Intercept October 2003 93 identity, specifically communication associated 94 information or data (e.g. unsuccessful 95 communication attempts), service associated 96 information or data (e.g. service profile 97 management by subscriber) and location 98 information. 100 Service providers are being asked to meet legal and regulatory 101 requirements for the interception voice as well as data 102 communications in IP networks in a variety of countries worldwide. 103 Although requirements vary from country to country, some requirements 104 remain common even though details such as delivery formats may 105 differ. This document describes Cisco's Architecture for supporting 106 lawful intercept in IP networks. It provides a general solution that 107 has a minimum set of common interfaces. This document does not deal 108 with legal requirements or obligations. 110 This document describes one method for supporting lawful intercept. 111 Other methods may be available. 113 1.1. Requirements Motivating the Architecture 115 The purpose of the following list of requirements is to provide an 116 understanding of the motivation behind the architecture and some of 117 the requirements imposed on components and interfaces that are 118 described in the later sections of the document. This does not imply 119 any legal requirements on service providers or equipment vendors 120 although such requirements may coincide. 122 Note that there are a variety of requirements that have been defined 123 for lawfully authorized intercept throughout the world. Some of these 124 have been defined by standards bodies (e.g. [13]), while others are 125 country specific. The following itemized list is a distillation of 126 some of these, although a given item may or may not apply to a 127 specific country: 129 * Lawful Intercept (LI) should be undetectable by the intercept 130 subject. 132 * Mechanisms should be in place to limit unauthorized personnel 133 from performing or knowing about lawfully authorized intercepts. 135 * There is often a requirement (especially for telecommunications 136 services) to provide intercept related information (IRI) 137 separately from the actual Internet Protocol (IP) traffic (or 138 content) of interest (Note: some authorizations may be 139 restricted to IRI). 141 * If IRI is delivered separately from content, there should be 142 some means to correlate the IRI and the content with each other. 144 * If the information being intercepted is encrypted by the service 145 provider and the service provider has access to the keys, then 146 the information should be decrypted before delivery to the Law 147 Architecture for Lawful Intercept October 2003 149 Enforcement Agency (LEA) or the encryption keys should be passed 150 to the Law Enforcement Agency to allow them to decrypt the 151 information. 153 * If the information being intercepted is encrypted by the 154 intercept subject and its associate and the service provider has 155 access to the keys, then the service provider may deliver the 156 keys to the LEA. 158 * There is often a requirement for a service provider to be able 159 to do multiple simultaneous intercepts on a single subject. The 160 fact that there are multiple intercepts should be transparent to 161 the LEAs. 163 * There is often a requirement that the service provider should 164 not deliver any unauthorized information to the LEA. 166 The architecture and interfaces described in this document attempts 167 to address these requirements. 169 1.2. Document Organization 171 Section 1 of this document lists requirements motivating the 172 architecture. Section 2 of this document describes a reference model 173 along with some operation considerations. Section 3 provides more 174 detailed requirements on the interfaces related to content 175 interception. Section 4 applies the reference model to voice over IP 176 and data intercepts and Section 5 examines security considerations. 178 Architecture for Lawful Intercept October 2003 180 2.0. Reference Model 182 This section describes a generic reference model (Figure 1) for 183 lawful intercept. 185 +--------------------+ +-----+ 186 | LI Administration | HI1(a) | | 187 | Function |<--------------| | 188 +--------------------+ | | 189 | | | 190 | MD Provisioning | | 191 | Interface(b) | LEA | 192 v | | 193 +-----------+ +--------------------+ | | 194 | |<---(c)----| | | | 195 | IRI IAP |--IRI(e)-->| Mediation |----HI2(g)--->| | 196 | | | Device (MD) | | | 197 +-----------+ | |----HI3(h)--->| | 198 +--------------------+ +-----+ 199 | ^ 200 Intercept | | Intercepted 201 Request(d) | | Content(f) 202 | | 203 v | 204 +--------------------+ 205 User | Content | User 206 ------->| IAP |--------> 207 Content +--------------------+ Content 209 Figure 1: Intercept Architecture 211 A brief description of the interfaces is included in table 1 below. 212 For a more detailed description of the interfaces refer to section 3. 213 For a description of the components refer to section 2.1. 215 Table 1 LI Interfaces 217 Interface Description 218 --------------------- ------------------------------------------- 219 (a) HI1 Handover Interface 1 - Administration 220 Interface: The LEA provides intercept 221 information to the service provider 222 administration function. 224 (b) MD Provisioning Mediation Device provisioning interface. 225 Parameters include: target identifier, 226 duration of intercept, type of intercept, 227 etc. 229 (c) IRI IAP Provisioning Specifies Target identifier, duration, 230 etc. for provisioning of delivery of 231 Intercept Related Information (IRI). 233 Architecture for Lawful Intercept October 2003 235 (d) Content Intercept Provisioning of the Content IAP. 236 Provisioning 238 (e) IRI to MD Internal interface between IRI Intercept 239 Access Point (IAP) and Mediation device 240 (MD) for delivery of IRI. 242 (f) Content to MD Internal interface between content 243 IAP and MD for delivery of Content. 245 (g) HI2 Handover Interface 2: Interface between 246 the MD and LEA for delivering IRI. This 247 interface may vary from country to 248 country. 250 (h) HI3 Handover Interface 3: Interface between 251 the MD and LEA for delivering Content. 252 This interface may vary from country to 253 country. 255 2.1. Reference Model Components 257 A brief description of the key components in the reference model is 258 as follows: 260 Lawful Intercept (LI) Administration Function: 261 This function provides the (typically manual) provisioning 262 interface for the intercept as a result of a court order or 263 warrant delivered by the Law Enforcement Agency (LEA). It could 264 involve separate provisioning interfaces for several components, 265 but more typically is a single interface to the Mediation Device 266 (MD), which then takes care of provisioning of other components in 267 the network. Because of the requirement in some laws to limit 268 accessibility to authorized personnel, the provisioning interface 269 has to be strictly controlled. In many cases, the identity of the 270 subject received from the LEA has to be translated into an 271 identity that can be used by the network to enable the intercept. 273 Intercept Access Point (IAP): 274 An IAP is a device within the network that is used for 275 intercepting lawfully authorized intercept information. It may be 276 an existing device that has intercept capability or it could be a 277 special device that is provided for that purpose. Two types of 278 IAP's are discussed here: IAP's that provide content; and IAP's 279 that provide intercept related information (IRI). 281 Content IAP: 282 A content IAP is an IAP that is used to intercept the IP traffic 283 of interest. 285 IRI IAP: This is an IAP that is used to provide intercept related 286 information (IRI). 288 Architecture for Lawful Intercept October 2003 290 Law Enforcement Agency (LEA): 291 This is the agency that has requested the intercept and to which 292 the service provider delivers the information. 294 Mediation Device (MD): 295 The MD requests intercepts from IAPs through interfaces (c) and 296 (d) in Figure 1. The Mediation Device receives the data from the 297 IAP, packages it in the correct format (which may vary from 298 country to country) and delivers it to the LEA. In the case where 299 multiple law enforcement agencies are intercepting the same 300 subject, the mediation device may replicate the information 301 multiple times. The assumption is that the service provider 302 operates the MD (via specially authorized personnel) and that the 303 LEA only has access to interfaces (a), (g) and (h) in Figure 1. 305 2.2. Operational Considerations 307 In a typical operation, a lawfully authorized surveillance request 308 arrives for a specified intercept subject. Authorized personnel 309 provision the intercept using interface (b) in Figure 1, which may 310 be for content only, IRI only or both. Once the intercept is 311 provisioned, the IAP's send the IRI and/or content to the MD, 312 which formats the information into the appropriate format for 313 delivery to the LEA. Some operational issues that need to be 314 considered: 316 * Location and Address Information for Content Intercepts: In 317 some cases where the location and/or addressing information 318 for the intercept is not known until the subject registers 319 (or makes a call in the case of voice), the IRI may provide 320 needed information in order to do the content tap (e.g. the 321 IP address and port for the content streams). 323 * Content Encryption: If the intercept content is encrypted and 324 the service provider has access to the encryption keys (e.g., 325 receives keys in Session Description Protocol for Voice over 326 IP), then the keys can be sent via IRI. It is, however, 327 possible for end-users to exchange keys by some other means 328 without any knowledge of the service provider in which case 329 the service provider will not be able to provide the keys. 330 Content transformations could make decryption at the LEA 331 impossible. This is why the original packets are provided on 332 interface (f) rather than attempting to convert them to some 333 other format. 335 * Detection by the Intercept Subject: One requirement is to 336 ensure that the intercept subject is unable to detect that 337 they are being intercepted. This document assumes a 338 sophisticated subject: 340 - Able to check IP addresses, use traceroute, etc. 342 - Able to check if any unusual signaling is occurring on 343 their customer premises equipment (CPE). 345 Architecture for Lawful Intercept October 2003 347 - Able to detect degradation or interruptions in service. 349 This is why the intercept mechanism described here does not 350 involve special requests to the CPE, re-routing of packets or 351 end-to-end changes in IP addresses. Instead, content 352 intercept is done on a device along the normal content path 353 (i.e. no re-routing has occurred) that is within the service 354 provider's network. A convenient content IAP is a router or 355 switch at the edge of the service provider�s network to which 356 the intercept subject connects. This is illustrated in Figure 357 2. 359 | 360 Customer Premises | Service Provider's Network 361 | 362 +-------+ 363 +-----+ | | 364 | CPE |-------------| Router|---------- 365 +-----+ | (IAP) | 366 | | 367 +-------+ 369 Figure 2 Content IAP - Router 371 Another possibility of course is to provide a special device 372 along the path to provide the content IAP capabilities. 374 Note that in the case where there is multi-homing (two or 375 more routers connected to provide access for the CPE), 376 intercept taps may have to be installed on more than one 377 access router. If the CPE is multi-homed to multiple service 378 providers, then the intercept will have to be installed on 379 each service provider separately and the LEA will have to 380 correlate the data. 382 * Unauthorized Creation and Detection: Another concern is the 383 prevention of unauthorized creation and detection of 384 intercepts. This is particularly important when a network 385 element such as a router is used as a content IAP. Those 386 routers that have the capability should be carefully 387 controlled with access to intercept capability and 388 information only via authorized personnel. In one approach 389 using the reference model in Figure 1, the MD is in a 390 controlled environment and the MD does the intercept request 391 to the content IAP over an encrypted link. Logging and 392 auditing are used to detect unauthorized attempts to access 393 the intercept capability. 395 * Capacity: Support for lawful intercept on a network element 396 supporting customers consumes resources on that equipment. 397 Therefore, support for lawful intercept requires capacity 398 Architecture for Lawful Intercept October 2003 400 planning and engineering to ensure that revenue-producing 401 services are not adversely affected. 403 3.0. Interfaces 405 This section provides a brief description of the interfaces in the 406 reference model (Figure 1). A list of these interfaces is included in 407 Table 1 in Section 2. 409 One of the objectives in defining these interfaces is to keep the 410 internal interfaces (b to f) the same regardless of country-specific 411 requirements. The MD then formats the IRI and the content to meet the 412 country specific requirements for interfaces (g) and (h). 414 3.1. Content Intercept Request Interface 416 This section describes some of the requirements for the content 417 intercept request interface (d) in Figure 1. It makes use of a common 418 request protocol (SNMPv3) regardless of the type of application (e.g. 419 voice, data) and suggests the usage of a TAP-MIB, which is defined in 420 a separate document [1]. Some of the considerations that lead to the 421 use of SNMPv3 and to the definition of the specific Management 422 Information Base (MIB) defined in [1] are provided here. 424 In order to provide a generic interface for intercepting, 425 replicating, encapsulating and transporting content packets to the 426 MD, the content intercept interface ((d) in Figure 1) should specify: 428 * A Filter specification for classifying the packets to be 429 intercepted. 431 * The destination address of the MD (where to send the packets). 433 * Encapsulation and Transport parameters. 435 In addition, a timeout value for the intercept should also be 436 specified. This defines a limited lifetime for the intercept so that 437 failures will not result in intercepts remaining beyond their 438 authorized lifetime. If a failure of the MD occurs such that it is 439 not able to supply the refresh to the timeout, then the intercept 440 will cease to exist after the timeout expires. Similarly, if the IAP 441 re-boots, then the intercept will not survive the re-boot unless the 442 IAP is capable of ascertaining that the intercept lifetime 443 requirements will continue to be met. 445 In order for this to work, it must be possible for the mediation 446 device to realize that there is a failure in the IAP such that it 447 must re-establish the intercept. This may be in the form of an audit 448 (from the MD to the IAP), or in the form of a heartbeat mechanism in 449 the content stream, or both. 451 Architecture for Lawful Intercept October 2003 453 3.2. Intercept Content Interface (f) 455 The encapsulation method should retain all of the information in the 456 original packets (source and destination addresses as well as 457 payload) and provide an identifier for correlating the packets with 458 the IRI. One encapsulation that meets those requirements is described 459 in Section 4 of [2]. For non-voice intercepts, the "Intercepted 460 Information" field in Table 1 of [2] contains the original 461 intercepted IP packet. 463 Note, however, that the interface defined in [2] is based on UDP 464 which is an unreliable and unordered transport protocol (i.e., 465 provides neither retransmission on detection of errors nor ordering 466 of data). If this transport is used, the underlying network (Layers 467 1 - - 3) should be engineered to meet the overall reliability 468 requirements for delivery of content. 470 If a more reliable transport protocol is required, then a mechanism 471 that provides timely delivery as well as limits the burden (both 472 processing and buffering) on the Content IAP should be used. One 473 mechanism that meets these requirements is a NACK-oriented 474 retransmission scheme based on [12]. 476 If [12] is used, the call content channel identifier may be placed in 477 the SSRC field of the encapsulating RTP packet. The payload type may 478 be used to identify the type of packet encapsulated in RTP (e.g., IP, 479 PPP, Ethernet MAC). Note that usage of [12] is still under 480 investigation and may need further specification. Usage of [12] in 481 the content IAP places more processing burden on the content IAP than 482 a UDP-based intercept and can affect the capacity of the content IAP. 484 4.0. Applying the Reference Model 486 This section applies the reference model to some example 487 applications. 489 4.1. Voice over IP networks 491 This section will look at some of the issues surrounding interception 492 of voice over IP calls, taking local voice services as a specific 493 service example. The reference model from Figure 1 will be applied 494 with the use of a common set of interfaces that are independent of 495 the call signaling protocols in use. 497 4.1.1. Interception of Voice over IP Services 499 There are a variety of architectures in use for voice over IP (e.g., 500 centralized versus distributed) as well as various protocols (SIP 501 [6], H.323 [9], MGCP [7], H.248 [8]). There are also a variety of 502 services that may be offered: 504 * Local Voice Services (i.e. service to a user that has an IP 505 phone or a phone connected to a gateway) 506 Architecture for Lawful Intercept October 2003 508 * Transit services 510 * Long distance access services (e.g. calling/debit card). 512 This document does not address any obligations that a service 513 provider might or might not have to support intercepts. It simply 514 describes how intercept might be done using the reference model in 515 Figure 1. 517 Note that in the case of services where the intercept subject 518 accesses the network via a non-IP endpoint (e.g., TDM), the 519 detectability issue is less acute (e.g. re-routing of packets to 520 intercept them in a special device is a possible option), since the 521 intercept subject does not have access to the IP addresses or to 522 traceroute. 524 However, in the case of local services, this is a much more difficult 525 problem. The intercept for a call originating and terminating on-net 526 (i.e. a call that is voice over IP end-to-end) has to be intercepted 527 along its normal route in order to be undetectable. In addition, the 528 call-forwarding feature that is often provided as a local service 529 feature makes interception even more difficult: If call forwarding is 530 invoked, a call that was intended to terminate on the intercept 531 subject may be forwarded anywhere in the network resulting in the 532 media stream bypassing the original content IAP (since in voice over 533 IP, the media stream goes directly from end-to-end). Also, since call 534 forwarding can often be set up on a call-by-call basis, the location 535 of the content IAP will often not be known until the call is set up. 537 4.1.2. Local Voice Services 539 This sub-section will look at the specific case in which the 540 intercept subject under surveillance is being provided with a local 541 voice service by the same provider that also provides the network 542 access (e.g., controls the edge router or switch). This is an 543 important assumption, since in VoIP the entity providing call control 544 (e.g., SIP server) can be totally separate from the entity providing 545 network access (e.g., operates edge routers). 547 Suppose that a subscriber that subscribes to a local (e.g. 548 residential) voice service is a target for a lawfully authorized 549 surveillance. Part of the system providing these services is a 550 subscriber database that includes addressing information about the 551 subscriber as well information on what features are in effect (e.g. 552 call forwarding). Some call control entity (CCE) accesses that 553 database in order to provide local services. For example, if the 554 subject has call forwarding invoked, that fact (and where to forward 555 the call) is indicated in the subscriber database. A call arriving at 556 the CCE that "owns" that subscriber can then take the appropriate 557 action (e.g. forward the call). 559 The CCE that "owns" the target subscriber (which could be an H.323 560 gatekeeper, a SIP proxy or a Media Gateway Controller) is provisioned 561 with the intercept parameters (e.g. subject identification 562 Architecture for Lawful Intercept October 2003 564 information such as the telephone number and where to deliver the 565 IRI). The provisioning of this CCE could be through interface (c) in 566 Figure 1. The CCE in question is the IRI IAP and once provisioned, it 567 passes the IRI to the MD. In the scenario being discussed, the CCE 568 typically remains in the signaling path throughout the call, even in 569 the call-forwarding case. Part of the IRI it passes to the MD is the 570 media signaling information (i.e. SDP [11] or H.245 [10]), which 571 includes endpoint IP address and port information for the media 572 (content) streams. Armed with this media address information, the MD 573 can determine the content IAP (e.g. [5]) and make the request via 574 interface (d). The request identifies the voice stream to be 575 intercepted based on information received in the call signaling 576 (i.e., IP addresses and UDP port numbers). 578 Note that the content IAP in the case of voice over IP could be an 579 edge router or a PSTN gateway (e.g. a call from the PSTN forwarded to 580 the PSTN). SIP, H.323, MGCP or H.248 call signaling protocols could 581 be used. However, the protocol (SNMPv3 [1]) used for interface (d), 582 is not dependent on the type of call signaling protocol used; nor is 583 the encapsulation format and transport protocol (interface "f"). The 584 same reference model (Figure 1) with the same interfaces can be used 585 for lawfully authorized surveillance, regardless of the signaling 586 protocol and regardless of the type of service being provided (Note: 587 even though a local voice service was used in this example, other 588 voice services could use the same model and interfaces). 590 4.2. Data Services 592 The same model (Figure 1) can also be used for data services. In this 593 case the IRI IAP could be a server that acts as registration, 594 authentication and authorization point for the data service (e.g. a 595 RADIUS server). If a potential IRI IAP does not have the available 596 interfaces (c) and (e), the MD may have to do a content tap on 597 registration signaling in order to obtain the IRI. 599 The IRI in the case of a data service could include: 601 * The time that the user registered or de-registered for the 602 service. 603 * Addressing information (i.e. given the user identity, what IP 604 address or other information is available that could be used in 605 interface (d) to do the content tap). 607 Once suitable addressing information is available in order to do 608 content tapping the MD can invoke the tap via interface (d). 610 Clearly the IRI interfaces (c, e, g) are different for data than they 611 are for voice services. However, the content IAP is typically the 612 same (an edge router). Interfaces (d, f, and h) may also be the same. 614 Architecture for Lawful Intercept October 2003 616 5.0. Security Considerations 618 Given the sensitive nature of lawful intercept (LI) -- both from the 619 standpoint of the need to protect sensitive data, as well as conceal 620 the identities of the intercept subjects, the LI solution should have 621 the ability to provide stringent security measures to combat threats 622 such as impersonation of MD's, privacy and confidentiality breaches, 623 as well as message forgery and replay attacks. 625 While this document doesn�t discuss issues of physical security, 626 operating system, or application hardening within the principals of 627 the LI solution, they are clearly important. In particular, the MD 628 server would be considered a prime target for attacks. 630 In general, all interfaces should have the capability of providing 631 strong cryptographic authentication to establish the identity of the 632 principals, and be able to correlate the identity of the principal 633 with the action they are attempting to perform. All interfaces should 634 be capable of performing some sort of cryptographic message integrity 635 checking such as, for example, HMAC-MD5. Message integrity checking 636 can also be used to counter replay attacks. Privacy and 637 confidentiality considerations, may also require the use of 638 encryption. 640 The content and IRI IAPs also should also provide protection of the 641 identity of the intercept subject and the existence of an intercept. 643 5.1. Content Request Interface (d) - SNMPv3 Control 645 For interface (d,) native SNMPv3 security module mechanism is used. 646 The additional requirement is that the IAP should support the ability 647 to protect the TAP MIB's [1] from disclosure or control by 648 unauthorized USM [3] users. VACM [4] provides the necessary tools to 649 limit the views to particular USM users, but there are also special 650 considerations: 652 * The ability to limit access to the appropriate TAP MIB's by only 653 those SNMPv3 USM users which have keys established and the 654 proper VACM views defined. 656 * Segregation of the TAP MIB such that only operators of 657 sufficient privilege level can create VACM views that include 658 the TAP MIB [1]. 660 Architecture for Lawful Intercept October 2003 662 6.0. References 664 [1] F. Baker, Cisco Lawful Intercept Control MIB, draft-baker- 665 slem-mib-00, (work in progress) 666 [2] PacketCable(TM) Electronic Surveillance Specification, PKT- 667 SP-ESP-I01-991229, http://www.packetcable.com/specifications/ 668 [3] Blumenthal, U. and B. Wijnen, User-based Security Model(USM) 669 for version 3 of the Simple Network Management Protocol 670 (SNMPv3), STD 62, RFC3414, December 2002. 671 [4] B. Wijnen, et al, View-based Access Control Model (VACM) for 672 the Simple Network Management Protocol (SNMP), STD62, RFC3415 673 December 2002 674 [5] E. Warnicke, DNS Resolution of Networks and Gateways, IETF 675 Draft draft-warnicke-network-dns-resolution-02.txt (work in 676 progress) 677 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 678 Peterson, J., Sparks, R., Handley, M. and E. Schooler, SIP: 679 Session Initiation Protocol, RFC3261, June 2002. 680 [7] F. Andreasen, B. Foster, Media Gateway Control Protocol 681 (MGCP) Version 1.0, RFC3435, January 2003 682 [8] ITU-T Recommendation H.248.1, Gateway Control Protocol: 683 Version 2, May 2002 684 [9] ITU-T Recommendation H.323, Packet-based Multimedia 685 Communications Systems, November 2000 686 [10] ITU-T Recommendation H.245, Control Protocol for Multimedia 687 Communications, February 2003 688 [11] M. Handley, V, Jacobson, SDP: Session Description Protocol, 689 RFC2327 April 1998 690 [12] J. Rey, D. Leon, A. Miyazaki, V. Varsa, R. Hakenber, RTP 691 Retransmission Payload Format, draft-ietf-avt-rtp- 692 retransmission-09.txt (work in progress) 693 [13] ETSI TS 101 331, Telecommunications security; Lawful 694 Interception (LI); Requirements of law enforcement agencies. 695 [14] ETSI TS 33.108 v1.0.0, 3rd Generation Partnership Project; 696 Technical Specification Group Services and System Aspects; 3G 697 Security; Handover Interface for Lawful Interception. 699 Architecture for Lawful Intercept October 2003 701 7.0. Acronyms 703 CCE Call Control Entity 704 CMTS Cable Modem Termination System 705 CPE Customer Premises Equipment 706 ETSI European Telecommunications Standards Institute 707 GPRS Generalized Packet Radio Service 708 HMAC-MD5 Hash-based Message Authentication Code - - 709 Message Digest 5 710 IAP Intercept Access Point 711 IETF Internet Engineering Task Force 712 IRI Intercept Related Information 713 ITU-T International Telecommunications Union - - 714 Telecommunications Sector 715 LEA Law Enforcement Agency 716 LI Lawful Intercept 717 MGCP Media Gateway Control Protocol 718 MD Mediation Device 719 MIB Management Information Base 720 NACK Negative Acknowledgement 721 PSTN Public Switched Telecommunications Network 722 RFC Request for Comment 723 RTP Real-time Transport Protocol 724 SDP Session Description Protocol 725 SIP Session Initiation Protocol 726 SSRC Synchronization Source 727 TDM Time Division Protocol 728 UDP User Datagram Protocol 729 USM User Service Model 730 VACM View-based Access Control Model 731 VoIP Voice over IP 733 8.0. Authors' Addresses 735 Fred Baker 736 Cisco Systems 737 1121 Via Del Rey 738 Santa Barbara, CA 93117 739 US 741 Phone: +1-408-526-4257 742 Fax: +1-413-473-2403 743 EMail: fred@cisco.com 745 Bill Foster 746 Cisco Systems 747 Email: bfoster@cisco.com 749 Chip Sharp 750 Cisco Systems 751 Email: chsharp@cisco.com 752 Architecture for Lawful Intercept October 2003 754 9.0. Full Copyright Statement 756 Copyright (C) The Internet Society (2003). All Rights Reserved. 758 This document and translations of it may be copied and furnished to 759 others, and derivative works that comment on or otherwise explain it 760 or assist in its implementation may be prepared, copied, published 761 and distributed, in whole or in part, without restriction of any 762 kind, provided that the above copyright notice and this paragraph are 763 included on all such copies and derivative works. However, this 764 document itself may not be modified in any way, such as by removing 765 the copyright notice or references to the Internet Society or other 766 Internet organizations, except as needed for the purpose of 767 developing Internet standards in which case the procedures for 768 copyrights defined in the Internet Standards process must be 769 followed, or as required to translate it into languages other than 770 English. 772 The limited permissions granted above are perpetual and will not be 773 revoked by the Internet Society or its successors or assigns. 775 This document and the information contained herein is provided on an 776 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 777 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 778 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 779 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 780 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 782 Acknowledgement 784 Funding for the RFC Editor function is currently provided by the 785 Internet Society.