RFC 6084

General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS)

📅 published January 2011, from ietf

General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS) 🎀

Okay bestie, this is RFC 6084 💖 It's an Experimental doc, so it's published so people can examine it, try it out in code, and evaluate it. It's not a standards-track spec 🧪 It was written by X. Fu and C. Dickmann at the University of Goettingen, with J. Crowcroft at the University of Cambridge, and it's dated January 2011 📅 The ISSN is 2070-1721 🦋 The title block doesn't list anything it obsoletes or updates, so no drama there ✨

Abstract ✨

GIST currently uses TCP, or TLS over TCP, for Connection mode operation 🔌 This document explains how to run GIST over SCTP and DTLS instead 🦋

Status of This Memo 📜

This document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🧪

This document defines an Experimental Protocol for the Internet community 💅 It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 📚

Info about the current status of this document, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc6084 🔗

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please read these carefully, because they explain your rights and restrictions for this document 🙈 Code Components pulled from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🫶

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust the right to allow modifications outside the IETF Standards Process. Without an adequate license from them, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈

Table of Contents 🗂️

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology and Abbreviations  . . . . . . . . . . . . . . . .  4
   3.  GIST over SCTP . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Message Association Setup  . . . . . . . . . . . . . . . .  5
       3.1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . .  5
       3.1.2.  Protocol-Definition: Forwards-SCTP . . . . . . . . . .  5
     3.2.  Effect on GIST State Maintenance . . . . . . . . . . . . .  6
     3.3.  PR-SCTP Support  . . . . . . . . . . . . . . . . . . . . .  6
     3.4.  API between GIST and NSLP  . . . . . . . . . . . . . . . .  7
   4.  Bit-Level Formats  . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  MA-Protocol-Options  . . . . . . . . . . . . . . . . . . .  7
   5.  Application of GIST over SCTP  . . . . . . . . . . . . . . . .  8
     5.1.  Multihoming Support of SCTP  . . . . . . . . . . . . . . .  8
     5.2.  Streaming Support in SCTP  . . . . . . . . . . . . . . . .  8
   6.  NAT Traversal Issue  . . . . . . . . . . . . . . . . . . . . .  8
   7.  Use of DTLS with GIST  . . . . . . . . . . . . . . . . . . . .  9
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     11.2. Informative References . . . . . . . . . . . . . . . . . . 11

1. Introduction 🌸

This document is about using the General Internet Signaling Transport (GIST) protocol [1] together with Datagram Transport Layer Security (DTLS) [2] 💖

Okay so, GIST's first spec for Connection mode (C-mode) operation runs on a byte-stream transport that gives reliable, in-sequence delivery. That's the Transmission Control Protocol (TCP) [9] carrying signaling messages 🔌 But some Next Steps in Signaling (NSIS) Signaling Layer Protocol (NSLP) [10] context info has a definite lifetime. So the GIST transport could really benefit from flexible retransmission, which lets stale NSLP messages get dropped when they're stuck behind congestion 🗑️ Add in the head-of-line blocking and multihoming problems with TCP, and these points argue that GIST implementations should support SCTP as an optional transport 🦋 SCTP is reliable, does congestion control, and does fragmentation, just like TCP. Unlike TCP, though, it has multiple streams and multiple IP addresses for path failure recovery 👑 It's also message-oriented, so you don't have to add separate framing the way you do with byte-stream TCP ✨ Its Partial Reliability extension (PR-SCTP) [3] supports partial retransmission based on a programmable retransmission timer ⏱️ And DTLS gives a viable way to secure SCTP [4], so SCTP can use almost all of its transport features and extensions 🫶

This document defines SCTP as the underlying transport for GIST, and DTLS as the security mechanism for protecting GIST Messaging Associations 🔐 It also covers what this means for GIST state maintenance and for the API between GIST and NSLPs 🧚 On top of that, it explains how GIST rides over SCTP and how NSLPs use SCTP's extra features to deliver GIST C-mode messages more effectively 💅 Specifically:

  • How to use the multiple streams feature of SCTP. 🌈
  • How to use the PR-SCTP extension of SCTP. 🍓
  • How to take advantage of the multihoming support of SCTP. 💜

GIST over SCTP, as described here, doesn't require any changes to GIST's high-level operation and structure 🎀 Adding new transport options does need extra interface code and configuration support, though, so applications can actually use the new transport when it makes sense 🛠️ Also, SCTP implementations that transport GIST MUST support the optional feature of fragmentation of SCTP user messages 💀

This document also specifies how to set up GIST security with DTLS for use with, for example, SCTP and UDP 🔒

