ATIS 1000021-2007 Data Buffering (Short Term Storage) in an Internet Access and Services LAES Environment.pdf

《ATIS 1000021-2007 Data Buffering (Short Term Storage) in an Internet Access and Services LAES Environment.pdf》由会员分享，可在线阅读，更多相关《ATIS 1000021-2007 Data Buffering (Short Term Storage) in an Internet Access and Services LAES Environment.pdf（20页珍藏版）》请在麦多课文档分享上搜索。

1、 ATIS-1000021 DATA BUFFERING (SHORT TERM STORAGE) IN AN INTERNET ACCESS AND SERVICES LAES ENVIRONMENT TECHNICAL REPORT The Alliance for Telecommunication Industry Solutions (ATIS) is a technical planning and standards development organization that is committed to rapidly developing and promoting tec

2、hnical and operations standards for the communications and related information technologies industry worldwide using a pragmatic, flexible and open approach. Over 1,100 participants from more than 350 communications companies are active in ATIS 23 industry committees and its Incubator Solutions Prog

3、ram. NOTE - The users attention is called to the possibility that compliance with this standard may require use of an invention covered by patent rights. By publication of this standard, no position is taken with respect to whether use of an invention covered by patent rights will be required, and i

4、f any such use is required no position is taken regarding the validity of this claim or any patent rights in connection therewith. ATIS-1000021, Data Buffering (Short Term Storage) in an Internet Access and Services LAES Environment Is an ATIS Standard developed by the Lawfully Authorized Electronic

5、 Surveillance (LAES) Subcommittee under the ATIS Packet Technologies and Systems Committee (PTSC). Published by Alliance for Telecommunications Industry Solutions 1200 G Street, NW, Suite 500 Washington, DC 20005 Copyright 2007 by Alliance for Telecommunications Industry Solutions All rights reserve

6、d. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher. For information contact ATIS at 202.628.6380. ATIS is online at . Printed in the United States of America. ATIS-1000021 Technical Repor

7、t on DATA BUFFERING (SHORT TERM STORAGE) IN AN INTERNET ACCESS AND SERVICES LAES ENVIRONMENT Secretariat Alliance for Telecommunications Industry Solutions Approved October 2007 Abstract Reliable collection of intercepts is of paramount importance to Law Enforcement. An option for ensuring reliable

8、collection of intercepts by Law Enforcement is the use of buffering (short term storage) as an adjunct function to the intercept process. ATIS-1000021 ii FOREWORD The Alliance for Telecommunication Industry Solutions (ATIS) serves the public through improved understanding between carriers, customers

9、, and manufacturers. The Packet Technologies and Systems Committee (PTSC) - formerly T1S1 - develops and recommends standards and technical reports related to services, architectures, and signaling, in addition to related subjects under consideration in other North American and international standar

10、ds bodies. PTSC coordinates and develops standards and technical reports relevant to telecommunications networks in the U.S., reviews and prepares contributions on such matters for submission to U.S. ITU-T and U.S. ITU-R Study Groups or other standards organizations, and reviews for acceptability or

11、 per contra the positions of other countries in related standards development and takes or recommends appropriate actions. Suggestions for improvement of this document are welcome. They should be sent to the Alliance for Telecommunications Industry Solutions, ATIS PTSC Secretariat, 1200 G Street NW,

12、 Suite 500, Washington, DC 20005. At the time it approved this document, ATIS PTSC, which is responsible for the development of this Technical Report, had the following members: B. Hall, PTSC Chair J. Zebarth, PTSC Vice-Chair C.A. Underkoffler, ATIS Chief Editor M. Bilca, PTSC LAES Technical Editor

13、Organization Represented Name of Representative AcmePacket Kevin Klett Alcatel-Lucent Stuart Goldman AT there shall be no access to directories and files outside of a case directory for a particular access session. The BF shall provide the option of using the same authentication credentials (e.g, pa

14、ssword, SSH public key) for multiple case directories. Over the e interface, the only permissible actions are to (1) Gain access to a particular case directory; (2) Read the attributes of the files; (3) Read CmII or CmC files; (4) Delete CmII or CmC files; and (5) Read the intercept log. 5.3 Buffer

15、Files This clause defines the characteristics of the CmII and CmC buffer files. 5.3.1 Buffer File Format 5.3.1.1 CmC Files The two categories of buffer files have different representations. For CmC, the Packet CAPture (PCAP) file format (see Annex C) shall be used, since CmC messages are Internet Pr

16、otocol (IP) 67 packets ATIS-1000021 8 encapsulated within a CmC message. The BF will strip away the CmC encapsulation and create the CmC files which will contain the IP packets that were originally intercepted. The PCAP format requires representation from the data-link layer outward, and since this

