Stable Implementation Agreements for Open Systems Interconnection Protocols: Part 4 - Transport Output from the December 1993 Open Systems Environment Implementors' Workshop (OIW) SIG Chair: Fred Burg, AT&T SIG Editor: Brenda Gray PART 4 - TRANSPORT December 1993 (Stable) Foreword This part of the Stable Implementation Agreements was prepared by the Lower Layers Special Interest Group (LLSIG) of the Open Systems Environment Implementors' Workshop (OIW). See Part 1 - Workshop Policies and Procedures of the "Draft Working Implementation Agreements Document" for the charter. Text in this part has been approved by the Plenary of the above- mentioned Workshop. This part replaces the previously existing chapter on this subject. Future changes and additions to this version of these Implementor Agreements will be published as change pages. Deleted and replaced text will be shown as strikeout. New and replacement text will be shown as shaded. ii PART 4 - TRANSPORT December 1993 (Stable) Table of Contents Part 4 - Transport . . . . . . . . . . . . . . . . . . . . . 1 0 Introduction . . . . . . . . . . . . . . . . . . . . . . 1 1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Normative References . . . . . . . . . . . . . . . . . . 1 2.1 CCITT . . . . . . . . . . . . . . . . . . . . . . . 1 2.2 ISO . . . . . . . . . . . . . . . . . . . . . . . . 1 3 Status . . . . . . . . . . . . . . . . . . . . . . . . . 2 4 Errata . . . . . . . . . . . . . . . . . . . . . . . . . 2 5 Provision of Connection Mode Transport Service . . . . . 2 5.1 Transport Class 4 . . . . . . . . . . . . . . . . . 3 5.1.1 Transport Class 4 Overview . . . . . . . . 3 5.1.2 Protocol Agreements . . . . . . . . . . . . 3 5.1.2.1 General Rules . . . . . . . . . . . . . . . 3 5.1.2.2 Transport Class 4 Service Access Points or Selectors . . . . . . . . . . . . . . . . . 5 5.1.2.3 Retransmission Timer . . . . . . . . . . . 5 5.1.2.4 Keep-Alive Function . . . . . . . . . . . . 8 5.1.2.5 Congestion Avoidance Policies . . . . . . . 9 5.1.2.6 Use of Priority . . . . . . . . . . . . . . 12 5.2 Transport Class 0 . . . . . . . . . . . . . . . . . 12 5.2.1 Transport Class 0 Overview . . . . . . . . 12 5.2.2 Protocol Agreements . . . . . . . . . . . . 12 5.2.2.1 General Rules . . . . . . . . . . . . . . . 12 5.2.2.2 Transport Class 0 Service Access Points . . 13 5.2.3 Rules for Negotiation . . . . . . . . . . . 13 5.3 Transport Class 2 . . . . . . . . . . . . . . . . . 13 5.3.1 Transport Class 2 Overview . . . . . . . . 13 5.3.2 Protocol Agreements . . . . . . . . . . . . 13 6 Provision of Connectionless Transport Service . . . . . . 14 6.1 Connectionless Transport Overview . . . . . . . . . 14 6.2 Protocol Agreements . . . . . . . . . . . . . . . . 14 6.2.1 General Rules . . . . . . . . . . . . . . . 14 6.2.2 Connectionless Transport Service Access Points or Selectors . . . . . . . . . . . . 14 7 Transport Protocol Identification . . . . . . . . . . . . 15 8 Security . . . . . . . . . . . . . . . . . . . . . . . . 16 iii PART 4 - TRANSPORT December 1993 (Stable) 8.1 ISO/IEC 10736 Transport Layer Security Protocol (TLSP) . . . . . . . . . . . . . . . . . . . . . . . 16 8.2 Services . . . . . . . . . . . . . . . . . . . . . . 16 8.3 Mechanisms . . . . . . . . . . . . . . . . . . . . . 16 8.4 Protocol Constraints . . . . . . . . . . . . . . . . 17 8.5 Functional Security Sequence Ordering . . . . . . . 17 iv PART 4 - TRANSPORT December 1993 (Stable) List of Figures Figure 1 - AK exchange on idle connection. . . . . . . . . . 9 v PART 4 - TRANSPORT December 1993 (Stable) List of Tables Table 1 - Protocol Identification TPDU Values . . . . . . . . 15 vi Part 4 - Transport 0 Introduction These agreements support the integration of LANs, packet networks, and other WANs with the smallest possible set of mandatory protocol sets, in accordance with the other agreements already reached. Nothing here shall preclude vendors from implementing protocol suites in addition to the ones described in this document. 1 Scope This part presents agreements for providing the OSI Transport layer services over both connection mode and connectionless mode services. 2 Normative References 2.1 CCITT [1] Recommendation X.214 (Blue Book, 1988), Transport Service Definition for Open Systems Interconnection for CCITT Applications. [2] Recommendation X.224 (Blue Book, 1988), Transport Protocol Specification for Open Systems Interconnection for CCITT Applications. 2.2 ISO [3] ISO 8072, Information processing systems - Open systems interconnection - Transport service defintion. [4] ISO 8072 Addendum 1, Information processing systems - Open systems interconnection - Addendum 1: Transport service definition - Connectionless-mode transmission. [5] [5] ISO/IEC 8073:199x,Edition 3, Information Technology- Telecommunications and Information Exchange Between Systems - Open Systems Interconnection - Protocol for Providing the Connection-mode Transport Service, (SC6N7589 Rev). [6] ISO 8602, Information processing systems - Open systems 1 PART 4 - TRANSPORT December 1993 (Stable) interconnection - Protocol for providing the connectionless- mode transport service. [7] ISO/IEC 10736, Information Technology - Telecommunications and Information Exchange Between Systems -Transport Layer Security Protocol 3 Status Completed December 1993. 4 Errata NOTE - This clause may contain "defect report" and resolutions material, and the versions of implementor agreements to which this material applies. 5 Provision of Connection Mode Transport Service Three connection mode protocol classes have been identified for implementation. Transport classes 0, 2 and 4 of X.224 (1988)1 have been endorsed for use over CONS. Only Transport Class 4 of ISO 8073/Add. 2 2 has been endorsed for use over CLNS. The following class combinations are endorsed for CONS: (0), (0,2) or (0,2,4). 1 Where a CR TPDU proposing Class 2 or 4 is initiated, Class 0 shall be explicitly indicated as an alternative class except if there is already one (or several) transport connection(s) assigned to the network connection (multiplexing being possible). 2 In general, references to ISO 8073 in ISO 8073/Add. 2 should be interpreted as applying to X.224 (1988); however, the reference to Clause 14.6.a in Clause 14 of ISO 8073/Add. 2 should be interpreted as a reference to Clause 14.5.a of X.224(1988). 2 PART 4 - TRANSPORT December 1993 (Stable) 5.1 Transport Class 4 5.1.1 Transport Class 4 Overview Transport Class 4 is mandatory for communication between systems using the OSI CLNS and may also be used for systems using the OSI CONS (e.g., a private MHS, etc.). 5.1.2 Protocol Agreements A disconnect request shall be issued in response to a connect request when the maximum number of Transport connections is reached or exceeded. 5.1.2.1 General Rules The rules are as follows: a) All implementations shall request "use of extended formats" in the CR TPDU. Implementations shall accept the "use of extended formats" in the CC TPDU if it was proposed in the CR TPDU. Implementations shall accept "use of normal formats" if it was proposed in the CR TPDU; b) Negotiation of protection is outside the scope of these agreements. If negotiation of protection is not supported, receipt of the protection parameters in CR TPDU and CC TPDU shall be ignored; c) Implementations shall be capable of proposing and accepting the non-use of checksums; NOTE - See clause 8.2 for more information on checksums when the Transport Protocol and the Transport Layer Security Protocol are both implemented. d) Use of the acknowledgment time parameter is optional. If an implementation is operating any policy which delays the transmission of AK TPDUs, the maximum amount of time by which a single AK TPDU may be delayed shall be indicated to the peer Transport service provider using the acknowledgment time parameter. The value transmitted should be expressed in units of milliseconds and rounded up to the nearest whole millisecond; e) QoS negotiation is outside the scope of these 3 PART 4 - TRANSPORT December 1993 (Stable) agreements. If QoS negotiation is not supported, receipt of the parameters "throughput," "residual error rate," "priority," and "transit delay" in the CR and CC TPDUs shall be ignored; f) It is recommended that implementations not send user data in the CR TPDU or the CC TPDU. The disposition of any user data received in a CR TPDU or CC TPDU is implementation dependent; g) It is recommended that implementations not send user data in the DR TPDU. The disposition of any user data received in a DR TPDU is implementation dependent; h) An unknown parameter in any received CR TPDU shall be ignored; i) A Transport entity shall accept a DR TPDU and a corresponding DC TPDU with or without a checksum in response to a CR or CC TPDU; j) Transmitted DR TPDUs shall carry a disconnect reason code which pertains to the actual cause of the disconnect. A DR TPDU may carry a reason code of "0" (unspecified) if an appropriate reason code is not defined; k) Known parameters with valid lengths but with invalid values in a CR TPDU shall be handled as follows: 1) Parameter; 2) Action: a) TSAP id a) Send DR TPDU b) TPDU size b) ignore parameter, use default c) Version c) ignore parameter, use default d) Checksum d) discard CR TPDU e) Alternate Protocol Classes e) Protocol Error l) Unrecognized or not applicable bits of the Additional Options parameter shall be ignored. m) It is recommended that the capability of request acknowledgments be supported and proposed in CR TPDUs. If 4 PART 4 - TRANSPORT December 1993 (Stable) request acknowledgments are supported, then if the implementation delays acknowledgments it shall: 1) request use of request acknowledgments in the CR TPDU; 2) accept the use of request acknowledgments in the CC TPDU if it was proposed in the CR TPDU. n) It is recommended that implementations send both the preferred and existing TPDU size parameters in the CR TPDU. o) It is recommended that inactivity timer values be exchanged during connection establishment. This may be mandatory in the future. If the "exchange of inactivity timers" capability is supported, the implementation shall send its minimum inactivity timer in the CR TPDU. If a CR TPDU is received with this timer value and the capability is supported, the responding CC TPDU shall contain the inactivity time. If the Inactivity time is received and the capability is supported, the following shall be used as an upper bound for W: IR/N > W N > 2 5.1.2.2 Transport Class 4 Service Access Points or Selectors If present, the TSAP Id. field in the CR and CC TPDUs shall be encoded as a variable length field and will be interpreted as an octet string. The length of the string cannot exceed 32 octets. 5.1.2.3 Retransmission Timer It is recommended that the value used for the retransmission timer be based upon the round-trip delay experienced on a transport connection. The implementation should maintain, and continually update, an estimate of the round-trip delay for the TC. From this estimate, a value for the retransmission timer is calculated each time it is started. Example techniques for maintaining the estimate and calculating the retransmission timer are described below. Example 1 represents a simple retransmission strategy and example 2 is particularly suitable for networks subject to high traffic loads. Example 1 5 PART 4 - TRANSPORT December 1993 (Stable) The value of the retransmission timer may be calculated according to the following formula: T1 <--- kE + AR. In this formula, E is the current estimate of the round-trip delay on the transport connection, AR is the value of the acknowledgment time parameter received from the remote transport service provider during connection establishment, and k is some locally administered factor. A value for k should be chosen to keep the retransmission timer sufficiently small such that lost TPDUs will be detected quickly, but not so small that false alarms are generated causing unnecessary retransmission. The value of E may be calculated using an exponentially weighted average based upon regular sampling of the interval between transmitting a TPDU and receiving the corresponding acknowledgment. Samples are taken by recording the time of day when a TPDU requiring acknowledgment is transmitted and calculating the difference between this and the time of day when the corresponding acknowledgment is received. New samples are incorporated with the existing average according to the following formula: E <--- E + (1 - )(S - E). In this formula, S is the new sample and is a parameter which can be set to some value between 0 and 1. The value chosen for determines the relative weighting placed upon the current estimate and the new sample. A large value of weights the old estimate more heavily causing it to respond only slowly to variations in the round-trip delay. A small value weights the new sample more heavily causing a quick response to variations. (Note that setting to 1 will effectively disable the algorithm and result in a constant value for E, being that of the initial seed.) If is set to 1-2-n for some value of n, the update can be reduced to a subtract and shift as shown below: E <--- E + 2-n (S - E). When sampling, if an AK TPDU is received which acknowledges multiple DT TPDUs, only a single sample should be taken being the round-trip delay experienced by the most recently transmitted DT TPDU. This attempts to minimize in the sample any delay caused by the remote transport service provider withholding AK TPDUs. 6 PART 4 - TRANSPORT December 1993 (Stable) Example 2 As network load increases, the variability of round-trip delay also increases. In environments where load fluctuates widely, it is therefore useful to estimate the variability of round-trip delay measurements and use this estimate in the calculation of retransmission timer values. An estimate of the variability of round-trip delay measurements can be efficiently calculated as an exponentially weighted average of the differences between round- trip delay measurements and the average round-trip delay. This represents the mean deviation of the round-trip delays, which is a useful approximation of the standard deviation and can be much more efficiently computed. The formula is D <-- D + (1 - a)(|S - E| - D) where D is the estimate of variability in round-trip delays. S, E, and a are as defined for the preceding formula. As before the value of a must be between 0 and 1 and the choice of a value of 1 - 2-N allows for efficient update of the average. The value of a for the variability estimation, though, does not need to be the same as that used for the round-trip delay estimate. A smaller value for a is useful in the variability estimation to cause a more rapid response to changes in round-trip delays. D can then be used to calculate retransmission timer values according to the formula: T1 <-- E + AR + kD where T1 is the retransmission timer value, E is the estimated average round-trip delay, AR is the value of the acknowledgment timer parameter received from the remote transport service provider during connection establishment, and k is a locally administered factor. Since D approximates the standard deviation of the round-trip delays, but is greater than or equal to the standard deviation, round-trip delays within k standard deviations of the mean would be accounted for by the retransmission timer value (e.g., k = 2, if round-trip delays were normally distributed, would account for 95% of the variability). Round-trip time measurements based on acknowledgment of any retransmitted data should not be used to update the round-trip delay estimate or the estimate of variability. Such measurements are not reliable since it is ambiguous which transmission of the data is being acknowledged. One strategy for handling a retransmission timeout is to retransmit the PDU and reset the timer with a value that is twice 7 PART 4 - TRANSPORT December 1993 (Stable) the previous value. In this case, a new roundtrip delay estimate and estimate of variability should be calculated only when an acknowledgment of data is received where none of the acknowledged data has been retransmitted. This calculation uses the new round- trip delay measurement and the last estimate before the retransmission timeout(s). 5.1.2.4 Keep-Alive Function The Class 4 protocol detects a failed Transport connection by use of an "inactivity timer." This timer is reset each time a TPDU is received on a connection. If the timer ever expires, the connection is terminated. The Class 4 protocol maintains an idle connection by periodically transmitting an AK TPDU upon expiration of the "window timer." Thus, in a simple implementation, the interval of one transport entity's window timer must be less than that of its peer's inactivity timer, and vice versa. The following agreements permit communicating transport entities to maintain an idle connection without shared information about timer values: a) In accordance with ISO 8073/X.224, Clause 12.2.3.9.a, all implementations must respond to the receipt of a duplicate AK TPDU not containing FCC by transmitting an AK TPDU containing the "flow control confirmation" parameter; b) Implementations must always transmit duplicate AK TPDUs without FCC on expiration of the local window timer (see ISO 8073/X.224, Clause 12.2.3.8.1). Receipt of this TPDU by the remote Transport entity will cause it to respond with an AK TPDU containing the "flow control confirmation" parameter. When this is received by the local transport entity, it will reset its inactivity timer. See figure 1; c) It is a local matter for an implementation to set the intervals of its timers to appropriate relative values. Specifically: 1) The window timer must be greater than the round-trip delay. See 5.1.2.3; 2) The inactivity timer must be greater than two times the window timer; and should normally be an even greater multiple if the Transport connection is to be resilient to the loss of an AK TPDU. A duplicate AK TPDU (see figure 1) is one which contains the same 8 PART 4 - TRANSPORT December 1993 (Stable) values for YR-TU-NR, credit, and subsequence number as the previous AK TPDU transmitted. A duplicate AK TPDU does not acknowledge any new data, nor does it change the credit window. I W | | | | | | | | | ----+---- | duplicate | | expire | | AK | | | | | ----+---- | | AK + FCC | reset | | | | | | | | | | | | | ----+---- | duplicate | | expire | | AK | | | | | | | | | ----+---- | | AK + FCC | reset | | | | | | | | | | | | | ----+---- | | | expire | | | | | | | | | | | Figure 1 - AK exchange on idle connection. 5.1.2.5 Congestion Avoidance Policies This clause defines both mandatory and optional requirements relating to avoiding congestion in OSI networks and recovering from it when it is experienced. The mandatory requirements specify a minimum approach to congestion avoidance/recovery which can be tuned based upon the specific requirements of the network. The optional requirements specify a dynamic window sizing scheme which, if implemented, will contribute further to the avoidance of congestion in the network. Mandatory Requirements are as follows: a) A maximum size for the "receive credit window," the value of which is locally configurable, should be provided. A "receive credit window" reflects the number of credits sent by a Transport entity for a Transport connection. The maximum size of the "receive credit window" shall be referred to as WR1; 9 PART 4 - TRANSPORT December 1993 (Stable) b) A maximum size for the "sending credit window," the value of which is locally configurable, shall be provided. A "sending credit window" reflects the number of data TPDUs that a Transport entity is willing to send on a Transport connection. The maximum size of the "sending credit window" shall be referred to as WS1. As specified in ISO 8073, the "sending credit window" shall also be less than or equal to the remote "receive credit window" as conveyed in the last CDT field; c) It is strongly recommended that an implementation use a retransmission timer per Transport connection. If, upon expiration of the retransmission timer, an implementation allows more than "1" TPDU to be transmitted a means to locally adjust the maximum number shall be provided; d) All implementations shall have the capability of operating without delaying ACKs of data TDPUs received in- sequence (i.e., AL essentially equals zero). If an implementation optionally chooses to explicitly delay ACKs, a means to locally adjust AL shall be provided. Optional Requirements are as follows: For systems implementing the dynamic window sizing scheme the following rules apply as described below: 1. RECEIVING TRANSPORT ENTITY (RTE) RULES: a) Rule 1 - Initialization of Window: 1) The initial value of WR (known as WR0) shall have a locally configurable upper bound. This window is sent to the sending transport entity (STE) in the next CDT field transmitted; a) Rule 2 - Required Sampling Period: 1) All RTEs shall maintain a fixed value for WR until the next 2WR DT TPDU arrive since the last CDT field was transmitted by the RTE; b) Rule 3 - Required Counting of Received TPDUs in a Sampling Period: 1) All RTEs shall maintain a count, N, equal to the total number of TPDUs received and a count, NC, equal to the total number of TPDUs 10 PART 4 - TRANSPORT December 1993 (Stable) received which had the CE Flag set. All types of TPDUs are included in the counts for N and NC, not just DT TPDUs; c) Rule 4 - Required Action upon the end of a Sampling Period: All RTEs shall take the following actions at the end of each sampling period: 1) If the count NC is less than 50 percent of the count N, the RTE shall increase WR by adding 1 up to a maximum, WR1, (that is based on the local buffer management policy); otherwise, it shall decrease WR by multiplying by 0.875 (a minimum of 1); 2) Reset N and NC to zero; 3) Transmit the new window WR in the next CDT field sent to the sending transport entity; 2) SENDING TRANSPORT ENTITY (STE) RULES: a) Rule 1: Initialization of Window: 1) All STEs shall maintain a sending window size (WS). Initially and also as long as there is no loss, WS is set equal to the receiving window value WR received from the remote RTE in the last CDT field; b) Rule 2: Required Action on a Timeout; 1) All STEs shall reset WS to one when the retransmissions timer expires and indicates a lost TPDU. WS now limits the number of DT TPDUs that may be transmitted or retransmitted without further acknowledgments; c) Rule 3: Required Counting of Acknowledged TPDU: 1) All STEs shall maintain a count, ACKRCVD of the number of DT TPDUs acknowledged, by the RTE, since WS was last adjusted. Therefore each time WS is adjusted, the count ACKRCVD shall be reset to zero; 11 PART 4 - TRANSPORT December 1993 (Stable) d) Rule 4: Increase Window Policy: 1) All STEs shall increase WS by one each time ACKRCVD is equal to or greater than the current value of WS, unless WS exceeds the window permitted by the remote RTE. 5.1.2.6 Use of Priority (Refer to the Working Implementation Agreements). 5.2 Transport Class 0 5.2.1 Transport Class 0 Overview Transport Class 0 over X.25 is mandatory (see X.400) for use in communicating with public MHS systems operating in accordance with the CCITT X.400 series recommendations. The purpose of the agreements concerning Transport Class 0 is to allow connection to these public services. Transport Class 0 over X.25 can also be used in communicating between PRMDs (this choice is prevalent outside North America). 5.2.2 Protocol Agreements 5.2.2.1 General Rules Transport Class 0 agreements are as follows: a) The Error (ER) TPDU may be used at any time and upon receipt requires that the recipient disconnect the network connection, and by extension the transport connection; b) The allowed values for the maximum TPDU size are 128, 256, 512, 1024, and 2048 octets; c) The Class 0 protocol does not support multiplexing. At any instant, one Transport connection corresponds to one Network connection; d) It is recommended that the optional timers TS1 and TS2, if implemented, be settable by local system management. Values in the order of minutes should be supported; 12 PART 4 - TRANSPORT December 1993 (Stable) e) An unlimited TSDU length must be supported. f) It is recommended that implementations send both the preferred and existing TPDU size parameters in the CR TPDU. 5.2.2.2 Transport Class 0 Service Access Points For communicating with public MHS systems, section 5 of X.410 specifies the use and format of TSAP identifiers. 5.2.3 Rules for Negotiation The rules for class negotiation shall be used. 5.3 Transport Class 2 5.3.1 Transport Class 2 Overview Transport Class 2 is applicable in OSI end systems which provide the Connection-mode Network Service. 5.3.2 Protocol Agreements Transport Class 2 agreements follow: a) The values of the TS1 and TS2 timers shall be configurable. The recommended timer values are: 1) TS1: 60 seconds; 2) TS2: 60 seconds; b) If present, the TSAP-id field in the CR and CC TPDUs shall be encoded as a variable length field and will be interpreted as an octet string. The length of the string cannot exceed 32 octets; c) The rules for class negotiation shall be used; d) QoS negotiation is outside the scope of these agreements. If QoS negotiation is not supported, receipt of the parameters "throughput," "residual error rate," "priority," and "transit delay" in the CR and CC TPDU shall be ignored. 13 PART 4 - TRANSPORT December 1993 (Stable) NOTE - If Class 0 is indicated in the Alternative Protocol Class field and QoS parameters are conveyed and the responding end system chooses Class 0, then the QoS parameters have been ignored by the responding system. e) It is recommended that implementations send both the preferred and existing TPDU size parameters in the CR TPDU. 6 Provision of Connectionless Transport Service ISO 8072/Add. 2 is the Transport Service Definition covering Connectionless-mode Transmission. ISO 8602 is the Protocol for providing the Connectionless-Mode Transport Service. 6.1 Connectionless Transport Overview When providing the connectionless Transport Service, the protocol shall be implemented as specified in ISO 8602. 6.2 Protocol Agreements 6.2.1 General Rules The connectionless Transport protocol is a relatively simple protocol providing little opportunity for conflicting interpretations. A few relevant agreements follow: a) The optional elements of procedure for use of CLTS over CONS (i.e., clause 6.3 of ISO 8602) will not be supported; b) A Unitdata TPDU that is received that contains a protocol error or an unknown destination TSAP ID shall be discarded. 6.2.2 Connectionless Transport Service Access Points or Selectors The TSAP selector field in the UD TPDU shall be encoded as a variable length field and will be interpreted as an octet string. The length of the string cannot exceed 32 octets. 14 PART 4 - TRANSPORT December 1993 (Stable) 7 Transport Protocol Identification The absence of Call User Data (CUD) in an X.25/ISO 8208 Call Request/Incoming Call packet indicates the operation of ISO 8073/CCITT X.224. Protocol Identification TPDU values applicable to these agreements are given in table 1. These TPDUs, when used, are conveyed as N-connect user data. Table 1 - Protocol Identification TPDU Values +---------------------+------------------------+ | | | | TPDU Value | Protocol | +---------------------+------------------------+ | | | | 03 01 01 00 * | ISO 8073/Add. 1 | | (see note 1) | | | 03 01 02 00 ** | ISO 8602 | | (see note 2) | | | | | | | | +---------------------+------------------------+ NOTES 1 Corresponds to an ISO 8073/Add. 1 UN-TPDU and a X.224 Annex B PI-TPDU. 2 Corresponds to an ISO 8073/Add. 1 UN-TPDU. The following agreements apply: a) Any additional TPDU, which follows (by concatenation) a Protocol Identification TPDU shall be ignored if ISO 8073/Add. 1 is not supported; b) When using ISO 8208, usage of a Protocol Identification TPDU not corresponding to those listed in table 1 is outside the scope of these agreements. 15 PART 4 - TRANSPORT December 1993 (Stable) 8 Security 8.1 ISO/IEC 10736 Transport Layer Security Protocol (TLSP) ISO/IEC 10736 describes both a connection oriented and connectionless security protocol that can be used in conjunction with OSI Transport Layer Protocols (ISO/IEC 8073 and ISO/IEC 8602). Before secure communication can be accomplished, a security association (in band or out of band) shall have been established with agreement on all attributes associated with this association. Managed objects are not yet specified by this standard and therefore the security domain/administrative authority shall determine the procedures and policies that govern this information with other security information. All mandatory functions are supported by these implementation agreements. 8.2 Services If access control service is selected and the labels mechanism is used, then integrity shall also be selected. The Transport (Class 4) initiator shall propose the non-use of checksums if TLSP is also invoked with connection integrity selected (as this would be redundant functionality). The integrity mechanism selected shall be one of the recommended algorithms (a signed MD5 or SHA for public key systems or DES MAC for secret key systems to name just a few) in part 12 (OS Security) of these agreements or a private algorithm that both communicating parties have agreed to use. 8.3 Mechanisms To optimize efficiency and assist in the interoperability of secure implementations, it is useful to specify which mechanisms and algorithms apply. This specification shall allow implementations to know the exact encapsulation format used including what fields are required, their length, and order. A set of applicable profiles (mechanisms and algorithms) shall be specified within the Implementation Agreements to insure this efficient interoperability. 16 PART 4 - TRANSPORT December 1993 (Stable) 8.4 Protocol Constraints Although the standard has the option of all type-length-value (tlv) fields being in any order, for efficiency, the encapsulation format depicted in the standard shall be used. If the tlv fields are not in order, undefined (type field has not been allocated a value in the TLSP Standard), or the SE TPDU fails one of the TLSP Security checks, the secure encapsulated PDU should be discarded. The reporting of this situation is a local matter. If shared knowledge of this event is required, a possible technique would be to use the system management to report the error. The Security Association-Identification field should be no more than 20 octets. 8.5 Functional Security Sequence Ordering If Access control is implemented using labels, the label function is first applied followed by the integrity function. If confidentiality has also been selected, then that function is perfomed after the integrity function. If integrity and confidentiality have been selected, the integrity function is performed before the confidentiality function. 17