RFC 3554 (rfc3554) - Page 2 of 9


On the Use of Stream Control Transmission Protocol (SCTP) with IPsec



Alternative Format: Original Text Document



RFC 3554                    SCTP with IPsec                    July 2003


1.1.  Terminology

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [RFC-2119].

2.  SCTP over IPsec

   When utilizing the Authentication Header [RFC 2402] or Encapsulating
   Security Payload [RFC 2406] protocols to provide security services for
   SCTP frames, the SCTP frame is treated as just another transport
   layer protocol on top of IP (same as TCP, UDP, etc.)

   IPsec implementations should already be able to use the SCTP
   transport protocol number as assigned by IANA as a selector in their
   Security Policy Database (SPD).  It should be straightforward to
   extend existing implementations to use the SCTP source and
   destination port numbers as selectors in the SPD.  Since the concept
   of a port, and its location in the transport header is
   protocol-specific, the IPsec code responsible for identifying the
   transport protocol ports has to be suitably modified.  This, however
   is not enough to fully support the use of SCTP in conjunction with
   IPsec.

   Since SCTP can negotiate sets of source and destination addresses
   (not necessarily in the same subnet or address range) that may be
   used in the context of a single association, the SPD should be able
   to accommodate this.  The straightforward, and expensive, way is to
   create one SPD entry for each pair of source/destination addresses
   negotiated.  A better approach is to associate sets of addresses with
   the source and destination selectors in each SPD entry (in the case
   of non-SCTP traffic, these sets would contain only one element).
   While this is an implementation decision, implementors are encouraged
   to follow this or a similar approach when designing or modifying the
   SPD to accommodate SCTP-specific selectors.

   Similarly, SAs may have multiple associated source and destination
   addresses.  Thus an SA is identified by the extended triplet ({set of
   destination addresses}, SPI, Security Protocol).  A lookup in the
   Security Association Database (SADB) using the triplet (Destination
   Address, SPI, Security Protocol), where Destination Address is any of
   the negotiated peer addresses, MUST return the same SA.









Bellovin, et. al.           Standards Track