17、is almost always Ethernet, an artificial Ethernet header needs to be constructed for each IP packet in the CmC messages. The Ethertype field shall be set to describe the packet as IPv4 6 or IPv6 7. The destination Media Access Control (MAC) address will be set to 0xFFFFFF (Broadcast). The source MAC

18、 address shall be the first 6 octets of the correlation ID contained in the CmC message, or the correlation ID padded with zeros if the correlation ID is fewer than 6 octets. The PCAP timestamp shall contain the timestamp originally stored in the CmC message. The type of ATIS-1000013.2007 messaging

19、- e.g., Society of Cable Telecommunications Engineers (SCTE) Datagram, ATIS-1000678.2006, or IAS Datagram Format - a BF receives shall be provisionable. 5.3.1.2 CmII Files For CmII buffer files, the representation is different since these are messages with no meaningful layer two through layer four

20、information. CmII buffer files will be sequential files that contain variable-length entities, which are the CmII messages. 5.3.2 File Naming Buffer files are named by the BF when they are created. CmII files have the name caseid_seqnum.cmii, where caseid is the case ID (same name as the case direct

21、ory) and seqnum is a sequence number. The sequence number starts at 00000000 when the buffering function is activated for an intercept. CmC files have the name caseid_seqnum.pcap following the same conventions. CmII and CmC files having the same sequence number in the same case directory cover the s

22、ame period. The BF shall create these files on an event-driven basis (i.e., for a given sequence number in use, there could be a pair of files, just the CmII file, or just the CmC file). A new CmII file shall use: (1) the sequence number of the corresponding CmC file that is currently open; or (2) t

23、he next sequential number if no CmC file is currently open. A new CmC file shall use: (1) the sequence number of the corresponding CmII file that is currently open; or (2) the next sequential number if no CmII file is currently open. 5.3.3 Buffer File Granularity An administrative function shall exi

24、st for specifying the size granularity for file creation during an intercept. File size granularity limits the maximum amount of data that can be written to a buffer file until it is closed and made available to the LEA. It shall be possible, per intercept, to provision the maximum: a) Number of CmI

25、I messages and CmC packets buffered per file; b) Amount of time over which the CmII messages and CmC packets are buffered within a file; and c) Size of a file. ATIS-1000021 9 When a CmII or CmC file is closed due to the above, the corresponding file of other type (i.e., CmC if CmII, CmII if CmC) is

26、also closed. 5.3.4 Buffer File Deletion The BF shall be able to store buffer files for at least 24 hours after the time they are closed and made available in the case directory. The maximum buffer file storage time should be configurable per case directory. Buffer files that are deleted by the CF ov

27、er the e interface shall be deleted immediately. The BF is permitted to delete CmII and CmC files if they have not been deleted by the CF after 24 hours. Buffer files shall be deleted by the BF on a first-in, first-out basis. The event of a file deletion by the BF shall be placed in the intercept lo

28、g and the event of a file deletion by the CF may be placed in the intercept log. 5.4 Intercept Log There is certain information that is useful for an intercept that may not be communicated in CmII and CmC messages. This information is placed in a file per case called the intercept log. The intercept

29、 log file is named caseid.ilog. The intercept log has an initial record defining the product or platform serving as the BF, the software version, and the BF identity. When a CmII or CmC file is closed, a Secure Hash Algorithm (SHA-256) 4 hash is performed of the file contents. The hash digest and na

30、me of the file is placed in the intercept log. If a CmII or CmC file is deleted by the BF or the CF, the name of the file, a timestamp of when it was deleted, and the reason for deletion are placed in the intercept log entry associated with the deleted file. If the BF has access to statistics about

31、the e interface, the statistics are placed in the intercept log at an administrator-specified interval. The dropped packet statistic is currently the only statistic defined in the log file, and represents e interface Protocol Data Units (PDU)s dropped due to parsing errors. The intercept log is a se

32、quential file. Its Abstract Syntax Notation Number 1 (ASN.1) definition appears in clause 7. 5.5 Buffering Capacity The default buffering capacity shall be a minimum of 24 hours per intercept. The number of cases a BF can simultaneously support is limited by the available storage space, the total su

33、bject bandwidth of cases which require CmC buffering, and the required time which the buffered data needs to be stored. If an LEA requests an intercept which would exceed the capacity of the BF the LEA may, as mutually agreed with the IASP: a) Request more buffer storage capacity; or b) Use the exis

34、ting capacity for more cases by reducing the required buffer file storage time. The LEA may reduce the buffer file storage time for any or all of the LEAs active cases. ATIS-1000021 10 6. E INTERFACE 6.1 e Protocol Stack The CF accesses Buffer Function files via SSH File Transfer Protocol (SFTP) 5.

35、The BF shall provide at least one secure authentication method supported by SSH. The CF initiates the SFTP connection to the BF to retrieve the buffered CmII, CmC, and intercept log files. The BF shall not support access to the CmII and CmC buffer files currently open for writing, but it must suppor

