Sponsored by the Alliance for Telecommunications Industry Solutions. Generic Guidelines for the use of TCP/IP in Electronic Bonding

Transcription

1 Sponsored by the Alliance for Telecommunications Industry Solutions Generic Guidelines for the use of TCP/IP in Electronic Bonding TCIF Issue 1 12/08/1999

2 Copyright TCIF Guideline Use of TCP/IP in Electronic Bonding Generic Guidelines for use of TCP/IP in Electronic Bonding Prepared for TCIF by the Electronic Communications Implementation Committee. For more information about TCIF, go to To order this document, please contact TCIF at (202) , FAX (202) If you have questions or comments about this document, please contact: Alliance for Telecommunication Industry Solutions 1200 G St. NW, Suite 500 Washington, D.C (phone) (fax) Copyright 1999 ATIS. This document is printed and distributed by the Alliance for Telecommunications Industry Solutions ("ATIS") on behalf of the Telecommunications Industry Forum ("TCIF"). Participants in TCIF are hereby authorized to reproduce this document and distribute it within their own business organizations and to others for TCIFrelated business provided that this notice continues to appear in the reproduced documentation. Reproduction and distribution for resale is prohibited. TCIF Issue 1 Page 2 12/08/1999

3 TCIF Guideline Use of TCP/IP in Electronic Bonding Contents Table of Contents 1 Purpose Scope Access Architecture and Standards Access Topology Options Physical and Data Link Layers Configuration Requirements Network Interoperability Protocol Interoperability Bandwidth and Scalability Configuration Requirements TCP versus OSI Transport Class TP TCP/IP Security Security for EDI over TCP/IP Security for CMIP Over TCP/IP Upper Layer Security Peer Entity Authentication Data Origin Authentication Whole PDU Protection Security for CORBA Over TCP/IP References...14 List of Figures Figure 1. Applicable Protocol Standards for EB over TCP/IP...6 Figure 2. Applicable Protocol Standards for CORBA over TCP/IP...6 Figure 3. Applicable Protocol Standards for EDI over TCP/IP...7 Figure 4. Applicable Protocol Standards for CMIP over TCP/IP...8 Figure 5. Sample Network Topology for EB over TCP/IP...9 Issue 1 TCIF /08/1999 Page 3

4 List of Acronyms TCIF Guideline Use of TCP/IP in Electronic Bonding List of Acronyms ACSE Association Control Service Element ANSI American National Standards Institute ATIS Alliance for Telecommunication Industry Solutions CA Certification Authority CBC Cipher Block Chaining CMIP Common Managed Information Protocol CMISE Common Management Information Service Element CORBA Common Object Request Broker Architecture DES Digital Encryption Standard EB Electronic Bonding IETF Internet Engineering Task Force IIOP Internet Inter ORB Protocol IP Internet Protocol ISO International Organization for Standardization ITU International Telecommunications Union ITU-T International Telecommunications Union Telecommunications MD Message Digest OAM&P Operation, Administration, Maintenance and Provisioning ORB Object Request Broker OSI Open Systems Interconnection ROSE Remote Operation Service Element RSA Rivest Shamir Adelman SHA Secure Hash Algorithm SNI Subscriber Network Interface SSL3 Secure Socket Layer version 3 TCIF Telecommunications Industry Forum TCP Transmission Connection Protocol TLS Transaction Layer Security TCIF Issue 1 Page 4 12/08/1999

5 TCIF Guideline Purpose Use of TCP/IP in Electronic Bonding 1 1 Purpose The purpose of this document is to outline a recommendation for the use of TCP/IP as a generic transport for Electronic Bonding (EB) Gateways as proposed by the ITU-T in standards Q.811 and Q.812. It is intended that this recommendation be used for any application level gateway. This includes (but is not limited to) those gateways using EDI (ANSI X12), CORBA, or CMIP at the application layer. This recommendation incorporates and supercedes the two previous TCIF Connectivity documents (TCIF Lower Layer Protocol Specifications for EDI over TCP/IP, TCIF Lower Layer Protocol Specifications for CMIP over TCP/IP ). It is intended that any future changes to recommendations for connectivity using TCP/IP will be made as updates to this current document. 2 Scope This document provides for the addition of TCP/IP (Internet Engineering Task Force RFCs 793, 791) for use as a generic transport for any Electronic Bonding application as specified in ITU-T Q.811/Q Access Architecture and Standards This document supports the implementation of protocol stacks that use TCP/IP. Stacks may differ slightly depending on what is running at the application layer. The following figures present protocol stacks currently supported by this document. Applicable connectivity standards are referenced in each case for the four lower layers. Future TCP/IP based applications will be addressed as the need arises. Figure 1 depicts a generic protocol stack for connecting Electronic Bonding Gateways over TCP/IP. If CMIP is used in the Application Layer then RFC 1006 is included in the transport layer. TLS (RFC 2246) is used for security. For those implementations still using SSL3 it is recommended that they consider upgrading to TLS. More specifics can be found in the example protocol stacks below. Issue 1 TCIF /08/1999 Page 5

