Secure SCTP – A Versatile Secure Transport Protocol

1 downloads 3 Views 431KB Size Report
Abstract. The Stream Control Transmission Protocol (SCTP) is a new general purpose transport protocol defined by the IETF. Originally intended for the transport ...

Telecommunication Systems 27:2–4, 273–296, 2004  2004 Kluwer Academic Publishers. Manufactured in The Netherlands.

Secure SCTP – A Versatile Secure Transport Protocol ESBOLD UNURKHAAN, ERWIN P. RATHGEB and ANDREAS JUNGMAIER

{esbold;rathgeb;ajung} Computer Networking Technology Group, IEM, University of Duisburg-Essen, Ellernstr. 29, D-45326 Essen, Germany

Abstract. The Stream Control Transmission Protocol (SCTP) is a new general purpose transport protocol defined by the IETF. Originally intended for the transport of voice signaling data (SS7) over IP networks, SCTP together with newly defined extensions is increasingly considered for other application scenarios as well. These require strong security solutions to authenticate the communication partners and protect sensitive data with respect to integrity and confidentiality. Proposals have been issued on how to protect SCTP transport by using standard security protocols such as TLS and IPsec. However, these solutions introduce limitations or inefficiencies und thus may not be able to fully exploit the capabilities of SCTP. Therefore, we propose a security extension to SCTP named Secure SCTP (S-SCTP) to solve these issues in an efficient and user-friendly way. Keywords: transport protocol security, SCTP, end-to-end security


Introduction to SCTP

SCTP, as defined in [Stewart et al., 32, 33; Stone et al., 35], is a connection-oriented, message-based reliable transport protocol. It works on top of a connectionless, datagram-oriented service such as IP, and explicitly supports multi-homed endpoints, i.e. endpoints with more than one IP address. SCTP provides its user with flexible methods of data delivery where the SCTP user can request messages to be delivered by an ordered or unordered service. Several independent message streams may be multiplexed into a single connection, and received without interference from other streams. This avoids head-of-line blocking. 1.1. A protocol overview SCTP connections, named associations, are established between two endpoints, i.e. logical entities that implement the protocol. These endpoints are identified by a set of transport addresses, i.e. combinations of IP addresses and a common source port. SCTP endpoints communicate by exchanging PDUs that contain a fixed size header plus a possibly variable number of data units which are called chunks. A typical PDU is shown in figure 1. Chunks may either transport user data (data chunks) or control information (control chunks) for establishing/releasing associations, selectively acknowledg-



Figure 1. SCTP packet format with common header und chunks.

ing data, supervising the status of network paths, reporting errors, or optional protocol extensions. When both control and data chunks are transported in a SCTP packet, control chunks are always placed before data chunks. The SCTP header contains two 16-bit port numbers, a verification tag, and a CRC32-C checksum [Stone et al., 35]. The verification tag is a 32 bit random value that is exchanged between the endpoints when the association is set up. Upon receipt of an SCTP packet, an endpoint first verifies the checksum, and then drops the packet if it is incorrect. It then checks for existing associations based on the combination of source and destination IP adresses and ports. If an association exists, the verification tag is verified and again, the packet is dropped if there is no match. In this way, SCTP endpoints are protected from attackers that try to blindly insert forged packets into SCTP associations. Associations are established after a four-way handshake between client and server. The initial two messages, Init and Init-Ack chunks, contain fixed length parameters plus a variable number of address parameters. The Init-Ack returned to the client by the server additionally includes a parameter named cookie, containing all relevant data from Init and Init-Ack chunks. This allows the server to free up any resources allocated to the partially established association after receipt of the Init chunk, and not change state. The client returns the cookie which contains all information required to resume the association setup to the server in the third message, a Cookie-Echo chunk. The cookie is protected by an HMAC [Krawczyk et al., 16], and thus its integrity can be verified by the server that created it before processing its information and finally allocating resources for the new association. Therefore, denial of service attacks, where attackers block resources by sending a large number of forged setup requests, are far less likely to succeed for SCTP than, e.g., for TCP.



1.2. Multi-homing and path monitoring For an SCTP endpoint, the notion of a path is equal to that of one peer destination address. By default, SCTP endpoints monitor the reachability of their peers as well as availability of each path to the peer by regularly sending Heartbeat control chunks to all of the destination addresses of the peer endpoint. Upon receipt of such a message, an endpoint replies with a Heartbeat Acknowledgment chunk. SCTP endpoints keep track of the number of consecutive retransmissions of data or Heartbeat chunks per peer endpoint and per destination path, respectively, by maintaining separate path and destination error counters. Each time a chunk is acknowledged, the relevant counters are cleared. Once a counter exceeds an error limit, the peer endpoint or the respective path is considered unavailable. In a multi-homed SCTP association, one path is selected as the primary path and carries the main load of the user data traffic. Other paths are only used for data retransmissions and Heartbeat chunks. Should the primary path become unreachable, an endpoint may send data to another, active address. Any such failure is reported to the SCTP user which can subsequently choose a new primary path or take other appropriate measures. 1.3. Data transmission and delivery SCTP allows for flexible methods of data delivery that surpass the abilities of protocols like TCP. This is achieved by separating the reliable transport of messages from the actual reordering and delivery to the SCTP user. Reliable transport is ensured by the use of 32 bit transmission sequence numbers (TSNs), selective acknowledgements and retransmission mechanisms. All data chunks must be acknowledged, and SCTP uses selective acknowledgements (Sack chunks) for this purpose: at least one Sack chunk must be sent within 200 ms after a new data chunk was received, or for every two received SCTP packets that contained data chunks. Sack chunks also carry a cumulative TSN value (ctsna), that acknowledges all TSNs up to and including this value. When an association is established, both endpoints negotiate an individual number of up to 65536 unidirectional channels that are transported in a multiplex within this association. These channels carry streams of messages (rather than bytes) within which user messages are usually delivered in sequence. To allow for resequencing, messages are buffered on the receiving side and may have to wait for retransmissions of earlier messages if these were lost in the course of transmission. Alternatively, the SCTP user may request an unordered transmission service, allowing messages to be delivered to the receiving application directly upon arrival. The advantage of the stream mechanism comes at the cost of additional stream identifiers and stream sequence numbers that need to be transported with the user data chunks. SCTP streams allow for combining message streams belonging to independent flows and carrying them within one association. Due to the separation of streams, messages of one



