RFC 3554

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

📅 published July 2003, from ietf

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

Okay bestie, let's get the vibes check first ✨ This is RFC 3554, titled "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec". The authors are S. Bellovin (AT&T Labs - Research), J. Ioannidis (AT&T Labs - Research), A. Keromytis (Columbia University) and R. Stewart (Cisco). It's a Standards Track doc from the Network Working Group, dated July 2003 🎀 The title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅

Status of this Memo 📜

This document is an Internet standards track protocol for the Internet community, and it's inviting discussion and suggestions for improvements 🌸 If you want the current standardization state and status of this protocol, go check the "Internet Official Protocol Standards" (STD 1) 🔍 Distribution of this memo is unlimited, so share the tea 🫶

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

Abstract ✨

This doc lays out the functional requirements for IPsec (RFC 2401) and Internet Key Exchange (IKE) (RFC 2409) so they can smoothly secure SCTP (RFC 2960) traffic 🦋

1. Introduction 🧚

okay so the Stream Control Transmission Protocol (SCTP) is a reliable transport protocol that runs on top of a connection-less packet network like IP 💜 It was designed to carry PSTN signaling messages over IP networks, but it's giving "capable of so much more" 👑

When SCTP runs over IP networks, it may use the IP security protocol suite [RFC2402][RFC2406] for integrity and confidentiality 🔐 To set up IPsec Security Associations (SAs) on the fly, a key negotiation protocol such as IKE [RFC2409] may be used ⭐

So this document is all about the functional requirements for IPsec and IKE so they can secure SCTP traffic without drama 🎀 Specifically, we talk about extra support in the form of a new ID type in IKE [RFC2409], plus implementation choices in the IPsec processing. Why? Because a single SCTP association can come with a whole crowd of source and destination addresses, and IPsec has to handle that multiplicity 🙈

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]. Yes, the capitalized ones are doing the heavy lifting here, so pay attention to them 💅

2. SCTP over IPsec 🦋

When you use the Authentication Header [RFC2402] or Encapsulating Security Payload [RFC2406] protocols to protect SCTP frames, the SCTP frame gets treated as just another transport layer protocol on top of IP, same as TCP, UDP, etc. 💖 No special VIP treatment, just vibing with the rest of the crew ✨

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 so they use the SCTP source and destination port numbers as selectors in the SPD 🍓 Here's the catch: the concept of a port, and where it sits in the transport header, is protocol-specific. So the IPsec code that identifies the transport protocol ports has to be suitably modified 🔧 Still, that alone is not enough to fully support SCTP with IPsec, and that's the real plot twist 😭

Now for the addresses. SCTP can negotiate sets of source and destination addresses (not necessarily in the same subnet or address range) that may be used within a single association, so the SPD should be able to handle that 🌈 The straightforward but expensive way is to create one SPD entry for each source/destination address pair that gets negotiated 💀 A better approach is to associate sets of addresses with the source and destination selectors in each SPD entry. For non-SCTP traffic, those sets would just contain one element, so nothing breaks for the rest of the group 🧚 This is an implementation decision, but implementors are encouraged to follow this approach or a similar one when designing or modifying the SPD to handle SCTP-specific selectors ✨

Similarly, SAs may have multiple associated source and destination addresses 💜 So an SA is identified by the extended triplet ({set of destination addresses}, SPI, Security Protocol) 🎀 When you look up the Security Association Database (SADB) using the triplet (Destination Address, SPI, Security Protocol), where Destination Address is any of the negotiated peer addresses, it MUST return the same SA 👑 Non-negotiable, periodt 💅

3. SCTP and IKE ✨

okay so there are two big issues when IKE is negotiating protection for SCTP traffic 🦋

  • a) Multiple addresses per association 💖 SCTP lets one association have multiple source and destination network addresses, so IKE MUST be able to negotiate all of them efficiently in the Phase 2 (Quick Mode) exchange. The obvious move is one pair of IPsec SAs per combination of source and destination addresses, but that can make an unnecessarily huge pile of SAs, which wastes time (negotiating them!) and memory 💀. Every current IKE implementation supports this, ngl, but a way to specify multiple selectors in Phase 2 is desirable for efficiency. Conformance with this document means following the guidelines in the rest of this section 🎀
  • b) Validating the Phase 2 selectors 🔥 For IKE to validate the Phase 2 selectors, enough information has to get exchanged during Phase 1.

Okay, let's zoom in on part a) first. The solution is a brand-new ID type called ID_LIST 🧚 It allows recursive inclusion of IDs, so the IKE Phase 2 Initiator ID for an SCTP association MAY be an ID_LIST, which would then contain as many ID_IPV4_ADDR IDs as needed to describe the Initiator addresses. Responder IDs work the same way. Other selector types MAY be used when setting up SAs for SCTP, as long as there's no need to negotiate multiple addresses for each SCTP endpoint (aka if each peer of an SCTP flow only uses one address). Implementations MUST support this new ID type, no exceptions 👑

Some rules for ID_LIST, bestie:

  • ID_LIST IDs cannot appear inside ID_LIST ID payloads. No nesting dolls here 🙈
  • 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.

Here's a picture of an ID_LIST ID payload holding two ID_FQDN payloads 🍓

    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 field rules here are super specific, so pay attention 👀

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

