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]

RFC 3554                    SCTP with IPsec                    July 2003


3.  SCTP and IKE

  There are two issues relevant to the use of IKE when negotiating
  protection for SCTP traffic:

  a) Since SCTP allows for multiple source and destination network
  addresses associated with an SCTP association, it MUST be possible
  for IKE to efficiently negotiate these in the Phase 2 (Quick Mode)
  exchange.  The straightforward approach is to negotiate one pair of
  IPsec SAs for each combination of source and destination addresses.
  This can result in an unnecessarily large number of SAs, thus wasting
  time (in negotiating these) and memory.  All current implementations
  of IKE support this functionality.  However, a method for specifying
  multiple selectors in Phase 2 is desirable for efficiency purposes.
  Conformance with this document requires that implementations adhere
  to the guidelines in the rest of this section.

  Define a new type of ID, ID_LIST, that allows for recursive inclusion
  of IDs.  Thus, the IKE Phase 2 Initiator ID for an SCTP association
  MAY be of type ID_LIST, which would in turn contain as many
  ID_IPV4_ADDR IDs as necessary to describe Initiator addresses;
  likewise for Responder IDs.  Note that other selector types MAY be
  used when establishing SAs for use with SCTP, if there is no need to
  use negotiate multiple addresses for each SCTP endpoint (i.e., if
  only one address is used by each peer of an SCTP flow).
  Implementations MUST support this new ID type.

  ID_LIST IDs cannot appear inside ID_LIST ID payloads.  Any of the ID
  types defined in [RFC2407] can be included inside an ID_LIST ID.
  Each of the IDs contained in the ID_LIST ID must include a complete
  Identification Payload header.

  The following diagram illustrates the content of an ID_LIST ID
  payload that contains two ID_FQDN payloads.

















Bellovin, et. al.           Standards Track                     [Page 3]

RFC 3554                    SCTP with IPsec                    July 2003


   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  !  Next Payload !   RESERVED    !        Payload Length         !
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  !    ID Type    !  Protocol ID  !             Port              !
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  !  Next Payload !   RESERVED    !        Payload Length         !
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  !    ID Type    !  Protocol ID  !             Port              !
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                  FQDN 1 Identification Data                   ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  !  Next Payload !   RESERVED    !        Payload Length         !
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  !    ID Type    !  Protocol ID  !             Port              !
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ~                  FQDN 2 Identification Data                   ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The Next Payload field in any of the included IDs (for FQDN 1 and
  FQDN 2) MUST be ignored by the Responder.  The Payload Length, ID
  Type, Protocol ID, and Port fields of the included Payloads should be
  set to the appropriate values.  The Protocol ID and Port fields of
  the ID_LIST Payload should be set to zero by the Initiator and MUST
  be ignored by the Responder.

  Different types of IDs (e.g., an ID_FQDN and an ID_IPV4_ADDR) can be
  included inside the same ID_LIST ID.  If an ID type included in an
  ID_LIST ID payload is invalid in the context the ID_LIST ID is used,
  the whole ID_LIST should be considered to be at fault, e.g., if an
  ID_LIST ID payload that contains an ID_FQDN and an ID_IPV4_ADDR is
  received during an IKE Quick Mode exchange, the Responder should
  signal a fault to the Initiator and stop processing of the message
  (the same behavior it would exhibit if simply an ID_FQDN was received
  instead).

  The IANA-assigned number for the ID_LIST ID is 12.

  b) For IKE to be able to validate the Phase 2 selectors, it must be
  possible to exchange sufficient information during Phase 1.
  Currently, IKE can directly accommodate the simple case of two peers
  talking to each other, by using Phase 1 IDs corresponding to their IP
  addresses, and encoding those same addresses in the SubjAltName of
  the certificates used to authenticate the Phase 1 exchange.  For more
  complicated scenarios, external policy (or some other mechanism)
  needs to be consulted, to validate the Phase 2 selectors and SA
  parameters.  All addresses presented in Phase 2 selectors MUST be
  validated.  That is, enough evidence must be presented to the



Bellovin, et. al.           Standards Track                     [Page 4]