stream can still be delivered, even though messages of other streams may be blocked waiting for retransmission of data chunks that were lost in the network. SCTP also allows “bundling” of small data chunks that all belong to different streams into one SCTP packet in order to reduce delay and transmission overhead. For large data chunks, SCTP endpoints must do path MTU discovery (cf. [McCann et al., 20; Mogul and Deering, 22]) to find the current maximum transmission unit (MTU) for all paths to their associated endpoint. The smallest MTU of all paths is usually taken to fragment user messages that, together with all necessary headers, exceed this value in length. Fragments of large messages all carry an identical stream sequence number and successive TSNs. The beginning and end of a fragmented user message is marked by flags in the data chunk headers. SCTP implementations may enforce a maximum size for messages to avoid blocking effects on the receiver side. 1.4. Flow and congestion control SCTP flow control is based on a receiver window, the size of which is negotiated at association setup. This initial receiver window reflects the maximum amount of data an SCTP sender may have outstanding, i.e. sent and not yet acknowledged. Each selective acknowledgement carries a current value of this parameter for the associated endpoint. This mechanism can be used by slow endpoints to stop their peers from overloading them. Each SCTP endpoint keeps a distinct set of congestion control parameters for each destination path. This ensures that endpoints behave fairly towards other – especially TCP – traffic, do not overload the network, and reduce the sending rate when congestion is experienced. Similarly to TCP flow control [Allman et al., 1], a packet loss is taken as an indication of congestion, and an AIMD (additive increase, multiplicative decrease) algorithm is used to increase or decrease the size of the congestion window. When sending to a certain path, SCTP associations either operate in a slow start mode, where the current congestion window (cwnd) is less than a certain threshold value (slow start threshold, ssthresh) and grows faster, or in congestion avoidance mode, where cwnd  ssthresh, and the size of cwnd grows more slowly. 1.5. SCTP extensions The chunk concept of SCTP allows for flexible extension of the protocol by defining new types of control chunks to support the required mechanisms. The Transport Area Working Group of the IETF currently discusses several extensions to SCTP, most of which have already been integrated and tested in SCTP implementations publicly available (see, e.g., [Jungmaier et al., 9]). However, as will be discussed later in section 3, these extensions raise issues when used with standardized security protocols. 1.5.1. Partially reliable SCTP The extension for partial reliability (cf. [Stewart et al., 31]) specifies a mechanism an endpoint can use to indicate to its associated endpoint that some apparently lost data



chunks will not be retransmitted. A new parameter, called fwtsn is defined for that purpose together with new control chunk type, the Forward TSN chunk, to transport it. The sender of this chunk does not need to retransmit any data chunk with a TSN less than the fwtsn value. The receiver of the Forward TSN chunk advances its ctsna (see section 1.3) to fwtsn, and further if possible, and stops indicating the respective data chunks as missing. This mechanism is advantageous, e.g., in the following scenarios: • In times of congestion, retransmitted data may add to the congestion. By skipping the retransmission, the network is relieved of additional traffic caused by retransmissions. • User data may have a limited time of validity (e.g., packetized voice samples, or sensor data when a more recent sensor reading is available). After that time, there is no point in retransmitting this obsolete data. SCTP implementations conveniently allow for specifying a lifetime for data that is to be sent. After expiry of this lifetime, data may not be sent or may not be retransmitted again. In this latter case, the sender cannot decide whether the data has finally been received by the peer, or a Forward TSN chunk has advanced the ctsna value of the peer. 1.5.2. Dynamic address reconfiguration The extension described in [Stewart et al., 29] allows for dynamically adding and removing addresses from established associations. Also, the peer can be told to use another path as a new primary path (e.g., a new path with a higher bandwidth). For this purpose, the draft defines new control chunks and a mechanism for reliably exchanging these chunks and their acknowledgements between two endpoints. Addition or removal of addresses may be signaled to the peer, e.g., in the following cases: • IPv6 site renumbering, or connection to a new ISP. Some SCTP associations may need to remain active and established, even if their addresses are changed. • Addition and removal of interfaces and associated network layer addresses, e.g., through endpoint mobility. A mobile SCTP endpoint may enter a new wireless network, and receive a new address from the network provider. A mobile SCTP endpoint leaving a wireless network may need to signal the removal of a path to its peer. See [Dreibholz et al., 5; Koh et al., 15; Riegel and Tüxen, 26] for details. Naturally, an endpoint may never remove its last address from an existing association. For reasons of flow-control, there may only be one control chunk for address reconfiguration outstanding at any one time. Therefore these changes may be limited in number and frequency. The extension for dynamic address reconfiguration introduces a new possibility of hi-jacking associations unless additional security mechanisms are specified and implemented.




Security requirements for SCTP-based end-to-end transport

The Signaling Transport Working Group (Sigtran) of IETF targets the use of SCTP as underlying transport protocol for the transfer of SS7 signaling data [Ong et al., 24]. Moreover, the Reliable Server Pooling (RSerPool) working group of the IETF is also relying on SCTP transport when defining an architecture [Dreibholz, 4; Tüxen et al., 36] and protocols for the management of high-availability server pools. Within both groups, resulting security issues are being discussed and described in the drafts [Loughney et al., 18] and [Stillman et al., 34], respectively. There is a consensus that security services must be implemented for the protection of the core elements and protocols of both of the above mentioned architectures, among these peer authentication, integrity of data transmission and in some cases also privacy through encryption. Since an implementation of security services is bound to rely on security protocols already standardized within the IETF, and to leave these protocols untouched, solutions for their implementation include, as mentioned in [Loughney et al., 18; Stillman et al., 34], use of TLS (cf. [Dierks and Allen, 3]) or IPsec (cf. [Kent and Atkinson, 14]). See section 3 for more details on these protocols. Within the IETF, SCTP is being discussed as transport protocol for many other applications. Clearly, many candidate protocols for SCTP transport such as Diameter, SIP or iSCSI have an obvious need for protection (authentication, privacy, etc.) in many usage scenarios. In order to fully exploit the advanced SCTP features, security solutions must be tailored to the rather heterogeneous needs of the various application scenarios. 2.1. Specific security requirements for Sigtran protocols The term Sigtran refers to the Signaling Transport Working Group of IETF and the protocols standardized therein. These protocols can be used to transport SS7 telephony signaling data between telephone switches of network operators, or between customer premises equipment and network service providers (cf. [Ong et al., 24]). SS7 networks and their security traditionally rely strongly on the fact that access for end-users is not possible and that they operate within a closed, monitored and strongly regulated environment. These networks must adhere to national and international standards. SS7 transport over IP networks needs to be as secure as traditional, TDM-based signaling transport based on the SS7 Message Transfer Part (MTP), and must provide similar performance. Since there is not yet an international standard for security mechanisms that can protect the protocol stacks defined by the IETF, e.g., M2PA [George et al., 7], M2UA [Morneault et al., 23], M3UA [Sidebottom et al., 27], or SUA [Loughney et al., 17], the Sigtran group has started to discuss security considerations for Sigtran protocols in [Loughney et al., 18]. This document analyzes the common threats to the Sigtran protocols, and makes recommendations as to which security mechanisms nodes supporting Sigtran based communication should implement in order to guarantee a minimum security level. All Sigtran protocols use SCTP as transport, and the goal is a sufficient end-to-end security. This can be achieved by deploying either one of the standard solutions described in section 3, namely TLS over SCTP or SCTP over IPsec.



