SHUTDOWN chunk SHOULD be silently discarded.
If an endpoint is in SHUTDOWN-SENT state and receives a SHUTDOWN
chunk from its peer, the endpoint shall respond immediately with a
SHUTDOWN ACK to its peer, and move into a SHUTDOWN-ACK-SENT state
restarting its T2-shutdown timer.
If an endpoint is in the SHUTDOWN-ACK-SENT state and receives a
SHUTDOWN ACK, it shall stop the T2-shutdown timer, send a SHUTDOWN
COMPLETE chunk to its peer, and remove all record of the association.
10. Interface with Upper Layer
The Upper Layer Protocols (ULP) shall request for services by passing
primitives to SCTP and shall receive notifications from SCTP for
various events.
The primitives and notifications described in this section should be
used as a guideline for implementing SCTP. The following functional
description of ULP interface primitives is shown for illustrative
purposes. Different SCTP implementations may have different ULP
interfaces. However, all SCTPs must provide a certain minimum set of
services to guarantee that all SCTP implementations can support the
same protocol hierarchy.
10.1 ULP-to-SCTP
The following sections functionally characterize a ULP/SCTP
interface. The notation used is similar to most procedure or
function calls in high level languages.
The ULP primitives described below specify the basic functions the
SCTP must perform to support inter-process communication. Individual
implementations must define their own exact format, and may provide
combinations or subsets of the basic functions in single calls.
A) Initialize
Format: INITIALIZE ([local port], [local eligible address list]) ->
local SCTP instance name
This primitive allows SCTP to initialize its internal data structures
and allocate necessary resources for setting up its operation
environment. Once SCTP is initialized, ULP can communicate directly
with other endpoints without re-invoking this primitive.
SCTP will return a local SCTP instance name to the ULP.
Mandatory attributes:
None.
Optional attributes:
The following types of attributes may be passed along with the
primitive:
o local port - SCTP port number, if ULP wants it to be specified;
o local eligible address list - An address list that the local SCTP
endpoint should bind. By default, if an address list is not
included, all IP addresses assigned to the host should be used by
the local endpoint.
IMPLEMENTATION NOTE: If this optional attribute is supported by an
implementation, it will be the responsibility of the implementation
to enforce that the IP source address field of any SCTP packets sent
out by this endpoint contains one of the IP addresses indicated in
the local eligible address list.
B) Associate
Format: ASSOCIATE(local SCTP instance name, destination transport addr,
outbound stream count)
-> association id [,destination transport addr list] [,outbound stream
count]
This primitive allows the upper layer to initiate an association to a
specific peer endpoint.
The peer endpoint shall be specified by one of the transport
addresses which defines the endpoint (see Section 1.4). If the local
SCTP instance has not been initialized, the ASSOCIATE is considered
an error.
An association id, which is a local handle to the SCTP association,
will be returned on successful establishment of the association. If
SCTP is not able to open an SCTP association with the peer endpoint,
an error is returned.
Other association parameters may be returned, including the complete
destination transport addresses of the peer as well as the outbound
stream count of the local endpoint. One of the transport address
from the returned destination addresses will be selected by the local
endpoint as default primary path for sending SCTP packets to this
peer. The returned "destination transport addr list" can be used by
the ULP to change the default primary path or to force sending a
packet to a specific transport address.
IMPLEMENTATION NOTE: If ASSOCIATE primitive is implemented as a
blocking function call, the ASSOCIATE primitive can return
association parameters in addition to the association id upon
successful establishment. If ASSOCIATE primitive is implemented as a
non-blocking call, only the association id shall be returned and
association parameters shall be passed using the COMMUNICATION UP
notification.
Mandatory attributes:
o local SCTP instance name - obtained from the INITIALIZE operation.
o destination transport addr - specified as one of the transport
addresses of the peer endpoint with which the association is to be
established.
o outbound stream count - the number of outbound streams the ULP
would like to open towards this peer endpoint.
Optional attributes:
None.
C) Shutdown
Format: SHUTDOWN(association id)
-> result
Gracefully closes an association. Any locally queued user data will
be delivered to the peer. The association will be terminated only
after the peer acknowledges all the SCTP packets sent. A success
code will be returned on successful termination of the association.
If attempting to terminate the association results in a failure, an
error code shall be returned.
Mandatory attributes:
o association id - local handle to the SCTP association
Optional attributes:
None.
D) Abort
Format: ABORT(association id [, cause code])
-> result
Ungracefully closes an association. Any locally queued user data
will be discarded and an ABORT chunk is sent to the peer. A success
code will be returned on successful abortion of the association. If
attempting to abort the association results in a failure, an error
code shall be returned.
Mandatory attributes:
o association id - local handle to the SCTP association
Optional attributes:
o cause code - reason of the abort to be passed to the peer.
None.
E) Send
Format: SEND(association id, buffer address, byte count [,context]
[,stream id] [,life time] [,destination transport address]
[,unorder flag] [,no-bundle flag] [,payload protocol-id] )
-> result
This is the main method to send user data via SCTP.
Mandatory attributes:
o association id - local handle to the SCTP association
o buffer address - the location where the user message to be
transmitted is stored;
o byte count - The size of the user data in number of bytes;
Optional attributes:
o context - an optional 32 bit integer that will be carried in the
sending failure notification to the ULP if the transportation of
this User Message fails.
o stream id - to indicate which stream to send the data on. If not
specified, stream 0 will be used.
o life time - specifies the life time of the user data. The user
data will not be sent by SCTP after the life time expires. This
parameter can be used to avoid efforts to transmit stale user
messages. SCTP notifies the ULP if the data cannot be initiated
to transport (i.e. sent to the destination via SCTP's send
primitive) within the life time variable. However, the user data
will be transmitted if SCTP has attempted to transmit a chunk
before the life time expired.
IMPLEMENTATION NOTE: In order to better support the data lifetime
option, the transmitter may hold back the assigning of the TSN number
to an outbound DATA chunk to the last moment. And, for
implementation simplicity, once a TSN number has been assigned the
sender should consider the send of this DATA chunk as committed,
overriding any lifetime option attached to the DATA chunk.
o destination transport address - specified as one of the
destination transport addresses of the peer endpoint to which this
packet should be sent. Whenever possible, SCTP should use this
destination transport address for sending the packets, instead of
the current primary path.
o unorder flag - this flag, if present, indicates that the user
would like the data delivered in an unordered fashion to the peer
(i.e., the U flag is set to 1 on all DATA chunks carrying this
message).
o no-bundle flag - instructs SCTP not to bundle this user data with
other outbound DATA chunks. SCTP MAY still bundle even when this
flag is present, when faced with network congestion.
o payload protocol-id - A 32 bit unsigned integer that is to be
passed to the peer indicating the type of payload protocol data
being transmitted. This value is passed as opaque data by SCTP.
F) Set Primary
Format: SETPRIMARY(association id, destination transport address,
[source transport address] )
-> result
Instructs the local SCTP to use the specified destination transport
address as primary path for sending packets.
The result of attempting this operation shall be returned. If the
specified destination transport address is not present in the
"destination transport address list" returned earlier in an associate
command or communication up notification, an error shall be returned.
Mandatory attributes:
o association id - local handle to the SCTP association
o destination transport address - specified as one of the transport
addresses of the peer endpoint, which should be used as primary
address for sending packets. This overrides the current primary
address information maintained by the local SCTP endpoint.
Optional attributes:
o source transport address - optionally, some implementations may
allow you to set the default source address placed in all outgoing
IP datagrams.
G) Receive
Format: RECEIVE(association id, buffer address, buffer size
[,stream id])
-> byte count [,transport address] [,stream id] [,stream sequence
number] [,partial flag] [,delivery number] [,payload protocol-id]
This primitive shall read the first user message in the SCTP in-queue
into the buffer specified by ULP, if there is one available. The
size of the message read, in bytes, will be returned. It may,
depending on the specific implementation, also return other
information such as the sender's address, the stream id on which it
is received, whether there are more messages available for retrieval,
etc. For ordered messages, their stream sequence number may also be
returned.
Depending upon the implementation, if this primitive is invoked when
no message is available the implementation should return an
indication of this condition or should block the invoking process
until data does become available.
Mandatory attributes:
o association id - local handle to the SCTP association
o buffer address - the memory location indicated by the ULP to store
the received message.
o buffer size - the maximum size of data to be received, in bytes.
Optional attributes:
o stream id - to indicate which stream to receive the data on.
o stream sequence number - the stream sequence number assigned by
the sending SCTP peer.
o partial flag - if this returned flag is set to 1, then this
Receive contains a partial delivery of the whole message. When
this flag is set, the stream id and stream sequence number MUST
accompany this receive. When this flag is set to 0, it indicates
that no more deliveries will be received for this stream sequence
number.
o payload protocol-id - A 32 bit unsigned integer that is received
from the peer indicating the type of payload protocol of the
received data. This value is passed as opaque data by SCTP.
H) Status
Format: STATUS(association id)
-> status data
This primitive should return a data block containing the following
information:
association connection state,
destination transport address list,
destination transport address reachability states,
current receiver window size,
current congestion window sizes,
number of unacknowledged DATA chunks,
number of DATA chunks pending receipt,
primary path,
most recent SRTT on primary path,
RTO on primary path,
SRTT and RTO on other destination addresses, etc.
Mandatory attributes:
o association id - local handle to the SCTP association
Optional attributes:
None.
I) Change Heartbeat
Format: CHANGEHEARTBEAT(association id, destination transport address,
new state [,interval])
-> result
Instructs the local endpoint to enable or disable heartbeat on the
specified destination transport address.
The result of attempting this operation shall be returned.
Note: Even when enabled, heartbeat will not take place if the
destination transport address is not idle.
Mandatory attributes:
o association id - local handle to the SCTP association
o destination transport address - specified as one of the transport
addresses of the peer endpoint.
o new state - the new state of heartbeat for this destination
transport address (either enabled or disabled).
Optional attributes:
o interval - if present, indicates the frequency of the heartbeat if
this is to enable heartbeat on a destination transport address.
This value is added to the RTO of the destination transport
address. This value, if present, effects all destinations.
J) Request HeartBeat
Format: REQUESTHEARTBEAT(association id, destination transport
address)
-> result
Instructs the local endpoint to perform a HeartBeat on the specified
destination transport address of the given association. The returned
result should indicate whether the transmission of the HEARTBEAT
chunk to the destination address is successful.
Mandatory attributes:
o association id - local handle to the SCTP association
o destination transport address - the transport address of the
association on which a heartbeat should be issued.
K) Get SRTT Report
Format: GETSRTTREPORT(association id, destination transport address)
-> srtt result
Instructs the local SCTP to report the current SRTT measurement on
the specified destination transport address of the given association.
The returned result can be an integer containing the most recent SRTT
in milliseconds.
Mandatory attributes:
o association id - local handle to the SCTP association
o destination transport address - the transport address of the
association on which the SRTT measurement is to be reported.
L) Set Failure Threshold
Format: SETFAILURETHRESHOLD(association id, destination transport
address, failure threshold)
-> result
This primitive allows the local SCTP to customize the reachability
failure detection threshold 'Path.Max.Retrans' for the specified
destination address.
Mandatory attributes:
o association id - local handle to the SCTP association
o destination transport address - the transport address of the
association on which the failure detection threshold is to be set.
o failure threshold - the new value of 'Path.Max.Retrans' for the
destination address.
M) Set Protocol Parameters
Format: SETPROTOCOLPARAMETERS(association id, [,destination transport
address,] protocol parameter list)
-> result
This primitive allows the local SCTP to customize the protocol
parameters.
Mandatory attributes:
o association id - local handle to the SCTP association
o protocol parameter list - The specific names and values of the
protocol parameters (e.g., Association.Max.Retrans [see Section
14]) that the SCTP user wishes to customize.
Optional attributes:
o destination transport address - some of the protocol parameters
may be set on a per destination transport address basis.
N) Receive unsent message
Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer size
[,stream id] [, stream sequence number] [,partial flag]
[,payload protocol-id])
o data retrieval id - The identification passed to the ULP in the
failure notification.
o buffer address - the memory location indicated by the ULP to store
the received message.
o buffer size - the maximum size of data to be received, in bytes.
Optional attributes:
o stream id - this is a return value that is set to indicate
which stream the data was sent to.
o stream sequence number - this value is returned indicating
the stream sequence number that was associated with the message.
o partial flag - if this returned flag is set to 1, then this
message is a partial delivery of the whole message. When
this flag is set, the stream id and stream sequence number MUST
accompany this receive. When this flag is set to 0, it indicates
that no more deliveries will be received for this stream sequence
number.
o payload protocol-id - The 32 bit unsigned integer that was sent to
be sent to the peer indicating the type of payload protocol of the
received data.
O) Receive unacknowledged message
Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer size,
[,stream id] [, stream sequence number] [,partial flag]
[,payload protocol-id])
o data retrieval id - The identification passed to the ULP in the
failure notification.
o buffer address - the memory location indicated by the ULP to store
the received message.
o buffer size - the maximum size of data to be received, in bytes.
Optional attributes:
o stream id - this is a return value that is set to indicate which
stream the data was sent to.
o stream sequence number - this value is returned indicating the
stream sequence number that was associated with the message.
o partial flag - if this returned flag is set to 1, then this
message is a partial delivery of the whole message. When this
flag is set, the stream id and stream sequence number MUST
accompany this receive. When this flag is set to 0, it indicates
that no more deliveries will be received for this stream sequence
number.
o payload protocol-id - The 32 bit unsigned integer that was sent to
be sent to the peer indicating the type of payload protocol of the
received data.
P) Destroy SCTP instance
Format: DESTROY(local SCTP instance name)
o local SCTP instance name - this is the value that was passed to
the application in the initialize primitive and it indicates which
SCTP instance to be destroyed.
10.2 SCTP-to-ULP
It is assumed that the operating system or application environment
provides a means for the SCTP to asynchronously signal the ULP
process. When SCTP does signal an ULP process, certain information
is passed to the ULP.
IMPLEMENTATION NOTE: In some cases this may be done through a
separate socket or error channel.
A) DATA ARRIVE notification
SCTP shall invoke this notification on the ULP when a user message is
successfully received and ready for retrieval.
The following may be optionally be passed with the notification:
o association id - local handle to the SCTP association
o stream id - to indicate which stream the data is received on.
B) SEND FAILURE notification
If a message can not be delivered SCTP shall invoke this notification
on the ULP.
The following may be optionally be passed with the notification:
o association id - local handle to the SCTP association
o data retrieval id - an identification used to retrieve unsent and
unacknowledged data.
o cause code - indicating the reason of the failure, e.g., size too
large, message life-time expiration, etc.
o context - optional information associated with this message (see D
in Section 10.1).
C) NETWORK STATUS CHANGE notification
When a destination transport address is marked inactive (e.g., when
SCTP detects a failure), or marked active (e.g., when SCTP detects a
recovery), SCTP shall invoke this notification on the ULP.
The following shall be passed with the notification:
o association id - local handle to the SCTP association
o destination transport address - This indicates the destination
transport address of the peer endpoint affected by the change;
o new-status - This indicates the new status.
D) COMMUNICATION UP notification
This notification is used when SCTP becomes ready to send or receive
user messages, or when a lost communication to an endpoint is
restored.
IMPLEMENTATION NOTE: If ASSOCIATE primitive is implemented as a
blocking function call, the association parameters are returned as a
result of the ASSOCIATE primitive itself. In that case,
COMMUNICATION UP notification is optional at the association
initiator's side.
The following shall be passed with the notification:
o association id - local handle to the SCTP association
o status - This indicates what type of event has occurred
o destination transport address list - the complete set of transport
addresses of the peer
o outbound stream count - the maximum number of streams allowed to
be used in this association by the ULP
o inbound stream count - the number of streams the peer endpoint has
requested with this association (this may not be the same number
as 'outbound stream count').
E) COMMUNICATION LOST notification
When SCTP loses communication to an endpoint completely (e.g., via
Heartbeats) or detects that the endpoint has performed an abort
operation, it shall invoke this notification on the ULP.
The following shall be passed with the notification:
o association id - local handle to the SCTP association
o status - This indicates what type of event has occurred; The status
may indicate a failure OR a normal termination event
occurred in response to a shutdown or abort request.
The following may be passed with the notification:
o data retrieval id - an identification used to retrieve unsent and
unacknowledged data.
o last-acked - the TSN last acked by that peer endpoint;
o last-sent - the TSN last sent to that peer endpoint;
F) COMMUNICATION ERROR notification
When SCTP receives an ERROR chunk from its peer and decides to notify
its ULP, it can invoke this notification on the ULP.
The following can be passed with the notification:
o association id - local handle to the SCTP association
o error info - this indicates the type of error and optionally some
additional information received through the ERROR chunk.
G) RESTART notification
When SCTP detects that the peer has restarted, it may send this
notification to its ULP.
The following can be passed with the notification:
o association id - local handle to the SCTP association
H) SHUTDOWN COMPLETE notification
When SCTP completes the shutdown procedures (section 9.2) this
notification is passed to the upper layer.
The following can be passed with the notification:
o association id - local handle to the SCTP association
11. Security Considerations
11.1 Security Objectives
As a common transport protocol designed to reliably carry time-
sensitive user messages, such as billing or signaling messages for
telephony services, between two networked endpoints, SCTP has the
following security objectives.
- availability of reliable and timely data transport services
- integrity of the user-to-user information carried by SCTP
11.2 SCTP Responses To Potential Threats
SCTP may potentially be used in a wide variety of risk situations.
It is important for operator(s) of systems running SCTP to analyze
their particular situations and decide on the appropriate counter-
measures.
Operators of systems running SCTP should consult [RFC2196] for
guidance in securing their site.
11.2.1 Countering Insider Attacks
The principles of [RFC2196] should be applied to minimize the risk of
theft of information or sabotage by insiders. Such procedures
include publication of security policies, control of access at the
physical, software, and network levels, and separation of services.
11.2.2 Protecting against Data Corruption in the Network
Where the risk of undetected errors in datagrams delivered by the
lower layer transport services is considered to be too great,
additional integrity protection is required. If this additional
protection were provided in the application-layer, the SCTP header
would remain vulnerable to deliberate integrity attacks. While the
existing SCTP mechanisms for detection of packet replays are
considered sufficient for normal operation, stronger protections are
needed to protect SCTP when the operating environment contains
significant risk of deliberate attacks from a sophisticated
adversary.
In order to promote software code-reuse, to avoid re-inventing the
wheel, and to avoid gratuitous complexity to SCTP, the IP
Authentication Header [RFC2402] SHOULD be used when the threat
environment requires stronger integrity protections, but does not
require confidentiality.
A widely implemented BSD Sockets API extension exists for
applications to request IP security services, such as AH or ESP from
an operating system kernel. Applications can use such an API to
request AH whenever AH use is appropriate.
11.2.3 Protecting Confidentiality
In most cases, the risk of breach of confidentiality applies to the
signaling data payload, not to the SCTP or lower-layer protocol
overheads. If that is true, encryption of the SCTP user data only
might be considered. As with the supplementary checksum service,
user data encryption MAY be performed by the SCTP user application.
Alternately, the user application MAY use an implementation-specific
API to request that the IP Encapsulating Security Payload (ESP)
[RFC2406] be used to provide confidentiality and integrity.
Particularly for mobile users, the requirement for confidentiality
might include the masking of IP addresses and ports. In this case
ESP SHOULD be used instead of application-level confidentiality. If
ESP is used to protect confidentiality of SCTP traffic, an ESP
cryptographic transform that includes cryptographic integrity
protection MUST be used, because if there is a confidentiality threat
there will also be a strong integrity threat.
Whenever ESP is in use, application-level encryption is not generally
required.
Regardless of where confidentiality is provided, the ISAKMP [RFC2408]
and the Internet Key Exchange (IKE) [RFC2409] SHOULD be used for key
management.
Operators should consult [RFC2401] for more information on the
security services available at and immediately above the Internet
Protocol layer.
11.2.4 Protecting against Blind Denial of Service Attacks
A blind attack is one where the attacker is unable to intercept or
otherwise see the content of data flows passing to and from the
target SCTP node. Blind denial of service attacks may take the form
of flooding, masquerade, or improper monopolization of services.
11.2.4.1 Flooding
The objective of flooding is to cause loss of service and incorrect
behavior at target systems through resource exhaustion, interference
with legitimate transactions, and exploitation of buffer-related
software bugs. Flooding may be directed either at the SCTP node or
at resources in the intervening IP Access Links or the Internet.
Where the latter entities are the target, flooding will manifest
itself as loss of network services, including potentially the breach
of any firewalls in place.
In general, protection against flooding begins at the equipment
design level, where it includes measures such as:
- avoiding commitment of limited resources before determining that
the request for service is legitimate
- giving priority to completion of processing in progress over the
acceptance of new work
- identification and removal of duplicate or stale queued requests
for service.
- not responding to unexpected packets sent to non-unicast
addresses.
Network equipment should be capable of generating an alarm and log if
a suspicious increase in traffic occurs. The log should provide
information such as the identity of the incoming link and source
address(es) used which will help the network or SCTP system operator
to take protective measures. Procedures should be in place for the
operator to act on such alarms if a clear pattern of abuse emerges.
The design of SCTP is resistant to flooding attacks, particularly in
its use of a four-way start-up handshake, its use of a cookie to
defer commitment of resources at the responding SCTP node until the
handshake is completed, and its use of a Verification Tag to prevent
insertion of extraneous packets into the flow of an established
association.
The IP Authentication Header and Encapsulating Security Payload might
be useful in reducing the risk of certain kinds of denial of service
attacks."
The use of the Host Name feature in the INIT chunk could be used to
flood a target DNS server. A large backlog of DNS queries, resolving
the Host Name received in the INIT chunk to IP addresses, could be
accomplished by sending INIT's to multiple hosts in a given domain.
In addition, an attacker could use the Host Name feature in an
indirect attack on a third party by sending large numbers of INITs to
random hosts containing the host name of the target. In addition to
the strain on DNS resources, this could also result in large numbers
of INIT ACKs being sent to the target. One method to protect against
this type of attack is to verify that the IP addresses received from
DNS include the source IP address of the original INIT. If the list
of IP addresses received from DNS does not include the source IP
address of the INIT, the endpoint MAY silently discard the INIT.
This last option will not protect against the attack against the DNS.
11.2.4.2 Blind Masquerade
Masquerade can be used to deny service in several ways:
- by tying up resources at the target SCTP node to which the
impersonated node has limited access. For example, the target
node may by policy permit a maximum of one SCTP association with
the impersonated SCTP node. The masquerading attacker may attempt
to establish an association purporting to come from the
impersonated node so that the latter cannot do so when it requires
it.
- by deliberately allowing the impersonation to be detected, thereby
provoking counter-measures which cause the impersonated node to be
locked out of the target SCTP node.
- by interfering with an established association by inserting
extraneous content such as a SHUTDOWN request.
SCTP reduces the risk of blind masquerade attacks through IP spoofing
by use of the four-way startup handshake. Man-in-the-middle
masquerade attacks are discussed in Section 11.3 below. Because the
initial exchange is memoryless, no lockout mechanism is triggered by
blind masquerade attacks. In addition, the INIT ACK containing the
State Cookie is transmitted back to the IP address from which it
received the INIT. Thus the attacker would not receive the INIT ACK
containing the State Cookie. SCTP protects against insertion of
extraneous packets into the flow of an established association by use
of the Verification Tag.
Logging of received INIT requests and abnormalities such as
unexpected INIT ACKs might be considered as a way to detect patterns
of hostile activity. However, the potential usefulness of such
logging must be weighed against the increased SCTP startup processing
it implies, rendering the SCTP node more vulnerable to flooding
attacks. Logging is pointless without the establishment of operating
procedures to review and analyze the logs on a routine basis.
11.2.4.3 Improper Monopolization of Services
Attacks under this heading are performed openly and legitimately by
the attacker. They are directed against fellow users of the target
SCTP node or of the shared resources between the attacker and the
target node. Possible attacks include the opening of a large number
of associations between the attacker's node and the target, or
transfer of large volumes of information within a legitimately-
established association.
Policy limits should be placed on the number of associations per
adjoining SCTP node. SCTP user applications should be capable of
detecting large volumes of illegitimate or "no-op" messages within a
given association and either logging or terminating the association
as a result, based on local policy.
11.3 Protection against Fraud and Repudiation
The objective of fraud is to obtain services without authorization
and specifically without paying for them. In order to achieve this
objective, the attacker must induce the SCTP user application at the
target SCTP node to provide the desired service while accepting
invalid billing data or failing to collect it. Repudiation is a
related problem, since it may occur as a deliberate act of fraud or
simply because the repudiating party kept inadequate records of
service received.
Potential fraudulent attacks include interception and misuse of
authorizing information such as credit card numbers, blind masquerade
and replay, and man-in-the middle attacks which modify the packets
passing through a target SCTP association in real time.
The interception attack is countered by the confidentiality measures
discussed in Section 11.2.3 above.
Section 11.2.4.2 describes how SCTP is resistant to blind masquerade
attacks, as a result of the four-way startup handshake and the
Verification Tag. The Verification Tag and TSN together are
protections against blind replay attacks, where the replay is into an
existing association.
However, SCTP does not protect against man-in-the-middle attacks
where the attacker is able to intercept and alter the packets sent
and received in an association. For example, the INIT ACK will have
sufficient information sent on the wire for an adversary in the
middle to hijack an existing SCTP association. Where a significant
possibility of such attacks is seen to exist, or where possible
repudiation is an issue, the use of the IPSEC AH service is
recommended to ensure both the integrity and the authenticity of the
SCTP packets passed.
SCTP also provides no protection against attacks originating at or
beyond the SCTP node and taking place within the context of an
existing association. Prevention of such attacks should be covered
by appropriate security policies at the host site, as discussed in
Section 11.2.1.
12. Recommended Transmission Control Block (TCB) Parameters
This section details a recommended set of parameters that should be
contained within the TCB for an implementation. This section is for
illustrative purposes and should not be deemed as requirements on an
implementation or as an exhaustive list of all parameters inside an
SCTP TCB. Each implementation may need its own additional parameters
for optimization.
12.1 Parameters necessary for the SCTP instance
Associations: A list of current associations and mappings to the data
consumers for each association. This may be in the
form of a hash table or other implementation dependent
structure. The data consumers may be process
identification information such as file descriptors,
named pipe pointer, or table pointers dependent on how
SCTP is implemented.
Secret Key: A secret key used by this endpoint to compute the MAC.
This SHOULD be a cryptographic quality random number
with a sufficient length. Discussion in [RFC1750] can
be helpful in selection of the key.
Address List: The list of IP addresses that this instance has bound.
This information is passed to one's peer(s) in INIT and
INIT ACK chunks.
SCTP Port: The local SCTP port number the endpoint is bound to.
12.2 Parameters necessary per association (i.e. the TCB)
Peer : Tag value to be sent in every packet and is received
Verification: in the INIT or INIT ACK chunk.
Tag :
My : Tag expected in every inbound packet and sent in the
Verification: INIT or INIT ACK chunk.
Tag :
State : A state variable indicating what state the association
: is in, i.e. COOKIE-WAIT, COOKIE-ECHOED, ESTABLISHED,
: SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED,
: SHUTDOWN-ACK-SENT.
Note: No "CLOSED" state is illustrated since if a
association is "CLOSED" its TCB SHOULD be removed.
Peer : A list of SCTP transport addresses that the peer is
Transport : bound to. This information is derived from the INIT or
Address : INIT ACK and is used to associate an inbound packet
List : with a given association. Normally this information is
: hashed or keyed for quick lookup and access of the TCB.
Primary : This is the current primary destination transport
Path : address of the peer endpoint. It may also specify a
: source transport address on this endpoint.
Overall : The overall association error count.
Error Count :
Overall : The threshold for this association that if the Overall
Error : Error Count reaches will cause this association to be
Threshold : torn down.
Peer Rwnd : Current calculated value of the peer's rwnd.
Next TSN : The next TSN number to be assigned to a new DATA chunk.
: This is sent in the INIT or INIT ACK chunk to the peer
: and incremented each time a DATA chunk is assigned a
: TSN (normally just prior to transmit or during
: fragmentation).
Last Rcvd : This is the last TSN received in sequence. This value
TSN : is set initially by taking the peer's Initial TSN,
: received in the INIT or INIT ACK chunk, and
: subtracting one from it.
Mapping : An array of bits or bytes indicating which out of
Array : order TSN's have been received (relative to the
: Last Rcvd TSN). If no gaps exist, i.e. no out of order
: packets have been received, this array will be set to
: all zero. This structure may be in the form of a
: circular buffer or bit array.
Ack State : This flag indicates if the next received packet
: is to be responded to with a SACK. This is initialized
: to 0. When a packet is received it is incremented.
: If this value reaches 2 or more, a SACK is sent and the
: value is reset to 0. Note: This is used only when no
: DATA chunks are received out of order. When DATA chunks
: are out of order, SACK's are not delayed (see Section
: 6).
Inbound : An array of structures to track the inbound streams.
Streams : Normally including the next sequence number expected
: and possibly the stream number.
Outbound : An array of structures to track the outbound streams.
Streams : Normally including the next sequence number to
: be sent on the stream.
Reasm Queue : A re-assembly queue.
Local : The list of local IP addresses bound in to this
Transport : association.
Address :
List :
Association : The smallest PMTU discovered for all of the
PMTU : peer's transport addresses.
12.3 Per Transport Address Data
For each destination transport address in the peer's address list
derived from the INIT or INIT ACK chunk, a number of data elements
needs to be maintained including:
Error count : The current error count for this destination.
Error : Current error threshold for this destination i.e.
Threshold : what value marks the destination down if Error count
: reaches this value.
cwnd : The current congestion window.
ssthresh : The current ssthresh value.
RTO : The current retransmission timeout value.
SRTT : The current smoothed round trip time.
RTTVAR : The current RTT variation.
partial : The tracking method for increase of cwnd when in
bytes acked : congestion avoidance mode (see Section 6.2.2)
state : The current state of this destination, i.e. DOWN, UP,
: ALLOW-HB, NO-HEARTBEAT, etc.
PMTU : The current known path MTU.
Per : A timer used by each destination.
Destination :
Timer :
RTO-Pending : A flag used to track if one of the DATA chunks sent to
this address is currently being used to compute a
RTT. If this flag is 0, the next DATA chunk sent to this
destination should be used to compute a RTT and this
flag should be set. Every time the RTT calculation
completes (i.e. the DATA chunk is SACK'd) clear this
flag.
last-time : The time this destination was last sent to. This can be
used : used to determine if a HEARTBEAT is needed.
12.4 General Parameters Needed
Out Queue : A queue of outbound DATA chunks.
In Queue : A queue of inbound DATA chunks.
13. IANA Considerations
This protocol will require port reservation like TCP for the use of
"well known" servers within the Internet. All current TCP ports
shall be automatically reserved in the SCTP port address space. New
requests should follow IANA's current mechanisms for TCP.
This protocol may also be extended through IANA in three ways:
-- through definition of additional chunk types,
-- through definition of additional parameter types, or
-- through definition of additional cause codes within
ERROR chunks
In the case where a particular ULP using SCTP desires to have its own
ports, the ULP should be responsible for registering with IANA for
getting its ports assigned.
13.1 IETF-defined Chunk Extension
The definition and use of new chunk types is an integral part of
SCTP. Thus, new chunk types are assigned by IANA through an IETF
Consensus action as defined in [RFC2434].
The documentation for a new chunk code type must include the
following information:
a) A long and short name for the new chunk type;
b) A detailed description of the structure of the chunk, which MUST
conform to the basic structure defined in Section 3.2;
c) A detailed definition and description of intended use of each
field within the chunk, including the chunk flags if any;
d) A detailed procedural description of the use of the new chunk type
within the operation of the protocol.
The last chunk type (255) is reserved for future extension if
necessary.
13.2 IETF-defined Chunk Parameter Extension
The assignment of new chunk parameter type codes is done through an
IETF Consensus action as defined in [RFC2434]. Documentation of the
chunk parameter MUST contain the following information:
a) Name of the parameter type.
b) Detailed description of the structure of the parameter field.
This structure MUST conform to the general type-length-value
format described in Section 3.2.1.
c) Detailed definition of each component of the parameter value.
d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances multiple
instances of this parameter type may be found within the same
chunk.
13.3 IETF-defined Additional Error Causes
Additional cause codes may be allocated in the range 11 to 65535
through a Specification Required action as defined in [RFC2434].
Provided documentation must include the following information:
a) Name of the error condition.
b) Detailed description of the conditions under which an SCTP
endpoint should issue an ERROR (or ABORT) with this cause code.
c) Expected action by the SCTP endpoint which receives an ERROR (or
ABORT) chunk containing this cause code.
d) Detailed description of the structure and content of data fields
which accompany this cause code.
The initial word (32 bits) of a cause code parameter MUST conform to
the format shown in Section 3.3.10, i.e.:
-- first two bytes contain the cause code value
-- last two bytes contain length of the Cause Parameter.
13.4 Payload Protocol Identifiers
Except for value 0 which is reserved by SCTP to indicate an
unspecified payload protocol identifier in a DATA chunk, SCTP will
not be responsible for standardizing or verifying any payload
protocol identifiers; SCTP simply receives the identifier from the
upper layer and carries it with the corresponding payload data.
The upper layer, i.e., the SCTP user, SHOULD standardize any specific
protocol identifier with IANA if it is so desired. The use of any
specific payload protocol identifier is out of the scope of SCTP.
14. Suggested SCTP Protocol Parameter Values
The following protocol parameters are RECOMMENDED:
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
IMPLEMENTATION NOTE: The SCTP implementation may allow ULP to
customize some of these protocol parameters (see Section 10).
Note: RTO.Min SHOULD be set as recommended above.
15. Acknowledgements
The authors wish to thank Mark Allman, R.J. Atkinson, Richard Band,
Scott Bradner, Steve Bellovin, Peter Butler, Ram Dantu, R.
Ezhirpavai, Mike Fisk, Sally Floyd, Atsushi Fukumoto, Matt Holdrege,
Henry Houh, Christian Huitema, Gary Lehecka, Jonathan Lee, David
Lehmann, John Loughney, Daniel Luan, Barry Nagelberg, Thomas Narten,
Erik Nordmark, Lyndon Ong, Shyamal Prasad, Kelvin Porter, Heinz
Prantner, Jarno Rajahalme, Raymond E. Reeves, Renee Revis, Ivan Arias
Rodriguez, A. Sankar, Greg Sidebottom, Brian Wyld, La Monte Yarroll,
and many others for their invaluable comments.
16. Authors' Addresses
Randall R. Stewart
24 Burning Bush Trail.
Crystal Lake, IL 60012
USA
Phone: +1-815-477-2127
EMail: rrs@cisco.com
Qiaobing Xie
Motorola, Inc.
1501 W. Shure Drive, #2309
Arlington Heights, IL 60004
USA
Phone: +1-847-632-3028
EMail: qxie1@email.mot.com
Ken Morneault
Cisco Systems Inc.
13615 Dulles Technology Drive
Herndon, VA. 20171
USA
Phone: +1-703-484-3323
EMail: kmorneau@cisco.com
Chip Sharp
Cisco Systems Inc.
7025 Kit Creek Road
Research Triangle Park, NC 27709
USA
Phone: +1-919-392-3121
EMail: chsharp@cisco.com
Hanns Juergen Schwarzbauer
SIEMENS AG
Hofmannstr. 51
81359 Munich
Germany
Phone: +49-89-722-24236
EMail: HannsJuergen.Schwarzbauer@icn.siemens.de
Tom Taylor
Nortel Networks
1852 Lorraine Ave.
Ottawa, Ontario
Canada K1H 6Z8
Phone: +1-613-736-0961
EMail: taylor@nortelnetworks.com
Ian Rytina
Ericsson Australia
37/360 Elizabeth Street
Melbourne, Victoria 3000
Australia
Phone: +61-3-9301-6164
EMail: ian.rytina@ericsson.com
Malleswar Kalla
Telcordia Technologies
3 Corporate Place
PYA-2J-341
Piscataway, NJ 08854
USA
Phone: +1-732-699-3728
EMail: mkalla@telcordia.com
Lixia Zhang
UCLA Computer Science Department
4531G Boelter Hall
Los Angeles, CA 90095-1596
USA
Phone: +1-310-825-2695
EMail: lixia@cs.ucla.edu