2. Terminology and Abbreviations 📚

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [5] 🧠 Other terms and abbreviations come from related specs ([1], [2], [3], [6]) 📖

  • SCTP - Stream Control Transmission Protocol 🦋
  • PR-SCTP - SCTP Partial Reliability Extension 🌸
  • MRM - Message Routing Method 🗺️
  • MRI - Message Routing Information 🧭
  • SCD - Stack-Configuration-Data 🗃️
  • Messaging Association (MA) - A single connection between two explicitly identified GIST adjacent peers, meaning between a given signaling source and destination address. A messaging association may use a transport protocol. If security protection is required, it may use a specific network layer security association, or use a transport layer security association internally. A messaging association is bidirectional, so signaling messages can be sent over it in either direction, referring to flows of either direction 💞
  • SCTP Association - A protocol relationship between SCTP endpoints, made up of the two SCTP endpoints and their protocol state information. An association can be uniquely identified by the transport addresses the endpoints use in it. Two SCTP endpoints MUST NOT have more than one SCTP association between them at any given time 🚫
  • Stream - A unidirectional logical channel from one associated SCTP endpoint to another. Within it, all user messages are delivered in sequence, except for those sent to the unordered delivery service 🌊

3. GIST over SCTP 🦋

This section defines a new MA-Protocol-ID type, Forwards-SCTP, for using SCTP as the GIST transport protocol 💖 DTLS use in GIST is defined in Section 7 🔐

3.1. Message Association Setup 🫶

3.1.1. Overview ✨

GIST's basic spec defines two protocols that can be used in Messaging Associations: Forwards-TCP and TLS 🔌 This info is a big part of the Stack Configuration Data (SCD) [1] 📦 This section adds Forwards-SCTP (value 3) as another possible protocol option 🎀 Just like Forwards-TCP, Forwards-SCTP opens connections between peers in the forwards direction, starting at the querying node and heading toward the responder 🧚

3.1.2. Protocol-Definition: Forwards-SCTP 🌈

The MA-Protocol-ID Forwards-SCTP denotes a basic use of SCTP between peers 💅 Support for this protocol is OPTIONAL. If this protocol is offered, MA-protocol-options data MUST also be carried in the SCD object 📦 The MA-protocol-options field formats are:

  • In a Query: no information apart from the field header.
  • In a Response: a 2-byte port number where the connection will be accepted, followed by 2 pad bytes.

The connection is opened in the forwards direction, from the querying node toward the responder ➡️ The querying node MAY use any source address and source port 🌸 The destination for establishing the Messaging Association MUST be derived from the Response. Use the address from the interface-address in the Network-Layer-Information object, and the port from the SCD object as described above 🧭

Associations using Forwards-SCTP can carry messages with the transfer attribute Reliable=True 💖 If an error happens on the SCTP connection, like a reset that can be reported through an SCTP socket API notification [11], GIST MUST report it to NSLPs, as discussed in Section 4.1.2 of [1] 🚨 For the multihoming scenario, when a destination address of a GIST-over-SCTP peer changes, the SCTP API will notify GIST about the availability of different SCTP endpoint addresses and any possible change of the primary path 🦋 🫶

3.2. Effect on GIST State Maintenance ✨

okay so SCTP gives us extra features on top of TCP 🦋 this section is all about how using GIST over SCTP changes the way GIST keeps track of state 💅

SCTP streams are one-directional, but for this document we're going to treat a bidirectional stream as the main idea 🎀 implementations MUST establish both a downstream and an upstream (unidirectional) SCTP stream, and they MUST use the same stream identifier in both directions. so those two one-way streams, pointing opposite ways, team up and form one bidirectional stream 🫶

the multi-streaming support in SCTP is honestly iconic 👑 it means you can put different resources on different SCTP streams (like different NSLP sessions) instead of cramming everything onto one transport connection or association in a correlated way, which is what TCP does. TCP forces strict (re)ordering and reliability at the transport level, and SCTP doesn't have to 🌸 but no cap, there are limits. when an SCTP implementation is used for GIST transport, all GIST messages for a particular session MUST be sent over the same SCTP stream so the NSLP can keep its in-order delivery assumption 🙈 multiple sessions MAY share the same SCTP stream, based on local policy.

the GIST idea of Messaging Association re-use is not changed by this document or by using SCTP 💜 every rule in the GIST specification still applies to GIST over SCTP, no exceptions bestie 🍓

3.3. PR-SCTP Support 🧚

