datatracker.ietf.org
Sign in
Version 5.12.0.p1, 2015-03-01
Report a bug

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

Document type: RFC - Proposed Standard (July 2003; No errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 3554 (Proposed Standard)
Responsible AD: Russ Housley
IESG Note: Responsible: Housley
Send notices to: <byfraser@cisco.com>, <tytso@mit.edu>

Network Working Group                                        S. Bellovin
Request for Comments: 3554                                  J. Ioannidis
Category: Standards Track                           AT&T Labs - Research
                                                            A. Keromytis
                                                     Columbia University
                                                              R. Stewart
                                                                   Cisco
                                                               July 2003

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

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document describes functional requirements for IPsec (RFC 2401)
   and Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in
   securing SCTP (RFC 2960) traffic.

1.  Introduction

   The Stream Control Transmission Protocol (SCTP) is a reliable
   transport protocol operating on top of a connection-less packet
   network such as IP.  SCTP is designed to transport PSTN signaling
   messages over IP networks, but is capable of broader applications.

   When SCTP is used over IP networks, it may utilize the IP security
   protocol suite [RFC2402][RFC2406] for integrity and confidentiality.
   To dynamically establish IPsec Security Associations (SAs), a key
   negotiation protocol such as IKE [RFC2409] may be used.

   This document describes functional requirements for IPsec and IKE to
   facilitate their use in securing SCTP traffic.  In particular, we
   discuss additional support in the form of a new ID type in IKE
   [RFC2409] and implementation choices in the IPsec processing to
   accommodate for the multiplicity of source and destination addresses
   associated with a single SCTP association.

Bellovin, et. al.           Standards Track                     [Page 1]
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 [RFC2402] or Encapsulating
   Security Payload [RFC2406] 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                     [Page 2]

[include full document text]