6 Access Architecture & Standards TCIF Guideline 3 Use of TCP/IP in Electronic Bonding Application Layer Presentation Layer Session Layer Transport Layer SSL3 or TLS RFC 2246 RFC1006 for CMIP TCP RFC 793 Network Layer IP RFC 791 Data Link Layer LLC, ATM, X.25, ISDN, Frame Relay, SMDS Physical Layer Ethernet, Token Ring, FDDI, SNI, V.35, SONET, RS-449, EIA-232D Figure 1. Applicable Protocol Standards for EB over TCP/IP Figure 2 depicts the protocol stack recommended for CORBA over TCP/IP. Security options include SSL3 or TLS (see section 6 for more details). CORBA incorporates GIOP (Generic Inter-ORB Protocol) and IIOP (Internet Inter-ORB Protocol) to allow for communication over TCP/IP. Document TCIF , CORBA Implementation Profile for Electronic Communications contains additional information on GIOP and IIOP. Application Layer (CORBA, GIOP, IIOP) Transport Layer SSL3 or TLS RFC 2246 TCP RFC 793 Network Layer IP RFC 791 Data Link Layer LLC, ATM, X.25, ISDN, Frame Relay, SMDS Physical Layer Ethernet, Token Ring, FDDI, SNI, V.35, SONET, RS-449, EIA-232D Figure 2. Applicable Protocol Standards for CORBA over TCP/IP TCIF Issue 1 Page 6 12/08/1999

7 TCIF Guideline Access Architecture & Standards Use of TCP/IP in Electronic Bonding 3 Figure 3 depicts a protocol stack for running an EDI application gateway over TCP/IP. In this case the Interactive Agent (defined in TCIF ) runs above the transport layer. The Interactive Agent provides session layer functionality for EDI. It can also provide nonrepudiation and/or whole message integrity protection. As in figure 1, SSL3 or TLS provide security at the transport layer. Upper Layer EDI (ANSI X12) IA -Interactive Agent Transport Layer SSL3 or TLS RFC 2246 TCP RFC 793 Network Layer IP RFC 791 Data Link Layer LLC, ATM, X.25, ISDN, Frame Relay, SMDS Physical Layer Ethernet, Token Ring, FDDI, SNI, V.35, SONET, RS-449, EIA-232D Figure 3. Applicable Protocol Standards for EDI over TCP/IP Figure 4 depicts a protocol stack running CMIP over TCP/IP in accordance with RFC Note that T1.256 is simply an example of an application that could be used with this protocol stack. The stack is applicable to any CMIP-based application layer standard. Issue 1 TCIF /08/1999 Page 7

8 Access Architecture & Standards TCIF Guideline 3 Use of TCP/IP in Electronic Bonding ANSI T1.256 (PROVISIONING) CMISE/CMIP ISO 9595/9596 ACSE ISO 8649/8650. ROSE, STASE ROSE Presentation Layer ISO 8822/8823 Basic encoding rules (BER) ISO 8825 Session Layer ISO 8326/8327 Transport Layer RFC1006 SSL3 or TLS RFC 2246 TCP RFC 793 Network Layer IP RFC 791 Data Link Layer LLC, ATM, X.25, ISDN, Frame Relay, SMDS Physical Layer Ethernet, Token Ring, FDDI, SNI,V.35,SONET, RS- 449, EIA-232D Figure 4. Applicable Protocol Standards for CMIP over TCP/IP 4 Access Topology Options Figure 5 shows a typical TCP/IP based configuration. For the purpose of this document the encryption devices should be considered optional; their use is dependent on the nature of the application data to be exchanged. The use of firewalls (screening routers or proxy servers) is highly recommended. Routers are required for an internetwork based connection. The router or firewall must allow the specified TCP port on which application traffic is to pass. Point to point connections are also possible using this protocol stack. If the application layer is running CMIP, then the transport layer will have to be compliant with RFC 1006 as well as RFC 793. If the application layer is running EDI, then the Interactive Agent, as specified in TCIF , Electronic Communications Interactive Agent Functional Specifications", must be running above the transport layer. TCIF Issue 1 Page 8 12/08/1999