36、t access to the intercept log. CmC PCAP, CmII, or Intercept Log Files SFTP SSH Transport IP Figure 3: Protocol Stack ATIS-1000021 11 Annex A (informative) A CHECKLIST FOR DEPLOYING LEA-PROVIDED BUFFERING (SHORT TERM STORAGE) EQUIPMENT The following checklist of items needs to be considered during ne

37、gotiations between a LEA and an IASP in developing arrangements that will allow LEA-provided buffering (short term storage) equipment to be deployed as close as practical to the DF. Note that the following is not an exhaustive list, and not all items may apply to every implementation. 1. Floor Space

38、 Requirements: a. Rack Space. b. Cage Space. c. Shared facility. 2. Interconnection Requirements: a. From DF to BF, including physical connection, protocols, bandwidth, security. b. Interconnection (cross-connects). c. From BF to LEA, including physical connection, protocols, bandwidth, security. 3.

39、 Installation Services/Assistance: a. Qualified/Certified Personnel. 4. Geographic Location of BF. 5. Security: a. Building. b. Cage Area. c. Facilities. d. Access/Entrance Procedures. e. Identification/Authorization List. 6. Environmental: a. Fire Suppression. b. Lighting. c. Heat Dissipation/Venti

40、lation. d. Cooling. e. Network Equipment Building System (NEBS)7 Compliance. 7. Power and Grounding Requirements: a. AC Voltage. b. DC Voltage. 7NEBS is the most common set of safety, spatial, and environmental design guidelines applied to telecommunications equipment in the United States. The NEBS

41、equipment design guidelines are described in Telcordia documents: GR-63, NEBS Requirements: Physical Protection. GR-1089, Electromagnetic Compatibility and Electrical Safety - Generic Criteria for Network Telecommunications Equipment. ATIS-1000021 12 c. Redundant Power Feeds. d. Power Backup/ Uninte

42、rruptible Power Supply (UPS). e. Grounding Bus. 8. Reliability Factor: a. Alternate Facilities. b. Alternate Site. 9. LEA provided Buffering Equipment: a. NEBS Compliance. 10. Service Level Agreement. ATIS-1000021 13 Annex B (normative) B ASN.1 DEFINITION OF INTERCEPT LOG - ATIS-0x0000x-YYYY ANNEX B

43、 - IAS Buffering Log Abstract Syntax Module IAS-Buffering-Log-Abstract-Syntax-Module iso(1) member-body(2) us(840) tia(113737) laes(2) t1(1) t1-ias(1) buffering-log(3) version-1(0) DEFINITIONS IMPLICIT TAGS := BEGIN IMPORTS ; - OID for IAS-Buffering-Log-Abstract-Syntax-Module IAS-Buffering-Log-Abstr

44、act-Syntax-Module-OID := OBJECT IDENTIFIER InterceptLogRecord := CHOICE sys-def 0 SystemDefinition, file-complete 1 FileCompletion, file-delete 2 FileDeletion, stat 3 Statistic SystemDefinition := SEQUENCE mod 0 Model, vers 1 Version, bfId 2 BfId FileCompletion := SEQUENCE file 0 FileName, digest 1

45、HashDigest FileDeletion := SEQUENCE file 0 FileName, time 1 GeneralizedTime, delete-reason 2 FileDeleteReason Statistic := CHOICE dropped 0 DroppedPackets Model := VisibleString Version := SEQUENCE maj 0 MajorVersion, min 1 MinorVersion MajorVersion := INTEGER MinorVersion := INTEGER BfId := Visible

46、String FileName := VisibleString HashDigest := OCTET STRING FileDeleteReason := CHOICE deletedbyCF 0 NULL, administrative 1 NULL DroppedPackets := SEQUENCE drops 0 Drops, timePeriod 1 GeneralizedTime Drops := INTEGER END - of IAS-Buffering-Log-Abstract-Syntax-Module ATIS-1000021 14 Annex C (normativ

47、e) C LIBPCAP FILE FORMAT PCAP (also called libpcap) files are a de facto industry standard way for software tools to store network packets. The format has been stable and in widespread use for many years, but has not been the subject of a published standard or RFC. Thus, the format used in the BF is

48、 documented in this Annex. A PCAP file consists of a global header followed by zero or more packet records. A packet record consists of a fixed-length PCAP packet header followed by the packet. The global header consists of 24 octets of information, shown below as a C language type definition: struc

49、t pcap_hdr_s guint32 magic_number; guint16 version_major; guint16 version_minor; gint32 thiszone; guint32 sigfigs; guint32 snaplen; guint32 network; ; In the above type definition, the following elements are defined: magic_number: Used to detect the file format itself and the byte ordering. The writing application writes 0xa1b2c3d4 with its native byte ordering format into this field. version_major, versi