For SCTP over IPsec, encryption is required to protect the privacy of the data. In some cases it is necessary to protect IP layer information as well. For peer authentication and establishment of (new) security associations (SA), the Internet Key Exchange (IKE) must be supported by Sigtran nodes. With IKE, different authentication mechanisms are possible but at least support of pre-shared keys is required. Sigtran sessions that are secured by TLS over SCTP must be mutually authenticated between client and server. TLS must be used on all bidirectional streams, and unidirectional streams are not allowed. This ensures that all data exchanged between two Sigtran nodes is protected. Loughney et al. [18] explicitly allows for a session upgrade, and defines how two Sigtran nodes can use STARTTLS and STARTTLS_ACK messages to initiate a TLS connection. This document also states that for sufficient security Sigtran nodes must properly support IPsec and may optionally support TLS. 2.2. Security requirements for Reliable Server Pooling The Reliable Server Pooling (RSerPool) working group of the IETF is defining an architecture [Tüxen et al., 36] and protocols for the management of server pools. While SCTP provides redundancy at the network level, RSerPool aims at maintaining availability of services by managing sessions between redundant elements within server pools. The RSerPool architecture defines the following elements: • Pool Elements (PEs). These represent the servers providing a service as elements of a pool. All elements within a pool provide the same service. • Pool Users (PUs). The clients using the services being offered by a PE. • Name Servers (NSs). These are special PEs that provide a name translation service. This service translates so-called pool handles (byte vectors, with, e.g., an ASCII string like “video pool”) to a set of transport addresses identifying active PEs. Moreover, NSs supervise PEs, and remove inactive PEs from their databases. The protocol used between PEs and NSs, PUs and PEs and between PUs and NSs, is called the Aggregate Server Access Protocol (ASAP), which is currently defined in [Stewart et al., 30]. It provides registration, reregistration and deregistration of PEs with NSs, supervision of PEs using session layer keep-alive messages, and detection of NSs using server announcements via multicast (if available). For PUs it provides name translation via an NS, and a mechanism for session (re-)establishment with PEs (cf. sections 3.8 and 3.9 of [Stewart et al., 30]): in case of a PE failure, the ASAP allows for transparent session failover of a PU to other PEs, where the service can be continued. The protocol used by NSs to synchronize their name spaces and PE databases is called the Endpoint Name Resolution Protocol (ENRP), see also [Xie et al., 38]. Stillman et al. [34] analyze possible threats to the RSerPool architecture. For a secure communication between the above mentioned entities (namely, NSs, PEs, and PUs), integrity protection and authorization are desired security mechanisms for most communication relationships. For some of them, confidentiality may also be a desired



property, but support for this is considered optional. In particular, NS ↔ NS communication via ENRP must be secured in order to ensure the functionality of the RSerPool system, as the name service is vital. Also, PE ↔ NS communication must be protected, otherwise a malicious PE could corrupt the ENRP databases. For PU ↔ NS and PU ↔ PE communication, authentication and integrity protection are also desired, but their use is left to the PUs. PUs, however, can expect that the respective communication with NSs or PEs can be protected, if they want to use security mechanisms. Therefore, NSs and PEs must support proper security mechanisms. Any serious security implementation for RSerPool must first ensure integrity protection. If integrity is guaranteed, authentication mechanisms can safely be implemented. Confidentiality, e.g., by using encryption, is an orthogonal feature, and may or may not be needed or required by end users. Stillman et al. [34] suggest to use either one of the two standardized solutions discussed in more detail in section 3. 3.

Standardized security solutions

One of the main requirements in defining security solutions for SCTP has been to leave existing standards untouched, and define how SCTP could be used with as few modifications or restrictions as possible. A natural choice for offering cryptographically secure services are protocols operating above the transport protocol, such as transport layer security (TLS), see also [Dierks and Allen, 3]. Another choice is the use of the IP security architecture (IPsec), cf. [Kent and Atkinson, 14], that protects the IP payload exchanged between endpoints that have created so-called security associations between them. 3.1. TLS over SCTP The TLS protocol (cf. [Dierks and Allen, 3]) was specified for use on top of a byteoriented, reliable transport protocol that enforces data delivery with strict reordering, e.g., TCP. It introduces its own record marking in the TLS record layer (see [Dierks and Allen, 3, section 6.2]). In [Jungmaier et al., 10] it is defined how a standard TLS protocol implementation should use the services of SCTP, and which limitations implementors and users would have to consider. As the TLS standard does not readily support a multiplexing concept as required for the SCTP streams, a separate TLS connection has to be established for each stream that has to be protected resulting in multiple (possibly many) TLS connections per SCTP association. Furthermore, TLS connections always require a bidirectional communication. Therefore, two unidirectional SCTP streams have to be combined logically to a bidirectional stream in order to support TLS. The unidirectional communication also possible with SCTP is not applicable for streams secured by TLS. SCTP implementations must be able to handle a maximum message size equal to the maximum length of a TLSCiphertext structure (cf. [Dierks and Allen, 3, section 6.2.3]), i.e. 18437 bytes. TLSCiphertext records of a TLS connection are sent as