RFC 3554                    SCTP with IPsec                    July 2003


  Responder that the Initiator is authorized to receive traffic for all
  addresses that appear in the Phase 2 selectors.  This evidence can be
  derived from the certificates exchanged during Phase 1 (if possible);
  otherwise it must be acquired through out-of-band means (e.g., policy
  mechanism, configured by the administrator, etc.).

  In order to accommodate the same simple scenario in the context of
  multiple source/destination addresses in an SCTP association, it MUST
  be possible to:

     1) Specify multiple Phase 1 IDs, which are used to validate Phase
        2 parameters (in particular, the Phase 2 selectors).  Following
        the discussion on an ID_LIST ID type, it is possible to use the
        same method for specifying multiple Phase 1 IDs.

     2) Authenticate the various Phase 1 IDs.  Using pre-shared key
        authentication, this is possible by associating the same shared
        key with all acceptable peer Phase 1 IDs.  In the case of
        certificates, we have two alternatives:

           a) The same certificate can contain multiple IDs encoded in
           the SubjAltName field, as an ASN.1 sequence.  Since this is
           already possible, it is the preferred solution and any
           conformant implementations MUST support this.

           b) Multiple certificates MAY be passed during the Phase 1
           exchange, in multiple CERT payloads.  This feature is also
           supported by the current specification.  Since only one
           signature may be issued per IKE Phase 1 exchange, it is
           necessary for all certificates to contain the same key as
           their Subject.  However, this approach does not offer any
           significant advantage over (a), thus implementations MAY
           support it.

        In either case, an IKE implementation needs to verify the
        validity of a peer's claimed Phase 1 ID, for all such IDs
        received over an exchange.

  Although SCTP does not currently support modification of the
  addresses associated with an SCTP association (while the latter is in
  use), it is a feature that may be supported in the future.  Unless
  the set of addresses changes extremely often, it is sufficient to do
  a full Phase 1 and Phase 2 exchange to establish the appropriate
  selectors and SAs.







Bellovin, et. al.           Standards Track                     [Page 5]

RFC 3554                    SCTP with IPsec                    July 2003


  The last issue with respect to SCTP and IKE pertains to the initial
  offer of Phase 2 selectors (IDs) by the Initiator.  Per the current
  IKE specification, the Responder must send in the second message of
  the Quick Mode the IDs received in the first message.  Thus, it is
  assumed that the Initiator already knows all the Selectors relevant
  to this SCTP association.  In most cases however, the Responder has
  more accurate knowledge of its various addresses.  Thus, the IPsec
  Selectors established can be potentially insufficient or inaccurate.

  If the proposed set of Selectors is not accurate from the Responder's
  point of view, the latter can start a new Quick Mode exchange.  In
  this new Quick Mode exchange, the roles of Initiator and Responder
  have been reversed; the new Initiator MUST copy the SA and Selectors
  from the old Quick Mode message, and modify its set of Selectors to
  match reality.  All SCTP-supporting IKE implementations MUST be able
  to do this.

4.  Security Considerations

  This documents discusses the use of a security protocol (IPsec) in
  the context of a new transport protocol (SCTP).  SCTP, with its
  provision for mobility, opens up the possibility for
  traffic-redirection attacks whereby an attacker X claims that his
  address should be added to an SCTP session between peers A and B, and
  be used for further communications.  In this manner, traffic between
  A and B can be seen by X.  If X is not in the communication path
  between A and B, SCTP offers him new attack capabilities.  Thus, all
  such address updates of SCTP sessions should be authenticated.  Since
  IKE negotiates IPsec SAs for use by these sessions, IKE MUST validate
  all addresses attached to an SCTP endpoint either through validating
  the certificates presented to it during the Phase 1 exchange, or
  through some out-of-band method.

  The Responder in a Phase 2 exchange MUST verify the Initiator's
  authority to receive traffic for all addresses that appear in the
  Initiator's Phase 2 selectors.  Not doing so would allow for any
  valid peer of the Responder (i.e., anyone who can successfully
  establish a Phase 1 SA with the Responder) to see any other valid
  peer's traffic by claiming their address.

