See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/220144818

Secure SCTP - A versatile secure transport protocol

Article  in  Telecommunication Systems · October 2004

DOI: 10.1023/B:TELS.0000041012.85567.54 · Source: DBLP

CITATIONS READS

18 5,346

3 authors, including:

Esbold Unurkhaan
MNCERT/CC
7 PUBLICATIONS   58 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

SCTP (Stream Control Transmission Protocol) View project

Information System Development View project

All content following this page was uploaded by Esbold Unurkhaan on 16 July 2014.

The user has requested enhancement of the downloaded file.

 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}@exp-math.uni-essen.de
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

1. Introduction to SCTP

SCTP, as defined in [Stewart et al., 32, 33; Stone et al., 35], is a connection-orient-
ed, 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 meth-
ods 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. log-
ical entities that implement the protocol. These endpoints are identified by a set of trans-
port 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 infor-
mation (control chunks) for establishing/releasing associations, selectively acknowledg-
274 UNURKHAAN ET AL.

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 associa-
tion 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.
SECURE SCTP 275

1.2. Multi-homing and path monitoring

For an SCTP endpoint, the notion of a path is equal to that of one peer destination ad-
dress. 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 des-
tination 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 re-
transmissions 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 acknowledge-
ments (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, al-
lowing 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 car-
rying them within one association. Due to the separation of streams, messages of one
276 UNURKHAAN ET AL.

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 avail-
able (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
SECURE SCTP 277

chunks will not be retransmitted. A new parameter, called fwtsn is defined for that pur-
pose 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 sec-
tion 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 remov-
ing 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 pur-
pose, 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 net-
work, 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 asso-
ciation. 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 imple-
mented.
278 UNURKHAAN ET AL.

2. 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 consen-
sus 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 authenti-
cation, 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 al-
ready 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 sec-
tion 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 pro-
tocols 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 environ-
ment. 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 pro-
tocols, and makes recommendations as to which security mechanisms nodes supporting
Sigtran based communication should implement in order to guarantee a minimum se-
curity 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 solu-
tions described in section 3, namely TLS over SCTP or SCTP over IPsec.
SECURE SCTP 279

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 authenti-
cated 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 up-
grade, 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 archi-
tecture [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. More-
over, 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
280 UNURKHAAN ET AL.

property, but support for this is considered optional. In particular, NS ↔ NS commu-

nication 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 protec-
tion 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 pro-
tection. If integrity is guaranteed, authentication mechanisms can safely be imple-
mented. 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 modifi-
cations or restrictions as possible. A natural choice for offering cryptographically secure
services are protocols operating above the transport protocol, such as transport layer se-
curity (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 byte-
oriented, 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 implementa-
tion 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 estab-
lished 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, sec-
tion 6.2.3]), i.e. 18437 bytes. TLSCiphertext records of a TLS connection are sent as
SECURE SCTP 281

SCTP user messages within one bidirectional stream. SCTP takes care of proper frag-
mentation 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 inse-
cure 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 communi-
cation 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 differ-
ent 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 as-

sociation 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 des-
tination 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 imple-
menting 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 charac-
teristics such as source or destination addresses, transport protocols used, or source or
destintation ports.
282 UNURKHAAN ET AL.

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 as-
sociations, 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 au-
thenticate a packet’s source are based on MD5 and SHA-1. The symmetric crpyto-
algorithms 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 mes-
sages 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 authentica-
tion 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
SECURE SCTP 283

X.509 certificate and client authentication via CHAP can be used (provided the under-
lying 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 scalabil-
ity 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 in-
sequence 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 pro-
tected by TLS, unless suitable TLS extensions are standardized and provided in imple-
mentations. 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 trans-
port 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.
284 UNURKHAAN ET AL.

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, destina-
tion 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 op-
erating 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 infor-
mation. 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.
SECURE SCTP 285

Table 1
Comparison of TLS/SCTP and SCTP/IPsec.
Criteria TLS over SCTP SCTP over IPsec
Scalability for multiple streams – +
Overhead for small messages (bundling) – +
Overhead for long messages (fragmentation) – +
Protection for unordered delivery service no +
Protection for SCTP control chunks no +
Flexible multiplexing of secure/insecure streams + no
Management of security sessions (handling, automation) + –
Partially Reliable Transport (SCTP extension) no +
Support for SCTP multi-homing + (–)
Dynamic Address Reconfiguration (SCTP extension) + –

4. 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 inte-
grates 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 Re-
configuration 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 over-
head 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 updat-
ing (rekeying) is decreased for long-lived associations. Compared to IPsec in the case
286 UNURKHAAN ET AL.

of many possible address combinations between the endpoints, cost is minimized since
there is no need to establish many security associations. Further, to minimize trans-
mission 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 func-
tional 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 pos-
sible 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 imple-
menting the security mechanism, please refer to section 4.5.
Similar to security protocols as TLS, S-SCTP uses a hybrid encryption mecha-
nism: an asymmetric crypto-algorithm establishes a shared secret between communica-
tion endpoints, and a symmetric algorithm actually encrypts the user data. We define
several phases within an S-SCTP association:
SECURE SCTP 287

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

1. The first phase, the insecure transmission phase is entered right after the establish-
ment 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 secu-
rity level. This phase is called secure session phase.
4. When the application terminates the secure session, phase 4, the secure session ter-
mination 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 se-
cure 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
288 UNURKHAAN ET AL.

Table 2
List of new chunk types for S-SCTP.
Chunk type Chunk name
0xD0 Secure session open request
0xD1 Secure session certificate
0xD2 Secure session acknowledge
0xD3 Secure session server key
0xD4 Secure session client key
0xD5 Secure session open complete
0xD6 Secure session close
0xD7 Secure session close acknowledge
0x10 Encrypted data chunk
0x11 Authentication chunk
0x12 Padding chunk

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

the secure session, for intermediate re-keying handshakes, and the termination of se-
cure 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
SECURE SCTP 289

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 suffi-
cient 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 asso-
ciation (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 exchang-
ing 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 Ses-
sion Open Request chunk. The chunk type code point is chosen such that a peer imple-
mentation 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
290 UNURKHAAN ET AL.

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).
SECURE SCTP 291

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.
292 UNURKHAAN ET AL.

The integration of encryption and HMAC calculation clearly optimises the trans-
mission overhead and the computational effort. Moreover, S-SCTP packets are self-
contained 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 reconfigura-
tion (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 proto-
type implementation of S-SCTP is currently under development. For the cryptographic

Figure 7. S-SCTP protocol architecture.

SECURE SCTP 293

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 gener-
ation 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 applica-
tion layer, and the memory used by the processes, respectively. All security solutions

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

294 UNURKHAAN ET AL.

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 secu-
rity 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.
SECURE SCTP 295

5. Conclusion

SCTP is a new multi-purpose transport protocol defined by IETF, which due to its vari-
ous 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 po-
tential 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 inef-
ficiencies prohibiting full exploitation of the advantages of SCTP. This is a clear con-
sequence 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) http://tdrwww.exp-
math.uni-essen.de/dreibholz/rserpool/.
[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 (De-
cember 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-sjkoh-
mobile-sctp-handover-00.txt (February 2003) work in progress.
 296 UNURKHAAN ET AL.

[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-mobile-
sctp-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-ietf-
tsvwg-addip-sctp-09.txt (June 2004) work in progress.
[30] R. Stewart et al., Aggregate server access protocol (ASAP), IETF, Network Working Group, draft-
ietf-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-ietf-
rserpool-arch-07.txt (October 2003) work in progress.
[37] E. Unurkhaan, Secure SCTP – A draft specification, Computer Networking Technology Group, Uni-
versity 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.

View publication stats