SCTP user messages within one bidirectional stream. SCTP takes care of proper fragmentation and reassembly when that data is transported over the network layer. TLS as SCTP application must use the in-sequence delivery service. Messages handed over to the unordered transport service of SCTP cannot be protected within a TLS connection. An advantage of the separate TLS connections per stream is that both secure and insecure streams can be used within one association as required by the application. It is also possible to upgrade an already existing insecure communication to a secure communication by setting up a new TLS connection at any time. Two endpoints that establish an SCTP association with n bidirectional streams can have a maximum of n TLS connections. These connections can be established in different ways, depending on the way TLS over SCTP is implemented: • Full handshake for each bidirectional stream. The handshake is performed before the first data is to be transmitted securely. After that, each stream has an independent TLS connection. • Full handshake only for the first bidirectional stream. This results in a valid TLS session identifier. The session identifier can be used for TLS session resumption, which allows for establishing successive TLS connections on the other streams with an abbreviated handshake. After this abbreviated handshake, each newly established TLS connection has its proper set of security parameters. 3.2. SCTP over IPsec The security architecture for the internet protocol [Kent and Atkinson, 14] relies on a suite of protocols providing a system for securing communication between IP based host systems. As such, IPsec defines: 1. Security protocols. There are two security protocols, the IP Authentication Header (AH), cf. [Kent and Atkinson, 12], and the IP Encapsulating Security Payload (ESP), cf. [Kent and Atkinson, 13]. The AH provides protection of the integrity of packets (i.e. parts of the IP header and IP packet payload) sent from a host address to another host address, and data origin authentication. In addition to these services, ESP also provides confidentiality by encrypting the IP payload (in transport mode), or by encapsulating and encrypting the complete IP packet (in tunnel mode). 2. Security associations (SAs). A security association designates a unidirectional association characterized by the tuple SPI, destination address, security protocol. The security parameter index (SPI) is an index which is needed if different SAs exist per destination address, and the security protocol may be either AH or ESP. The set of all SAs is kept in the so-called security association database (SAD). Each IP endpoint implementing IPsec maintains a second database, the security policy database (SPD), which maps in- or outbound traffic to a SA. The SPD identifies traffic according to its characteristics such as source or destination addresses, transport protocols used, or source or destintation ports.



3. Key and SA management procedures. IPsec implementations should support both manual and automatic key distribution. Manual configuration of SAs and distribution of keys is appropriate for smaller, mostly static scenarios, where few communication flows need to be protected. Automatic key distribution is based on a key management protocol (ISAKMP), cf. [Maughan et al., 19], and a corresponding protocol for creating authenticated keying material based on the internet key exchange (IKE), as mentioned in [Harkins and Carrel, 8]. These protocols are used to establish initial security associations, i.e. secure, authenticated channels for further communication, also named phase-1 SAs. Over these channels, further SAs for the IPsec security protocols may be established as phase-2 SAs, which involves distribution of appropriate keying material between the endpoints. Usually, the setup of phase-2 SAs is a shorter process compared to the initial phase-1 exchange. 4. Encryption and authentication algorithms. The algorithms that can be used to authenticate a packet’s source are based on MD5 and SHA-1. The symmetric crpytoalgorithms for ESP are CAST-128, RC-5, IDEA, Blowfish, DES, or 3DES (cf. [Pereira and Adams, 25]). The IPsec services can be used transparently by SCTP for the protection of messages exchanged between endpoints. However, IPsec implementations may have to be adapted to match their SPD entries properly to the SCTP protocol type, and SCTP port numbers. Since SCTP supports multi-homing, in principle the creation of a maximum of 2 × i × k unidirectional SAs may be required for an SCTP association between an endpoint with i addresses and another one with k addresses. 3.3. A comparison of security solutions Bearing in mind SCTP application scenarios with specific security requirements, such as, for example, those discussed in section 2 as well as the overall features of SCTP and its extensions (see section 1), we will analyse the applicability and possible limitations of the standard SCTP security concepts in this section in more detail. In general, a secure end-to-end transport service over SCTP using • • • •

bidirectional communication, in-sequence and reliable delivery, multiple streams, and multi-homing

can be realized by using TLS over SCTP (TLS/SCTP) or SCTP over IPsec (SCTP/IPsec), alternatively. Both IPsec and TLS provide means for cryptographically secure integrity and authentication checks without encryption. IPsec uses the Authentication Header protocol (AH) for this purpose, TLS a cipher with a non-null hash algorithm, e.g., TLS_RSA_WITH_NULL_SHA (cf. [Dierks and Allen, 3]). Methods for authentication can be based on the mechanisms provided by TLS, i.e. mutual authentication with X.509 certificates. Alternatively, simpler mechanisms like server authentication with a



X.509 certificate and client authentication via CHAP can be used (provided the underlying protocols are integrity protected). For highly asymmetrical scenarios with many clients which have to be authenticated frequently by one or few servers, complex and computationally costly authentication mechanisms may contribute to possible scalability problems. One critical scenario here is the authentication of clients with the Name Servers in RserPool (see [Stillman et al., 34]). If confidentiality is required when using IPsec, the ESP protocol with a non-null encryption algorithm can be used to protect the user data. Obviously, TLS also provides encryption with different algorithms by using one of the available cipher suites. Possible scaling problems may exist for the TLS/SCTP solution in scenarios with a large number of streams and strict bounds on association setup delays as well as in case of frequent re-keying. However, first experiments with our prototype implementation of the functionality defined in RFC 3436 [Jungmaier et al., 10] have shown that several thousand streams can readily be supported. Scaling issues or at least significant inefficiencies for the SCTP/IPsec solution may arise in application scenarios where high volume user traffic without specific security requirements is multiplexed into one SCTP association together with sensitive control traffic. TLS/SCTP in this case allows to flexibly adapt the security mechanisms on a per stream basis and even dynamically. On the other hand, the TLS/SCTP solution tends to have more transmission overhead if all data of multiple streams has to be protected and may also suffer delay penalties depending on the size of the TLS records when packet loss occurs in the network. In the case of small TLS records which can be bundled into one SCTP packet (see section 1.3) the security overhead (e.g., 16 or 20 bytes for a MAC) is per TLS record and thus appears several times in one SCTP packet. TLS is not aware of the MTU size limitations (see section 1.3) that apply. Therefore, SCTP has to possibly fragment long TLS records. With respect to transmission and delivery, the TLS/SCTP concept requires insequence and reliable service. This is due to the fact, that TLS was designed with these TCP properties in mind. Unordered delivery (see section 1.3) or the Partially Reliable Transport extension of SCTP (see section 1.5.1) cannot be supported on streams protected by TLS, unless suitable TLS extensions are standardized and provided in implementations. However, these features as well as unidirectional communication can be used on non-secure streams within a protected association. One consequence of using the TLS/SCTP concept is that although TLS protects the SCTP user data, neither the control chunks exchanged within the corresponding SCTP association nor any IP layer information can be protected by TLS (as TLS is only an SCTP user). This is a general problem with security solutions operating above the transport layer which possibly allows some forms of denial of service attacks against the SCTP association itself. SCTP/IPsec protects the complete SCTP packets including SCTP common header, control chunks and data chunks. In cases where IP layer information must be protected as well, associations can use the tunnel mode of IPsec. Each packet secured by IPsec is a self-contained unit independent of other packets.



