| draft-ietf-sigtran-sctp-applicability-02 Description: Request For Comments
You can download source copies of the file as follows:
Listed below is the contents of file draft-ietf-sigtran-sctp-applicability-02.txt.
INTERNET-DRAFT L. Coene
Internet Engineering Task Force M. Tuexen
Issued: 30 september 2000 Siemens
Expires: 31 March 2001 J. Loughney
Nokia
I. Rytina
Ericsson
L. Ong
Nortel Networks
R.R. Stewart
Cisco
Stream Control Transmission Protocol Applicability Statement
<draft-ietf-sigtran-sctp-applicability-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-
Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document describes the applicability of the Stream Control
Transmission Protocol for general usage in the internet. Some of the
prominent features, such a the selective acknowledgement, Congestion
control, fast retransmit etc.. are explained in some detail. The
design of SCTP against certain forms of attacks in the internet is
also discussed. The use and specification of adaptation layers in
conjunction with SCTP is described. A few general applications are
described such as the transport of signalling information (SS7,
DSS1/2 ...) over IP infrastructure
Coene, et al. Informational [Page 1]
Table of Contents
Stream Control Transmission Protocol Applicability statement
................................................................ ii
Chapter 1: Introduction ........................................ 1
Chapter 2: Stream Control Transmission Protocol -- SCTP ........ 3
Chapter 2.1: Introduction ...................................... 3
Chapter 2.2: Issues affecting deployment of SCTP ............... 3
Chapter 2.2.1 : SCTP multhoming ................................ 4
Chapter 2.2.2 : Fast retransmit of chunks ...................... 6
Chapter 2.2.3 : Use of SCTP in Network Address
Translators(NAT) networks ...................................... 6
Chapter 2.2.4 : MTU path discovery ............................. 7
Chapter 2.2.5 : Use of multiple streams ........................ 7
Chapter 2.2.6 : Congestion control & Flow control .............. 8
Chapter 2.2.6.1 : 3-Sack rule in SCTP .......................... 10
Chapter 2.2.6.2 : Congestion control ........................... 12
Chapter 2.2.6.3 : Use of explicit Congestion
Notification(ECN) .............................................. 13
Chapter 2.2.6.4 : Duplicated messages .......................... 13
Chapter 2.2.6.5 : SCTP in high throughput delivery networks
................................................................ 13
Chapter 2.2.6.6 : SCTP in long delay/Fat networks(LFN) ......... 13
Chapter 2.2.6.7 : SCTP in long thin Networks(LTN) .............. 14
Chapter 2.2.7 : Use of the protocol Identifier ................. 14
Chapter 2.2.8 : Use of QOS methods ............................. 14
Chapter 2.2.9 : SCTP checksum .................................. 15
Chapter 2.2.10: ???tunneling ??? .............................. 16
Chapter 2.2.11: How to use and define adaptation layers ........ 16
Chapter 2.2.12: Security considerations ........................ 17
Chapter 3: Adaptation Layers ................................... 20
Chapter 4: References and related work ......................... 23
Chapter 5: Acknowledgments ..................................... 24
Chapter 6: Author's address .................................... 25
1 Introduction
This document covers subject terminology and makes a overview of
the solutions for transporting information over Internet Protocol
infrastructure. The transport medium used is the Stream Control
Coene, et al. Informational [Page 1]
Draft SCTP applicability statement March 2000
Transmission Protocol (SCTP). However some of the issues may also relate
to the transport of information via TCP.
SCTP provides the following services to its users:
- acknowledged error-free non-duplicated transfer of user data
- transport-level segmentation to conform to discovered MTU size
- sequenced delivery of user datagrams within multiple streams,
with an option for order-of-arrival delivery of individual
datagrams
- optional multiplexing of user datagrams into SCTP datagrams, sub-
ject to MTU size restrictions
- enhanced reliability through support of multi-homing at either
or both ends of the association.
- Explicit indication in the message of the application protocol
SCTP is carrying.
1.1 Terminology
The following terms are commonly identified in related work:
Port Number: Indicates on the transport level which application
needs to be reached in the layer above.
Transport Address: An IP address and a port number forms a tran-
sport address which identifies a SCTP association.
Protocol Identifier: Indicates the upper layer protocol that is
using SCTP for the transport of its data.
Chunk: a unit of information within an SCTP datagram, consisting
of a chunk header and chunk-specific content. Each chunk can con-
tain user or data information about the particular SCTP associa-
tion.
Coene, et al. Informational [Page 2]
Draft SCTP applicability statement March 2000
Multihoming: Endpoint which uses more than one IP address for
receiving SCTP datagrams on the same association.
NAT: Network Address Translation
SACK: Selective Acknowledgement message, this is a response on the
data msg acknowledging the receipt of it at the remote side.
TSN: Transaction Sequence Number, this is a number assigned by
SCTP to assure reliable delivery of user data within an associa-
tion.
MTU: Maximum Transmission unit, the maximum length (in bytes) that
a message may have without being segmented along the path the mes-
sage takes.
2 Stream Control Transmission Protocol -- SCTP
2.1 Introduction
The Stream Control Transmission Protocol (SCTP) provides a high reli-
able, redundant transport between two endpoints. The interface between
SCTP and its applications is handled via adaptation layers which provide
a intermediate layer so that the existing upper layer protocols do not
have to change their interface towards the transport medium and internal
functionality when they start using SCTP instead of an other transport
protocol.
The following function are provided by SCTP:
- Initialization of transport association
- Synchronization of association state
- Synchronization of sequence numbering
- Reliable Data Transfer
- Forward and backward sequence numbering
- Timers for transmission and acknowledgement
- Notification of out-of-sequence - Retransmission of
lost messages
- Support of multiple control streams
Coene, et al. Informational [Page 3]
Draft SCTP applicability statement March 2000
- Separate sequence control and delivery of each stream
- Congestion control
- Window flow control
- Congestion avoidance based on TCP methods, e.g. using
retransmission backoff, window reduction, etc.
- Detection of session failure by active means, e.g. heartbeat
- Termination of association
SCTP does support a number of functions that are not provided by current
TCP:
- no head-of-line blocking, i.e. multiple streams
- multilink failover for added reliability
- keep-alive function for active rapid failure detection
- message versus byte sequence numbering
- tighter timer control (than the standard TCP implementations)
By defining the appropriate User adaptation module, a reliable
transport mechanism can be provided:
- reliable transmission of packets with end-to-end congestion con-
trol provided using methods similar to TCP
- choice between sequenced and unsequenced, reliable message
delivery
- keep-alive message
Within a association between the two endpoints, 1 or more stream(s) may
be available. These streams are visible to the adaptation layers but are
invisible to any layer above the adaptation layer.
2.2 Issues affecting deployment of SCTP
2.2.1 SCTP Multihoming
Coene, et al. Informational [Page 4]
Draft SCTP applicability statement March 2000
Redundant communication between 2 SCTP endpoints is achieved by using
multihoming where the endpoint is able to send/receive over more than
one IP address.
Under the assumption that every IP address will have a different,
seperate paths towards the remote endpoint, (this is the responsibility
of the routing protocols or of manual configuration) , if the transport
to one of the IP address (= 1 particular path) fails then the traffic
can migrate to the other remaining IP address (= other paths) within the
SCTP association.
As a practical matter, it is recommended that IP addresses in a mul-
tihomed endpoint be assigned IP endpoints from different TLV's to ensure
against network failure.
Multihoming provides redundant communication in SCTP by allowing commun-
ication between two endpoints to continue in the event of failure along
a path between the endpoints.
In IP implementations the outgoing interface of multihomed hosts is
ofter determined by the destination IP address. The mapping is done by a
lookup in a routing table maintained by the operating system. Therefore
the outgoing interface is not determined by SCTP. Using such implemen-
tations, it should be noted that a multihomed host cannot make use of
the multiple local IP addresses if the peer is singlehomed. The mul-
tihomed host has only one path and will normally use only one of its
interfaces to send the SCTP datagrams to the peer. If this physical path
fails, the IP routing table in the multihome host has to be changed.
Somethink which is out of scope of SCTP.
SCTP will always send its traffic to a certain transport address (= des-
tination address + port number combination) for as long as the transmis-
sion is uninterrupted (= primary). The other transport addresses (secon-
dary paths) will act as a backup in case the primary path goes out of
service. The changeover between primary are backup will occur without
packet loss and is completely transparent to the application.
The port number is the same for all transport addresses of that specific
association.
Applications directly using SCTP may choose to control the multihoming
service themselves. The applications have then to supply the specific IP
address to SCTP for each datagram. This might be done for reasons of
load-sharing and load-balancing across the different paths. This might
not be advisable as the throughput of any of the paths is not known in
advance and constantly changes due to the actions of other associations
and transport protocols along that particular path, would require very
tight feedback of each of the paths to the loadsharing functions of the
Coene, et al. Informational [Page 5]
Draft SCTP applicability statement March 2000
user.
Applications using adaptation layers to run over SCTP do not have that
kind of control. The adaptation layers will have to take care of this.
By sending a keep alive message on all the multiple paths that are not
used for active transmission of messages across the association, it is
possible for SCTP to detect whether one or more paths have failed. SCTP
will not use these failed paths when a changeover is required.
The transmission rate of sending keep alive message should be modifiable
and the possible loss of keep alive message could be used for the moni-
toring and measurements of the concerned paths.
2.2.2 Fast retransmit of chunks
The retransmission of a message is basically governed by the retransmis-
sion timer. So if no acknowledgement is received after a certain time,
then the message is retransmitted. However there is a faster way for
retransmitting which is not dependant on that timer.
Every second message that a node received will be acknowledge to the
remote peer. If gaps occur in the acknowledge message at the remote
side, then the remote side will wait 3 further gap reports (acknowledge-
ments) before it retransmit the message. As the gap occurs, the node
must transmit a SACK on every datagram until there are no more gap. This
retransmission will happen far sooner than with a timer. Especially if
the traffic volume increases in SCTP, those retransmissions of the
chunks would happen faster and faster (and hopefully, they would also be
faster acknowledged). In any case if gaps occur, the node will certainly
try to acknowledge them faster(irespective of the fact if the SACKs will
get to the remote node, where, if received, they would speed up the
retransmission of the chunks)
See also the paragraph on congestion control and avoidance.
2.2.3 Use of SCTP in Network Address Translator (NAT) Networks
When a NAT is present between two endpoints, the endpoint that is behind
the NAT, i.e., one that does not have a publicly available network
address, shall take one of the following options:
A) Indicate that only one address can be used by including no transport
addresses in the INIT message. This will make the endpoint that receives
Coene, et al. Informational [Page 6]
Draft SCTP applicability statement March 2000
this Initiation message to consider the sender as only having that one
address. This method can be used for a dynamic NAT, but any multi-homing
configuration at the endpoint that is behind the NAT will not be visible
to its peer, and thus not be taken advantage of.
B) Indicate all of its networks in the Initiation by specifying all the
actual IP addresses and ports that the NAT will substitute for the end-
point. This method requires that the endpoint behind the NAT must have
pre-knowledge of all the IP addresses and ports that the NAT will
assign.
This requires the adaptation of NAT boxes to search within SCTP outgoing
INIT and incoming INIT_ACK mesages for the addresses and replace them
with the NAT internal address in addition to replacing the addresses in
the IP header.
C) Use RSIP where the connection is tunneled from host until the NAT
border and the host layers above IP network layer have no knowledge of
the NAT internal addresses.
D) Use the hostname feature and the DNS to resolve the addresses. The
hostname is included in the INIT of the association or in the INIT-ACK.
The hostname must be resolved by the DNS before the association is com-
pletely set up. That means that more time shall be needed for the com-
pletion of the association setup as the DNS has to be queried.
2.2.4 MTU path discovery
SCTP discovers the maximal length of the message that can be transported
through the network to the final destination without having to
fragment(=chop something in pieces) the message in IP network layer.
This avoids using IP fragmenting. SCTP level segmentation is beneficial
because if a packet is lost during network transmission, only that
packet will need to be retransmitted. Contrasted with IP-level segmenta-
tion, where the whole unsegmented message will have to be retransmitted,
this is a much more effective scheme [RFC1981].
2.2.5 Use of multiple streams
A stream is a unidirectional flow of user messages between 2 endpoints
within a SCTP association. The messages within the stream may be ordered
or un-ordered (by request from the user/application). A association can
have one or more streams in its association and the number of streams in
one direction does NOT need to be the same as the number of streams in
Coene, et al. Informational [Page 7]
Draft SCTP applicability statement March 2000
the opposite direction. The number of streams in both directions is thus
assymmetrical.
The application can choose on which stream it can send it data. Streams
may specify order of deliver or sequenced delivery. Some application
level protocols may reserve certain streams for certain media, for exam-
ple sending graphical content (jpeg, gif, etc.) of a web page through a
certain stream while text through others, and streaming content through
others. Any packet loss on one stream will not block packet transmis-
sion on others.
Each stream within a association should be looked upon as a link between
two points. If multiple streams are used then the application is dealing
with multiple links towards the destination. Some applications may
require the use of sequenced delivery, which would require for them to
select a certain link to send their message on.
2.2.6 Congestion control & Flow control
Congestion control and/or avoidance is of primordial importance in any
connectionless network. Congestion is the result of approaching or
exceeding the processing capacity of the link, network, application
and/or transport layers. If the processing capacity is exceeded, then
the congestion can be avoided (example taking a other non-congested path
towards the destination) or controlled (for example, reducing the rate
of messages to that destination = flow control).
Flow control algorithms do control the rate with which messages are
injected into the network. Both endpoints can try to influence the mes-
sage rate of each other based on the congestion they experience at their
own side. If no congestion is present in the network, then flow control
will still be at work, trying to achieve a steady message rate for that
association.
The reaction of SCTP to congestion is detailed in the next paragraphs.
Congestion can be controlled and/or avoided on different levels:
- Transport: congestion control/avoidance within SCTP, TCP(fig
2.1.2)
- Network : Congestion control/avoidance present in the network
layers( example: SCCP, MTP ...)
- Link layer: flow control
Coene, et al. Informational [Page 8]
Draft SCTP applicability statement March 2000
SCTP conforms to the model of end-to-end congestion control (Fig
2.2.6.2) [RFCSALLY] while ISUP and SCCP model themselves on a link and
network based congestion control/overload mechanism (Fig 2.2.6.3).
End-to-end congestion control is based on the following assumption, if
message loss occurs in the network, it happens due to congestion, NOT to
a castrophic host, link or router failure in the network.
| |
| Application and/or transport layer |
+---------------------------------------------------+
| A
| |
| +-------------------------------------+ |
---->| |----
| Network layer |
---->| |----
| +-------------------------------------+ |
| |
| V
+---------------------------------------------------+
| |
| Link layer |
Fig 2.2.6.1 General Congestion model
| |
|transport layer| Congestion control present based on
| SCTP | windows
+---------------+
| A
V |
+---------------+
| |
| Network layer | No congestion control present
| IP(v4/v6) | in the IP layer
+---------------+
| A
V |
+---------------+
| Ethernet | No congestion control present
| Link layer | in the Ethernet link layer
Fig 2.2.6.2 End-to-End congestion control
Coene, et al. Informational [Page 9]
Draft SCTP applicability statement March 2000
| |
|Application layer| Congestion control present for
| TC + MAP, IN... | specific applications
+-----------------+ - MAP: No congestion control
| A - IN: Call gapping
V |
+-----------------+
| |
| Network layer | Congestion control present in the
| SCCP & MTP | in MTP and SCCP based on link and
+-----------------+ destination status
| A
V |
+-----------------+
| MTP lvl 2 | Congestion control present
| Link layer | in the link layer
Fig 2.2.6.3 Distributed congestion control
By default, SCTP associations do not have a fixed capacity assigned to
them unless other QoS mechanisms are employed. Thus congestion within
SCTP association can and will be affected by all traffic using the same
links including other SCTP, TCP, RTP, UDP ... traffic traveling on the
same path followed by the SCTP association.
2.2.6.1 3-SACK rule in SCTP.
The Selective Acknowledgement (SACK) is one of the cornerstones of SCTP.
It selectively Acknowledges datagrams that have been successfully
received by the remote node. It serves 2 purposes:
- it indicates until a certain datagram that all previous
datagrams have been received (without any holes in the
sequence) and
- it indicates the datagrams sequence ranges which have been
received (and so does indicate the holes/gaps between them).
It provides us with a form of gap/hole report on messages that
have been lost or delayed. A hole can consist of one or more
messages.
Coene, et al. Informational [Page 10]
Draft SCTP applicability statement March 2000
sender Receiver
- |-----* | -
Emission I | * | I Link delay
time - |----* * | I time
I | * *----------->| -
I | * |
Round I |---* *------------>|
trip I | : * /----|<-------- acknowledge sent
time I | : *-------- / --->| after 2 data's
I | : /: |
- |<------------/ : |
Round trip Time = RTT
Windowsize = Cwnd
Fig 2.2.6.4 Influence of Window Size/ Link Speed/ Round Trip Delay
Fig 2.2.6.4 is given here as a example where after receiving 2 messages
an advisory acknowledgement (SACK) is sent (in this case window = 4).
Therefore the sender could be kept busy. The acknowledgement opens the
window again. The total time (from first emission till the receiving of
the acknowledgement) calculates as: (max. windowsize * emission time)/2
+ round trip delay. If the round trip time(RTT) is large, the advisory
acknowledgments (SACK) will enhance the throughput.
The SACK is always generated and send back to the sender either
- after every second message received (delayed ack).
- after at most 200ms after receiving the last message.
The reason for the holes may be diverse:
- simple message loss
- different round trip times of messages being transmitted on
different interfaces
At the sender end, whenever the sender notices a hole in a SACK, it
should wait for 3 further SACKs (identifying the same hole) before tak-
ing action. This is 3 strikes besides the first one, so that means 4.
Thus after 4 SACK, the datagrams belonging to the hole should be
retransmitted(and only those).
Coene, et al. Informational [Page 11]
Draft SCTP applicability statement March 2000
If gaps occur, the receiver end will send SACKs on every data message
received instead on being send on every second data message received. As
the sender is waiting for the 3 SACK strikes and the receiver is
increasing the SACK rate, that would mean that retransmission would be
happening faster. Also the window should be opening up more than in the
normal case (= transmission without gaps).
The 3 SACKs rule might be relaxed in certain networks provided certain
condition are met:
- private IP network
- closed networks
- only a single type of application traffic is running on that
network (the message in the network exhibit the same charac-
teristics:
example: signalling messages).
The SACK rule might be configurable in such a networks, if the network
operator felt confident in the correctness of the network. This would
mean that in case of packet loss, retransmission could be "immediate".
SACK will also report duplicate message arrival. See paragraph 2.2.6.4.
2.2.6.2 Congestion Control
The number of messages in flight is determined by the Congestion window
(Cwnd). Every time a message is SACK, a new message(with size x bytes)
might be send to the remote side(up till the (Cwnd + 1 MTU - 1) bytes),
even if gaps exists which might ultimately lead to retransmissions.
The value of the Cwnd is dependant on the slow start and/or congestion
avoidance/control and is set in bytes, not messages. (takes care of
using small or large messages for pulling a leg on the congestion con-
trol algorithm)
If messages are getting lost, then it is assumed by SCTP that they are
lost according to congestion, not that they are lost due to error on the
link(such as cable cutthrough ...).
When messages are lost then the rate of messages sending is reduced,
till no messages are lost.
Coene, et al. Informational [Page 12]
Draft SCTP applicability statement March 2000
The consequence of using congestion control in SCTP or any other tran-
sport protocol(provided it is end-to-end) is that during the time the
association is up and running, somewhere along the path taken by the
messages belonging to a certain association, a node or link may be
hovering in or near congestion.
2.2.6.3 Use of Explicit Congestion notification (ECN)
Explicit Congestion control is a experimental method for communicating
congestion back to the end node. SCTP does not support the use of ECN,
but specific recommendations for using ECN with SCTP might be forthcom-
ing. Specific Chunks have been reserved for ECN's use. See [SCTP]
2.2.6.4 Duplicated messages
SACKs can get lost(it is best-effort in both directions). The receiving
node would then receive duplicated packets, because the sending side
thought the messag it send was not acknowledge and thus did not arrive
at the receiving end. A reason for such a behavior is imbalance between
the 2 traffic direction, use of different up and down path.
2.2.6.5 SCTP in high throughput delivery networks
The TSN is associated with a message, not with the number of bytes(as is
the sequence number of TCP) in the message. So the TSN will wrap around
less frequently but has a dependency on the length of each message. Use
of short messages will lead to a faster wrapping around of the TSN. So
in high throughput networks, it is advised to make the messages as long
as possible so that the wrap around will be less frequent.
SCTP already has a larger window than TCP does even when TCP is using
the "large windows" option.
2.2.6.6 SCTP in long delay/Fat networks (LFN)
Long delay(Fat) Networks consists of network paths which have a high
"bandwidth*delay product"(such as satelite links(high delay) or high
capacity fiber(high bandwith)). There the 3-SACK rule would lead to
enhanced throughput, if the initial windowsize is set higher than
Coene, et al. Informational [Page 13]
Draft SCTP applicability statement March 2000
2(which is the default value for non-LFNs).
The initial windowsize should be set to a higher value (4 or 8) as that
would mean that 4 messages would be injected in the network and the
first sack would come back at about the same time as the last message
before the window is full, is injected.
Thus to have the most of the 3 sack rule immediatly, the initial window
size should at least be set at 4 (and possible at 8 if we are dealing
with really very long delays).
The drawback of this is that it makes SCTP more aggressive to begin
with(certainly when faced with TCP).
For a more precise description of the issues associated with this, refer
to [RFC123], [RFC2001] and [RFC2018]
2.2.6.7 SCTP in Long Thin Networks(LTN)
Long thin networks consists of network paths that traverse "very low
bit-rate" links(such as 56 Kbit modem links). This means that a single
host can very easy saturate such a link(= pushing the link into conges-
tion). And it is then this link which determines the congestion control
variables in SCTP.
2.2.7 Use of the protocol identifier in SCTP
Indicates the the upper layer protocol that is using the associations.
The protocol identifier is available to the application and is included
in each chunk. 0 is the unknown protocol. This protocol id can be used
by firewalls for filtering out certain protocols. If firewalls drops
certain protocol id's then the association will fail in the end because
the TSN will be lost.
The protocol identifier is administered by IANA[IANA].
2.2.8 Use of QoS methods
SCTP is a end-to-end protocol which cannot guarantee the quality-of-
service along the complete path(s) taken by the messages of that partic-
ular association. If more guarantees are required for improving the
reliability of the transport, some form of QoS mechanism may be needed.
The possible schemes are as follows.
Coene, et al. Informational [Page 14]
Draft SCTP applicability statement March 2000
2.2.8.1 Over-provisioning
Over-provisioning of the links so that the total traffic running over
the link never exceeds the link capacity. In practice, this may be dif-
ficult to ensure reliably. But SCTP will work to utilise as much of the
link as possible(going near or in congestion).
2.2.8.2 Private Internets
Use of a private network solely for transport purposes. Private networks
may allow better control and monitoring of resources available.
2.2.8.3 Differentiated services
By providing a certain code point in the Type-of-service field (TOS),
certain Differential services can be selected. [RFC2597, RFC2598]
Setting the code point for transport requires some thought. It is depen-
dant on the kind of differentiate service selected. Also the use of
traffic is important: example signalling info should have a higher
priority than the user data traffic for which the signalling is
responsible(and that relation does not always exist).
2.2.8.4 Integrated services
By use of integrated services [RFC2208], resources are reserved for sig-
naling transport.
If resources are unavailable for to initiate a new signaling transport,
that request will be denied. RSVP may not scale well and this solution
may prove to be unfeasible.
An example is Multi Protocol Label Switching.
2.2.9 SCTP Checksum
SCTP uses the Adler-32 checksum algorithm. This algorithm will perform
better than a 16 bit (CRC or not) checksum or even a 32 bit CRC check-
sum.
The message can also be protected by IPSEC which is much stronger. In
Coene, et al. Informational [Page 15]
Draft SCTP applicability statement March 2000
that case, the checksum should still be computed.
2.2.10 Tunneling of SCTP association over UDP
The basic operation of SCTP is to run directly on top of IP. However,
due to restrictions placed on implementers by Operating Systems, not all
implementations may be able to run over IP directly. Therefore an alter-
native is given which might circumvent some or all of the restrictions.
The STCP messages are transported over UDP instead. The following issues
must be observed:
- the port number in the UDP header should be the port number
assigned to SCTP. The port number in the SCTP common header
should be the one assigned to the user adaptation layer or to
the application of SCTP. This means that port numbers previ-
ously used in UDP and/or TCP can be reused for the same appli-
cation using SCTP. SCTP DOES NOT change the semantics of the
port number just because the protocol identifier is added to
the SCTP message.
- the checksum field might be used as a additional guard
against errors(particular errors in the UDP header). However,
the SCTP checksum employed is far better at catching errors,
but does not take the UDP header into account.
2.2.11 How to define and Use adaptation layers
Many different applications may use SCTP for different purposes. They go
from File transfer over HTTP transport to signalling information tran-
sport.
Some applications might want preserve the existing interface with its
lower layer (in this case SCTP) while for other applications, this does
not pose a problem. A narchitecture has been devised to let the applica-
tion choose whether they want to run over SCTP directly (just a many
applications run over TCP) or let application run on top of a adaptation
layer over SCTP.
The basic architecture is as in Figure 2.11.1 :
Coene, et al. Informational [Page 16]
Draft SCTP applicability statement March 2000
User/Application level Protocols
| | |
+------------------------------------+
| User Adaptation modules |
+------------------------------------+
|
+------------------------------------+
|Stream Control Transmission protocol|
+------------------------------------+
|
+------------------------------------+
| Standard IP Transport |
+------------------------------------+
|
Network Layer (IP)
Figure 2.11.1: Transport Components
The three components of the transport protocol are :
(1) Adaptation modules that support specific primitives, e.g. manage-
ment indications, required by a particular user/ application proto-
col. The use of a adaptation protocol is optional. It is only used
in case in which the application protocol does not want to change
its interface with the underlying layer.
(2) the Stream Control Transmission Protocol itself that supports a
common set of reliable transport functions.
(3) a standard IP transport/network protocol provided by the operating
system. In some network scenarios, it has been recognized that TCP
can provide limited (but sufficient) reliable transport functional-
ity for some applications.
2.2.12 Security considerations
The following aspects of security are :
Authentication:
Information is sent/received from a known and/or trusted partner.
Coene, et al. Informational [Page 17]
Draft SCTP applicability statement March 2000
Integrity:
Information may not be modified while in transit. The integrity of
a message in a public network is not guaranteed.
Confidentiality:
Confidentiality of the user data must be ensured. User data can
not be examined by unauthorized users.
Availability:
The communicating endpoint must remain in service in all cir-
cumstances. Some services have very high availability requirements:
for example, all SS7 nodes have to remain active for the 99.999% of
the time.
2.2.12.1 General Considerations
SCTP only tries to increase the availability of a network. SCTP does not
contain any protocol elements in its messages which are directly related
to Authentication, Integrity and Confidentiality functions. It depends
for such a features on the IPSEC protocols and architecture and/or on
security features of its user protocols.
The only function which has some bearing on security of SCTP is the
integrity of message in SCTP, which is guarded by a Checksum. This
checksum is always mandatory even if IPSEC is NOT used. It is advised to
use of IPSEC in the SCTP association on a END-TO-END basis. The use of
IPSEC on a part of a path of a SCTP association does NOT relieve SCTP
from using the checksum(as this ain't end-to-end transport)
The general rule is that IPSEC should be turned on unconditionally.
The description of the internet security architecture and the use of it
is described in [RFC2401].
2.2.12.2 The cookie mechanism and Denial-of-Service (DOS) attacks
The cookie mechanism in SCTP is a measure against Denial-of-Service
(DOS) attacks. In a DOS attack, a lot of init chunks are send towards a
single terminating node (the source is a bogus node = a invalid source
address in the datagram), so that very quickly all resources are used up
Coene, et al. Informational [Page 18]
Draft SCTP applicability statement March 2000
and that normal users are rejected due to resource shortage in the ter-
minating node/host.
How does SCTP counter a DOS attack(A: by running on Linux:-) : When a
INIT chunk is received, the TCB info is encoded and put into the cookie
and send to the initiating node via the INIT_ACK. No TCB is allocated at
the receiving node as all info is encoded in the cookie and the cookie
will return in the COOKIE_ACK (at that time the TCB will be really allo-
cated with the info from the cookie and a full association is set up).
As in the case of a DOS attack, the INIT_ACK will be send back to a
bogus address, no COOKIE_ACK will come back and no resources will be
tied up in the terminating node.
If however the INIT_ACK is not send back to a Bogus address but to a
real address, then resources will get reserved and a association will be
set up. THis would allow to find out who the initiator is.(provided of
course that the initiator started the association in the first place)
After the cookie exchange, a DNS query may be launched(if the host
option was used in the specification of the endpoint address) to resolve
the host name. It is not allowed to do that before as this would tie up
resources(wait for the DNS query answer to come back), thus state during
the time between INIT_ACK and COOKIE_ACK(thus negating the cookie
mechanism for the receiving end of the asociation).
But even with that constraint this opens up some interesting DDoS (= DNS
DOS) attacks. If X sends to B1, B2, ... B1000000 an INIT with host-
name-address = a.example.com then when the cookie exchanges are done
1,000,000 hosts will attempt to 1) pound on example.com's DNS server and
2) potentially send data to A. This assumes X has sufficient bandwith
to send the INIT etc packets to all the B's - or at least that X's band-
with exceeds A's bandwith to the net; not an unreasonable assumption.
Similar things apply to the INIT-ACK. In both cases example.com would
see this DNS traffic coming from all over the place - and nothing would
directly point back at X.
2.2.12.3 Initiate Tag considerations
As the tag is fixed during the whole lifetime of the association, the
initiate Tag values should be selected as random as possible to help
protect against "man in the middle" and "sequence number" attacks. It is
suggested that RFC 1750 [RFC1750] be used for the Tag randomization. A
new tag is only assigned if a new association is set up.
2.2.12.4 Fingerprinting of SCTP
Coene, et al. Informational [Page 19]
Draft SCTP applicability statement March 2000
Different implementations may show a certain fingerprint in their mes-
sages when they have to answer to certain messages send to them. It is
advisabel to send only the basic required information back according to
the SCTP protocol.
Fingerprinting is the art of figuring out whose implementation you are
dealing with by analysing certain parameters within the syntax of the
message.
Example: a certain TCAP implementation (from a vendor whose name shall
not be mentioned) always fills in the length field of its transaction in
a msg to 1 while all other folks fill in the maximum value 4.
2.2.12.5 The ACK-Splitting attack
The ACK-splitting attack splits up the acknowledgements send back to the
sender into segments, which acknowledge only a part of the received
message(see [SAVAGE99]) . Normally, a receiver should send back a single
acknowledge for a single send data message received. The net result of
ACK splitting is that the congestion window will grow for each ACK
received which is more than if the congestion window was grown for the
acknowledgement of the single message.
In SCTP this behaviour is counterd by the fact that the messages are
acknowledged and NOT the bytes. If a message is acknowledged, then the
congestion window is grown by a certain amount of bytes, depending on
the situation: MIN(msg size, path MTU)). A second SACK would Acknowledge
the same already acknowledged message and does not grow the congestion
window.
It is assumed for sake of clarity that one message contains only a sin-
gle chunk.
3 Adaptation Layers
Currently, there are four adaptation layers, to support carrying of SS7
application protocols over IP. These adaptation layers are being
developed for different purposes, and there is no assumption that they
should interwork - i.e. - M2UA carries M3UA. They should be thought of
as individual protocols for specific uses.
3.1 IUA
There is a need for Switched Circuit Network (SCN) signaling protocol
Coene, et al. Informational [Page 20]
Draft SCTP applicability statement March 2000
delivery from an ISDN Signaling Gateway (SG) to a Media Gateway Con-
troller (MGC). The delivery mechanism should meet the following cri-
teria
* Support for transport of the Q.921 / Q.931 boundary primitives
* Support for communication between Layer Management modules on SG
and MGC
* Support for management of active associations between SG and MGC
This draft supports both ISDN Primary Rate Access (PRA) as well as Basic
Rate Access (BRA) including the support for both point-to-point mode and
point-to-multipoint modes of communication. QSIG adaptation layer
requirements do not differ from Q.931 adaptation layer, hence the pro-
cedures described in this draft are also applicable to QSIG adaptation
layer.
3.2 M2UA
There is a need for SCN signaling protocol delivery from an Signaling
Gateway (SG) to a Media Gateway Controller (MGC) or IP Signaling Point
(IPSP). The delivery mechanism should meet the following criteria:
* Support for MTP Level 2 / MTP Level 3 interface boundary
* Support for communication between Layer Management modules on SG
and MGC
* Support for management of active associations between the SG and
MGC
In other words, the Signaling Gateway will transport MTP Level 3 mes-
sages to a Media Gateway Controller (MGC) or IP Signaling Point (IPSP).
In the case of delivery from an SG to an IPSP, the SG and IPSP function
as traditional SS7 nodes using the IP network as a new type of SS7 link.
This allows for full MTP Level 3 message handling and network management
capabilities.
3.3 M3UA
There is a need for SCN signaling protocol delivery from an SS7
Coene, et al. Informational [Page 21]
Draft SCTP applicability statement March 2000
Signaling Gateway (SG) to a Media Gateway Controller (MGC) or IP-
resident Database as described in the Framework Architecture for Signal-
ling Transport [11]. The delivery mechanism should meet the following
criteria:
* Support for transfer of all SS7 MTP3-User Part messages (e.g.,
ISUP, SCCP, TUP, etc.)
* Support for the seamless operation of MTP3-User protocol peers
* Support for the management of SCTP transport associations and
traffic between an SG and one or more MGCs or IP-resident Databases
* Support for MGC or IP-resident Database failover and loadsharing
* Support for the asynchronous reporting of status changes to
management
In simplistic terms, the SG will terminate SS7 MTP2 and MTP3 protocols
and deliver ISUP, SCCP and/or any other MTP3-User protocol messages over
SCTP transport associations to MTP3-User peers in MGCs or IP-resident
Databases.
3.4 SUA
This document details the delivery of SCCP-user messages (MAP & CAP over
TCAP, RANAP, etc.) over IP. The architecture may be from from an SS7
Signaling Gateway (SG) to an IP-based signaling node (such as an IP-
resident Database) as described in the Framework Architecture for Sig-
naling Transport [RFC2719], or between two endpoints located completely
within an IP network. The delivery mechanism SHOULD meet the following
criteria:
* Support for transfer of SS7 SCCP-User Part messages (e.g., TCAP,
RANAP, etc.)
* Support for SCCP connectionless service.
* Support for SCCP connection oriented service.
* Support for the seamless operation of SCCP-User protocol peers
* Support for the management of SCTP transport associations
between an SG and one or more IP-based signaling nodes).
Coene, et al. Informational [Page 22]
Draft SCTP applicability statement March 2000
* Support for distributed IP-based signaling nodes.
* Support for the asynchronous reporting of status changes to
management
4 References and related work
[SCTP] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , ,
Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang, L.
and Paxson, V."Stream Control Transmission Protocol", <draft-
ietf-sigtran-sctp-13.txt>, RFCxxxx, July 2000. Work In Progress.
[Q1400] SG11, ITU-T Recommendation Q.1400, " architecture framework for
the development of signaling and OA&M protocols using OSI concepts
",1993
[HUITEM] Huitema, C., "Routing in the Internet", Prentice-Hall, 1995.
[RFC2373] Hinden, R. and Deering, S., "IP Version 6 Addressing Architec-
ture", RFC 2373, July 1998.
[RFC2460] Hinden, R. and Deering, S., "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC814] Clark, D.D., "Names, addresses, ports and routes", RFC 0814,
July 1982.
[RFC2401] Kent, S., and Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC1981] McCann, J., Deering, S., and Mogul, J., "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[RFC2208] Mankin, A. Ed., Baker, F., , Braden, B., Bradner, S., O`Dell,
M., Romanow, A., Weinrib, A. and Zhang, L., "Resource ReSerVation
Protocol (RSVP) -- Version 1 Applicability Statement Some Guide-
lines on Deployment" , RFC 2208, September 1997.
Coene, et al. Informational [Page 23]
Draft SCTP applicability statement March 2000
[RFC2597] Heinanen, J., Baker, F., Weiss, W. and Wroclawski, J.,
"Assured Forwarding PHB Group", RFC2597, June 1999
[RFC2598] Jacobson, V., Nichols, K. and Poduri, K., "An Expedited For-
warding PHB", RFC2598, June 1999
[RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L.,
Lin, H., Juhasz, I., Holdrege, M., Sharp, C., "Framework Architec-
ture for Signaling Transport", RFC2719, October 1999
[IANA] Internet Assigned Numbers Authority, http://www.iana.org/, April
2000
[RFCSALLY] Floyd, S. Ed., "Congestion Control Principles", <draft-
floyd-cong-02.txt> RFCxxxx, July 2000
[RFC1750] Eastlake, 3rd, D., Crocker, S., Schiller, J., "Randomness
Recommendations for Security", RFC1750, December 1994
[RFC1323] Jacobson, V., Braden, R., Borman, D., "TCP Extensions for High
Performance", RFC1323, May 1992
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms ", RFC2001, January 1997
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., Romanow, A., "TCP Selec-
tive Acknowledgement Options ", RFC2018, October 1996
[SAVAGE9] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
"TCP Congestion Control with a Misbehaving Receiver", ACM Computer
Communication Review, 29(5), October 1999.
http://www.cs.washington.edu/homes/savage/papers/CCR99.pdf
[JUNGM00] Jungmaier, A., Schopp, M. and Tuexen, M., "Performance Evalua-
tion of the Stream Control Transmission Protocol", , July 2000.
6 Acknowledgments
Coene, et al. Informational [Page 24]
Draft SCTP applicability statement March 2000
The authors wish to thank Renee Revis, Q. Xie, H.J. Schwarzbauer, J.P.
Martin-Flatin and many others for their invaluable comments.
7 Author's Address
Lode Coene
Siemens Atea
Atealaan 34
B-2200 Herentals
Belgium
Phone: +32-14-252081
EMail: lode.coene@siemens.atea.be
John Loughney
Nokia Research Center
Itamerenkatu 11-13
FIN-00180 Helsinki
Finland
Phone: +358-9-43761
EMail: john.loughney@nokia.com
Ian Rytina
Ericsson Australia
37/360 Elizabeth Street
Melbourne, Victoria 3000
Australia
Phone : -
EMail:ian.rytina@ericsson.com
Lyndon Ong
Nortel Networks
4401 Great America Parkway
Santa Clara, CA 95054
USA
Phone: -
EMail: long@nortelnetworks.com
Michel Tuexen
SIEMENS AG
Hofmannstr. 51
81359 Munich
Germany
Coene, et al. Informational [Page 25]
Draft SCTP applicability statement March 2000
Phone: +49 89 722 47210
EMail: Michael.Tuexen@icn.siemens.de
Randall R. Stewart
24 Burning Bush Trail.
Crystal Lake, IL 60012
USA
Tel: +1-815-479-8536
EMail: rstewart@flashcom.net
Expires: March 31, 2001
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished
to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet Society or
other Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not
Be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Coene, et al. Informational [Page 26]
Draft SCTP applicability statement March 2000
Coene, et al. Informational [Page 27]
|
Documentation