okay this one is so good 😭 a variant of SCTP called PR-SCTP [3] gives you a "timed reliability" service, which would be especially useful for delivering GIST Connection mode messages 🦋 it lets you choose, on a per-message basis, the rules for how hard the transport should keep trying to get the message to the receiver. because of SCTP's chunk bundling, reliable and partially reliable messages can be multiplexed over a single PR-SCTP association 🌈 so an SCTP implementation for GIST transport SHOULD try to set up a PR-SCTP association with "timed reliability" service instead of a standard SCTP association, if that's available. this gives you more flexible transport features for the different needs of different NSLPs ✨

when you're using a normally reliable session (not a partially reliable one), if a node already sent the first transmission before the lifetime ran out, the message MUST be sent as a normal reliable message 💀 during congestion this is so painful, because retransmitting wastes bandwidth that could have gone to other messages whose lifetime hadn't expired yet 😭 the "timed reliability" service in PR-SCTP fixes this, so it is RECOMMENDED for GIST over PR-SCTP 💖

3.4. API between GIST and NSLP 💅

the GIST spec defines an abstract API between GIST and NSLPs 🎀 this document doesn't change the API itself, but some parameters mean slightly different things when you're using SCTP. so this section only lists the primitives and parameters that need extra attention with SCTP. the relevant primitives from [1] are:

  • The Timeout parameter in API "SendMessage": according to [1], this parameter is the "length of time GIST should attempt to send this message before indicating an error". with PR-SCTP, it becomes the timeout for the "timed reliability" service of PR-SCTP 🧚
  • "NetworkNotification": according to [1], this primitive "is passed from GIST to a signalling application. It indicates that a network event of possible interest to the signalling application occurred". here's the tea ☕ if SCTP detects a failure of the primary path, GIST SHOULD also tell the NSLP about it by calling this primitive with Network-Notification-Type "Routing Status Change". and this notification should happen even if SCTP managed to keep an open connection to the peer thanks to its multihoming 🫶

4. Bit-Level Formats 🌸

4.1. MA-Protocol-Options 🦋

this section gives the bit-level format for the MA-protocol-options field used for SCTP in the Stack-Configuration-Data object of GIST 🧚

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :       SCTP port number        |         Reserved              :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SCTP port number = Port number at which the responder will accept SCTP connections

the SCTP port number is only supplied if the responder sends it 🙈

5. Application of GIST over SCTP ✨

5.1. Multihoming Support of SCTP 👑

the multihoming support in SCTP can generally be used to improve fault-tolerance when a path or link fails 🌈 so GIST over SCTP could still deliver NSLP messages between peers even when the primary path isn't working anymore. but for the Message Routing Methods (MRMs) in the basic GIST spec, this is only of limited use 💀 the default MRM is path-coupled, which means that if the primary path fails for the SCTP association, it most likely also fails for the IP traffic being signaled for. so GIST would still need to refresh the NSIS nodes onto the alternative path to cope with the route change anyway 😭

when the two endpoints of a multihomed SCTP association support NSIS (but none of the intermediate nodes between them do), GIST over SCTP gives you a robust way to deliver NSLP messages even when the primary path fails, as long as at least one alternative path between those NSIS-enabled endpoints is available 💖 on top of that, the multihoming support gives GIST and the NSLP another source for detecting route changes 🫶 and during the time between detecting the route change and recovering from it, the NSLP can use the alternative path SCTP offers to make the transition smoother 🦋 finally, future MRMs might have different properties and could benefit from multihoming more broadly ✨

5.2. Streaming Support in SCTP 🎀

streaming support in SCTP is a big win for GIST 🔥 it allows better parallel processing, mainly by avoiding the head-of-line blocking issue in TCP. since a single GIST MA may be reused by multiple sessions, using TCP for GIST signaling messages belonging to different sessions means they can get blocked if another message is dropped 😭 with SCTP this can be avoided, because sessions with different requirements can live on different streams. so a message loss or reordering in one stream only affects message delivery within that particular stream, not any of the other streams 🌸

6. NAT Traversal Issue 🧚

NAT traversal for GIST over SCTP will follow Section 7.2 of [1] and the GIST extensibility capabilities defined in [12]. this specification does not define NAT traversal procedures for GIST over SCTP, although an approach for SCTP NAT traversal is described in [13] 🍓

7. Use of DTLS with GIST 💜