One disadvantage of the SCTP/IPsec solution is that – in principle – it requires the configuration of multiple, possibly many IPsec Security Associations (SA) to support a multi-homed SCTP association. To solve this problem, Stewart [28] specify how the SA definition of IPsec can be extended to support multi-homing. Stewart [28] suggest associating the entries in IPsec’s Security Policy Database (SPD) with sets of addresses (of an SCTP endpoint) rather than single addresses. A lookup for the SPI, destination address, security protocol tuple (see section 3.2) with any of the addresses of the respective SCTP peer endpoint must yield the same SA in this case. This implementation-specific feature can only be used in an interoperable fashion, if the key management protocols also allow for a simple way of configuring SAs for sets of endpoint addresses. Although IKE can establish policies for SAs covering complete IP subnets, this functionality does not suffice for SCTP, where endpoint addresses can be diverse and usually do not all belong to one subnet. For this purpose, Stewart [28] suggest an enhancement to ISAKMP and IKE, allowing SAs to be configured for lists of IP addresses rather than single addresses in a phase-2 exchange. A requirement for this mechanism is that phase-1 exchanges are done in a way that allows for validation of all addresses presented in phase-2, either by static, pre-shared keys, or by use of certificates with multiple identifiers of the ASN.1 type SubjAltName. The very recent extension by Stewart [28] must be supported by Sigtran nodes that use IPsec according to [Loughney et al., 18]. However, it is not yet available widely in implementations. Configuration of TLS/SCTP is simple for TLS-aware applications which can be used without modifications. Moreover, the adaptation of TLS and SCTP does not require major modifications as our prototype implementation proves and can be done without touching the operating system. IPsec, on the other hand, is implemented in the operation system and has a rather complex API (see [McDonald et al., 21] for details). Various operating systems use different semantics and options and IPsec configuration is commonly restricted to privileged users and processes. If IPsec is used, the management of security associations must be taken care of by the application, e.g., a RSerPool implementation, since generally IPsec use is transparent to the transport layer (SCTP). Stillman et al. [34] state that RserPool Name Servers may have to rely on hardware acceleration in this case, since depending on the usage scenario very many SAs may have to be established and maintained. Scalability might be an issue in that case. In addition, Internet Key Exchange (IKE) has to be used to distribute keying information. This must also be managed and controlled by the respective application if, e.g., the Dynamic Address Reconfiguration extension of SCTP (see section 1.5.2) is used in a dynamic scenario requiring full automation. This is, e.g., the case in SCTP mobility scenarios [Dreibholz et al., 5]. Table 1 summarizes this discussion and highlights the various issues associated with the two approaches.



Table 1 Comparison of TLS/SCTP and SCTP/IPsec.




SCTP over IPsec

Scalability for multiple streams Overhead for small messages (bundling) Overhead for long messages (fragmentation) Protection for unordered delivery service Protection for SCTP control chunks Flexible multiplexing of secure/insecure streams Management of security sessions (handling, automation) Partially Reliable Transport (SCTP extension) Support for SCTP multi-homing Dynamic Address Reconfiguration (SCTP extension)

– – – no no + + no + +

+ + + + + no – + (–) –

Secure SCTP

As pointed out before, there are significant limitations when using SCTP together with standard security protocols. Therefore, we propose an extension to SCTP that integrates security functionality into the protocol itself. This extension, called Secure SCTP (S-SCTP), was designed to avoid the drawbacks of the non-integrated solutions while still providing full compatibility with the original SCTP when no protection is being used. 4.1. Design goals for S-SCTP S-SCTP was designed to meet the following criteria: Security. S-SCTP provides data integrity and origin authentication not only for the user data transported by SCTP, but also for the peer-to-peer control information used by SCTP itself. Thus, vulnerabilities that may occur when using the Dynamic Address Reconfiguration extension (see section 1.5.2) without security mechanism can by avoided. Optional data confidentiality is also provided by mechanisms for flexible encryption of SCTP user data and control information. The decision whether encryption is used or not can be taken by the application on a per message basis. All chunks subject to encryption within one SCTP packet are grouped and encrypted together to save overhead. Performance and scalability. By integrating the security functionality directly into SCTP, the overhead for using a security protocol – both in terms of transmission overhead and computational effort – can be optimized with very fine granularity according to the application needs. Both in the case of many streams that need to be secured, and in the case of many possible address combinations between endpoints, S-SCTP shall provide a scalable solution which is achieved by establishing exactly one secure session per SCTP association. This decreases cost for secure session initialization compared to TLS especially in the case of many secure streams. Also, cost for secure session updating (rekeying) is decreased for long-lived associations. Compared to IPsec in the case



of many possible address combinations between the endpoints, cost is minimized since there is no need to establish many security associations. Further, to minimize transmission overhead, an HMAC (see [Krawczyk et al., 16]) is computed over the whole SCTP packet, including all chunks and the common header, rather than over individual messages (cf. also figure 1). Ease of use. For users to easily take advantage of the full functionality of S-SCTP without excessive configuration effort, we define several security levels: • Security level 0: At this level S-SCTP does not use any of the security functions and is fully compatible with standard SCTP. • Security level 1: At this level all SCTP chunks and the header of all SCTP packets of the association are authenticated and integrity checked, i.e. the HMAC algorithm is applied to all SCTP packets. • Security level 2: In addition to the HMAC operation, selected user data chunks are encrypted based on an indication flag provided by the (S-SCTP aware) application. • Security level 3: At this level, all chunks within any SCTP packet are encrypted, and the complete packet is authenticated, and integrity checked. Within a S-SCTP session, two endpoints may well use different security levels: for instance, one endpoint may only require authentication whereas the other endpoint also requires privacy. The first would choose security level 1 in this case, and the second would choose security level 3. Any time during an SCTP association lifetime, the user (or application) can change the security level. 4.2. Basic concepts of S-SCTP Each SCTP association can be protected by a single Secure SCTP session. There needs to be only one such session per association, independently from the number of streams used or the number of destination addresses of (and thus paths to) the peer endpoint. Figure 2 shows that the core security mechanism is logically situated between two functional blocks: the upper block performs grouping of SCTP data chunks to SCTP packets (also named bundling), and the lower block performs the selection of network paths (by choosing a destination address to send the SCTP packet to). Thus, by integrating the security functionality into the transport protocol, it is possible to avoid the drawbacks mentioned in section 3.3, and to flexibly support a mix of secure and insecure messages on each stream (as encryption can be activated on a per message basis). For a more detailed explanation of the workings of the module implementing the security mechanism, please refer to section 4.5. Similar to security protocols as TLS, S-SCTP uses a hybrid encryption mechanism: an asymmetric crypto-algorithm establishes a shared secret between communication endpoints, and a symmetric algorithm actually encrypts the user data. We define several phases within an S-SCTP association:



Figure 2. S-SCTP connection between two dual-homed endpoints.

1. The first phase, the insecure transmission phase is entered right after the establishment of the normal SCTP association. During this phase, no security features are available. 2 The second phase, named secure session initiation phase, starts when one of the peers enables its security features by setting a security level greater than 0, or explicitly opens a secure session. During phase 2, both peers exchange messages to securely establish a common master secret on both sides. Therefore, security features cannot be used, until phase 2 is completed. User data may only be transported in a protected fashion, when the implementation signals to the application that phase 2 is completed, and thus phase 3 is entered. 3. In phase 3, the application can use all security features according to the chosen security level. This phase is called secure session phase. 4. When the application terminates the secure session, phase 4, the secure session termination phase, is entered. The peer that closes the session must not use any more security features after phase 4 has started, but must be prepared to accept encrypted or authenticated data until the second peer acknowledges the termination of the secure session. If the normal SCTP association is not terminated as well, both peers are back to phase 1, the insecure transmission phase. 4.3. New chunk types for S-SCTP For S-SCTP to work in a compatible fashion to standard SCTP, we defined a number of new chunk types (see also table 2) which are used for the initial establishment of



Table 2 List of new chunk types for S-SCTP. Chunk type

Chunk name

0xD0 0xD1 0xD2 0xD3 0xD4 0xD5 0xD6 0xD7 0x10 0x11 0x12

Secure session open request Secure session certificate Secure session acknowledge Secure session server key Secure session client key Secure session open complete Secure session close Secure session close acknowledge Encrypted data chunk Authentication chunk Padding chunk

Figure 3. Format of the S-SCTP EncData chunk.

the secure session, for intermediate re-keying handshakes, and the termination of secure sessions as well as for transport of encrypted data and packet authentication. The interaction of these new chunks is described in the following sections. The new chunks were chosen such that an SCTP implementation not supporting the Secure SCTP extension will report an error as soon as a chunk for establishing a S-SCTP session is encountered, but will continue a normal, insecure SCTP association. Only when one of the last three chunk types listed in table 2 is encountered, an error is reported to the peer, and the association will be closed. The Encrypted Data chunk (EncData) is used for carrying the encrypted payload, whereas the Authentication chunk contains a HMAC for the SCTP packet. The format of an EncData chunk is shown in figure 3. It contains (in cleartext) the chunk length, a random number and its length in bytes, a reference to a master secret key, and the payload field for the data which holds the encrypted content of the concatenation of all



encrypted chunks contained in the EncData chunk. Before the encryption, this content may have to be padded to a minimum length (e.g., 64 bits) in order to avoid attacks that analyze traffic patterns, or to fit the block length (if a block cipher is used). For this, the Padding chunk is needed to fill the size of the concatenated data chunks up to the cipher block length. Its size depends on the data that is to be encrypted and the encryption algorithm. Besides the standard SCTP chunk header, it contains random data. With the reference to the master secret key, the receiver of an EncData chunk is able to decide which set of keys was used for encryption and authentication, since during the lifetime of a secure session the keying material between client and server may be updated several times, each time leading to a different set of master secrets. The initialisation vectors needed for CBC encryption and decryption of the payload are derived in a cryptographically secure way from 1. a shared master secret which is computed in the secure session initiation phase (cf. also section 4.4), and 2. the random number transported in cleartext by the EncData chunk. A similar approach is used for IPsec’s ESP. High quality random numbers of sufficient length must be used (e.g., 64 bits or longer; see also [Eastlake et al., 6] for necessary properties of random numbers). 4.4. Management of secure S-SCTP sessions The setup of an S-SCTP association is basically the same as for a normal SCTP association (see, e.g., [Stewart et al., 33, section 5] for a description). The secure session initiation phase only starts after the basic association is in the established state. The secure session initiation can be triggered by any SCTP user (application) at any time allowing for dynamic creation and deletion of secure sessions. The negotiation is done in a four-way handshake as shown in figure 4, by exchanging the newly defined SCTP control chunks, which can be bundled together with regular chunks. The transmission of these control chunks is protected by a retransmission timer against loss. To start the handshake, one SCTP endpoint, named the client, sends a Secure Session Open Request chunk. The chunk type code point is chosen such that a peer implementation not supporting S-SCTP will report an error and otherwise ignore this chunk. In that case, a failure is reported to the user (or application) of the client and the – insecure – SCTP association is continued. The chunk contains a list of cipher suites and list of compression methods supported by the client. The cipher suites indicate the three crypto-algorithms used for asymmetric key exchange, symmetric encryption and computation of the message authentication code (MAC). The client can present its certificate (X.509v3) – if available – to the server in a Secure Session Certificate chunk. A Secure Session Open Acknowledgement chunk indicating the crypto-algorithm the server has chosen is sent back to the client. With its own Secure Session Certificate chunk, the server can forward its credentials to the



Figure 4. S-SCTP secure session negotiation.