5.  IANA Considerations

  IANA has assigned number 12 for ID_LIST (defined in Section 3) in the
  "IPSEC Identification Type" registry from the Internet Security
  Association and Key Management Protocol (ISAKMP) Identifiers table.






Bellovin, et. al.           Standards Track                     [Page 6]

RFC 3554                    SCTP with IPsec                    July 2003


6.  Intellectual Property Rights Notice

  The IETF takes no position regarding the validity or scope of any
  intellectual property or other rights that might be claimed to
  pertain to the implementation or use of the technology described in
  this document or the extent to which any license under such rights
  might or might not be available; neither does it represent that it
  has made any effort to identify any such rights.  Information on the
  IETF's procedures with respect to rights in standards-track and
  standards-related documentation can be found in BCP-11.  Copies of
  claims of rights made available for publication and any assurances of
  licenses to be made available, or the result of an attempt made to
  obtain a general license or permission for the use of such
  proprietary rights by implementors or users of this specification can
  be obtained from the IETF Secretariat.

  The IETF invites any interested party to bring to its attention any
  copyrights, patents or patent applications, or other proprietary
  rights which may cover technology that may be required to practice
  this standard.  Please address the information to the IETF Executive
  Director.

Normative References

  [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
             Internet Protocol", RFC 2401, November 1998.

  [RFC2402]  Kent, S. and R. Atkinson, "IP Authentication Header", RFC
             2402, November 1998.

  [RFC2406]  Kent, S. and R. Atkinson, "IP Encapsulating Security
             Payload (ESP)", RFC 2406, November 1998.

  [RFC2407]  Piper, D., "The Internet IP Security Domain of
             Interpretation for ISAKMPD", RFC 2407, November 1998.

  [RFC2408]  Maughan, D., Schertler, M., Schneider, M. and J. Turner,
             "Internet Security Association and Key Management
             Protocol", RFC 2408, November 1998.

  [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
             (IKE)", RFC 2409, November 1998.

  [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
             Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
             Zhang, L. and V. Paxson, "Stream Control Transmission
             Protocol", RFC 2960, October 2000.




Bellovin, et. al.           Standards Track                     [Page 7]

RFC 3554                    SCTP with IPsec                    July 2003


Authors' Addresses

  Steven M. Bellovin
  AT&T Labs - Research
  180 Park Avenue
  Florham Park, New Jersey 07932-0971

  Phone: +1 973 360 8656
  EMail: [email protected]


  John Ioannidis
  AT&T Labs - Research
  180 Park Avenue
  Florham Park, New Jersey 07932-0971

  EMail: [email protected]


  Angelos D. Keromytis
  Columbia University, CS Department
  515 CS Building
  1214 Amsterdam Avenue, Mailstop 0401
  New York, New York 10027-7003

  Phone: +1 212 939 7095
  EMail: [email protected]


  Randall R. Stewart
  24 Burning Bush Trail.
  Crystal Lake, IL 60012

  Phone: +1-815-477-2127
  EMail: [email protected]
















Bellovin, et. al.           Standards Track                     [Page 8]

RFC 3554                    SCTP with IPsec                    July 2003


Full Copyright Statement

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

  This document and translations of it may be copied and furnished to
  others, and derivative works that comment on or otherwise explain it
  or assist in its implementation may be prepared, copied, published
  and distributed, in whole or in part, without restriction of any
  kind, provided that the above copyright notice and this paragraph are
  included on all such copies and derivative works.  However, this
  document itself may not be modified in any way, such as by removing
  the copyright notice or references to the Internet Society or other
  Internet organizations, except as needed for the purpose of
  developing Internet standards in which case the procedures for
  copyrights defined in the Internet Standards process must be
  followed, or as required to translate it into languages other than
  English.

  The limited permissions granted above are perpetual and will not be
  revoked by the Internet Society or its successors or assignees.

  This document and the information contained herein is provided on an
  "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

  Funding for the RFC Editor function is currently provided by the
  Internet Society.



















Bellovin, et. al.           Standards Track                     [Page 9]


You are viewing proxied material from gopher.rbfh.de. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.