    Internet Engineering Task Force (IETF)                             X. Fu
    Request for Comments: 6084                                   C. Dickmann
    Category: Experimental                          University of Goettingen
    ISSN: 2070-1721                                             J. Crowcroft
                                                     University of Cambridge
                                                                January 2011

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

    Abstract

       The General Internet Signaling Transport (GIST) protocol currently
       uses TCP or Transport Layer Security (TLS) over TCP for Connection
       mode operation.  This document describes the usage of GIST over the
       Stream Control Transmission Protocol (SCTP) and Datagram Transport
       Layer Security (DTLS).

    Status of This Memo

       This document is not an Internet Standards Track specification; it is
       published for examination, experimental implementation, and
       evaluation.

       This document defines an Experimental Protocol for the Internet
       community.  This document is a product of the Internet Engineering
       Task Force (IETF).  It represents the consensus of the IETF
       community.  It has received public review and has been approved for
       publication by the Internet Engineering Steering Group (IESG).  Not
       all documents approved by the IESG are a candidate for any level of
       Internet Standard; see Section 2 of RFC 5741.

       Information about the current status of this document, any errata,
       and how to provide feedback on it may be obtained at
       http://www.rfc-editor.org/info/rfc6084.

    Copyright Notice

       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) in effect on the date of
       publication of this document.  Please review these documents
       carefully, as they describe your rights and restrictions with respect

    Fu, et al.                    Experimental                      [Page 1]

    RFC 6084                 GIST over SCTP and DTLS            January 2011

       to this document.  Code Components extracted from this document must
       include Simplified BSD License text as described in Section 4.e of
       the Trust Legal Provisions and are provided 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 person(s) controlling the copyright in some of this
       material may not have granted the IETF Trust the right to allow
       modifications of such material outside the IETF Standards Process.
       Without obtaining an adequate license from the person(s) controlling
       the copyright in such materials, 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, except to format
       it for publication as an RFC or to translate 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

    Fu, et al.                    Experimental                      [Page 2]

    RFC 6084                 GIST over SCTP and DTLS            January 2011

    1.  Introduction

       This document describes the usage of the General Internet Signaling
       Transport (GIST) protocol [1] and Datagram Transport Layer Security
       (DTLS) [2].

       GIST, in its initial specification for Connection mode (C-mode)
       operation, runs on top of a byte-stream-oriented transport protocol
       providing a reliable, in-sequence delivery, i.e., using the
       Transmission Control Protocol (TCP) [9] for signaling message
       transport.  However, some Next Steps in Signaling (NSIS) Signaling
       Layer Protocol (NSLP) [10] context information has a definite
       lifetime; therefore, the GIST transport protocol could benefit from
       flexible retransmission, so stale NSLP messages that are held up by
       congestion can be dropped.  Together with the head-of-line blocking
       and multihoming issues with TCP, these considerations argue that
       implementations of GIST should support SCTP as an optional transport
       protocol for GIST.  Like TCP, SCTP supports reliability, congestion
       control, and fragmentation.  Unlike TCP, SCTP provides a number of
       functions that are desirable for signaling transport, such as
       multiple streams and multiple IP addresses for path failure recovery.
       Furthermore, SCTP offers an advantage of message-oriented transport
       instead of using the byte-stream-oriented TCP where the framing
       mechanisms must be provided separately.  In addition, its Partial
       Reliability extension (PR-SCTP) [3] supports partial retransmission
       based on a programmable retransmission timer.  Furthermore, DTLS
       provides a viable solution for securing SCTP [4], which allows SCTP
       to use almost all of its transport features and its extensions.

       This document defines the use of SCTP as the underlying transport
       protocol for GIST and the use of DTLS as a security mechanism for
       protecting GIST Messaging Associations and discusses the implications
       on GIST state maintenance and API between GIST and NSLPs.
       Furthermore, this document describes how GIST is transported over
       SCTP and used by NSLPs in order to exploit the additional
       capabilities offered by SCTP to deliver GIST C-mode messages more
       effectively.  More specifically:

       o  How to use the multiple streams feature of SCTP.

       o  How to use the PR-SCTP extension of SCTP.

       o  How to take advantage of the multihoming support of SCTP.

       GIST over SCTP as described in this document does not require any
       changes to the high-level operation and structure of GIST.  However,
       adding new transport options requires additional interface code and
       configuration support to allow applications to exploit the additional

    Fu, et al.                    Experimental                      [Page 3]

    RFC 6084                 GIST over SCTP and DTLS            January 2011

       transport when appropriate.  In addition, SCTP implementations to
       transport GIST MUST support the optional feature of fragmentation of
       SCTP user messages.

       Additionally, this document also specifies how to establish GIST
       security using DTLS for use in combination with, e.g., 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 interpreted as described in [5].  Other
       terminologies and abbreviations used in this document are taken from
       related specifications ([1], [2], [3], [6]):

       o  SCTP - Stream Control Transmission Protocol

       o  PR-SCTP - SCTP Partial Reliability Extension

       o  MRM - Message Routing Method

       o  MRI - Message Routing Information

       o  SCD - Stack-Configuration-Data

       o  Messaging Association (MA) - A single connection between two
          explicitly identified GIST adjacent peers, i.e., 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: signaling messages can be sent over
          it in either direction, referring to flows of either direction.

       o  SCTP Association - A protocol relationship between SCTP endpoints,
          composed of the two SCTP endpoints and protocol state information.
          An association can be uniquely identified by the transport
          addresses used by the endpoints in the association.  Two SCTP
          endpoints MUST NOT have more than one SCTP association between
          them at any given time.

       o  Stream - A unidirectional logical channel established from one to
          another associated SCTP endpoint, within which all user messages
          are delivered in sequence except for those submitted to the
          unordered delivery service.

    Fu, et al.                    Experimental                      [Page 4]

    RFC 6084                 GIST over SCTP and DTLS            January 2011

    3.  GIST over SCTP

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

    3.1.  Message Association Setup

    3.1.1.  Overview

       The basic GIST protocol specification defines two possible protocols
       to be used in Messaging Associations, namely Forwards-TCP and TLS.
       This information is a main part of the Stack Configuration Data (SCD)
       [1].  This section adds Forwards-SCTP (value 3) as another possible
       protocol option.  In Forwards-SCTP, analog to Forwards-TCP,
       connections between peers are opened in the forwards direction, from
       the querying node, towards 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:

       o  in a Query: no information apart from the field header.

       o  in a Response: 2-byte port number at which the connection will be
          accepted, followed by 2 pad bytes.

       The connection is opened in the forwards direction, from the querying
       node towards the responder.  The querying node MAY use any source
       address and source port.  The destination for establishing the
       message association MUST be derived from information in the Response:
       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 occurs on the SCTP connection
       such as a reset, as can be reported by an SCTP socket API
       notification [11], GIST MUST report this 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 encounters a change, the
       SCTP API will notify GIST about the availability of different SCTP
       endpoint addresses and the possible change of the primary path.

    Fu, et al.                    Experimental                      [Page 5]

    RFC 6084                 GIST over SCTP and DTLS            January 2011

    3.2.  Effect on GIST State Maintenance

       As SCTP provides additional functionality over TCP, this section
       discusses the implications of using GIST over SCTP on GIST state
       maintenance.

       While SCTP defines unidirectional streams, for the purpose of this
       document, the concept of a bidirectional stream is used.
       Implementations MUST establish both downstream and upstream
       (unidirectional) SCTP streams and use the same stream identifier in
       both directions.  Thus, the two unidirectional streams (in opposite
       directions) form a bidirectional stream.

       Due to the multi-streaming support of SCTP, it is possible to use
       different SCTP streams for different resources (e.g., different NSLP
       sessions), rather than maintaining all messages along the same
       transport connection/association in a correlated fashion as TCP
       (which imposes strict (re)ordering and reliability per transport
       level).  However, there are limitations to the use of multi-
       streaming.  When an SCTP implementation is used for GIST transport,
       all GIST messages for a particular session MUST be sent over the same
       SCTP stream to assure the NSLP assumption of in-order delivery.
       Multiple sessions MAY share the same SCTP stream based on local
       policy.

       The GIST concept of Messaging Association re-use is not affected by
       this document or the use of SCTP.  All rules defined in the GIST
       specification remain valid in the context of GIST over SCTP.

    3.3.  PR-SCTP Support

       A variant of SCTP, PR-SCTP [3] provides a "timed reliability"
       service, which would be particularly useful for delivering GIST
       Connection mode messages.  It allows the user to specify, on a per-
       message basis, the rules governing how persistent the transport
       service should be in attempting to send the message to the receiver.
       Because of the chunk bundling function of SCTP, reliable and
       partially reliable messages can be multiplexed over a single PR-SCTP
       association.  Therefore, an SCTP implementation for GIST transport
       SHOULD attempt to establish a PR-SCTP association using "timed
       reliability" service instead of a standard SCTP association, if
       available, to support more flexible transport features for potential
       needs of different NSLPs.

       When using a normally reliable session (as opposed to a partially
       reliable session), if a node has sent the first transmission before
       the lifetime expires, then the message MUST be sent as a normal
       reliable message.  During episodes of congestion, this is

    Fu, et al.                    Experimental                      [Page 6]

    RFC 6084                 GIST over SCTP and DTLS            January 2011

       particularly unfortunate, as retransmission wastes bandwidth that
       could have been used for other (non-lifetime expired) messages.  The
       "timed reliability" service in PR-SCTP eliminates this issue and is
       hence RECOMMENDED to be used for GIST over PR-SCTP.

    3.4.  API between GIST and NSLP

       The GIST specification defines an abstract API between GIST and
       NSLPs.  While this document does not change the API itself, the
       semantics of some parameters have slightly different interpretations
       in the context of SCTP.  This section only lists those primitives and
       parameters that need special consideration when used in the context
       of SCTP.  The relevant primitives from [1] are as follows:

       o  The Timeout parameter in API "SendMessage": According to [1], this
          parameter represents the "length of time GIST should attempt to
          send this message before indicating an error".  When used with
          PR-SCTP, this parameter is used as the timeout for the "timed
          reliability" service of PR-SCTP.

       o  "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, if SCTP detects a failure of the primary path,
          GIST SHOULD also indicate this event to the NSLP by calling this
          primitive with Network-Notification-Type "Routing Status Change".
          This notification should be done even if SCTP was able to retain
          an open connection to the peer due to its multihoming
          capabilities.

    4.  Bit-Level Formats

    4.1.  MA-Protocol-Options

       This section provides the bit-level format for the MA-protocol-
       options field that is used for SCTP protocol 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 sent by the responder.

    Fu, et al.                    Experimental                      [Page 7]

    RFC 6084                 GIST over SCTP and DTLS            January 2011

    5.  Application of GIST over SCTP

    5.1.  Multihoming Support of SCTP

       In general, the multihoming support of SCTP can be used to improve
       fault-tolerance in case of a path or link failure.  Thus, GIST over
       SCTP would be able to deliver NSLP messages between peers even if the
       primary path is not working anymore.  However, for the Message
       Routing Methods (MRMs) defined in the basic GIST specification, such
       a feature is only of limited use.  The default MRM is path-coupled,
       which means that if the primary path is failing for the SCTP
       association, it most likely is also failing for the IP traffic that
       is signaled for.  Thus, GIST would need to perform a refresh to the
       NSIS nodes to the alternative path anyway to cope with the route
       change.  When the two endpoints of a multihomed SCTP association (but
       none of the intermediate nodes between them) support NSIS, GIST over
       SCTP provides a robust means for GIST to deliver NSLP messages even
       when the primary path fails but at least one alternative path between
       these (NSIS-enabled) endpoints of the multihomed path is available.
       Additionally, the use of the multihoming support of SCTP provides
       GIST and the NSLP with another source to detect route changes.
       Furthermore, for the time between detection of the route change and
       recovering from it, the alternative path offered by SCTP can be used
       by the NSLP to make the transition more smoothly.  Finally, future
       MRMs might have different properties and therefore benefit from
       multihoming more broadly.

    5.2.  Streaming Support in SCTP

       Streaming support in SCTP is advantageous for GIST.  It allows better
       parallel processing, in particular by avoiding the head-of-line
       blocking issue in TCP.  Since a single GIST MA may be reused by
       multiple sessions, using TCP as the transport for GIST signaling
       messages belonging to different sessions may be blocked if another
       message is dropped.  In the case of SCTP, this can be avoided, as
       different sessions having different requirements can belong to
       different streams; thus, a message loss or reordering in a stream
       will only affect the delivery of messages within that particular
       stream, and not any 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].

    Fu, et al.                    Experimental                      [Page 8]

    RFC 6084                 GIST over SCTP and DTLS            January 2011

    7.  Use of DTLS with GIST

       This section specifies a new MA-Protocol-ID "DTLS" (value 4) for the
       use of DTLS in GIST, which 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), as well as optionally replay protection for
       control packets.  The use of DTLS for securing GIST over SCTP allows
       GIST to take the advantage of features provided by SCTP and its
       extensions.  The usage of DTLS for GIST over SCTP is similar to TLS
       for GIST as specified in [1], where a stack-proposal containing 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 will be negotiated within the DTLS layer
       itself, but implementations MUST NOT negotiate to protocol versions
       prior to DTLS v1.0 and MUST use the highest protocol version
       supported by both peers.  NULL authentication and integrity ciphers
       MUST NOT be negotiated for GIST nodes supporting 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 such that
       connection security parameters can change without the application
       knowing it.  Hence, 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 over which DTLS is running
       (e.g., SCTP port number) is provided by the MA-protocol-options for
       that protocol.

    8.  Security Considerations

       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.

    Fu, et al.                    Experimental                      [Page 9]

    RFC 6084                 GIST over SCTP and DTLS            January 2011

    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 but 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

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

    Fu, et al.                    Experimental                     [Page 10]

    RFC 6084                 GIST over SCTP and DTLS            January 2011

       [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

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

    Fu, et al.                    Experimental                     [Page 11]

    RFC 6084                 GIST over SCTP and DTLS            January 2011

    Authors' Addresses

       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

    Fu, et al.                    Experimental                     [Page 12]