client. The Secure Session Server Key chunk contains keying material that is used by the asymmetric public key algorithm negotiated above. It is used to compute one set of master secret keys for the symmetric encryption algorithm, and another one for the authentication algorithm. In a Secure Session Client Key chunk, the client returns keying information to the server. Finally, Secure Session Open Complete chunks are exchanged. These contain a HMAC of all messages exchanged during the handshake and the association ID. For the computation of the HMAC, the newly computed master secret key is used. Thus, both server and client can verify that all messages have been exchanged correctly and have not been tampered with. The keying material may be updated at any time. This is done by an abbreviated handshake similar to the initial one. However, this update happens in an encrypted fashion using the current set of keys. The transmission and verification of the Certificate chunks is not necessary in that case. During the update secure data transport is allowed. The secure session termination phase begins when one of the associated endpoints sends a secure session close control chunk (cf. table 2) to its peer, as is shown in figure 5. This chunk includes a cumulative transmission sequence number (TSN) of encrypted data chunks with the highest encrypted TSN that is still outstanding (or a flag, if no more encrypted data is outstanding).



Figure 5. S-SCTP secure session termination.

Figure 6. S-SCTP packet assembly for security level 2.

The peer, after having received the secure session close chunk, returns a secure session close acknowledge chunk as soon as all outstanding encrypted data (as indicated by the TSN of the secure session close chunk) has been acknlowledged. The encryption or authentication of new outgoing data is not allowed after sending or receiving secure session close or secure session close ack chunks. 4.5. Secure data transport Figure 6 shows the packet assembly process in more detail for security level 2 where data chunks are encrypted selectively. Chunks that are available for sending and are to be encrypted (see darker chunks in figure 6) are grouped together to form an Encrypted Data chunk (EncData). To these, a padding chunk may need to be added up to the size of the block length. The data is encrypted, and the resulting EncData chunk is placed after (unencrypted) control chunks. If space is left in the packet, any data chunks that need not be encrypted can be added (see, for example, data-chunk 2 in figure 6). After adding the SCTP common header, the HMAC is computed over the whole packet and appended in the newly defined, fixed size Authentication chunk (Auth chunk) at the end of the packet before computing the packet checksum, and inserting it into the appropriate field in the SCTP common header. As a result, the Auth chunk cannot protect the CRC32C checksum header, but protects all other fields contained in the SCTP common header.



The integration of encryption and HMAC calculation clearly optimises the transmission overhead and the computational effort. Moreover, S-SCTP packets are selfcontained in a sense that all information required to decrypt and verify them are included in the same packet. The allocation of the cryptographic functions to the packet assembly and disassembly module also fully avoids any problems related to multiple streams and order of delivery, as well as to multiple IP addresses and dynamic address reconfiguration (see section 3.3). 4.6. Implementation issues In our group, a full SCTP implementation has already been developed in cooperation with an industrial partner, which is available under a GNU public license (see [Jungmaier et al., 9] for details). Based on this implementation and using the OpenSSL package (cf. [Cox et al., 2]), we have as a first step implemented the TLS over SCTP solution as defined in RFC 3436 (see chapter 3). The realization of S-SCTP requires – in addition to the definition of the new chunk types and procedures – modifications and extensions of the various modules of the SCTP implementation as indicated in figure 7. The SCTP controller module is a complex state machine controlling the status of an SCTP association (see, e.g., [Jungmaier et al., 11]). For S-SCTP we introduce an additional state machine which controls the activation and deactivation of cryptographic processing including initial key exchange, re-keying, and changes of the security level. Another major part of the new S-SCTP functionality is integrated into the packet assembly and disassembly module responsible for mapping user data and control chunks to SCTP packets together with the common SCTP header as described in section 4.5. A detailed draft specification of S-SCTP defining types and detailed encoding of new chunks as well as necessary procedures can be found in [Unurkhaan, 37]. Based on this draft specification and using our existing SCTP implementation, a prototype implementation of S-SCTP is currently under development. For the cryptographic

Figure 7. S-SCTP protocol architecture.



functions, we use the relevant parts of the OpenSSL library to avoid recoding of the crypto algorithms. This allows for performing the encryption, decryption and generation of HMACs according to the negotiated cipher suites. As default, we use the DH_with_3DES_CBC_SHA cipher suite, but similar to TLS and IPsec, our concept allows flexible addition and selection of various cipher suites.

4.7. Experimental results First results from experiments in a testbed environment showed very promising results for the performance of the Secure SCTP prototype even though the implementation has not yet been optimized for peak performance. We compared the behaviour of all three security solutions in two important scenarios: 1. In a first scenario we measured end-to-end throughput between two PCs depending on the security protocol used, and varied the percentage of data that needed to be transmitted securely. 2. In a second scenario we compared the main memory used by the different security solutions depending on the number of streams that needed to be secured. For both scenarios, we connected two single-homed PCs (Linux-based Pentium 3 workstations with 500 MHz processors) to a 100 MBit/s switched ethernet and used a simple test program to measure the end-to-end throughput as perceived by the application layer, and the memory used by the processes, respectively. All security solutions

Figure 8. Throughput of security solutions depending on percentage of secured messages.



Figure 9. Memory consumption of security solutions depending on the number of streams.

used identical encryption and authentication algorithms, i.e. 3DES and SHA-1, and all messages transmitted were of size 1300 bytes. In the first case (see figure 8), we can see that for IPsec it does not matter how much data actually needs to be encrypted, as all traffic between the endpoints is treated equally. This gravely affects performance, even if only a small percentage of the data actually needs to be secured. As IPsec is implemented in the operating system kernel, its performance is slightly better than TLS over SCTP or Secure SCTP for a high fraction of encrypted data. It is also apparent that both Secure SCTP and TLS over SCTP achieve a similar and much higher throughput when only a smaller fraction of data is encrypted. It is also worth to be noted that Secure SCTP achieves a slightly higher throughput than TLS over SCTP which comes as an advantage of the integrated solution. Figure 9 shows the behaviour of the security solutions depending on the number of SCTP message streams that need to be secured. Note that for reasons of clarity, only a fraction of the values we measured are displayed. Since TLS over SCTP establishes a separate TLS connection for each secured message stream, memory use for this solution increases linearly with the number of secured streams. Furthermore, our measurements showed that this trend continues for even higher numbers of streams. The other two solutions show a nearly constant use of main memory (approx. 1.8 MByte for SCTP over IPsec, and 2.05 Mbyte for Secure SCTP). This difference is due to the fact that for IPsec the standard SCTP implementation could be used, and security mechanisms are implemented in the operating system kernel. Secure SCTP, on the other hand, is implemented as a user process and thus shows a slightly higher memory footprint.