this section specifies a new MA-Protocol-ID "DTLS" (value 4) for using DTLS in GIST 🎀 it denotes a basic use of datagram transport layer channel security, initially in conjunction with GIST over SCTP. it provides server (i.e., GIST transport receiver) authentication and integrity (as long as the NULL ciphersuite is not selected during ciphersuite negotiation), and optionally replay protection for control packets 🛡️ using DTLS to secure GIST over SCTP lets GIST take advantage of the features SCTP and its extensions provide ✨ the way DTLS works for GIST over SCTP is similar to how TLS works for GIST as specified in [1], where a stack-proposal contains both MA-Protocol-IDs for SCTP and DTLS during the GIST handshake phase 🦋

the usage of DTLS [2] for securing GIST over datagram transport protocols MUST be implemented and SHOULD be used 🔥

GIST message associations using DTLS may carry messages with transfer attributes requesting confidentiality or integrity protection 💅 the specific DTLS version gets negotiated within the DTLS layer itself, but implementations MUST NOT negotiate to protocol versions prior to DTLS v1.0, and they MUST use the highest protocol version supported by both peers 👑 NULL authentication and integrity ciphers MUST NOT be negotiated for GIST nodes that support DTLS 🙈 for confidentiality ciphers, nodes can negotiate the NULL ciphersuites. the same rules for negotiating TLS ciphersuites as specified in Section 5.7.3 of [1] apply 🌈

DTLS renegotiation [7] may cause problems for applications, because connection security parameters can change without the application knowing it 😭 so it is RECOMMENDED that renegotiation be disabled for GIST over DTLS 💖

no MA-protocol-options field is required for DTLS 🧚 the configuration information for the transport protocol DTLS runs over (e.g., SCTP port number) is provided by the MA-protocol-options for that protocol ✨

8. Security Considerations 🔥

okay this is serious bestie, so pay attention 🚨 the security considerations of [1], [6], and [2] apply. additionally, although [4] does not support replay detection in DTLS over SCTP, the SCTP replay protection mechanisms [6] [8] should be able to protect NSIS messages transported using GIST over (DTLS over) SCTP from replay attacks 💀

9. IANA Considerations 🌸

according to this specification, IANA has registered the following codepoints (MA-Protocol-IDs) in a registry created by [1] 🎀

  +---------------------+------------------------------------------+
  | MA-Protocol-ID      | Protocol                                 |
  +---------------------+------------------------------------------+
  | 3                   | SCTP opened in the forwards direction    |
  |                     |                                          |
  | 4                   | DTLS initiated in the forwards direction |
  +---------------------+------------------------------------------+

note that MA-Protocol-ID "DTLS" is never used alone 🙅‍♀️ it's always coupled with a transport protocol specified in the stack proposal 💜

10. Acknowledgments 🫶

the authors would like to thank John Loughney, Jukka Manner, Magnus Westerlund, Sean Turner, Lars Eggert, Jeffrey Hutzelman, Robert Hancock, Andrew McDonald, Martin Stiemerling, Fang-Chun Kuo, Jan Demter, Lauri Liuhto, Michael Tuexen, and Roland Bless for their helpful suggestions 🌈👑

11. References ✨

11.1. Normative References ✨

okay so these are the normative refs, aka the docs you literally have to read to understand this spec 📚💅

  • [1] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, October 2010. 🦋
  • [2] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. 🔐
  • [3] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004. 🌸
  • [4] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, January 2011. 💜
  • [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 👑
  • [6] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. 🧚
  • [7] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010. ✨
  • [8] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, August 2007. 🎀

11.2. Informative References 🌈

these ones are informative, so they're more like bonus reading for when you're curious 🤓🫶

  • [9] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. 🍓
  • [10] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005. 🦋
  • [11] Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. Lei, "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)", Work in Progress, January 2011. 🚧
  • [12] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and Extending the NSIS Protocol Family", RFC 5978, October 2010. 💅
  • [13] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control Transmission Protocol (SCTP) Network Address Translation", Work in Progress, December 2010. 🚧

Authors' Addresses 🎀

these are the humans behind it all, the squad who wrote it 🫶💖

Xiaoming Fu
University of Goettingen
Institute of Computer Science
Goldschmidtstr. 7
Goettingen  37077
Germany

EMail: fu@cs.uni-goettingen.de


Christian Dickmann
University of Goettingen
Institute of Computer Science
Goldschmidtstr. 7
Goettingen  37077
Germany

EMail: mail@christian-dickmann.de


Jon Crowcroft
University of Cambridge
Computer Laboratory
William Gates Building
15 JJ Thomson Avenue
Cambridge  CB3 0FD
UK

EMail: jon.crowcroft@cl.cam.ac.uk

and that's the whole RFC, bestie!! 🌸✨ the GIST crew really said "let's make signalling transport slay" and delivered 👑💅

📦 where this page comes from