9. Termination of Association An endpoint should terminate its association when it exits from service. An association can be terminated by either abort or shutdown. An abort of an association is abortive by definition in that any data pending on either end of the association is discarded and not delivered to the peer. A shutdown of an association is considered a graceful close where all data in queue by either endpoint is delivered to the respective peers. However, in the case of a shutdown, SCTP does not support a half-open state (like TCP) wherein one side may continue sending data while the other end is closed. When either endpoint performs a shutdown, the association on
each peer will stop accepting new data from its user and only deliver data in queue at the time of sending or receiving the SHUTDOWN chunk. 9.1. Abort of an Association When an endpoint decides to abort an existing association, it MUST send an ABORT chunk to its peer endpoint. The sender MUST fill in the peer's Verification Tag in the outbound packet and MUST NOT bundle any DATA chunk with the ABORT. If the association is aborted on request of the upper layer, a User-Initiated Abort error cause (see Section 18.104.22.168) SHOULD be present in the ABORT chunk. An endpoint MUST NOT respond to any received packet that contains an ABORT chunk (also see Section 8.4). An endpoint receiving an ABORT MUST apply the special Verification Tag check rules described in Section 8.5.1. After checking the Verification Tag, the receiving endpoint MUST remove the association from its record and SHOULD report the termination to its upper layer. If a User-Initiated Abort error cause is present in the ABORT chunk, the Upper Layer Abort Reason SHOULD be made available to the upper layer. 9.2. Shutdown of an Association Using the SHUTDOWN primitive (see Section 10.1), the upper layer of an endpoint in an association can gracefully close the association. This will allow all outstanding DATA chunks from the peer of the shutdown initiator to be delivered before the association terminates. Upon receipt of the SHUTDOWN primitive from its upper layer, the endpoint enters the SHUTDOWN-PENDING state and remains there until all outstanding data has been acknowledged by its peer. The endpoint accepts no new data from its upper layer, but retransmits data to the far end if necessary to fill gaps. Once all its outstanding data has been acknowledged, the endpoint shall send a SHUTDOWN chunk to its peer including in the Cumulative TSN Ack field the last sequential TSN it has received from the peer. It shall then start the T2-shutdown timer and enter the SHUTDOWN-SENT state. If the timer expires, the endpoint must resend the SHUTDOWN with the updated last sequential TSN received from its peer. The rules in Section 6.3 MUST be followed to determine the proper timer value for T2-shutdown. To indicate any gaps in TSN, the endpoint may also bundle a SACK with the SHUTDOWN chunk in the same SCTP packet.
An endpoint should limit the number of retransmissions of the SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. If this threshold is exceeded, the endpoint should destroy the TCB and MUST report the peer endpoint unreachable to the upper layer (and thus the association enters the CLOSED state). The reception of any packet from its peer (i.e., as the peer sends all of its queued DATA chunks) should clear the endpoint's retransmission count and restart the T2-shutdown timer, giving its peer ample opportunity to transmit all of its queued DATA chunks that have not yet been sent. Upon reception of the SHUTDOWN, the peer endpoint shall - enter the SHUTDOWN-RECEIVED state, - stop accepting new data from its SCTP user, and - verify, by checking the Cumulative TSN Ack field of the chunk, that all its outstanding DATA chunks have been received by the SHUTDOWN sender. Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT send a SHUTDOWN in response to a ULP request, and should discard subsequent SHUTDOWN chunks. If there are still outstanding DATA chunks left, the SHUTDOWN receiver MUST continue to follow normal data transmission procedures defined in Section 6, until all outstanding DATA chunks are acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data from its SCTP user. While in the SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately respond to each received packet containing one or more DATA chunks with a SHUTDOWN chunk and restart the T2-shutdown timer. If a SHUTDOWN chunk by itself cannot acknowledge all of the received DATA chunks (i.e., there are TSNs that can be acknowledged that are larger than the cumulative TSN, and thus gaps exist in the TSN sequence), or if duplicate TSNs have been received, then a SACK chunk MUST also be sent. The sender of the SHUTDOWN MAY also start an overall guard timer 'T5-shutdown-guard' to bound the overall time for the shutdown sequence. At the expiration of this timer, the sender SHOULD abort the association by sending an ABORT chunk. If the 'T5-shutdown- guard' timer is used, it SHOULD be set to the recommended value of 5 times 'RTO.Max'. If the receiver of the SHUTDOWN has no more outstanding DATA chunks, the SHUTDOWN receiver MUST send a SHUTDOWN ACK and start a T2-
shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If the timer expires, the endpoint must resend the SHUTDOWN ACK. The sender of the SHUTDOWN ACK should limit the number of retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 'Association.Max.Retrans'. If this threshold is exceeded, the endpoint should destroy the TCB and may report the peer endpoint unreachable to the upper layer (and thus the association enters the CLOSED state). Upon the receipt of the SHUTDOWN ACK, the SHUTDOWN sender shall stop the T2-shutdown timer, send a SHUTDOWN COMPLETE chunk to its peer, and remove all record of the association. Upon reception of the SHUTDOWN COMPLETE chunk, the endpoint will verify that it is in the SHUTDOWN-ACK-SENT state; if it is not, the chunk should be discarded. If the endpoint is in the SHUTDOWN-ACK- SENT state, the endpoint should stop the T2-shutdown timer and remove all knowledge of the association (and thus the association enters the CLOSED state). An endpoint SHOULD ensure that all its outstanding DATA chunks have been acknowledged before initiating the shutdown procedure. An endpoint should reject any new data request from its upper layer if it is in the SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED, or SHUTDOWN-ACK-SENT state. If an endpoint is in the SHUTDOWN-ACK-SENT state and receives an INIT chunk (e.g., if the SHUTDOWN COMPLETE was lost) with source and destination transport addresses (either in the IP addresses or in the INIT chunk) that belong to this association, it should discard the INIT chunk and retransmit the SHUTDOWN ACK chunk. Note: Receipt of an INIT with the same source and destination IP addresses as used in transport addresses assigned to an endpoint but with a different port number indicates the initialization of a separate association. The sender of the INIT or COOKIE ECHO should respond to the receipt of a SHUTDOWN ACK with a stand-alone SHUTDOWN COMPLETE in an SCTP packet with the Verification Tag field of its common header set to the same tag that was received in the SHUTDOWN ACK packet. This is considered an Out of the Blue packet as defined in Section 8.4. The sender of the INIT lets T1-init continue running and remains in the COOKIE-WAIT or COOKIE-ECHOED state. Normal T1-init timer expiration will cause the INIT or COOKIE chunk to be retransmitted and thus start a new association.
If a SHUTDOWN is received in the COOKIE-WAIT or COOKIE ECHOED state, the SHUTDOWN chunk SHOULD be silently discarded. If an endpoint is in the 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 the 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 (ULPs) shall request 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 that 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 that defines the endpoint (see Section 1.3). 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 addresses 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 [, Upper Layer Abort Reason]) -> 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 abort 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 Upper Layer Abort Reason - 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] [,unordered 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 life time 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 life time 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 unordered 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 the 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 the 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: CHANGE HEARTBEAT(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, affects 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 15) 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 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 is 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 a 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 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 cannot be delivered, SCTP shall invoke this notification on the ULP. The following may 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 the 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 that 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. o Upper Layer Abort Reason - the abort reason specified in case of a user-initiated abort. 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 operators 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. The SCTP Authentication extension SCTP-AUTH [RFC4895] MAY be used when the threat environment requires stronger integrity protections, but does not require confidentiality. 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) [RFC4303] 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 Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306] SHOULD be used for key management. Operators should consult [RFC4301] 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. 22.214.171.124. 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 startup 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 INITs 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. 126.96.36.199. 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 that 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. Because the initial exchange is memory-less, 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. 188.8.131.52. 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. SCTP Interactions with Firewalls It is helpful for some firewalls if they can inspect just the first fragment of a fragmented SCTP packet and unambiguously determine whether it corresponds to an INIT chunk (for further information, please refer to [RFC1858]). Accordingly, we stress the requirements, stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled
with any other chunk in a packet, and (2) a packet containing an INIT chunk MUST have a zero Verification Tag. Furthermore, we require that the receiver of an INIT chunk MUST enforce these rules by silently discarding an arriving packet with an INIT chunk that is bundled with other chunks or has a non-zero verification tag and contains an INIT-chunk. 11.4. Protection of Non-SCTP-Capable Hosts To provide a non-SCTP-capable host with the same level of protection against attacks as for SCTP-capable ones, all SCTP stacks MUST implement the ICMP handling described in Appendix C. When an SCTP stack receives a packet containing multiple control or DATA chunks and the processing of the packet requires the sending of multiple chunks in response, the sender of the response chunk(s) MUST NOT send more than one packet. If bundling is supported, multiple response chunks that fit into a single packet MAY be bundled together into one single response packet. If bundling is not supported, then the sender MUST NOT send more than one response chunk and MUST discard all other responses. Note that this rule does NOT apply to a SACK chunk, since a SACK chunk is, in itself, a response to DATA and a SACK does not require a response of more DATA. An SCTP implementation SHOULD abort the association if it receives a SACK acknowledging a TSN that has not been sent. An SCTP implementation that receives an INIT that would require a large packet in response, due to the inclusion of multiple ERROR parameters, MAY (at its discretion) elect to omit some or all of the ERROR parameters to reduce the size of the INIT ACK. Due to a combination of the size of the COOKIE parameter and the number of addresses a receiver of an INIT may be indicating to a peer, it is always possible that the INIT ACK will be larger than the original INIT. An SCTP implementation SHOULD attempt to make the INIT ACK as small as possible to reduce the possibility of byte amplification attacks. 12. Network Management Considerations The MIB module for SCTP defined in [RFC3873] applies for the version of the protocol specified in this document.