One document matched: draft-ietf-nsis-ntlp-sctp-12.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="no"?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc0793
PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793'>
<!ENTITY rfc4080
PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4080'>
<!ENTITY rfc4081
PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4081'>
<!ENTITY rfc2119
PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119'>
<!ENTITY rfc4347
PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4347'>
<!ENTITY rfc4960
PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960'>
<!ENTITY rfc3758
PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3758'>
<!ENTITY I-D.ietf-nsis-ntlp
PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nsis-ntlp'>
<!ENTITY I-D.ietf-tsvwg-sctpsocket
PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tsvwg-sctpsocket'>
<!ENTITY I-D.ietf-tsvwg-dtls-for-sctp
PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tsvwg-dtls-for-sctp'>
<!ENTITY I-D.ietf-behave-sctpnat
PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-sctpnat'>
<!ENTITY I-D.ietf-nsis-ext
PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nsis-ext'>
]>
<rfc category="exp" ipr="pre5378Trust200902" docName="draft-ietf-nsis-ntlp-sctp-12.txt">
<front>
<title abbrev="GIST over SCTP and DTLS">General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS)</title>
<author initials="X." surname="Fu" fullname="Xiaoming Fu">
<organization abbrev="University of Goettingen"> University of Goettingen </organization>
<address>
<postal>
<street>Institute of Computer Science </street>
<street>Goldschmidtstr. 7 </street>
<city>Goettingen</city>
<code>37077</code>
<country>Germany</country>
</postal>
<email>fu@cs.uni-goettingen.de</email>
</address>
</author>
<author initials="C." surname="Dickmann" fullname="Christian Dickmann">
<organization abbrev="University of Goettingen"> University of Goettingen </organization>
<address>
<postal>
<street>Institute of Computer Science </street>
<street>Goldschmidtstr. 7</street>
<city>Goettingen</city>
<code>37077</code>
<country>Germany</country>
</postal>
<email>mail@christian-dickmann.de</email>
</address>
</author>
<author initials="J." surname="Crowcroft" fullname="Jon Crowcroft">
<organization abbrev="University of Cambridge"> University of Cambridge </organization>
<address>
<postal>
<street>Computer Laboratory </street>
<street>William Gates Building </street>
<street>15 JJ Thomson Avenue</street>
<city>Cambridge</city>
<code>CB3 0FD</code>
<country>UK</country>
</postal>
<email>jon.crowcroft@cl.cam.ac.uk</email>
</address>
</author>
<date month="May" year="2010"/>
<area>Transport</area>
<workgroup>Network Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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). The use of SCTP can take advantage of features provided by SCTP,
namely streaming-based transport, support of multiple streams to avoid head of line blocking,
the support of multi-homing to provide network level fault
tolerance, as well as partial reliability extension for partially reliable data transmission. This document also specifies how to establish GIST security over datagram transport protocols using an extension to DTLS.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t> This document describes the usage of the General Internet
Signaling Transport (GIST) protocol <xref target="I-D.ietf-nsis-ntlp"/> and Datagram Transport Layer Security (DTLS)
<xref target="RFC4347"/> over
the Stream Control Transmission Protocol (SCTP) <xref target="RFC4960"/>.</t>
<t> GIST, in its initial specification for connection 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) <xref target="RFC0793"/>
for signaling message transport. However, some Next Steps in Signaling (NSIS) Signaling Layer Protocol (NSLP) <xref target="RFC4080"/> 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 one has to provide its own
framing mechanisms. In addition, its Partial Reliability extension (PR-SCTP) <xref target="RFC3758"/>
supports partial retransmission based on a programmable
retransmission timer. Furthermore, DTLS provides a viable solution for securing SCTP <xref target="I-D.ietf-tsvwg-dtls-for-sctp"/>, which allows SCTP to use almost all its transport features and its extensions.
</t>
<t> This document defines the use of SCTP as a transport protocol and the use of DTLS as a security mechanism for GIST Messaging Associations
and discusses the implications on GIST state maintenance and API between GIST and NSLPs.
Furthermore, this document describes how GIST should be interfaced
to 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:
<!-- TODO: are these really covered in this document? (christian.dickmann) -->
<list style="symbols">
<t> How to use the multiple streams feature of SCTP.</t>
<t> How to use the PR-SCTP extension of SCTP.</t>
<!-- <t> how to handle the message oriented nature of SCTP.</t>-->
<t> How to take advantage of the multi-homing support of SCTP.</t>
</list>
</t>
<t> The methods of using an unchanged SCTP with GIST described in this
document do not require any changes to the high level
operation and structure of GIST. Addition of new transport
options requires additional interface code and configuration
support to allow applications to exploit the additional transport
when appropriate. In addition, SCTP implementions to transport GIST MUST support
the optional feature of fragmentation of SCTP user messages.</t>
<t>Additionally, this document also specifies how to establish
GIST security using DTLS for use in combination with e.g., SCTP and UDP.
</t>
</section>
<section title="Terminology and Abbreviations">
<t>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 <xref target="RFC2119"/>. Other terminologies and abbreviations used in this document
are taken from related specifications (<xref target="I-D.ietf-nsis-ntlp"/>,
<xref target="RFC4347"/>, <xref target="RFC4960"/>,
<xref target="RFC3758"/>):
<list style="symbols">
<t>SCTP - Stream Control Transmission Protocol</t>
<t>PR-SCTP - SCTP Partial Reliability Extension</t>
<t>MRM - Message Routing Method</t>
<t>MRI - Message Routing Information</t>
<t>SCD - Stack-Configuration-Data</t>
<t>Messaging Association (MA) - a single connection between
two explicitly identified GIST adjacent peers, i.e. between a given
signalling 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. A messaging association is bi-directional: signaling messages can be
sent over it in either direction, referring to flows of either
direction. </t>
<t>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. </t>
<t>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.</t>
</list>
</t>
</section>
<section title="GIST Over SCTP">
<t>This section defines a new MA-Protocol-ID type, "Forwards-SCTP",
for using SCTP as GIST transport protocol. The use of DTLS in GIST is defined in Section 7.
</t>
<section title="Message Association Setup">
<section title="Overview">
<t>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) <xref target="I-D.ietf-nsis-ntlp"/>.
This section adds "Forwards-SCTP" 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.
</t>
</section>
<section title="Protocol-Definition: Forwards-SCTP">
<t>This 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:
<list style="symbols">
<t>in a Query: no information apart from the field header.</t>
<t>in a Response: 2 byte port number at which the connection will be
accepted, followed by 2 pad bytes.</t>
</list>
</t>
<t>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 from the Network-Layer-Information object and the port from
the SCD object as described above.
</t>
<t>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<xref target="I-D.ietf-tsvwg-sctpsocket"/>, GIST MUST report this to NSLPs as discussed in
Section 4.1.2 of <xref target="I-D.ietf-nsis-ntlp"/>. For the multi-homing 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 possible change of the primary path. </t>
</section>
</section>
<section title="Effect on GIST State Maintenance">
<t>As SCTP provides additional functionality
over TCP, this section discusses the implications of using GIST over SCTP
on GIST State Maintenance.
</t>
<t>While SCTP defines uni-directional streams, for the purpose of this document,
the concept of a bi-directional stream is used. Implementations MUST establish
downstream and upstream (uni-directional) SCTP streams always together and use the same stream
identifier in both directions. Thus, the two uni-directional streams (in opposite directions)
form a bi-directional stream.
</t>
<t> 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.
</t>
<t>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.
</t>
</section>
<section anchor="pr-sctp" title="PR-SCTP Support">
<t>A variant of SCTP, PR-SCTP <xref target="RFC3758"/> provides a
"timed reliability" service, which would be particular 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.
</t>
<t>In a standard SCTP, instead, 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 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.
</t>
</section>
<section title="API between GIST and NSLP">
<t>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
interpretation 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 <xref target="I-D.ietf-nsis-ntlp"/> are as follows:
<list style="symbols">
<t>The Timeout parameter in API "SendMessage":
According to <xref target="I-D.ietf-nsis-ntlp"/>, 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.
</t>
<t> "NetworkNotification": According to <xref target="I-D.ietf-nsis-ntlp"/>, 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 multi-homing capabilities. </t>
</list>
</t>
</section>
</section>
<section title="Bit-Level Formats">
<section title="MA-Protocol-Options">
<t>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.
</t>
<t>
<figure>
<artwork><![CDATA[
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
]]>
</artwork>
</figure>
</t>
<t>The SCTP port number is only supplied if sent by the
responder.
</t>
</section>
</section>
<!--
<section title="TODO list for version 01">
<t>
<list style="symbols">
<t>More discussion on stream support of SCTP (started)</t>
<t>Application scenarios for SCTP as transport for GIST: For NatFw and QoS NSLP the multi-homing capabilities of SCTP
are of near no use with regard to fault-tolerance, as the data path is most likely affected by the same
problem and therefore GIST has to react to the route change. However, multi-homing might be used for load
balancing of NSLP traffic. We also should give some advice when to use the partial reliability feature.
</t>
</list>
</t>
</section>
-->
<section title="Application of GIST over SCTP">
<section title="Multi-homing support of SCTP">
<t>In general, the multi-homing 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 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 multi-homed 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 multi-homing
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 multi-homing
more broadly.
</t>
</section>
<section title="Streaming support in SCTP">
<t>Streaming support in SCTP is advantageous for GIST. It allows better parallel processing, in particular by avoiding head of line blocking issue in TCP. Since a same GIST MA may be reused by multiple sessions, using TCP as 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. </t>
</section>
<!-- This could also be used for local policy, how stream distribution should be done.
- Partial reliability can be used, whenever a message has a limited lifetime. We should analyze how this
interferes with NSLP protocol specification (if they do not state a limited lifetime, should an application
decide this on its own?). The question is important, as messages might be important for state machine transitions or
refreshing of some state, etc. The question which message really has a limited lifetime might be non trivial for
the implementor.
- Multi-homing support for GIST message associations is only of limited use. The basic MRM defined for GIST is the
path-coupled one. Whenever the primary SCTP path fails, and thus multi-homing in terms of failure-recovery is
relevant, the IP path faces a failure too. Thus GIST might not be path-coupled anymore, and a GIST refresh
needs to be performed. This might change the next peer. Thus, multi-homing is of limited use, however, it might
make the transition between old and new path more smooth.
Thats why an SCTP path failure should be reported to the NSLP (see API section). SCTP can therefore be used as
an additional source to detect path changes.
- Multi-homing support in general could be used for e.g. load balancing. However, this is currently not supported by
the SCTP specification. Correct?
Any further benefits of SCTP we claim to be present?
Do we want to present any specially highlighted scenario? I think this discussion should be sufficient.
<t>
</t>
-->
</section>
<section title="NAT Traversal Issue">
<t>NAT traversal for GIST over SCTP will follow Section 7.2 of <xref target="I-D.ietf-nsis-ntlp"/> and the GIST extensibility capabilities defined in <xref target="I-D.ietf-nsis-ext"/>. This specification does not define NAT traversal procedure for GIST over SCTP, although an approach for SCTP NAT traversal is described in <xref target="I-D.ietf-behave-sctpnat"/>.
</t>
</section>
<section title="Use of DTLS with GIST">
<t>This section specifies a new "MA-Protocol-ID" 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 authentication, integrity and 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. Note replay protection is not available for DTLS over SCTP <xref target="I-D.ietf-tsvwg-dtls-for-sctp"/>. The usage of DTLS for GIST over SCTP is similar to TLS for GIST as specified in <xref target="I-D.ietf-nsis-ntlp"/>, where a stack-proposal containing both MA-Protocol-IDs for SCTP and DTLS during the GIST handshake phase. </t>
<t> 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. GIST nodes
supporting DTLS MUST be able to negotiate the DTLS
NULL and block ciphers and SHOULD be able to negotiate the
new cipher suites. They MAY negotiate any
mutually acceptable ciphersuite that provides authentication,
integrity, and confidentiality. The same rules for negotiating TLS cipher suites
as specified in Section 5.7.3 of <xref target="I-D.ietf-nsis-ntlp"/> apply. </t>
<t> 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.
</t>
</section>
<section anchor="security" title="Security Considerations">
<t> The security considerations of <xref target="I-D.ietf-nsis-ntlp"/>,
<xref target="RFC4960"/> and <xref target="RFC4347"/> apply. Following <xref target="I-D.ietf-tsvwg-dtls-for-sctp"/>, replay detection of DTLS over SCTP is not supported.
</t>
<t> The usage of DTLS <xref target="RFC4347"/> for securing GIST over datagram transport protocols MUST be implemented and SHOULD be used. An implementation of GIST over SCTP with no PR-SCTP support MAY use TLS for its channel security, when DTLS is not available between two GIST peers.</t>
</section>
<section anchor="IANA Considerations" title="IANA Considerations">
<t>
This specification requests the following codepoints (MA-Protocol-IDs) be assigned in a registry created by <xref target="I-D.ietf-nsis-ntlp"/>:
<figure>
<artwork><![CDATA[
+---------------------+------------------------------------------+
| MA-Protocol-ID | Protocol |
+---------------------+------------------------------------------+
| 3 | SCTP opened in the forwards direction |
| | |
| 4 | DTLS initiated in the forwards direction |
+---------------------+------------------------------------------+
]]>
</artwork>
</figure>
</t>
<t> Note that MA-Protocol-ID 4 is never used alone but always coupled with a transport protocol in the stack proposal.</t>
</section>
<section title="Acknowledgments">
<t>The authors would like to thank
John Loughney, Jukka Manner, Magnus Westerlund, Robert Hancock, Andrew McDonald, Martin Stiemerling, Fang-Chun Kuo, Jan Demter, Lauri Liuhto, Michael Tuexen, and Roland Bless
for their helpful suggestions.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&I-D.ietf-nsis-ntlp;
&rfc4960;
&rfc4347;
&rfc3758;
&I-D.ietf-tsvwg-dtls-for-sctp;
</references>
<references title="Informative References">
&rfc0793;
&rfc4080;
&I-D.ietf-behave-sctpnat;
&I-D.ietf-nsis-ext;
&I-D.ietf-tsvwg-sctpsocket;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 20:11:33 |