1. ------IND- 2020 0810 D-- EN- ------ 20210118 --- --- PROJET
German Federal
Network Agency
Federal Network Agency
for Electricity, Gas, Telecommunications,
Post and Railways
__________________________________________
Technical Guideline
for the implementation of legal measures for the
surveillance of telecommunications and the
disclosure of information (TR TKÜV) *
Edition 7.2
As at: Draft
Editor and publisher:
Federal Network Agency for Electricity, Gas, Telecommunications, Post and Railways
Telecommunications and Postal Services Security Unit, technical implementation of surveillance
measures
Canisiusstraße 21
55122 Mainz
Germany
* Notified in accordance with Directive (EU) 2015/1535 of the European Parliament and of the Council of 9 September 2015 laying
down a procedure for the provision of information in the field of technical regulations and of rules on Information Society services
(OJ L 241, 17 September 2015, p. 1).
TR TKÜV, edition 7.2 (draft) Page 3
Table of contents
1 Scope of regulation ....................................................................................................6
2 Content of the present edition of the Technical Guideline.........................................6
3 Terms and definitions ................................................................................................6
4 Referenced standards ...............................................................................................7
Part A Technical implementation of legal measures for the surveillance of
telecommunications ................................................................................................ 12
1 Basic principles ....................................................................................................... 13
2 Structure ................................................................................................................. 13
3 Fundamental requirements ..................................................................................... 14
4 Other requirements ................................................................................................. 21
Appendix A Fundamental stipulations concerning data transmission........................................ 24
Appendix A.1 FTP and TCP/IP specifications ............................................................................... 24
Appendix A.2 Stipulations regarding participation in a VPN ......................................................... 27
Appendix A.3 Transmission of HI1 and additional events............................................................. 28
Appendix A.4 Difficulties in transmission of the surveillance copy to the authorised agency’s lines
................................................................................................................................ 35
Appendix B (Deleted: Transmission point for circuit-switched networks (national)) .................. 37
Appendix C Provisions for PSTN and ISDN (ETSI ES 201 671 or TS 101 671) ....................... 38
Appendix C.1 Selection of options and stipulation of additional technical requirements .............. 39
Appendix C.2 Explanations of the ASN.1 descriptions ................................................................. 42
Appendix D Specifications regarding mobile telephony networks and mobile-based IMS
platforms (3GPP TS 33.108 and TS 33.128).......................................................... 43
Annex D.1 Selection of options and determination of additional technical requirements ........ 45
Appendix D.2 Explanations of the ASN.1 descriptions ................................................................. 51
Appendix E Transmission point for storage systems for voice, facsimile and data (voice-mail
systems, Unified Messaging Systems, etc.) ........................................................... 53
Appendix E.1 Definitions ............................................................................................................... 53
Appendix E.2 General explanations .............................................................................................. 53
Appendix E.3 Basic forwarding methods and determination of relevant events ........................... 54
Appendix E.4 Requirements for surveillance of voice and fax messages and SMS according to
Appendices B, C or D ............................................................................................. 55
Appendix E.5 Requirements for surveillance of voice and fax messages, SMS and MMS in an
XML-encoded file .................................................................................................... 57
Appendix F Stipulations for storage systems for the e-mail service .......................................... 61
Appendix F.1 Definitions, fundamentals ....................................................................................... 61
Appendix F.2 Nationally specified e-mail transmission point ........................................................ 62
Appendix F.3 E-mail transmission point according to ETSI TS 102 232-02 (from Version 2.1.1) 67
Appendix G Stipulations regarding the Internet gateway (ETSI TS 102 232-03, 102 232-04 and
TS 101 909-20-2) .................................................................................................... 71
Appendix G.1 Selection of options and stipulation of additional technical requirements .............. 71
Appendix G.2 Explanations of the ASN.1 descriptions ................................................................. 75
Appendix H Specifications regarding VoIP, other multimedia services in landline networks and
landline-based IMS platforms (ETSI TS 102 232-05, 102 232-06 and 101 909-20-1)
................................................................................................................................ 76
TR TKÜV, edition 7.2 (draft) Page 4
Appendix H.1 Fundamental requirements for use of ‘Service-specific details for IP multimedia
services´ (TS 102 232-05 and TS 101 909-20-1) ................................................... 76
Appendix H.2 Fundamental requirements for use of ‘Service-specific details for
PSTN/ISDN services’ (ETSI TS 102 232-06) ......................................................... 78
Appendix H.3 Selection of options and stipulation of additional technical requirements .............. 78
Appendix H.3.1 Basis: ETSI TS 102 232-01 .................................................................................... 78
Appendix H.3.2 Basis: ETSI TS 102 232-05 .................................................................................... 81
Appendix H.4 Explanations of the ASN.1 descriptions ................................................................. 84
Appendix I Provisions for messaging services (ETSI TS 103 707 and ETSI TS 102 232-02) . 86
Part B Technical implementation of legal measures for the disclosure of information ...... 88
1 Basic principles ....................................................................................................... 89
2 Transmission methods ETSI-ESB and E-Mail-ESB ............................................... 89
3 Guaranteeing data security and data quality .......................................................... 90
Appendix A ETSI-ESB transmission method ............................................................................. 94
1.1 Basic description of procedure ............................................................................... 94
1.2 Procedural requirements ........................................................................................ 95
1.3 Specifics of the different applications ..................................................................... 96
1.4 Secure electronic transmission of the surveillance order ..................................... 101
2 Provisions for the transmission point according to ETSI Specification TS 102 657
.............................................................................................................................. 101
2.1 Selection of options for ETSI TS 102 657 ............................................................ 102
2.2 Supplementary technical requirements for the interface specification under ETSI
TS 102 657 ........................................................................................................... 104
3 Definition of national parameters .......................................................................... 108
3.1 General ................................................................................................................. 108
3.2 Description of the national XML module ‘Natparas2’ (for requests) ..................... 108
3.3 Description of the national XML module ‘Natparas3’ (for responses) .................. 114
3.3.2 Specification of additional data in the national XML module Natparas3 .............. 114
4 Transmission of accounting information or submitting claims for compensation
pursuant to § 23(1) of the German Judicial Remuneration and Compensation Act
.............................................................................................................................. 118
4.1 Basic principles ..................................................................................................... 118
4.2 Methods of electronic transmission ...................................................................... 118
4.3 Description of the national XML module ‘Natparas2’ (for accounts data) ............ 119
Appendix A.1 Explanatory notes on the procedure ..................................................................... 120
Appendix A.1.1 Fundamental flow of communication .................................................................... 120
Appendix A.1.2 Stipulations regarding participation in the IP VPN using a cryptosystem ............. 124
Appendix B E-Mail-ESB transmission procedure ..................................................................... 126
1. Basic description of the procedure ....................................................................... 126
Part X Informative Appendix ............................................................................................ 128
Appendix X.1 Proposed changes to the TR TKÜV ..................................................................... 128
Appendix X.2 Assignment of identifiers for authorised agencies to ensure uniqueness of
reference numbers................................................................................................ 131
Appendix X.3 Provisions for the registration and certification authority TKÜV-CA of the Federal
Network Agency, Department IS16 (Policy) ......................................................... 132
TR TKÜV, edition 7.2 (draft) Page 5
1 General ................................................................................................................. 132
2 Services provided by the TKÜV-CA ..................................................................... 132
3 Requirements for participants ............................................................................... 133
4 Rules for registration............................................................................................. 133
5 Rules for certification ............................................................................................ 134
6 Disabling a smart card .......................................................................................... 137
7 Revocation of certificates...................................................................................... 137
8 Distribution and handling of smart cards .............................................................. 138
9 Card content ......................................................................................................... 138
10 Management of cryptosystems/selection of options ............................................. 139
11 Selection of options/values ................................................................................... 140
12 Other applicable documents ................................................................................. 141
Appendix X.4 Table of applicable ETSI/3GPP standards and specifications as well as the
ASN.1 modules ..................................................................................................... 142
Appendix X.5 Standard concept for the preparation of verification documents, test records and
test reports for verification testing ......................................................................... 144
Updates 145
Version list 145
TR TKÜV, edition 7.2 (draft) Page 6
1 Scope of regulation
The Technical Guideline [TR TKÜV] sets out technical details for implementing legal measures for
telecommunications surveillance and information disclosure on the basis of § 110(3) of the
Telecommunications Act [TKG] [21], in conjunction with § 36 TKÜV [14], in consideration of §§ 96, 113(5)
and 113c(3) TKG.
The TR TKÜV is to be prepared in accordance with § 110(3) of the Telecommunications Act, in
conjunction with § 36 TKÜV, by the Federal Network Agency in consultation with the authorised agencies
and with the participation of the associations of the subjects and manufacturers of the surveillance
equipment and the recording and analysis equipment. International standards are to be taken into
account, with reasons given for deviations from the standards. The Technical Guideline is to be published
on the website of the Federal Network Agency; the agency must announce the publication in its official
journal.
Amendments to the TR TKÜV to conform with the current state of the art are to be undertaken by the
Federal Network Agency in the same process.
The TR TKÜV can normally define the dates up to which previous technical regulations may still be
applied. It also lays down the types of identifiers for which the prevailing legislation on the surveillance of
telecommunication systems requires additional measures for the technical implementation of orders to be
taken in certain types of telecommunication systems in addition to the target and source addresses used
in them. In cases where recent technical developments have not yet been incorporated into the
TR TKÜV, the obligated party shall coordinate the design of his/her surveillance systems with the Federal
Network Agency.
2 Content of the present edition of the Technical Guideline
The first edition of the Technical Guideline was published in December 1995 as TR FÜV, edition 1.0.
Over the past 20 years, it has been continuously amended in line with fresh legislation and to adapt to
new technological developments; the current 17th edition of the Technical Guideline is published as
TR TKÜV, edition 7.2.
Edition 7.2 differs from the preceding edition, TR TKÜV, edition 7.1, mainly as a result of changes
necessitated due to the updating of the European and international standards already being applied in the
Guideline.
The TR TKÜV, edition 7.2, includes the following three Parts A, B and X:
Part A – Technical implementation of legal measures for the surveillance of
telecommunications
This section describes the technical details of the surveillance equipment and the required
technical characteristics of recording lines.
Part B – Technical implementation of legal measures for the disclosure of information
This section contains the technical details of the devices for inventory and traffic data retrieval,
and particularly the optional procedure for transmission of the copy of the order to implement
such measures.
Part X – Informative Annex
This informative section contains the planned further changes to the TR TKÜV which are to form
the basis for a discussion of the next edition, supplementary information relating to Parts A and B
of this edition, regulations for the registration and certification body TKÜV-CA and a history of the
individual editions of the TR TKÜV published so far.
The differences compared with edition 7.1 are set out in Part X under ‘Updates’.
3 Terms and definitions
In addition to the definitions in the TKÜV, the following definitions also apply in this Guideline:
3.1 Content of telecommunications (informational content, content of
communication, CC)
The portion of telecommunication under surveillance containing informational content exchanged
between the subscribers or their end devices (e.g. voice, e-mail or IP traffic).
TR TKÜV, edition 7.2 (draft) Page 7
3.2 Event data (Intercept-Related Information, IRI)
Data to be supplied pursuant to § 7 of the TKÜV on detailed circumstances associated with the
telecommunication under surveillance. These data should also be supplied if the telecommunication
content fails to be transmitted (e.g. on user busy).
3.3 Surveillance copy
Pursuant to § 2 point 14 of the TKÜV, the copy of the telecommunication under surveillance required to
be transmitted (content of communication and event data).
3.4 Internet gateway
The transmission channel which provided direct subscriber access to the Internet, as defined in § 2 point
12, in conjunction with § 3(2) point 3, of the TKÜV.
3.5 Subject’s telecommunication system (STS)
Normally the subject’s telecommunication system, in which the telecommunications on the line under
surveillance originates - in the case of outgoing traffic - or terminates - in the case of incoming traffic (e.g.
subscriber switching centre, UMS, email server).
3.6 Transit network
The network through which the surveillance copy (informational content and/or event data) is transmitted
from the subject’s telecommunication system to the authorised agency.
3.7 Concept
Documents according to § 110(1) sentence 1 point 3a of the Telecommunications Act.
4 Referenced standards
The table below lists the standards referenced in the TR TKÜV:
[1] ETS 300 007 Integrated Services Digital Network (ISDN); Support of packet-mode
(ITU- X.31) terminal equipment by an ISDN
[2] ETS 300 011 ISDN; Primary rate user-network interface, Layer 1 specification and test
principles
[3] ETS 300 012 ISDN; Basic user-network interface, Layer 1 specification and test
principles
[4] ETS 300 090 ISDN; Calling line identification restriction (CLIR) supplementary service;
Service description
[5] ETS 300 094 ISDN; Connected line identification presentation (COLP) supplementary
service; Service description
[6] EN 300 403-1 ISDN; user network interface layer 3, specification for basic connection
control procedures
[7] ETS 300 108 ISDN; Circuit-mode 64 Kbit/s unrestricted 8 kHz structured bearer service
category; Service description
[8] ETS 300 133-X Paging Systems (PS); European Radio Message System (ERMES)
Parts 1 - 4
[9] ETS 300 136 ISDN; Closed User Group (CUG) supplementary service; Service
description
[10] ETS 300 383 ISDN; File transfer over the ISDN EUROFILE transfer profile
[11] ETS 300 409 ISDN; Eurofile transfer teleservice; Service description
[12] ETS 300 485 ISDN; Use of cause and location in DSS1 and ISUP (ITU-T Rec. Q.850
(1993, modified)
[13] ETS 300 523 European digital cellular telecommunications system (Phase 2);
Numbering, addressing and identification (GSM 03.03)
[14] TKÜV Ordinance on the technical and organisational implementation of
measures for the surveillance of telecommunications
TR TKÜV, edition 7.2 (draft) Page 8
(Telecommunications Surveillance Ordinance – Telekommunikations-
Überwachungsverordnung, TKÜV])
[15] ISO/IEC 8571 File Transfer, Access and Management
[16] ISO/IEC ISP 10607-1 File Transfer, Access and Management; Part 1: Specification of ACSE,
Presentation and Session Protocols for the use of FTAM
[17] ISO/IEC ISP 10607-3 File Transfer, Access and Management; Part 3: Simple File Transfer
Service (unstructured)
[18] ITU-T G.711 Pulse Code Modulation (PCM) of Voice Frequencies
[19] ITU-T H.221 Line Transmission of non-Telephone Signals; Frame Structure for a 64 to
1920 Kbit/s Channel in audiovisual Teleservices
[20] ITU-T X.25 Interface between data terminal equipment (DTE) and data circuit-
terminating equipment (DCE) for terminals operating in the packet mode
and connected to public data networks by dedicated circuit
[21] TKG Telecommunications Act [Telekommunikationsgesetz]
[22] ES 201 671/TS 101 Telecommunications security; Lawful Interception (LI); Handover interface
671 for the lawful interception of telecommunications traffic
[23] 3GPP TS 33.108 3G security; Handover interface for Lawful Interception (LI) (ETSI TS 133
108)
[24] RFC 822 Standard for the Format of ARPA Internet Text Messages
[25] RFC 2822 Internet Message Format
[26] RFC 2045 Multipurpose Internet Mail Extensions, (MIME) - Format of Internet
Message Bodies
[27] RFC 2060 Internet Message Access Protocol - Version 4rev1
[28] RFC 3261 SIP: Session Initiation Protocol. June 2002.
[29] TS 102 232 bzw. Telecommunications security; Lawful Interception (LI); Handover
TS 102 232-01 specification for IP delivery
[30] TS 102 233 bzw. Telecommunications security; Lawful Interception (LI); Service specific
TS 102 232-02 details for E-mail services
[31] TS 102 234 bzw. Telecommunications security; Lawful Interception (LI); Service-specific
TS 102 232-03 details for internet access services
[32] TS 102 815 bzw. Telecommunications security; Lawful Interception (LI); Service-specific
TS 102 232-04 details for Layer 2 Lawful Interception
[33] TS 101 909-20-2 Digital Broadband Cable Access to the Public Telecommunications
Network;
IP Multimedia Time Critical Services;
Part 20: Lawful Interception; Sub-part 2: Streamed multimedia services
[34] TS 102 232-05 Telecommunications security; Lawful Interception (LI); Service specific
details for IP Multimedia Services
[35] TS 102 232-06 Telecommunications security; Lawful Interception (LI); Service specific
details for PSTN/ISDN services
[36] TS 101 909-20-1 Digital Broadband Cable Access to the Public Telecommunications
Network;
IP Multimedia Time Critical Services;
Part 20: Lawful Interception; Sub-part 1: CMS based Voice Telephony
Services
[37] TS 102 657 Telecommunications security; Lawful Interception (LI); Retained data
handling; Handover interface for the request and delivery of retained data
[38] TS 103 120 Lawful Interception (LI); Interface for warrant information
[39] TS 103 707 Lawful Interception (LI); Handover for messaging services over
HTTP/XML
[40] 3GPP TS 33.128 Security; Protocol and procedures for Lawful Interception (LI); Stage 3
(ETSI TS 133 128)
TR TKÜV, edition 7.2 (draft) Page 9
5 Abbreviations
The following abbreviations are used in the TR TKÜV:
ASCII American National Standard Code for Information Interchange
ASN.1 Abstract Syntax Notation One
BA ISDN-Basisanschluss
BC Bearer Capability
BMWi Federal Ministry for Economic Affairs and Energy
bS berechtigte Stelle
BSI Federal Office for Information Security
BSS Base Station Subsystem
CC Content of Communication
CLIP/R Calling Line Identification Presentation / Restriction
COLP/R Connected Line Identification Presentation / Restriction
CUG Closed User Group
DCF77 Mainflingen time code transmitter broadcasting the official time for the Federal Republic
of Germany as produced by the Federal Technical Physics Institute (PTB) at a
frequency of 77.5 kHz
DCS Digital Cellular System
DDI Direct Dialing In
DM Service attribute
DSS1 Digital Subscriber Signalling System Nr. 1
DTD Document Type Definition
ERMES European Radio Message System
ESB Specification of the electronic interface for information and connection data disclosure
requests and telecommunications surveillance and tracing
ETSI European Telecommunications Standards Institute
FTAM File Transfer, Access and Management
FTP File Transfer Protocol
GLI Global Line Identifier
GLIC GPRS Lawful Interception Correlation
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
GUTI Globally Unique Temporary UE Identity
HI Handover Interface
HLC High Layer Compatibility
IMAP Internet Message Access Protocol
IMEI International Mobile station Equipment Identity
IMS IP Multimedia Subsystem
IMPI IP Multimedia Private Identity
IMPU IP Multimedia PUblic Identity
IMSI International Mobile Subscriber Identity
IN Intelligentes Netz
IP Internet Protocol
IPS Internet Protocol Stack
IRI Intercept Related Information
ISDN Integrated Services Digital Network
TR TKÜV, edition 7.2 (draft) Page 10
ITU-T International Telecommunication Union - Telecommunication Standardization Sector
LDAP Lightweight Directory Access Protocol
LEA Law Enforcement Agencies
LI Lawful Interception
LLC Low Layer Compatibility
LTE Long Term Evolution
LTMP Local Mail Transfer Protocol
MAP Mobile Application Part
MMS Multimedia Messaging Service
MSC Mobile Switching Center
MSISDN Mobile Subscriber ISDN Number
MSN Multiple Subscriber Number
NCI NR Cell Identity
NEID Network Element Identifier
NR New radio
OID Object Identifier
PEI Permanent Equipment Identifier
PMXA ISDN primary rate interface
POP3 Post Office Protocol 3
PSTN Public Switched Telephone Network
(analogue telephone network or analogue connections to digital hubs)
PTB Federal Technical Physics Institute
SIP Session Initiation Protocol
SMS Short Message Service
SMTP Simple Mail Transfer Protocol
SUB SUBaddressing (supplementary service)
SUCI Subscriber Concealed Identifier
SUPI Subscriber Permanent Identifier
TCP Transport Control Protocol
TFTS Terrestrial Flight Telecommunication System
TKA-V Telecommunication System of the subject
TKG Telecommunications Act [Telekommunikationsgesetz]
TKÜV Telecommunications Surveillance Ordinance
UDI Unrestricted digital information
UMS Unified-Messaging-System
UMTS Universal Mobile Telecommunications System
UPT Universal Personal Telecommunication
URI Uniform Resource Identifier
URL Uniform Resource Locator
UTF-8 8-bit Unicode Transformation Format (RFC 3629, ISO 10646)
UTM Universale Transversale Mercator-Projektion (Coordinates)
VoIP Voice over IP
VoLTE Voice over LTE
VMS Voice Mail System
VPN Virtual Private Network
WGS World Geographic System
TR TKÜV, edition 7.2 (draft) Page 11
XML Extensible Markup Language
ZGS Signalling system
züA Line or identifier under surveillance
TR TKÜV, edition 7.2 (draft) Part A, page 12
Part A Technical implementation of legal
measures for the surveillance of
telecommunications
TR TKÜV, edition 7.2 (draft) Part A, page 13
1 Basic principles
This Part A of the Technical Guideline (TR TKÜV) describes the technical details of surveillance systems
and the required technical characteristics of recording lines, pursuant to § 110(3) of the TKG [21], in
conjunction with § 36 of the TKÜV [14].
Finally, it lays down the types of identifiers for which the prevailing legislation on the surveillance of
telecommunication systems requires additional measures for the technical implementation of surveillance
actions to be taken in certain types of telecommunication systems in addition to the target and source
addresses used in them.
In cases where recent technical developments have not yet been incorporated into the TR TKÜV, the
subject shall coordinate the design of his/her surveillance systems with the Federal Network Agency.
2 Structure
Dividing Part A into the following sections assists in the most straightforward possible allocation of the
technical requirement to the various telecommunication systems or services. To this end, the system- or
service-specific requirements (such as for ISDN networks, Internet gateways, or servers for the e-mail
service) are described in separate appendices, which can be used in conjunction with the fundamental
and other requirements, as a separate description of the requirement for a specific transmission point:
Basic requirements
These requirements apply equally to all transmission points and are presented in Chapters 5 and
6.
Other requirements
Where required, the other subjects mentioned in § 36 of the TKÜV in addition to the technical
requirements for transmission points may be included in the provisions of the TR TKÜV. These
can be found in Chapter 6.
System- or service-specific requirements
The exact requirements for the design of system- or service-specific transmission points can be
found in the respective appendices. Appendix A contains provisions on permitted transmission
methods.
2.1 Overview of system- or service-specific appendices and the
informational part
This part of the TR TKÜV describes the transmission point for services in landline and mobile networks
(e.g. GSM, UMTS, VoLTE and VoIP), other multimedia services, e-mail and for the Internet gateway.
The description of the relevant transmission point is given in the following appendices to the TR TKÜV:
Appendix Contents
Appendix A.1 The FTP transmission method (file name, parameters)
Appendix A.2 Participation in a VPN via a cryptosystem
Appendix A.3 Transmission of HI1 events and additional events
Appendix A.4 Difficulties in transmission of the surveillance copy to the connections of the authorised agency
(AA)
Appendix B This Appendix has been deleted; the descriptions can be found in the TR TKÜV editions up to
edition 7.0. Existing implementations according to Annex B shall be permitted until 31 December
2021, after which date these will be converted to forwarding via FTP. Forwarding via X.25/X.31
in accordance with this annex has not been permitted since 1 January 2018.
Circuit-switched networks are subject to the descriptions under Annex C.
Appendix C Specifications for circuit-switched fixed-line networks (PSTN and ISDN) according to the
ETSI Standard ES 201 671 or the ETSI specification TS 101 671 [22]. This implementation shall
only be permitted until 31 December 2021; between now and then, it must be converted to
forwarding in accordance with Annex H.
Appendix D Specifications for mobile networks and mobile-based IMS platforms in accordance with 3GPP
Specification TS 33.108 [23] and TS 33.128 [40].
Appendix E Provisions for storage devices (UMS, VMS, etc.) for voice, fax, SMS, MMS, etc. As these types
of systems are not taken into account in the provisions in Appendices A to D, these requirements
may also need to be complied with.
TR TKÜV, edition 7.2 (draft) Part A, page 14
Appendix F Specifications for the e-mail service under national requirements or the ETSI specification TS
102 232-02 [30]
Appendix G Specifications for direct subscriber access to the Internet according to the ETSI specifications
TS 102 232-03 [31], TS 102 232-04 [32] or TS 101 909-20-2 [33]
Appendix H Specifications for VoIP, other multimedia services in landline networks and landline-based IMS
platforms according to ETSI Specifications TS 102 232-05 [34], TS 102 232-06 [35] and
TS 101 909-20-1 [36]
Appendix I Specifications for messaging services according to ETSI specifications TS 102 232-2 [30] and
TS 103 707 [39]
Reference is also made to the following appendices in Part X of the TR TKÜV:
Appendix Contents
Appendix X.1 Proposed changes to the TR TKÜV
Appendix X.2 Assignment of identifiers to authorised agencies to ensure uniqueness of reference numbers
Appendix X.3 Provisions for the registration and certification authority TKÜV-CA of the Federal Network
Agency, Department IS16 (Policy)
Appendix X.4 Table of applicable ETSI/3GPP standards and specifications as well as the ASN.1 modules
Appendix X.5 Requirements for administration and logging in the organisational implementation of surveillance
actions
3 Fundamental requirements
This Technical Guideline lays down the technical details required to ensure comprehensive recording of
telecommunication under surveillance and to set up appropriate transmission points to the authorised
agencies.
The requirements arising directly from the provisions of the TKÜV should also be complied with.
3.1 Transmission of the surveillance copy
The telecommunication under surveillance is composed of informational content and event data.
Telecommunications should fundamentally also be monitored even when it is rerouted or forwarded to
another target address.
NB:
This requirement applies, for example, to telephony service attributes such as call forwarding or call
deflection, where the connection is forwarded either by the network or the terminal of the LuS. Here,
the surveillance copy should be forwarded to the authorised agency for as long as the forwarded
connection remains. E-mail messages must also be monitored when automatically forwarded to
another e-mail address of a different mailbox. When the transmission of an existing
telecommunication is individually instigated by the LuS (e.g. by explicit call transfer (ECT)), the
transmission of the copy of the telecommunication to the authorised agency has to cease as soon as
the connection between network and LuS is triggered.
The event data must be compiled and transmitted to the authorised agency in real time, i.e. immediately
after the relevant event (e.g. beginning of a telecommunication, use of a service attribute for data
transmission). Where required, several similar events (e.g. in sequential dialling) may be combined into a
single data set for transmission. Specifically, an event data set with the relevant data should be
transmitted at the start and end of a telecommunication under surveillance, as well as with each event
during the telecommunication (e.g. activities in connection with a service attribute).
The events also include registration/activation processes for service attributes, provided these operation
options are controlled directly (e.g. by means of the telephone connection of the line under surveillance).
In addition to the standard case, i.e. transmission of the informational content together with real-time
transmission of event data, it should be possible, at the request of the authorised agency, in the case of a
particular surveillance action, to transmit only the event data to the authorised agency, but not the copy of
the associated informational content. In this case, no ISDN connections to the authorised agency should be
made when, for instance, monitoring circuit-switched telecommunications.
The connections made for transmission of the surveillance copy should be closed immediately after
successful transmission, i.e. access lines to the authorised agency should not be kept occupied for longer
than necessary.
TR TKÜV, edition 7.2 (draft) Part A, page 15
In transmissions, informational content and associated event data should be labelled such that they can
be unambiguously matched to each other (§ 7(2) of the TKÜV). To this end, each surveillance action is
assigned a reference number. In addition, individual connections made in the context of a surveillance
action should be assigned an allocation number which is unique for the relevant connection.
In case of difficulties in transmission of the surveillance copy, the event data should be transmitted later in
any case (Appendix A.4).
3.1.1 General requirements for circuit-switched networks (PSTN and ISDN)
The requirements for the design of the transmission point for PSTN and ISDN are derived from Appendix
C and relate to the ETSI Standard ES 201 671 or the ETSI Specification TS 101 671 [22].
To transmit the copy of the informational content, it should be forwarded via the Internet (RTP) or dial-up
connections may still be used until 31 December 2021.
In accordance with Appendix C, the event data are sent online via FTP in an ASN.1-encoded file.
The special requirements below shall apply when carrying out ISDN-based forwarding under
Appendices C and D (and former Appendix B where the forwarding has been converted to FTP): For
the transmission of the copy of the informational content, the STS sets up two transparent dial-up
connections to the authorised agency (circuit mode 64 kbit/s unrestricted, ETS 300 108 [7]),
independent of the service requested by the line under surveillance (LuS) or its telecommunication
partner upon call origination requests; one of these connections transmits to the technical
installations of the authorised agency a copy of the informational content sent by the LuS, the other a
copy of the informational content sent to the LuS. Thus, transmission to the authorised agency of the
copy of the informational content is separated directionally.
NB: When using the ‘large conference’ (CONF) service attribute, the informational content sent to the
LuS shall be considered to comprise the informational content sent by all the other participants (sum
signal). The copy of the telecommunications sent by the LuS (individual signal of the LuS) should be
transmitted to the authorised agency over the second connection.
If the informational content of the LuS consists of voice, then it should be presented to the authorised
agency in accordance with ITU-T Recommendation G.711 A-law. Network encodings should be
removed.
Note 1: If other technologies are used by the STS to transmit the voice information (e.g. using ‘half
rate speech transcoding’ in GSM), or if compression technology is used to allow multiplexed use of
channels, then the STS should transcode such voice information to an encoding in accordance with
ITU-T Recommendation G.711, A-law [18] for use by the authorised agency.
Note 2: Voice transmission is possible not only in the standard (3.1 kHz) telephony service, but also
in other services, e.g. in video telephony and in the 7 kHz telephony service. Here, the user’s end
device sets up a frame in the 64 kbit/s B channel(s) (e.g. according to
ITU-T Recommendation H.221 [19]), which is then filled with the relevant information (voice, image,
data). This content is not decoded by the STS, but by the technical installations of the authorised
agency.
The connections to the lines of the relevant authorised agency used to transmit the copy of the
informational content should always be created by the STS immediately after detection of the start of
a telecommunication under surveillance, i.e. nearly concurrently with the creation of the connection
to or from the LuS, and closed immediately after detection of the end of the telecommunication under
surveillance.
NB: As an example, the start of an ISDN connection should be taken not as the time when the called
line replies and the content channel is transferred, but already from the start of signalling (receipt of a
SETUP message by the STS for outgoing connections in ISDN or GSM, circuit closure on the
subscriber line in PSTN). Only by creating a connection to the authorised agency early on, from the
start of signalling, can a potential loss of parts of the content at the beginning of the connection be
avoided.
The creation of a connection from the LuS to its telecommunication partner or vice versa should not
be delayed, even if the creation of the connection to the authorised agency is delayed (e.g. due to
repeated connection attempts).
The lines of the STS on which the surveillance copy is transmitted to the authorised agency should
be set up for outgoing connections only on the side of the subject. To safeguard transmission of the
TR TKÜV, edition 7.2 (draft) Part A, page 16
surveillance copy at all times, the lines of the authorised agencies should be operated exclusively for
incoming traffic.
The lines of the authorised agency should be designed in accordance with the technology used to
transmit the surveillance copy. Where technically possible for the particular type of
telecommunication under surveillance, the telecommunication under surveillance (informational
content and event data) should be directed to the EURO ISDN primary rate interfaces (PRIs) or
EURO ISDN basis lines (BA) according to ETS 300 012 [3] available at the authorised agencies. In
addition, the authorised agency will set up automated answering systems so that the calling phase is
not required for these connections.
The connections used to transmit the copy of the telecommunication under surveillance to the
relevant authorised agency are created by the STS as needed. The creation of the connection is
initiated by the STS. If (a) circuit-switched connection(s) to the authorised agency for the
transmission of the content should fail to be created, three further connection attempts will be
undertaken at intervals of 5 to 10 seconds.
3.1.2 General requirements for mobile networks and mobile-based IMS
platforms
The requirements for the design of the transmission point are fundamentally derived from Appendix D and
relate to 3GPP specifications TS 33.108 [23] and TS 33.128 [40].
Existing systems must be converted to TCP-based forwarding in accordance with 3GPP TS 33.108 or
33.128 by 31 December 2021 at the latest. For packet-switched voice services (e.g. VoLTE), combined
forwarding in accordance with 3GPP TS 33.108 or TS 33.128 and ETSI TS 102 232-5 (Appendix H) may
be used temporarily.
3.1.3 General requirements for storage systems for voice, fax and data
(voice-mail systems, Unified Messaging Systems,...)
If the subject offers his/her customers the option to store messages in voice memory or similar storage
systems associated with the LuS, copies of all messages stored in such systems or retrieved from them,
including the associated event data, should always be transmitted to the authorised agency. Changes in
settings, such as generating mailing lists, should also be reported.
Copies of informational content sent from these storage systems to the authorised agency are normally
transmitted to the same target number as the copy of the informational content sent by or to the LuS. If
the technical installations of the STS allow, the authorised agency should have the technical option, for
individual surveillance actions, of directing a copy of the informational content from such storage systems
to a different target number upon request from the authorised agency.
The technical details of the transmission point are contained in Appendix E.
3.1.4 General requirements for the e-mail service
Appendix F contains two alternative descriptions of a transmission point for surveillance of the e-mail
service:
transmission point under national rules pursuant to Appendix F.2
transmission point according to ETSI Specification TS 102 232-02 [30] pursuant to Appendix F.3.
3.1.5 General requirements for the Internet gateway
Pursuant to § 3 of the TKÜV, operators of transmission channels used to provide immediate subscriber
Internet access (e.g. Internet gateways over xDSL, CATV, WLAN) are required to implement measures
for surveillance of the entire IP traffic.
To ensure this, Appendix G comprises three options, based on ETSI specifications for forwarding
monitored IP data in layer 2, layer 3, or based on the IP Cablecom architecture.
3.1.6 General requirements for VoIP and other multimedia services
Appendix H addresses services based on the Session Initiation Protocol (SIP) and the Realtime
Transport Protocol (RTP) or the ITU-T standards H.323 and H.248, and also offers a possibility for so-
called emulated PSTN/ISDN services to transmit copies of telecommunications content over RTP instead
of ISDN dial-up connections.
TR TKÜV, edition 7.2 (draft) Part A, page 17
In addition, this Appendix addresses multimedia services provided via the IP Cablecom architecture.
3.1.7 General requirements for messaging services
Appendix I refers to messaging services provided over the Internet. The technical details described in this
Appendix , which are necessary to ensure the interception of these telecommunications services, shall
become mandatoryafter the entry into force of Article 1 (TKG) of the Act implementing Directive
(EU) 2018/1972 of the European Parliament and of the Council of 11 December 2018 establishing the
European Electronic Communications Code (recast) and modernising telecommunications law
(Telecommunications Modernisation Act) in conjunction with the transitional period set out in Appendix I.
3.2 Standard values
Pursuant to § 5(6) of the TKÜV, the administration system and capacities for forwarding the surveillance
copies to the authorised agency should be appropriately dimensioned in terms of the number of
surveillance actions expected to be implemented.
Implementing this requirement normally requires monitoring of the available surveillance and forwarding
capacity (interception point to Internet transmission point), particularly for bandwidth-based services. In
case of a large difference between the average bandwidth requirement of a connection and the maximum
available bandwidth, normally a higher level of utilisation of the monitored lines shall be assumed.
The relevant technical and organisational measures shall be described in the concept in accordance with
§ 19(2) point 5 of the TKÜV.
As a planning aid for initial dimensioning in the area of line provision, based on statistical data under the
assumptions given below, it is recommended allowing for at least the following:
1. that M independent surveillance actions can be simultaneously accommodated; and
2. that at least A of these can have their surveillance copies transmitted to the authorised agencies
at the same time.
Furthermore, any additional requirements should be detected in sufficient time (e.g. when a particular
load level is permanently reached) and the system should be extended accordingly.
The relationship is as follows:
M = a * x 0.45
A=V*M
where: M = number of surveillance actions which can be activated
a = system-specific factor
x = number of potential LuS
A = number of simultaneously transmittable surveillance copies
V = factor incorporating the traffic intensity on the relevant telecommunications
lines
The following assumptions apply to various types of telecommunication system:
a) for circuit-switched fixed networks (ISDN/PSTN) and systems for VoIP and other multimedia
services:
a= 0.75
x= total number of line units (LU), (e.g. analogue subscriber lines or B-channels of an
ISDN Basis or PRI) in a hub.
V= for the traffic intensity on monitored lines, it is recommended to assume three times the
traffic intensity on an average LU in a hub at peak times.
This formula should be applied separately to each hub.
TR TKÜV, edition 7.2 (draft) Part A, page 18
b) for circuit-switched services in mobile telephony networks (GSM and UMTS CS):
a= 0.75
x= total number of mobile lines supporting circuit-switched services.
V= for the traffic intensity on monitored lines, it is recommended to assume three times the
traffic intensity on an average mobile line at peak times.
Example of a switching centre according to letter a)
a = 0.75
x = 5 000 ISDN basis lines = 10 000 B-channels
M = 0.75 * 10.000 0.45
M = 47 surveillance measures which can be activated simultaneously
V = 0.24 if the average traffic intensity is 0.08
A = 0.24 * 47
A = 11 ISDN Basis lines to be simultaneously forwarded (two ISDN stubs each to the authorised agency)
3.3 Actions to provide the complete surveillance copy at the IP-based
transmission point
The obligated party should provide a complete copy of the telecommunication to the authorised agency in
accordance with § 5(2) of the TKÜV at the transmission point. The system must be designed pursuant to
§ 8(2) to ensure the quality of the surveillance copy provided at the transmission point is no poorer than
that of the telecommunication under surveillance. In addition to the copy of the telecommunication, the
obligated party must also provide the event data at the transmission point (§ 7 of the TKÜV).
The obligated party must use suitable precautions to ensure that the data concerned are complete
at the recording point of the copy of the telecommunication and of the event data,
on the transmission channel to the transmission point and
at the transmission point
(e.g. by means of adequate transmission capacity, redundancies, network-typical buffer
mechanisms, selection of the transmission procedure, monitoring of the transmission line, load-
balancing at the incoming delivery function, agreement of the MTU size).
(The delivery function here refers to the technical system receiving and processing the internal network
data and making it available at the transmission point.)
In the exceptional event that transmission of the data from the recording point to the transmission point is
impossible, the obligated party must transmit the event data later without delay as is also foreseen under
§ 10 of the TKÜV for the transmission of the data from the transmission point to the recording line. Where
the transmission protocol used on the line allows it (e.g. TCP), at the very least, a short-term buffering at
the recording point is to be provided for the copy of the telecommunication which is orientated to the
availability and load on the transmission line from the recording point up to the input for the delivery
function (DF3). If buffering is not possible (e.g. when using UDP), the transmission line should be
designed (e.g. by adequate dimensioning, redundancies) to ensure peak loads do not lead to loss of data.
Adequate dimensioning of the incoming bandwidth of the delivery function (DF3) is present when the
average data stream measured in 24 hours does not exceed 60 % of the maximum incoming bandwidth.
The incoming bandwidth available in the subject’s data network must also not be less than three times the
value of the customer line with the highest bandwidth. This should guarantee that a short-term rise in
bandwidth resulting from high use of a line under surveillance does not result in loss of data.
If the data are multiplied in the event of a multiple forwarding to the delivery function (DF3), the
corresponding additional requirements for processing and transmission capacity must be taken into
account when dimensioning. Otherwise multiple forwarding has to take place in the recording point.
The transmission point is defined in the TR TKÜV in accordance with § 8(1) of the TKÜV. Provision of the
copy of the telecommunication and the event data takes place in a TCP/IP-based transmission point via a
VPN-secured transmission channel to the recording lines of the authorised agency. To secure this
TR TKÜV, edition 7.2 (draft) Part A, page 19
TCP/IP-based transmission, at least the precautions mentioned below must be taken, referring to
forwarding in accordance with Appendices D, G and H (these precautions do not concern the
transmission of IRI by FTP).
3.3.1 Buffering
If, due to transmission problems between the transmission interface of the obligated party and the
authorised agency, it is impossible, without exception, to transmit the surveillance copy to the recording
line, the transmission must take place immediately afterwards. For these reasons, the surveillance copy
may be buffered (§ 10 sentence 3 of the TKÜV). This kind of buffering must meet the following
requirements:
The buffer size must be designed to fulfil a buffer period of 5 minutes. This corresponds to the
downtime until the VPN connection is re-established and also covers peak loads on the
transmission line that may arise in the internal network.
The size of buffer has to be dimensioned to enable the double volume of data transmitted on
average at the transmission point to be buffered.
After a fresh creation of the connection, data from the buffer must be transmitted by the
FIFO principle. The entire data stream is transmitted via a buffer by the FIFO principle. If the
maximum buffer size is reached or the buffer cannot be emptied, the oldest data in the buffer are to
be discarded after no more than 5 minutes. (In case data have to be discarded, this will ensure that
this is done in a coherent block)
The buffering must be designed so that the buffer time can be achieved for each TCP connection
created for the authorised agency (independently of the VPN connection) without the buffers of all
connections influencing each other (e.g. the simultaneous utilisation of another buffer in the event
of one buffer being overloaded). The design of a buffer whose size is adjusted dynamically, and
thereby achieves the same target as above, is also made possible, but has to be agreed with the
Federal Network Agency.
3.3.2 Determination of the MTU size
To avoid data packets becoming fragmented, which can result in increased load on the bandwidth, the
relevant packet sizes on the way from creation in the recording point of the subject must be defined up to
transmission of the prepared data to the secured transmission channel such that fragmentation is
prevented, particularly at the transmission point to the Internet (SINA Box).
The manufacturer Secunet specifies for transmission via the SINA Box an 80-byte overhead; an
additional 30 bytes must be taken into account when using NAT-T and 8 bytes when using PPPoE.
Based on the assumption that these circumstances regularly exist, the rule value for the MTU size of the
delivery function is set to 1380 bytes. However, the subject must check whether a lower or higher MTU
size must be set in order to optimise data transmission as well as to reduce fragmentation. However, the
MTU size must not exceed 1420 bytes (1500 bytes of data minus 80 bytes of SINA overhead). A test
(Federal Network Agency, LEMF) in order to also take account of possible fragmentation in the internal
network is urgently recommended. The recording ports of the authorised agencies must be capable of
accepting data packets up to this maximum size of 1420 bytes for the MTU size.
Where a joint interface is required for linking the network elements under surveillance and the SINA Box,
the respective values need to be harmonised and also agreed with the Federal Network Agency where
relevant.
The same applies if the network element supports jumbo frames because the MTU size used for this
cannot be used no later than between the delivery function and the SINA Box. Although jumbo frames are
supported by the SINA Boxes from version 3.x upwards, this support is currently unnecessary with the
use of the Internet as a transport network.
3.3.3 ‘Alive’ test of the availability of the transmission line
In order to monitor the availability of the transmission line between the obligated party and the authorised
agency, an "alive" test must be carried out in accordance with the requirements for the "keep alive"
(ETSI TS 102 232-1). The ‘alive’ test has to be activated for those authorised agencies which require it
from the obligated undertakings. In deviation from the ETSI rules, it must be possible for the authorised
agency not to send a ‘Response’ message. This is necessary because it is not always possible for
the authorised agency to send such messages for security reasons. The subject must therefore
TR TKÜV, edition 7.2 (draft) Part A, page 20
implement the following options, which can be configured for each of the monitoring centres of an
authorised agency:
The "alive" test is not used if requested by the authorised agency.
The ‘alive’ test is used and is answered by a ‘response’ message from the authorised agency; the
subject will acknowledge the lack of a ‘response’ message with a corresponding error message.
The ‘alive’ test is used and is in principle not answered by a ‘response’ message from
the authorised agency; the authorised agency carries out the analysis; the subject never
generates an error message. In this case, the authorised agency notifies the subject of the
misbehaviour.
The ‘alive’ test must be carried out independently of any possible forwarding.
The following times must be accounted for:
sending an "alive" test: every 60 minutes,
answering an "alive" test by a "response" message: within 30 seconds,
period during which the obligated party may expect a "response" message after sending an
"alive" test: 60 seconds.
3.3.4 Standardised error messages (HI1 messages)
To achieve improved analysis of the error messages, their content and format are specified as follows:
1. In the event of data loss (where it can be established):
Data losses attributable to an action or connection have to be notified to the authorised agency as
follows:
initial report at start of data loss and at subsequent intervals of 5 minutes as long as the data
loss continues during this interval,
statement of the point in time of the initial loss of data and details of the data loss (quantitative)
since the last message and the total quantity (MByte),
details of the LIID concerned if such information is available,
Format: first missing data: DDMMYYhhmmss; data loss: value; total data loss: value (based on
an existing restriction of the ETSI parameter to 256 places, details of the values in the following
format only: 'DDMMYYhhmmss;value;value', value stands as the placeholder for details of the
data loss in Mbyte as a whole number (integer)).
2. In the case of a missing connection (error in ‘alive’ test)
In the case of missing ‘response’ messages (if this option has been chosen by the authorised agency),
the interval of the ‘alive’ test is reduced to 1 minute. This allows better verification of the continuing
interruption. The error message takes place for the first and last establishment of the interruption with
an indication:
of the time of the first absence of the "response" message,
of the number of "response" messages not received so far,
of optional details of an ID for the sending DF,
Format: first missing response: DDMMYYhhmmss; value missing responses; DF-ID value (due
to an existing restriction on the ETSI parameter to 256 places, details of the values in the
following format only: ‘DDMMYYhhmmss;value;value’, value stands as the placeholder for
details of the responses not received as a whole number (integer) and/or as a placeholder for
details of the DF-ID).
After the connection is restored, the regular interval is used and the counter for the error messages is
reset.
3. In the case of insufficient receiving capacity on the part of the authorised agencies
If the Monitoring Centre (MC) of an authorised agency is incapable of receiving the data stream from
the subject’s transmission point in full (e.g. remote terminal with insufficient incoming capacity to allow
it to receive all the data correctly) and therefore causes buffering on the part of the subject, the error
message ‘MC is blocking’ has to be sent.
TR TKÜV, edition 7.2 (draft) Part A, page 21
In the event of the complete blocking of the remote terminal, there would be data losses which would
be reported by error messages as in point 1.
Note: The error messages should be evaluated by the authorised agency.
4 Other requirements
In addition to the technical requirements for design of transmission points to authorised agencies, the TR
TKÜV contains other requirements to be complied with in the technical and organisational implementation
of surveillance actions.
4.1 Provisions on identifiers for implementation of surveillance
actions
Based on § 36 sentence 6 of the TKÜV, the provisions below lay down the types of identifiers for which
the prevailing legislation on the surveillance of telecommunication systems requires additional measures
for the technical implementation of surveillance measures to be taken in certain types of
telecommunication systems in addition to the target and source addresses used in them.
Identifiers in landline-based telephony networks and IMS platforms
- Target and source address according to E.164 including service numbers (e.g. 0700)
- SIP-URL, SIP-URI, TEL-URL, TEL-URI
Identifiers in mobile telephony networks and mobile-based IMS platforms
- MSISDN
- IMSI
- IMEI
- SIP-URL, SIP-URI, TEL-URL, TEL-URI
- PEI, SUPI, IMPI, IMPU, 5G-GUTI, GLI (identifiers related to 5G according to 3GPP TS
33.128)
Identifiers for the e-mail service
- E-mail address according to RFC 822 [24], RFC 2822 [25] (target and source address)
- Access identifier (login name without password, e.g. 'user name', 'phone number', 'email
address') of the mailbox
Identifiers of the Internet gateway
- Identifier of the associated telephone line
- Fixed IP address
- User ID allocated to the internet gateway
- MAC address according to the following instructions
- Other title for the transmission channel, e.g. postal identifier (installation address) of the
customer side of the Internet connection
Note on cable networks:
Surveillance actions can normally be implemented technically only on the basis of a cable modem
identifier (MAC address). However, a MAC address need not be specified in the surveillance
order if another definable identifier (e.g. identifier of the associated telephone line, system
address) provides equivalent unambiguous identification of the transmission channel. This
obviates the need for issuing a new order in case of replacement of a cable modem.
If the identifier of the associated telephone line is mentioned in the order, organisational
precautions must be taken so that
- in the absence of further explanation as to the scope of the surveillance action only the
telephony service or,
- where there is a more detailed definition of the scope of surveillance (e.g. "Internet access
only" or "telephony service and Internet access") the specific domain can be monitored.
If the cable modem address or installation address is mentioned in the order, organisational
precautions must be taken so that
- in the absence of further explanation as to the scope of the surveillance action the entire
connection with telephony and Internet access service or,
- where there is a more detailed definition of the scope of surveillance (e.g. "Internet access
only" or "telephony service only") the specific domain can be monitored.
TR TKÜV, edition 7.2 (draft) Part A, page 22
Note for WLAN networks:
If none of the above identifiers is available for a publicly available Internet access service via
wireless local area networks (WLAN networks or WLAN hotspots), the identifier of the terminal
relevant for Internet access (e.g., MAC address) shall be used in accordance with § 6(3) of the
TKÜV. If the users of public WLAN networks are not registered users, the number of regularly and
simultaneously connected users (terminal equipment) in the overall access network (i.e., not only
in the respective hotspot) is to be used as a basis for determining the relevant marginal limit
pursuant to § 3(2) of the TKÜV or to be assessed by corresponding empirical values.
If this type of Internet access service is provided through the interaction of several
telecommunications systems which may be operated by different operators, reference is made to
the provision of § 110(1) No 1a TKG, according to which it must nevertheless be possible to
monitor the service as if it were provided by only one system (general case). The requirement is
based on the assumption that, if necessary, control must be exercised between installations in
order to achieve this objective.
Content that is offered internally within the network by the operator of the WLAN is not affected by
the obligation to monitor the Internet access channel. This may, for example, be the landing page
which contains a particular offer of information (internal to the operator) and from which the user
then has the option to download other content from the Internet. In this case, only the access to
the Internet or the retrieval of restricted services connected over the Internet should be capable of
being monitored.
Should the design of the technical equipment only allow the surveillance of the entire offer, in
other words, internal content and access to the Internet, this may be tolerated after consulting the
Federal Network Agency.
Implementation of surveillance orders for Internet gateways:
In the Federal Network Agency’s view and from the interpretation of the legislation, the
implementation of such actions in relation to unbundled lines typically requires a two-tier
procedure:
1. Request to the supplier of the Internet gateway concerning the identity of the operator
responsible and the identifier required for implementation,
2. Issuance of the order to the obligated operator stating the relevant identifier of the
Internet gateway (the operation does not have to be the supplier, nor does he/she have to
provide relevant customer data).
In case the connection is known to be a so-called “non-unbundled connection”, the obligated
operator and the DSL transmission channel are unambiguously identified by the telephone
number. In this case, step 1 may be dispensed with.
Identifiers for the VoIP service and other multimedia services based on SIP, H.323 or H.248
in connections with media stream (e.g. RTP)
- Target and source address according to E.164 including service numbers (e.g. 0700)
- SIP-URL, SIP-URI, TEL-URL, TEL-URI
- H.323 URL, H.323 ID
- Access identifier (login name without password, e.g. ‘user name’, ‘phone number’, SIP-URI)
of the VoIP account
4.2 Transmission procedure for notifications and confirmations of
functional tests for recording and analysis devices used by the
authorised agencies
In accordance with § 23(1)(3) of the TKÜV, a functional test of recording and analysis devices used by
authorised agencies requires prior notification by the authorised agency and confirmation by the Federal
Network Agency. On the basis of § 23(1) sentence 9 of the TKÜV, the form and transmission procedure
for login and confirmation are set out below:
1. The Federal Network Agency provides the authorised agencies with an electronically editable
form, which after verification and adding of a check note is sent in electronic form to the subject
and the requesting authorised agency as a confirmation.
TR TKÜV, edition 7.2 (draft) Part A, page 23
2. The form shall be sent between the authorised agency and the Federal Network Agency and
between the Federal Network Agency and the subject using a transmission procedure stipulated
in Part B.
TR TKÜV, edition 7.2 (draft) Part A, Appendix A, Page 24
Appendix A Fundamental stipulations
concerning data transmission
Appendix A.1 FTP and TCP/IP specifications
This annex lays down specifications for the FTP and TCP/IP methods of transmission.
ASN.1-encoded sets of event data according to Appendix C can be still be sent to the authorised agency
online using the FTP protocol until 31 December 2021. Appendices D, E and F contain specifications
stating that the transmission copy is also sent via FTP.
To secure the sets of event data being sent, a VPN shall be used if these are being sent via the Internet.
In addition to the FTP transmission method, Annexes C, D, F, G, and H contain requirements for
transmission via TCP/IP. The national stipulations required to this end concerning the port addresses to
be used are contained in the respective Appendices.
Appendix A.1.1 File name
Files shall be transported using the FTP transmission method. The format of the file name is essentially
derived from file naming method B of ETSI Standard ES 201 671 or ETSI Specification TS 101 671 [22];
an identical description is found in the 3GPP Specification TS 33.108 [23].
In case of implementation pursuant to Appendix B, the file name may be freely chosen from the fifth
position onwards.
File name according to file naming method B:
<File name> according to the format ABXYyymmddhhmmsseeeet
where:
AB : two ASCII characters as identifier of the subject (see note)
XY : two ASCII characters as identifier of the sending mediation function (see note)
yy : two ASCII characters [“00”...“99”] to denote the year (last two digits)
mm : two ASCII characters [“01”...“12”] to denote the month
dd : two ASCII characters [“01”...“31”] to denote the day
hh : two ASCII characters [“00”...“23”] to denote the hour
mm : two ASCII characters [“00”... “59”] to denote the minute
ss : two ASCII characters [“00”...“59”] to denote the second
eeee : four alphanumeric ASCII characters (A-Z, 0-9) to prevent otherwise identical file names during
the same second within a single mediation function; lower-case alphanumeric characters
[‘a’...‘z’] are not permitted
t: one ASCII character to identify the content (see note)
Note on ‘AB’:
The identifiers of the subjects are assigned by the Federal Network Agency to prevent duplicates. The
Federal Network Agency assigns this identifier as part of the installation of the surveillance technology. At
the same time, a five-digit operator ID is defined for the subject, which is transmitted as a parameter in
the event data (see Appendix X.2).
Note on ‘XY’:
File naming method B essentially provides that different sending mediation functions (e.g. two different
FTP clients) of the same subject can be distinguished at least by this identifier even if they should send
files with otherwise identical file names to a particular authorised agency.
‘X’ (3rd position of the file name) should essentially be used in accordance with file naming method B to
distinguish between different mediation functions. To this end, the ASCII characters of upper-case letters
A-Z and the numbers 0-9 are available. However, if the obligated party only has a single mediation
function (e.g. operation of a single FTP client for the entire telecommunication system), then a different
value can be used for "X" in consultation with the Federal Network Agency.
TR TKÜV, edition 7.2 (draft) Part A, Appendix A, Page 25
However, as it is possible to transmit both ASCII-encoded and ASN.1-encoded files using the
FTP protocol in accordance with the above provision, it is necessary to include a distinguishing criterion in
the file name. This is represented by the selection of a corresponding value for ‘Y’ (4th position of the file
name). In addition, the value used for ‘Y’ can also serve to distinguish between the encodings in the
different ETSI Standards or ETSI and 3GPP Specifications.
Table A.1.1-1 below assumes the use of ASN.1 modules with an Object Identifier (OID) used in
accordance with Appendix X.4. Table A.1.1-2 applies additionally, but only if ASN.1 modules without
Object Identifier (OID) are used, and for older implementations pursuant to Appendices C and D.
‘Y’ (4th Meaning
position)
N Encoding in accordance with existing implementations under Annex B (optional, mandatory for
new implementations from 1 January 2003 and when using FTP as the transfer protocol).
E Encoding pursuant to Appendices C, E, F.3, G and H (mandatory).
ASN.1 or TLV-encoded records according to ETSI Standard or ETSI specification.
G Encoding pursuant to Appendix D (mandatory)
ASN.1 or TLV-encoded records encoded according to the 3GPP Specification TS 33.108.
X Encoding pursuant to Appendix E.5 or F.2 (mandatory).
XML-encoded content of a monitored e-mail.
Table A.1.1-1: Stipulations regarding 'Y' (modules with OID)
‘Y’ (4th Meaning
position)
E Encoding pursuant to Appendix C (mandatory).
Individual records encoded according to ETSI Standard ES 201 671 or the
ETSI Specification TS 101 671.
M Encoding pursuant to Appendix C (mandatory).
Packetised records in a file encoded according to ETSI Standard ES 201 671 or the
ETSI Specification TS 101 671.
G Encoding pursuant to Appendix D (mandatory).
Individual records encoded according to the 3GPP Specification TS 33.108.
U Encoding pursuant to Appendix D (mandatory).
Packetised records in a file encoded according to the 3GPP Specification TS 33.108.
Table A.1.1-2: Additional stipulations regarding 'Y' (modules without OID)
Note on ‘t’:
The ASCII characters used as values for ‘t’ (21st position of the file name) can be used to identify the
contents of the file. The file may contain the following:
IRI: Event data (Intercept Related Information)
HI1: Administration data; in the case of implementations according to Appendix B, the file type may
be freely chosen
CC(MO): Mobile Originated (MO) Content of Communication (CC) is included for the intercepted
data
CC(MT): Mobile Terminated (MT) Content of Communication (CC) is included for the intercepted
data
CC(MO&MT): Mobile Originated and Terminated (MO&MT) Content of Communication (CC) is
included for the intercepted data
national use: Transmission of event data and informational content according to Appendices E and
F
Table A.1.1.-3 below shows the possible values for 't' and their interpretations.
TR TKÜV, edition 7.2 (draft) Part A, Appendix A, Page 26
‘t’ (21st position) ‘t’ in binary File contains data in the form:
representation
1 0011 0001 IRI / HI1
2 0011 0010 CC(MO)
4 0011 0100 CC(MT)
6 0011 0110 CC(MO&MT)
8 0011 1000 national use
Table A.1.1-3: Stipulations regarding 't'
Example of a file name: VPEX06050410431200018
where:
VP : identifier for the subject (assigned by the Federal Network Agency)
E: identifier for e-mail surveillance (as only a single mediation function (FTP client) is used)
X: XML-encoded content according to Appendices E.5 and F.2
06 : Year: 2006
05 : month: May
04 : day: 04
10 : hour: 10
43 : minute: 43
12 : second: 12
0001 : extension 0001 to distinguish file names
8: transmission of event data and informational content in a file according to Appendices E or F
Appendix A.1.2 Parameters
When transmitting over FTP, the subject’s system operates as the sender (e.g. as an FTP client) and the
authorised agency’s system as the recipient (e.g. as the FTP server). The parameters (e.g. user name
and password for each FTP account) must be chosen such that they can be pre-assigned by a subject for
each recipient at the authorised agency in the preparatory phase of a surveillance action. This also
enables combined transmission of the event data sets for several actions in a single file to a single
FTP account.
The following essentially applies in this regard:
Several event data sets and possibly copies of informational content intended for transmission to a
recipient at the same authorised agency may be processed as a single file; in the case of ASN.1-
encoded data sets, for instance, this is done in an ‘IRISequence’.
In the context of a connection between the STS and the recipient at an authorised agency, one or
several files may be transmitted if these files are already available in the STS. However, the
connection should be closed immediately after transmission of the files if there are no more data sets
present in the STS at such time.
The FTP servers of the authorised agency should allow files to be overwritten so as to enable
resending of files in case of failure.
Table A.1.2-2 contains the most critical FTP parameters.
FTP parameters Values/stipulations Remarks
document type binary binary
filename Length: 21 positions refer to the stipulations pursuant to
(up to 25 positions in the case of Appendix A.1.1
implementations according to
Appendix B)
Characters: The following ASCII characters
are permitted:
Upper-case letters and numbers
(A-Z, 0-9), no umlauts
LEA user name for each Length: up to 8 positions no encryption necessary as VPN used
FTP account at an
authorised agency Characters: Alphanumeric characters (a-z, A-
Z, 0-9), no umlauts
LEA password for each Length: up to 8 positions no encryption necessary as VPN used
FTP account at an
authorised agency
TR TKÜV, edition 7.2 (draft) Part A, Appendix A, Page 27
FTP parameters Values/stipulations Remarks
Characters: Alphanumeric characters (a-z, A-
Z, 0-9), no umlauts
Special characters ‘.’, ‘%’, ‘*’, ‘!’,
‘?’, ‘@’, ‘#’
Directory change no requirement Directory changes by the FTP client
within the predetermined target
directory are not required
port for data connection 20 (default value)
port for control 21 (default value)
connection
mode passive mode should be supported Extended passive mode need not be
supported by the authorised agency,
i.e. the subject must offer the ‘simple’
active or passive mode.
Table A.1.2-2: Important parameters for FTP
Appendix A.2 Stipulations regarding participation in a VPN
To protect the IP-based transmission point, dedicated cryptosystems based on the IPSec protocol family
are used to connect the subnets of the authorised agencies and subjects in a Virtual Private
Network (VPN). To administer the cryptographic keys used for authentication, a Public Key
Infrastructure (PKI) is set up, for which the Federal Network Agency operates as the central certification
and registration authority. In addition, the Federal Network Agency administers the possible security
relationships in an Access Control List (ACL) made available via a directory service.
The cryptosystems are positioned as dedicated systems before the subnets of the authorised agencies
and subjects which they are intended to protect. These systems ensure authenticity, integrity and
confidentiality.
More extensive mechanisms to protect the transmission point, such as measures against denial of
service attacks on authorised agencies, are only addressed to a limited extent by cryptosystems and
should be independently resolved by the operator of the relevant subnets.
The relevant cryptosystems are essentially components of the technical systems of the authorised
agency or the subject; therefore, their planning and operation (e.g. operation of a syslog server),
maintenance and troubleshooting are the responsibility of the operator of the relevant subnet.
The requirements for cryptosystems should be updated in future to reflect the current state of the art in
order to ensure continued protection. The relevant extensions (e.g. use of different key lengths) or
necessary short-term changes in the existing implementations in the case of security issues arising later
should be implemented by the operator of the relevant cryptosystem within a period laid down for each
case individually — in the context of extensions or updates made available by the manufacturer of the
cryptosystem — according to the requirements set by the Federal Network Agency.
Network architecture
The cryptosystems of the authorised agencies and the subjects constitute a meshed network, where
directed security relationships (point-to-point connections) are created between the telecommunication
systems of the subjects and the subnets of the authorised agencies. Connections between the subjects
are not permitted.
The required cryptographic keys for authentication of the cryptosystems are created by the Federal
Network Agency and, after registration, stored on the smart card of each cryptosystem as supplied by the
operators of the relevant subnets. The keys used to encrypt the transmitted data are created and updated
by the cryptosystems themselves, i.e. they are not made available to participants.
After the cryptosystems are put into operation, they autonomously set up a secure connection to the
directory service at the Federal Network Agency in order to retrieve the current ACL. Further update
processes for the ACL either take place automatically or are controlled by the Federal Network Agency.
The log data created by the cryptosystems (e.g. successful ACL updates, failures) are sent to the log
server of the subject or the authorised agency in the standard syslog format (UDP port 514) for further
processing.
TR TKÜV, edition 7.2 (draft) Part A, Appendix A, Page 28
Design of the Internet access or transmission point
To ensure unambiguous addressing of VPN endpoints and of sending and receiving systems on the
connection used to transmit the surveillance copy or the IRI, public IP addresses are used. Where
existing Internet structures are used, separate tunnelling should typically be employed to fulfil the security
requirements of § 14 of the TKÜV. However, various different network configurations are possible in
principle.
The above requirements should be taken into account when describing the design of the Internet access
or transmission point in connection with the submission of the concept.
Use scenarios and procedures
In normal situations, cryptosystems are a fixed component of subnets and are identified unambiguously in
the ACL, amongst other things by their IP configuration. After registration and key creation, the directory
service is updated.
A list of data needed to administer the ACL, together with a description of the total process (policy), is
made available to all participants in the procedure.
A concept to be submitted by the participant to the Federal Network Agency should mention all the
relevant details (e.g. the proposed IP address for the transmission) to enable the ACL to be maintained
appropriately. This also applies where operators of smaller telecommunication systems make use of
cryptosystems in so-called pool solutions as referred to in § 21 of the TKÜV.
Other rules and guidelines
In addition to the above provisions for participation in the VPN, the following normative individual
provisions and guidelines apply:
Provisions for the registration and certification authority TKÜV-CA of the Federal Network
Agency, Department IS16 (Policy).
Appendix X.3 reflects the state of affairs at the time of publication of this version of the TR TKÜV.
Overview "Description of the overall process of participating in the VPN procedure".
Application for participation in the VPN for the subjects and authorised agencies (registration and
technical description of the infrastructure of the subnet with IP addresses and selection of
options).
The documents are published on the Federal Network Agency’s website at
http://www.bundesnetzagentur.de/tku
Overview of the cryptosystems to be deployed
The cryptosystems fulfilling the basic technical system and interoperability requirements are listed in the
following table.
No Manufacturer Product name Contact person
1 secunet Security Networks AG SINA Box Division Public Authorities
Ammonstraße 74 E-mail:
[email protected]
01067 Dresden Tel.: 0201 5454-0
www.secunet.com
Appendix A.3 Transmission of HI1 and additional events
The international standards and specifications underlying this TR TKÜV essentially describe the
transmission and content of the event data sets to be transmitted.
This also includes the transmission of so-called HI1 event data, which should be transmitted to
the authorised agency upon activation, deactivation and modification of surveillance actions as well as
alarm signals. This is essentially achieved using the ETSI-specified ASN1 module
‘HI1NotificationOperations’ (ETSI TS 101 671, Appendix D.4, Version 3 and up) or the nationally specified
ASN.1 module pursuant to Appendix A.3.2. For transmission of the actual identifier involved in the
activation of a surveillance action pursuant to § 5(5) of the TKÜV, the ASN.1 module
‘HI1NotificationOperations’ has been extended by a corresponding parameter from Version 6 onwards.
In addition, the national ASN.1 module should be used to transmit the following events, since the
international specifications and standards do not define any parameters for them:
TR TKÜV, edition 7.2 (draft) Part A, Appendix A, Page 29
manufacturer-specific services and service attributes (if not covered by the HI2 modules of the
relevant standards or specifications),
events related to activation, deactivation or modification of services and service attributes (e.g.
creation of a mailing list in a UMS by means of web access),
events related to settings for surveillance of the e-mail service when applying ETSI TS 102 232-
02 (see Appendix F.3).
The ASN1 module ‘HI1NotificationOperations’ and the national ASN.1 module are integrated in different
ways, depending on the standard or specification applied.
Appendix A.3.1 Transmission options
The following table explains the fundamental possibilities for integration of the ASN1 module
‘HI1NotificationOperations’ and the national ASN.1 module:
Standard or Method Note
specification
ES 201 671 / Transmission of the ASN.1 Module Using the ASN.1 module, the above HI1 events can be
TS 101 671 1) ‘HI1NotificationOperations’ with the transmitted direct to the authorised agency; it also
integrated parameter contains the parameter ‘National-HI1-ASN1parameters’
‘National-HI1-ASN1parameters’ with which the above additional events can also be
transmitted.
The required stipulations are contained in
Appendix A.3.2.1.
Transmission of the ASN.1 parameter The ASN.1 parameter enables direct integration of
‘National-HI2-ASN1parameters’ using HI1 events and additional events into the HI2 module.
the HI2 module ‘HI2Operations’ The required specifications are contained in
Annex A.3.2.2.
3GPP Transmission of the ASN.1 Parameters The ASN.1 parameter enables direct integration of
TS 33.108 1) ‘National-HI2-ASN1parameters’ using HI1 events and additional events into the HI2 module.
the HI2 module ‘HI2Operations’, which Before transmission, this HI2-module is imported into the
in turn is imported into modules relevant UMTS module.
‘UmtsHI2Operations’ and ‘UmtsCS- The required stipulations are contained in
HI2Operations’. Appendix A.3.2.2.
Transmission of the ASN.1 parameter The ASN.1 parameter enables direct integration of
‘National-HI3-ASN1parameters’ by the HI1 events and additional events into the HI2 module.
HI2 module ‘Umts-HI3-PS’ The required specifications are contained in
Appendix A.3.2.3.
TS 102 232-01 Import of the entire ASN.1 module By importing the entire module, the above HI1 events
‘HI1NotificationOperations’ by the can be transmitted direct to the authorised agency; it
module ‘LI-PS-PDU’ also contains the parameter
‘National-HI1-ASN1parameter’ with which the above
additional events can also be transmitted.
The required stipulations with regard to the HI1 module
are contained in Appendix A.3.2.1.
Table A.3-1 Transmission of HI1 and additional events
1) According to ES 201 671/TS101671 or 3GPP TP 33.108, there is also the functional possibility to transmit the
events through the HI2 module ‘HI2Operations’ by means of the ASN.1 parameter ‘National-parameters’. The
ASN.1 parameter defines an octet string into which the HI1 events and additional events are indirectly incorporated
by means of an additional ASN.1 module. As this method is very time-consuming in terms of programming and
analysis, it may no longer be used in new implementations (see Appendix A.3.2.4).
Appendix A.3.2 The national ASN.1 module 'Natparas'
This Appendix contains the ASN.1 description of the national module 'Natparas' for the transmission of
HI1 events and additional events according to Table A.3-1. If this module is used inside the HI1 module
'HINotificationOperations', the parameters for the HI1 events need only be transmitted once.
As this ASN.1 description is subject to relatively frequent updates with new additional parameters, the
present Appendix only reflects the state of affairs at the time of publication of the relevant version of the
TR TKÜV. The Federal Network Agency will coordinate proposed new parameters with the parties
involved and will then update the ASN.1 module. The current version of the ASN.1 description of the
TR TKÜV, edition 7.2 (draft) Part A, Appendix A, Page 30
national parameters will be made available for download on the website of the Federal Network Agency
after consultation:
http://www.bundesnetzagentur.de/tku
ASN.1 module ‘Natparas’, Version 8
-- National parameters (Content defined by national law)
-- Version of this ASN.1 specification of the national parameters: '8',
-- to be inserted in the parameter ‘specificationVersion’
-- Newer versions are downward-compatible.
NatParameter
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
Natparas ::= SEQUENCE {
application [0] ENUMERATED
{ hI2-201671 (1),
-- When using the HI2/3 modules of ES 201 671 or TS 101 671
hI2-33108 (2),
-- When using the HI2/3 modules of 3GPP TS 33 108
hI2-101233 (3),
-- When using the HI2/3 modules of TS 102,234 or TS 102 232-2
hI2-101234 (4),
-- When using the HI2/3 modules of TS 102,234 or TS 102 232-3
...,
hi2-102232 (5),
-- When using the transmission method according to TS 102 232 or TS 102 232-1
-- This use comprises tags 3 and 4 and all other HI2/3-modules which
-- are transmitted via TS 102 232 or TS 102 232-1
hi1-201671 (6)
-- When using the HI1 module of ES 201 671 or TS 101 671
} OPTIONAL,
-- This parameter was first introduced in Version 3
-- This parameter is optional for implementations based on Version 1 or 2;
-- This parameter is mandatory for implementations based on Version 3 and above
natVersion [1] SEQUENCE {
country [0] OCTET STRING (SIZE (1..4)),
-- coded in the same format as country codes [EN 300 356-1 to 20]
-- e.g. 49 for Germany
specificationVersion[1] INTEGER (0..255)
},
notification [2] SEQUENCE {
liOperation-type [1] ENUMERATED {
liActivated (1),
liDeactivated (2),
liModified (3)
} OPTIONAL,
-- Not required in conjunction with the HI1 module of TS 101 671,
-- as this provides for an operation-type
alarms-indicator [2] Alarm-Indicator OPTIONAL,
-- values for Alarm-Indicator, all characters in ASCII format
-- Not required in conjunction with the HI1 module of TS 101 671,
-- as this provides for an alarm-indicator
li-end [3] TimeStamp OPTIONAL,
-- 'time of expiry of the monitoring order'(liActivated-, liModified-
-- Records)
target [4] OCTET STRING (SIZE (1..256)) OPTIONAL
-- in the format: free ASCII-encoded text
-- actually monitored identifier pursuant to § 5(5) of the TKÜV
-- optional for reasons of backward compatibility
} OPTIONAL,
sCIGerman [3] SEQUENCE {
typeOfData [0] SciType OPTIONAL,
sciResult [1] SciResultMode OPTIONAL,
sciData [2] OCTET STRING (SIZE (1..256)) OPTIONAL
} OPTIONAL,
common [4] CommonMode OPTIONAL,
-- moduls of the manufactures
alcatel [5] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
ericsson [6] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
lucent [7] OCTET STRING (SIZE (1..256)) OPTIONAL,
TR TKÜV, edition 7.2 (draft) Part A, Appendix A, Page 31
-- the manufacturer has to provide an ASN.1 Specification
nortel [8] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
siemens [9] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
gten [10] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
md-usag-nokia [20] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
md-usag-comverse [21] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
md-usag-motorola [22] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
md-usag-siemens [23] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
md-usag-unisys [24] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
md-usag-ericsson [25] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
md-usag-nortel [26] OCTET STRING (SIZE (1..256)) OPTIONAL,
-- the manufacturer has to provide an ASN.1 Specification
...,
e-mail-type [100] ENUMERATED
-- In the case of implementations based on Version 5.1 and above of the TR TKÜV,
-- this parameter does not need to be used
{
iMAP (1),
webmail (2),
...,
lMTP (3),
iMAPS (4),
sSMTP (5),
pOP3S (6)
} OPTIONAL,
e-mail-add [101] SEQUENCE
{
event [1] Event,
explain [2] Explain,
...
} OPTIONAL
}
-- **************************** Parameter begin **********************
Event ::= ENUMERATED
{
grouplist-create (0),
grouplist-change (1),
grouplist-delete (2),
-- settings for mailing lists
messaging-create (3),
messaging-active (4),
messaging-change (5),
messaging-delete (6),
-- settings for messaging service
forwarding-create (7),
forwarding-active (8),
forwarding-change (9),
forwarding-delete (10),
-- settings for forwarding service
email-new (11),
email-change (12),
email-delete (13),
-- setting for e-mail addresses
sonstiges (14),
-- This parameter should be used in addition to the above categories whenever a
-- further, different parameter is necessary
...
-- If, when using a messaging or forwarding service, a new setting is indeed
-- activated, only the active event needs to be reported;
}
Explain ::= OCTET STRING (SIZE (1..256))
-- Designation of the chosen settings (parameters)
TR TKÜV, edition 7.2 (draft) Part A, Appendix A, Page 32
-- in the format: free ASCII-encoded text
Alarm-Indicator ::= OCTET STRING (SIZE (1 .. 25))
--Provides information about alarms (free format)
CC-F:ccc = CC-Link Failure, is the Cause Value of the Release Message
-- as decimal value
-- MD-OFF:DDMMYYhhmm = date and time of failure or power-off of the
-- mediation device (optional)
-- MD-ON:DDMMYYhhmm = date and time of (re)activation of the
-- mediation device (optional)
-- LEMF-IRI-OFF:DDMMYYhhmm = date and time of start of unattainability
-- of the LEMF for IRI (optional)
-- LEMF-IRI-ON:DDMMYYhhmm = date and time of (restored) reachability of the
-- LEMF for IRI (optional)
CommonMode ::= SEQUENCE {
inControlled [0] InControlMode OPTIONAL,
-- spvInfo [1] SpvInfoMode OPTIONAL
...
}
InControlMode ::= SEQUENCE {
correlationNumber [0] INTEGER (0..65535) OPTIONAL,
dataContent [1] OCTET STRING (SIZE (1 .. 100))
}
SciType ::= ENUMERATED {
undefined (0),
analogSubscriber (1),
dss1FunctionalProt (2),
dss1KeypadProt (3),
einsTr6FunctionalProt (4),
mobileNetProt (5),
systemSpecific (6)
}
SciResultMode ::= ENUMERATED {
undefined (0),
successful (1),
unsuccessful (2),
rejected (3),
intermediateInfo (4)
}
TimeStamp ::= CHOICE
{
localTime [0] LocalTimeStamp,
utcTime [1] UTCTime
-- TimeStamp as in ETSI ETS 201 671
}
LocalTimeStamp ::= SEQUENCE
{
generalizedTime [0] GeneralizedTime,
winterSummerIndication [1] ENUMERATED {
notProvided(0),
winterTime(1),
summerTime(2),
...
}
}
END -- Natparas
Appendix A.3.2.1 Transmission using the ASN.1 module
'HI1NotificationOperations'
This Appendix contains the method for transmission of HI1 and additional events via the ASN.1 module
'HINotificationOperations' from Version 3 onwards. Earlier versions of this module are not permitted as
they do not yet include the OID.
The same description is used if the entire module ‘HI1NotificationOperations’ is imported into the
module ‘LI-PS-PDU’ for the Internet gateway as described in Appendix G.
HI1NotificationOperations
{itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulIntercept(2) hi1(0)
notificationOperations(1) version5(5)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
TR TKÜV, edition 7.2 (draft) Part A, Appendix A, Page 33
IMPORTS
OPERATION,
ERROR
FROM Remote-Operations-Information-Objects
{joint-iso-itu-t(2) remote-operations(4) informationObjects(5) version1(0)}
CommunicationIdentifier,
TimeStamp,
LawfulInterceptionIdentifier
FROM HI2Operations
{itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulIntercept(2)
hi2(1) version8(8)}
Natparas
FROM NatParameter
Natparas2
FROM NatParameter2;
National-HI1-ASN1parameters ::= SEQUENCE
{
domainID [0] OBJECT IDENTIFIER (hi1OperationId) OPTIONAL,
-- Once using FTP delivery mechanism.
countryCode [1] PrintableString (SIZE (2)),
-- Country Code according to ISO 3166-1 [67],
-- the country to which the parameters inserted after the extension marker apply.
...,
-- In case a given country wants to use additional national parameters according to
-- its law, these national parameters should be defined using the ASN.1 syntax and
-- added after the extension marker (...).
-- It is recommended that "version parameter" and "vendor identification parameter"
–- are included in the national parameters definition. Vendor identifications can be
-- retrieved from IANA web site (see annex H). Besides, it is recommended to avoid
-- using tags from 240 to 255 in a formal type definition.
natparas [2] Natparas,
-- Import from TR TKÜV, Part A, Appendix A.3.2
natparas2 [3] Natparas2
-- Import from TR TKÜV, Part C, Paragraph 3.2
}
END -- HI1NotificationOperations
Appendix A.3.2.2 Implementation in the ASN.1 module ‘HI2Operations’
This Appendix contains the implementation in the ASN.1 module ‘HI2Operations’. The same description
is used if the entire module ‘HI2Operations’ is imported into the modules ‘UmtsHI2Operations’ and
‘UmtsCS-HI2Operations’ as described in Appendix D.
HI2Operations
{itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulIntercept(2) hi2(1)
version8(8)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS OPERATION,
ERROR
FROM Remote-Operations-Information-Objects
{joint-iso-itu-t(2) remote-operations(4) informationObjects(5) version1(0)}
UmtsQos,
IMSevent
FROM UmtsHI2Operations
{itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulintercept(2)
threeGPP(4) hi2(1) r6(6) version-5(5)}
Natparas
FROM NatParameter
Natparas2
FROM NatParameter2;
IRI-Parameters ::= SEQUENCE
{
domainID [0] OBJECT IDENTIFIER (hi2OperationId) OPTIONAL,
TR TKÜV, edition 7.2 (draft) Part A, Appendix A, Page 34
-- for the sending entity the inclusion of the Object Identifier is mandatory
national-HI2-ASN1parameters [255] National-HI2-ASN1parameters OPTIONAL
}
National-HI2-ASN1parameters ::= SEQUENCE
{
countryCode [1] PrintableString (SIZE (2)),
-- Country Code according to ISO 3166-1 [67],
-- the country to which the parameters inserted after the extension marker apply.
...
-- In case a given country wants to use additional national parameters according to
-- its law, these national parameters should be defined using the ASN.1 syntax and
-- added after the extension marker (...).
-- It is recommended that "version parameter" and "vendor identification parameter"
-- are included in the national parameters definition. Vendor identifications can be
-- retrieved from the IANA web site (see annex H). Besides, it is recommended to
-- avoid using tags from 240 to 255 in a formal type definition.
natparas [2] Natparas,
-- Import from TR TKÜV, Part A, Appendix A.3.2
natparas2 [3] Natparas2
-- Import from TR TKÜV, Part C, Paragraph 3.2
}
END -- HI2Operations
Appendix A.3.2.3 Implementation in the ASN.1 module ‘Umts-HI3-PS’
This Appendix contains the implementation in the ASN.1 module ‘Umts-HI3-PS’:
Umts-HI3-PS
{itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulintercept(2) threeGPP(4)
hi3(2) r6(6) version-3(3)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
GPRSCorrelationNumber
FROM UmtsHI2Operations
{itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulintercept(2)
threeGPP(4) hi2(1) r6(6) version-6(6)}
LawfulInterceptionIdentifier,
TimeStamp
FROM HI2Operations
{itu-t(0) identified-organization(4) etsi(0) securityDomain(2) lawfulIntercept(2) hi2(1)
version7(7)}
Natparas
FROM NatParameter
Natparas2
FROM NatParameter2;
National-HI3-ASN1parameters ::= SEQUENCE
{
countryCode [1] PrintableString (SIZE (2)),
-- Country Code according to ISO 3166-1 [39],
-- the country to which the parameters inserted after the extension marker apply
...,
-- In case a given country wants to use additional national parameters according to its
-- law, these national parameters should be defined using the ASN.1 syntax and added after
-- the extension marker (...).
-- It is recommended that "version parameter" and "vendor identification parameter" are
-- included in the national parameters definition. Vendor identifications can be
-- retrieved from IANA web site. It is recommended to avoid
-- using tags from 240 to 255 in a formal type definition.
natparas [2] Natparas,
-- Import from TR TKÜV, Part A, Appendix A.3.2
natparas2 [3] Natparas2
-- Import from TR TKÜV, Part C, Paragraph 3.2
}
END-- OF Umts-HI3-PS
TR TKÜV, edition 7.2 (draft) Part A, Appendix A, Page 35
Appendix A.3.2.4 Transmission using the ASN.1 parameter ‘National-Parameters’
This Appendix contains the method for transmission of HI1 and additional events via the
ASN.1 parameter ‘National-Parameters’ in the module HI2Operations of ES 201 671/TS 101 671 up to
Version 4, or in the module UmtsHI2Operations up to Version 6.6.0.
The ASN.1 parameter defines an octet string into which the HI1 events and additional events are
indirectly incorporated by means of an additional ASN.1 module. As this method is very time-consuming
in terms of programming and analysis, it has been replaced in the standards and specifications by the
method as described in Appendix A.3.2.3, and is no longer available for new implementations.
Explanation using a concrete example:
The data encoded according to the Basic Encoding Rules (BER) should be included after encoding in the
following container, created according to the ASN.1 type:
‘National-Parameters::= SET SIZE (1..40) OF OCTET STRING (SIZE (1..256))’
of at most 40 x 256 octets (see also the diagram below).
An example using SIZE (3):
T L V (see green area)
SET = 'B0 Xx
T L V (see red area)
OCTETSTRING='04 Y1 ASN.1-encoded national parameter, starting with ‘Natparas::=
SEQUENCE { ’, where the individual octets are inserted
sequentially:
T('30)LV1 TLV2 TLV3 ... TLVm (also nested)
'04 Y2 TLVm+1 TLVm+2 TLVm+3…TLVn
‘04 Y3 TLVn+1 TLVn+2 TLVn+3…TLVo
Coding SET SIZE (3) OF
Coding OCTET STRING
Coding of national parameters, beginning with SEQUENCE = '30
Concrete example: Report Record upon activation of a surveillance action:
This example shows the content of the national parameter for the event ‘Activation of a surveillance
action- liActivated’ and its embedding into a Report record.
The next line contains the full OCTET STRING of the national parameter, corresponding to the red area
in the above diagram: 30 0E A1 07 80 02 34 39 81 01 01 A2 03 81 01 01
The individual bytes are explained below:
30 0E sequence, length 14 (universal type, constructed)
A1 07 natVersion (context specific type, constructed)
80 02 34 39 country code (context specific type primitive, filled with ASCII code ‘49’)
81 01 01 version-number (context specific type, primitive, integer ‘1’)
A2 03 notification (context specific type, constructed)
81 01 01 liOperation-type (context specific type, primitive, liActivated)
The lines below comprise the entire Report record including the national parameter:
A4 44 97 01 02 81 09 42 4B 41 2D 31 32 33 34 35 A2 09 A1 07 80 05 34 39 31 32 33 A3 15
A0 13 80 0E 32 30 30 32 30 38 30 39 31 35 33 35 31 32 81 01 00 B0 12 04 10 30 0E A1 07
80 02 34 39 81 01 01 A2 03 81 01 01
Appendix A.4 Difficulties in transmission of the surveillance copy to the
authorised agency’s lines
If the surveillance copy cannot be transmitted to the authorised agency (e.g. due to a failure in the
transmitting device of the STS, overload of the transit network, or when the lines of the authorised agency
are occupied), the requirement of § 10 of the TKÜV applies, pursuant to which the event data sets should
be retransmitted immediately.
TR TKÜV, edition 7.2 (draft) Part A, Appendix A, Page 36
It is not permitted to disable or delay the monitored telecommunications or to store the contents of the
surveillance copy for these reasons. Contents of communications may only be buffered to the extent
necessary for a smooth operation due to technical, particularly transmission-related, considerations.
In case of monitoring of subsequent telecommunications events, a renewed connection attempt should be
made for transmission of the surveillance copy, unless other arrangements have been made with the
authorised agency on a case-by-case basis (e.g. in case of prolonged failure).
Technical implementation
First repeated connection attempts
If an obstacle arises when attempting to transmit the surveillance copy, three further connection
attempts should be made in the first instance. When using circuit-switched connections, these
attempts should be made at intervals of 5 to 10 seconds each, and at intervals of up to a few minutes
when using FTP or TCP/IP. If, after these three attempts, the connection to the authorised agency can
be restored, the buffered and newly accrued event data and the copy of the communication content
should be transmitted as of the time of restoration.
If the surveillance copy cannot be transmitted to the authorised agency after these repeated
connection attempts, the event data sets must be stored for later transmission.
Further connection attempts
After the above three repeated connection attempts, repeated attempts should be made at reasonable
time intervals for a period of 24 hours until successful.
If transmission is not successful even during this extended period, the event data must be able to be
printed out or saved on a storage medium (e.g. a CD), sent to the authorised agency through suitable
means (e.g. secure e-mail) and deleted from the STS. The subject may extend the above 24-hour
period to at most 1 week, provided it is ensured that the authorised agency can access the event data
earlier on request for specific purposes (e.g. through the backup channel provided for failure
situations).
If the connection to the authorised agency is restored during this extended period, transmission should
include the copy of the content of the communication in addition to the event data from the time of
restoration.
In circuit-switched fixed and mobile telephony networks, however, no additional connection attempts
should be made to transmit the copy of the content of communication to the authorised agency after
the above three further connection attempts, if the transmission point follows the design pursuant to
Appendix B or C.
Detected failure or error situations affecting the surveillance of the telecommunications or the
transmission of the surveillance copy should be immediately sent to the authorised agency as alarm
reports in a separate event data set or reported to it through other means. If the transmission of the
relevant event data sets itself is affected by a failure, these alarms should still be generated so that they
can be transmitted after restoration of the transmission function or sent on a storage medium in order to
document the failure. In mobile telephony networks, the details of failures affecting only regionally defined
parts of the network need only be provided upon request from the authorised agencies, using suitable
means (e.g. via fax or e-mail).
TR TKÜV, edition 7.2 (draft) Part A, Appendix B, page 37
Appendix B (Deleted: Transmission point for
circuit-switched networks (national))
Note: Since all forwarding via X.25 was discontinued as of 31 December 2017, existing implementations
under Appendix B are now only permitted until 31 December 2021 if these have been converted to
forwarding via FTP. No new implementations are possible. The descriptions under this Annex B can be
found in the TR TKÜV versions up to version 7.0.
TR TKÜV, edition 7.2 (draft) Part A, Appendix C, page 38
Appendix C Provisions for PSTN and ISDN
(ETSI ES 201 671 or TS 101 671)
Note on the use of existing systems based on forwarding via ISDN:
Due to the closing down of ISDN-based technology foreseeable in the medium term, the
corresponding forwarding, based on this technology, must also be adapted in the medium term.
New implementations with forwarding based on ISDN are no longer permitted. Existing systems
are to be converted by 31 December 2021 at the latest to forwarding in accordance with
Appendix H. If the existing suppliers are no longer capable of supplying within this time limit, a
change may be made to an alternative supplier which continues to offer ISDN. Forwarding via
X.25/X.31 is no longer permitted; it was replaced by FTP on 31 December 2017.
This Appendix describes the conditions in case the transmission point for circuit-switched fixed networks
(PTSN and ISDN) is designed according to ETSI Standard ES 201 671 or
ETSI Specification TS 101 671 [22]. The transmission point for mobile networks must comply with
Appendix D.
This includes the decisions made with respect to options contained in the standard or specification, as
well as additional technical requirements.
Telecommunications surveillance activation in existing telecommunications links
If there is already a telecommunications link under surveillance when a surveillance action is activated,
then both the content and the event data should be recorded from this time onwards and a copy
delivered. Data pursuant to § 7(1) of the TKÜV, which exists on the net at the time of activation of the
surveillance action and is no longer forwarded via future event data (e.g. codecs of the existing
telecommunication), must also be reported. Since there is currently no standard dictating the technical
implementation in detail, the compulsory implementation of this requirement is deferred for the time being,
as long as signalling information and informational content are provided in various network elements, and
provided that no information for operational purposes regarding the points at which the voice data can be
forwarded and correlated is provided.
In addition to the requirements under Part A, Sections 3 and 4, the following Appendices shall also apply:
Appendix Contents
Appendix A.1 FTP transmission method
For PSTN and ISDN, the copy of the informational content is sent via an ISDN dual stub
according to this Appendix C or in an IP-based manner according to Appendix H. The event data
are sent via FTP/Internet. The stipulations required to this end are contained in Appendix A.1.
Appendix A.2 Participation in a VPN via a cryptosystem
If the copy of the content or the event data is transmitted over FTP or TCP/IP, the procedure for
participation in VPN should also be followed
Appendix A.3 Transmission of HI1 events and additional events
Appendix A.4 Difficulties in transmission of the surveillance copy to the authorised agency’s lines
Reference is also made to the following appendices in Part X of the TR TKÜV:
Appendix X.1 Proposed changes to the TR TKÜV
Appendix X.2 Assignment of an identifier to the authorised agency to ensure uniqueness of reference numbers
Appendix X.3 Provisions for the registration and certification authority TKÜV-CA of the Federal Network
Agency, Department IS16 (Policy)
Appendix X.4 Table of applicable ETSI/3GPP standards and specifications as well as the ASN.1 modules
Appendix X.5 Requirements for administration and logging in the organisational implementation of surveillance
actions
TR TKÜV, edition 7.2 (draft) Part A, Appendix C, page 39
Appendix C.1 Selection of options and stipulation of additional technical
requirements
The following table describes, on the one hand, the selection of options for the different chapters and
paragraphs of ETSI Specification TS 101 671 or ETSI Standard 201 671 and, on the other, specifies the
respective additional requirements. Unless otherwise indicated, the references in the table relate to the
respective sections of the ETSI specification or ETSI standard:
Section ES Description of the option or problem and Additional requirement, background and
201 671 / specifications regarding national supplemental information
TS 101 671 application
5.1 Manual/Electronic Handover Interface 1
(HI1) For the transmission of events (e.g.
There is no electronic interface from the LEA to activation/deactivation/modification of an action,
the installation of the subject for direct error reports) from the installation of the obligated
administration of actions. party to the LEA, the HI1 may be used (see
Appendix A.3 of the TR TKÜV in this regard).
The events for administration of an action (e.g.
about activation) and fault reports should be
reported.
6.2.1 Network Identifier (NID)
The NID consists, inter alia, of the 5-character
NWO/AP/SvP identifier (Operator Identifier). In
Germany, the first digits are set to ‘49’ while the
remaining 3 digits are determined by the
Federal Network Agency for each subject.
8.1 Data transmission protocol (HI2)
To transmit the event data (IRI) over the HI1
and HI2 interfaces, FTP is used; ROSE is not
permitted.
The FTP connection should be closed
immediately after transmission of the event
data.
10.1 Timing (Buffering of IRI)
For buffering of IRI, the requirement given in see Appendix A.4 of the TR TKÜV.
the adjacent column applies.
11 Security aspects
When using an IP-based transmission point, To protect IP-based transmission points, dedicated
IPSec is applied. IP cryptosystems should be used, based on IPSec
in conjunction with a PKI as referred to in
Appendix A2 of the TR TKÜV.
For transmission of content over ISDN, the Where a COLP check cannot always be carried
service attributes CLIP, COLP and CUG are out reliably, particularly for newer network
used. technologies, it may be disabled permanently or
dispensed with after consulting with the Federal
Network Agency.
12 Quantitative aspects
The dimensioning of the administration and
transmission capacities is subject to the
guidelines as per Section 5.2 of the TR TKÜV.
Appendix A: Circuit-switched network handover
A.1.3 Usage of Identifiers
The options ‘IRI and CC’ and ‘only IRI’ should The option ‘only CC’ is part of the specification up
be supported; the option ‘only CC’ need not be to Version 2.5.1.
supported.
A.3.2.1 Control information for HI2
The GeneralizedTime parameter is not encoded as
universal time and without time difference. The
TR TKÜV, edition 7.2 (draft) Part A, Appendix C, page 40
Section ES Description of the option or problem and Additional requirement, background and
201 671 / specifications regarding national supplemental information
TS 101 671 application
All times (TimeStamp) should normally be given winterSummerIndication must be specified as
as local time based on the official time. either wintertime or summertime.
A.4.1 Delivery of Content of Communication
Correlation of the informational content (CC) As the user-to-user service has not been
with the other HI Interfaces should not be done implemented in all networks in Germany,
via the user-to-user service but instead via the correlation should exclusively use the subaddress
subaddress service. service.
Appendix E describes this use.
A.4.2 Delivery of packetised Content of
Communication For transmission of this content, a choice may be
For the SMS and UUS services, informational made between either the ASN.1 module
content is transmitted as event data. ‘HI2Operations’ as described in Appendix D.5 or
the module ‘HI3CircuitDataOperations’ as
described in Appendix D.6. Both modules provide
the relevant parameters for UUS and SMS.
A.4.3 Control information for circuit switched
Content of Communication
As described above, the end devices of
authorised agencies should immediately
respond to a SETUP message with a
CONNECT message, i.e. without an
ALERTING message.
A.4.4.1 Failure of CC links
In case a connection fails to be created, three see Appendix A.4 of the TR TKÜV.
renewed attempts should be made.
A.4.4.2 Fault Reporting
Fault reports are transmitted as event data as Fault reports may be transmitted as national
described in Appendix D.5 (IRI) (see parameters or via the HI1 interface as an
Appendix A.4 of the TR TKÜV). alternative. The minimum error events which
should be transmitted are derived from the national
In mobile telephony networks, the details of parameters (see Appendix A.3 of the TR TKÜV).
failures affecting only regional parts of the
network need only be provided upon request
from the authorised agency.
A.4.5 Security Requirements at the interface port
HI3 Where a COLP check cannot always be carried
When creating the CC links to the LEMF (LEA), out reliably, particularly for newer network
the ISDN service attributes CLIP, COLP and technologies, it may be disabled permanently or
CUG should be used. dispensed with after consulting with the Federal
Network Agency.
The provision of target addresses for the
Routing to the target addresses of the authorised agencies by the Federal Network
authorised agencies shall take place in such a Agency shall ensure a routing such that only
way that the aforementioned service attributes appropriately secure transit networks are used,
are transmitted securely. and for example any IP networks considered
insecure, or wider foreign networks, are avoided.
A.4.5.3 Authentication
No specific authentication procedure is used in
the ISDN B-channel or the subaddresses.
A.5 LI procedures for circuit switched
supplementary services
For non-standardised (proprietary) surveillance-
relevant service attributes, the required
information should be transmitted in the
national parameters. The content of the
TR TKÜV, edition 7.2 (draft) Part A, Appendix C, page 41
Section ES Description of the option or problem and Additional requirement, background and
201 671 / specifications regarding national supplemental information
TS 101 671 application
parameters should be agreed with the Federal
Network Agency.
A.5.4 Multi party calls — general principles
A.6.11 For large conferences (CONF) with more than
six participants, the option B according to
A.5.4.2 should be implemented.
For CW, HOLD, 3PTY and CONF with up to
A.6.2, A.6.3, For CW, HOLD, 3PTY and CONF with up to 6 participants, the following applies:
A.6.12 6 participants, either option A or option B may As multiplexed use of ISDN channels to the
be used alternatively. authorised agency as described in option B lead to
more complex analysis and more difficult analysis
of the content (no differentiation of speaker per
channel), use of option A should be preferred.
A.6.3 Call Hold/Retrieve
When HOLD is activated, both CC links should
be muted during the HOLD phase.
The option where only the held party is muted
is also acceptable.
A.5.5 Subscriber Controlled Input The obligation to report controls regarding
operation options in accordance with § 5(1)(4)
TKÜV is lifted. However, systems in operation
before TR TKÜR 7.1 enters into force may still use
these parameters.
A.6.4 Explicit Call Transfer (ECT)
After transfer, option 2 should be implemented
(“The transferred call shall not be intercepted.”).
A.6.22 User-to-User Signalling (UUS)
Informational content for the UUS service is See Section A.4.2 in this table.
transmitted as event data.
A.8.3 HI3 (delivery of CC)
Informational content for the SMS service is See Section A.4.2 in this table.
transmitted as event data.
Correlation of the informational content (CC) See Section A.4.1 in this table.
with the other HI interfaces should be done via
the subaddress service as described in
Appendix E.
Annex C: HI2 delivery mechanisms and procedures
C.1 / C.2 ROSE / FTP
For transmission of the event data (IRI) over
the HI2 interface, FTP is used; ROSE is not
permitted.
C.2.2 Usage of FTP
File naming method B must be used.
The provisions of Appendices A.1 and A.2 of
the TR TKÜV also apply.
Appendix D: Structure of data at the Handover Interface
D.3 to D.8 ASN.1 modules
When using FTP to transmit the IRI, the Since not all modules have been specified as
ROSE operations are not relevant in the being error-free or do not contain all the required
parameters, the Federal Network Agency will
publish on its website a list of the modules which
TR TKÜV, edition 7.2 (draft) Part A, Appendix C, page 42
Section ES Description of the option or problem and Additional requirement, background and
201 671 / specifications regarding national supplemental information
TS 101 671 application
Appendices and do not need to be may be used for implementations (see also
implemented. Appendix X.4 to TR TKÜV).
Appendix E: Use of subaddress and calling party number to carry correlation information
E.3.2 Field order and layout
The parameters for assigning CC and IRI
according to Tables E.3.2 and E.3.3 should be
used accordingly.
National specifications for circuit-switched
Also, the octets 17–23 of the Called Party networks (former Annex B) stipulate that
Subaddress (Table E.3.4 and E.3.6) should subaddresses are also used, but with a different
contain the fixed bit pattern content. To enable the analysis device of
‘45 54 53 49 20 56 32' hex = ETSI V2’ to the authorised agency to make a distinction, this
differentiate it from the subaddresses according differentiating attribute is mandatory.
to the specifications of Annex B to TR TKÜV.
Appendix C.2 Explanations of the ASN.1 descriptions
On its website, the Federal Network Agency publishes information, pursuant to § 36 sentence 5 of
the TKÜV, on the applicable ETSI and 3GPP standards and specification, including the associated
ASN.1 modules. Use of the different versions of the national ASN.1-module is also regulated.
Appendix X.4 contains further explanations in this regard.
The ASN.1 descriptions of the different modules for implementations according to this Appendix C should
be taken from the various versions of ETSI Standard ES 201 671 or ETSI Specification TS 101 671,
taking care to correct any errors in the ASN.1-modules contained in them (e.g. incorrect domainID).
Because FTP is used as the transfer protocol, ROSE operations are not relevant.
Whenever the above information is updated on the website of the Federal Network Agency, the updated
versions of the ASN.1-modules may be used. Potentially, without a corresponding update on the part of
the authorised agency, not all parameters may be able to be interpreted.
Parameters designated as ‘conditional’ or ‘optional’ in the standard or specification should normally be
transmitted if they are available and the relevant standard or specification, or Appendix C.1 where
applicable, does not contain any contrary provisions.
For the associated ASN.1 types of the “OCTET STRING” format, the following rules apply:
If the standard has defined a format for the relevant parameters, e.g. ASCII or a cross-reference
to a (signalling) standard, this format should be used.
If no particular format has been prescribed, both hexadecimal values should be inserted in the
relevant bytes, with the higher-order half-byte in bits 5-8 and the lower-order half-byte in bits 1-4.
(Examples: 4F H is entered as 4F H = 0100 1111 and not as F4 H. Or for example,
DDMMYYhhmm = 23.07.2002 10:35 h is entered as ‘2307021035’ H and not ‘3270200153’ H)
Transmission of administrative events (e.g. activation/deactivation/modification of actions as well as fault
reports) and additional events (e.g. with regard to manufacturer-specific services) takes place according
to Appendix A.3.
TR TKÜV, edition 7.2 (draft) Part A, Appendix D, page 43
Appendix D Specifications regarding mobile
telephony networks and mobile-based
IMS platforms (3GPP TS 33.108 and TS
33.128)
Note on the use of existing systems based on forwarding via ISDN and the combined use of
standards for forwarding packet-switched voice services:
Due to the anticipated closing down of ISDN-based technology, the corresponding forwarding
based on this technology must also be adapted. New implementations with forwarding based on
ISDN are no longer permitted. Existing systems must be converted to TCP-based forwarding in
accordance with 3GPP TS 33.108 by 31 December 2021 at the latest. For packet-switched voice
services (e.g. VoLTE), combined forwarding in accordance with 3GPP TS 33.108 or TS 33.128 and
ETSI TS 102 232-5 (Appendix H) may be used temporarily (see guidelines in Appendix X.1.1).
This Appendix describes the requirements for the transmission point formobile telephony networks and
mobile-based IMS platforms according to 3GPP Specifications TS 33.108 [23] and TS 33.128 [40]. The
specification essentially contains a technical description for both circuit-switched and packet-switched
networks as well as for multimedia services.
The 3GPP Specification TS 33.128 uses the IP-based transmission procedure according to the ETSI
Specifications TS 102 232-1 and 102 232-7, in which the data is encapsulated according to 3GPP TS
33.128. At the latest when both forwarding methods are implemented in a network as part of the
successive migration of forwarding from 3GPP TS 33.108 to 3GPP TS 33.128, forwarding in accordance
with 3GPP TS 33.108 shall also be carried out via ETSI Specifications TS 102 232-1 and 102 232-7.
According to this edition of the TR TKÜV, the forwarding of 3GPP TS 33.108 via the ETSI Specifications
TS 102 232-1 and 102 232-7 is also possible after consultation with the Federal Network Agency,
irrespective of the above-mentioned successive migration of forwarding to 3GPP TS 33.128.
For forwarding via ETSI TS 102 232-1 the already defined port number (destination port number) 50100
applies, for direct forwarding according to 3GPP TS 33.108 the port number 50010 continues to apply.
The use of 3GPP TS 33.108 shall be in accordance with the conditions set out in Appendix D.1. 3GPP TS
33.128 [40] will be used until further notice after consultation with the Federal Network Agency.
Section 4 in Part A of this TR TKÜV lists those identifiers on which basis the surveillance of
telecommunications should be implemented. If the order specifies an IMEI as identifier of the LuS, the
data sets should contain this IMEI and the associated MSISDN.
In addition to the requirements under Part A, Sections 3 and 4, the following Appendices shall also apply:
Appendix Contents
Appendix A.1 The FTP transmission methods (file name, parameters)
In the circuit-switched domain, the informational content shall be transmitted via ISDN dual stubs
or via the Internet (RTP). For ISDN-based forwarding (as described in this Annex D), the
following applies: The event data (ASCII data) are sent via FTP/IP. The stipulations required to
this end are contained in Appendix A.1.
In packet-switched networks as well as for multimedia services, transmission of both the copy of
the content and the event data takes place via FTP/Internet or TCP/IP. In the case of
transmission via FTP, this Appendix is also applicable.
Appendix A.2 Participation in a VPN via a cryptosystem.
If the data are transmitted over the Internet via FTP or TCP/IP, the procedure for participation in
VPN should also be followed.
Appendix A.3 Transmission of HI1 events and additional events
Appendix A.4 Difficulties in transmission of the surveillance copy to the authorised agency’s lines
TR TKÜV, edition 7.2 (draft) Part A, Appendix D, page 44
Reference is also made to the following appendices in Part X of the TR TKÜV:
Appendix X.1 Proposed changes to the TR TKÜV
Appendix X.2 Assignment of an identifier to the authorised agency to ensure uniqueness of reference numbers
Appendix X.3 Provisions for the registration and certification authority TKÜV-CA of the Federal Network
Agency, Department IS16 (Policy)
Appendix X.4 Table of applicable ETSI/3GPP standards and specifications as well as the ASN.1 modules
Appendix X.5 Requirements for administration and logging in the organisational implementation of surveillance
actions
Requirements for specification of the location in mobile telephony networks
When monitoring an identifier whose use is not fixed to a particular location, the location of the end device
as known to the relevant network should be indicated with the greatest possible accuracy, pursuant to
§ 7(1) point 7 of the TKÜV.
When carrying out orders to provide the location of the end device on standby to receive which is
associated with the identifier being monitored, the available surveillance system may be used
accordingly.
The following provisions apply in this case:
Where possible, the location should be encoded in a form enabling the authorised agency to determine
the geographical location of the radio cell without documentation on the network of the specific operator.
To this end, the location coordinates of the radio cell (e.g. BTS in GSM, NodeB in UMTS, eNodeB for LTE
or gNodeB for 5G NR) and the cell identifier CGI (Cell Global Identification, pursuant to
ETS 300 523 [13]), ECI (E-UTRAN Cell Identifier, pursuant to ETSI TS 123 003) or NCI (NR Call Identity,
pursuant to ETSI TS 123 003) are to be indicated.
Geographical angular coordinates based on WGS84 are to be used.
If the mobile network does not record the exact location of the mobile device, at least the cell through
which the connection is processed should be given.
Details of the location or the cell identifiers are always to be indicated even when information on this is
not present in the core network, but only in the access network. Including the functions so far available
from the networks, the information must at least be indicated for the following events:
Circuit Switched Service
Idle Mode: Periodic Location Update
Connected Mode: Call origination and termination, handover between cells and SMS messaging
Data Service, 2.5G
Standby Mode: Periodic Routing Area Update, Routing Area Update
Ready Mode: GPRS Attach and Detach, Cell Updates (in the active PDP Context) and Routing
Area Update
Data Service, 3G
Idle Mode: Periodic Routing Area Update, Routing Area Update
Connected Mode: GPRS Attach and Detach and Routing Area Update,
Cell Updates (with activated PDP Context in CELL_DCH mode)
Data Service, 4G
Idle Mode: Periodic Tracking Area Update, Tracking Area Update
Connected Mode: Attach and Detach, Tracking Area Update
Inter-eNodeB-Handover
Data Service, 5G NSA
see Data Service 4G
Data Service, 5G SA
To be defined in a subsequent edition of the TR TKÜV
Telecommunications surveillance activation in existing telecommunications links
If there is already a telecommunications link under surveillance when a surveillance action is activated,
then both the content and the event data should be recorded from this time onwards and a copy delivered
(see Appendix H.3.2, point 5.3). Data pursuant to § 7(1) of the TKÜV, which exists on the net at the time
of activation of the surveillance action and is no longer forwarded via future event data (e.g. codecs of the
TR TKÜV, edition 7.2 (draft) Part A, Appendix D, page 45
existing telecommunication), must also be reported. Since there is currently no standard dictating the
technical implementation in detail, the compulsory implementation of this requirement is deferred for the
time being, as long as signalling information and informational content are present in various network
elements, and provided that no information for operational purposes regarding the points at which the
voice data (e.g. IP address, port number) can be forwarded and correlated is provided.
Exceptions for IMEI monitoring
Owing to the network architecture, the IMEI is generally only recorded when logging onto the network and
is not available for monitoring at the corresponding network elements. Forwarding may not be possible in
these cases. Until these situations are standardised, the Federal Network Agency’s restriction, on
condition that these cases are recorded in full as part of telephone number monitoring, must be tolerated.
Once relevant standards have been drawn up, their specifications must be complied with in full.
Annex D.1 Selection of options and determination of additional technical
requirements
The following table describes, on the one hand, the selection of options for the different chapters and
paragraphs of 3GPP Specification TS 33.108 and, on the other, specifies the respective additional
requirements. Unless otherwise indicated, the references in the table relate to the respective sections of
the 3GPP Specification:
Section Description of the option or problem and Additional requirement, background and
3GPP specifications regarding national supplemental information
TS 33.108 application
4.3 Functional requirements
The options ‘IRI and CC’ and ‘only IRI’ should
be supported; the option ‘only CC’ need not be
supported.
4.4 Overview of handover interface
There is no electronic interface from the LEA to For the transmission of events (e.g.
the installation of the subject for direct activation/deactivation/modification of an action,
administration of actions. fault reports) from the installation of the obligated
party to the LEA, the HI1 may be used
The events for administration of an action (e.g. (Appendix A.3 of the TR TKÜV).
about activation) and fault reports should be
reported.
4.5 HI2: Interface port for intercept related
information
For buffering of IRI, the requirement given in See Appendix A.4 of the TR TKÜV.
the adjacent column applies.
4.5.1 Data transmission protocols (HI2)
To transmit the event data (IRI) over the HI1
and HI2 interfaces, FTP is used; ROSE is not
permitted.
The FTP connection should be closed
immediately after transmission of the event
data.
Addendum 1 Security aspects
When using an IP-based transmission point, To protect IP-based transmission points, dedicated
IPSec is applied. IP cryptosystems should be used, based on IPSec
in conjunction with a PKI as referred to in
Appendix A2 of the TR TKÜV.
For transmission of content over ISDN, the Where a COLP check cannot always be carried
service attributes CLIP, COLP and CUG are out reliably, particularly for newer network
used. technologies, it may be disabled permanently or
dispensed with after consulting with the Federal
Network Agency.
Addendum 2 Quantitative aspects
TR TKÜV, edition 7.2 (draft) Part A, Appendix D, page 46
Section Description of the option or problem and Additional requirement, background and
3GPP specifications regarding national supplemental information
TS 33.108 application
The dimensioning of the administration and
transmission capacities is subject to the
guidelines as per Section 5.2 of the TR TKÜV.
Addendum 3 Failure of CC links
In case a connection fails to be created, three See Appendix A.4 of the TR TKÜV.
renewed attempts should be made.
Chapter 5: Circuit-switch domain
5.1.2.1 Network Identifier (NID)
The NID consists, inter alia, of the 5-character
Operator (NO/AN/SP) identifier. In Germany,
the first digits are set to '49' while the remaining
3 digits are determined by the Federal Network
Agency for the relevant obligated party.
5.2.2.1 Control Information for HI2
All times (TimeStamp) should normally be The GeneralizedTime parameter is not encoded as
given as local time based on the official time. universal time and without time difference. The
winterSummerIndication must be specified as
either wintertime or summertime.
5.3.1 Delivery of Content of Communication
Correlation of the informational content (CC) As the user-to-user service has not been
with the other HI Interfaces should not be done implemented in all networks in Germany,
via the user-to-user service but instead via the correlation should exclusively use the subaddress
subaddress service. service.
For the SMS and UUS services, informational Appendix E describes this use.
5.3.1, 5.4
content is transmitted as event data. For transmission of this content, a choice may be
made between either the ASN.1 module
‘HI2Operations’ as described in Appendix D.5 or
the module ‘HI3CircuitDataOperations’ as
described in Appendix D.6. Both modules provide
the relevant parameters for UUS and SMS.
5.3.2 Control information for Content of
Communication
As described above, the end devices of
authorised agencies should immediately
respond to a SETUP message with a
CONNECT message, i.e. without an
ALERTING message.
Addendum 4 Fault Reporting
Fault reports are transmitted as event data (IRI) Fault reports may be transmitted as national
(see Appendix A.4 of the TR TKÜV). parameters or via the HI1 interface as an
alternative. The minimum error events which
In mobile telephony networks, the details of should be transmitted are derived from the national
failures affecting only regional parts of the parameters (as determined in Appendix A.3 of the
network need only be provided upon request TR TKÜV).
from the authorised agency.
5.3.3 Security requirements at the interface port
of HI3
When creating the CC links to the LEMF (LEA), Where a COLP check cannot always be carried
the ISDN service attributes CLIP, COLP and out reliably, particularly for newer network
CUG should be used. technologies, it may be disabled permanently or
dispensed with after consulting with the Federal
Network Agency.
5.3.3.3 Authentication
TR TKÜV, edition 7.2 (draft) Part A, Appendix D, page 47
Section Description of the option or problem and Additional requirement, background and
3GPP specifications regarding national supplemental information
TS 33.108 application
No specific authentication procedure is used in
the ISDN B-channel or the subaddresses.
5.4 LI procedures for supplementary services
For non-standardised (proprietary) surveillance-
relevant service attributes, the required
information should be transmitted in the
national parameters. The content of the
parameters should be agreed with the Federal
Network Agency.
5.4.4 Multi party calls — general principles
5.5.2, 5.5.3, For CW, HOLD and MPTY (with up to For CW, HOLD and MPTY with up to
5.5.11 6 participants), either option A or option B may 6 participants, the following applies:
be used alternatively. For large conferences As multiplexed use of ISDN channels to the
with more than 6 participants, option B should authorised agency as described in option B lead to
be implemented. more complex analysis and more difficult analysis
of the content (no differentiation of speaker per
channel), use of option A should be preferred.
5.4.5 Subscriber Controlled Input The obligation to report controls regarding
operation options in accordance with § 5(1)(4)
TKÜV is lifted. However, systems in operation
before TR TKÜR 7.1 enters into force may still use
these parameters.
5.5.3 Call Hold/Retrieve
When HOLD is activated, both CC links should
be muted during the HOLD phase.
The option where only the held party is muted
is also acceptable.
5.5.4 Explicit Call Transfer (ECT)
After transfer, option 2 should be implemented
(‘The transferred call shall not be intercepted.’).
5.5.15 User-to-User Signalling (UUS)
Informational content for the UUS service is See Sections 5.3.1 and 5.4 in this table.
transmitted as event data.
Chapter 6: Packet data domain
6.4 Quantitative aspects
The dimensioning of the administration and See Addendum 2 in this table.
transmission capacities is subject to the
guidelines as per Section 5.2 of the TR TKÜV.
6.5.0 PacketDirection
The unambiguous designation of the path taken
by content data shall be tracked with to target
and from target.
IP addresses and port numbers
The parameters sourceIPAddress,
destinationIPAddress, sourcePortNumber and
destinationPortNumber should be used for
transmitting the source and destination
IP addresses and the associated port numbers
of the communication participants.
6.5.1.1 REPORT record information
The REPORT record shall be triggered when, This option should not be implemented in
as a national option, a mobile terminal is Germany.
TR TKÜV, edition 7.2 (draft) Part A, Appendix D, page 48
Section Description of the option or problem and Additional requirement, background and
3GPP specifications regarding national supplemental information
TS 33.108 application
authorised for service with another network NB: Where roaming between network operators is
operator or service provider. possible in Germany, an action for any given LuS
should be implemented on all the relevant
networks.
6.6 IRI reporting for packet domain at GGSN
As a national option, in the case where the This option must not be implemented in Germany.
GGSN is reporting IRI for an intercept subject, NB: Where roaming between network operators is
the intercept subject is handed off to another possible in Germany, an action for any given LuS
SGSN and the same GGSN continues to should be implemented on all the relevant
handle the content of communications subject networks.
to roaming agreements, the GGSN shall
continue to report the following IRI of the
content of communication:
- PDP context activation;
- PDP context deactivation;
- Start of interception with PDP context active.
6.7 Content of communication interception for
packet domain at GGSN
As a national option, in the case where the This option may only be implemented in Germany
GGSN is performing interception of the content if the requirement as per § 4(1) of the TKÜV has
of communications, the intercept subject is been fulfilled.
handed off to another SGSN and the same NB: Where roaming between network operators is
GGSN continues to handle the content of possible in Germany, an action for any given LuS
communications subject to roaming should be implemented on all the relevant
agreements, the GGSN shall continue to networks.
perform the interception of the content of
communication.
Chapter 7: Multimedia domain
7.1.2 Network Identifier (NID)
The NID consists, inter alia, of the 5-character
Operator (NO/AN/SP) identifier. In Germany,
the first digits are set to '49' while the remaining
3 digits are determined by the Federal Network
Agency for each obligated party.
7.2.1 Timing
All time stamps should normally be given as The GeneralizedTime parameter is not encoded as
local time based on the official time. universal time and without time difference. The
winterSummerIndication must be specified as
either wintertime or summertime.
For buffering of IRI, the requirement given in See Appendix A.4 of the TR TKÜV.
the adjacent column applies.
7.3 Security aspects.
When using an IP-based transmission point, To protect IP-based transmission points, dedicated
IPSec is applied. IP cryptosystems should be used, based on IPSec
in conjunction with a PKI as referred to in
Appendix A2 of the TR TKÜV.
7.4 Quantitative aspects
The dimensioning of the administration and
transmission capacities is subject to the
guidelines as per Section 5.2 of the TR TKÜV.
7.5 IRI for IMS
In case of IRI-only surveillance, the content of
communication, for example SMS content or
other messaging content (e.g. immediate
TR TKÜV, edition 7.2 (draft) Part A, Appendix D, page 49
Section Description of the option or problem and Additional requirement, background and
3GPP specifications regarding national supplemental information
TS 33.108 application
messaging), shall be removed from the
‘SIPmessage’ parameter before forwarding.
7.5.1 Events and information If the obligated party used encryption on the
network side or it is involved in generating or
The Correlation number and Correlation exchanging keys, thereby allowing it to decrypt the
parameters in accordance with Table 2 shall be telecommunication, the encryption at the handover
reported. point must be lifted (§ 8(3) TKÜV).
The parameter mediaDecryption-info. If the subject supports encryption of peer-to-peer-
CCKeyInfo.cCSalt must be reported if it is communications over the Internet by means of key
available to the obligated party. management provided by him/her, without
involving his/her network elements or those of
his/her partners in the transmission of the content,
he/she should at least inform the authorised
agency of the key initially exchanged by him/her
with his/her telecommunication system.
Transmission of the exchanged key is not required
if the subject can still remove the encryption by
means of additional network elements.
Chapter 8: 3GPP WLAN Interworking
In Germany, where publicly accessible services as
defined in Section 8 of
3GPP Specification TS 33.108 are offered, the
associated requirements must always be fulfilled.
Further details as to the form of the surveillance
functionality for these services, shall be agreed
with the Federal Network Agency.
Chapter 9: Interception of Multimedia Broadcast /MultiCast Service (MBMS)
In Germany, where publicly accessible services as
defined in Section 9 of
3GPP Specification TS 33.108 are offered, the
associated requirements must always be fulfilled.
Further details as to the form of the surveillance
functionality for these services, shall be agreed
with the Federal Network Agency.
Chapter 10: Evolved Packet System (EPS)
10.1.2 Network Identifier (NID)
The NID consists, inter alia, of the 5-character
Operator (NO/AN/SP) identifier. In Germany,
the first digits are set to '49' while the remaining
3 digits are determined by the Federal Network
Agency for each obligated party.
10.2.1 Timing
All time stamps should normally be given based The GeneralizedTime parameter is not encoded as
on the official time. universal time and without time difference. The
winterSummerIndication must be specified as
either wintertime or summertime.
For buffering of IRI, the requirement given in See Appendix A.4 of the TR TKÜV.
the adjacent column applies.
10.3 Security aspects.
When using an IP-based transmission point, To protect IP-based transmission points,
IPSec is applied. dedicated IP cryptosystems should be used,
based on IPSec in conjunction with a PKI as
referred to in Appendix A2 of the TR TKÜV.
10.4 Quantitative aspects
TR TKÜV, edition 7.2 (draft) Part A, Appendix D, page 50
Section Description of the option or problem and Additional requirement, background and
3GPP specifications regarding national supplemental information
TS 33.108 application
The dimensioning of the administration and
transmission capacities is subject to the
guidelines as per Section 5.2 of the TR TKÜV.
10.5.0 PacketDirection
The unambiguous designation of the path taken
by content data shall be tracked with to target
and from target.
IP addresses and port numbers
The parameters sourceIPAddress,
destinationIPAddress, sourcePortNumber and
destinationPortNumber should be used for
transmitting the source and destination
IP addresses and the associated port numbers
of the communication participants.
10.5.1.1.5 Tracking Area Update (REPORT)
old location information
This parameter shall be reported if it is available in
Provide (only by the old MME), when the obligated party’s surveillance functionality.
authorised and if available, to identify the old
location information for the intercept
subject’s MS.
10.5.1.4.1 Bearer Deactivation (END)
EPS bearer id
This parameter shall be reported if it is available in
the subject’s surveillance functionality.
10.6 IRI reporting for evolved packet domain at
PDN-GW
This option must not be implemented in Germany.
In certain circumstances (e.g. roaming), the
PDN-GW may constitute the only surveillance NB: Where roaming between network operators is
possibility. In these cases, the surveillance possible in Germany, an action for any given LuS
functionality for event data capture and should be implemented on all the relevant
forwarding (IRIs) shall be implemented at the networks.
PDN-GW in accordance with Section 10.6 of
3GPP Specification 33.108.
10.7 CC interception for evolved packet domain
at PDN-GW
This option may only be implemented in Germany
In certain circumstances (e.g. roaming), the if the requirement under § 4(1) of the TKÜV has
PDN-GW may constitute the only surveillance been fulfilled.
possibility. In these cases, the surveillance
functionality for content-of-communication (CC) NB: Where roaming between network operators is
capture and forwarding shall be implemented at possible in Germany, an action for any given LuS
the PDN-GW in accordance with Section 10.7 should be implemented on all the relevant
of 3GPP Specification 33.108. networks.
Chapter 11: 3GPP IMS Conference Services
Chapter 12: 3GPP IMS-based VoIP Services
Chapter 13: Interception of Proximity Services (ProSe)
Chapter 14: Invocation of Lawful Interception (LI) for Group Communications System Enablers (GCSE)
Chapter 15: Interception of Messaging Services
In Germany, where publicly accessible services as
defined in Sections 11 to 15 of
3GPP Specification TS 33.108 are offered, the
associated requirements must always be fulfilled.
Further details as to the form of the surveillance
functionality for these services, shall be agreed
with the Federal Network Agency.
TR TKÜV, edition 7.2 (draft) Part A, Appendix D, page 51
Section Description of the option or problem and Additional requirement, background and
3GPP specifications regarding national supplemental information
TS 33.108 application
Appendix A: HI2 delivery mechanisms and procedures
A.1.2.3.1 Data link establishment
Optionally a Data link test procedure may be This option is not relevant in view of the decision to
used to verify periodically the data link. use FTP as the transfer protocol for the IRI.
A.2 FTP
For the transmission of the IRI, FTP must be
used in Germany. File naming method B must
be used.
The provisions of Appendices A.1 and A.2 of
the TR TKÜV also apply.
Appendix C: UMTS HI3 interface
C UMTS HI3 Interface
The choice between use of the ULIC-header All options (ULIC Version 0 and Version 1 and
Version 0 or Version 1 or FTP is left to the FTP) should be supported on the side of the
subjects. authorised agency.
C.1.1 Introduction
In Germany, transmission method TCP/IP is For transmission, port number 50010 is chosen on
envisaged. the part of the authorised agency (destination port
number).
C.1 UMTS LI correlation header
Option ULICv1 must be implemented in
Germany.
When using the ULIC header Version 1, the
parameters LIID and timeStamp should be
used (mandatory).
Annex J: Use of subaddress and calling party number to carry correlation information
J.2.3.2 Field order and layout
The parameters for assigning CC and IRI
according to Tables J.2.3 and J.2.4 should be
used accordingly.
Under purely national stipulations for circuit-
Also, the octets 17–23 of the Called Party switched networks (Appendix B of the TR TKÜV),
Subaddress (Table E.3.4 and E.3.6) should subaddresses are also used, but with a different
contain the fixed bit pattern content. To enable the analysis device of
‘45 54 53 49 20 56 32' hex = ETSI V2’ to the authorised agency to make a distinction, this
differentiate it from the subaddresses according differentiating attribute is mandatory.
to the stipulations of Appendix B of the
TR TKÜV.
Appendix D.2 Explanations of the ASN.1 descriptions
On its website, the Federal Network Agency publishes information, pursuant to § 36 sentence 5 of
the TKÜV, on the applicable ETSI and 3GPP standards and specification, including the associated
ASN.1 modules. Use of the different versions of the national ASN.1-module is also regulated.
Appendix X.4 contains further explanations in this regard.
The ASN.1 descriptions of the different modules for implementations according to this Appendix D should
be taken from the various versions of 3GPP Specification TS 33.108, taking care to correct any errors in
the ASN.1-modules contained in them (e.g. incorrect domainID). Because FTP is used as the transfer
protocol, ROSE operations are not relevant.
Whenever the above information is updated on the website of the Federal Network Agency, the updated
versions of the ASN.1-modules may be used. Potentially, without a corresponding update on the part of
the authorised agency, not all parameters may be able to be interpreted.
TR TKÜV, edition 7.2 (draft) Part A, Appendix D, page 52
Parameters designated as ‘conditional’ or ‘optional’ in the specification should normally be transmitted if
they are available and the relevant specification, or Appendix D.1 where applicable, does not contain any
contrary provisions.
For the associated ASN.1 types of the “OCTET STRING” format, the following rules apply:
If the standard has defined a format for the relevant parameters, e.g. ASCII or a cross-reference
to a (signalling) standard, this format should be used.
If no particular format has been prescribed, both hexadecimal values should be inserted in the
relevant bytes, with the higher-order half-byte in bits 5-8 and the lower-order half-byte in bits 1-4.
(Examples: 4F H is entered as 4F H = 0100 1111 and not as F4 H. Or, for example,
DDMMYYhhmm = 23.07.2002 10:35 h is entered as ‘2307021035’ H and not ‘3270200153’ H)
Transmission of administrative events (e.g. activation/deactivation/modification of actions as well as fault
reports) and additional events (e.g. with regard to manufacturer-specific services) takes place according
to Appendix A.3.
TR TKÜV, edition 7.2 (draft) Part A, Appendix E, page 53
Appendix E Transmission point for storage
systems for voice, facsimile and data
(voice-mail systems, Unified
Messaging Systems, etc.)
This Appendix describes the national requirements for the transmission point in storage systems (UMS,
VMS, etc.). As the stipulations contained in Appendices B to D do not take account of these types of
systems, these requirements should be fulfilled additionally where applicable.
In addition to the requirements under Part A, Sections 3 and 4, the following Appendices shall also apply:
Appendix Contents
Appendix A.1 The FTP transmission methods (file name, parameters)
The copy of the informational content is transmitted in accordance with this annex E together
with the event data in an XML-encoded file, which can be transmitted over FTP/Internet. The
stipulations required to this end are contained in Appendix A.1.
Appendix A.2 Participation in a VPN via a cryptosystem
If the surveillance copy is transmitted via FTP/Internet, the procedure for participation in VPN
should also be followed.
Appendix A.3 Transmission of HI1 events and additional events
Appendix A.4 Difficulties in transmission of the surveillance copy to the authorised agency’s lines
Reference is also made to the following appendices in Part X of the TR TKÜV:
Appendix X.1 Proposed changes to the TR TKÜV
Appendix X.2 Assignment of an identifier to the authorised agency to ensure uniqueness of reference numbers
Appendix X.3 Provisions for the registration and certification authority TKÜV-CA of the Federal Network
Agency, Department IS16 (Policy)
Appendix X.4 Table of applicable ETSI/3GPP standards and specifications as well as the ASN.1 modules
Appendix X.5 Requirements for administration and logging in the organisational implementation of surveillance
actions
Appendix E.1 Definitions
Unified Messaging System All variants of storage systems used in telecommunications networks,
(UMS) which are typically used for several modalities of telecommunication,
such as voice, fax, e-mail, Short Messages, Multimedia Messaging
Service (MMS), etc.
(UMS)Box The part of the Unified Messaging System which is allocated to a
particular subscriber – the LuS in the cases under consideration here.
Appendix E.2 General explanations
In the technical implementation of ordered surveillance actions for telecommunications, it should be noted
with regard to UMS that this system has the particular property that it does not provide real-time
communication between the LuS and its communication partner. This property affects several aspects of
the technical implementation of such surveillance actions, particularly with regard to the transmission of
the surveillance copy to the authorised agency:
it is not necessary to separate the telecommunication under surveillance into sending and
receiving directions and to transmit these separately,
TR TKÜV, edition 7.2 (draft) Part A, Appendix E, page 54
in view of the absence of the real-time requirement in these cases, new - useful as well as
economical - options for transmission of the telecommunication under surveillance can be
considered.
The copy of the content taken from the aforementioned storage systems may be transmitted to
the authorised agency with a small time delay, but should still be sent as close to real time as possible: no
later than immediately after storing a message in the storage system, or with a delay not exceeding
10 seconds when retrieving a message.
When a full copy of a given message has already been transmitted, it suffices to send only the event data
in the case of further events (e.g. subsequent listening to the message). To enable correct grouping of the
different transmissions at the authorised agency in these cases, the allocation number field should
contain a unique identifier.
Since a surveillance order covers only the telecommunication which is stored, retrieved or copied in the
relevant UMS during the specified period, any messages which were already present in the UMS before
such period may not be monitored. These should, however, be included when they are retrieved from the
system, for example.
Appendix E.3 Basic forwarding methods and determination of relevant events
Appendix E.3.1 Basic forwarding methods for the telecommunication under
surveillance
The telecommunication types of voice, fax and SMS stored in Unified Messaging Systems are normally
amenable to collection or forwarding in conjunction with implementations pursuant to Appendices B, C, D,
F, H or I. There is an alternative possibility of transmitting these telecommunication types to the
authorised agency in an XML-encoded file via FTP.
Multimedia messages (MMS) stored in UMSs are also transmitted to the authorised agency in an XML-
encoded file via FTP. In addition, MMS may normally be transmitted to the authorised agency using the
transmission point described in Appendix H.
If the UMS additionally provides functionality of the e-mail service, or if the e-mail service is used to
transmit messages, then the transmission point for this telecommunication type should be designed
according to Appendix F. In addition, it is permitted, in principle, for all telecommunication types to effect
forwarding according to Appendix F, e.g. if they are stored in the UMS in the form of e-mail.
The table below reiterates the individual options:
Content Forwarding methods
via an ISDN 64 kbit/s connection with the ISDN Bearer Service ‘Unrestricted Digital Information
(UDI)’ according to Appendix B, or Appendix C or D. This method is only allowed until 31
December 2021; new implementations are no longer possible.
via RTP connections pursuant to Appendix H (the encoding used 1) should be agreed with the
Voice Federal Network Agency).
In wav or mp3 format in an XML-encoded file2) together with the event data according to
Appendix E.5, which may be transmitted via FTP.
in e-mail format according to Appendix F.
in XML format in accordance with Appendix I.
via an ISDN 64 kbit/s connection supporting the procedures as described in ITU-
T Recommendation T.30 and the ISDN Teleservice ‘Facsimile Gr. 2/3’ as described in
Appendix B, C or D. This method is only permitted until 31 December 2021; new
implementations are no longer possible.
Fax via RTP connections pursuant to Appendix H (the encoding used 1) should be agreed with the
Federal Network Agency).
in tif, jpg or png format in an XML-encoded file1) together with the event data according to
Appendix E.5, which may be transmitted via FTP.
in e-mail format according to Appendix F.
in XML format in accordance with Appendix I.
TR TKÜV, edition 7.2 (draft) Part A, Appendix E, page 55
in an event data set according to Appendix B, C or D.
via RTP connections or SIP messages pursuant to Appendix H (the method and encoding used
1) should be agreed with the Federal Network Agency).
SMS 3)
as SMS in an XML-encoded file1) together with the event data according to Appendix E.5,
which may be transmitted via FTP.
in e-mail format according to Appendix F.
in XML format in accordance with Appendix I.
Multimedia in e-mail format in an XML-encoded file1) together with the event data according to Appendix
messages E.5, which may be transmitted via FTP.
(MMS)
in e-mail format according to Appendix F.
via RTP connections or SIP messages pursuant to Appendix H (the method and encoding used
1) should be agreed with the Federal Network Agency).
E-mail in an XML-encoded file together with the event data via FTP, as described in Appendix F.
in XML format in accordance with Appendix I.
Appendix E.3.1-1 - Table: Forwarding methods for UMS
1) Exclusively open encoding algorithms should be used for the encoding.
2) Transmission of the XML-encoded file to the authorised agency is subject to the requirements for the event data
pursuant to Appendices B, C, D and H in terms of transmission and the security requirements.
If the file with the copy of the content and the event data cannot be transmitted to the authorised agency during the
first connection attempt, then three further transmission attempts should be made within a few minutes. Further
details are given in Appendix A.4.
3) The message text of an SMS or MMS should be sent to the authorised agency as text in the UTF-8 character set.
Alternatively, when sending the message content of an SMS, the content of the entire PDU (incl. SM Header,
Subscriber data Header, Subscriber data) may be sent in hexadecimal form, as per Specification 3GPP TS 23.040.
This complies with the requirement as per Appendices B, C, D or H.
Appendix E.3.2 Basic determination of relevant events
For the following basic events, a copy of the informational content as well as the event data should be
forwarded. If the UMS has service attributes not covered by these events (e.g. callback in response to a
stored voice message), the relevant requirements should be agreed with the Federal Network Agency:
Event Remarks
Recording or storing Recording or storing a message (voice, fax or SMS) in the UMS, through:
call forwarding via the identifier of the LuS, or
dialling or sending from an arbitrary connection (e.g. dialling directly into
the UMS via a service number or via web access)
Retrieving or reading Retrieving or reading a message (voice, fax or SMS) from the UMS, through:
the identifier of the LuS, or by dialling this identifier with subsequent call
forwarding to the UMS
an arbitrary connection (e.g. dialling directly into the UMS via a service
number or via web access)
Copying memory contents Copying memory contents from one box associated with the identifier of the LuS
to another box, and vice versa
Access to the box and The possible events (e.g. storing a notification number, generating mailing lists)
modification of settings should be agreed in individual cases with the Federal Network Agency.
Appendix E.3.2-1 - Table: Events in UMSs
Appendix E.4 Requirements for surveillance of voice and fax messages and SMS
according to Appendices B, C or D
Due to the anticipated closing down of ISDN-based technology, the corresponding forwarding
based on this technology must also be adapted. New implementations with forwarding based on
TR TKÜV, edition 7.2 (draft) Part A, Appendix E, page 56
ISDN are no longer permitted. Existing systems must be converted to IP-based forwarding in
accordance with Appendix D or H by 31 December 2021 at the latest.
The following deviating requirements or clarifications apply to the forwarding of voice and fax messages
via ISDN connections and SMS by means of an event data set designed according to the principles
described in Appendices B, C or D for circuit-switched networks.
Item No Deviating requirements or clarifications Remarks
A. Forwarding of a copy of voice messages
1 The information to be transmitted to the authorised As an alternative, if the welcome message
agency consists of the entire voice message, including and/or end delimiter are always the same,
any welcome message and any end delimiter (e.g. a they may be transmitted once at the start of
sound or text message). the surveillance action.
Whenever the content changes, it should be
transmitted to the authorised agency again.
2 Transmission takes place via an ISDN 64 kbit/s For transmission, an ISDN stub (mono mode)
connection using the ISDN bearer service ‘Unrestricted is adequate, i.e. a dual stub for sending and
digital information (UDI)’. receiving directions, as in surveillance of a
telephone line, is not necessary here.
If transmission to the authorised agency
should fail, three other connection attempts
Call origination by the UMS is automatic; the copy of the should be made at intervals of a few minutes,
voice message may be copied prior to calling into a box e.g. 3 minutes (see also Appendix A.4).
associated with the authorised agency.
Pursuant to the requirements of Appendices B, C or D,
the matching criteria are transmitted in the subaddress.
3 The security requirements as described in This is necessary so that the authorised
Appendices B, C or D (CLI, CUG) should be complied agency can be redirected to other identifiers
with. A ‘Connected Number’ sent by the authorised for receiving fax messages.
agency may not be verified.
4 Both content and transmission of event data sets are
subject to Part D of this table
B. Forwarding of a copy of fax messages
1 The copy of a fax message as transmitted to
the authorised agency consists of the entire fax
message as received by the LuS or the latter’s
communication partner.
2 Transmission takes place with the aid of the procedures For transmission, an ISDN stub (mono mode)
as described in ITU-T Recommendation T.30 and the is adequate, i.e. a dual stub for sending and
ISDN Teleservice ‘Facsimile Gr. 2/3’, i.e. Bearer receiving directions, as in surveillance of a
Capability BC = ‘audio 3.1 kHz’ and High Layer telephone line, is not necessary here.
Compatibility HLC = ‘Facsimile Gr 2/3’. In this context, the recording devices of the
authorised agencies support the procedures
of ITU-T Recommendation T.30
If transmission to the authorised agency
should fail, three other connection attempts
Call origination by the UMS is automatic; the copy of the should be made at intervals of a few minutes,
voice message may be copied prior to calling into a box e.g. 3 minutes (see also Appendix A.4).
associated with the authorised agency.
Transmission of the matching criteria in both
the subaddress and the header enables
Pursuant to the requirements of Appendices B, C or D, the authorised agency to use both integrated
the matching criteria are transmitted in the subaddress. devices with facilities for automatic analysis of
Additionally, the reference number (or, in case of subaddresses and common commercial fax
Appendix B, the phone number of the LuS) and the devices with manual matching.
allocation number are sent to the authorised agency in
the Header of the fax message
3 The security requirements as described in This is necessary so that the authorised
Appendices B, C or D (CLI, CUG) should be complied agency can be redirected to other identifiers
with. A ‘Connected Number’ sent by the authorised for receiving fax messages.
agency may not be verified.
4 Both content and transmission of event data sets are
subject to Part D of this table
TR TKÜV, edition 7.2 (draft) Part A, Appendix E, page 57
Item No Deviating requirements or clarifications Remarks
C. Forwarding of a copy of SMS messages
1 The copy of an SMS message as transmitted to the
authorised agency consists of the message content in
UTF-8 format or the entire PDU (incl. SM Header, User
data header, User data).
2 Transmission is in a single event data set. Parameters are envisaged each time in the
corresponding appendices.
Call origination by the UMS is automatic; the copy of the If transmission to the authorised agency
SMS message may be copied prior to calling into a box should fail, three other connection attempts
associated with the authorised agency. should be made at intervals of a few minutes,
e.g. 3 minutes (see also Appendix A.4).
3 The security requirements as described in
Appendices B, C or D (CUG or VPN) should be
complied with when transmitting event data.
4 Both content and transmission of other event data sets
are subject to Part D of this table
D. Content and transmission of ancillary event data
1 For every event listed in the table of Appendix E-1.1, an Possible events are:
event data set is created and transmitted according to recording of a voice message
the requirements of Appendices B, C or D.
listening to a voice message
The event to be reported is included in field 13 (Service
Attribute) for implementations pursuant to Appendix B, access to the box
and in the national parameter for implementations receipt of a box-to-box message
pursuant to Appendices C or D.
notifications of stored messages via SMS
or e-mail
modification of notification number
creation or modification of mailing lists
Appendix E.1.3-2 - Table: Deviating requirements or clarifications for UMS
Appendix E.5 Requirements for surveillance of voice and fax messages, SMS and
MMS in an XML-encoded file
As an alternative to forwarding according to Appendix E.4, copies of the various telecommunication types
voice, fax, SMS and MMS may be transmitted in unified form by means of an XML-encoded file over FTP.
In this case, the different telecommunication types should be converted into a file format corresponding to
the table below. This table will be extended as new technologies are introduced. Any new parameters to
be defined should be agreed with the Federal Network Agency.
Parameter (tag) Application
<audio-wav> voice message in wav format
<audio-mp3> voice message in mp3 format
<fax-tif> fax message in TIFF format
<fax-jpg> fax message in JPEG format
<fax-png > fax message in PNG format
<sms> Short Message
<mms> Multimedia Message
The MMS to be monitored is expressed in the form of e-mail such that the message text is
given in the text field and the associated images as attachments. No parameters are given in
the e-mail header.
Appendix E.5-1 - Table: Parameter (tag) for file formats
TR TKÜV, edition 7.2 (draft) Part A, Appendix E, page 58
Appendix E.5.1 Parameters for event data
The individual parameters for event data, which are typically combined with the copy of the content into
an XML-encoded file for transmission to the authorised agency, are listed in the following table:
Parameters Values/definition/explanation
<version identifier> identifier allocated by the operator of the STS, which designates the relevant interface
version, in ASCII format (max. 20 characters)
<data set type> ‘report’ as identifier of a unique event
<reference number> identifier of the surveillance action pursuant to § 7(2) sentence 1 of the TKÜV, in
ASCII format
<allocation number> number enabling allocation to content, in ASCII format (values of 1 to 65 535)
<identifier of the LuS> attribute of the identifier under surveillance pursuant to § 7(1) sentence 1 point 1 of
the TKÜV (e.g. telephone service or fax number associated with the UMS pursuant to
E.164, e-mail address)
<partner identifier> 1) identifier pursuant to §7(1) sentence 1 points 2 to 4 of the TKÜV, from which a message
is stored or retrieved, or settings are made (e.g. phone number of the line with which
the UMS is associated, service number)
<IP> 1) The IP-address transmitted to the UMS, pursuant to § 7(1) sentence 1 points 2 to 4 of
the TKÜV (IP address of the telecommunication partner, e.g. when retrieving or storing
messages via web access, if there is no phone number which serves as the partner
identifier)
<start> start of monitored telecommunication (e.g. time of storing a message) according to
§ 7(1) sentence 1 point 8 of the TKÜV, in the format:
DD/MM/YY hh:mm:ss
The file with event data and/or informational content should not be transmitted
to authorised agencies until after completion of the monitored telecommunications
procedure.
<settings> 1.Details of the settings made in the UMS, starting with the event:
‘access’ (to the box by its owner), ‘create mailing lists’,
‘messaging’ (settings in the notification service), ‘welcome text’,
‘change’ (other box settings),
2. followed by the settings made (parameters) in the format: free ASCII-encoded text
These details should be separated by ‘;’ (ASCII character no 59).
<direction> Details of the event being reported, e.g.:
‘received’, ‘retrieved’, ‘listened’ (for messages ), ‘received box-to-box’,
‘stored’, ‘sent’, ‘recorded’ (for messages ), ‘sent box-to-box’,
‘notification’ (of stored messages), ‘callback’2). If several events are stored and sent
almost simultaneously, for example, two values may be inserted, separated by ‘;’
(ASCII character no 59).
<cause of termination at Indication of the reason why the monitored connection was closed, e.g.
monitored line> ‘successful’ or
error message from the system as a text string, e.g. interruption of a download.
The text string may contain only the ASCII characters of the Base64 alphabet.
<start of surveillance Once for each action, with the time of activation of the action (not of administration in
action> case of time-controlled actions) in the STS pursuant to § 5(5) of the TKÜV, in the format:
DD/MM/YY hh:mm:ss
<end of surveillance Once for each action, with the time of deactivation of the action (not of administration in
action> case of time-controlled actions) in the STS pursuant to § 5(5) of the TKÜV, in the format:
DD/MM/YY hh:mm:ss
Table E.5.1-1: Parameters for event data in the XML file
1) This serves to enable transmission of at least the IP address if a unique <partner identifier> is not available.
2) If the owner of the box in a VMS/UMS is able, based on a received message, to initiate a call to the line from which
the message was stored, this event should be reported, and additionally it should be ensured that such a call is
TR TKÜV, edition 7.2 (draft) Part A, Appendix E, page 59
also monitored. It is not necessary to relate the ‘callback’ event to the stored message using the <allocation
number> parameter.
Appendix E.5.2 The XML structure and DTD for voice, fax, SMS and MMS
The XML-encoded file should be created in UTF-8 format.
The following example of an XML structure has values included for all tags. These tags should, however,
only be transmitted if the relevant event requires them. If there are no parameters for the relevant event
data, an empty tag should be used in accordance with XML syntax, e.g. “<start-UEM/>”. Comment lines
are not required and may be omitted.
XML structure (with example entries):
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE hi3-ums SYSTEM "hi3-ums_v1.dtd">
<?xml-stylesheet href="ums_v1.xsl" type="text/xsl"?>
<hi3-ums>
<version identifier>ABC1234</version identifier>
<data set type>report</data set type>
<reference number><![CDATA[123456789 in Base64 encoding 1]]></reference number>
<sequence number><![CDATA[123 in Base64 encoding 1]]></sequence number>
<identifier-of the-monitored-line><![CDATA[987654#E.164#national number in Base64 encoding 1]]></identifier-
of the-monitored-line>
<IP>111.222.63.254</IP>
<partner identifier><![CDATA[123456#E.164#national number in Base64 encoding 1]]></partner identifier>
<start>31/12/06 10:10:05</start>
<settings><![CDATA[announcement text;free text in Base64 encoding 1]]></settings>
<direction><![CDATA[retrieved in Base64 encoding 1]]</direction>
<cause-of-termination-at-monitored-line><![CDATA[normal call clearing in Base64 encoding 1]]></cause-of-
termination-at-monitored-line>
<start-of-surveillance-action>01/12/06 01:00:00</start-of-surveillance-action>
<end-of-surveillance-action>01/02/07 01:00:00</end-of-surveillance-action>
<fax-tif>
<!-- start fax-tif -->
<![CDATA[copy of the entire fax to be monitored in Base64 encoding 1]]>
<!-- end fax-tif -->
</fax-tif>
<fax-jpg>
<!-- start fax-jpg -->
<![CDATA[copy of the entire fax to be monitored in Base64 encoding 1]]>
<!-- end fax-jpg -->
</fax-jpg>
<fax-png >
<!-- start fax-png -->
<![CDATA[copy of the entire fax to be monitored in Base64 encoding 1]]>
<!-- end fax-png -->
</fax-png>
<audio-wav>
<!-- start audio-wav -->
<![CDATA[copy of the entire audio signal to be monitored in Base64 encoding 1]]>
<!-- end audio-wav -->
</audio-wav>
<audio-mp3>
<!-- start audio-mp3 -->
<![CDATA[copy of the entire audio signal to be monitored in Base64 encoding 1]]>
<!-- end audio-mp3 -->
</audio-mp3>
<sms>
TR TKÜV, edition 7.2 (draft) Part A, Appendix E, page 60
<!-- start SMS -->
<![CDATA[copy of the entire SMS to be monitored in Base64 encoding 1]]>
<!-- end SMS -->
</sms>
<mms>
<!-- start MMS -->
<![CDATA[copy of the entire MMS to be monitored to be inserted here in e-mail format in Base64 encoding 1]]>
<!-- end MMS -->
</mms>
</hi3-ums>
Doctype definition:
<!ELEMENT hi3-ums (version identifier,data set type,reference number,sequence number,identifier-of the-
monitored-line,IP,partner identifier,start,settings,direction,cause-of-termination-at-monitored-line,start-of-
surveillance-action,end-of-surveillance-action,fax-tif,fax-jpg,fax-png,audio-wav,audio-mp3,sms,mms)>
<!ELEMENT version identifier (#PCDATA)>
<!ELEMENT data set type (#PCDATA)>
<!ELEMENT reference number (#PCDATA)>
<!ELEMENT sequence number (#PCDATA)>
<!ELEMENT identifier-of the-monitored-line (#PCDATA)>
<!ELEMENT IP (#PCDATA)>
<!ELEMENT partner identifier (#PCDATA)>
<!ELEMENT start (#PCDATA)>
<!ELEMENT settings (#PCDATA)>
<!ELEMENT direction (#PCDATA)>
<!ELEMENT identifier-of the-monitored-line (#PCDATA)>
<!ELEMENT start-of-surveillance-action (#PCDATA)>
<!ELEMENT end-of-surveillance-action (#PCDATA)>
<!ELEMENT fax-tif (#PCDATA)>
<!ELEMENT fax-jpg (#PCDATA)>
<!ELEMENT fax-png (#PCDATA)>
<!ELEMENT audio-wav (#PCDATA)>
<!ELEMENT audio-mp3 (#PCDATA)>
<!ELEMENT sms (#PCDATA)>
<!ELEMENT mms (#PCDATA)>
1
The values of the individual tags or the copy of the monitored message should be included in Base64 encoding as
per RFC 822 or RFC 2045 [26]. Please note that the Base64 encoding requires a line break to be inserted every
76 characters.
TR TKÜV, edition 7.2 (draft) Part A, Appendix F, page 61
Appendix F Stipulations for storage systems for
the e-mail service
This Appendix contains two alternative descriptions of the transmission point for surveillance of the e-mail
service:
Appendix F.2 defines a national transmission point from which the copy of the e-mail is
transmitted to the authorised agency together with the event data in an XML file via FTP.
The alternative description of the transmission point of Appendix F.3 is derived from
ETSI Specification TS 102 233 or TS 102 232-02 [30] and describes an ASN.1 file which also
contains the entire surveillance copy and uses TCP/IP for transmission.
In addition to the requirements under Part A, Sections 3 and 4, the following Appendices shall also apply:
Appendix Contents
Appendix A.1 The FTP transmission methods (file name, parameters)
If the copy of the e-mail pursuant to this Appendix F.2 is transmitted together with the event data
in an XML-encoded file via FTP/Internet, the stipulations of Appendix A.1 apply.
Appendix A.2 Participation in a VPN via a cryptosystem.
If the surveillance copy is transmitted by FTP/Internet in accordance with Appendix F.2, the
procedure for participating in the VPN should also be followed.
Appendix A.3 Transmission of HI1 events and additional events
Appendix A.4 Difficulties in transmission of the surveillance copy to the authorised agency’s lines
Reference is also made to the following appendices in Part X of the TR TKÜV:
Appendix X.1 Proposed changes to the TR TKÜV
Appendix X.2 Assignment of an identifier to the authorised agency to ensure uniqueness of reference numbers
Appendix X.3 Provisions for the registration and certification authority TKÜV-CA of the Federal Network
Agency, Department IS16 (Policy)
Appendix X.4 Table of applicable ETSI/3GPP standards and specifications as well as the ASN.1 modules
Appendix X.5 Requirements for administration and logging in the organisational implementation of surveillance
actions
Appendix F.1 Definitions, fundamentals
E-mail server Any kind of telecommunications equipment which stores or transmits e-mail service
messages, irrespective of how it is accessed by the user, e.g. SMTP, POP3, IMAP,
WEB or WAP.
E-mail address Address according to RFC 822, RFC 2822.
The e-mail address is an identifier used to denote the telecommunication under
surveillance.
Mailbox Storage space for e-mail-messages of a given user (e-mail account), where both
sent and received messages are kept. A monitored e-mail mailbox may sometimes
contain several e-mail addresses.
Login Procedure by which the access rights of a given subscriber or other end-user for
this mailbox are verified.
Login name The login name used at login as part of the access data is, in addition to the e-mail
address, also an identifier used to denote the telecommunication under
surveillance.
TR TKÜV, edition 7.2 (draft) Part A, Appendix F, page 62
An order for surveillance of telecommunications in the e-mail service may contain, as a technical attribute:
an e-mail address, or
the access identifier (login name without password) of a mailbox.
To implement surveillance of the entire telecommunication which takes place under the given identifier,
care should be taken especially for outgoing traffic (e.g. sending e-mails via SMTP) that the monitored
telecommunication is actually associated with the LuS by using suitable authentication methods. This
should prevent situations where, for example, sending an e-mail which should be monitored fails to be
recorded because the sender address was manipulated by the user.
Whereas this requirement is typically fulfilled in login name-based surveillance by the login authentication
procedure (login name and password), e-mail address-based surveillance can only be implemented if the
authentication methods used by the particular protocol also fulfil this requirement. Appendix F.2 contains
further details on the permitted authentication methods in this context.
If this requirement cannot be fulfilled (e.g. due to an unsuitable authentication method) for one of the
protocols SMTP, POP3 or IMAP, an e-mail address-based order for the entire mailbox should be
implemented for the relevant protocol instead, which should include the telecommunications of all e-mail
addresses of this mailbox. If no integrated authentication procedure is in place for access to the mailbox,
then another authentication procedure, or another procedure enabling only the telecommunications on
the LuS to be monitored, shall be agreed with the Federal Network Agency.
The informational content, consisting of a complete copy of the monitored e-mail (header, body and
attachment), is combined with the associated event data into a file. This file should be transmitted to
the authorised agency via FTP immediately after the occurrence of the relevant event. However, in
certain usage scenarios, such as multipart messages, it is possible that the e-mail to be monitored is not
transmitted in a single file, provided that the requirements for the non-caching of user information and the
provision of unmodified, monitored telecommunications are met. This ensures that even individual parts
of an e-mail that has not been completely transmitted are transferred to the recording lines of the
authorised agencies.
In cases where surveillance of only the event data has been ordered, only these should be transmitted to
the authorised agency (without the content).
Appendix F.2 Nationally specified e-mail transmission point
When a full copy of a given e-mail has already been transmitted to the authorised agency, it suffices to
send only the event data in the case of further events as described in Tables F.2-1-1 to F.2-1-4 (e.g.
subsequent retrieval of the e-mail). To enable correct grouping of the different transmissions at
the authorised agency in these cases, the allocation number field should contain a unique identifier.
The list given in Tables F.2-1-1 to F.2-1-4 may need to be supplemented or modified depending on the
actual possibilities of the specific e-mail server.
For the following events, a copy of the informational content as well as the event data should normally be
forwarded to the authorised agency:
Simple Mail Transfer Protocol (SMTP)
Event Remarks Value of the Notes regarding the value of the
XML parameter XML parameter <partner identifier>
<direction>
Receipt of an e- Regardless of whether it is ‘received’ In e-mails intended for the monitored e-
mail delivered directly to the mail address, the event data field
monitored user or stored in the <partner identifier> should contain only
mailbox. the sender (Envelope: MAIL FROM as
per RFC 2822), but not the other
recipients (Envelope: RCPT TO as per
RFC 2822).
The identifier of the LuS should be
given in an a RCPT TO field of the
envelope or in the TO field of the
header of the e-mail.
Storing an e-mail An e-mail is transferred from the ‘stored’
1) monitored user to the e-mail
server.
TR TKÜV, edition 7.2 (draft) Part A, Appendix F, page 63
Transmission of The e-mail server transmits a ‘sent’ In e-mails originating from the
an e-mail stored e-mail. monitored e-mail address, the event
data field <partner identifier> should
Forwarding of an E-mails which are received and ‘sent’ contain the values of all address fields
e-mail subsequently forwarded. apart from the LuS (ENVELOPE: RCPT
TO as per RFC 2822).
Table F.2-1-1 Events for ‘SMTP’
1) The event ‘storing an e-mail’ is also available for stored or modified drafts of an e-mail, irrespective of the protocol
used, even if such drafts are e.g. initially stored without an e-mail address or subject line.
Permissible methods of authentication:
Upon connection, the SMTP server normally performs explicit authentication by means of SMTP-
AUTH.
The subscriber first logs into his/her mailbox via the POP server, authenticating himself/herself by
means of his/her access details (user name and password). He/she is then given a limited time
window to send e-mails via SMTP. (“SMTP after POP”). The requirement for authentication as
per Appendix F.1.2 is only fulfilled for appropriately small time windows.
The subscriber is assigned an IP address which serves as the authentication criterion.
If an e-mail provider is also an access provider, it is permitted to use the authentication performed
at network login for the e-mail service as well.
Authentication is not relevant for the “received” event, as incoming e-mails should always be forwarded in
monitored telecommunications.
Post Office Protocol Version 3 (POP3)
Event Remarks Value of the Notes regarding the value of the
XML parameter XML parameter <partner identifier>
<direction>
Retrieval of an e- The monitored user retrieves a ‘retrieved’ In e-mails intended for the monitored e-
mail complete or partial e-mail from mail address, the event data field
his mailbox (e.g. only the <partner identifier> should contain only
header, subject or attachment). the sender, not the other recipients. The
value to be inserted is found in the
MAIL-BODY.
Table F.2-1-2 Events for ‘POP3’
Permissible methods of authentication:
The subscriber first logs into his/her mailbox by logging onto the website1 or onto the
POP3 server, authenticating himself/herself by means of his/her access details (login name and
password), before e-mails may be retrieved.
Internet Message Access Protocol (IMAP)
Event Remarks Value of the Notes regarding the value of the
XML parameter XML parameter <partner identifier>
<direction>
Storing an e-mail A message produced by an e- ‘stored’ For these e-mails, the event data field
2) mail client is stored in an <partner identifier> should contain the
IMAP directory (using the combined values of all address fields,
IMAP command APPEND) and apart from the LuS. The value to be
then synchronised with the inserted is found in the MAIL-BODY.
server.
TR TKÜV, edition 7.2 (draft) Part A, Appendix F, page 64
Retrieval of an e- The monitored user retrieves a ‘retrieved’ In e-mails intended for the monitored e-
mail complete or partial e-mail from mail address, the event data field
his mailbox (e.g. only the <partner identifier> should contain only
header, subject or attachment). the sender, not the other recipients. The
However, in IMAP, only those e- value to be inserted is found in the
mails should be monitored which MAIL-BODY.
are transmitted between client
and server as part of a
synchronisation of folders (as
new e-mail)
Table F.2-1-3 Events for ‘IMAP’
2) The event ‘storing an e-mail’ is also available for stored or modified drafts of an e-mail, irrespective of the protocol
used, even if such drafts are e.g. initially stored without an e-mail address or subject line.
Permissible methods of authentication:
The subscriber first logs into his/her mailbox by logging onto the website1 or the IMAP server,
authenticating himself/herself by means of his/her access details (login name and password),
before e-mails may be retrieved, stored or moved.
1 applies to webmail services based on IMAP or POP3.
Notes on the above tables:
Repeated transmission to the authorised agency of data sets with identical content between
different physical parts of a logical IMAP server is only permitted if this is the result of Fetch or
Append commands for synchronisation of server or client folders.
E-mail received by the SMTP server and then immediately forwarded to an e-mail address
predefined by the user of the mailbox should normally also be monitored. The parameter
<direction> should have the value ‘received’ upon receipt, and ‘sent’ upon subsequent
transmission.
The copy of each e-mail being monitored must be combined relating to the event with the
associated event data corresponding to Table F.2-1 in Appendix F.2.1 in a single XML-encoded
file each time. The complete copy of the e-mail, i.e. address fields, subject, main text and any
attachments, shall be encoded in accordance with Base64. The Base64 encoding requires a line
break to be inserted after every 76 characters.
The XML-encoded file is transmitted to the authorised agency via FTP. With regard to the layout
of the file name, FTP parameters, security using a VPN, and the procedure in case of difficulties
in transmission, see Appendices A1 to A4.
Appendix F.2.1 Parameters for event data
The individual parameters for event data, which are typically combined with the copy of the content into
an XML-encoded file for transmission to the authorised agency, are listed in the following table:
Parameters Definition/explanation
<version identifier> identifier allocated by the operator of the STS, and which designates the relevant
interface version
<data set type> ‘report’ as identifier of a unique event
<reference number> identifier of the surveillance action, pursuant to § 7(2) sentence 1 of the TKÜV, in
ASCII format (1 to 25 positions, character subset 'a'…'z', 'A'…'Z', '-', '_', '.', and '0'…'9').
The permitted character subset corresponds to the implementations as per ETSI or
3GPP.
<allocation number> Matching to the informational content
Here, the Message ID (according to RFC 2822) of the monitored e-mail should be used.
It can be copied from the e-mail header or envelope data.
<identifier of the LuS> attribute of the identifier under surveillance pursuant to § 7(1) sentence 1 point 1 of
the TKÜV (e.g. e-mail address or user id of the mailbox)
<partner identifier>1 identifier pursuant to §7(1) sentence 1 points 2 to 4 of the TKÜV
TR TKÜV, edition 7.2 (draft) Part A, Appendix F, page 65
Parameters Definition/explanation
The value of the parameter depends on the particular protocol (see Table F.2-1-1 to F.2-
1-3).
More than one partner identifier should be included, separated by ‘;’ (ASCII character no
59).
<IP> The IP address of the e-mail client from which e-mail is stored or retrieved or settings are
made, as known to the e-mail server.
<port> The identifier of the transfer protocol used (e.g. HTTP, SMTP, POP3).
For implementations based on edition 4.1 of the TR TKÜV, port numbers (e.g. 80, 25,
110) may only continue to be used if these details are given corresponding to the
respective well-known ports.
<start> start of monitored telecommunication (e.g. time of receipt of an e-mail message)
according to § 7(1) sentence 1 point 8 of the TKÜV, in the format:
DD/MM/YY hh:mm:ss
The file with event data and/or informational content should not be transmitted
to authorised agencies until after completion of the monitored telecommunications
procedure.
<settings> Contains two details which should be separated by ‘;’ (ASCII character no 59).
1. Details of the following settings:
‘access’ (successful login by the mailbox owner),
‘mailing lists (including changes)’,
‘messaging’ (e.g. settings for the notification service ),
‘forwarding’ (e.g. settings for forwarding of e-mail),
‘e-mail address’ (e.g. creation or deletion of an additional e-mail address in the
monitored mailbox),
2. followed by the settings made (parameters) in the format: free ASCII-encoded text.
<direction> Details of the event being reported pursuant to Tables F.2-1-1 to F.2-1-4:
‘received’, ‘retrieved’, ‘sent’, ‘stored’, ‘delivered’.
If several events are stored or sent almost simultaneously, for example, two values may
be inserted, separated by ‘;’ (ASCII character no 59).
<cause of termination Indication of the reason why the monitored connection was closed, e.g.
at monitored line> ‘successful’ or
error message from the system as a text string, e.g. interruption of a download.
The text string may contain only the ASCII characters of the Base64 encoding.
<start of surveillance Once for each action, with the time of activation of the action (not of administration in
action> case of time-controlled actions) in the STS pursuant to § 5(5) of the TKÜV, in the format:
DD/MM/YY hh:mm:ss
<end of surveillance Once for each action, with the time of deactivation of the action (not of administration in
action> case of time-controlled actions) in the STS pursuant to § 5(5) of the TKÜV, in the format:
DD/MM/YY hh:mm:ss
Table F.2.1: Parameters for event data in the XML file
1 In connection with evaluation, the receiving authorised agency must take account of the fact that amended Other
party identifications cannot in principle be recognised (e.g. ‘
[email protected]’ instead of the actual e-mail
address).
Appendix F.2.2 XML structure and DTD
The XML-encoded file should be created in UTF-8 format.
The following example of an XML structure has values included for all tags. These tags should, however,
only be transmitted if the relevant event requires them. If there are no parameters for the relevant event
data, an empty tag should be used in accordance with XML syntax, e.g. “<start-UEM/>”. Comment lines
are not required and may be omitted.
XML structure:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE hi3-email SYSTEM "hi3-email_v1.dtd">
TR TKÜV, edition 7.2 (draft) Part A, Appendix F, page 66
<?xml-stylesheet href="E-Mail_v1.xsl" type="text/xsl"?>
<hi3-email>
<version identifier>ABC1234</version identifier>
<data set type>report</data set type>
<reference number><![CDATA[123456789 in Base64 encoding 1]]></reference number>
<sequence number><![CDATA[0474745765656 in Base64-encoding 1]]></sequence number>
<identifier-of the-monitored-line><![CDATA[
[email protected] in Base64 encoding 1]]></identifier-of
the-monitored-line>
<IP>111.222.63.254</IP>
<port>SMTP</port>
<partner identifier><![CDATA[
[email protected];
[email protected] in Base64 encoding 1]]></partner
identifier>
<start>31/12/06 10:10:05</start>
<settings><![CDATA[forwarding; free text in Base64 encoding 1]]></settings>
<direction><![CDATA[retrieved in Base64 encoding 1]]></direction>
<cause-of-termination-at-monitored-line><![CDATA[successful in Base64 encoding 1]]></cause-of-termination-at-
monitored-line>
<start-of-surveillance-action>01/12/06 01:00:00</start-of-surveillance-action>
<end-of-surveillance-action>01/02/07 01:00:00</end-of-surveillance-action>
<e-mail>
<!-- start e-mail-->
<![CDATA[ the copy of the monitored e-mail in Base64 encoding 1]]>
<!-- end e-mail-->
</e-mail>
</hi3-email>
Doctype definition:
<!ELEMENT hi3-email (version identifier,data set type,reference number,sequence number,identifier-of the-
monitored-line,IP,port,partner identifier,start,settings,direction,cause-of-termination-at-monitored-line,start-of-
surveillance-action,end-of-surveillance-action,e-mail)>
<!ELEMENT version identifier (#PCDATA)>
<!ELEMENT data set type (#PCDATA)>
<!ELEMENT reference number (#PCDATA)>
<!ELEMENT sequence number (#PCDATA)>
<!ELEMENT identifier-of the-monitored-line (#PCDATA)>
<!ELEMENT IP (#PCDATA)>
<!ELEMENT port (#PCDATA)>
<!ELEMENT partner identifier (#PCDATA)>
<!ELEMENT start (#PCDATA)>
<!ELEMENT settings (#PCDATA)>
<!ELEMENT direction (#PCDATA)>
<!ELEMENT identifier-of the-monitored-line (#PCDATA)>
<!ELEMENT start-of-surveillance-action (#PCDATA)>
<!ELEMENT end-of-surveillance-action (#PCDATA)>
<!ELEMENT e-mail (#PCDATA)>
1
The values of the individual tags or the copy of the monitored e-mail message should be included in Base64
encoding as per RFC 822 or RFC 2045. Please note that the Base64 encoding requires a line break to be inserted
every 76 characters.
TR TKÜV, edition 7.2 (draft) Part A, Appendix F, page 67
Appendix F.3 E-mail transmission point according to ETSI TS 102 232-02 (from
Version 2.1.1)
As an alternative to the nationally specified transmission point pursuant to Appendix F.2, it is also
permitted to design the transmission point according to ETSI TS 102 232-02 [30].
The principles as per Appendix F.1 apply in this regard.
When a full copy of a given e-mail has already been transmitted to the authorised agency, it suffices to
send only the event data in the case of further e-mail events as described in Section 6, ETSI TS 102 232-
02 (e.g. subsequent retrieval of the e-mail). To enable correct grouping of the different transmissions at
the authorised agency in these cases, a unique identifier should be assigned.
In addition to the events defined in TS 102 232-02, changes in settings for the e-mail address or mailbox
should be notified where they occur within the effective period of the surveillance order. The relevant
values should be entered in the ASN.1 field National EM ASN1 parameters of the ASN.1 module as
defined in TS 102 232-02. Appendix A.3 defines the associated national ASN.1 module (see requirement
to report settings as per Appendix F.3.1.2).
Depending on the event recorded, the ASN.1 parameter 'E-Mail Recipient List' should be assigned the
relevant value (see requirement as described in Appendix F.3.1.2).
Appendix F.3.1 Selection of options and stipulation of additional technical
requirements
Appendix F.3.1.1 Basis: ETSI TS 102 232-01
The following table describes the selection of options for the different chapters and sections of ETSI
Specification TS 102 232-01 and also specifies additional requirements.
Unless otherwise indicated, the references in the table relate to the respective sections of the
ETSI specification:
Section TS Description of the option or problem and Additional requirement, background and
102 232-01 specifications regarding national supplemental information
application
5.2.1 Version
The use of an OID in the ASN.1 description
obviates the need for a separate parameter.
5.2.3 Authorisation country code
In Germany, use ‘DE’.
5.2.4 Communication identifier
In Germany, the delivery country code ‘DE’ The communication identity number identifies IRI
should be used. The operator identifier is and CC of a communication process: this
assigned by the Federal Network Agency corresponds to the allocation number pursuant to
pursuant to Appendix A.1 and always begins § 7(2) sentence 2 of the TKÜV.
with ‘49...’.
The network element identifier is assigned by
the network operator. It identifies the network
element on which the telecommunication is
recorded.
5.2.5 Sequence number
The allocation number should already be If this condition cannot be met - in exceptional
created when the surveillance copy is produced cases - it should be ensured that this function is
for the first time (interception point). created in the Delivery Function at the latest.
However, if the sequence number is not created
until then, it should reflect the exact counting
method at the place of origin.
If UDP is used on this segment, additional
measures should be taken to prevent potential
package losses and secure the sequence order.
5.2.6 Payload timestamp
TR TKÜV, edition 7.2 (draft) Part A, Appendix F, page 68
Section TS Description of the option or problem and Additional requirement, background and
102 232-01 specifications regarding national supplemental information
application
All times (TimeStamp) should normally be given From TR TKÜV edition 7.0 and later, only the
based on the official time (local time) as: Micro-SecondTimeStamp now should be used.
MicroSecondTimeStamp (with maximum If the time stamp is not available at the interception
resolution and accuracy). point in the format of the MicroSecondTimeStamp,
The MicroSecondTimeStamp must be created the time stamp must be generated in this format as
where the surveillance copy is produced for the closely as possible to the recording point of the
first time (interception point). surveillance copy.
5.2.11 Interception point identifier
The interception point identifier is assigned by
the network operator. It identifies the logical
point (inside a network element) at which the
data (IRI and/or CC) is recorded in the network.
6.2.2 Error Reporting
Transmission is essentially subject to
Appendix A.4 of the TR TKÜV.
6.2.3 Aggregation of payloads
Combined transmission of monitored However, it should not span more than a few
IP packets is basically introduced to avoid an seconds and should be agreed with the Federal
unnecessary overhead. Network Agency.
6.2.5 Padding Data
May optionally be implemented by the subject. Action-specific use of padding must be agreed with
the relevant authorised agency.
6.3.1 General
TCP/IP is used.
6.3.2 Opening and closing of connections
Normally based on Section 3.1 of the
TR TKÜV, under which the Delivery Function
should trigger to avoid unnecessarily keeping
the lines of the authorised agency busy.
6.3.4 Keep-alives
May optionally be implemented by the subject. After the successful transmission of data, the
TCP connection should normally be closed by
means of a timer. Action-specific use of Padding
Keep-alives, where the TCP connection is kept
alive indefinitely, must be agreed by the
relevant authorised agency.
6.4.2 TCP settings
For forwarding, port number 50100 is chosen The port number applies to applications of the
on the part of the authorised agency service specifications TS 102 232-02, TS 102 232-
(destination port). 03, TS 102 232-04, TS 101 909-20-2, TS 102 232-
05 and TS 102 232-06.
7.1 Type of Networks
Forwarding occurs over the public Internet.
7.2 Security requirements
The requirements as per Appendix A.2 of the TLS and signatures and hash codes may not be
TR TKÜV apply. used.
7.3.2 Timeliness
Any use of separate managed networks should
be agreed between the subject and
the authorised agencies.
TR TKÜV, edition 7.2 (draft) Part A, Appendix F, page 69
Appendix F.3.1.2 Basis: ETSI TS 102 232-02
The following table describes, on the one hand, the selection of options for the different chapters and
sections of ETSI Specification TS 102 232-02 and, on the other, specifies the respective additional
requirements.
Unless otherwise indicated, the references in the table relate to the respective sections of the
ETSI specification:
Section TS Description of the option or problem and Additional requirement, background and
102 232-02 specifications regarding national supplemental information
application
6.2.3, 6.3.3, IRI information
6.4.3 The IRI informations for the events ‘e-mail See also the point 'e-mail format'
send’, ‘e-mail receive’ and ‘e-mail download’, as
described in Tables 1, 2 and 3, should always
be transmitted.
7 E-mail attributes
The e-mail attributes should be sent according 7.3 Email recipient list
to the requirements of the specification. This In e-mails intended for the monitored identifier,
applies, in particular, to the attribute only the sender should be included, not the other
“AAAInformation”. In addition, the following recipients such as CC and/or BCC recipients.
requirements should be complied with.
7.10 AAAInformation
Parameters of POP3 or SMTP authentication, such
as ‘user name’, ‘password’, ‘authMethod’, etc.
should also be reported.
A.4, B.4, HI2 event-record mapping
C.2 In addition to the events described here, the The transmission of settings should use the
settings for the following service attributes national ASN.1 module pursuant to Appendix A.3.2
should be reported: of this TR TKÜV, which should be sent to the
authorised agency by means of the ASN.1 module
- Mailing lists (including changes), of TS 102 232-02.
- Messaging (e.g. settings for a notification
service)
- Forwarding (automatic forwarding of e-mails)
When monitoring a mailbox, also the following:
- E-mail address (e.g. addition or deletion of
an additional e-mail address in the mailbox)
Appendix D E-mail format
When using well-known ports and when For IRI-Only actions, they should nevertheless be
implementing the e-mail format ‘ip-packet’, the included.
parts of the IRI information ‘client address’,
‘server address’, ‘client port’ and ‘server port’
need not be reported as they can be deduced
from the relevant IP or TCP header data.
Appendix F.3.2 Explanations of the ASN.1 descriptions
On its website, the Federal Network Agency publishes information, pursuant to § 36 sentence 5 of
the TKÜV, on the applicable ETSI and 3GPP Standards and Specification, including the associated
ASN.1 modules. Use of the different versions of the national ASN.1-module is also regulated.
Appendix X.4 contains further explanations in this regard.
The ASN.1 descriptions of the different modules for implementations according to this Appendix F.3
should be taken from the various versions of ETSI Specifications TS 102 232-01 and TS 102 232-02,
taking care to correct any errors in the ASN.1-modules contained in them (e.g. incorrect domainID).
Because FTP is used as the transfer protocol, ROSE operations are not relevant.
Whenever the above information is updated on the website of the Federal Network Agency, the updated
versions of the ASN.1-modules may be used. Potentially, without a corresponding update on the part of
the authorised agency, not all parameters may be able to be interpreted.
Parameters designated as ‘conditional’ or ‘optional’ in the specifications should normally be transmitted if
they are available and the relevant specifications, or Appendix F.3 where applicable, does not contain any
contrary provisions.
TR TKÜV, edition 7.2 (draft) Part A, Appendix F, page 70
For the associated ASN.1 types of the “OCTET STRING” format, the following rules apply:
If the standard has defined a format for the relevant parameters, e.g. ASCII or a cross-reference
to a (signalling) standard, this format should be used.
If no particular format has been prescribed, both hexadecimal values should be inserted in the
relevant bytes, with the higher-order half-byte in bits 5-8 and the lower-order half-byte in bits 1-4.
(Examples: 4F H is entered as 4F H = 0100 1111 and not as F4 H. Or, for example,
DDMMYYhhmm = 23.07.2002 10:35 h is entered as ‘2307021035’ H and not ‘3270200153’ H)
Transmission of administrative events (e.g. activation/deactivation/modification of actions as well as fault
reports) and additional events (e.g. with regard to manufacturer-specific services) takes place according
to Appendix A.3.
TR TKÜV, edition 7.2 (draft) Part A, Appendix G, page 71
Appendix G Stipulations regarding the Internet
gateway (ETSI TS 102 232-03, 102 232-
04 and TS 101 909-20-2)
This Appendix describes the conditions for the transmission point according to
ETSI Specifications TS 102 232-03 [31], TS 102 232-04 [32] and TS 101 909-20-2 [33] for those
transmission channels (e.g. xDSL, CATV, WLAN) which are intended for direct subscriber access to the
Internet.
Each of these ETSI specifications uses the relevant general IP-based transmission point as described in
ETSI Specification TS 102 232-01 [29].
The Appendix addresses the decision made with respect to options contained in the specifications, as
well as additional technical requirements.
If, in addition to the Internet access service, broadcast distribution services or similar services intended
for the general public (e.g. IP television, video on demand) are provided through this Internet gateway by
means of platforms or feed points operated by the operator of the Internet gateway, for which no
measures need to be taken under § 3(2) point 4 of the TKÜV, then the relevant telecommunication
portions should - if possible - be left out of the surveillance copy of the Internet access.
If, on the other hand, personalised distribution services are provided which are not provided to the
general public (e.g. distribution of privately produced content to closed user groups), then such
telecommunication portions are not covered by the exemption under § 3(2) point 4 of the TKÜV and
should therefore be recorded as part of the surveillance action.
Under § 7(1)(9), the public IP addresses of the users involved, as known by the subject’s
telecommunications system, must be reported.
In addition to the requirements under Part A, Sections 3 and 4, the following Appendices shall also apply:
Appendix Contents
Appendix A.2 Participation in a VPN via a cryptosystem.
As the surveillance copy is transmitted over the Internet via TCP/IP, the procedure for
participation in VPN should also be followed.
Appendix A.3 Transmission of HI1 events and additional events
Appendix A.4 Difficulties in transmission of the surveillance copy to the authorised agency’s lines
Reference is also made to the following appendices in Part X of the TR TKÜV:
Appendix X.1 Proposed changes to the TR TKÜV
Appendix X.2 Assignment of an identifier to the authorised agency to ensure uniqueness of reference numbers
Appendix X.3 Provisions for the registration and certification authority TKÜV-CA of the Federal Network
Agency, Department IS16 (Policy)
Appendix X.4 Table of applicable ETSI/3GPP standards and specifications as well as the ASN.1 modules
Appendix X.5 Requirements for administration and logging in the organisational implementation of surveillance
actions
Appendix G.1 Selection of options and stipulation of additional technical
requirements
Appendix G.1.1 Basis: ETSI TS 102 232-01
The following table describes the selection of options for the different chapters and sections of ETSI
Specification TS 102 232-01 and specifies additional requirements.
TR TKÜV, edition 7.2 (draft) Part A, Appendix G, page 72
Unless otherwise indicated, the references in the table relate to the respective sections of the
ETSI specification:
Section TS Description of the option or problem and Additional requirement, background and
102 232-01 stipulations regarding national application supplemental information
5.2.1 Version
The use of an OID in the ASN.1 description
obviates the need for a separate parameter.
5.2.3 Authorization country code
In Germany, use ‘DE’.
5.2.4 Communication identifier
In Germany, the delivery country code ‘DE’ The communication identity number identifies IRI
should be used. and CC of a communication process: this
The operator identifier is assigned by the corresponds to the allocation number pursuant to
Federal Network Agency pursuant to Appendix § 7(2) sentence 2 of the TKÜV.
A.1 and always begins with ‘49...’.
The network element identifier is assigned by
the network operator. It identifies the network
element on which the telecommunication is
recorded.
5.2.5 Sequence number
The allocation number should already be If this condition cannot be met - in exceptional
created when the surveillance copy is produced cases - it should be ensured that this function is
for the first time (interception point). created in the Delivery Function at the latest.
However, if the sequence number is not created
until then, it should reflect the exact counting
method at the place of origin.
If UDP is used on this segment, additional
measures should be taken to prevent potential
package losses and secure the sequence order.
5.2.6 Payload timestamp
All times (TimeStamp) should normally be given From TR TKÜV edition 7.0 and later, only the
based on the official time (local time) as: Micro-SecondTimeStamp now should be used.
MicroSecondTimeStamp (with maximum If the time stamp is not available at the interception
resolution and accuracy). point in the format of the MicroSecondTimeStamp,
the time stamp must be generated in this format as
The MicroSecondTimeStamp must be created closely as possible to the recording point of the
where the surveillance copy is produced for the surveillance copy.
first time (interception point).
5.2.7 Payload direction
The unambiguous designation of the path taken
by content data shall be tracked with to target
and from target.
5.2.11 Interception point identifier
The interception point identifier is assigned by
the network operator. It identifies the logical
point (inside a network element) at which the
data (IRI and/or CC) is recorded in the network.
6.2.2 Error Reporting
Transmission is essentially subject to
Appendix A.4 of the TR TKÜV.
6.2.3 Aggregation of payloads
Combined transmission of monitored However, it should not span more than a few
IP packets is basically introduced to avoid seconds and should be agreed with the Federal
unnecessary overheads. Network Agency.
6.2.5 Padding Data
May optionally be implemented by the subject. Action-specific use of padding must be agreed with
the relevant authorised agency.
TR TKÜV, edition 7.2 (draft) Part A, Appendix G, page 73
Section TS Description of the option or problem and Additional requirement, background and
102 232-01 stipulations regarding national application supplemental information
6.3.1 General
TCP/IP is used.
6.3.2 Opening and closing of connections
Based on Section 3.1 of the TR TKÜV, under
which the Delivery Function should trigger to
avoid unnecessarily keeping the lines of
the authorised agency busy.
6.3.4 Keep-alives
The basic requirements set out in Part A, After the successful transmission of data, the
Section 3.3, are to be observed for the TCP connection should normally be closed by
obligatory use of keep-alives. means of a timer. Action-specific use of keep-
alives, where the TCP connection is kept alive
indefinitely, is subject to approval by the
relevant authorised agency.
6.4.2 TCP settings
For forwarding, port number 50100 is chosen The port number applies to applications of the
on the part of the authorised agency service specifications TS 102 232-02, TS 102 232-
(destination port). 03, TS 102 232-04, TS 101 909-20-2, TS 102 232-
05 and TS 102 232-06..
7.1 Type of Networks
Forwarding occurs over the public Internet.
7.2 Security requirements
The provisions under Appendix A.2 of the TLS and signatures and hash codes may not be
TR TKÜV apply. used.
7.3.2 Timeliness
Any use of separate managed networks should
be agreed between the subject and
the authorised agencies.
Appendix G.1.2 Basis: ETSI TS 102 232-03
The following table describes the selection of options for the different chapters and sections of ETSI
Specification TS 102 232-03 and specifies additional requirements.
Unless otherwise indicated, the references in the table relate to the respective sections of the
ETSI specification:
Section TS Description of the option or problem and Additional requirement, background and
102 232-03 stipulations regarding national application supplemental information
4.3.1 Target Identity
The requirements under Part A, Section 4 For instance, implementations of surveillance
TR TKÜV apply. Any deviating technical based on a cable modem identifier are possible,
implementation should behave accordingly. but should take into account that another cable
modem could be connected to the monitored
Internet gateway, or the “monitored” cable modem
could be connected to another Internet gateway.
4.3.2 Result of interception
All times (TimeStamp) should normally be given The GeneralizedTime parameter shall be encoded
based on the official time (local time). as universal time and without time difference.
6.1 Events
The events and HI2 attributes from Version 1.4.1 supplemented the event
Version 1.4.1 of the ETSI Specification should ‘startOfInterceptionWithSessionActive’.
be used.
8 ASN.1 for IRI and CC
For these cases, defined in § 7(3) of the TKÜV, For these cases, only the ASN.1 data of the
the ASN.1 description for ‘IRIOnly’ need not be ‘IPIRIContents’ need be transmitted in addition to
implemented. the administrative data (e.g. LIID). This complies
TR TKÜV, edition 7.2 (draft) Part A, Appendix G, page 74
Section TS Description of the option or problem and Additional requirement, background and
102 232-03 stipulations regarding national application supplemental information
with the requirement that in this type of
surveillance order, only the CC part need not be
transmitted.
Appendix G.1.3 Basis: ETSI TS 102 232-04
The following table describes the selection of options for the different chapters and sections of ETSI
Specification TS 102 232-04 and specifies additional requirements.
Unless otherwise indicated, the references in the table relate to the respective sections of the
ETSI specification:
Section TS Description of the option or problem and Additional requirement, background and
102 232-04 stipulations regarding national application supplemental information
4.2.1 Target Identity
The requirements under Part A, Section 4 For instance, implementations of surveillance
TR TKÜV apply. Any deviating technical based on the MAC address of a modem are
implementation should behave accordingly. possible, but should take into account that another
modem could be connected to the monitored
Internet gateway, or the “monitored” modem could
be connected to another Internet gateway.
4.3.2 Result of interception
All times (TimeStamp) should normally be given The GeneralizedTime parameter shall be encoded
based on the official time (local time). as universal time and without time difference.
6.1 Events
The events and HI2 attributes of Version 1.3.1 In Version 1.3.1, the event ‘End of Interception
of the ETSI Specification should be used. Session_Active’ was deleted.
8.2 ASN.1 specification
For the cases described in § 7(3) TKÜV, the In these cases, opening and closing a
ASN.1 description for ‘IRIOnly’ may be Layer2 tunnel is the only known option.
implemented instead of the description of the
ASN.1 data ‘L2IRIContents’.
Appendix G.1.4 Basis ETSI TS 101 909-20-2
The following table describes, on the one hand, the selection of options for the different chapters and
sections of ETSI Specification TS 101 909-20-2 and, on the other, specifies the respective additional
requirements.
Unless otherwise indicated, the references in the table relate to the respective sections of the
ETSI specification:
Section of Description of the option or problem and Additional requirement, background and
TS 101 909- stipulations regarding national application supplemental information
20-2
4.2 Architecture
An implementation based on EuroDOCSIS is Depending on the design of the STS, particularly of
assumed. the service scope, the Federal Network Agency
may prescribe the use of a particular version of the
standard.
5 LI architecture for IP multimedia Time
Critical Services
The specification refers to the remarks in The exact details of the surveillance device,
ES/TS 101 671. particularly the events and their associated
parameters, should be agreed with the Federal
Network Agency.
Appendix A ASN.1 modules
The module used, ‘TS101909202’, has syntax A corrected version is available at
errors. http://www.bundesnetzagentur.de/tku.
TR TKÜV, edition 7.2 (draft) Part A, Appendix G, page 75
Section of Description of the option or problem and Additional requirement, background and
TS 101 909- stipulations regarding national application supplemental information
20-2
Addendum 1 Target Identity
The provisions of Part A, Section 4 TR TKÜV Implementations of surveillance based on the
apply. MAC address of a modem are possible in principle,
but should take into account that another modem
could be connected to the monitored Internet
gateway, or the ‘monitored’ modem could be
connected to another Internet gateway.
Addendum 2 Timestamps
All times (TimeStamp) should normally be The GeneralizedTime parameter shall be encoded
given based on the official time (local time). as universal time and without time difference.
Appendix G.2 Explanations of the ASN.1 descriptions
On its website, the Federal Network Agency publishes information, pursuant to § 36 sentence 5 of
the TKÜV, on the applicable ETSI and 3GPP standards and specification, including the associated
ASN.1 modules. Use of the different versions of the national ASN.1-module is also regulated.
Appendix X.4 contains further explanations in this regard.
The ASN.1 descriptions of the different modules for implementations according to this Appendix G should
be taken from the various versions of ETSI Specifications TS 102 232-01, TS 102 232-03, TS 102 232-04
and TS 101 909-20-2, taking care to correct any errors in the ASN.1-modules contained in them (e.g.
incorrect domainID). Because FTP is used as the transfer protocol, ROSE operations are not relevant.
Whenever the above information is updated on the website of the Federal Network Agency, the updated
versions of the ASN.1-modules may be used. Potentially, without a corresponding update on the part of
the authorised agency, not all parameters may be able to be interpreted.
Parameters referred to as ‘conditional’ or ‘optional’ in the specifications should normally be transmitted if
they are available and unless stipulated otherwise in the relevant specifications or Appendix G.1.
For the associated ASN.1 types of the ‘OCTET STRING’ format, the following rules apply:
If the standard has defined a format for the relevant parameters, e.g. ASCII or a cross-reference
to a (signalling) standard, this format should be used.
If no particular format has been prescribed, both hexadecimal values should be inserted in the
relevant bytes, with the higher-order half-byte in bits 5-8 and the lower-order half-byte in bits 1-4.
(Examples: 4F H is entered as 4F H = 0100 1111 and not as F4 H. Or, for example,
DDMMYYhhmm = 23.07.2002 10:35 h is entered as ‘2307021035’ H and not ‘3270200153’ H)
Transmission of administrative events (e.g. activation/deactivation/modification of actions as well as fault
reports) and additional events (e.g. with regard to manufacturer-specific services) takes place according
to Appendix A.3.
TR TKÜV, edition 7.2 (draft) Part A, Appendix H, page 76
Appendix H Specifications regarding VoIP, other
multimedia services in landline
networks and landline-based IMS
platforms (ETSI TS 102 232-05,
102 232-06 and 101 909-20-1)
This Appendix describes the conditions for the transmission point according to the
ETSI Specifications TS 102 232-05 [34] for IP multimedia services and TS 101 909-20-1 for the
IP Cablecom architecture, and according to ETSI Specification TS 102 232-06 [35] for emulated
PSTN/ISDN services. This ETSI specification uses the general IP-based transmission point as described
in ETSI Specification TS 102 232-01 [29]. Where use of an IMS platform is shared, or when identical IMS
platforms are used for mobile and landline telecommunications, the use of an interface in accordance with
Appendix D must be agreed upon with the Federal Network Agency.
So far, it has also been permissible for VoIP services to set up the surveillance technology based on the
circuit-switched technology described in Appendix C. In future, it will no longer be possible to use this
interface for new implementations, including additional multimedia services. The time limits set out in
Appendix C must be observed for existing implementations.
Offers of VoIP or other multimedia services in GPRS and UMTS networks are essentially not affected by
this Appendix as Appendix D already describes the relevant transmission points.
The Appendix addresses the decision made with respect to options contained in the specifications, as
well as additional technical requirements.
In addition to the requirements under Part A, Sections 3 and 4, the following Appendices shall also apply:
Appendix Contents
Appendix A.2 Participation in a VPN via a cryptosystem.
As the surveillance copy is transmitted over the Internet via TCP/IP, the procedure for
participation in VPN should also be followed.
Appendix A.3 Transmission of HI1 events and additional events
Appendix A.4 Difficulties in transmission of the surveillance copy to the authorised agency’s lines
Reference is also made to the following appendices in Part X of the TR TKÜV:
Appendix X.1 Proposed changes to the TR TKÜV
Appendix X.2 Assignment of an identifier to the authorised agency to ensure uniqueness of reference numbers
Appendix X.3 Provisions for the registration and certification authority TKÜV-CA of the Federal Network
Agency, Department IS16 (Policy)
Appendix X.4 Table of applicable ETSI/3GPP standards and specifications as well as the ASN.1 modules
Appendix X.5 Requirements for administration and logging in the organisational implementation of surveillance
actions
Appendix H.1 Fundamental requirements for use of ‘Service-specific details for
IP multimedia services´ (TS 102 232-05 and TS 101 909-20-1)
The ETSI Specification TS 102 232-05 describes a transmission point for VoIP and other multimedia
services which are based on the Session Initiation Protocol (SIP), the ITU-T Standards H.323 and H.248
and the Realtime Transport Protocol (RTP).
TR TKÜV, edition 7.2 (draft) Part A, Appendix H, page 77
The ETSI Specification TS 101 909-20-1 may be used in networks designed according to the
IP Cablecom architecture.
Annex H.1.1 Definitions
Multimedia server Telecommunication systems based on SIP, H.323 or H.248, in conjunction
(VoIP server) and with the media stream (e.g. RTP), which participate in the provision of the
participating network VoIP service or another multimedia service.
elements
VoIP identifier The VoIP identifier designates the telecommunication under surveillance.
This term is used as a general designation for the various types of possible
identifiers.
VoIP account An account set up for the user in order to manage a number of
VoIP identifiers collectively. A monitored VOIP account may sometimes
contain several VoIP identifiers.
Login Procedure by which the access rights of a given subscriber or other end-
user for his/her VoIP account are verified.
Login name The login name used at login as part of the access identifier is also an
identifier used to denote the telecommunication under surveillance.
Appendix H.1.2 Fundamentals
An order for surveillance of telecommunications may contain, as a technical identifier:
a VoIP identifier, or
the access identifier (login name without password) of a VoIP account.
To implement surveillance of the entire telecommunication which takes place under the given
VoIP identifier, care should be taken that the monitored telecommunication is actually associated with the
LuS by using suitable authentication methods. This should prevent situations where, for example, a
VoIP communication which should be monitored fails to be recorded because the sender address was
manipulated by the user.
If this requirement cannot be fulfilled (e.g. due to an unsuitable authentication method), a VoIP identifier-
based surveillance order for the entire VoIP account should be implemented, which should include the
telecommunication of all VoIP identifiers pertaining to this account.
If there is already a telecommunications link under surveillance when a surveillance action is activated,
then both the content and the event data should be recorded from this time onwards and a copy delivered
(see Appendix H.3.2, point 5.3). Data pursuant to § 7(1) TKÜV that exists on the net when the
surveillance action is activated and is no longer forwarded as future event data (e.g. codecs of the
existing telecommunication) must also be reported. Since there is currently no standard dictating the
technical implementation in detail, the compulsory implementation of this requirement is deferred for the
time being, as long as signalling information and informational content are present in various network
elements, and provided that no information for operational purposes regarding the points at which the
voice data (e.g. IP address, port address) can be forwarded and correlated is provided.
Under § 7(1)(9) and (10), the public IP addresses of involved users known by the subject’s
telecommunications system and the known encoding used when transmitting the telecommunication
under surveillance must be reported.
Appendix H.1.3 Completeness of event data
When using the two ETSI specifications, it is assumed that the signalling information used for the service
is sufficient to describe the monitored events. Where this cannot be achieved, the event data should be
transmitted via the HI2Operations module as described in Appendix C, which contains more parameters
in addition to the transmission of a copy of the SIP signalling, which can be used to supplement the
missing information. Such information may, for example, be available in network elements (e.g.
SIP proxy, conference server, web interface for user settings).
When setting up the surveillance technology, it should be kept in mind that pursuant to § 5(1) of
the TKÜV, every signalling message associated with the monitored identifier should be included. To
prevent multiple registration of signalling messages without producing new information with regard to the
event data as described in § 7 of the TKÜV (e.g. identifiers, services used), the number of surveillance
TR TKÜV, edition 7.2 (draft) Part A, Appendix H, page 78
points used should be kept to the minimum required. This should prevent, for example, repeated
registration of an INVITE message at different hops within the network, which merely add the details of
the various hops. However, it is not required to include logic for filtering and, where needed, suppression
of the messages recorded at the relevant surveillance points before delivering them to the transmission
point.
Appendix H.1.4 Delivery of informational content in case of separate transmission
of signalling
The event data and informational content produced on the basis of the signalling messages should
normally be delivered to the transmission point. According to ETSI Specification TS 102 232-05, the
informational content consists of the totality of RTP and RTCP packets as well as any other protocols
conveying the media stream (e.g. gateway protocols). In some cases, however, the content is transmitted
separately from the signalling by other operators, particularly in the case of VoIP. The following options
are available for providing informational content:
1. The VoIP provider himself/herself operates network elements through which the content is
transmitted. These network elements may include the following:
a) the Internet gateway, regardless of whether it is based on a dedicated or leased subscriber line
(but not including entire resale products such as Resale DSL from DTAG),
b) the hub which contains the connection point to the Internet,
c) the transport or connection network for the content, or
d) the transmission point to and from the PSTN (e.g. Media Gateway).
This Appendix H prescribes the more detailed requirements for this.
2. The provider of VoIP uses a particular operator of network elements as described in 1. for
transmitting the content. In addition to rules in Appendix H, there is also a possibility of
implementation pursuant to § 110(1) sentence 1 point 1a of the TKG. However, the task of
arranging the corresponding interaction is reserved for the obligated supplier of the VoIP.
Where the content and event data are delivered separately, it should be ensured - pursuant to § 7(2) of
the TKÜV - that these parts contain a uniform reference number and allocation numbers.
Where the surveillance of the informational content is done using special routing, e.g. to a central hub, it
should particularly be ensured that VoIP users cannot detect this, as described in § 5(4) of the TKÜV.
Appendix H.2 Fundamental requirements for use of ‘Service-specific details for
PSTN/ISDN services’ (ETSI TS 102 232-06)
ETSI Specification TS 102 232-06 creates a possibility for emulated PSTN and ISDN services to use a
purely IP-based transmission point. In this option, the copy of the telecommunication is transmitted as an
RTP data stream over the general IP-based transmission point according to TS 102 232-01. In addition,
the event data, which are encoded in the HI2Operatons module according to Appendix C, are also
transmitted using TS 102 232-01; here, FTP transmission as described in Appendix C should not be
used.
Appendix H.3 Selection of options and stipulation of additional technical
requirements
Appendix H.3.1 Basis: ETSI TS 102 232-01
The following table describes the selection of options for the different chapters and sections of ETSI
Specification TS 102 232-01 and also specifies additional requirements.
Unless otherwise indicated, the references in the table relate to the respective sections of the
ETSI specification:
Section TS Description of the option or problem and Additional requirement, background and
102 232-01 stipulations regarding national application supplemental information
5.2.1 Version
The use of an OID in the ASN.1 description
obviates the need for a separate parameter.
TR TKÜV, edition 7.2 (draft) Part A, Appendix H, page 79
Section TS Description of the option or problem and Additional requirement, background and
102 232-01 stipulations regarding national application supplemental information
5.2.3 Authorisation country code
In Germany, use ‘DE’.
5.2.4 Communication identifier
In Germany, the delivery country code ‘DE’ The communication identity number identifies IRI
should be used. and CC of a communication process: this
corresponds to the allocation number pursuant to
The operator identifier is assigned by the § 7(2) sentence 2 of the TKÜV.
Federal Network Agency pursuant to Appendix
A.1 and always begins with ‘49...’.
The network element identifier is assigned by
the network operator. It identifies the network
element on which the telecommunication is
recorded.
5.2.5 Sequence number
The allocation number should already be If this condition cannot be met - in exceptional
created when the surveillance copy is produced cases - it should be ensured that this function is
for the first time (interception point). created in the Delivery Function at the latest.
However, if the sequence number is not created
until then, it should reflect the exact counting
method at the place of origin.
If UDP is used on this segment, additional
measures should be taken to prevent potential
package losses and secure the sequence order.
5.2.6 Payload timestamp From TR TKÜV edition 7.0, only the Micro-
SecondTimeStamp now should be used.
All times (TimeStamp) should normally be given
based on the official time (local time) as: If the time stamp is not available at the interception
MicroSecondTimeStamp (with maximum point in the format of the MicroSecondTimeStamp,
resolution and accuracy). the time stamp must be generated in this format as
closely as possible to the recording point of the
The MicroSecondTimeStamp must be created surveillance copy.
where the surveillance copy is produced for the
first time (interception point).
5.2.7 Payload direction
The unambiguous designation of the path taken
by content data shall be tracked with to target
and from target.
Encoding information
As a rule, there are various optional encodings In practice, the codec used (if known to the
for the audio data available to the terminal. The network) must be reported as event datum with
codec actually used for transferring the audio simple forwarding of the IRI data. If the IRI data is
data and known to the network has to be recorded at different points in the network and if
transmitted as event datum pursuant to § 7(1) different codecs happen to be forwarded (e.g.
of the TKÜV. change of codec in the network), the Interception
(The reference to the existing legal situation Point Identifier should help to bring together the
was included in the TR TKÜV owing to the use relevant IRI data set and the forwarded
of different codecs in part unknown to the informational content (audio data) (see 5.2.11).
analysis system.)
5.2.11 Interception point identifier
The interception point identifier is assigned by The Interception Point Identifier serves to help
the network operator. It identifies the logical improve the labelling of the coherent IRI data in the
point (inside a network element) at which the event of multiple forwarding of IRI data (e.g. via
data (IRI and/or CC) is recorded in the network. different recording points) and, if possible, to
merge the codec described via the IRI data set
with the forwarded informational content (audio
data) If more than one codec is reported in the IRI
data, this requirement should be implemented as
follows:
If the audio data codec is changed within the
network, the CC data for forwarding should be
provided with the same Interception Point Identifier
TR TKÜV, edition 7.2 (draft) Part A, Appendix H, page 80
Section TS Description of the option or problem and Additional requirement, background and
102 232-01 stipulations regarding national application supplemental information
as the associated IRI data set containing the
correct codec.
Should the above-described correction not be
possible, then alternative methods should be
agreed with the Federal Network Agency.
6.2.2 Error Reporting
Transmission is essentially subject to
Appendix A.4 of the TR TKÜV.
6.2.3 Aggregation of payloads
Combined transmission of monitored However, it should not span more than a few
IP packets is basically introduced to avoid an seconds and should be agreed with the Federal
unnecessary overhead. Network Agency.
6.2.5 Padding Data
May optionally be implemented by the subject. Action-specific use of padding must be agreed with
the relevant authorised agency.
6.3.1 General
TCP/IP is used.
6.3.2 Opening and closing of connections
Normally based on Section 3.1 of the
TR TKÜV, under which the Delivery Function
should trigger to avoid unnecessarily keeping
the lines of the authorised agency busy.
6.3.4 Keep-alives
May optionally be implemented by the subject. After the successful transmission of data, the
TCP connection should normally be closed by
means of a timer. Action-specific use of keep-
alives, where the TCP connection is kept alive
indefinitely, is subject to approval by the
relevant authorised agency.
The basic requirements set out in Part A,
Section 3.3, are to be observed for the
obligatory use of keep-alives.
6.4.2 TCP settings
For forwarding, port number 50100 is chosen The port number applies to applications of the
on the part of the authorised agency service specifications TS 102 232-02, TS 102 232-
(destination port). 03, TS 102 232-04, TS 101 909-20-2, TS 102 232-
05 and TS 102 232-06.
7.1 Type of Networks
Forwarding occurs over the public Internet.
7.2 Security requirements
The requirements as per Appendix A.2 of the TLS and signatures and hash codes may not be
TR TKÜV apply. used.
7.3.2 Timeliness
Any use of separate managed networks should
be agreed between the subject and
the authorised agencies.
TR TKÜV, edition 7.2 (draft) Part A, Appendix H, page 81
Appendix H.3.2 Basis: ETSI TS 102 232-05
The following table describes the selection of options for the different chapters and sections of ETSI
Specification TS 102 232-05 and specifies additional requirements. Unless otherwise indicated, the
references in the table relate to the respective sections of the ETSI specification:
Section TS Description of the option or problem and Additional requirement, background and
102 232-05 stipulations regarding national application supplemental information
4.3 General Requirements
Copies of the signalling messages (e.g. The concept should explain the parameters
SIP Messages) are normally transmitted as denoting the various individual services (e.g. basic
event data. call, call forwarding) or combinations of messages,
with examples. Individual services which can be
controlled by subscribers’ terminals (clients) should
also be explained in terms of any known changes
in their signalling or RTP stream behaviour, e.g.
simultaneous RTP sessions in conferences;
updates should be provided for any subsequent
extensions.
The HI2Operatons module of Appendix C should
Event data which are not part of the signalling be used for the transmission of all event data;
must also be transmitted. however, a separate parameter may be used for
SIP messages; the module itself should be
transmitted according to the requirements of
TS 102 232-06.
No general mapping, such as is defined, for
example, by ANS T1.678, is included.
5.2.2 Provisioning of the H.323 IRI IIF
The exact signalling messages of the various
different protocols in the H.323 family which
should be sent as event data should be agreed
with the Federal Network Agency for individual
cases.
5.3 Assigning a value to the CIN
The CIN is normally assigned at the start of a The first signalling message (e.g. INVITE) shall be
new session with the first signalling message designated as IRI-BEGIN and all subsequent
(CC or IRI). signalling messages (e.g. INVITE from SIP server
for partner identifier) shall be designated as IRI-
If a session already exists at activation of the CONTINUE. The last (expected) signalling
surveillance action, the CIN should be message shall be designated IRI-END.
generated together with the first IRI or
CC message.
If a telecommunications link to the monitored
identifier already exists at the time of activation of
a surveillance action, then both telecommunication
content and event data should be recorded from
this time onwards and a copy delivered.
5.3., 5.3.1 Assigning a CIN value to SIP related IRI
The description assumes that the Call ID and The requirement to generate a unified CIN for the
the ‘O’ field of the SDP are used to generate a individual communication sessions applies
uniform CIN (allocation number) for the call as regardless of whether the described parameters
a whole. can in fact be used.
For processing different media streams within one
session, the stream identifier as described in
Section 5.5 should be used.
5.4 Events and IRI record types
The different call-specific event data are The option to send all event data as REPORT may
reported as IRI-BEGIN, IRI-CONTINUE and not be used.
IRI-END; a later event (after an IRI-END) In certain exceptional cases which are to be
should be reported as IRI-REPORT, as agreed on beforehand with the Federal Network
indicated. Agency, it is permissible to report data from an
existing session partially as REPORT. (This may,
for example, be a call forwarding scenario in which
TR TKÜV, edition 7.2 (draft) Part A, Appendix H, page 82
Section TS Description of the option or problem and Additional requirement, background and
102 232-05 stipulations regarding national application supplemental information
the session is initially reported as
BEGIN/CONTINUE/END and after forwarding as
REPORT.)
Only one event per session may be designated as
IRI-BEGIN and one as IRI-END.
In other words, the first signalling message (e.g.
INVITE) shall be designated as IRI-BEGIN and all
subsequent signalling messages (e.g. INVITE from
SIP server for partner identifier) shall be
designated as IRI-CONTINUE. The last (expected)
signalling message shall be designated IRI-END.
5.5 Interception of Content of Communication
If the subject uses encryption on the network If the subject supports encryption of peer-to-peer-
side or it is involved in generating or communications over the Internet by means of key
exchanging keys, thereby allowing it to decrypt management provided by him/her, without
the telecommunication, the encryption at the involving his/her network elements or those of
transmission point must be lifted (§ 8(3) TKÜV). his/her partners in the transmission of the content,
This applies in cases according to H.1.4 where he/she should at least inform the authorised
the informational content needs to be provided. agency of the key initially exchanged by him/her
with his/her telecommunication system. The
associated procedure should be agreed with the
Federal Network Agency.
Transmission of the exchanged key is not required
if the obligated party can still remove the
encryption by means of additional network
elements.
In case of several media streams within one
session, the stream identifier should be used.
7 ASN.1 specification for IRI and CC
The iPSourceAddress and Reporting internal IP addresses of the network,
iPDestinationAddress parameters shall be used e.g. where the IP addresses of the communicating
to transmit the IP addresses of the partners are available at the network boundaries
communicating partners as known to the but not directly on the VoIP server, does not
subject’s network. comply with the provision.
If information on the location of the terminal as
defined in § 7(1) point 7 of the TKÜV cannot be
reported, then this IP address shall also be
used as location information. This temporary
solution applies until the transmission of the
correct locational information.
Appendix H.3.3 Basis: ETSI TS 101 909-20-1
The following table describes the selection of options for the different chapters and sections of ETSI
Specification TS 101 909-20-1 and also specifies additional requirements. Unless otherwise indicated, the
references in the table relate to the respective sections of the ETSI specification:
Section of Description of the option or problem and Additional requirement, background and
TS 101 909- stipulations regarding national application supplemental information
20-1
Event data which are not part of the signalling The concept should explain the parameters
must also be transmitted. denoting the various individual services (e.g. basic
call, call forwarding) or combinations of messages,
with examples. Individual services which can be
controlled by subscribers’ terminals (clients) should
also be explained in terms of any known changes
in their signalling or RTP stream behaviour, e.g.
simultaneous RTP sessions in conferences;
updates should be provided for any subsequent
extensions.
The HI2Operatons module of Appendix C should
be used for the transmission of all event data; a
separate parameter may be used for signalling
TR TKÜV, edition 7.2 (draft) Part A, Appendix H, page 83
Section of Description of the option or problem and Additional requirement, background and
TS 101 909- stipulations regarding national application supplemental information
20-1
messages; the module itself should be transmitted
according to the requirements of TS 101 232-06.
5 Functional Architecture
An implementation based on EuroDOCSIS is Depending on the design of the STS, particularly of
assumed. the service scope, the Federal Network Agency
may prescribe the use of a particular version of the
standard.
5.2 Functional Components
The specification refers to the remarks in The exact details of the surveillance device,
ES 201 671 and TS 101 671. particularly the events and their associated
parameters, should be agreed with the Federal
Network Agency.
4.4 Interworking Considerations
If the subject uses encryption on the network If the subject supports encryption of peer-to-peer-
side or it is involved in generating or communications over the Internet by means of key
exchanging keys, thereby allowing it to decrypt management provided by him/her, without
the telecommunication, the encryption at the involving his/her network elements or those of
transmission point must be lifted (§ 8(3) TKÜV). his/her partners in the transmission of the content,
This applies in cases according to H.1.4 where he/she should at least inform the authorised
the informational content needs to be provided. agency of the key initially exchanged by him/her
with his/her telecommunication system. The
associated procedure should be agreed with the
Federal Network Agency.
Transmission of the exchanged key is not required
if the obligated party can still remove the
encryption by means of additional network
elements.
Appendix A ASN.1 modules
The modules used, ‘PCESP’ and A corrected version is available at
‘TS101909201’, have syntax errors. http://www.bundesnetzagentur.de/tku.
Addendum 1 ASN.1 specification for IRI and CC
When this interface is used, the IP addresses See in this regard the remarks on Chapter 7 in the
of the communicating partners must be description of the use of this interface pursuant to
reported. TS 102 232-05 in Appendix H.3.2.
Addendum 2 Timestamps
All times (TimeStamp) should normally be The GeneralizedTime parameter shall be encoded
given based on the official time (local time). as universal time and without time difference.
Appendix H.3.4 Basis: ETSI TS 102 232-06
The following table describes the selection of options for the different chapters and sections of ETSI
Specification TS 102 232-06 and also specifies additional requirements.
Unless otherwise indicated, the references in the table relate to the respective sections of the
ETSI specification:
Section TS Description of the option or problem and Additional requirement, background and
102 232-06 stipulations regarding national application supplemental information
5.2 Structures
The event data are encoded using the
HI2Operations module as described in
Appendix C and transmitted directly with
TS 101 232-01 using the ETSI671IRI
parameter.
The copy of the content is transmitted in
the form of RTP packets with UDP and
IP headers as per TS 102 232-06 and
TS 102 232-01, by means of the
PstnIsdnCC parameter.
TR TKÜV, edition 7.2 (draft) Part A, Appendix H, page 84
Section TS Description of the option or problem and Additional requirement, background and
102 232-06 stipulations regarding national application supplemental information
The necessary information for
interpretation of the RTP packets is also
transmitted by means of the
PstnIsdnIRI parameter via TS 102 232-06
with TS 102 232-01.
6.2 CC format
If the subject uses encryption on the network If the subject supports encryption of peer-to-peer-
side or it is involved in generating or communications over the Internet by means of key
exchanging keys, thereby allowing it to decrypt management provided by him/her, without
the telecommunication, the encryption at the involving his/her network elements or those of
transmission point must be lifted (§ 8(3) TKÜV). his/her partners in the transmission of the content,
This applies in cases according to H.1.4 where he/she should at least inform the authorised
the informational content needs to be provided. agency of the key initially exchanged by him/her
with his/her telecommunication system. The
required procedure should be agreed with the
Federal Network Agency.
Transmission of the exchanged key is not required
if the obligated party can still remove the
encryption by means of additional network
elements.
6.2, 6.3.2 Supplementary information
G.711 should be used as the default
(mediaAttributes = ‘1’)
A copy of the entire SDP message should Transmission of the entire SDP message provides
always be sent in the copyOfSDPMessage field the authorised agency with a complete copy of the
(mandatory); the optional individual fields telecommunication; it also prevents any errors
sessionName and sessionInfo are not required which the subject might make when extracting the
(optional). individual parameters.
Addendum 1 ASN.1 specification for IRI and CC
When this interface is used, the IP addresses See in this regard the remarks on Chapter 7 in the
of the communicating partners must be description of the use of this interface pursuant to
reported. TS 102 232-05 in Appendix H.3.2.
Appendix H.4 Explanations of the ASN.1 descriptions
On its website, the Federal Network Agency publishes information, pursuant to § 36 sentence 5 of
the TKÜV, on the applicable ETSI and 3GPP standards and specification, including the associated
ASN.1 modules. Use of the different versions of the national ASN.1-module is also regulated.
Appendix X.4 contains further explanations in this regard.
The ASN.1 descriptions of the different modules for implementations according to this Appendix H should
be taken from the various versions of ETSI Specifications TS 102 232-01, TS 102 232-05, TS 102 232-06
and TS 101 909 20-1, taking care to correct any errors in the ASN.1-modules contained in them (e.g.
incorrect domainID). Because FTP is used as the transfer protocol, ROSE operations are not relevant.
Whenever the above information is updated on the website of the Federal Network Agency, the updated
versions of the ASN.1-modules may be used. Potentially, without a corresponding update on the part of
the authorised agency, not all parameters may be able to be interpreted.
Parameters referred to as ‘conditional’ or ‘optional’ in the specifications should normally be transmitted if
they are available and unless stipulated otherwise in the relevant specifications or Appendix H.2.
For the associated ASN.1 types of the ‘OCTET STRING’ format, the following rules apply:
If the standard has defined a format for the relevant parameters, e.g. ASCII or a cross-reference
to a (signalling) standard, this format should be used.
If no particular format has been prescribed, both hexadecimal values should be inserted in the
relevant bytes, with the higher-order half-byte in bits 5-8 and the lower-order half-byte in bits 1-4.
(Examples: 4F H is entered as 4F H = 0100 1111 and not as F4 H. Or, for example,
DDMMYYhhmm = 23.07.2002 10:35 h is entered as ‘2307021035’ H and not ‘3270200153’ H)
TR TKÜV, edition 7.2 (draft) Part A, Appendix H, page 85
Transmission of administrative events (e.g. activation/deactivation/modification of actions as well as fault
reports) and additional events (e.g. with regard to manufacturer-specific services) takes place according
to Appendix A.3.
TR TKÜV, edition 7.2 (draft) Part A, Appendix I, page 86
Appendix I Provisions for messaging services
(ETSI TS 103 707 and ETSI TS 102 232-
02)
The use of the interface described in this Appendix will become mandatory one year after the entry into
force of the provisions of the TKG in conjunction with the TKÜV, which include an obligation to take
precautions to implement legally required measures for telecommunications surveillance, including for
number-independent interpersonal telecommunications services.
For messaging services which are provided on the basis of proprietary and non-uniform protocols and for
which surveillance technology to be developed individually is also to be used regularly to meet the legal
requirements of another European country, it is specified that the interface described here must be
established no later than two years after the entry into force of the above-mentioned regulation in the
TKG in conjunction with the TKÜV.
The Appendix describes the conditions for the XML/HTTP based transmission point according to ETSI
Specification TS 103 707 [39] and for the ASN.1/TCP based transmission point according to ETSI
Specification TS 102 232-02 [30] for messaging services.
ETSI Specification TS 103 707 [39] uses the IP-based transmission procedure described in ETSI
Specification TS 103 120 [38]. The transmission of the order for the surveillance of telecommunications
and related messages, such as the specific activation of a measure, shall continue to be carried out in
accordance with Part B of this edition and not in accordance with the procedure described in ETSI
Specification TS 103 120.
In addition, it is possible to use the ASN.1/TCP-based transmission point in accordance with the ETSI
Specification TS 102 232-02 [30] in cases where the provisions in this specification and in Appendix F are
sufficient to meet the requirements of the TKÜV. This ETSI specification uses the general IP-based
transmission point as described in ETSI Specification TS 102 232-01 [29].
When using the two methods, it may be necessary to additionally provide the transmission point
according to the ETSI Specification TS 102 232-05 as specified in Appendix H.
If the surveillance technology to be provided is also used to meet another country’s legal requirements, it
is possible to deviate from the requirements of Appendix A.2. Intended deviations must be coordinated
with the Federal Network Agency before the surveillance technology is put into operation.
The use of ETSI Specifications TS 103 707 [39] and TS 103 120 [38] is subject to consultation with the
Federal Network Agency until further notice. The use of the ETSI Specification TS 102 232-02 [30] is
subject to the conditions of Appendix F.3.
In addition to the requirements under Part A, Sections 3 and 4, the following Appendices shall also apply:
Appendix Contents
Appendix A.2 Participation in a VPN via a cryptosystem.
As the surveillance copy is transmitted over the Internet via TCP/IP, the procedure for
participation in VPN should also be followed. Intended deviations in accordance with Appendix I
must be agreed with the Federal Network Agency prior to commissioning.
Appendix A.3 Transmission of HI1 events and additional events
Appendix A.4 Difficulties in transmission of the surveillance copy to the authorised agency’s lines
Reference is also made to the following appendices in Part X of the TR TKÜV:
Appendix X.1 Proposed changes to the TR TKÜV
Appendix X.2 Assignment of an identifier to the authorised agency to ensure uniqueness of reference numbers
Appendix X.3 Provisions for the registration and certification authority TKÜV-CA of the Federal Network
Agency, Department IS16 (Policy)
Appendix X.4 Table of applicable ETSI/3GPP standards and specifications as well as the ASN.1 modules
TR TKÜV, edition 7.2 (draft) Part A, Appendix I, page 87
Appendix X.5 Requirements for administration and logging in the organisational implementation of surveillance
actions
TR TKÜV, edition 7.2 (draft) Part B, page 88
Part B Technical implementation of legal
measures for the disclosure of
information
TR TKÜV, edition 7.2 (draft) Part B, page 89
1 Basic principles
This Part B of the TR TKÜV describes, pursuant to § 110(3) of the TKG [21] in conjunction with §§ 96,
113(5) and 133c(3) of the TKG:
1. technical details to be observed in connection with disclosure requests from authorised agencies and
the disclosure of information concerning subscriber and traffic data by the obligated service providers
and network operators,
2. the technical characteristics of the required sending and receiving lines of the obligated parties and
authorised agencies, and
3. the requirements for guaranteeing a particularly high standard of data security and quality pursuant to
§ 113f(1) TKG when transmitting traffic data subject to compulsory storage pursuant to § 113c(3),
sentence 1 TKG.
In addition, the use of the interface described in this Appendix will also become mandatory for number-
independent interpersonal telecommunications services one year after the entry into force of the
provisions of the TKG in conjunction with the TKÜV, which include an obligation to make arrangements
for the provision of information on inventory and traffic data.
For messaging services which are provided on the basis of proprietary and non-uniform protocols and for
which an information technology to be developed individually is also to be used regularly to meet the legal
requirements of another European country, it is stipulated that the interface described here must be
established no later than two years after the entry into force of the above-mentioned regulation in the
TKG in conjunction with the TKÜV. In such cases , the requirements of Appendix A.2 may be waived.
Intended deviations must be agreed with the Federal Network Agency before the information technology
is put into operation.
Furthermore, additional optional applications for the interface are described in this Part B of the TR
TKÜV, which serve to enhance the effectiveness of the overall procedure.
This part also describes the technical details for the secure electronic transmission of orders for traffic
data disclosure and telecommunications surveillance pursuant to § 12(2) TKÜV, and for other
applications.
The transmission methods described in this Part B of the TR TKÜV must or can (identifier ‘optional’) be
used for the following purposes:
a. subscriber data disclosure;
b. traffic data disclosure;
c. transmission of the order to provide information on traffic data in real time;
d. disclosure of the structure of radio cells1 (optional);
e. disclosure of the location (optional);
f. transmission of the telecommunications surveillance order;
g. transmission of data for accounting reconciliation in preparation for compensation pursuant to
§ 23(1) of the German Judicial Remuneration and Compensation Act (optional).
For better readability, the term ‘disclosure’ is used synonymously in this TR TKÜV for the request to
provide information (request), for the transmission of the order (warrant) and for the provision of
information (response).
2 Transmission methods ETSI-ESB and E-Mail-ESB
The transmission methods described in Annexes A and B below must be used according to Part 4 of the
TKÜV as follows:
The transmission method ETSI-ESB (Appendix A) must be used for disclosing information on
subscriber data and traffic data and for receiving corresponding orders from subjects pursuant to
§ 113(5) sentence 2 of the TKG.
1
For the purposes of this Guideline, a radio cell is the area covered by a mobile radio antenna that has been allocated its own cell
identifier.
TR TKÜV, edition 7.2 (draft) Part B, page 90
Other subjects according to Part 4 of the TKÜV may use this transmission method as an
alternative to the E-Mail-ESB transmission method, with the possibility of mixed operation for
different applications (e.g. ETSI-ESB for traffic data information, including transmission of the
associated order, and E-Mail-ESB for disclosing subscriber data), subject to agreement from the
Federal Network Agency.
Parties who are not obligated under § 113(5), sentence 2 TKG must use the E-Mail-ESB
transmission method (Annex B) to respond to information requests for traffic data pursuant to
Part 4 of the TKÜV.
As an alternative, subjects may use the ETSI-ESB transmission method as defined in the above
provision.
These transmission methods can be used for other applications in accordance with Section 1.
The encrypted ESB transmission method still used previously can be provided in addition as an
alternative to E-Mail-ESB subject to agreement from the Federal Network Agency, provided the relevant
requirements are adhered to similarly. Other transmission methods and a local transfer are excluded if
the systems are also available for traffic data disclosures pursuant to § 113b of the TKG.
Unsecure transmission methods, for example unencrypted transfer by e-mail or postal mailing of
unencrypted data media, are generally not admissible - i.e. also outside the use of the systems provided
for disclosure of traffic data pursuant to § 113b of the TKG.
These requirements apply accordingly, pursuant to § 1(1) point 7 of the TKÜV, to the recording lines of
the authorised agencies, even in the case of the shared use of central incoming interfaces. In addition to
this, the operation of the E-Mail-ESB outside the authorised agencies, the subjects or their agents is not
permitted.
3 Guaranteeing data security and data quality
3.1 Fundamental requirements
The requirements under § 14(1) of the TKÜV essentially apply, whereby the obligated party has to
provide state-of-the-art protection against unauthorised use in connection with the technical and
organisational precautions taken to implement measures and transmission to the receiving device of the
authorised agency.
Transmissions to the authorised agency must be encrypted; the relevant procedures are set out in the
following descriptions of the transmission procedures.
The requirements under § 14(3) of the TKÜV apply equally to the administration of network elements via
public networks for monitoring or retrieving information data, including storage of information in these
network elements required for this. When implementing these requirements, the relevant international
standards and the recommendations of the BSI must be followed.
3.2 Special requirements for the transmission of traffic data requiring
storage pursuant to § 113b of the TKG
Under § 113c(3) sentence 1, in conjunction with § 113f(1) sentence 1, of the TKG, the transmission of
traffic data pursuant to § 113b of the TKG requires the guarantee of a particularly high standard of data
security and data quality.
Together with BSI and BfDI, the Federal Network Agency has prepared the catalogue of requirements
pursuant to § 113f of the TKG by virtue of whose compliance it is assumed that the statutory
requirements pursuant to §§ 113b to 113e of the TKG are observed.
These following special requirements apply to the transmission methods described for this, provided they
are used exclusively for disclosing information on traffic data pursuant to § 113b of the TKG or
are used in addition to other content permitted under Section 1 above for disclosing information
on traffic data pursuant to § 113b of the TKG.
TR TKÜV, edition 7.2 (draft) Part B, page 91
The following image from the catalogue of requirements shows a possible version of the overall
architecture:
Figure: Implementation example of the basic architecture (source: Catalogue of requirements pursuant to
§ 113f TKG)
Netz des Verpflichteten Network of the subject
Datenquellen Data sources
Kontroll-·und Filtereinrichtung Control and filter device
Rufnummern nach § 99 TKG Call numbers under § 99 of the TKG
Physisch zutrittgesicherte Umgebung für das Physically secure environment for the traffic data
Verkehrsdatenspeichersystem storage system
Firewall Firewall
Ablagesystem Storage system
Datenspeicher Data storage
Zugriffssystem Access system
Schlüsselmanagement Key management
Abfragesystem Query system
ETSI-ESB ETSI-ESB
Wartungszugänge Maintenance access
Bestandsdatenspeicher,… Subscriber data storage
Berechtigte Stelte Authorised agencies
In keeping with the catalogue of requirements pursuant to § 113f of the TKG, the following requirements
in particular apply to the transmission as per § 113c(3) of the TKG:
3.2.1 Ensuring particularly high standards of data security
All the elements of the ETSI-ESB and E-Mail-ESB transmission methods, starting from the query
system and as far as the transfer point for the encrypted transfer (dedicated Internet connection)
to the authorised agency, have to fulfil the requirements for IT baseline protection of BSI with the
protection requirement "high" (see IT baseline protection approach, BSI Standard 100-2).
3.2.2 Use of particularly secure encryption methods, buffering in the transmission process
components and deletion of traffic data in the query system
During transmission, traffic data have to be encrypted using a suitable procedure. The following
descriptions of the two transmission methods include corresponding requirements.
No encryption methods other than those mentioned therein may be used.
To disclose traffic data pursuant to § 113b TKG, the requirements catalogue under § 113f TKG
states that the traffic data should be encrypted inside the access system. To transmit the query
results through the query system as part of the transmission procedure, they can be temporarily
TR TKÜV, edition 7.2 (draft) Part B, page 92
buffered unencrypted in the RAM or encrypted in the persistent memory, with the requirement
that the keys used should be renewed regularly.
When the query system and the transmission method are used for additional disclosures of
information according to the above Section 1, it must be ensured that the connection of further
systems necessary for this is secured using a firewall. The content relating to the firewall
configuration and the log files applies accordingly to subsection 5.2.4 of the requirements
catalogue pursuant to § 113f of the TKG.
Plain data that arises when processing search queries in the query system and transmission
process (decrypted traffic data and other temporary data) must be deleted from the RAM directly
after transmission. In addition, unsecured outsourcing (swapping) of sensitive data from the RAM
must be prevented. Moreover, the requirements as per Section 5.2.5 of the requirements
catalogue pursuant to § 113f of the TKG must be observed.
3.2.3 Implementation of the four-eyes principle in the case of access to and transmission of
traffic data
To be able to process information requests from authorised agencies by employees specially
authorised by the obligated party, there must be controlled access to the query system according
to the four-eye principle. The specially authorised persons must provide authentication with
individual user IDs to the query system. The relevant logging requirements set out in the TKÜV
should be met in doing so.
Depending on the method of transmission employed, the query system has to be designed so that
the two specially authorised persons are able to undertake the following checks:
a) ETSI-ESB transmission procedure
When using ETSI-ESB, the order and relevant query parameters are transmitted by the
authorised agency. The two persons with special access authorisation shall verify in separate,
independent stages the agreement of the query parameters contained in a judicial order or
public prosecutor’s order or in an information request by an authority with the query parameters
made ready for access.
Within the query system, it should be ensured that the query parameters prescribed by the
authorised agency cannot be altered by revision on the part of the obligated party. In the event
of any errors or a lack of clarity, feedback must be sent to the authorised agency in accordance
with the section on the treatment of errors. If there is an error on the part of the authorised
agency, the process must be restarted (it is not admissible to arrange a correction through the
subject by telephone, for example).
b) E-Mail-ESB transmission procedure
When using E-Mail-ESB, no predefined query parameters apart from the order and any further
explanatory notes are transmitted by the authorised agency. The query parameters for access
to the traffic data must be determined in a first step by the first of the two persons specially
authorised to do this.
The first person enters the query parameters in the query system corresponding to the judicial
order or information request by an authority.
The second person shall verify in a separate, independent further stage the agreement of the
query parameters contained in the judicial order or information request by an authority with the
query parameters made ready for access.
If the outcome is positive, the second person shall initiate access to the traffic data and similarly
instigate transmission of the query results to the authorised agency.
If the outcome is negative, the query parameters must be readjusted between the two verifiers.
If no clear result is possible, this must be fed back to the authorised agency with indication of
the flaws detected.
TR TKÜV, edition 7.2 (draft) Part B, page 93
If the AA has made an error, the process must be restarted (the obligated party may not
implement corrections after a phone call, for example).
3.2.4 Physically securing the transmission procedure
The query systems and other parts of the transmission process must be physically protected from
access by persons without special authorisation.
3.3 Time until traffic data is available
The systems for supplying traffic data from network elements of their own telecommunications network
must be designed in accordance with § 31(3), sentence 3 TKÜV such that data collected can be retrieved
by the authorised agency at the latest within 24 hours of the actual event. Their set-up in this respect may
differ in individual cases.
It should be noted that the anticipated period between collection and availability for retrieval must be
stated in the supporting documents.
TR TKÜV, edition 7.2 (draft) Part B, page 94
Appendix A ETSI-ESB transmission method
This Appendix describes the national requirements for the ETSI-ESB transmission method based on the
ETSI specification, TS 102 657.
1.1 Basic description of procedure
The procedure is essentially based on the mechanisms described in ETSI Specification TS 102 657.
Since this specification requires further, nationally defined technical elaboration and has no defined
requirements in Germany (e.g. a surveillance order obligation), additional provisions are needed which go
beyond mere selection of options to address the specification as such.
The basic transmission mechanism requires one recipient and one sender each at both the authorised
agency and the obligated undertaking, through which an initial request message is sent by the authorised
agency to the undertaking, following which the requested data are transmitted in a separate response
message.
These protocols are typically initiated through electronic transmission of the surveillance order in a
warrant request, followed by one or more actual information requests, contained in separate data
requests. Since the ETSI specification does not distinguish between warrant and data requests, these
concepts relate to the uniform request as described there.
The procedure is shown below for a single disclosure request and associated information on traffic data
for various identifiers and in different periods:
Authorised undertakings
agency
AA syst Req Recipient Underta
em king’s
Req (TIFF metadata) system
Sender
XML te
st
Req TIFF ord
HTTP OK er
Metadata
TIFF ord
er
Metadata
Other data Recipient
Response ReqAck
Sender
XML te
Scanner st
ReqAck
HTTP OK
Su
rve SINA VPN
1. The administration of the request by the authorised agency includes entering all the required
metadata for the warrant request and an electronic copy of the order. The metadata contain the
information on the surveillance order for the various identifiers and periods for the actual electronic
processing. Where the metadata refer to several requested identifiers, they shall be assigned
consecutive numbers in the form of a targetNumber. In addition to this, other data not intended for
transmission (e.g. reference numbers, frequency of disclosure) may be administered. The warrant
request is automatically identified by a distinct request number (e.g. 4711).
2. The receipt of the warrant request and automatic verification of its legibility and completeness is
followed by manual verification and clearance of the metadata encompassed by the surveillance
order that are to be used for the disclosure of information by the person(s) expressly authorised for
this by the subject. Clearance must take place only if the metadata correspond to the details of the
surveillance order.
Clearance takes place with reference to the relevant surveillance order for all identifiers and periods
referred to by the latter; such clearance is identified by the request-Number of the warrant request (here
4711).
Every specific request for traffic data requires a separate data request:
1. Based on the settings of the AA system, a separate data request is sent manually or automatically,
which contains the request with respect to a particular identifier and a particular period. This data
request is in turn identified by a distinct requestNumber (e.g. 4922) and refers to the warrant
TR TKÜV, edition 7.2 (draft) Part B, page 95
request through the latter’s requestNumber as a referencedRequestNumber (here 4711). In
addition, the targetNumber refers to the sequential number in the metadata of the warrant request.
2. The receipt of the data request and automatic verification of its legibility and completeness is
followed by automatic verification against the metadata and targetNumber as laid down through the
clearance. If the specific requested identifier and period are covered by the metadata, disclosure
then proceeds automatically.
The data collected with respect to the identifier on which the request is based is transmitted in a separate
response message identified through the requestNumber of the data request (here 4922). Messages from
the undertaking are transmitted using the same procedure but with the roles reversed.
1.2 Procedural requirements
Use of ETSI definitions and national addenda
The delivery of an electronic surveillance order and associated metadata in the warrant request
and the subsequent data requests requires the use of a national XML definition Natparas2,
transmitted through the XML module of the ETSI specification. Other uses (e.g. subscriber data,
tracing) require the transmission of the additional XML definition Natparas3 for the transmission
of the response data using the response message.
Inconsistency of the metadata with the surveillance order
If the metadata in the warrant request does not correspond to the information in the surveillance
order, the data for this part of the warrant request shall not be cleared for disclosure. In this case,
a ResponseIncomplete message as defined in Section 2.2.2.4 shall be returned with an
automatically readable list (TargetNumber) of the identifiers considered invalid. Error-free
requests with respect to other identifiers, which do correspond to the surveillance order, shall be
cleared for disclosure.
After approval from the authorised agency, the procedure shall be re-initiated with a separate
warrant request if there is still a need for the information covered by the incorrect entries. In this
case, the new warrant request may contain either:
- a corrected surveillance order with unchanged metadata for the relevant identifier, or:
- an unchanged surveillance order with corrected metadata for the relevant identifiers.
In case information requests are not issued for some identifiers listed in the surveillance order, no
metadata shall be entered for them (this does not require an error message).
Rejection of an entire warrant request is only required in cases where fundamental errors are
present or suspected (e.g. in case of a garbled electronic copy of the surveillance order, or
absent or incorrect metadata). This shall also be indicated by means of a FailureResponse
message as defined in Section 2.2.2.3.
Parallel transmission of warrant and data request
It is common for a warrant request to be transmitted together with the first few associated data
requests. The receiving system of the undertaking should accordingly have a mechanism in place
enabling it to immediately process received data requests as soon as the associated warrant
request is cleared.
Separate procedures for different uses of the interface
To achieve as simple a query system process as possible, any combination of the applications
listed in ‘1. Basic principles’ is not permitted. Different applications require different warrant
requests, even if they relate to the same electronic surveillance order and the same identifier.
Several identifiers per warrant request, one identifier per subsequent request or order
Every actual request or order (e.g. data request, activation request, etc.) contains exactly one
specific identifier (where, in addition to the forms described in Chapter 4.1 of Part A of this TR
TKÜV, an identifier may also consist of several components, e.g. a name and address, if this is
needed for unambiguous identification), the meta-requests in the warrant request may contain
several identifiers to reflect a possible multiple specification in the surveillance order.
Specifics for transmission of orders for the implementation of surveillance actions
Parallel to the disclosure of traffic data, this interface may be used for the implementation of
surveillance actions as defined in Section 1.3.6.
Use of unified formats and parameters
Similarly to the requirements of Part A of the TR TKÜV, the ETSI specification provides for
TR TKÜV, edition 7.2 (draft) Part B, page 96
various options for the disclosure of data (e.g. IP address in ASCII or binary format). Where the
undertaking needs to convert available data into one of these formats before disclosure, the
encoding specified in Section 2.2.3 must be used. The authorised agencies must use the
encodings listed there in their requests. In Section 2.2.4, it is also specified which
XML parameters are used if the structure of the ETSI specification allows alternative parameters
(standardisation).
Use of newer versions of the national XSD and of ETSI-XSD and related format
requirements
Subjects may only routinely use newer versions of the national XML modules and of the ETSI
XSD six months after their publication. The Federal Network Agency will publish on its website an
overview of the usable modules and any differing transitional deadlines, as well as details on
which modules may not be used for first-time implementations. During the transitional period, the
data not yet defined in the previous version and the legal basis shall be disclosed using the
parameters <additionalInformation> and <other_LegalBasis>, respectively. In Section 2.2.3, the
Federal Network Agency stipulates formats for data and shall publish on its website the
standardised information that should also be used from the legal bases.
The authorised agencies must support and use the versions used by the individual subjects.
Pursuant to § 110(5) TKG, subjects must update older versions. To this end, the aforementioned
overview shall contain an implementation period (optionally also based on requirements).
In the case of version conflicts, an error message is presented pursuant to Section 2.2.2.2,
containing the supported version.
Differences from the requirements of the ETSI specification
In order to simplify the procedure, and to meet the specific requirements in Germany, the
following differences shall apply with respect to the mechanism as defined in the ETSI
specification:
1. In order to enable requests for traffic data from all services used (e.g. telephone service,
Internet access) by a given identifier, the response message may contain the traffic data for
different services, contrary to Chapter 6.2.1 of the ETSI specification.
2. In order to have a standardised scheme for data requests, only the telephony part of the
ETSI specification is applied. Consequently, in order to request the traffic data for all processes
involving an e-mail address, for example, this e-mail address may be entered in the e-mail
address field under partyInformation in the telephony area. Section 2.2.3.4 also permits
combined disclosure. Through an extension of the field 'nationalTelephonyServiceUsage', this
also enables disclosure of the Internet access service via disclosure for the telephony service.
Requirements for the encryption procedure to be used
When using the ETSI-ESB transmission method, only the systems specified in Appendix A.1 of
this part of the TR TKÜV and those in the current policy (Appendix X.3) are provided with the
encryption procedures mentioned therein.
The systems do not have a memory for the data to be transferred. The automated logging of the
transfers does not contain any indications of the nature of the data transferred.
1.3 Specifics of the different applications
The specifics of the different applications are described below.
1.3.1 Disclosure of traffic data
The disclosure of traffic data requires the transmission and verification of a warrant request before
automatic processing of data requests can begin. It is mandatory that the surveillance order be
transmitted over this interface. Separate transmission of data requests enables the authorised agency to
individually specify the frequencies and periods based on information from subject undertaking on the
archival periods of the traffic data kept by them. Therefore, no set disclosure intervals are specified for
future queries. The data request shall only be sent once the query period provided therein has elapsed.
The information shall be disclosed immediately.
According to § 113c(3) sentence 2 of the TKG, it shall be mandatory to label the traffic data for disclosure
pursuant to § 96 (operational traffic data) and § 113b of the TKG (stored traffic data). For the disclosure of
large data volumes, Section 5.1.7 of the ETSI specification provides for transmission in several parts.
TR TKÜV, edition 7.2 (draft) Part B, page 97
1.3.1.1 Disclosure of future traffic data for an urgent order
The needsConfirmation flag must always be set in the warrant request for the retrieval of future traffic
data initiated by an urgent order. The judicial confirmation is done by a warrant-request in which the flag
isConfirmation is set.
1.3.1.2 Correction of a decision already implemented
In order to correct a decision that has been conditionally implemented - for example, due to non-optimal
readability of an original fax transmission - with a new decision, the authorised body sends a warrant-
request in which the flag isCorrection has been set.
1.3.1.3 Extension of an order
Active actions may be renewed only by a new decision. For this purpose, a warrant request with a new
end time is transmitted to the subject and DataRequests are sent as required.
1.3.1.4 Selection of the type of traffic data
For a better understanding of whether traffic data is to be reported with or without location data, each
warrant request contains a corresponding label (LocationCriteria). A further label specifies whether the
traffic data was generated before the decision date or after the decision date. If both elements are set to
false, no location data will be disclosed.
1.3.1.5 Data source
Each warrant-request contains unique information about the origin of the data source. The choice is
between operational traffic data and traffic data stored on the basis of a legal obligation (cf. ‘Act
introducing a storage obligation and maximum retention period for traffic data’).
1.3.1.6 Automatic delivery of late records after determining the authorised
agency
As specified in Section 3.3, the subject’s systems must be designed such that data sets within the
network are available for retrieval by the authorised agencies at the latest within 24 hours of the actual
event. The exact time period, which in some cases may be longer, shall be announced by the obligated
party within its supporting documents and can be taken into account by the authorised agencies when
giving deadlines for data requests.
To also obtain external data sets that may become available later (e.g. roaming data), authorised
agencies may deviate from the practice of immediate information disclosure and specify that delayed
traffic data (late records) that only become available after the requested time period in the warrant
request and a waiting period specified by the obligated party for such data sets have elapsed, be
disclosed using a data request labelled accordingly (see Section 3.2.2.3). The waiting period to be agreed
with the Federal Network Agency has to be long enough for late records to be regularly recorded
completely. The disclosure is made in a regular response message and contains all the traffic data stored
at this point for the entire period. This specification may be withdrawn by the authorised agencies in a
cancel message.
1.3.1.7 Selective disclosure of traffic data
Disclosure of traffic data must, in principle, be available in selective form (§ 101a(1) sentence 1 point 1 of
the Code of criminal procedure). This necessitates the parameters for disclosure to be provided in
XPATH notation with the aid of the XML element <requestedData> of the ETSI XSD. Contrary to non-
selective disclosure, only the parameters requested by the authorised agency are thereby provided.
When using this XML element, only the selectively requested data is to be transmitted, unlike the
procedure as described in Section 1.3.1.
If the chosen element contains ‘child nodes’, the entire XML subtree below it is deemed to be selected.
Only absolute paths are permissible, i.e. wildcard characters or other search operators or logical links
such as AND, OR or XOR may not be used.
TR TKÜV, edition 7.2 (draft) Part B, page 98
1.3.1.8 Selective disclosure of traffic data in a destination dialling search
Further to the previous section, to disclose traffic data produced for a particular destination address or
from a known phone number (source address) for unknown destination addresses (destination dialling
search), the following parameters are to be filled in the Natparas2 of ETSI-XSD in addition to the labelling
(see Section 3.2.2.3):
Destination dialling search for a known target address:
TelephonyServiceUsage/partyInformation/partyNumber: Target phone number (E.164 format):
Specification of known target address
TelephonyServiceUsage/TelephonyPartyInformation/TelephonyPartyRole:
Tag number 1, "terminating-Party"
Destination dialling search from a known phone number (source address):
TelephonyServiceUsage/partyInformation/partyNumber: Source address (E.164 format):
Specification of known source address
TelephonyServiceUsage/TelephonyPartyInformation/TelephonyPartyRole:
Tag number 1, "originating-Party".
1.3.1.9 Early deactivation of individual identifiers of an existing order based on
traffic data
If the authorised agency does not intend to request any additional traffic data on a particular identifier for
the term of the surveillance order, it should inform the subject to this effect. To allow for early deactivation
of targets of a valid warrant related to traffic data, a WarrantTarget must be disabled. For this purpose,
the authorised agency sends a warrant in which the DeactivateTarget flag is set for each target to be
terminated prematurely. Targets not listed are not deactivated. As acknowledgement, this is followed by
either ResponseComplete (all changes implemented), ResponseIncomplete (some changes rejected with
error message per target) or ResponseFailed (all changes rejected, again with error messages).
Any subsequent incoming data requests for deactivated targets are acknowledged with FailureResponse.
The DeactivateTarget flag cannot be used for other purposes.
1.3.2 Disclosure of traffic data in real time
In addition to the remarks in Section 1.3.1, the following applies:
In order to meet real-time requirements, any obligated undertakings under § 32(3) TKÜV with an interface
in place for transmitting the telecommunication under surveillance as defined in Part A shall implement
such disclosure requests by administering an IRI-Only action (provision of data pursuant to § 7 TKÜV). To
implement this, the surveillance technology shall be adapted such that
1. the data transmitted to the agency authorised to receive the information do not contain any
message content,
2. location data can be collected and transmitted even for terminals in stand-by mode and
transmitted to said agency, and
3. the transmission of the location data according to point 2 can be limited such that, for criminal
prosecution authorities, the data is only transmitted in accordance with § 100g(1) of the Code of
Criminal Procedure, or, for another authorised agency, the data is only transmitted in
accordance with the applicable statutory regulations.
Depending on the system, SMS short messages shall be transmitted in the signalling channel. Where
traffic data is disclosed in real time, this SMS informational content should be removed before the data is
forwarded to the authorised agency. Any parameter values, e.g. length information or test totals
describing the original packet size, should not be altered when doing so. In the future, this specific case
shall be resolved with a comprehensive solution established in cooperation with international
standardisation committees.
Alternative precautions for implementing such disclosure requests must be equivalent and in agreement
with the Federal Network Agency.
For the associated messages (warrantRequest and dataRequest), according to Section 2.2.1, the port for
transmitting the telecommunication surveillance order is to be used; the cited legal basis distinguishes
between the two uses.
TR TKÜV, edition 7.2 (draft) Part B, page 99
1.3.3 Disclosure of the structure of radio cells
The interface described, and the procedure as described in Section 1.3.1, may optionally be used for
disclosures of the structure of radio cells.
1.3.4 Disclosure of subscriber data
It is mandatory for all telecommunications suppliers with more than 100 000 subscribers to use the
interface as described and adopt the procedures specified in Section 1.3.1 pursuant to § 113(5) sentence
2 of the TKG for the disclosure of subscriber data.
The request for subscriber data is delivered with the transmission of the warrant request and data
request. The warrant request must comply with the formal requirements of § 113(2) of the TKG (including
the text form and specification of the legal basis) and includes a respective WarrentTarget (multiple
disclosure is not possible). It also includes the optional list for selective requests. For the text form, the
XML elements <warrantTIFF> and <warrantTextform> are available.
The data request is then to be sent with the warrant request or immediately afterwards. The content of the
data request does not differ from the warrant request (e.g. no extremely large quantities). For cases
where the ETSI XSD does not contain appropriate fields for request data, the national addendum defines
the necessary fields. If the warrant request is not followed by a data request within one hour (or vice
versa), it is closed and a FailureResponse is sent for the warrantRequest (or dataRequest) request.
The request is processed starting with a formal check of the warrant request by a responsible employee
as soon as the data request is received. An automatic check is not permissible by law. The disclosure is
made after receipt of the data request.
1.3.4.1 Selective disclosure of subscriber data
Selective disclosure of subscriber data must also be permitted in principle. This necessitates the
parameters for disclosure to be provided in XPATH notation with the aid of the XML element
<requestedData> of the ETSI XSD. Contrary to non-selective disclosure, only the parameters requested
by the authorised agency are thereby provided. When using this XML element, only the selectively
requested data is to be transmitted, unlike the procedure as described in Section 1.3.4.
If the chosen element contains ‘child nodes’, the entire XML subtree below it is deemed to be selected.
Only absolute paths are permissible, i.e. wildcard characters or other search operators or logical links
such as AND, OR or XOR may not be used. Where the request includes the data field PUK of ETSI-XSD,
the PTN is also required, which must be reported by the subject in the appropriate field of NatParas3. The
data field scope of the type ScopeForSubscriberData specifies the scope of the request.
The Federal Network Agency publishes on its homepage (www.bundesnetzagentur.de/tku) a table of
possible inventory data that can be queried, an explanation of the expected result per parameter and the
corresponding x-path.
1.3.5 Disclosure of location
The interface described in the procedure described in Section 1.3.1 can optionally be used for disclosure
of location, for example to avert danger in connection with a surveillance measure or a traffic data
request:
a) location of mobile terminals;
b) determination of connection owner to IP address;
c) disclosure of the name and address of a physical connection or customer ID (LineID);
d) determination of connection owner on the basis of another identifier (OtherID in combination with
OtherIDtype).
The requirements of earliest possible availability of the results of such requests issued at varying
locations (e.g. deployment sites in case of searches for missing persons) and based on locally defined
initiation points of the requests are not always compatible with this type of electronic procedure.
Accordingly, it is often necessary to follow a parallel ‘manual’ procedure, e.g. via telephone.
TR TKÜV, edition 7.2 (draft) Part B, page 100
1.3.6 Transmission of surveillance orders and other
telecommunications surveillance actions
The use of this interface fulfils the requirements under § 12(2), sentence 1 TKÜV for secure electronic
transmission of a copy of the surveillance order. In this case, the original order or a certified copy thereof
need not be presented.
1.3.6.1 Implementation of surveillance actions
Similar to the procedure for traffic data disclosure, implementing surveillance actions initially requires
clearance based on a warrant request; the activation and deactivation of actions is sent in separate
activation and deactivation requests. Several relevant identifiers are referred to through sequential
numbers in the form of a targetNumber.
When using this possibility, the requirement of logging pursuant to Section 16 of the TKÜV must be
observed, which requires every single application of the surveillance device to be logged, irrespective of
whether the application is done manually or automatically.
The figures below show the procedure for the implementation of a surveillance action with respect to two
different identifiers (Figure A) and for the extension of an action (Figure B):
Activation of ‘Early’
Order pursuant TKÜ-MN for deactivation of
to § 100a of identifier A with Change of TKÜ- TKÜ-MN with
the Code of LIID 111222 MN with identifier A
criminal identifier A
procedure
new requestNumber new requestNumber new requestNumber
requestNumber: 56789 referencedRequestNumber: 56789 refReqNumber: 56789 refReqNumber: 56789
LIID: 111222 LIID: 111222
Activation of ‘premature’
TKÜ-MN for deactivation of
identifier B with TKÜ-MN with
LIID 55555 identifier B
new requestNumber new requestNumber
referencedRequestNumber: 56789 refReqNumber: 56789
LIID: 55555
Figure A: Implementation of a surveillance action for identifiers A and B
Activation of
Order pursuant TKÜ-MN for
to § 100a of identifier C with
the Code of LIID 454545
criminal
procedure
new requestNumber
requestNumber: 56899 referencedRequestNumber: 56899
Order pursuant ‘premature’
to § 100a of Renewal of TKÜ-
MN with deactivation of
the Code of TKÜ-MN with
criminal identifier C
identifier C
procedure,
extension
new requestNumber: 57123 new requestNumber new requestNumber
referencedRequestNumber: 56899 refRequestNumber: 57123 refRequestNumber: 57123
LIID: 454545 LIID: 454545
Figure B: Implementation and extension of a surveillance action for identifier C
TR TKÜV, edition 7.2 (draft) Part B, page 101
1.3.6.2 Implementation of urgent surveillance orders
If a surveillance action is to be implemented by means of an urgent surveillance order, the
needsConfirmation flag must be set in the warrant-request. The judicial confirmation is done by a warrant-
request with the flag isConfirmation set.
1.3.6.3 Corrections to the order on actions already implemented
A decision that has been implemented with reservations - for example, because an original fax message
was not optimally legible - can be corrected by a new decision. To this end, a warrant-request with the
flag isCorrection set must be transmitted.
1.3.6.4 Switching to actions already implemented
Changes to an active action which do not require an additional surveillance order are implemented
through a modify request.
1.3.6.5 Extension of an order
Active actions may be renewed only by a new decision. For this purpose, a warrant request with a new
end date is transmitted to the subject, as well as a renewal request.
Changes to an active action which do require another surveillance order are initiated through a second
warrant request and activated through a second activation request. The second warrant request initiating
the change must not contain the metadata of individual actions or identifiers from the first warrant request
which are not affected by the change.
Similar to the procedure for traffic data disclosure, activation, modification, modify and renewal requests
may be processed automatically after verification against the metadata of the warrant request.
1.3.7 Transmission of data for accounting reconciliation in preparation
for compensation pursuant to § 23(1) of the German Judicial
Remuneration and Compensation Act (optional)
See Section 4.
1.4 Secure electronic transmission of the surveillance order
Processes for secure electronic transmission of the surveillance order as described in accordance with
Part B of the TR TKÜV which use a SINA VPN as defined in Appendix A-2, do not require subsequent
transmission of the original or a certified copy of the surveillance order by post.
The stipulation of using a SINA VPN provides for a secure electronic transmission as defined in the
requirements under § 12(2) of the TKÜV.
When implementing this procedure and the thereby enabled preallocation of administrative areas, it
should, however, be ensured that the order cannot be implemented automatically. Rather, a manual
verification must be undertaken for each individual case. Only after such manual verification and
subsequent clearance within the system may an action be activated, either manually or automatically
through further requests.
Format of the order
The order shall be converted into the multipage TIFF format (CCITT Group 4 Fax) for transmission. The
maximum file size is 5 MB. If a follow-up order does not contain all the required data (e.g. legal basis,
identifier, period), it must be transmitted in a single file together with the original order. Copies of the
telecommunications surveillance order that were sent previously via fax must meet minimum quality
requirements. This must correspond to at least to the high resolution (203 or 204 dpi horizontally; 196 dpi
vertically) of commonly used fax devices (this usually corresponds to the ‘fine’ setting).
2 Provisions for the transmission point according to ETSI
Specification TS 102 657
This section describes the conditions for the transmission point according to
ETSI Specification TS 102 657 [37].
TR TKÜV, edition 7.2 (draft) Part B, page 102
The Appendix addresses the decision made with respect to options contained in the specification, as well
as additional technical requirements. Using the XML module described in the ETSI specification, one
query at a time is transmitted; packetisation of multiple queries is not envisaged.
The following Appendices of Part X of the TR TKÜV apply in addition to the requirements of this Part:
Appendix Contents
Appendix X.1 Proposed changes to the TR TKÜV
Appendix X.3 Provisions for the registration and certification authority TKÜV-CA of the Federal Network
Agency, Department IS16 (Policy)
Appendix X.4 Table of applicable ETSI/3GPP standards and specifications as well as the ASN.1 modules
2.1 Selection of options for ETSI TS 102 657
The following table describes, on the one hand, the selection of options for the different chapters and
sections of ETSI Specification TS 102 657 and, on the other, specifies the respective additional
requirements. Unless otherwise indicated, the references in the table relate to the respective sections of
the ETSI specification:
Paragraph Description of the option or problem and Additional requirement, background and
TS 102 657 specifications regarding national supplemental information
application
4.1 Reference model
No provision for different Authorized See in this regard the stipulations in this Table with
Organisations for HI-A and HI-B has been respect to Chapter 5.4
made.
4.5 Model used for the RDHI
XML/HTTP shall be used as the transmission See in this regard the stipulations in this Table with
mechanism. respect to Chapter 7, or immediately below this
Table.
5.1.2 Message flow modes
Essentially, provision is only made for the Requested data shall be transmitted by the
General situation variant pursuant to obligated party directly to the authorised agency
Chapter 5.2. (push procedure).
5.1.5 Errors and failure situations
Errors as defined in 5.1.5.2 shall be reported to See in this regard the stipulations in Section 2.2.2 of
the authorised agency together with a qualified this TR TKÜV immediately after this Table.
error message.
Transmissions with formal errors (errors as
defined in 5.1.5.3) shall be rejected by the
recipient.
5.1.7 Delivery of results
The single shot delivery option must be In the single shot delivery option, there will be
implemented; the multi-part delivery option may exactly one response for each request. For future-
be implemented. related orders for disclosure of information on traffic
data, the authorised agency shall send separate
requests to the undertaking for each relevant
surveillance order, taking account of the periods for
which the relevant data are archived by the
undertaking.
The multi-part delivery option allows subdividing a
disclosure into several parts in case of a large
volume of traffic data to be transmitted. If this option
is implemented, the ResponseNumber parameter
must be used. The use and its exact form must be
described in the concept.
For both options, the following additional
requirements apply:
1. The basic obligation incumbent upon
telecommunications undertakings under § 96 of
TR TKÜV, edition 7.2 (draft) Part B, page 103
Paragraph Description of the option or problem and Additional requirement, background and
TS 102 657 specifications regarding national supplemental information
application
the TKG to immediately delete any traffic data not
needed after the connection is terminated is not
affected.
2. The form of the technical procedure shall not give
rise to an obligation or entitlement to archive
traffic data for longer than the period provided for
by § 96 of the TKG.
5.5 HI-A and HI-B addressing
The deliveryPointHIB field is not used. Different IP addresses for a single Authorized
Organization within a request and its associated
response shall not be permitted, i.e. the source IP
address for HI-A and the target IP address for HI-B
must be identical.
6.1.2 RequestID field specification
The required Authorized Organization Code The Authorized Organization Code of the authorised
identifier of the authorised agency will be agency corresponds to the authorised agency ID
allocated by the Federal Network Agency. assigned as a unique reference number for
surveillance measures (see in this regard
Appendix X.2 of the TR TKÜV).
If the authorised agency fails to receive an
ACK message for a transmitted request, it may Acknowledgement of duplicate RequestNumbers by
resend the same request with the same the subject is limited to the information available to
RequestNumber. This procedure is described him/her. It does not mandate a violation of
in Section 2.2.2.5 of this TR TKÜV. obligations to delete data under privacy laws.
6.1.3 CSP Identifiers
The required identifiers of the subject, CSP ID The CSP ID of the obligated party matches the
and Third Party CSP ID, will be allocated by Operator ID allocated as part of the obligation under
the Federal Network Agency. Part A and/or Part B of this TR TKÜV.
6.1.4 Timestamp
The limitations under Section 2.2.3.1 of this
TR TKÜV shall apply.
6.3.1 Information contained within a request
6.3.2 Identifiers shall be requested with equals. The following shall not be used:
The range parameters lessThanOrEqualTo and notEqualTo, lessThan, greaterThan, startsWith,
greaterThanOrEqualTo are to be used only for endsWith, isAMemberOf
timestamps.
6.3.3 Additional information in requests
All requests shall have the same priority.
The MaxHits parameter shall not be used.
6.4 Error messages
Error message must be clear. In the case of
version conflicts, for example, the error
messages must at least contain the expected
version.
7 Data exchange techniques
XML/HTTP shall be used as the transmission See in this regard the stipulations in Section 2.2 of
mechanism. Transmission shall occur over the this TR TKÜV or those immediately after this Table.
public Internet using a VPN in accordance with
Appendix A-2.
7.2 HTTP data exchange
The Mutual client/server option shall be used. See in this regard the stipulations immediately
following this Table.
7.2.3 Mutual client/server
The URI shall be the same for HI-A and HI- A host header is not needed.
B: /etsi
TR TKÜV, edition 7.2 (draft) Part B, page 104
Paragraph Description of the option or problem and Additional requirement, background and
TS 102 657 specifications regarding national supplemental information
application
8 Security Measures
The requirements as per Appendix A-2 shall
apply.
Appendix A Data fields
The Appendix describes the data fields used Examples of common requests and the generally
and the stipulations within an ASN.1 definition. expected results may be requested from the Federal
The applicable XML definition shall be taken Network Agency.
from the ETSI website together with the ETSI
specification.
2.2 Supplementary technical requirements for the interface
specification under ETSI TS 102 657
The handshake mechanism as described in the ETSI specification requires more stringent national
stipulations than the HTTP transmission method described therein if an error-free interaction of the
various systems is to be ensured.
2.2.1 HTTP transmission method
For electronic transmission to participating undertakings, the latter shall inform the Federal Network
Agency of the addressing information required in this regard (IP address), which is then forwarded to
the authorised agencies.
The port numbers of the relevant recipient (destination port) are the same for HI-A and HI-B and shall be
used as follows. If a surveillance order is necessary for the corresponding request, this will be transmitted
via the same port.
Application Destination port
Traffic data disclosure 50200
Subscriber data disclosure 50210
Disclosure of location 50220
Transmission of the telecommunications surveillance order, disclosure of traffic 50230
data in real time
Disclosure of the structure of radio cells 50250
Transmission of accounting information or submitting claims for compensation 50260
pursuant to § 23(1) of the German Judicial Remuneration and Compensation Act
All messages (Req, ReqAck, Res, ResAck, etc.) shall be transmitted via the POST method each in its
own HTTP session. Successful transmission and server-side validation of the XML message shall be
acknowledged by the server by means of an HTTP 200 (OK). After transmitting the HTTP status codes,
the server shall terminate the connection.
Connection may be terminated after 60 seconds without any activity by the client or server. If the server
terminates the connection, it shall first send an HTTP 408 (request time-out) to the client.
Only one request per HTTP session is permitted; multiple requests must each be contained in their own
HTTP sessions.
Use of “Content-Encoding: gzip” within the client’s HTTP POST request shall be optional. The server
must be able to process the relevant requests and responses.
In accordance with the XML standard, special characters shall be replaced by the corresponding escaped
characters since the validation will otherwise fail.
TR TKÜV, edition 7.2 (draft) Part B, page 105
2.2.2 Error handling
2.2.2.1 Error in encoding of request or disclosure (pursuant to
ETSI TS 102 657, Section 5.1.5.3)
If a request/disclosure contains formal errors (invalid XML or missing obligatory parameter), the
HTTP server shall reject it with the HTTP status code 422 (Unprocessable Entity). A clear error message
is to be transmitted in the HTTP body. For example, if the version of the transmitted Natparas does not
correspond to the version expected from the obligated party, the version used by the obligated party is to
be notified in the HTTP body of the error message.
Appendix A.4 of Part A of this TR TKÜV applies accordingly regarding the requirement of repeated
transmission attempts.
2.2.2.2 Status errors (pursuant to ETSI TS 102 657 Section 5.1.5.3)
In case of a status error (‘wrong messages at the wrong time’), an Error Message (ErrorAck) shall be
sent which refers to the RequestID of the relevant request and which may contain an optional comment.
2.2.2.3 Request cannot be implemented (pursuant to ETSI TS 102 657
Section 5.1.5.2)
If a request cannot be implemented (e.g. incorrect parameter, no corresponding surveillance order or data
request for a rejected warrant), a FailureResponse message shall be sent, structured as described in the
following example, with an explanation.
This procedure will be necessary when:
a) during manual verification of a request message (e.g. after transmission of a surveillance order or a
request for subscriber data) it is found that the entire request cannot be implemented, or:
b) automatic verification (e.g. a request message of type usageData) finds an error in the parameters.
A new request typically then needs to be sent, with a new request number.
This FailureResponse message may also be used when technical or other errors on the part of the
obligated undertaking cause delays in disclosure of which the requesting agency needs to be informed.
2.2.2.4 Transmission of the ResponseComplete or ResponseIncomplete
message
When there are no errors, a Request of the warrant type is confirmed with a ResponseComplete
message.
If parts of the order cannot be implemented, a ResponseIncomplete message shall be returned with an
automatically readable list of the identifiers considered invalid. A short error message
(RejectedTargetErrorMessage) can be added to each rejected identifier (RejectedTargetNumber).
2.2.2.5 Repeated transmission of the same message
Every request, response, or cancel message shall be acknowledged by a corresponding ACK message. If
such an ACK message is not received, the original message (e.g. a request) may be retransmitted with
the same request number. The receiving system must be able to recognise that the same message is
being resent, and
return an ACK message,
nevertheless refrain from processing the second message (e.g. traffic data disclosure) if the first
message was in fact received and is already being processed.
Repeated transmission of a message shall have the same content; if any discrepancy is found when
(optionally) comparing the original and repeat messages, processing shall be terminated and a
FailureResponse message shall be returned.
2.2.2.6 Transmission of a cancel message
By means of a cancel message, authorities can stop unprocessed data requests that are no longer
required. Data requests already being processed will still be disclosed.
TR TKÜV, edition 7.2 (draft) Part B, page 106
2.2.3 Determination of formats
Wherever possible, the data to be disclosed shall be presented in the format in which they are available
to the obligated undertaking. Where individual available data need to be converted into a format specified
by the ETSI specification before disclosure, the encoding to be used shall be as listed below in
Section 2.2.3.3. The authorised agencies must use the encodings listed therein in their requests.
Since these provisions will be subject to updates based on additional applications or eligible types of
traffic data, this section reflects the state of affairs at the time of publication of the relevant version of the
TR TKÜV. The Federal Network Agency will coordinate any new provisions with the parties involved and
update the list accordingly. The current version of the format provisions will be made available for
download on the website of the Federal Network Agency at (www.bundesnetzagentur.de/tku) after
consultation.
2.2.3.1 Formats for date and time data
For this part of the TR TKÜV, the use of the GeneralisedTime encoding for date and time data is required
throughout. Here, the GeneralisedTime format is reduced to YYYYMMDDhhmmss.fraction +/- time
differential, where YYYY represents the year, MM the month, DD the day, hh the hour (00 to 23), mm the
minute (00 to 59) and ss the second (00 to 59). Data may optionally be specified to a higher accuracy
(fractions of seconds). Times should always be given as the official German time (local time). In order to
unambiguously represent different times at the transition between summer and winter time, the time
differential with respect to UTC must also be specified. This requirement applies equally to disclosed data
which are produced within the internal system or network of the obligated undertaking; for time data
received from foreign roaming partners, the time value as provided may be used alternatively.
2.2.3.2 Formats for geographical location information pursuant to
ETSI TS 102 657
Coordinate data should normally be specified either as geographical coordinates in decimal notation
(‘geoCoordinatesDec’) or as geographical angular coordinates (‘geoCoordinates’).
Coordinates shall be specified within the 'extended Location' construct based on the WGS84 reference
system. If known, the location shall be specified with reference to the main radiation direction ('azimuth').
If a geographical location, for example, a so-called radio cell disclosure request or location information
with respect to mobile terminals has to be specified using postal address data, the ‘postalLocation’
parameter within the ‘extendedLocation’ construct must be used to communicate these data.
2.2.3.3 Formats for identification of radio cells for disclosure requests
For radio cell disclosure requests, the radio cell identifier from 2G to 4G (including 5G NSA) has to be
transmitted in the field ‘userLocationInformation’. It must be observed in this regard that only one
specification may be contained in the userLocationInformation block. The use of other data fields such as
GlobalCellID is not permitted. For 5G SA radio cell identifiers, the nCGI field (already present in TS 102
657) must be used instead.
For radio cell identifiers within traffic data disclosures, again only the field ‘userLocationInformation’
should be used.
2.2.3.4 Formats for other identifiers pursuant to ETSI TS 102 657
Table A below lists the identifiers pursuant to ETSI TS 102 657 for which there is only a single format
option, and explains their application.
Table B lists identifiers for which the ETSI specification allows several format options or for which an
explanation seems appropriate, and explains those alternatives which should be used based on the
above explanation or which must be used for requests from the authorised agencies:
Table A
Identifier Format pursuant to Example of encoding pursuant to TS 102 657
TS 102 657
(or national addendum)
PartyNumber E.164 in international format as Identifier 0123/4567890
(Callnumber, MSISDN, a UTF-string
VLR) ETSI format 491234567890
TR TKÜV, edition 7.2 (draft) Part B, page 107
IMSI Octet String Size 3–8 Identifier 262071234567890
pursuant to 3GPP TS 09.02
ETSI format 62021732547698F0
IMEI Octet String Size 8 Identifier 12345678901234
pursuant to 3GPP TS 09.021
ETSI format 21436587092143F0
userLocationInformation Octet String Size 1-35
pursuant to 3GPP TS 29.274
emailAddress UTF8String Identifier
[email protected]
(E-Mail Address)
ETSI format
[email protected]
1 Where only positions 1 to 14 are available for a given IMEI, the remaining positions shall be filled with padding
(11110000) or ‘F0’. When comparing IMEIs, an IMEI shall be deemed equivalent to the requested IMEI even if the
checksum or software version digits are different or missing.
Table B
Identifier Format pursuant to TS Example of encoding pursuant to TS 102 657
102 657
IPv4 address Octet String Size 4 Identifier 127.0.0.1
ETSI format 7F000001
IPv6 address Octet String Size 16 Identifier 2001:0db8:85a3:08d3:1319:8a2e:0370:7344
ETSI format 20010DB885A308D313198A2E03707344
For other necessary identifiers for which the ETSI specification does not specify a parameter, the national
XML module ‘Natparas2’ contains extensions to the ETSI parameter nationalTelephonyPartyInformation
(see Section 3.2.2 of this TR TKÜV ). The ETSI parameters TelephonyDeviceID and subscriberID should
therefore not be applied for those options.
2.2.3.5 Combined inquiries on traffic data for telephony and Internet access
services for a single identifier (optional)
The ETSI Specification TS 102 657 distinguishes between inquiries for different services, such as voice
services and Internet access services. Accordingly, inquiries on the traffic data for both telephony and
Internet for a particular identifier (fixed or mobile telephony number) would require separate disclosure
requests.
To avoid the need for duplicate requests and disclosures, this TR TKÜV allows the following procedure to
be followed as an option:
1. Both the warrant request and the data request specify, using the usageData parameter, whether
the traffic data are to be disclosed for telephony or for Internet access. If both possible values are
set to true, the request is understood to relate to a disclosure of the two combined.
2. To facilitate the transmission of traffic data with respect to combined requests, the field
'nationalTelephonyServiceUsage' in the ETSI specification is extended (as highlighted in bold
below) to enable a disclosure for telephony also to be used for a disclosure for Internet access.
TelephonyServiceUsage ::= SEQUENCE
{
partyInformation [1] SEQUENCE OF TelephonyPartyInformation OPTIONAL,
communicationTime [2] TimeSpan OPTIONAL,
-- Time and duration of the communication
nationalTelephonyServiceUsage[10] NationalTelephonyServiceUsage OPTIONAL
}
NationalTelephonyServiceUsage :: = SEQUENCE
{
countryCode [1] UTF8String (SIZE (2)),
version [2] UTF8String (SIZE (2)),
internetAccess [3] NAServiceUsage OPTIONAL
}
TR TKÜV, edition 7.2 (draft) Part B, page 108
The option to make use of this method shall be laid down in the concept. If the relevant obligated
undertaking does not support this option, a request to that effect shall be answered with an error
message as defined in Section 2.2.2.3.
2.2.4 Standardisation of response data for subscriber data and traffic
data - selective disclosure
A national survey concerning the selection of suitable ETSI parameters for subscriber and traffic data
revealed that the specification does offer possibilities of interpretation and that for this reason, in some
cases, this may lead to different parameters being selected. In order to ensure a uniform level of
information in selective disclosure, tables should define the parameters to be used across manufacturers
(see also Sections 1.3.1.2 and 1.3.4.1 of this Appendix).
The Federal Network Agency publishes on its website (www.bundesnetzagentur.de/tku) the tables to be
used, if applicable.
2.2.5 Flexible use of free text field ‘otherInformation’
For all possible parameters for which no unambiguous correspondences exist in the ETSI construct, the
free text field 'otherInformation' is to be used
(responseMessage/responsePayload/ResponseRecord/additionalInformation/otherInformation).
The syntax to be observed in this regard can be taken from Section 3.3.2.1.
3 Definition of national parameters
3.1 General
The international standards and specifications underlying this TR TKÜV have the option to transmit
national parameters.
The additional national XML modules ‘Natparas2’, used for transmission of the copy of the surveillance
order as well as the additional data in the warrant and data requests, and ‘Natparas3’, used for
transmission of the response for other uses (e.g. for determining the location of mobile telephony
terminals) are described below. Only the Federal Network Agency may introduce changes and additions.
In accordance with the XML standard, special characters shall by replaced by the corresponding escaped
characters since the validation will otherwise fail.
The module Natparas2 is inserted in the NationalRequestParameters field of the RequestMessage. The
module Natparas3 is inserted in the NationalResponsePayload field of the Response Message.
The current versions of the national modules are published on the Federal Network Agency website
(www.bundesnetzagentur.de/tku). The published Natparas versions are not linked to the current
ETSI XSD version. However, if versions of the national modules should not be used due to, for instance
XML compatibility problems with certain ETSI XSD versions, a corresponding note is placed on the
website.
3.2 Description of the national XML module ‘Natparas2’ (for requests)
This Appendix contains the XML description of the national module ‘Natparas2’, used for transmitting the
copy of the surveillance order as well as the additional metadata in the warrant and data requests.
As this XML description will be subject to updates with new additional parameters, this Appendix only
reflects the state of affairs at the time of publication of the relevant edition of the TR TKÜV. The Federal
Network Agency will coordinate proposed new parameters with the parties involved (authorised agencies,
subjects) and will then update the XML module. The current version of the XML description of the national
parameters as well as the provisions below for the individual parameters will be made available from time
to time for download on the website of the Federal Network Agency (www.bundesnetzagentur.de/tku)
after consultation. To determine the standardised information to be used from the legal bases, the
elements of the ComplexType ‘LegalBasis’ shall be listed additionally in a separate list and published on
the Federal Network Agency’s website. This list shall set out the legal bases according to the Natparas2
version.
TR TKÜV, edition 7.2 (draft) Part B, page 109
3.2.1 Determination of usage modes
The Natparas2 module is defined for the following usage modes:
Transmission of the surveillance order and metadata (type warrant);
here, the ETSI RequestMessage merely serves as a transmission envelope.
Transmission of actual inquiries on disclosure of subscriber and traffic data (subscriberData and
usageData types);
here, the national module merely contains supplementary data whilst the ETSI RequestMessage
contains the actual request through the content of the corresponding known parameters (e.g.
transmission of phone number and a period with the disclosure of traffic data).
Transmission of queries on determining the location of mode terminals (locating type) and the
structure of radio cells (radioStructure type);
here, the ETSI RequestMessage merely serves as a transmission envelope
Transmission of the activation or change messages for implementing surveillance actions
(lawfulInterception type);
here, the ETSI RequestMessage merely serves as a transmission envelope
Transmission of an early deactivation of individual targets t(deactivateTarget type) of an existing
warrant related to traffic data.
Usage modes linked to a given surveillance order may contain several identifiers in their warrant
request (the various identifiers are identified by means of consecutive numbers through the
<targetNumber> parameter). For usage modes usageData, locating and radioStructure, each request
can relate to only a single identifier.
3.2.2 Specification of additional data in the national XML module
Natparas2
The XML module Natparas2 is inserted in the NationalRequestParameters field of the RequestMessage,
and is structured as follows:
3.2.2.1 Specifications for the header
NationalRequestParameters
Parameters Description M/C/O
<countryCode> Value 'DE' M
<headerID> Version number of the national Natparas2 module M
The format of the version number is made up as follows:
ETSI version.TR edition no,
where:
ETSI version: 8 characters,
TR edition: 4 characters,
No: 2 characters.
Example: 01.26.01.07.2.01 means:
01.26.01 07.2 01
ETSI TS 102 657 relevant consecutive numbering for the
version No TR TKÜV NatParas version
01.26.01 edition 7.2
<referencedRequestNumber> This refers to the request number (RequestID in the ETSI XSD) of C
a surveillance order previously transmitted in a warrant request;
this is a mandatory parameter for all requests following a warrant
request.
<targetNumber> Consecutive number of the relevant identifier in the warrant C
request to which the subscriberData and lawfulInterception
requests refer when initiating a disclosure or surveillance action for
that identifier. This parameter is mandatory in these cases.
<groupID> The consecutive number serves only to group different requests O
for accounting purposes.
(e.g. to group 10 different inquiries on the same IP address
pursuant to § 23(1), Appendix 3 point 201 of the German Judicial
Remuneration and Compensation Act)
TR TKÜV, edition 7.2 (draft) Part B, page 110
<additionalInformation> Free text to be taken into account before processing the O
applications <subscriberData>, <locating> and<radioStructure>.
<requestDetails> Here, the possible application modules are specified as a choice M
requestDetails
Parameters Description M/C/O
<warrant> to transmit a surveillance order including metadata C
<usageData> for requests for traffic data, with the specific request data defined C
in the ETSI XSD; the national addendum as described in
Section 3.2.2.3 additionally distinguishes between the service to
which the request relates (telephony or Internet access service)
<subscriberData> for requests for subscriber data beyond the options of the C
ETSI XSD
<locating> for site determinations according to Section 1.3.5 C
<radioStructure> for requests for the structure of radio cells, with the specific data
requested defined in the ETSI XSD
<lawfulInterception> for the activation/change/deactivation of a surveillance action, after C
the surveillance order itself has been transmitted
<compensation> data type for asserting compensation claims C
3.2.2.2 Specifications for warrant requests in the national XSD addendum
Warrant
Parameters Description M/C/O
<warrantTIFF> Order (base64-encoded TIFF document as described above) C
<warrantType> Parameters for determining the request format (warrantTIFF or M
warrantTextform) for subscriber data disclosure requests
<warrantDate> Date of the surveillance order in the format YYYYMMDD M
<warrantTargets> List of individual identifiers, numbered consecutively, M
see definition of <warrantTarget>
<legalBases> Legal basis for the surveillance order M
see XSD definition
<warrantTextform> Implementation of the required text form for subscriber data C
requests pursuant to § 113(2) of the TKG, as an alternative to the
TIFF document
<needsConfirmation> If confirmation is still required, e.g. in the case of an urgent C
surveillance order (Sections 1.3.1 and 1.3.6)
<isConfirmation> Flag to confirm, for example, an (urgent) surveillance order C
previously sent with <needsConfirmation> (Sections 1.3.1 and
1.3.6)
<isCorrection> Flag to indicate that the new decision corrects a minor deficiency C
(Sections 1.3.1 and 1.3.6)
WarrantTarget
Parameters Description M/C/O
<targetNumber> Consecutive number identifying the identifier within the metadata M
and requests referring to them
<deactivateTarget> for prematurely terminating individual targets of an active warrant O
for traffic data information warrant
<target> This contains the TelephonyPartyInformation element with related M
data field values from the ETSI XSD, and — if necessary — the
nationalTelephonyPartyInformation parameter with the national
addenda from the XSD module Natparas2
<startDateTime> Start of the time period specified in the surveillance order for this M
identifier, in the GeneralizedTime format
<endDateTime> End of the time period specified in the surveillance order for this M
identifier, in the GeneralizedTime format
<targetType> This field serves to distinguish whether: M
a traffic data disclosure or a surveillance action is requested
for the given identifier,
the traffic data disclosure in combination with the
<usageData> parameter refers to <telephonyService>, <data
service> or a combined request,
the surveillance action in combination with the
<interceptionCriteria> parameter refers to Voice+Data or
IRIOnly.
TR TKÜV, edition 7.2 (draft) Part B, page 111
<interceptionCriteria> Mandatory field for surveillance actions; specifies the potential C
scope of the surveillance action as defined in the surveillance
order (CC+IRI or IRIOnly). The actual scope that will be activated
in this respect is defined by the activation request (this enables, for
example, an existing surveillance order for CC+IRI to be
implemented as an IRIOnly action as deemed appropriate by the
authorised agency).
WarrantTextform
Parameters Description M/C/O
<originator> Name of enquirer. M
<originatorContactDetails> Phone number of enquirer. M
<endOfText> Text field necessary to reveal the closure of the text form. 'This M
document is valid without a signature!' should be entered as a
parameter value.
NationalTelephonyPartyInformation
Parameters Description M/C/O
<countryCode> Value 'DE' M
<headerID> Version number of the national Natparas2 module M
The format of the version number is made up as follows:
ETSI version.TR edition no,
where:
ETSI version: 8 characters,
TR edition: 4 characters,
No: 2 characters.
Example: 01.26.01.07.2.01 means:
01.26.01 07.2 01
ETSI TS 102 657 relevant consecutive numbering for the
version no TR TKÜV NatParas version
01.26.01 edition 7.2
<partyNumberAKUE> The foreign phone number specified in the surveillance order, C
starting with the country code (e.g. 33 for France )
<voipID> VOIP identifier that is not in E.164 format (e.g. C
[email protected]
<lineID> Line identifier or technical key of an Internet gateway C
<userName> Account name of an Internet connection C
<postBoxAddress> Mailbox address or account name of an e-mail box C
<macAddress> MAC address of a terminal used for Internet access in cable C
networks
<ipAddress> Fixed IP address of an Internet connection C
<hostMacAddress> hostMacAddress for WIFI / hotspot C
<mailboxID> For mailbox queries such as retrieve, download, delete e-mails. C
3.2.2.3 Specifications for usageData requests in the national XSD addendum
For traffic data disclosures, the request data for the actual traffic data to be disclosed are sent as part of
the ETSI XSD (e.g. phone number and period for traffic data disclosures).
The national XSD addendum contains, in addition to the basic information in the header (including the
reference to the warrant request and the respective targetNumber), a reference to the requested service
(telephony, data, combined request).
UsageData
Parameters Description M/C/O
<usageData> Indication whether the disclosure of traffic data from the fixed or M
mobile telephony number relates to telephony or to Internet.
Setting both options to true produces a combined disclosure as
defined in Chapter 2.2.3.5.
Possible values:
- telephonyService: true or false
- dataService: true or false
TR TKÜV, edition 7.2 (draft) Part B, page 112
- lateRecordRequest: true or false
- onetouch dialRequest: true or false
A special data request for the disclosure of delayed traffic data
(late records) which will only become available after a waiting
period and after the queried period in the warrant request has
elapsed.
one-touch dialRequest to identify a destination dialling search.
locationCriteria
Parameters Description M/C/O
<retrogradLocation> The requested location data relate to a period prior to the decision M
date.
<anterogradLocation> The requested data refer to the period from the decision date to M
the end date.
typeOfData
Parameters Description M/C/O
<betrieblicheVerkehrsdaten> Traffic data available for operational reasons. C
<bevorrateteVerkehrsdaten> Traffic data stored on the basis of a legal obligation (cf. ‘Act C
introducing a storage obligation and a maximum retention period
for traffic data’).
3.2.2.4 Specifications for the subscriberData request in the national XSD
addendum
For subscriber data disclosures, the request properties for the actual subscriber data to be disclosed are
sent as part of the ETSI XSD (e.g. phone number or name and address).
3.2.2.5 Specifications for the locating request in the national XSD addendum
To disclose responses to requests for determining location in accordance with Section 1.3.5, the
ETSI XSD serves merely as an envelope for transmission and to define the requestNumber; the national
XSD addendum contains the search term. Locating requests are subject to the procedure under
Section 1.3.1. The <referencedRequestNumber> field in the header of the location request links it to the
corresponding warrant request.
If, in addition to the result, information on the structure of the relevant radio cell is also required, this shall
be done separately through an independent radioStructure request.
Locating
Parameters Description M/C/O
<mSISDN> Phone number of the mobile telephony terminal to be located, in C
E.164 format; refer to the stipulations in Section 2.2.3.4
<iMSI> IMSI of the mobile telephony terminal to be located, in C
3GPP TS 09.02 format; refer to the stipulations in Section 2.2.3.4
C
<legalBases> Legal basis for the disclosure C
see XSD definition
<iP> IP address of the connection to be located C
<lineID> Line identifier or technical key of an Internet access path that C
leads to the physical address of the connection
<otherID> Other ID, which in combination with otherIDtype leads to the C
physical address of the port
<otherIDtype> Defines the type of the other ID C
3.2.2.6 Specifications for the radioStructure request in the national XSD
addendum
The parameter userLocalInformation of the ETSI XSD is used for disclosures on the structure of radio
cells.
Only one specification may be contained in the userLocationInformation block in the case of radio cell
disclosure requests.
TR TKÜV, edition 7.2 (draft) Part B, page 113
3.2.2.7 Specifications for the lawfulInterception request in the national XSD
addendum
The different variants of the lawfulInterception request enable the administration of the surveillance
processes transmitted by means of warrant requests, and approved by the undertaking, to be activated,
modified, deactivated or renewed as well as resumed after an interruption.
To this end, one of the ETSI XSD modules described below is inserted.
LawfulInterception
Parameters Description M/C/O
<activation> For activating a cleared surveillance action (warrant request) C
see definition of <Activation>
<renewal> For renewal of a surveillance action; presupposes clearance of a C
further warrant request.
see definition of <Renewal>
<modification> For modifications of a surveillance action, if this does not require a C
surveillance order (e.g. change of the forwarding address)
see definition of <Modification>
<deactivation> For early deactivation of a surveillance action C
see definition of <Deactivation>
Activation
Parameters Description M/C/O
<target> identifier to be monitored M
For this parameter, the telephonyPartyInformation
parameter of the ETSI XSD is used
<lIID> Contains the LIID to be used. C
Obligated undertakings expressly permitted by the Federal
Network Agency to use the LIID because of their older
transmission equipment shall report the actually activated LIID in
the response message.
<interceptionCriteria> Details of the scope of surveillance, M
see definition of <InterceptionCriteria>
<monitoringCenter> Details of the forwarding targets, M
see definition of <MonitoringCenter>
<startDateTime> 2 Time of the proposed activation of the action, in GeneralizedTime C
format. Non-specification indicates immediate activation
<endDateTime> 2 Time of proposed deactivation, in GeneralizedTime format. M
2 These values may differ from the original values defined in the warrant request but must be within the time period
defined by these original values.
Renewal
Parameters Description M/C/O
<lIID> LIID of the action M
<endDateTime> The new end time, in GeneralizedTime format M
Modification
Parameters Description M/C/O
<lIID> LIID of the action M
<newLIID> New LIID, if it is to be changed C
<newInterceptionCriteria> New data for the InterceptionCriteria field, if the scope of the C
surveillance action is to be changed
<newMonitoringCenter> New data for the MonitoringCenter field, if the forwarding targets C
are to be changed
Deactivation
Parameters Description M/C/O
<lIID> LIID of the action M
<endDateTime> Time of proposed deactivation, in GeneralizedTime format. Non- C
specification of this parameter indicates immediate deactivation
InterceptionCriteria
Parameters Description M/C/O
<interceptVoice> 1 indicates whether the telephony service is to be monitored M
TR TKÜV, edition 7.2 (draft) Part B, page 114
<interceptData> 1 indicates whether the Internet access service is to be monitored M
<interceptIdlemodeHandover> indicates whether handovers of a mobile telephony terminal are to C
be monitored even in idle mode
1 A false value for both parameters indicates an IRIOnly action.
MonitoringCenter
Parameters Description M/C/O
<destinationNumber> HI3 forwarding target for ISDN-based voice forwarding, format C
E.164
<ipAddress> HI2 and HI3 forwarding target for IP-based voice forwarding as C
well as data, the respective port results from Part A of the TR
TKÜV
<ftpAddress> IP address of the HI2 forwarding target in the case of FTP C
forwarding
<ftpUsername> FTP user name of the HI2 forwarding target C
<ftpPassword> FTP password of the HI2 forwarding target C
3.3 Description of the national XML module ‘Natparas3’ (for responses)
This Appendix contains the XML description of the national module ‘Natparas3’, used to transmit
additional response data (e.g. for locating mobile telephony terminals) in the response message.
As this XML description will be subject to updates with new additional parameters, this Appendix only
reflects the state of affairs at the time of publication of the relevant edition of the TR TKÜV. The Federal
Network Agency will coordinate proposed new parameters with the parties involved and will then update
the XML module. The current version of the XML description of the national parameters as well as the
provisions below for the individual parameters will be made available from time to time for download on
the website of the Federal Network Agency (www.bundesnetzagentur.de/tku) after consultation.
3.3.1 Specification of additional data in the national XML module
Natparas3
The Natparas3 module is defined for the following usage modes:
Transmission of responses on determining the location of mobile terminals (locatingResult type)
and the structure of radio cells (radioStructureResult type);
here, the ETSI ResponseMessage merely serves as a transmission envelope.
Transmission of supplementary responses on disclosing subscriber data;
depending on the scope of the request, the ETSI ResponseMessage may either serve merely as
an envelope for transmission or else contain supplementary information.
Transmission of confirmation of activation or change messages for implementing surveillance
actions (lawfulInterceptionResult type);
here, the ETSI ResponseMessage merely serves as a transmission envelope.
This transmission serves as an administrative-level response and replaces the HI1 messages as
described in Part A of Appendix A.3 of the TR TKÜV; it can then optionally be deactivated by the
subject undertaking.
3.3.2 Specification of additional data in the national XML module
Natparas3
The XML module Natparas3 is inserted in the NationalResponsePayload field of the RequestMessage,
and is structured as follows:
3.3.2.1 Specifications for the header
NationalResponsePayload
Parameters Description M/C/
O
<countryCode> Value 'DE' M
<headerID> Version number of the national Natparas3 module M
The format of the version number is made up as follows:
ETSI version.TR edition no,
TR TKÜV, edition 7.2 (draft) Part B, page 115
where:
ETSI version: 8 characters,
TR edition: 4 characters,
No: 2 characters.
Example: 01.26.01.07.2.01 means:
01.26.01 07.2 01
ETSI TS 102 657 relevant consecutive numbering for the NatParas version
version No TR TKÜV
01.26.01 edition 7.2
<additionalInformati Free text for additional information from the obligated undertaking with O
on> respect to the disclosure
<additionalDocument> Possibility of transmitting an additional document as a supplement O
<responseDetails> Here, the possible application modules are specified. M
The additionalInformation field may (similarly to Section 2.2.5) be completed with various items of
information, as described below:
<Info> <List>
<Info> <Comment>
<Info> <List>;<Comment>
<List> <ListItem>
<List> <ListItem>;<List>
<ListItem> „<Feldname>“=„<FeldWert>“
<Comment> COMMENT=<text>
The above identifiers in pointed brackets are designated non-terminals. Any strings are permissible for
the parameters <field name>, <field value> and <text>.
Where double inverted commas or backslash characters are shown in the case of the parameters <field
name> and <field value>, these characters shall each escape via a backslash.
The <Comment> parameter additionally permits comments in free text to the network operator-specific
fields.
An example without free text:
”Criterion sought“=”12345“;”Period“=”01.05.2015 00:00:00 – 02.05.2015 23:59.59-”;”Carrier Id”=”66221”
The same example using free text:
”Criterion sought“=”12345“;”Period“=”01.05.2015 00:00:00 – 02.05.2015 23:59.59-”;”Carrier
Id”=”66221”;COMMENT=The cell information was already partially deleted because the data are more
than 7 days old.
The free text field "otherInformation" of ETSI-XSD is to be used for missing parameters according to
Section 2.2.5.
responseDetails
Parameters Description M/C/O
<locatingResult> for the results of locating procedures for mobile telephony C
terminals; if several SIM cards have been assigned to the
identifier, this parameter shall be specified for each SIM card and
transmitted as a separate <locatingResult> each time in the
<responseDetails>
<radioStructureResult> for responses to requests for the structure of radio cells, with the C
specific data requested defined in the ETSI XSD
<lawfulInterceptionResult> for responses to activation/change/deactivation of a surveillance C
action, after the surveillance order itself has been transmitted
<rejectedTargets> Rejected targets should be stated here. If several targets have C
been rejected, the element <RejectedTargetNumber> is to be
used accordingly
TR TKÜV, edition 7.2 (draft) Part B, page 116
3.3.2.2 Specifications for the rejectedTargets in the national XSD addendum
rejectedTargets
Parameters Description M/C/O
C
<rejectedTargetInfo> For numbering of rejected targets and communication of the M
reason.
3.3.2.3 Specifications for the locatingResult in the national XSD addendum
For applications of type locating, one locatingResult per SIM card is defined. If several SIM cards have
been assigned to the identifier specified in the locating request, then the locatingResult parameter with
the respective response parameters is defined in the headers for each individual SIM card.
locatingResult
Parameters Description M/C/O
<mSISDN> Phone number of the mobile telephony terminal to be located, C
in E.164 format pursuant to Section 2.2.3.4
<iMSI> IMSI of the located SIM in 3GPP TS 09.02 format, format C
pursuant to Section 2.2.3.4
<iMEI> IMEI of the located mobile telephony terminal in C
3GPP TS 09.02 format, format pursuant to Section 2.2.3.4
<loginStatus> Reference to the state of the mobile terminal C
(attached/registered or detached/unregistered)
<detachReason> Reason for deregistration as free text, e.g. ‘Switched off by C
subscriber’
<vLR> VLR identifier in E.164 format, C
Format as defined in Section 2.2.3.4
<mME> Mobility Management Entity C
Use analogous to VLR identifier
<lastRadioContact> Time of last radio contact in GeneralizedTime format, format as C
defined in Section 2.2.3.1
<transmitterDetails> Reference to the network technology (GSM or UMTS) C
see definition in the ETSI XSD
(TransmitterTechnology parameter)
<userLocationInformation> in 3GPP TS 09.02 format, C
Format as defined in Section 2.2.3.4
<extendedLocation> For transmission of the geographical coordinates of the aerial C
location
see definition in the ETSI XSD (ExtendedLocation
parameter) as defined in Section 2.2.3.2
<postalLocation> Postal address of the location of the antenna, where postal C
addresses are used in addition to geographical coordinates
see definition in the ETSI XSD (postalLocation
parameter)
<subscribedTelephonyServices> In order to make queries that do not relate to a location, but to C
a person, such as for IP address information.
The indication ‘conditional’ refers to the scope of the legal basis for the request.
3.3.2.4 Specifications for the radioStructureResult in the national XSD
addendum
radioStructureResult
Parameters Description M/C/O
<radiationPattern> graphical representation of the theoretical coverage area (base64- M
encoded TIFF document )
<userLocationInformation> Contains cell information like cell ID, LAC, ECI etc. O
<azimuth> Main beam direction O
<antennaType> Antenna type O
3.3.2.5 Specifications for the lawfulInterceptionResult in the national XSD
addendum
lawfulInterceptionResult
Parameters Description M/C/O
<lIID> Reference number M
<begin> Activation time of the surveillance action C
TR TKÜV, edition 7.2 (draft) Part B, page 117
Date and time in GeneralizedTime format as described in Section
2.2.3.1
<end> Deactivation time of the surveillance action C
Date and time in GeneralizedTime format as described in Section
2.2.3.1
<modification> Modification time of the surveillance action C
Date and time in GeneralizedTime format as described in Section
2.2.3.1
3.3.2.6 Specifications for the subscriberDataResult in the national XSD
addendum
The disclosure of subscriber data relates to the special subscriberDataRequest as described in
Section 3.2.2.4 and always takes place within the ETSI XSD. To produce the reference to the request, the
header as defined in Section 3.3.2.1 must also be transmitted.
For the actual disclosure of a subscriberDataRequest with respect to telephony, the TelephonySubscriber
parameter of the ETSI XSD is used, which contains an option to specify several contracts (e.g. contracts
for different mobile telephony numbers) in a single response. Disclosure of the billingMethod,
bankAccount, and billingAddress or contractPeriod features is also done within the ETSI XSD.
The NationalResponsePayload field is not suitable for the transmission of supplementary data for
individual contracts or mobile telephony numbers since it can only be used once per response.
Accordingly, to report contract-specific supplementary data, the nationalTelephonySubscriptionInfo field in
the TelephonySubscriber parameter of the ETSI XSD needs to be supplemented as follows:
nationalTelephonySubscriptionInfo
Parameters Description M/C/O
<countryCode> Value 'DE' M
<headerID> Version number of the national Natparas3 module M
The format of the version number is made up as follows:
ETSI version.TR edition no,
where:
ETSI version: 8 characters,
TR edition: 4 characters
No: 2 characters
Example: 01.26.01.07.2.01 means:
01.26.01 07.2 01
ETSI TS 102 657 relevant consecutive numbering for the
version no TR TKÜV NatParas version
01.26.01 edition 7.2
<pIN> PIN of the target identifier C
<other> Free text for reporting on other requests as defined in the <other> C
parameter of the subscriberDataRequest
The excerpt from the ETSI XSD given below shows the structure of the TelephonySubscriber parameter
with various options for disclosure of subscriber data.
TelephonySubscriber ::= SEQUENCE
{
subscriberID [1] TelephonySubscriberId OPTIONAL,
-- unique identifier for this subscriber, e.g. account number
genericSubscriberInfo [2] GenericSubscriberInfo OPTIONAL,
-- generic personal information about this subscriber
[...]
subscribedTelephonyServices [4] SEQUENCE OF SubscribedTelephonyServices
OPTIONAL,
-- a subscriber (or account) may have more than one service listed against them
...,
nationalTelephonySubscriberInfo [5] NationalTelephonySubscriberInfo OPTIONAL
-- To be defined on a national basis
-- Only to be used in case the present document cannot fulfil the national
requirements
}
TR TKÜV, edition 7.2 (draft) Part B, page 118
SubscribedTelephonyServices ::= SEQUENCE
{
[...]
timeSpan [3] TimeSpan OPTIONAL,
-- Start and end data, if applicable, of the subscription
registeredNumbers [4] SEQUENCE OF PartyNumber OPTIONAL,
-- The set of telephone numbers registered for this service
[...]
iMSI [9] IMSI OPTIONAL,
pUKCode [13] UTF8String OPTIONAL,
pUK2Code [14] UTF8String OPTIONAL,
iMEI [15] SEQUENCE OF IMEI OPTIONAL,
nationalTelephonySubscriptionInfo [16] NationalTelephonySubscriptionInfo
OPTIONAL,
-- To be defined on a national basis
-- Only to be used in case the present document cannot fulfil the national
requirements
paymentDetails [17] PaymentDetails OPTIONAL
}
Excerpt from the ETSI XSD TS 102 657
3.3.2.7 Labelling data sets by origin
A selection must be made in the parameter NationalRecordPayload for each data set as to whether the
data are disclosed pursuant to § 96 or § 113b of the TKG. Equally, the obligation under § 113c(3)
sentence 2 of the TKG is fulfilled as a result.
NationalRecordPayload
Parameters Description M/C/O
<countryCode> Value 'DE' M
<headerID> See also Section 3.2.2.1 M
<typeOfData> Identification of the data origin (operational or stocked traffic data) M
typeOfData
Parameters Description M/C/O
<betrieblicheVerkehrsdaten> Traffic data available for operational reasons. C
<bevorrateteVerkehrsdaten> Traffic data stored on the basis of a legal obligation (cf. ‘Act C
introducing a storage obligation and a maximum retention period
for traffic data’).
RejectedTargetInfo
Parameters Description M/C/O
<rejectedTargetNumber> For numbering of rejected targets M
<rejectedTargetErrorMessage> Text field for communicating the reason for rejection in a few O
words.
4 Transmission of accounting information or submitting claims for
compensation pursuant to § 23(1) of the German Judicial
Remuneration and Compensation Act
4.1 Basic principles
This section describes the technical details of the optional secure electronic transmission of accounting
information or making claims for compensation in preparation of the actual compensation pursuant to
§ 23(1) of the German Judicial Remuneration and Compensation Act.
4.2 Methods of electronic transmission
The method uses the ETSI Specification TS 102 657 as well as the provisions stipulated in this part of the
TR TKÜV.
Transmission enables the obligated undertakings to send the accounting information for a particular
period, as defined in § 23(1) of the German Judicial Remuneration and Compensation Act, to the relevant
authorised agencies for settlement. The accounting information comprises the processed
TR TKÜV, edition 7.2 (draft) Part B, page 119
RequestNumbers (e.g. of a traffic data disclosure or identifier activation) and the cost and discount tariffs
applied by the obligated undertaking.
The standardised transmission of this accounting information enables authorised agencies to
automatically reconcile it with their own data. The subsequent steps (confirmation, discussion of
discrepancies, etc.) are not part of this interface due to the large variety involved.
The accounts data is transmitted with the national XML module Natparas2, which has to be inserted in
the field NationalRequestParameters of the RequestMessage.
4.3 Description of the national XML module ‘Natparas2’ (for accounts
data)
This section contains the description of the XML elements used to transmit accounting information from
the obligated undertakings to the authorised agencies in a request message. Here, the ETSI
RequestMessage merely serves as an envelope for transmission. A response message for this
application is not in place.
The provisions of Section 2.2 apply accordingly to transmission via HTTP and error handling.
As this XML description will be subject to updates with new additional parameters, this Appendix only
reflects the state of affairs at the time of publication of the relevant version of the TR TKÜV. The Federal
Network Agency will coordinate proposed new parameters with the parties involved and will then update
the XML module accordingly. The current version of the XML description of the national parameters as
well as the provisions below for the individual parameters will be made available from time to time for
download on the website of the Federal Network Agency (www.bundesnetzagentur.de/tku) after
consultation.
Determining the supplementary data
Compensation
Parameters Description M/C/O
<compensationName> Free text for unambiguous description of accounting information M
(e.g. for a specific month with consecutive number for
retransmission after correction)
<compensationItem> see 4.3.1.1 M
Stipulations regarding the CompensationItem parameter
CompensationItem
Parameters Description M/C/O
<requestNumber> The RequestID for which compensation is to be claimed (e.g. a M
traffic data disclosure or for activation of a surveillance action)
<groupID> This designates RequestIDs that are settled as a group in M
accordance with the provisions of § 23(1) of the JVEG 1
<jVEG2017> Selection field in the national module for the cost tariff number, M
e.g. 'JVEG Number 102'
<rebate> Designation of whether the tariff includes a 20 % rebate due to a
central contact point
Possible values:
- Rebate included: true
- Rebate not included: false
<quantity> Quantity or multiplier of the tariff 2 M
<price> Final tariff for the relevant RequestID, including any rebates and M
multiplier
<comment> Free text for additional comments O
1 For example, if eight IP addresses are requested in the same procedure (No 201 pursuant to Appendix 3 of § 23(1)
of the German Judicial Remuneration and Compensation Act), the eight RequestIDs corresponding to the individual
requests shall be listed, using the same groupID. The tariff as defined in § 23(1) of the German Judicial
Remuneration and Compensation Act shall be specified for a single RequestID only; for the other RequestIDs, an
amount of ‘0’ shall be specified.
2 This will normally be ‘1’. In volume-based invoices (e.g. for compensation of management costs pursuant to
point 104), the required multiplier shall be specified as an integer value.
TR TKÜV, edition 7.2 (draft) Part B, Appendix A, page 120
Appendix A.1 Explanatory notes on the procedure
Appendix A contains further explanations and illustrations of the procedure.
Example data sets for the various instances of usage and the current versions of the national XML
modules Natparas2 and Natparas3 can be downloaded from our website www.bundesnetzagentur.de/tku.
Appendix A.1.1 Fundamental flow of communication
The figures below explain the basic uses of the interface; they complement the descriptions in
ETSI TS 102 657.
Division into system, sender and recipient:
a) Successful transmission of a request
berechtigte Stelle Authorised agency
Req Req
System bSt AA system
Sender Sender
ReqAck ReqAck
Empfänger Recipient
XML-Schema Prüfung erfolgreich XML schema check successful
SINA= VPN über Internet SINA= VPN via Internet
Req über HTTP Req via HTTP
HTTP 200 (OK) HTTP 200 (OK)
ReqAck über HTTP ReqAck via HTTP
Verpflichteter subject
System Verpfl. subject system
automatische Checks automatic checks
manuelle Checks nach ReqAck manual checks after ReqAck
TR TKÜV, edition 7.2 (draft) Part B, Appendix A, page 121
b) Successful transmission of a response
berechtigte Stelle Authorised agency
Res Res
System bSt AA system
ResAck ResAck
Empfänger Recipient
XML-Schema Prüfung erfolgreich XML schema check successful
Sender Sender
SINA= VPN über Internet SINA= VPN via Internet
Res über HTTP Res via HTTP
HTTP 200 (OK) HTTP 200 (OK)
ResAck über HTTP ResAck via HTTP
Verpflichteter Subject
System Verpfl. Subject system
c) Transmission of a faulty message (error 5.1.5.3)
The figure shows an example of a faulty request message. This error can occur with any type of
message (Req, ReqAck, etc.).
berechtigte Stelle Authorised agency
Req Req
System bSt AA system
Sender Sender
TR TKÜV, edition 7.2 (draft) Part B, Appendix A, page 122
Empfänger Recipient
SINA= VPN über Internet SINA= VPN via Internet
Req über HTTP Req via HTTP
HTTP 422 (Unprocessable Entity) HTTP 422 (Unprocessable Entity)
Verpflichteter Obligated party
Empfänger Recipient
XML-Schema Prüfung nicht erfolgreich XML schema check successful
System Verpfl. Subject system
TR TKÜV, edition 7.2 (draft) Part B, Appendix A, page 123
d) Successful transmission of a request and multi-part response as defined in Section 5.2.3
of the ETSI TS 102 657
berechtigte Stelle Authorised agency
Req Req
Sender Sender
ReqAck ReqAck
Empfänger Recipient
XML-Schema Prüfung erfolgreich XML schema check successful
SINA= VPN über Internet SINA= VPN via Internet
Req über HTTP Req via HTTP
TR TKÜV, edition 7.2 (draft) Part B, Appendix A, page 124
HTTP 200 (OK) HTTP 200 (OK)
ReqAck über HTTP ReqAck via HTTP
Verpflichteter Subject
System Verpfl. Subject system
automatische Checks automatic checks
manuelle Checks nach ReqAck manual checks after ReqAck
Ermittlung der Daten Data production
System bSt AA system
Reslnc Reslnc
ReslncAck ReslncAck
Reslnc über HTTP ResInc via HTTP
ReslncAck über HTTP ResIncAck via HTTP
Res Res
ResAck ResAck
Res über HTTP Res via HTTP
ResAck über HTTP ResAck via HTTP
Appendix A.1.2 Stipulations regarding participation in the IP VPN using a
cryptosystem
General
To protect the IP-based transmission point, dedicated cryptosystems based on the IPSec protocol family
are used to connect the subnets of the authorised agencies and subjects into a Virtual Private Network
(VPN). To administer the cryptographic keys used for authentication, a Public Key Infrastructure (PKI) is
set up, for which the Federal Network Agency operates as the central certification and registration
authority. In addition, the Federal Network Agency administers the possible security relationships in an
Access Control List (ACL) made available via a directory service.
The cryptosystems are positioned as dedicated systems before the subnets of authorised agencies and
subjects which they are intended to protect. These systems ensure authentication, integrity, and
encryption.
More extensive mechanisms to protect the transmission point, such as measures against denial of
service attacks on authorised agencies, are addressed only to a limited extent by cryptosystems and
should be independently resolved by the operator of the relevant subnets.
The relevant cryptosystems are essentially components of the technical systems of the authorised
agency or the subject; therefore, their operation (e.g. operation of a syslog server) and maintenance and
troubleshooting are the responsibility of the operator of the relevant subnet.
The requirements for cryptosystems should be updated in future to reflect the current state of the art in
order to ensure continued protection. The relevant extensions (e.g. use of different key lengths) or
necessary short-term changes in the existing implementations in case of security issues arising later
should be implemented by the operator of the relevant cryptosystem within a period laid down for each
case individually - in the context of extensions or updates made available by the manufacturer of the
cryptosystem - according to the requirements set by the Federal Network Agency.
Network architecture
The cryptosystems of the authorised agencies and the subjects constitute a meshed network, where
directed security relationships (point-to-point connections) are created between the telecommunication
systems of the subjects and the subnets of the authorised agencies. Connections between the subjects
are not permitted.
The required certificate keys for authentication of cryptosystems are created by the Federal Network
Agency and, after registration, stored on the smart card of each cryptosystem as supplied by the operator
of the relevant subnet. The keys used to encrypt the transmitted data are created by the cryptosystems
themselves for each active VPN.
After the cryptosystems are put into operation, they autonomously set up a secure connection to the
directory service at the Federal Network Agency in order to retrieve the current ACL. Further update
processes for the ACL either take place automatically or are controlled by the Federal Network Agency.
The log data created by the cryptosystems (e.g. a successful ACL update, failure) are sent to the log
server of the subject or the authorised agency in the standard syslog format (UDP port 514) for further
processing.
TR TKÜV, edition 7.2 (draft) Part B, Appendix A, page 125
Design of the Internet access or transmission point
To ensure unambiguous addressing of VPN endpoints and of sending and receiving systems on the
connection used to transmit the surveillance copy or the IRI as well as the data as referred to in Part B,
public IP addresses are used. In case of existing intranet configurations, separate tunnelling should
typically be employed to fulfil the security requirements. However, various different network configurations
are possible in principle.
The above requirements should be taken into account when describing the design of the Internet access
or transmission point in connection with the submission of the concept.
Use scenarios and procedures
In normal situations, cryptosystems are a fixed component of subnets and are identified unambiguously in
the ACL, inter alia, by their IP configuration. After registration and key creation, the directory service is
updated.
A list of data needed to administer the ACL, together with a description of the total process (policy), is
made available to all participants in the procedure.
The concept should mention all the relevant details (e.g. the proposed IP address for the transmission) to
enable the ACL to be maintained appropriately.
Other provisions and guidelines for participation in an IP VPN
In addition to the above provisions for participation in an IP VPN, the following normative individual
provisions and guidelines apply:
Rules for the Registration and Certification Authority TKÜV-CA of the Federal Network Agency,
Section IS16 (Policy)
Appendix X.3 reflects the status of these rules at the time of publication of this edition of the TR
TKÜV.
Guideline document ‘Integration of IP cryptosystems into the network infrastructure of subjects
and authorised agencies’
Application for participation in the IP VPN for subjects and authorised agencies (Registration and
technical description of the infrastructure of the subnet with IP addresses and a selection of
options)
These documents are available for download from the website of the Federal Network Agency, in the
section on telecommunications, under the keyword ‘Technical Regulation of Telecommunications’ /
‘Technical Implementation of Surveillance Actions’.
Table of suitable IP cryptosystems
The systems fulfilling the basic technical system and interoperability requirements are listed in the
following table.
The updated table is published on the download site of the Federal Network Agency
(www.bundesnetzagentur.de/tku).
No Manufacturer Product name Contact person
1 secunet Security Networks AG SINA Box Division Public Authorities
Ammonstraße 74 E-mail:
[email protected]
01067 Dresden Tel.: 0201 5454-0
www.secunet.com
TR TKÜV, edition 7.2 (draft) Part B, Appendix B, page 126
Appendix B E-Mail-ESB transmission procedure
This Appendix describes the national requirements for the E-Mail-ESB transmission method.
1. Basic description of the procedure
The use of the E-Mail-ESB transmission procedure is governed by Sections 1 to 3 of this part of the TR
TKÜV.
Before using the E-Mail-ESB transmission procedure, once the authorised agency has been notified of
the presence of a surveillance order or other request, the requesting authorised agency and subject must
first exchange their public keys for use in the encryption procedure. It is not envisaged holding the keys
centrally for this procedure, e.g. via a key server. The subject must ensure that the key he/she transmits
comes from the requesting authorised agency, e.g. by means of a phone verification of the fingerprint.
As well as the surveillance order or other request, the authorised agencies may transmit notes on the
requested traffic data (e.g. direct line search, real time forwarding) and the request periods (times of
disclosure, redelivery of late records after expiry of the ordered period) to facilitate processing. The
processing is governed basically by the relevant material concerning the ETSI-ESB transmission
procedure.
When deploying the E-Mail-ESB transmission procedure, only those software solutions should be used
which allow an encryption procedure in accordance with the OpenPGP procedure specified by RFC4880
in hybrid application. The OpenPGP Standard supports the most common cryptosystems and algorithms.
Its use requires asymmetric RSA encryption with a key length of at least 4 096 bits and symmetric AES
encryption of at least 256 bits. The recording lines of the authorised agencies must support these
processes.
Other encryption procedures using proprietary PGP or other end-to-end encryption methods are not
permitted. Where confidential documents have to be transmitted by the authorised agency (e.g. a court
order deemed a classified document), it is the authorised agency’s duty to select a dedicated encryption
of this document (e.g. using Chiasmus encryption software) and transmit it by the E-Mail-ESB after
agreement with the undertaking concerned. The encryption process by the OpenPGP Standard is not
affected by this.
If the E-Mail-ESB transmission process is not integrated into the query system, the connection between
the query system and E-Mail-ESB must have transport protection in accordance with Section 4.1 of the
requirements catalogue pursuant to § 113f of the TKG. Data transport between the facilities by data
carrier (e.g. USB stick) is not permitted. Moreover, the requirement for automatic logging pursuant to § 35
of the TKÜV must also be ensured.
As regards protection prior to access from the Internet, the following applies for the subjects:
the hardware and software component used for the E-Mail-ESB transmission procedure must not
be used for any other purposes;
the E-Mail-ESB transmission procedure must be disengaged from the Internet after use; and
a firewall must be installed between the E-Mail-ESB transmission procedure and the Internet
connection.
In addition, the plain data arising in the E-Mail-ESB transmission procedure must be deleted from RAM
after transmission. Outsourcing to a hard drive or, for example, into a file for "Sent items" or similar must
also be prevented (Section 3.2.2 in Part B).
According to § 113c(3) sentence 2 of the TKG, traffic data which were saved pursuant to § 113b of the
TKG are to be labelled during transmission to the authorised agency. This necessitates labelling each
individual set of traffic data with the syntax ‘tKG113b’. Traffic data stored by companies for transmission
is to be labelled with the syntax ‘tKG96’.
Upon transmission of the surveillance order or in a separate e-mail, authorised agencies can specify the
disclosure of delayed traffic data (late records) which will only become available after a waiting period and
after the queried period has elapsed. The waiting period to be agreed with the Federal Network Agency
has to be long enough for late records to be regularly recorded completely. Disclosure of these late
records takes place after this waiting period and includes, where appropriate, all the traffic data stored at
this point for the entire period. This specification may be withdrawn by the authorised agencies in a fresh
e-mail.
TR TKÜV, edition 7.2 (draft) Part B, Appendix B, page 127
Format of the order
The order shall be converted into the multipage TIFF format (CCITT Group 4 Fax) for transmission. The
maximum file size is 5 MB. If a follow-up order does not contain all the required data (e.g. legal basis,
identifier, period), it must be transmitted in a single file together with the original order.
TR TKÜV, edition 7.2 (draft) Part X, Appendix X.1, page 128
Part X Informative Appendix
Part X contains the proposed changes to the TR TKÜV which should serve as a basis for discussion of
the next edition, as well as additional information on the various Appendices to this publication.
Appendix X.1 Proposed changes to the TR TKÜV
This Annex is non-mandatory as defined in § 110(3) of the TKG. It is merely intended to provide
information on future planned changes that only became necessary after this edition has been completed
or will be necessary once international standards currently being worked on are completed or relevant
services or technologies are launched. Such proposed changes should be coordinated in preparation for
the next edition of the TR TKÜV.
In the context of furnishing proof pursuant to § 110(1) point 3 of the TKG, the Federal Network Agency
will approve any implementations produced on the basis of this informative Annex as technically correct.
The proposed changes have been inserted into the relevant copied text segment and marked as such by
means of bold italics and underlining.
Annex X.1.1 Forwarding packet-switched voice services (e.g. VoLTE)
Against the backdrop of the imminent discontinuation of ISDN-based forwarding and the current lack of
coupling between access network and IMS in mobile telecommunications, the following schedule for
forwarding packet-switched voice services (e.g. VoLTE) has been agreed and shall be implemented on
the basis of the available 3GPP specifications. The current regulations described below (stage 1) also
apply to corresponding services provided by mobile virtual network operators (MVNOs) that provide their
services (e.g. VoLTE) independently of the access network. In this case, the IMS operator (generally the
MVNO) shall forward the VoIP portion and the EPS Service Gateway operator (usually the operator of the
mobile telecommunications access network used) shall forward the LocationInformation. The information
is correlated as follows.
Step Description Time limitation
1 Actual state
The two sets of information shall be forwarded concurrently in accordance
with 3GPP TS 33.108 and ETSI TS 102 232-5:
ETSI TS 102 232-5 for the VoIP portion according to Annex H
3GPP TS 33.108 as IRI-only for the LocationInformation according to
Annex D
They may be correlated by LIID and timeStamp; the CIN is not
correlated between the two forwarded portions
The form of the dual forwarding shall be tolerated under the following
circumstances:
1. The timeStamp information must be correct
2. For all services and service attributes (e.g. multi-SIM), unambiguous
correlation using LIID, timeStamp and optionally IMSI must be
possible. This may need explaining in the plan
3. The forwarding of the LocationInformation must be reported with the
timeStamp at which the information became known to the network;
the information must be forwarded immediately after this event
4. It must be possible for the LocationInformation to also be provided
solely to terminals in stand-by mode when ordered, and thus for the
requirement under § 7(7), No 7, second clause of the TKÜV to be
met.
2 Use of 3GPP TS 33.128 modules only
The use of ETSI TS 102 232-5 shall be replaced by the use of the
corresponding 3GPP TS 33.128 modules designed for the respective
services.
The necessity described in stage 1 of the dual forwarding according to
3GPP TS 33.128 from the access network as well as the IMS with the
TR TKÜV, edition 7.2 (draft) Part X, Appendix X.1, page 129
correlation via LIID and timeStamp will continue to apply here and will be
linked to the same conditions.
Appendix X.1.2 Security requirements
Under § 14(1) TKÜV, the subject must, among other things, use state-of-the-art technology to prevent
unauthorised use of the measures it must take to technically implement orders, in particular the technical
equipment for controlling the surveillance functions and the transmission point under § 8 TKÜV, including
the intermediate transmission paths. Pursuant to § 36(1) TKÜV, technical features to this end may be set
out in the TR TKÜV.
In a future edition, the Federal Network Agency is planning appropriate provisions covering the
surveillance function in the STS, the equipment for controlling the surveillance functions, the handover
point and the intermediate transmission paths.
In addition to basic security standards and BSI technical guidelines, the Federal Network Agency will also
consider the various ETSI specifications (e.g. ETSI TS 103 308 and 103 487) in these provisions. Once
the relevant security requirements have been fully drawn up, the corresponding specifications shall be
included in the TR TKÜV as references.
On the basis of these provisions, a questionnaire shall be developed. This will need to be completed as
part of the required documents for the evidence notice and in it the subject shall describe the anticipated
risks related to the cited systems, equipment and transmission paths and the specific protective
measures taken, as with the procedure under § 109(4) TKG.
In line with the risk assessment to be carried out, specific requirements are desired for certain risks, e.g.
for:
systems, equipment and transmission paths not located on the subject’s property or in the same
country;
systems, equipment and transmission paths for which sufficient IT security measures are
currently not possible and so need supplementing with increased physical security measures.
To solve this issue, a special work group is scheduled to be convened.
Appendix X.1.3 Future requirements for mobile telecommunications, in particular
5G
Future network technologies may present new challenges in terms of compliance with statutory
requirements for telecommunications surveillance. These challenges need to be recognised and require
possible solutions. This informative annex is intended to describe new technologies and set out the
problems or challenges that may occur in line with current knowledge in order to raise awareness of these
issues among manufacturers, network operators and authorised agencies as early as in the development
stage, and to develop possible solutions for the future TKÜ via the standardisation route.
The aim is also to make it possible to revert to standardised solutions for new network technologies by
describing the technical implementations in this guideline. Otherwise, specific national solutions would
need to be devised, and these could lead to significantly higher costs due to the individual nature of their
implementation.
Currently, the technical requirements are being developed for the new mobile telecommunications
standard, 5G. At the same time, the LI requirements are also in the process of being standardised.
Fundamentally, the surveillance functionalities must comply with statutory requirements even in future
networks, although lower quality or more complex analysis must be anticipated due to stronger
encryption.
In the following, certain aspects of the development we are already aware of will be described, and
comments will be made on particularly challenges posed by future surveillance functions:
- ID recognition
Where possible, IDs in 5G should be routed using pseudonyms that cannot be traced back to the user
(keyword ‘privacy’). In this case, for LI all LI-relevant interfaces will in future have to be designed such
that the pseudonymised identities can be reassigned to a user. In roaming situations too, operators will
TR TKÜV, edition 7.2 (draft) Part X, Appendix X.1, page 130
have to take account of the required mechanisms at the interfaces in terms of transmission and
recognition mechanisms.
- Network slicing
5G network slicing will allow network operators to divide individual physical networks into several virtual
networks in which the network slices can be retrieved as necessary. In future, therefore, networks will be
able to be implemented across countries. As a result, issues may arise in terms of data security/integrity
when executing a judicial order. For example, target lists may be managed abroad, or entire network sub-
services may be rented by foreign operators.
When designing services abroad, network operators shall be responsible for implementing the security
requirements and forwarding in accordance with German law.
- NFV - Network Functions Virtualisation
With the introduction of Network Functions Virtualisation under 5G, operators are given the opportunity to
implement their networks in a virtual environment and thus become less reliant on hardware. It should be
ensured that the use of Network Functions Virtualisation does not restrict the proper functioning of LI.
Note on location data:
In the case of other or future networks (e.g. 5G), it has to be ensured that the location information so far
provided and now available on the entire network will be reported even if standardisation has not included
transporting this information to the core network or the recording points for event data.
TR TKÜV, edition 7.2 (draft) Part X, Appendix X.2, page 131
Appendix X.2 Assignment of identifiers for authorised agencies to ensure
uniqueness of reference numbers
Basic principles
Pursuant to Section 7(2) sentence 1 of the TKÜV, every subject company should designate every
surveillance copy transmitted by means of the reference number of the respective surveillance action as
prescribed by the authorised agency, if this copy is transmitted to the authorised agency via
telecommunications networks with transmission capabilities.
Pursuant to the Technical Guideline for the implementation of legal measures for surveillance of
telecommunications (TR TKÜV) and the underlying ETSI and 3GPP Specifications, the reference number
should be composed of a maximum of 25 characters.
The permitted character subset consists of all upper-case and lower-case letters ‘a’…‘z’, ‘A’…‘Z’ (without
umlauts), all digits and the characters ‘-’, ‘_’ and ‘.’. However, when using ISDN stubs for transmission of
the copy of the content, only the digits ‘0’ to ‘9’ are permitted.
Depending on the implementation of the ETSI interface and the associated change in administrative area,
preallocation of the reference number by authorised agencies is now possible in most cases.
Possible problem cases
On the other hand, many network elements depend on different actions not being administered with
identical reference numbers. In practice, situations where the same reference number has been assigned
by different authorised agencies may lead to ambiguities and therefore potential technical errors in the
surveillance technology when matching and transmitting surveillance copies. As a consequence, there
could in some cases be a partial or complete failure to forward copies of the content to authorised
agencies.
Ensuring uniqueness of reference numbers
To ensure uniqueness and thereby an error-free operation of transmission devices, an additional
parameter is needed as part of the reference number. This identifying parameter ensures differentiation of
the authorised agencies, who in turn assign the remaining positions of the reference number
independently to uniquely identify the surveillance action.
To ensure the above, the Federal Network Agency assigns a once-only, unique three-character AA ID to
each authorised agency.
In the future surveillance actions, this AA ID should be placed in the first three positions of the reference
number, provided the obligated undertaking required to implement the order has already introduced the
ETSI implementation. The authorised agency then informs the subject of the entire reference number
including the AA ID.
Accordingly, the entire reference number will be composed as follows:
1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
AA ID 22 positions per authorised agency to assign unique reference numbers
Permitted characters, in principle: ‘a’…‘z’, ‘A’…‘Z’ (without umlauts), ‘-’, ‘_’, ‘.’, and
‘0’…‘9’. Permitted characters for ISDN forwarding: ‘0’...‘9’
The allocated AA ID will also be used for the interface for technical implementation of legal measures for
information requests on traffic data (see Part B of this TR TKÜV).
TR TKÜV, edition 7.2 (draft) Part X, Appendix X.3, page 132
Appendix X.3 Provisions for the registration and certification authority TKÜV-CA
of the Federal Network Agency, Department IS16 (Policy)
The Federal Network Agency defines the regulations for the registration and certification authority TKÜV-
CA and for participation in the Virtual Private Network (TKÜV-VPN). In doing so, it must take into account
the respective state of the art (§ 14 TKÜV).
If, in the course of further development of the state of the art, stricter requirements are to be placed on the
precautions to be taken or if the need arises to change precautions already taken, the VPN subscribers
shall make the necessary adjustments in accordance with the specifications of the Federal Network
Agency within a period to be specified by it in each individual case.
The currently valid policy is available for download at: http://www.bundesnetzagentur.de/tku
1 General
1.1 Introduction
This policy contains the provisions on the Registration and Certification Authority of the Federal Network
Agency, Department IS16 (TKÜV-CA) for participation in the Virtual Private Network ‘TKÜV-VPN’ and the
details to be provided by subnet operators for the administration of the Public Key Infrastructure (PKI) as
well as a description of the overall process.
These provisions are mandatory for both the authorised agencies participating in the procedure and the
subjects under § 110 and/or § 113 TKG as subnet operators of the VPN.
1.2 Identity of the Registration and Certification Authority TKÜV-CA
Address: Federal Network Agency
Department IS 16
Canisiusstraße 21
D-55122 Mainz
E-mail:
[email protected]
Note on e-mail transmission: When sending confidential information (e.g. application for
VPN participation) by e-mail, PGP encryption software should be used.
1.3 General information services provided by the TKÜV-CA
Additional details and requirements of the TKÜV-CA are made available on the website of the Federal
Network Authority www.bundesnetzagentur.de/tku.
1.4 Validity of this document
This document is edition 2.1.1; it will be valid for the period of operation of the TKÜV VPN until it is
revoked or a new edition is published. Details on the validity of this document will be published via the
general information services of the TKÜV-CA on the above Internet address.
2 Services provided by the TKÜV-CA
2.1 Generation of the certificates, management of the Certification
Authority
The TKÜV-CA creates and manages the certificates for participation in the TKÜV-VPN and for secure
transmission between obligated parties and authorised agencies. To this end, it registers the relevant
participants, creates for each participant the cryptographic key required for the authentication of his/her
systems, and certifies this key using its own CA key. The certificates thus produced are stored on a smart
card supplied by the respective participant.
The TKÜV-CA also creates and maintains the Access Control List (ACL) based on the details supplied by
the participants, making this list available for use by the cryptosystems via an LDAP directory service. In
TR TKÜV, edition 7.2 (draft) Part X, Appendix X.3, page 133
order to administer any present local routers, the required associated IP addresses of the ACL are made
available on request to the subnet operators.
To verify the security relationships or the used cryptosystems, the TKÜV-CA operates a test device which
is kept on standby in case of failure. The system does not allow the Federal Network Agency to test the
security relationships between the obligated parties and authorised agencies.
2.2 Security of the CA system
All technical devices of the TKÜV-CA which are required to operate the TKÜV-VPN are located in special
access-controlled areas. Dedicated computers are used for the services of the TKÜV-CA; communication
between the cryptosystems operated within the VPN and the directory service and associated central
management is itself secured by means of a cryptographic procedure.
The creation of certificates and maintenance of the ACL takes place in accordance with the “four eyes
principle”.
The operation of the devices of the TKÜV-CA is provided with support from the manufacturer of the
systems. These contractual provisions do not relate to the systems used by the authorised agencies and
the subjects.
3 Requirements for participants
Participants in the TKÜV-VPN as defined in this Policy are the authorised agencies and the obligated
parties, with their respective subnets.
Participants shall appoint one CA officer for each TKÜV-CA and, where appropriate, one representative,
who will be the liaison for the relevant subnets and, in particular, will be responsible for security.
In urgent situations, the CA officers will receive the required information from the CA administrator via
phone, e-mail or normal post. It should be ensured that these messages are retrieved quickly.
The following requirements apply to CA officers and their representatives:
The smart cards written by the TKÜV-CA should be handled with normal caution to prevent
abuse by unauthorised persons and may only be passed on to persons entrusted with the
operation or administration of the relevant cryptosystems.
The smart cards should be returned for deletion of their content upon request from the TKÜV-CA,
e.g. in case of security defects discovered later.
If there are grounds to disable a certificate (e.g. company shutdown, loss of the smart card,
abuse), this should be reported to the TKÜV-CA immediately so that the required measures (e.g.
disabling in the directory service, revocation of the certificate) can be taken.
Otherwise, the requirements of the TKÜV shall apply, particularly § 15 of the TKÜV
(confidentiality).
4 Rules for registration
To facilitate registration, a set of instructions, a registration form and the IP configuration of the
cryptosystems will be made available at the Internet address of the TKÜV-CA ( VPN participation
application form).
4.1 Registration of the authorised agencies
Since the relevant authorised agencies can be identified uniquely, there will be no verification of personal
identity. Registration or issuance of a smart card is requested from the TKÜV-CA by e-mail and in writing,
together with all the required details, by a CA officer appointed by the authorised agency.
The TKÜV-CA should be informed immediately of new registrations and of the change or removal of a
CA officer or representative ( VPN participation request); these changes do not require replacement of
the smart card.
4.2 Registration of the obligated parties
Obligated parties are each registered through verification of their personal identity by means of an identity
card or passport.
TR TKÜV, edition 7.2 (draft) Part X, Appendix X.3, page 134
The appointed CA officers or representatives appointed by those responsible within the undertaking
should preferably be persons entrusted with the organisational management of the technical facilities
used to implement the surveillance actions, e.g. the persons appointed under § 19 of the TKÜV or others
charged with the tasks of an administrator.
Registration or issuance of a smart card is requested from the TKÜV-CA by the CA officer by e-mail and
in writing ( VPN participation request) together with all the required details of the persons for whom
registration is requested.
Registration is normally done at the TKÜV-CA.
New registration becomes necessary when a registered person of the obligated party is replaced. The
removal of a registered person or a change in the legal status of the subject should immediately be
notified to the TKÜV-CA ( VPN participation request); these changes do not require replacement of the
smart card.
5 Rules for certification
The TKÜV-CA issues certificates only for the entire TKÜV-VPN process.
A set of instructions and forms for certification will be made available at the Internet address of the TKÜV-
CA.
Certificates are produced with a maximum validity of 4 years; the user certificate is linked to a single
smart card.
5.1 Data to be provided
For the purposes of certification ( VPN participation request), participants submit their basic details;
these are used to create the X.509 certificates and to create or update the ACL in the directory service.
The subsequent detailed decisions are made autonomously by the TKÜV-CA. The submitted details are
stored securely.
The naming scheme is prescribed by the TKÜV-CA. Other naming conventions do not have to be
observed due to the closed VPN.
A. Data for the X.509 certificates
(determined by TKÜV-CA)
The X.509v3 certificates used in this procedure create the link between the identities of participants
in the TKÜV PKI, in the form of an X.500 Distinguished Name (DN) and a public key which is certified
by the digital signature of the TKÜV-CA. The DN is included in the certificate as the subject and
combined with the public key. The relevant format is given in the table below.
Table ‘Format of the X.500 Distinguished Name (DN)’
Field Meaning Value
C Country DE
SP State or Province Name . 1)
L Locality Name . 1)
O Organisation Name regtp_sina
OU Organisational Unit Name further subdivision where applicable (in
addition to the CN)
CN Common Name Name of the authorised agency or subject
(e.g. ‘LKA_Stuttgart_1’)
E-mail E-mail address of the identity to facilitate administration of names (is
derived automatically from the data in the
form: CN@[OU].O.C)
1) If a value ‘.’ is entered, the field remains unused.
The Distinguished Name corresponds to the user name in the cryptosystem, which can be viewed on
the display of the cryptosystem.
Example: C: DE, O: regtp_sina, CN: LKA_Stuttgart_1, LKA_Stuttgart_1@regtp_sina.de
TR TKÜV, edition 7.2 (draft) Part X, Appendix X.3, page 135
Table ‘Format of the X.509v3 certificate’
Field Meaning Value
version Version of the X.509 certificate 3
serial number unique number for each certificate consecutive number
signature signing algorithm used
issuer Distinguished Name of the TKÜV-CA see above
validity Period of validity
subject name Distinguished Name of the authorised agency or
subject
subject public key of the owner (subject name)
PublicKeyInfo
unique Identifiers unused
Extensions
rfc822Name Mapping of the DN to an e-mail address used for IPSec; is
created
automatically
B. Data for drawing up/adding to the ACL
(Set by TKÜV-CA following general provision by participant)
The Access Control List (ACL) contains all valid security relationships of the relevant participants,
and is managed exclusively by the TKÜV-CA.
After commissioning or restart of the cryptosystem with the smart card issued by the TKÜV-CA, the
cryptosystem automatically sets up a connection to the directory service and loads the current ACL.
The ACL provided is always signed by the TKÜV-CA; the cryptosystems will not accept
unsigned ACLs. After this, the system is ready for operation.
The data required for creating or supplementing the ACL concern the issued certificate and the
unique IP addresses used to address the application (IP endpoint) behind the cryptosystem (IP WAN
and IP local), to be supplied by the participants.
For assigning the IP addresses, the subnet operators will be given a guideline with an example
configuration ( VPN participation request, chart).
Subnet operators are responsible for the accuracy of their details; the Federal Network Agency may
merely conduct a simple plausibility check.
Table ‘Necessary public IP addresses for unique addressing’
Field Meaning Value
IP-Router-WAN internal IP address of the (default) router required
exposed to the Internet
IP-Crypto-WAN IP address/subnet mask of the cryptosystem required
exposed to the Internet
IP-Crypto-Local IP address/subnet mask of the cryptosystem required
exposed to the internal network
IP-Router-Local IP address of the internal router used to connect optional (depends
more subnets to the box on network
structure)
IP application IP address(es) of the devices supplied to required 1)
implement the legal measures
IP-Logserver IP address of a dedicated log server receiving required 1)
operational and audit logs
TR TKÜV, edition 7.2 (draft) Part X, Appendix X.3, page 136
1) Connections may use private IP addresses, which should then be linked to the public IP address
of the IP cryptosystem (IP-Crypto-Local) by means of address translation (NAT). The NAT, in turn,
should of course be assigned a unique IP address exposed to the cryptobox.
5.2 Instructions
Persistence of connection of the cryptosystems to the Internet
The exact connection of the cryptosystem to the Internet (IP configuration) as the subscriber-
side portion of the security relation to the management and LDAP server of the TKÜV-CA, as
well as to the dedicated IP log server, are stored persistently on the smart card with the Auto-
Init option, so that at the start of the cryptosystem, the ACL can be downloaded and any errors
reported. In case of changes, a new smart card needs to be issued by means of the application
procedure ( VPN participation request).
In case of changes to the application proper (IP application) which do not affect the
IP configuration, a new smart card need not be issued.
Acceptance of designated hosts only (applications) behind the cryptosystem
In addition to the security interactions between the cryptosystem, the management, the
LDAP server of the TKÜV-CA and the dedicated IP log server, only expressly designated hosts
(applications) are defined as security relations in the ACL. Acceptance of entire subnets is
permissible. However, the TKÜV-CA reserves the right to limit the number of individual security
relationships and/or the size of the subnet at its own discretion. The security relationships
between the hosts of the subject and those of the authorised agencies are always mutual.
Use of routers, package filters, firewalls, etc.
When using routers or network elements with package filtering or firewall functionality on the
internal side between the cryptosystem and the host within the subnets, it should be ensured
that the administration of such elements - where required - does not cause any delays or
obstructions to the implementation of surveillance orders. If such network elements are relevant
for the IP configuration, they should be mentioned.
Providing partners’ IP addresses
In order to administer any network elements for routing, the TKÜV-CA supplies lists of the
required IP addresses on an FTP server operated by the TKÜV-CA and secured by means of a
cryptosystem. The operators of subnets will be granted access rights upon request; retrieval
and processing of this list are the responsibility of the operators of the subnets, and the content
of the lists should be handled confidentially.
5.3 Test of security relationships and cryptosystems used
After the subnet is commissioned, a test will be conducted to ensure correct operation, using the test
device operated by the TKÜV-CA for authorised agencies and subjects. This test serves to verify the
basic functionality of the IP configuration and the security relationships defined for management and
testing systems; it is done at the subject’s premises prior to acceptance of the technical surveillance
device. The system does not allow the Federal Network Agency to test the security relationships between
the subjects and authorised agencies.
5.4 Fact sheet for unique addressing of subnets
In case of participation in the VPN or use of cryptosystems in the subnets of the subjects and the
authorised agencies, it should be explained how the relevant subnet will be uniquely addressed. In
addition, the IP addresses needed for the procedure should be notified to the TKÜV-CA. To support
participants in their planning, a fact sheet has been developed which can be obtained from the relevant
information services. No guarantee can be given as regards the completeness of this fact sheet due to
the large number of technical solutions that are possible.
TR TKÜV, edition 7.2 (draft) Part X, Appendix X.3, page 137
5.5 Example layout
IP log server
Network Log
admin. server
Inhouse
Network
Internet
Local Cryptosyste Router W
Firewall
router m AN
IP application IP router WAN
IP crypto WAN
Local IP router IP crypto local
Diagram 1 ‘Example of a subnet with unique IP addresses’
Another example can be found in the VPN participation request.
6 Disabling a smart card
Disabling of a smart card takes place by means of a corresponding entry on a blacklist which is
transmitted to all participating cryptosystems and loaded by them upon restart. The entry in the blacklist
ensures that the cryptosystem equipped with the associated smart card will be excluded from
participation in the VPN. Identical backup cards will also be affected. A card is normally disabled after
consulting the relevant VPN participant. However, cards may also be disabled with immediate effect if
there is sufficient reason for doing so.
Disabling of a smart card may be necessary, for example, when
the issued smart card was lost or compromised,
misuse has occurred or the conditions of the TKÜV-CA have been violated,
there are circumstances requiring a temporary shutdown of the cryptosystem.
VPN participants are obliged to report immediately any circumstances which might constitute grounds for
disabling. The reason for disabling the smart card may allow it to be taken off the blacklist and put back
into normal operation.
7 Revocation of certificates
Certificates may be revoked only directly at the TKÜV-CA by an entry in the directory. VPN participants
are obliged to report immediately any circumstances which might be grounds for revocation.
Revocation of a certificate may be necessary, for example, when
the issued smart card was lost or compromised,
data in the certificate are invalid (change of IP configuration, company shutdown),
misuse has occurred or the conditions of the TKÜV-CA have been violated.
A certificate is always revoked when a smart card is deleted.
A certificate is generally revoked after consulting the relevant VPN participant. However, certificates may
also be disabled with immediate effect if there is sufficient reason for doing so. Revocations cannot be
undone. If a company resumes operations, a new smart card needs to be issued.
TR TKÜV, edition 7.2 (draft) Part X, Appendix X.3, page 138
8 Distribution and handling of smart cards
For the configuration and authentication data, smart cards are used onto which details of the user and
cryptosystem are stored.
The required quantity of empty cards of the relevant type should be enclosed by the relevant
VPN participant together with the VPN participation request. It is strongly recommended to have an
identical replacement card created for each IP cryptosystem. Smart cards are distributed by the TKÜV-
CA in person or via post to the designated group of persons (registered persons) of the relevant
VPN participant.
Smart cards are protected by a PIN/PUK combination as standard. The PIN is hard-coded by the TKÜV-
CA to a value where the cryptosystem boots into its operational state after power-up without prompting for
the PIN. While the PIN may be overwritten from the cryptosystem’s keyboard, the PIN will have to be
entered manually into the cryptosystem at each boot-up of the system (power-off, power-on) for any
other PIN than the hard-coded one.
Therefore, the PIN should not be modified.
9 Card content
The values set out in the following table are stored on the smart card at dispatch by the TKÜV-CA. The
terms used mean the following:
Column M (as in manipulation-secure): Data with an 'X' in the column are stored on the smart
card and protected from manipulation.
Keyword IP addresses: The “black side” or “black network” is the side of the cryptosystem which
is exposed to the Internet, hence insecure, and is therefore encrypted. The “red side” or “red
network” is used to refer to the unencrypted part lying in the secure network.
Keyword M Value / keyword
CA public key X
CA certificate X Certificate and public key of the certification authority
User key pair X Certificate, public and private key of the user
Validity of the X Encoded into the user‘s certificate; 4 years
certificates
Parameter sets for key Cryptographic parameters required to calculate temporary keys between
replacement users
Security relationships One security relationship each for the management system and the
LDAP directory (required for initial downloading of the ACL after power-
up of the cryptosystem) and security relationships for the test devices of
the Federal Network Agency. These security relationships are typically
stored persistently, i.e. these relations cannot be overridden through
ACL entries. Part of the security relationship are the cryptographic
functions to be used (one-way function / encryption algorithm)
PIN / PUK Security mechanism
IP address of the Interface name (ethX), IP address/subnet mask
cryptosystem (black
side)
IP address of the IP address
WAN router (black side)
IP address of the Interface name (ethY), IP address/subnet mask
cryptosystem (red side)
Releases IP addresses of the releases
IP address of the IP address of the dedicated syslog server
syslog server(s)
IP address of the The TKÜV-CA operates its own NTP server, whose IP address is
NTP server(s) encoded; a client-side NTP server may also be used
Time limit Time interval for querying the NTP server
TR TKÜV, edition 7.2 (draft) Part X, Appendix X.3, page 139
IP address of the hot- Only if used: Interface name (ethZ), IP address/subnet mask
standby interface
The menu system of the card reader integrated into the cryptosystem allows a number of settings to be
read and partly modified (PIN, time); further explanations can be found in the manual for the
cryptosystem.
Examples:
Keyword Value / keyword
IP configuration, "black side" Interface name (ethX)
IP address/subnet mask
IP configuration, ‘red page’ Interface name (ethY)
IP address/subnet mask
LDAP-Server IP address
Syslog-Server IP address
NTP-Server IP address
Identities username = Distinguished Name
Versions ACL version
Number of policies
Show/Set Time Display and editing of date and time
10 Management of cryptosystems/selection of options
10.1 Architecture of management and test devices at the Federal
Network Agency
The architecture of the overall management at the site of the TKÜV-CA for the cryptosystems used in the
subnets is divided into two subsystems:
a management station to administer the cryptosystems, set up the security relationships and
create the smart cards; and
a server for the directory service (LDAP) and a general database.
Both subsystems are connected to the Internet via a cryptosystem. The entire management is duplicated
for reasons of redundancy.
For each subsystem, security relationships with all cryptosystems in the subnets of the authorised
agencies or obligated parties (but not the hosts secured by them) should be hard-coded on the smart
card. The management system should be able to reach the cryptosystems for ACL updates and the
cryptosystems should be able to reach the server to load updated ACLs.
All security relationships are set up by the TKÜV-CA. Security relationships with the subsystems of the
management system must be hard-coded on the smart cards; the security relationships of the subjects’
hosts with the authorised agencies’ hosts are entered in the ACL of the directory service and then loaded
into the cryptosystems by the TKÜV-CA automatically or manually.
TR TKÜV, edition 7.2 (draft) Part X, Appendix X.3, page 140
Authorised
Subject
agency
Internet
Analysis
Technical
devices
transmission device
‘Management access II’ ‘Management access I’ ‘Test access’
Secondary
LDAP and
Primary LD
database
AP and Cryptosystem
database Test devices of
PKI managem reference system
ent
Structure of the PKI and the test device/reference system at the Federal
Network Authority
Diagram 2 ‘Architecture of management and test devices at the Federal Network Agency’
The test device (reference system) of the Federal Network Agency is used for acceptance pursuant to
§ 110 and/or 113 TKG and for functional testing of the authorised agencies’ and subjects’ cryptosystems
after commissioning. The system does not allow the Federal Network Agency to conduct functional tests
of the connections between subjects and authorised agencies as defined in the ACL. However,
participants do have such a possibility pursuant to § 23 of the TKÜV.
11 Selection of options/values
The management system allows various options for configuration of the cryptosystems and security
relationships which have to be decided before issuance of the smart cards. These options are given
below:
11.1 Log server
As each subnet operator is individually responsible for planning, use, maintenance and troubleshooting of
the cryptosystems, they should each operate their own log server. The Federal Network Agency does not
provide log servers for participants and will not be given access to participants’ log servers.
The cryptosystems used have no local mass storage devices such as hard disks or floppy drives.
Therefore, event reports cannot be stored locally. However, as these are needed for surveillance of the
cryptosystems and network, log servers should be set up. The IP address of the log server and the
connection between the individual cryptosystem and the associated log server are stored persistently on
the smart card. The UDP protocol with port 514 is used throughout.
Several SYSLOG servers may be set up for each cryptosystem and the log data will then be transmitted
to all log servers.
11.2 Heartbeat
In addition to the log server, a time interval may be given after which the cryptosystem sends a message
to the log server(s) to signal its operation, even when there is no further activity to be recorded. This
information is used to transmit certain system states such as interface statistics, uptime, etc. If no value is
entered, heartbeats will not be produced. However, normal activities will always be recorded, independent
of this setting. The heartbeat setting applies to all registered log servers.
TR TKÜV, edition 7.2 (draft) Part X, Appendix X.3, page 141
As part of the application procedure ( VPN participation request, options sheet), subnet operators may
indicate how this function should be used.
11.3 NTP server
The NTP server provides the time service within the PKI. The time (and date) retrieved from this server enables the
cryptosystem to determine whether a given certificate is still valid. If a box does not yet have access to an NTP server,
as this connection first needs to be set up, the local time as given by the on-board system clock is used
for comparison. After a successful connection to an NTP server, the cryptosystem clock is also
synchronised to the server's time.
The Federal Network Agency provides an NTP server exclusively for cryptosystems via its management
system; the required security relationships are stored persistently on the smart card. The reference time
is UTC, as derived from the official time of the Federal Republic of Germany. Participants may optionally
enter their own NTP servers.
It is possible to enter multiple NTP servers per cryptosystem. In this case, they are queried in the order
stored on the smart card.
Querying an NTP will create a syslog entry.
11.4 Supplying IP addresses of partner subnets
In order to administer network elements for routing and/or filtering where required, the TKÜV-CA supplies
a list of the required IP addresses on its own FTP server, secured by means of a cryptosystem. The
operators of subnets will be granted access rights upon request; retrieval of this list is the responsibility of
the operators of the subnets. The list is only updated as needed.
11.5 Hot standby (HSB)
In hot standby mode, two cryptosystems are installed to operate as a cluster. One of the systems is active
(master or Sys1), whereas the second system (slave or Sys2) takes over in the event of the failure of the
first system. This mode of operation requires specially prepared smart cards.
11.6 Software version Kryptobox
At present, only SINA Boxes from Secunet are used as cryptosystems. Only version 3.7.4.3 or newer is
permitted as operating software for the SINA Box.
11.7 Smart cards
Only Starcos smartcards version 3.5 with the BSI patch ECGDSA are currently approved.
12 Other applicable documents
Other applicable documents, in their respective current versions, are:
Telecommunications Act (TKG)
Telecommunications Surveillance Ordinance (TKÜV)
Technical Guideline for the implementation of legal measures for the surveillance of
telecommunications and the disclosure of information (TR TKÜV)
VPN participation request
TR TKÜV, edition 7.2 (draft) Part X, Appendix X.4, page 142
Appendix X.4 Table of applicable ETSI/3GPP standards and specifications as well
as the ASN.1 modules
On the basis of § 11 sentence 5 of the TKÜV, the Federal Network Agency publishes information on the
applicable versions of the ETSI and 3GPP standards and specifications in force pursuant to the TR TKÜV
on its website in the section on telecommunications, under the keywords ‘Technical Regulation of
Telecommunications’ / ‘Technical Implementation of Surveillance Actions’.
An essential part of this are the applicable ASN.1 modules.
Any syntax errors present in the ASN.1 modules should be corrected and care taken to use the correct
Object Identifier (OID) or version number. In addition, versions of the modules that are not backwards
compatible with the other versions must not be applied.
The following table lists this information as current at the time of publication.
Applicable ASN.1 modules Version of the Requirements or instructions for application
(more recent versions than those given standard or
can normally be applied) specification
ETSI ES 201 671, TS 101 671 (Appendix C)
This includes the versions of modules which have an OID as well as older versions which have previously been
implemented in the networks with their concepts endorsed.
HI2Operations Version 10 This version contains an error as applied to
Version 3.2.1 and above of the specification, which
makes it incompatible. Accordingly, this version may
only be used up to Version 3.1.1.
HI2Operations Version 11 This version contains an error which makes it
incompatible. This version may not therefore be
used. Version 3.6.1. of the specification removes
the error from the then latest Version 12.
3GPP TS 33.108 (Appendix D)
This includes the versions of modules which have an OID as well as older versions which have previously been
implemented in the networks with their concepts endorsed.
3GPP TS 33.128 (Appendix D)
TS33128Payloads, R16, version 2 Version 16.3.0
ETSI TS 102 232-01 (Appendices F.3 and G)
LI-PS-PDU, Version 4 Version 1.4.1
ETSI TS 102 232-02 (Appendix F.3)
E-mailPDU, Version 3 Version 2.1.1
ETSI TS 102 232-03 (Appendix G)
IPAccessPDU, Version 4 Version 1.6.1
ETSI TS 102 232-04 (Appendix G)
L2AccessPDU, Version 3 Version 1.3.1
ETSI TS 101 909-20-2 (Appendix G)
PCESP, Version-4(4) Version 1.1.2
TS101909202, interceptVersion (0)
ETSI TS 102 232-05 (Appendix H.1)
IPMultimediaPDU, Version 1 Version 2.1.1
ETSI TS 102 232-06 (Appendix H.2)
PstnIsdnPDU, Version 1 Version 2.1.1
ETSI TS 101 909-20-1 (Appendix H.3)
TS101909201, interceptVersion (0) Version 2.1.1
TSI TS 103 707 (Appendix I)
XML XSD definition according to Version 1.1.1
Appendix B
TR TKÜV, edition 7.2 (draft) Part X, Appendix X.4, page 143
ETSI TS 102 657 (Part B)
The uses are published on the
Federal Network Agency’s website at
http://www.bundesnetzagentur.de/tku
TR TKÜV, edition 7.2 (draft) Part X, Appendix X.5, page 144
Appendix X.5 Standard concept for the preparation of verification documents,
test records and test reports for verification testing
For the preparation of the documents pursuant to § 19 (2) and § 34 (1) of the TKÜV and for the review of
the organisational precautions pursuant to § 17(4) and § 35 sentence 7 of the TKÜV, the Federal Network
Agency provides the documents described below:
Standard concepts
Pursuant to § 19(2) TKÜV, the Federal Network Agency may specify requirements regarding the
documents (concept) to be submitted by the subject. This is done by providing service-specific standard
concepts which generally refer to the topics listed in § 19(2) TKÜV. This should make it easier for
subjects to submit the necessary documents for examination. In the standard concepts, for example, the
organisational precautions (e.g. overall responsible person, business hours, contacts, contact persons) or
the description of technical matters (e.g. explanation of services and features as support for the
evaluation, description of the telecommunications system, the surveillance equipment or the information
systems) are dealt with.
A standard concept for each of the different services is published on the website
www.bundesnetzagentur.de/TKU
. The obligated installation operator shall use the standard concept for the design of the verification
document (concept) to be submitted.
Test protocols and test reports
To check the technical and organisational precautions under § 110(1)(1)(3) TKG and the inspection under
§ 17(4) and § 35(7) TKÜV, the Federal Network Agency shall use test logs or test reports. As preparation
of the obligated companies for the audit to be carried out and as basic preparation for the requirements
resulting from the TKÜV and TR TKÜV, the documents are provided by the Federal Network Agency
upon request or in advance of the audit.
TR TKÜV, edition 7.2 (draft) Part X, continuation, page 145
Updates
The procedure for future updates to the TR TKÜV is governed by the provisions of § 36 of the TKÜV,
pursuant to which the Federal Network Agency lays down the relevant details, with the participation of
associations of subjects, authorised agencies, and manufacturers of surveillance systems and recording
and analysis devices.
Fundamental changes to this Guideline will be denoted by means of a new edition number before the
decimal point.
Adjustments and additions to parts of the TR TKÜV which were already described in a previous version
will be denoted by a new version number after the decimal point.
In both cases, new versions of the TR TKÜV will be notified in the Federal Gazette and the Official
Journal of the Federal Network Agency.
Version list
Edition Date Reason for change
1.0 December 1995 First version of the TR TKÜV
2.0 April 1997 Update pursuant to announcement of December 1995
2.1 March 1998 1. Requirements for voice mail systems and similar storage systems / inclusion
of an additional variant for transmission of event data
2. Time basis for time data in the data sets
3. Editorial corrections
2.2 December 2000 Corrections to Version 2.1
1. Update of Appendix 1
2. Appendix 3
Designation of unused digits by either hex ‘F’ or ‘odd/even’ indicator and
hex ‘0’ according to TABLE 4-10/Q.931
3. Adjustment of Appendix 6
3.1 Deletion of transmission method ‘Eurofile’ and ‘subaddress’ for event data
3.2 Forwarding to active fax devices at authorised agencies (support for
procedures according to ITU-T T.30) and use of the BC ‘audio’ and HLC
‘Facsimile’)
3.0 November 2001 Inclusion of the national requirements for implementation of ETSI Standard
ES 201 671 V2.1.1 in Germany as Appendix 7
3.1 May 2002 Editorial adjustments to the Technical Guideline to the TKÜV, change of
abbreviation to TR TKÜ
4.0 April 2003 1. Deletion of technical requirements in Section 5.2.3 for packet-switched, non-
IP-based networks
2. Flexible application of the FTAM and FTP transmission protocols, associated
requirements for file names in Appendix 1
3. Inclusion of requirements for secure transmission of monitored
telecommunications over IP networks using IPSec, as Annex 4 to Appendix 7
4. Requirements for packetisation of event data in case of implementation
pursuant to Appendix 7
5. Inclusion of the national requirements for implementation of
3GPP Specification TS 33.108 in Germany as Appendix 8
6. Inclusion of the national requirements for monitoring of e-mail as Appendix 9
4.1 November 2004 1. Notice of notification on the title page
2. Deletion of the reference to coordination with international committees in
Appendices 7 and 8.
3. New Version 4 of the ASN.1 module with the national parameters
(Appendix 7, Annex 3)
TR TKÜV, edition 7.2 (draft) Part X, continuation, page 146
Edition Date Reason for change
4. Determination of the port number for TCP in Appendix 7, Point F.3.1.3
5. In Table 1/A.5, the value for the maximum file length was increased to 25
6. In Appendix 1, a reference to the possibility of transmission of the IRI
according to TS 102 232 was included
7. In Appendix 5, stipulations were laid down for the major parameters when
using FTP.
8. In Appendix 7, Annex 2, a reference to the possibility of transmission of the
HI1 notifications was included
9. Inclusion of the national parameters as an integral component of the
HI2 module in Appendix 7, Annex 2
10. Specification of the treatment of log files in Appendix 7, Annex 4
11. Appendix 9, inclusion of the requirements pursuant to
ETSI Standard TS 102 233
12. Appendix 10, inclusion of the requirements for IP-based forwarding pursuant
to ETSI Standard TS 102 232
5.0 December 2006 1. Restructuring of the TR TKÜ
2. New provisions according to (previous) § 11, sentence 6 TKÜV (identifiers for
surveillance)
3. Detailed provisions for Internet gateways on the basis of ETSI specifications
4. Adjustments with respect to Unified Messaging Systems and e-mail
5. New provision for forwarding of SMS messages according to the national
variant (Appendix B)
6. Other editorial corrections
5.1 February 2008 1. Requirements for VoIP and other multimedia services based on the SIP, RTP
or H.323 and H.248 protocols or the IP Cablecom architecture and for
emulated PSTN/ISDN services
2. Adjustments with respect to e-mail through inclusion of all protocols in the
ETSI Specification TS 102 232-2
3. Clarification for Internet gateways, with regard to the services distributed
through them, such as IP TV and video on demand.
4. Adjustments with respect to the requirements in case of difficulties in
transmission of the surveillance copy to the receiving device of the
authorised agency
5. Inclusion of the CGI field as a mandatory supplemental field for coordinates
according to Appendix B
5. Other editorial corrections
6.0 December 2009 1. Restructuring / renaming
2. Extension by an optional transmission point for provision of information on
traffic data according to ETSI Specification TS 102 657
3. Optional electronic transmission of orders
4. Other editorial corrections
5. Copy of the new policy, Version 1.4 for the TKÜV-CA
6. Process description to ensure uniqueness of reference numbers for
surveillance actions
6.1 January 2012 1. Adjustments of the standard values, Section 3.2
2. Addenda on possible identifiers for surveillance of Internet gateways,
Section 4.1
3. Inclusion of a process description as per § 23(1) point 3 of the TKÜV
4. Clarification on FTP transmission procedures, Appendix A.1.2.2
5. New version of the national ASN.1 module ‘Natparas’, Appendix A.3.2
TR TKÜV, edition 7.2 (draft) Part X, continuation, page 147
Edition Date Reason for change
6. Value of Calling Party Subaddress for international exchange surveillance,
Appendix B.3
7. Relaxation of requirements concerning the use of the COLP check,
Appendices B.1, C.1, and D.1
8. Specification of ULICv1 for packet-switched in mobile telephony,
Appendix C.1 and Appendix D.1
9. Adjustments for e-mail, Appendix F
10. Clarification of allocation of different SIP messages to IRI events and use of
IP source/destination addresses, Appendices H.3.2, H.3.3 and H.3.4
11. Addenda in the table of applicable ASN.1 modules, Appendix X.4
12. Unified requirement for the use of timestamps
6.2 August 2012 1. Rewording and consolidation of the provisions of the previous Parts B and C
into the new Part B to reflect the refinement of the new interfaces already
introduced with edition 6.0
2. Adjustment to Appendix X.4
6.3 6 April 2016 1. Editorial revision of the entire document
2. Appendix A: Addition of Point 3.3 ("data losses")
3. Appendix A: Supplementary clarification of WLAN (point 4.1)
4. Appendix B: Note on the end of use of forwarding pursuant to Appendix B
5. Appendix C: Note on the end of use of forwarding pursuant to Appendix C
6. Appendix C: Restriction of validity to ISDN/PSTN (no mobile telephony now
included)
7. Appendix D: Addition to location information
8. Appendix D: Explanations of packet direction, IP addresses and ports (table)
9. Appendix F.3.1.1: Explanations of Network Element Identifier, Payload
Direction (tables)
10. Appendix G.1.1: Explanations of Network Element Identifier, Payload
Direction (tables)
11. Appendix H: Explanation of Mid-Session Interception (H.1.2), obligation for
essentially complete forwarding of telecommunications (H.1.4)
12. Appendix H.3.1: Appendix G.1.1: Explanations of Network Element Identifier,
Payload Direction, Keep-Alives and IP addresses (tables)
13. Appendix X.3: Adaptation of ‘Policy’
14. Part B: Adjustment in line with the current legal basis
15. Part B: Further development of the underlying ETSI specification
16. Part B: Selective subscriber data requests
17. Part B: Standardisation of network operator responses for BDA and VDA
18. Part B: Flexible use of free text fields
19. Part B: Extension of the national modules regarding requirement for text form
and introduction of a version scheme
7.0 14.06.2017 1. Editorial revision of the entire document
2. Part A, Appendix A: Supplementary clarification of WLAN (point 4.1)
3. Part A, Appendix D.1 (Table C.1.1): Specification of port number
4. Part A, Appendix F.3.1.1 (Table 5.2.4): Additional reference to
"Communication identifier"
5. Part A, Appendix F.3.1.1 (Table 5.2.6): new specification for ‘Payload
timestamp’
TR TKÜV, edition 7.2 (draft) Part X, continuation, page 148
Edition Date Reason for change
6. Part A, Appendix F.3.1.1 (Table 5.2.11): new specification for "Interception
Point identifier"
7. Part A, Appendix G.1.1 (Table 5.2.4): Additional reference to ‘Communication
identifier’
8. Part A, Appendix G.1.1 (Table 5.2.6): new specification for ‘Payload
timestamp’
9. Part A, Appendix G.1.1 (Table 5.2.11): new specification for "Interception
Point identifier"
10. Part A, Appendix H.1.2: Supplementary information on activating a
surveillance action with existing telecommunications link
11. Part A, Annex H.3.1 (Table 5.2.4): Additional reference to ‘Communication
identifier’
12. Part A, Appendix H.3.1 (Table 5.2.6): new specification for ‘Payload
timestamp’
13. Part A, Appendix H.3.1 (Table): Reference to encoding information
14. Part A, Appendix H.3.1 (Table 5.2.11): new specification for "Interception
Point identifier"
15. Part A, Appendix H.3.2 (Table 5.4): Supplementary references to "Events
and IRI record types"
16. Part B: Adaptations to ‘1. Basic principles’
17. Part B: New specifications concerning transmission procedures
18. Part B: Specifications for guaranteeing data security and data quality
19. Part B, Appendix A: Clarification of various usage procedures, traffic data in
real time, cancel message, radio cell requests, urgent surveillance orders
20. Part B, Appendix A: Inclusion of version scheme, late record, direct line
search, identification of data sets
21. Part B, Appendix B: Specifications on new ‘E-Mail-ESB’ transmission
procedure
22. Part X, Appendix X.3: Adaptation of "Policy"
7.1 11.06.2018 1. Editorial revision of the entire document
2. Deletion of Appendix B (Part A) due to repeal of X.25/X.31
3. Guidelines on IP addresses and encoding; repeal of control options
reporting; encryption requirements (specifications from new TKÜV; various
Appendices in Part A)
4. Note on telecommunications surveillance activation (various Appendices in
Part A)
5. Use of the relevant standards for telecommunications forwarding; exceptions
for IMEI surveillance Appendix D (Part A); also note in Appendix X.1.1
6. Amendments to Part B, Appendix 1: Use of newer versions / use of legal
data Legal bases (Chapter 1.2), Late records (Chapter 1.3.1.1), Real-time
disclosure (Chapter 1.3.2), Permitted time until availability (Chapter 1.3.3.2;
3.3), Early deactivation of a warrant (Chapter 1.3.1.4), Rejected targets
(Chapter 1.3.1.4), Radio cell structures for foreign mobile radio connections
(Chapter 3.2.2.5)
9. Note on future security requirements and requirements for 5G (Appendices
X.1.2 and X.1.3)
10. Note on test log and plan template (Appendix X.5)
7.2 23.11.2020 1. Editorial revision of the notes on MTU size (Part A, Chapter 3.3.2), on
identifiers for the implementation of monitoring measures of the Internet
access path (Part A, Chapter 4.1) and on the transmission of FTP files (Part
A, Appendix F.1)
2. Part A, Appendix I: Inclusion of specifications for messaging services
TR TKÜV, edition 7.2 (draft) Part X, continuation, page 149
Edition Date Reason for change
3. Part B: Adjusted specifications for warrant request (Chapters 1.3.x, 3.2.2.2)
4. Part B: Extension of information on the location of mobile terminals to
include all types of location and the prevention of danger to life, limb, health
or freedom of a person (Chapters 1.3.5, 3.2.2.5).
5. Part B: Extended labelling for traffic data request (1.3.5, 3.2.2.3)
6. Part X, Appendix X.3: Update ‘Policy’
7. Part X, Appendix X.5: Editorial revision
Maret Ots
Saatja: Karl Stern <
[email protected]>
Saatmisaeg: reede, 5. veebruar 2021 10:04
Adressaat: Mart Laas; Maret Ots
Teema: teatis
Manused: 2021810D.docx
Järeltegevuse lipp: Järeltegevus
Olekulipp: Lipuga märgitud
Tere
Saadan Saksamaa teatise 810 „Tehniline suunis, millega rakendatakse seaduslikud meetmed telekommunikatsiooni
järelevalveks, teabe väljastamiseks (TR TKÜV), väljaanne 7.2“. Ooteaeg lõpeb 17.03.
Karl
1