Mixing is allowed! Different types of IDs (like an ID_FQDN and an ID_IPV4_ADDR) can live in the same ID_LIST ID. BUT if an ID type inside an ID_LIST isn't valid for the context it's used in, the whole ID_LIST is considered at fault. For example, if an ID_LIST holding an ID_FQDN and an ID_IPV4_ADDR shows up during an IKE Quick Mode exchange, the Responder should signal a fault to the Initiator and stop processing the message. That's the same behaviour it would show if just a lonely ID_FQDN had arrived instead 🙅‍♀️

And the IANA-assigned number for ID_LIST is 12 🎀

Now part b), the Phase 1 side of things 🌸 For IKE to validate Phase 2 selectors, it has to be possible to exchange enough info during Phase 1. Right now, IKE can handle the simple case of two peers talking directly, by using Phase 1 IDs that match their IP addresses and putting those same addresses in the SubjAltName of the certificates used for Phase 1 authentication. For messier setups, external policy (or some other mechanism) has to be consulted to validate the Phase 2 selectors and SA parameters.

Important: all addresses presented in Phase 2 selectors MUST be validated. In other words, the Responder needs enough evidence that the Initiator is authorized to receive traffic for every address in the Phase 2 selectors. That evidence can come from the certificates exchanged during Phase 1 (if possible); otherwise it has to come through out-of-band means, like a policy mechanism or something the administrator configured 🫶

To get that same simple scenario working with multiple source/destination addresses in an SCTP association, it MUST be possible to do the following:

  1. Specify multiple Phase 1 IDs 💅 These are used to validate Phase 2 parameters (especially the Phase 2 selectors). Since we just talked about ID_LIST, the same method works for specifying multiple Phase 1 IDs.
  2. Authenticate the various Phase 1 IDs 🔐 With pre-shared key authentication, this works by associating the same shared key with all acceptable peer Phase 1 IDs. With certificates, there are two options:
    • a) The same certificate can contain multiple IDs encoded in the SubjAltName field, as an ASN.1 sequence. Since this is already possible, it's the preferred solution, and any conformant implementations MUST support it.
    • 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, all the certificates have to contain the same key as their Subject. However, this approach doesn't offer any significant advantage over a), so implementations MAY support it, but they don't have to 🤷‍♀️

No matter which way you go, an IKE implementation needs to verify the validity of a peer's claimed Phase 1 ID, for all such IDs received over an exchange. No skipping!

SCTP doesn't support changing the addresses of an association while it's in use yet, but it might in the future 👀 Unless the set of addresses changes extremely often, a full Phase 1 and Phase 2 exchange is enough to set up the right selectors and SAs.

The last issue is about the initial offer of Phase 2 selectors (IDs) from the Initiator 🦋 Under the current IKE spec, the Responder has to send back, in the second message of Quick Mode, the IDs it received in the first message. So the Initiator is assumed to already know all the Selectors relevant to this SCTP association. But honestly? In most cases the Responder knows its own addresses way better 🙃 That means the IPsec Selectors that get set up could be insufficient or inaccurate.

If the proposed set of Selectors isn't accurate from the Responder's point of view, the Responder can kick off a brand-new Quick Mode exchange. In this new one, the roles of Initiator and Responder are reversed. The new Initiator MUST copy the SA and Selectors from the old Quick Mode message, then modify its set of Selectors to match reality. And every SCTP-supporting IKE implementation MUST be able to do this 💖

4. Security Considerations 🔒

okay bestie, this part is SERIOUS 😭 This document discusses the use of a security protocol (IPsec) in the context of a new transport protocol (SCTP). SCTP, with its mobility support, opens the door to traffic-redirection attacks, where an attacker X claims that their address should be added to an SCTP session between peers A and B and then used for further communication. That way, traffic between A and B can be seen by X. If X isn't on the communication path between A and B, SCTP gives them brand-new attack capabilities 💀 So all such address updates of SCTP sessions should be authenticated. Since IKE negotiates the IPsec SAs used by these sessions, IKE MUST validate all addresses attached to an SCTP endpoint, either by validating the certificates presented 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. If it doesn't, any valid peer of the Responder (meaning anyone who can successfully establish a Phase 1 SA with the Responder) could see any other valid peer's traffic just by claiming their address. Not okay at all 🙅‍♀️

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 ✨

6. Intellectual Property Rights Notice 💜

Lowkey a boring one, but it's important! 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. It also doesn't 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, any assurances of licenses to be made available, or the result of an attempt 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 also 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 that 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.

Authors' Addresses 🎀

okay bestie, meet the squad behind this one 💖 four authors, all with real addresses, so you know exactly who to slide into the DMs (professionally, obviously 🙈)

Steven M. Bellovin 🌸

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

Phone: +1 973 360 8656
EMail: smb@research.att.com

John Ioannidis 🦋

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

EMail: ji@research.att.com

Angelos D. Keromytis 🧚

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: angelos@cs.columbia.edu

Randall R. Stewart 👑

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

Phone: +1-815-477-2127
EMail: rrs@cisco.com

okay, the legal part, and I'm keeping the wording exactly as written because lawyers are not it and changing a single word could mess up the rights 😭

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 🫶

last one, and it's a sweet one 🌈

Funding for the RFC Editor function is currently provided by the Internet Society. thank you, Internet Society 💜✨

📦 where this page comes from