9 TCIF Guideline Access Topology Options Use of TCP/IP in Electronic Bonding 4 Application Layer Presentation Layer Interactive Agent Transport Session Layer SSL3 or TLS TCP RFC 793 (RFC 1006) Network Layer IP RFC 791 Data Link Layer LLC, ATM, X.25, ISDN, Frame Relay, SMDS Physical Layer Ethernet, Token Ring, FDDI, SNI, V.35, Sonet, RS-449, EIA232D Application Layer Presentation Layer Interactive Agent Transport Session Layer SSL3 or TLS TCP RFC 793 (RFC 1006) Network Layer IP RFC 791 Data Link Layer LLC, ATM, X.25, ISDN, Frame Relay, SMDS Physical Layer Ethernet, Token Ring, FDDI, SNI, V.35, Sonet, RS-449, EIA232D Screening Router (Firewall) Point to Point or Internetwork Connection Screening Router (Firewall) Figure 5. Sample Network Topology for EB over TCP/IP 4.1 Physical and Data Link Layers As depicted in Figure 5, the physical and data link layers of the protocol stack may be chosen from a large number of alternatives when using TCP/IP, depending on throughput requirements. The TCP/IP protocol stack may be run over, for example Frame Relay, FDDI, ATM, X.25, SMDS, Token Ring or Token Bus topologies, and over point to point T1. The choice of lower layers should be made by each company, or pair of bonded companies, based on their internal policies and throughput requirements. 5 Configuration Requirements 5.1 Network Interoperability Any network supporting TCP/IP will work. This includes dedicated circuits (e.g. 9.6 kbps, 56 kbps, 256 kbps, T1-T3, etc) and the Internet. 5.2 Protocol Interoperability IPv4 is the version of IP currently deployed worldwide. It has been in existence and utilized for the past twelve years. This document recommends the use of IPv4 for Electronic Bonding applications. Issue 1 TCIF /08/1999 Page 9

10 Configuration Requirements TCIF Guideline 5 Use of TCP/IP in Electronic Bonding Currently, IPv6 is being developed and will be deployed world wide to provide additional functionality to IP users (see IETF RFC 1752). It is expected that IPv6 will be incorporated into Electronic Bonding implementation guidelines when IPv6 becomes widely available. 5.3 Bandwidth and Scalability The bandwidth supported by TCP/IP ranges from a few kbps to gigabits per second. A T1 for each interface will allow more than adequate bandwidth for current needs and growth. To increase network capacity, a larger pipe such as a T3 can be put into place without affecting the architecture of an Electronic Bonding gateway. In fact one of the primary benefits of the use of TCP/IP is the ease of changing the data link layer to provide the necessary throughput. 5.4 Configuration Requirements Stacks utilizing TCP/IP are available from several suppliers. Specific configuration requirements are a joint implementation issue for negotiation between implementing companies. 5.5 TCP versus OSI Transport Class TP-4 This section addresses the concern regarding the use of RFC 1006 with TP-0. RFC 1006 uses only transport class TP-0 at this time. This does not pose a problem for Electronic Bonding because RFC 1006 is implemented on top of TCP and TCP provides the same functionality as transport class TP-4 as indicated in Table 1. 6 TCP/IP Security Functions TP-4 TCP Flow control x x Window Management x x Handles recovery x x Error detection x x TABLE 1 Two communicating trading partners can agree on any level of security for their mutual interface and on any method for supporting the agreed-upon level of security. This section offers complete and detailed guidelines for an adequate level of security for Electronic Bonding applications. The security specified in these guidelines is based on the Transport Layer Security (TLS) standard developed by the Internet Engineering Task Force (IETF). For those implementations still using SSL3 it is recommended that they consider upgrading to TLS. The selection of TLS is based, in part, on the following assumptions and considerations: Electronic Bonding transactions can be carried directly over TCP/IP. Inclusion of TLS between the Electronic Bonding gateway application and TCP (Transport Control Protocol) does not impact the gateway application (with the possible exception of a configuration change such as different port number). In the course of a session: 1. The application instructs TCP to establish a connection, which it does TCIF Issue 1 Page 10 12/08/1999