SCTP is a new multi-purpose transport protocol defined by IETF, which due to its various features and easy extendability will be a valid option in many application scenarios – not only in those already standardized. The analysis of already standardized and potential application scenarios clearly indicates that secure end-to-end transport is one of the crucial requirements for SCTP in the future. While the standardized solutions already proposed, namely TLS over SCTP and SCTP over IPSec, provide such secure transport, they suffer from limitations and inefficiencies prohibiting full exploitation of the advantages of SCTP. This is a clear consequence of the fact that no or only minor modifications to the standard protocols are acceptable for these solutions. To complement these approaches, we propose S-SCTP with integrated security functions as a more experimental but optimised solution. The prototype implementation currently under development serves as a proof of concept and will allow us to quantify the additional effort in terms of code and implementation effort. First results with the prototype presented in section 4.6 showed the benefits of Secure SCTP compared to the standard solutions in two application scenarios.

References [1] M. Allman, V. Paxson and W. Stevens, TCP congestion control, RFC 2581 (April 1999). [2] M. Cox, R. Engelschall et al., The OpenSSL project (September 2003) http://www.openssl. org. [3] T. Dierks and C. Allen, The TLS protocol version 1.0, RFC 2246 (January 1999). [4] T. Dreibholz, An introduction to reliable server pooling (September 2003) [5] T. Dreibholz, A. Jungmaier and M. Tüxen, A new scheme for IP-based Internet-mobility, in: Proc. of the IEEE Conf. on Local Computer Networks (LCN 2003), Bonn (October 2003). [6] D. Eastlake, S. Crocker and J. Schiller, Randomness recommendations for security, RFC 1750 (December 1994). [7] T. George, B. Bidulock et al., SS7 MTP2-user peer-to-peer adaptation layer, IETF, Network Working Group, draft-ietf-sigtran-m2pa-12.txt (June 2004) work in progress. [8] D. Harkins and D. Carrel, The Internet key exchange (IKE), RFC 2409 (November 1998). [9] A. Jungmaier et al., SCTPLIB – an SCTP implementation (May 2004) http://freshmeat. net/projects/sctplib. [10] A. Jungmaier, E. Rescorla and M. Tüxen, Transport layer security over stream control transmission protocol, RFC 3436 (December 2002). [11] A. Jungmaier, M. Schopp and M. Tüxen, Performance evaluation of the stream control transmission protocol, in: ATM 2000 – Proc. of the IEEE Conf. on High Performance Switching and Routing (2000) pp. 141–148. [12] S. Kent and R. Atkinson, IP authentication header, RFC 2402 (November 1998). [13] S. Kent and R. Atkinson, IP encapsulating security payload (ESP), RFC 2406 (November 1998). [14] S. Kent and R. Atkinson, Security architecture for the Internet protocol, RFC 2401 (November 1998). [15] S.J. Koh et al., Use of SCTP for seamless handover, IETF, Network Working Group, draft-sjkohmobile-sctp-handover-00.txt (February 2003) work in progress.



[16] H. Krawczyk, M. Bellare and R. Canetti, HMAC: Keyed-hashing for message authentication, RFC 2104 (February 1997). [17] J. Loughney et al., Signalling connection control part user adaptation layer (SUA), IETF, Network Working Group, draft-ietf-sigtran-sua-15.txt (June 2003) work in progress. [18] J. Loughney, M. Tüxen and J. Pastor-Balbas, Security considerations for SIGTRAN protocols, RFC 3788 (June 2004). [19] D. Maughan et al., Internet security association and key management protocol (ISAKMP), RFC 2408 (November 1998). [20] J. McCann, S. Deering and J. Mogul, Path MTU discovery for IP version 6, RFC 1981 (August 1996). [21] D. McDonald, C. Metz and B. Phan, PF_KEY key management API, version 2, RFC 2367 (July 1998). [22] J. Mogul and S. Deering, Path MTU discovery, IETF, Network Working Group, RFC 1191 (November 1990). [23] K. Morneault et al., Signaling system 7 (SS7) message transfer part 2 (MTP2) – User adaptation layer, IETF, Network Working Group, RFC 3331 (September 2002). [24] L. Ong, I. Rytina et al., Framework architecture for signaling transport, IETF, Signaling Transport Working Group, RFC 2719 (October 1999). [25] R. Pereira and R. Adams, The ESP CBC-mode cipher algorithms, RFC 2451 (November 1998). [26] M. Riegel and M. Tüxen, Mobile SCTP, IETF, Network Working Group, draft-riegel-tuexen-mobilesctp-03.txt (August 2003) work in progress. [27] G. Sidebottom et al., Signaling system 7 (SS7) message transfer part 3 (MTP3) – User adaptation layer (M3UA), IETF, Network Working Group, RFC 3332 (September 2002). [28] R. Stewart et al., On the use of stream control transmission protocol (SCTP) with IPsec, RFC 3554 (June 2003). [29] R. Stewart et al., SCTP dynamic address reconfiguration, IETF, Network Working Group draft-ietftsvwg-addip-sctp-09.txt (June 2004) work in progress. [30] R. Stewart et al., Aggregate server access protocol (ASAP), IETF, Network Working Group, draftietf-rserpool-asap-09.txt (June 2004) work in progress. [31] R. Stewart et al., Stream Control Transmission Protocol (SCTP) partial reliability extension, RFC 3758 (May 2004). [32] R. Stewart et al., Stream control transmission protocol (SCTP) implementor’s guide, IETF, Network Working Group, draft-ietf-tsvwg-sctpimpguide-10.txt (November 2003) work in progress. [33] R. Stewart, Q. Xie et al., Stream control transmission protocol, IETF, Signaling Transport Working Group, RFC 2960 (October 2000). [34] M. Stillman et al., Threats introduced by rserpool and requirements for security in response to threats, IETF, Network Working Group, draft-ietf-rserpool-threats-01.txt (August 2003) work in progress. [35] J. Stone, R. Stewart and D. Otis, Stream control transmission protocol (SCTP) checksum change, IETF, Network Working Group, RFC 3309 (September 2002). [36] M. Tüxen et al., Architecture for reliable server pooling, IETF, Network Working Group, draft-ietfrserpool-arch-07.txt (October 2003) work in progress. [37] E. Unurkhaan, Secure SCTP – A draft specification, Computer Networking Technology Group, University Duisburg-Essen, Germany (February 2004). [38] Q. Xie, R. Stewart and M. Stillman, Endpoint name resolution protocol (ENRP), IETF, Network Working Group, draft-ietf-rserpool-enrp-09.txt (June 2004) work in progress.