8 June 2001. Thanks to Paul Wouters.
Source:
http://www.opentap.org/documents/101WAI-GT-FuncspecV1.0.1.doc
See related commentary by Paul Wouters: http://cryptome.org/nl-tap2.htm
Reference
WAI/GT/FuncSpecs V1.0.1
Keywords
Interception, IP, Email
[None]
Copyright Notification
Goes here
This document may be freely copied in whole and as-is for official use by Dutch government, service providers and third parties involved in maintaining or creating interceptable systems. Alteration of this document is prohibited unless expressly allowed by the Werkgroep Aftappen Internet and its technical working group. The copyright for this document remains with the GOVtech working group.
If you have received any information concerning an essential IPR related to this document please indicate the details here.
NONE
To be drafted by the ETSI secretariat.
This document has been produced by a technical working group within the Dutch government (GOVTech). This working group is a subgroup of the WAITech group that, in turn is a working group of the Werkgroep Aftappen Internet (WAI). The WAI represents the Dutch Internet Service Providers (represented by NLIP) and the Dutch governmental organisations directly involved in interception of Internet based communications.
The Dutch telecommunications law specifies in chapter 13 that service providers need to be (made) interceptable. This document specifies the functional requirements for interceptability for Internet, and Internet related, traffic.
A sister document of this document describes the handover protocol to be used for Intercepted Internet traffic.
[See Transport of Intercepted IP Traffic (TIIT v0.1.2.), The Netherlands Ministry of Justice, et al http://www.opentap.org/documents/TIIT-v0.1.2.pdf or Cryptome mirror: http://cryptome.org/TIIT-v0.1.2.pdf ]
This clause is optional. If it exists, it is always the third unnumbered clause.
This Technical Report (TR) describes the functional framework for lawful interception of Internet services and Internet based services in the Netherlands. It provides the functional specifications pertaining to the interception process and the delivery of the intercepted traffic and related information.
This document considers lawful interception in an IP network and of email messages.
For the purpose of this Technical Report the following references apply:
[1] WAIRFC 0.1.0[2] RFC 791 The Internet Protocol (IPv4)
[3] RFC 2460 (IPv6)
[4] RFC 821 (Email)
[5] RFC 792 (ICMPv4)
[6] RFC 2463 (ICMPv6)
[7] Functional specifications for lawful interception of Internet traffic in the Netherlands (this document)
3.1 Definitions
For the purposes of the present document, the following definitions apply:
Access provider: An access provider provides a user of some network with access from the user's terminal to that network.
(to) buffer: The temporary storing of information in case the necessary telecommunication connection to transport information to the LE is temporarily unavailable.
Call: Any connection (fixed or temporary) capable of transferring information between two or more users of a telecommunications system. In this context a user may be a person or a machine.
Content of communication: The information exchanged between two or more users of a telecommunications service, excluding intercept related information. This includes information that may, as part of some telecommunications service, be stored by one user for subsequent retrieval by another.
Handover Interface: A physical and logical interface across which the results of interception are delivered from a network operator / access provider / service provider to an LEMF.
Identity: A technical label that may represent the origin or destination of any telecommunications traffic, as a rule clearly identified by a physical telecommunications identity number (such as a telephone number or an IP number) or the logical or virtual telecommunications identity number (such as a personal number) which the subscriber can assign to access on a case-by-case basis.
Intercept related information: A collection of information or data associated with telecommunication services involving the target identity, specifically call associated information or data (e.g. access to a POP email box), service associated information or data (e.g. service profile management by subscriber) and location information.
Interception (or Lawful Interception): The action(s) based on appropriate law(s), performed by a network operator access provider / service provider aimed at making traffic to or from an interception subject available to the LEA that produced a warrant for the production of such traffic to the provider in question.
NOTE 3: In this document the term interception is not used to describe the action of observing communications by a LEA (see below).
Interception Interface: The physical and/or logical locations within the access provider's / network operator's service provider's telecommunications facilities where access to the content of communication and intercept related information is provided. The interception interface is not necessarily a single, fixed point.
Interception Measure: A technical measure that facilitates the interception of telecommunications; traffic pursuant to the relevant Dutch laws and regulations.
Interception Subject: A person or persons or entity, specified in a lawful authorisation, whose telecommunications are to be intercepted.
Internal Intercepting Function: A point within a network or network element at which the content of communication is made available.
Internal Network Interface: the network's internal interface between the Internal Intercepting Function and a mediation device.
Law Enforcement Agency (LEA): An organisation authorised by a lawful authorisation based on a national law to receive the results of telecommunications interceptions.
Law Enforcement Monitoring Facility (LEMF): A law enforcement facility designated as the transmission destination for the results of interception relating to a particular interception subject.
Lawful Authorisation: Permission granted to an LEA under certain conditions to intercept specified telecommunications and requiring co-operation from a network operator / access provider / service provider. Typically this refers to a warrant or order issued by a lawfully authorised body.
Lawful Interception: see Interception
Location Information: Information relating to the geographic, physical or logical location of an identity relating to an interception subject.
Mediation device: a mechanism which passes information between a network operator / access provider / service provider and a handover interface.
Network element: a component of the network structure, such as a local exchange, higher order switch or service control processor.
Network Operator: The operator of a public telecommunications infrastructure which permits the conveyance of signals between defined network termination points by wire, by microwave, by optical means or by other (electromagnetic) means.
Quality of Service: The quality specification of a telecommunications channel, system, virtual channel, computer-telecommunications session, etc. Quality of service may be measured, for example, in terms of signal-to-noise ratio, bit error rate, message throughput rate or call blocking probability.
Reliability: The probability that a system or service performs in a satisfactory manner for a given period of time when used under specific operating conditions.
Result of interception: Information relating to a target service, including the content of communication and intercept related information, which is passed by an access provider or network operator or service provider to an LEA. Intercept related information shall be provided whether or not telecommunication activity is taking place.
Service information: Information used by the telecommunications infrastructure in the establishment and operation of a network related service or services. The information may be established by an access provider, network operator, a service provider or a network user.
Service Provider: The natural or legal person providing one or more public telecommunications services whose provision consists wholly or partly in the transmission and routing of signals on a telecommunications network. A service provider need. not necessarily operate or own his own network.
Target Identity: The identity associated with a target service (see below) used by the interception subject.
Target identification: The identity that relates to a specific lawful authorisation as such. This might be an account name or similar identifier.
Target Service: A telecommunications service associated with an interception subject and usually specified in a lawful authorisation for interception.
NOTE 4: There may be more than one target service associated with a single interception subject.
Telecommunications: Any transfer of signs, signals, writing images,
sounds, data or intelligence of any nature transmitted in whole or in part
by a wire, radio, electromagnetic, photoelectronic or photo-optical system.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AP Access Provider
CC Content of Communication
HI Handover Interface
HI1 Handover Interface Port I (for Administrative Information)
HI2 Handover Interface Port 2 (for Intercept Related Information)
HI3 Handover Interface Port 3 (for Content of Communication)
ICC Interception Control Center
ICI Interception Configuration Information
IIF Internal Intercepting Function
IN Intelligent Network
INI Internal network interface
IP Internet Protocol
IRI Intercept Related Information
ISDN Integrated services digital network
LEA Law Enforcement Agency
LEMF Law Enforcement Monitoring Facility
LI Lawful Interception
MF Mediation Function
MTA Message Transfer Agent, the mail server
NWO Network Operator
PSTN Public Switched Telephone Network
QoS Quality of Service
SCN Switched Circuit Networks
SvP Service Provider
TCP Transmission Control Protocol
TI Target Identity
According to rules set by the laws and/or regulations of individual nations there is a need to lawfully intercept telecommunications traffic and provide intercept related information (IRI) in modem telecommunications systems.
In a telecommunications network interception usually takes place at a switching function close to the terminal. In the case of a PSTN SCN the interception often takes place at a local switch, to which the target identity is directly connected. Similarly, an IP network that directly supports terminals must make its own arrangements for interception of target identities at some suitable point, or multiple points, within that IP network.
The LEA requirements as they apply in The Netherlands [7] have been taken into account in the definition of the abstract handover interface [1]. This document is the specification of an internal interception function.
The definition of the internal interception function for the provision of the result of interception allows the technical facilities to be provided: with reliability; with accuracy; at low cost; with minimal disruption; most speedily; in a secure manner using open standards.
This section presents the user requirements related to the lawful interception of telecommunications with the LEA being the user. The relevant terms are defined in section 3.2. These user requirements are subject to Dutch national law and international treaties and should be interpreted in accordance with applicable national policies.
5 .1 General Requirements
1) The obligation of the NWO/AP/SvP as to which telecommunications traffic shall be intercepted is subject to national laws.2) In accordance with the relevant lawful authorisation a NWO/AP/SvP shall ensure that:
a) the entire content of communication associated with a target identity being intercepted can be intercepted during the entire period.NOTE: The exact contents to be delivered shall be specified on a case-by-case basis.
b) checksum information on the results of interception as defined in [1] shall be recorded.
3) The ability to intercept telecommunications shall be provided relating to all interception subjects, that can be identified, operating permanently within a telecommunications system.
4) The ability to intercept telecommunications shall be provided relating to all interception subjects, that can be identified, operating temporarily within a telecommunications system.
5) All results of interception provided to the handover interface shall be given a unique identification relating to lawful authorisation. This identifier is provided by the LEMF. This is further defined in [1]. See also 5.8.5.
6) Prevention of the interception of the content of communication is not permitted.
5.2 Result of interception
The NWO/AP/SvP shall, in relation to each target service:
1) provide the content of communication, relating to each successful establishment of telecommunication.2) remove any service coding and/or encryption which has been applied to the content of communication and/or the intercept related information at the instigation of the network operator or service provider (provide en clair). See 5.7.8.
NOTE: taken into consideration is the possibility to instead provide the encryption keys used. This issue is to be addressed later.
3) The conditions mentioned above also apply to multi-party or multi-way telecommunication (e.g. multicast) if and as long as the target identity participates.
NOTE: This requirement is mainly for IM where multicast/anycast addressing will become commonplace. For IPv4, this requirement will not be enforced.
5.3 Location Information
A LEA may request location information relating to locations, in a number of forms:
1) The current geographic, physical or logical location of the target identity, when telecommunications activity (involving a call or a service) is taking place, as precise as the NWO/AP/SvP can determine.2) The current geographic, physical or logical location of an identity temporarily associated with a target service because of successful telecommunication or an unsuccessful attempt to establish telecommunication, as precise as the NWO/AP/SvP can reasonably determine.
3) The current geographic, physical or logical location of an identity permanently associated with a target service.
NOTE: This information is expected to be made available from normal network operation. An example of geographic location might be the location of a point of presence operated by, or on behalf of, the NWO/AP/SvP, an example of physical location might be a subscriber access number in any network.
5.4 Time Constraints
1) A NWO/AP/SvP shall make the necessary arrangements to fulfil his obligation to enable the interception and delivery of the result of interception from the point in time when the telecommunication installation commences public service2) The above requirement applies accordingly to the introduction of modifications to the telecommunication installation or to new operational features for existing telecommunications services to the extent of their impact on existing interception capabilities.
3) When a lawful authorisation is presented a NWO/AP/SvP must co-operate immediately.
NOTE: Dutch law speaks of. "onverwijld"
4) After a lawful authorisation has been issued, provision of the results of interception of a target identity shall proceed on a real-time basis, within previously defined bounds.
5.5 Information Protection Requirements
The technical arrangements required within a telecommunication installation to allow implementation of the interception measures shall be realised with due care exercised in operating telecommunication installations, particularly with respect to:
1) In order to prevent or trace misuse of the interception installation, a NWO/AP/SvP shall ensure that any action in relation to a given identity shall be fully recorded, including any activation or application caused by faulty or unauthorised input.2) The records, shall cover at least:
a) the target identity of the target service or target services concernedb) the beginning and end of the activation or application of the interception measure
c) a reference to the lawful authorisation.
5.6 Unchanged State of Service, etc.
1) Interception shall be implemented and operated in such manner that no unauthorised person can detect any change from the unintercepted state.NOTE: Some discussion regarding traffic analysis took place. The outgoing interface on the IIF does provide some means for traffic analysis, but when RFC [1] is implemented correctly, this is acceptable.
2) Interception shall be implemented and operated in such manner that no telecommunicating parties can detect any change from t[ie unintercepted state. See Note at item 1.
3) The operating facilities of the target service shall not be altered as a result of any interception measure. The operating facilities of any other service shall not be altered as a result of any interception measure.
4) The quality of service of the target service shall not be altered as a result of any interception measure. The quality of service of any telecommunications service other than the target service shall not be altered as a result of any interception measure.
5.7 Technical Interface(s) and Format Requirements
1) The technical interface(s) shall provide the results of interception for the entire duration of the interception measure.2) The interface(s) need to be implemented in those telecommunication networks and services for which the interception capability is required by Dutch law.
3) The configuration of the interface(s) shall ensure that it provides the results of interception.
4) The configuration of the interface(s) shall ensure that the quality of service of the telecommunications traffic provided to the handover interface is not inferior to that offered to the target service for each particular session.
5) Each interception target shall be uniquely associated with a single instance of the handover interface. See also 5.1, item 6.
6) The correlation between the content of communication and intercept related information must be unique.
7) LEAs require that the intercepted telecommunications to the monitoring facility be transmitted only using the handover protocol defined in [1].
8) If an NWO/AP/SvP initiates encoding, compression or encryption of telecommunications traffic, LEAs require the NWO/AP/SvPs to provide intercepted telecommunications en clair. See also 5.2, item 2
9) The LEMF shall be informed of:
a) the activation of an intercept measureb) the deactivation of the intercept measure
c) any change of the intercept measure and
d) the temporary unavailability of the intercept measure.
5.8 Multiple points for delivery
1) The intercepted contents of a session shall be delivered to one or more LEMF's via interface HI3, the Interception Related Information shall be delivered through interface HI2. (See: [1])2) The receiving interface for the HI2 and HI3 interfaces on the side of the LEMF will change its IP address periodically for security reasons. The NWO/AP/SvP must be able to follow these changes within a period of no more than 12 hours.
3) The LEMF shall provide multiple addresses for its side of HI2 and HI3. The NWO/AP/SvP must be able to switch between these addresses without causing a gap in the traffic flow on either interface. A NWO/AP/SvP must change 6e delivery address if connections time out within the timeout bounds specified in [1].
4) The LEMF may revoke delivery addresses for interfaces HI2 and/or HI3. Any traffic from a NWO/AP/SvP to that address must seize immediately upon a notice of revocation. One of the alternate addresses must be used in this case without causing any gaps in the data traffic. If all addresses for a LEMF are revoked at once, traffic on the corresponding HI2 and HI3 interfaces should be buffered until a new address for this LEMF is received. HI2 traffic should be kept in case of a buffer overflow, even if H13 traffic should be deleted to create buffer space.
NOTE: If LEMF fails to deliver new destination addresses in time, causing a buffer overflow, a gap in interception content is acceptable. Interception Related Information shall be kept.NOTE: See also 5.9
5) The interface for address management is HI1, as defined in [1].
5.9 Temporary Obstacles to Transmission
When transmission to the LEMF of the content of communication is not possible, the remainder of the results of interception (e.g. intercept related information) shall nevertheless be provided to the LEA (see also subclause 5.4 item number 4.).
5.10 Identification of the identity to be intercepted
The lawful interception request shall be based on one or more of the following identifying characteristics:
1. Name and address information2. Account name
3. Email address
The NWO/AP/SvP shall ensure that the telecommunications traffic can be intercepted on the basis of one or more of these characteristics.
To be able to identify a user, the LEA can provide one or more of the following identifying characteristics:
1. The IP address and time stamp, including time zone.2. Other identification numbers where appropriate
NOTE: Meant here are identifiers like CLI, MAC address, A-nr of a telecommunications line3. A series of'connection time frames, authentication times, as long as they can identify an unique user.
If the query results in more than one target, the number of targets will be returned to the LEA.
5.11 Multiple interception measures
1) The NWO/AP/SvP shall ensure that more than one interception measure can be operated concurrently for one and the same identity. Multiple interceptions may be required for a single target service to allow monitoring by more than one LEA. Dutch law defines the minimum number of simultaneous interceptions with respect to the same interception subject.2) If multiple interceptions are active, NWO/AP/SvP shall take all necessary precautions to safeguard the identities of the monitoring agencies and ensure the confidentiality of the investigations.
NOTE: this implies that no LEA may learn of any interception measures in place for any other LEA
NOTE: Questions to be answered: What about handing over logs to LEA? Only by means of RC or Landelijk OvJ? As these are organisational questions they may be answered later.
6.1 IP interception scenario
In this section cases where the interception takes place on the IP side of the communication (regardless whether the target is located on the calling or called side) will be addressed.
In the IP interception scenario, the format of the interception contents is defined by RFC 791, also known as IPv4 [2], RFC 792 (ICMPv4) 15], RFC 2460 also known as IPv6 [3] and RFC 2463, (ICMPv6) [6]. In this scenario, these formats will be addressed as "IP traffic".
All IP traffic containing the IP address of the interception subject as either source or destination address as defined in [2], [3], [5] or [6] shall be lawfully interceptable.
6.2 Email interception scenario
In this section, interception of email messages directed to the target will be addressed.
6.2.1 Definition of email interception
In this context, every email message, see [4], that the MTA processes where the argument to the "RCPT TO" command contains the email address, or one of the email addresses, belonging to the interception subject, should be lawfully interceptable.
The communication that should be intercepted, is all traffic from the DATA command to the closing "." when a message is processed by the MTA.
6.2.2 Moment of interception
The moment of interception shall take place at the moment where the message is processed by the MTA operated by or on behalf of the NWO/AP/SvP for further delivery or storage in the targets mailbox.
The moment the target takes action to read or manage the contents of the mailbox, this action shall be logged. The logging is to be delivered to the LEA by means of the handover interface without delay [1]. Logging should at least contain date, time, account name, targets action and IP address used by the target
NOTE: Target ' can "POP" his email or read his email by means of a web access to the "POP box" is the event to be logged here.
NONE
Document history
March 21, 2000 V0.0.1 Initial draft from DTR/TIPHON-03008 VO.O.6 (1999-07).
March 21, 2000 V0.0.2 Added GOVTech opinions
March 24, 2000 V0.0.5 First official draft
March 27, 2000 V0.0.7 Commentaar n.a.v. WAITech vergadering 000327
March 27, 2000 V0.0.7-E Commentaar dienst, ingevuld door EvdL
March 29, 2000 V0.0.8 Cleanup, samenvoegen commentaren
April 07, 2000 V0.0.9 Verwerkt commentaar nav 29/3/2000
April 8, 2000 V0.0.10 References, translated Dutch comments, clarifications
April 8, 2000 V0.0.11 Committed proposed changes in V0.0.10
April 9, 2000 V0.1.0 Official release
May 31, 2000 V0.1.1 Result after discussion, final version?
May 31, 2000 V0.1.2 Final, pre-release for syntax checking only
June 13, 2000 V1.0 Final, still editorial typo's are left.
June 13, 2000 V1.0.1 Final official release
HTML by Cryptome.