11 TCIF Guideline TCP/IP Security Use of TCP/IP in Electronic Bonding 6 2. The application instructs TLS to establish a secure connection, which it does through the TLS handshaking mechanism 3. Electronic Bonding gateway messages are typically handed over to TLS using a TLS toolkit Application Programming Interface (API). These messages may be fragmented or combined by TLS, subjected to security transformations, delivered to the receiver. At the receiver the security transformations are reversed and/or verified, the original Electronic Bonding gateway messages are reconstructed and delivered to the TLS client. Transport Layer Security shall be used to secure Electronic Bonding gateway transactions with the following guidelines: Strong peer entity authentication, based on public key encryption shall be provided for all associations (this precludes interoperability with SSL2) Session secret shall be encrypted with receiver s public key Message encryption is optional SHA1 shall be used for integrity by TLS If privacy protection by TLS is chosen, then TDES (Triple Data Encryption Standard) in the EDE/CBC (Encrypt-Decrypt-Encrypt/Cipher Block Chaining) mode shall be used for symmetric key encryption. Alternatively, DES in the CBC mode may be used, but companies should be aware that this introduces more vulnerability, as there is a known attack on this encryption method Every participant is required to obtain a public key certificate from a CA acceptable to the communicating parties Message integrity and non-repudiation shall be computed on clear text (unencrypted) messages, Entity public key size shall be at least 1024 bits Certification Authority s public key size shall be at least 2048 bits Certificates shall be X.509 version 3. The following cipher suites will be supported: RSA_NULL_SHA1 (if no privacy protection is desired) RSA_DES CBC_SHA1 (if privacy protection is desired) Resumable sessions do not present any additional threat 6.1 Security for EDI over TCP/IP EDI transactions can be carried directly over TCP/IP. Inclusion of TLS between EDI and TCP does not impact EDI (with the possible exception of a configuration change such as different port number). In the course of a session, the application instructs TCP to establish a connection, which it does. The application instructs TLS to establish a secure connection, which it does through the TLS handshaking protocol. EDI messages are handed over to TLS using a TLS toolkit Application Programming Interface (API). These messages may be fragmented or combined by TLS, subjected to security transformations, and delivered to the receiver. At the receiver the security transformations are reversed, the original EDI messages are reconstructed and delivered to the TLS client. Non-repudiation or message integrity can be provided under EDI by the Interactive Agent (IA). If the IA provides message integrity, it shall use SHA1 to produce the message digest (MD). If the IA provides non-repudiation, it shall compute the message digest of the EDI Issue 1 TCIF /08/1999 Page 11

12 TCP/IP Security TCIF Guideline 6 Use of TCP/IP in Electronic Bonding data using the SHA1 digest algorithm and then digitally sign the message by applying the RSA signature algorithm to the digest. 6.2 Security for CMIP Over TCP/IP This section specifies the security measures to be provided over the Electronic Bonding CMIP/TCP/IP interface. When CMIP is carried over TCP/IP it can use TLS for security. In this case the application must instruct TLS to establish a secure connection before invoking ACSE to establish the association. TLS should be used with the same specifications as provided at the beginning of Section 6 of this document. In addition, further security measures can be provided in the upper layers of the protocol stack. They are included here for reference. Three types of security features are addressed in this document: External encryption devices IP network layer security Upper layer security External encryption devices (hardware or software) can be interposed between each of the communicating systems and the network. Their use and configuration are dependent on joint implementation agreements between bonded companies. IP security is provided through firewalls. It is recommended that firewalls be deployed to provide functionality analogous to Closed User Groups in X.25 networks. Upper Layer security is discussed in more detail below Upper Layer Security This document addresses the security of TMN management messages exchanged over the TMN X interface. It offers three levels of security: 1. Peer entity authentication 2. Data origin authentication 3. Whole Protocol Data Unit (PDU) protection. Which of the three levels of security is to be used is application dependent. However, this document specifies the following: Peer entity authentication shall always be provided. In addition data origin authentication or whole PDU protection shall be provided. Data origin authentication shall not be used if whole PDU protection is provided. Indeed, the mechanisms for whole PDU protection specified in this document implicitly provide data origin authentication. This document supports five types of whole PDU protection: confidentiality integrity non-repudiation confidentiality with non-repudiation confidentiality with integrity. TCIF Issue 1 Page 12 12/08/1999

