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 3.3.10.12) 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.

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 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.

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 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.

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.  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.