13 TCIF Guideline TCP/IP Security Use of TCP/IP in Electronic Bonding 6 It is application dependent which of those five, if any, to use during any given association. Access control is a major component of security, however implementation of access control is a local matter that does not affect interoperability, it is therefore not discussed in this document. (For a discussion of access control and access control management in the TMN see ANSI T1.261.) Peer Entity Authentication For peer entity authentication both the initiator and the responder of an association will use the authenticator described in T1.259, it shall be carried in the Authentication Functional Unit of the ACSE AARQ and AARE messages respectively. The (optional) publicly encrypted symmetric encryption keys in the AARQ and AARE messages can be different, allowing the initiator and the responder of the association to use different keys in the course of the association Data Origin Authentication This document specifies data origin authentication only for CMIP PDUs that have the access control field, i.e., m-get, m-set, m-create, m-delete, and m-action. Data origin authentication shall be provided by putting an authenticator in the CMIP access control field. The authenticator shall consist of: the unique identity of the sender an Initialization Vector (IV) an encrypted string consisting of a time stamp followed by a sequence number encrypted with a shared symmetric encryption key. The authenticator is fully specified in T1 Technical Report Number Whole PDU Protection Protection of whole PDUs, when desired, shall be accomplished by using STASE-ROSE (T ). STASE-ROSE protects ROSE PDUs by applying selected security transformations (ST) to whole ROSE PDUs encoded with the Distinguished Encoding Rules (DER). The use of STASE-ROSE shall be as specified in ANSI T Security for CORBA Over TCP/IP Two communicating trading partners can agree on any level of security for their mutual interface and on any method for supporting the agreed level of security. This document offers complete and detailed guidelines for the use of TLS to protect CORBA messages. The security specified in these guidelines is based on the Transport Layer Security (TLS) standard developed by the Internet Engineering Task Force (IETF). For those implementations still using SSL3 it is recommended that they consider upgrading to TLS. The selection of TLS is based, in part, on the following considerations: Issue 1 TCIF /08/1999 Page 13

14 TCP/IP Security TCIF Guideline 6 Use of TCP/IP in Electronic Bonding CORBA IIOP transactions can be carried directly over TCP/IP. inclusion of TLS between IIOP and TCP (Transport Control Protocol) does not impact IIOP (with the possible exception of a different port number). in the course of a session IIOP messages are handed over to TLS. These messages may be fragmented or combined by TLS, subjected to security transformations, delivered to the receiver. At the receiver the security transformations are reversed, the original IIOP messages are reconstructed. Transport layer Security (TLS) shall be used to secure IIOP transactions with the following guidelines: Strong peer entity authentication, based on public key encryption shall be provided for all associations (this precludes interoperability with SSL2) Session secret shall be encrypted with receiver s public key Message encryption is optional SHA1 shall be used for integrity by TLS Non-repudiation or message integrity can be provided, optionally, by higher layers. If privacy protection by TLS is chosen, than TDES (Triple Data Encryption Standard) in the EDE/CBC (Encrypt-Decrypt-Encrypt/Cipher Block Chaining) mode shall be used for symmetric key encryption. Alternatively, DES in the CBC mode may be used, but companies should be aware that this introduces more vulnerability, as there is a known attack on this encryption method Every participant is required to obtain a public key certificate from a CA acceptable to the communicating parties Message integrity and non-repudiation shall be computed on clear text (unencrypted) messages, Entity public key size shall be at least 1024 bits Certification Authority s public key size shall be at least 2048 bits Certificates shall be X.509 version 3. The following ciphersuites will be supported: RSA, NULL, SHA1 (if no privacy protection is desired) RSA, DES - CBC, SHA1 (if privacy protection is desired) Resumable session If non-repudiation protection is needed for CORBA transactions then Telecommunications Non-repudiation Inter-ORB Protocol (TCIF####) shall be used. 7 References TCIF - Telecommunications Industry Forum primarily develops technology specific implementation guidelines for use within the industry to realize a variety of intercommunication services. TCIF Issue 1 Page 14 12/08/1999

15 TCIF Guideline References Use of TCP/IP in Electronic Bonding 7 TCIF Electronic Communications Interactive Agent Functional Specification ISO - The International Organization for Standardization is a worldwide federation of national standards bodies from over 130 countries. The mission of ISO is to promote the development of standardization and related activities in the world with a view to facilitating the international exchange of goods and services, and to developing cooperation in the spheres of intellectual, scientific, technological and economic activity. In the context of this document, technology specified in the following ISO/IEC common text publication is incorporated herein by reference: ISO/IEC 8072:1996 Information technology Open systems interconnection Transport service definition ISO/IEC 8073:1997 Information technology Open Systems Interconnection Protocol for providing the connection-mode transport service ISO/IEC 8326:1996 Information technology Open Systems Interconnection Session service definition ISO/IEC :1996 Information technology Open Systems Interconnection Connection-oriented Session protocol: Protocol specification ISO/IEC 8649:1996 Information technology Open Systems Interconnection Service definition for the Association Control Service Element ISO/IEC :1996 Information technology Open Systems Interconnection Connection-oriented protocol for the Association Control Service Element: Protocol specification ISO/IEC :1996 [ANSI/IEEE Std , 1996 Edition] Information Technology Telecommunications and information exchange between systems Local and metropolitan area networks Specific requirements Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specification ISO/IEC 8822:1994 Information technology Open Systems Interconnection Presentation service definition ISO/IEC :1994 Information technology Open Systems Interconnection Connection-oriented presentation protocol: Protocol specification ISO/IEC :1995 Information technology ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) ISO/IEC 9595:1991 Information technology Open systems Interconnection -- Common management information service definition ISO/IEC :1991 Information technology Open Systems Interconnection Common management information protocol -- Part 1: Specification ANSI - The American National Standards Institute or ANSI is the coordinator and clearinghouse for national standards in the United States. ANSI does not write national standards, it charters organizations called 'Accredited Standards Committees' or ASCs, composed of voluntary representatives from industry, labor, consumer, and government to prepare consensus standards. Upon public comment and approval, ANSI ASCs publish national standards. Issue 1 TCIF /08/1999 Page 15

16 References TCIF Guideline 7 Use of TCP/IP in Electronic Bonding ANSI T OAM&P - Model for Interface Across Jurisdictional Boundaries to Support Electronic Access Service Ordering: Inquiry Function ANSI T STASE-ROSE ANSI T OAM&P - Security for TMN Management Transactions over the TMN Q3 Interface Accredited Standards Committee T1 This committee produces standards for the telecommunications industry. It is accredited by ANSI. T1 TR No. 40 May Security Requirements for Electronic Bonding Between Two TMNs Accredited Standards Committee (ASC) X12 of ANSI This committee is chartered to develop the structure, format, and content of electronic business transactions conducted through Electronic Data Interchange (EDI). This document incorporates, by reference, the various EDI standards produced by this committee IETF - Internet Engineering Task Force RFC 0791 Internet Protocol. RFC 0793 Transmission Control Protocol RFC 1883: Internet Protocol, Version 6 (IPv6) Specification RFC 1006: ISO transport services over TCP: Version: 3 Internet Draft; The SSL Protocol, Version 3.0; Freier, et al.; November 18, 1996 Internet Draft; The TLS Protocol, Version 1.0; Dierks, et al.; March 6, 1997 Note: TLS is currently an Internet Draft. Once it has been adopted as a formal standard, it is intended to supersede and replace the de facto standard - SSL3. Netscape Communications Corporation developed the original specification for SSL3 and contributed it to the IETF. ITU-T - The International Telecommunication Union (ITU) is a treaty based organization operating under the auspices of UNICEF (a branch of the United Nations). The ITU s primary mission is to study, promote, initiate and design global telecommunication services and technology to improve the quality of life for all of the world s inhabitants. During the World Telecommunication Service Conference (WTSC) of 1991, it was reorganized into three sectors: the Technology sector (titled ITU-T), Radio sector (titled ITU-R) and the Telecom Service Bureau sector (titled ITU-TSB) to handle administrative and publication matters. In the context of this document, technology specified in the following ITU and ISO/IEC common text publications are incorporated herein by reference: Rec. Q.811 (1997) Lower layer protocol profiles for the Q3 and X interfaces Rec. Q.812 (1997) Upper layer protocol profiles for the Q3 and X interfaces Rec. X.25 (1996) 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 TCIF Issue 1 Page 16 12/08/1999