draft-ietf-nsis-ntlp-sctp-15.txt   rfc6084.txt 
Network Working Group X. Fu Internet Engineering Task Force (IETF) X. Fu
Internet-Draft C. Dickmann Request for Comments: 6084 C. Dickmann
Intended status: Experimental University of Goettingen Category: Experimental University of Goettingen
Expires: December 27, 2010 J. Crowcroft ISSN: 2070-1721 J. Crowcroft
University of Cambridge University of Cambridge
June 25, 2010 January 2011
General Internet Signaling Transport (GIST) over Stream Control General Internet Signaling Transport (GIST)
Transmission Protocol (SCTP) and Datagram Transport Layer Security over Stream Control Transmission Protocol (SCTP)
(DTLS) and Datagram Transport Layer Security (DTLS)
draft-ietf-nsis-ntlp-sctp-15.txt
Abstract Abstract
The General Internet Signaling Transport (GIST) protocol currently The General Internet Signaling Transport (GIST) protocol currently
uses TCP or Transport Layer Security (TLS) over TCP for connection uses TCP or Transport Layer Security (TLS) over TCP for Connection
mode operation. This document describes the usage of GIST over the mode operation. This document describes the usage of GIST over the
Stream Control Transmission Protocol (SCTP) and Datagram Transport Stream Control Transmission Protocol (SCTP) and Datagram Transport
Layer Security (DTLS). Layer Security (DTLS).
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for examination, experimental implementation, and
working documents as Internet-Drafts. The list of current Internet- evaluation.
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on December 27, 2010. 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 Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 2, line 23
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 5 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. GIST Over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 5 3. GIST over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Message Association Setup . . . . . . . . . . . . . . . . 5 3.1. Message Association Setup . . . . . . . . . . . . . . . . 5
3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 6 3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 5
3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 6 3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 6
3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 7 3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 6
3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 7 3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 7
4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 8 4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 7
4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 8 4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 7
5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 8 5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 8
5.1. Multi-homing support of SCTP . . . . . . . . . . . . . . . 8 5.1. Multihoming Support of SCTP . . . . . . . . . . . . . . . 8
5.2. Streaming support in SCTP . . . . . . . . . . . . . . . . 9 5.2. Streaming Support in SCTP . . . . . . . . . . . . . . . . 8
6. NAT Traversal Issue . . . . . . . . . . . . . . . . . . . . . 9 6. NAT Traversal Issue . . . . . . . . . . . . . . . . . . . . . 8
7. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 9 7. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This document describes the usage of the General Internet Signaling This document describes the usage of the General Internet Signaling
Transport (GIST) protocol [1] and Datagram Transport Layer Security Transport (GIST) protocol [1] and Datagram Transport Layer Security
(DTLS) [2]. (DTLS) [2].
GIST, in its initial specification for connection mode operation, GIST, in its initial specification for Connection mode (C-mode)
runs on top of a byte-stream oriented transport protocol providing a operation, runs on top of a byte-stream-oriented transport protocol
reliable, in-sequence delivery, i.e., using the Transmission Control providing a reliable, in-sequence delivery, i.e., using the
Protocol (TCP) [9] for signaling message transport. However, some Transmission Control Protocol (TCP) [9] for signaling message
Next Steps in Signaling (NSIS) Signaling Layer Protocol (NSLP) [10] transport. However, some Next Steps in Signaling (NSIS) Signaling
context information has a definite lifetime, therefore, the GIST Layer Protocol (NSLP) [10] context information has a definite
transport protocol could benefit from flexible retransmission, so lifetime; therefore, the GIST transport protocol could benefit from
stale NSLP messages that are held up by congestion can be dropped. flexible retransmission, so stale NSLP messages that are held up by
Together with the head-of-line blocking and multihoming issues with congestion can be dropped. Together with the head-of-line blocking
TCP, these considerations argue that implementations of GIST should and multihoming issues with TCP, these considerations argue that
support SCTP as an optional transport protocol for GIST. Like TCP, implementations of GIST should support SCTP as an optional transport
SCTP supports reliability, congestion control and fragmentation. protocol for GIST. Like TCP, SCTP supports reliability, congestion
Unlike TCP, SCTP provides a number of functions that are desirable control, and fragmentation. Unlike TCP, SCTP provides a number of
for signaling transport, such as multiple streams and multiple IP functions that are desirable for signaling transport, such as
addresses for path failure recovery. Furthermore, SCTP offers an multiple streams and multiple IP addresses for path failure recovery.
advantage of message-oriented transport instead of using the byte Furthermore, SCTP offers an advantage of message-oriented transport
stream oriented TCP where one has to provide its own framing instead of using the byte-stream-oriented TCP where the framing
mechanisms. In addition, its Partial Reliability extension (PR-SCTP) mechanisms must be provided separately. In addition, its Partial
[3] supports partial retransmission based on a programmable Reliability extension (PR-SCTP) [3] supports partial retransmission
retransmission timer. Furthermore, DTLS provides a viable solution based on a programmable retransmission timer. Furthermore, DTLS
for securing SCTP [4], which allows SCTP to use almost all its provides a viable solution for securing SCTP [4], which allows SCTP
transport features and its extensions. to use almost all of its transport features and its extensions.
This document defines the use of SCTP as the underlying transport This document defines the use of SCTP as the underlying transport
protocol for GIST and the use of DTLS as a security mechanism for protocol for GIST and the use of DTLS as a security mechanism for
protecting GIST Messaging Associations and discusses the implications protecting GIST Messaging Associations and discusses the implications
on GIST state maintenance and API between GIST and NSLPs. on GIST state maintenance and API between GIST and NSLPs.
Furthermore, this document describes how GIST is transported over Furthermore, this document describes how GIST is transported over
SCTP and used by NSLPs in order to exploit the additional SCTP and used by NSLPs in order to exploit the additional
capabilities offered by SCTP to deliver GIST C-mode messages more capabilities offered by SCTP to deliver GIST C-mode messages more
effectively. More specifically: effectively. More specifically:
o How to use the multiple streams feature of SCTP. o How to use the multiple streams feature of SCTP.
o How to use the PR-SCTP extension of SCTP. o How to use the PR-SCTP extension of SCTP.
o How to take advantage of the multi-homing support of SCTP.
GIST over SCTP described in this document do not require any changes o How to take advantage of the multihoming support of SCTP.
to the high level operation and structure of GIST. However, adding
new transport options requires additional interface code and 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 configuration support to allow applications to exploit the additional
transport when appropriate. In addition, SCTP implementions to transport when appropriate. In addition, SCTP implementations to
transport GIST MUST support the optional feature of fragmentation of transport GIST MUST support the optional feature of fragmentation of
SCTP user messages. SCTP user messages.
Additionally, this document also specifies how to establish GIST Additionally, this document also specifies how to establish GIST
security using DTLS for use in combination with e.g., SCTP and UDP. security using DTLS for use in combination with, e.g., SCTP and UDP.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [5]. Other document are to be interpreted as described in [5]. Other
terminologies and abbreviations used in this document are taken from terminologies and abbreviations used in this document are taken from
related specifications ([1], [2], [6], [3]): related specifications ([1], [2], [3], [6]):
o SCTP - Stream Control Transmission Protocol o SCTP - Stream Control Transmission Protocol
o PR-SCTP - SCTP Partial Reliability Extension o PR-SCTP - SCTP Partial Reliability Extension
o MRM - Message Routing Method o MRM - Message Routing Method
o MRI - Message Routing Information o MRI - Message Routing Information
o SCD - Stack-Configuration-Data o SCD - Stack-Configuration-Data
o Messaging Association (MA) - a single connection between two
explicitly identified GIST adjacent peers, i.e. between a given o Messaging Association (MA) - A single connection between two
signalling source and destination address. A messaging explicitly identified GIST adjacent peers, i.e., between a given
association may use a transport protocol; if security protection signaling source and destination address. A messaging association
is required, it may use a specific network layer security may use a transport protocol; if security protection is required,
association, or use a transport layer security association it may use a specific network layer security association, or use a
internally. A messaging association is bi-directional; signaling transport layer security association internally. A messaging
messages can be sent over it in either direction, referring to association is bidirectional: signaling messages can be sent over
flows of either direction. it in either direction, referring to flows of either direction.
o SCTP Association - A protocol relationship between SCTP endpoints, o SCTP Association - A protocol relationship between SCTP endpoints,
composed of the two SCTP endpoints and protocol state information. composed of the two SCTP endpoints and protocol state information.
An association can be uniquely identified by the transport An association can be uniquely identified by the transport
addresses used by the endpoints in the association. Two SCTP addresses used by the endpoints in the association. Two SCTP
endpoints MUST NOT have more than one SCTP association between endpoints MUST NOT have more than one SCTP association between
them at any given time. them at any given time.
o Stream - A unidirectional logical channel established from one to o Stream - A unidirectional logical channel established from one to
another associated SCTP endpoint, within which all user messages another associated SCTP endpoint, within which all user messages
are delivered in sequence except for those submitted to the are delivered in sequence except for those submitted to the
unordered delivery service. unordered delivery service.
3. GIST Over SCTP 3. GIST over SCTP
This section defines a new MA-Protocol-ID type, "Forwards-SCTP", for 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 using SCTP as the GIST transport protocol. The use of DTLS in GIST
defined in Section 7. is defined in Section 7.
3.1. Message Association Setup 3.1. Message Association Setup
3.1.1. Overview 3.1.1. Overview
The basic GIST protocol specification defines two possible protocols The basic GIST protocol specification defines two possible protocols
to be used in Messaging Associations, namely Forwards-TCP and TLS. to be used in Messaging Associations, namely Forwards-TCP and TLS.
This information is a main part of the Stack Configuration Data (SCD) This information is a main part of the Stack Configuration Data (SCD)
[1]. This section adds "Forwards-SCTP" as another possible protocol [1]. This section adds Forwards-SCTP (value 3) as another possible
option. In Forwards-SCTP, analog to Forwards-TCP, connections protocol option. In Forwards-SCTP, analog to Forwards-TCP,
between peers are opened in the forwards direction, from the querying connections between peers are opened in the forwards direction, from
node, towards the responder. the querying node, towards the responder.
3.1.2. Protocol-Definition: Forwards-SCTP 3.1.2. Protocol-Definition: Forwards-SCTP
The MA-Protocol-ID "Forwards-SCTP" denotes a basic use of SCTP The MA-Protocol-ID "Forwards-SCTP" denotes a basic use of SCTP
between peers. Support for this protocol is OPTIONAL. If this between peers. Support for this protocol is OPTIONAL. If this
protocol is offered, MA-protocol-options data MUST also be carried in protocol is offered, MA-protocol-options data MUST also be carried in
the SCD object. The MA-protocol-options field formats are: the SCD object. The MA-protocol-options field formats are:
o in a Query: no information apart from the field header. 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
o in a Response: 2-byte port number at which the connection will be
accepted, followed by 2 pad bytes. accepted, followed by 2 pad bytes.
The connection is opened in the forwards direction, from the querying The connection is opened in the forwards direction, from the querying
node towards the responder. The querying node MAY use any source node towards the responder. The querying node MAY use any source
address and source port. The destination for establishing the address and source port. The destination for establishing the
message association MUST be derived from information in the Response: message association MUST be derived from information in the Response:
the address from the interface- address from the Network-Layer- the address from the interface-address in the Network-Layer-
Information object and the port from the SCD object as described Information object and the port from the SCD object as described
above. above.
Associations using Forwards-SCTP can carry messages with the transfer Associations using Forwards-SCTP can carry messages with the transfer
attribute Reliable=True. If an error occurs on the SCTP connection attribute Reliable=True. If an error occurs on the SCTP connection
such as a reset, as can be reported by an SCTP socket API such as a reset, as can be reported by an SCTP socket API
notification[11], GIST MUST report this to NSLPs as discussed in notification [11], GIST MUST report this to NSLPs as discussed in
Section 4.1.2 of [1]. For the multi-homing scenario, when a Section 4.1.2 of [1]. For the multihoming scenario, when a
destination address of a GIST over SCTP peer encounters a change, the destination address of a GIST-over-SCTP peer encounters a change, the
SCTP API will notify GIST about the availability of different SCTP SCTP API will notify GIST about the availability of different SCTP
endpoint addresses and possible change of the primary path. endpoint addresses and the possible change of the primary path.
3.2. Effect on GIST State Maintenance 3.2. Effect on GIST State Maintenance
As SCTP provides additional functionality over TCP, this section As SCTP provides additional functionality over TCP, this section
discusses the implications of using GIST over SCTP on GIST State discusses the implications of using GIST over SCTP on GIST state
Maintenance. maintenance.
While SCTP defines uni-directional streams, for the purpose of this While SCTP defines unidirectional streams, for the purpose of this
document, the concept of a bi-directional stream is used. document, the concept of a bidirectional stream is used.
Implementations MUST establish downstream and upstream (uni- Implementations MUST establish both downstream and upstream
directional) SCTP streams always together and use the same stream (unidirectional) SCTP streams and use the same stream identifier in
identifier in both directions. Thus, the two uni-directional streams both directions. Thus, the two unidirectional streams (in opposite
(in opposite directions) form a bi-directional stream. directions) form a bidirectional stream.
Due to the multi-streaming support of SCTP, it is possible to use Due to the multi-streaming support of SCTP, it is possible to use
different SCTP streams for different resources (e.g., different NSLP different SCTP streams for different resources (e.g., different NSLP
sessions), rather than maintaining all messages along the same sessions), rather than maintaining all messages along the same
transport connection/association in a correlated fashion as TCP transport connection/association in a correlated fashion as TCP
(which imposes strict (re)ordering and reliability per transport (which imposes strict (re)ordering and reliability per transport
level). However, there are limitations to the use of multi- level). However, there are limitations to the use of multi-
streaming. When an SCTP implementation is used for GIST transport, streaming. When an SCTP implementation is used for GIST transport,
all GIST messages for a particular session MUST be sent over the same all GIST messages for a particular session MUST be sent over the same
SCTP stream to assure the NSLP assumption of in-order delivery. SCTP stream to assure the NSLP assumption of in-order delivery.
skipping to change at page 7, line 26 skipping to change at page 6, line 38
policy. policy.
The GIST concept of Messaging Association re-use is not affected by 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 this document or the use of SCTP. All rules defined in the GIST
specification remain valid in the context of GIST over SCTP. specification remain valid in the context of GIST over SCTP.
3.3. PR-SCTP Support 3.3. PR-SCTP Support
A variant of SCTP, PR-SCTP [3] provides a "timed reliability" A variant of SCTP, PR-SCTP [3] provides a "timed reliability"
service, which would be particularly useful for delivering GIST service, which would be particularly useful for delivering GIST
Connection mode messages. It allows the user to specify, on a per Connection mode messages. It allows the user to specify, on a per-
message basis, the rules governing how persistent the transport message basis, the rules governing how persistent the transport
service should be in attempting to send the message to the receiver. service should be in attempting to send the message to the receiver.
Because of the chunk bundling function of SCTP, reliable and Because of the chunk bundling function of SCTP, reliable and
partially reliable messages can be multiplexed over a single PR-SCTP partially reliable messages can be multiplexed over a single PR-SCTP
association. Therefore, an SCTP implementation for GIST transport association. Therefore, an SCTP implementation for GIST transport
SHOULD attempt to establish a PR-SCTP association using "timed SHOULD attempt to establish a PR-SCTP association using "timed
reliability" service instead of a standard SCTP association, if reliability" service instead of a standard SCTP association, if
available, to support more flexible transport features for potential available, to support more flexible transport features for potential
needs of different NSLPs. needs of different NSLPs.
When using a normally reliable session (as opposed to a partially When using a normally reliable session (as opposed to a partially
reliable session), if a node has sent the first transmission before reliable session), if a node has sent the first transmission before
the lifetime expires, then the message MUST be sent as a normal the lifetime expires, then the message MUST be sent as a normal
reliable message. During episodes of congestion this is particularly reliable message. During episodes of congestion, this is
unfortunate, as retransmission wastes bandwidth that could have been particularly unfortunate, as retransmission wastes bandwidth that
used for other (non-lifetime expired) messages. The "timed could have been used for other (non-lifetime expired) messages. The
reliability" service in PR-SCTP eliminates this issue and is hence "timed reliability" service in PR-SCTP eliminates this issue and is
RECOMMENDED to be used for GIST over PR-SCTP. hence RECOMMENDED to be used for GIST over PR-SCTP.
3.4. API between GIST and NSLP 3.4. API between GIST and NSLP
GIST specification defines an abstract API between GIST and NSLPs. The GIST specification defines an abstract API between GIST and
While this document does not change the API itself, the semantics of NSLPs. While this document does not change the API itself, the
some parameters have slightly different interpretation in the context semantics of some parameters have slightly different interpretations
of SCTP. This section only lists those primitives and parameters, in the context of SCTP. This section only lists those primitives and
that need special consideration when used in the context of SCTP. parameters that need special consideration when used in the context
The relevant primitives from [1] are as follows: of SCTP. The relevant primitives from [1] are as follows:
o The Timeout parameter in API "SendMessage": According to [1], this o The Timeout parameter in API "SendMessage": According to [1], this
parameter represents the "length of time GIST should attempt to parameter represents the "length of time GIST should attempt to
send this message before indicating an error." When used with PR- send this message before indicating an error". When used with
SCTP, this parameter is used as the timeout for the "timed PR-SCTP, this parameter is used as the timeout for the "timed
reliability" service of PR-SCTP. reliability" service of PR-SCTP.
o "NetworkNotification": According to [1], this primitive "is passed o "NetworkNotification": According to [1], this primitive "is passed
from GIST to a signalling application. It indicates that a from GIST to a signalling application. It indicates that a
network event of possible interest to the signalling application network event of possible interest to the signalling application
occurred." Here, if SCTP detects a failure of the primary path, occurred". Here, if SCTP detects a failure of the primary path,
GIST SHOULD also indicate this event to the NSLP by calling this GIST SHOULD also indicate this event to the NSLP by calling this
primitive with Network-Notification-Type "Routing Status Change". primitive with Network-Notification-Type "Routing Status Change".
This notification should be done even if SCTP was able to retain This notification should be done even if SCTP was able to retain
an open connection to the peer due to its multi-homing an open connection to the peer due to its multihoming
capabilities. capabilities.
4. Bit-Level Formats 4. Bit-Level Formats
4.1. MA-Protocol-Options 4.1. MA-Protocol-Options
This section provides the bit-level format for the MA-protocol- This section provides the bit-level format for the MA-protocol-
options field that is used for SCTP protocol in the Stack- options field that is used for SCTP protocol in the Stack-
Configuration-Data object of GIST. Configuration-Data object of GIST.
skipping to change at page 8, line 42 skipping to change at page 8, line 7
: SCTP port number | Reserved : : SCTP port number | Reserved :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SCTP port number = Port number at which the responder will accept SCTP port number = Port number at which the responder will accept
SCTP connections SCTP connections
The SCTP port number is only supplied if sent by the responder. The SCTP port number is only supplied if sent by the responder.
5. Application of GIST over SCTP 5. Application of GIST over SCTP
5.1. Multi-homing support of SCTP 5.1. Multihoming Support of SCTP
In general, the multi-homing support of SCTP can be used to improve 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 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 SCTP would be able to deliver NSLP messages between peers even if the
primary path is not working anymore. However, for the Message primary path is not working anymore. However, for the Message
Routing Methods (MRMs) defined in the basic GIST specification such a Routing Methods (MRMs) defined in the basic GIST specification, such
feature is only of limited use. The default MRM is path-coupled, 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 which means that if the primary path is failing for the SCTP
association, it most likely is also for the IP traffic that is association, it most likely is also failing for the IP traffic that
signaled for. Thus, GIST would need to perform a refresh to the NSIS is signaled for. Thus, GIST would need to perform a refresh to the
nodes to the alternative path anyway to cope with the route change. NSIS nodes to the alternative path anyway to cope with the route
When the two endpoints of a multi-homed SCTP association (but none of change. When the two endpoints of a multihomed SCTP association (but
the intermediate nodes between them) support NSIS, GIST over SCTP none of the intermediate nodes between them) support NSIS, GIST over
provides a robust means for GIST to deliver NSLP messages even when SCTP provides a robust means for GIST to deliver NSLP messages even
the primary path fails but at least one alternative path between when the primary path fails but at least one alternative path between
these (NSIS-enabled) endpoints of the multihomed path is available. these (NSIS-enabled) endpoints of the multihomed path is available.
Additionally, the use of the multi-homing support of SCTP provides Additionally, the use of the multihoming support of SCTP provides
GIST and the NSLP with another source to detect route changes. GIST and the NSLP with another source to detect route changes.
Furthermore, for the time between detection of the route change and Furthermore, for the time between detection of the route change and
recovering from it, the alternative path offered by SCTP can be used recovering from it, the alternative path offered by SCTP can be used
by the NSLP to make the transition more smoothly. Finally, future by the NSLP to make the transition more smoothly. Finally, future
MRMs might have different properties and therefore benefit from MRMs might have different properties and therefore benefit from
multi-homing more broadly. multihoming more broadly.
5.2. Streaming support in SCTP 5.2. Streaming Support in SCTP
Streaming support in SCTP is advantageous for GIST. It allows better Streaming support in SCTP is advantageous for GIST. It allows better
parallel processing, in particular by avoiding head of line blocking parallel processing, in particular by avoiding the head-of-line
issue in TCP. Since a same GIST MA may be reused by multiple blocking issue in TCP. Since a single GIST MA may be reused by
sessions, using TCP as transport for GIST signaling messages multiple sessions, using TCP as the transport for GIST signaling
belonging to different sessions may be blocked if another message is messages belonging to different sessions may be blocked if another
dropped. In the case of SCTP, this can be avoided as different message is dropped. In the case of SCTP, this can be avoided, as
sessions having different requirements can belong to different different sessions having different requirements can belong to
streams, thus a message loss or reordering in a stream will only different streams; thus, a message loss or reordering in a stream
affect the delivery of messages within that particular stream, and will only affect the delivery of messages within that particular
not any other streams. stream, and not any other streams.
6. NAT Traversal Issue 6. NAT Traversal Issue
NAT traversal for GIST over SCTP will follow Section 7.2 of [1] and NAT traversal for GIST over SCTP will follow Section 7.2 of [1] and
the GIST extensibility capabilities defined in [12]. This the GIST extensibility capabilities defined in [12]. This
specification does not define NAT traversal procedure for GIST over specification does not define NAT traversal procedures for GIST over
SCTP, although an approach for SCTP NAT traversal is described in SCTP, although an approach for SCTP NAT traversal is described in
[13]. [13].
7. Use of DTLS with GIST 7. Use of DTLS with GIST
This section specifies a new MA-Protocol-ID "DTLS" for the use of This section specifies a new MA-Protocol-ID "DTLS" (value 4) for the
DTLS in GIST, which denotes a basic use of datagram transport layer use of DTLS in GIST, which denotes a basic use of datagram transport
channel security, initially in conjunction with GIST over SCTP. It layer channel security, initially in conjunction with GIST over SCTP.
provides server (i.e., GIST transport receiver) authentication and It provides server (i.e., GIST transport receiver) authentication and
integrity (as long as the NULL cipher suite is not selected during integrity (as long as the NULL ciphersuite is not selected during
cipher suite negotiation), as well as optionally replay protection ciphersuite negotiation), as well as optionally replay protection for
for control packets. The use of DTLS for securing GIST over SCTP control packets. The use of DTLS for securing GIST over SCTP allows
allows GIST to take the advantage of features provided by SCTP and GIST to take the advantage of features provided by SCTP and its
its extensions. The usage of DTLS for GIST over SCTP is similar to extensions. The usage of DTLS for GIST over SCTP is similar to TLS
TLS for GIST as specified in [1], where a stack-proposal containing for GIST as specified in [1], where a stack-proposal containing both
both MA-Protocol-IDs for SCTP and DTLS during the GIST handshake MA-Protocol-IDs for SCTP and DTLS during the GIST handshake phase.
phase.
The usage of DTLS [2] for securing GIST over datagram transport The usage of DTLS [2] for securing GIST over datagram transport
protocols MUST be implemented and SHOULD be used. protocols MUST be implemented and SHOULD be used.
GIST message associations using DTLS may carry messages with transfer GIST message associations using DTLS may carry messages with transfer
attributes requesting confidentiality or integrity protection. The attributes requesting confidentiality or integrity protection. The
specific DTLS version will be negotiated within the DTLS layer specific DTLS version will be negotiated within the DTLS layer
itself, but implementations MUST NOT negotiate to protocol versions itself, but implementations MUST NOT negotiate to protocol versions
prior to DTLS v1.0 and MUST use the highest protocol version prior to DTLS v1.0 and MUST use the highest protocol version
supported by both peers. NULL authentication and integrity ciphers supported by both peers. NULL authentication and integrity ciphers
MUST NOT be negotiated for GIST nodes supporting DTLS. For MUST NOT be negotiated for GIST nodes supporting DTLS. For
confidentiality ciphers, nodes can negotiate the NULL ciphersuites. confidentiality ciphers, nodes can negotiate the NULL ciphersuites.
The same rules for negotiating TLS cipher suites as specified in The same rules for negotiating TLS ciphersuites as specified in
Section 5.7.3 of [1] apply. Section 5.7.3 of [1] apply.
DTLS renegotiation [7] may cause problems for applications such that DTLS renegotiation [7] may cause problems for applications such that
connection security parameters can change without the application connection security parameters can change without the application
knowing it. Hence, it is RECOMMENDED that renegotiation be disabled knowing it. Hence, it is RECOMMENDED that renegotiation be disabled
for GIST over DTLS. for GIST over DTLS.
No MA-protocol-options field is required for DTLS. The configuration No MA-protocol-options field is required for DTLS. The configuration
information for the transport protocol over which DTLS is running information for the transport protocol over which DTLS is running
(e.g. SCTP port number) is provided by the MA-protocol-options for (e.g., SCTP port number) is provided by the MA-protocol-options for
that protocol. that protocol.
8. Security Considerations 8. Security Considerations
The security considerations of [1], [6] and [2] apply. Additionally, The security considerations of [1], [6], and [2] apply.
although [4] does not support replay detection in the DTLS over SCTP, Additionally, although [4] does not support replay detection in DTLS
the SCTP replay protection mechanisms [6] [8] should be able to over SCTP, the SCTP replay protection mechanisms [6] [8] should be
protect NSIS messages transported using GIST over (DTLS over) SCTP able to protect NSIS messages transported using GIST over (DTLS over)
from replay attacks. SCTP from replay attacks.
9. IANA Considerations 9. IANA Considerations
This specification requests the following codepoints (MA-Protocol- According to this specification, IANA has registered the following
IDs) be assigned in a registry created by [1]: codepoints (MA-Protocol-IDs) in a registry created by [1]:
+---------------------+------------------------------------------+ +---------------------+------------------------------------------+
| MA-Protocol-ID | Protocol | | MA-Protocol-ID | Protocol |
+---------------------+------------------------------------------+ +---------------------+------------------------------------------+
| 3 | SCTP opened in the forwards direction | | 3 | SCTP opened in the forwards direction |
| | | | | |
| 4 | DTLS initiated in the forwards direction | | 4 | DTLS initiated in the forwards direction |
+---------------------+------------------------------------------+ +---------------------+------------------------------------------+
Note that MA-Protocol-ID "DTLS" is never used alone but always Note that MA-Protocol-ID "DTLS" is never used alone but always
skipping to change at page 11, line 28 skipping to change at page 10, line 33
The authors would like to thank John Loughney, Jukka Manner, Magnus The authors would like to thank John Loughney, Jukka Manner, Magnus
Westerlund, Sean Turner, Lars Eggert, Jeffrey Hutzelman, Robert Westerlund, Sean Turner, Lars Eggert, Jeffrey Hutzelman, Robert
Hancock, Andrew McDonald, Martin Stiemerling, Fang-Chun Kuo, Jan Hancock, Andrew McDonald, Martin Stiemerling, Fang-Chun Kuo, Jan
Demter, Lauri Liuhto, Michael Tuexen, and Roland Bless for their Demter, Lauri Liuhto, Michael Tuexen, and Roland Bless for their
helpful suggestions. helpful suggestions.
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Schulzrinne, H. and M. Stiemerling, "GIST: General Internet [1] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", draft-ietf-nsis-ntlp-20 (work in Signalling Transport", RFC 5971, October 2010.
progress), June 2009.
[2] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [2] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
[3] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, [3] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad,
"Stream Control Transmission Protocol (SCTP) Partial "Stream Control Transmission Protocol (SCTP) Partial
Reliability Extension", RFC 3758, May 2004. Reliability Extension", RFC 3758, May 2004.
[4] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram [4] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
Transport Layer Security (DTLS) for Stream Control Transmission Transport Layer Security (DTLS) for Stream Control Transmission
Protocol (SCTP)", draft-ietf-tsvwg-dtls-for-sctp-05 (work in Protocol (SCTP)", RFC 6083, January 2011.
progress), March 2010.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[6] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, [6] Stewart, R., "Stream Control Transmission Protocol", RFC 4960,
September 2007. September 2007.
[7] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport [7] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport
Layer Security (TLS) Renegotiation Indication Extension", Layer Security (TLS) Renegotiation Indication Extension",
RFC 5746, February 2010. RFC 5746, February 2010.
skipping to change at page 12, line 24 skipping to change at page 11, line 24
[9] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [9] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[10] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den [10] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,
June 2005. June 2005.
[11] Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. Lei, [11] Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. Lei,
"Sockets API Extensions for Stream Control Transmission "Sockets API Extensions for Stream Control Transmission
Protocol (SCTP)", draft-ietf-tsvwg-sctpsocket-22 (work in Protocol (SCTP)", Work in Progress, January 2011.
progress), March 2010.
[12] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and [12] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and
Extending the NSIS Protocol Family", draft-ietf-nsis-ext-07 Extending the NSIS Protocol Family", RFC 5978, October 2010.
(work in progress), April 2010.
[13] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control [13] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control
Transmission Protocol (SCTP) Network Address Translation", Transmission Protocol (SCTP) Network Address Translation", Work
draft-ietf-behave-sctpnat-02 (work in progress), December 2009. in Progress, December 2010.
Authors' Addresses Authors' Addresses
Xiaoming Fu Xiaoming Fu
University of Goettingen University of Goettingen
Institute of Computer Science Institute of Computer Science
Goldschmidtstr. 7 Goldschmidtstr. 7
Goettingen 37077 Goettingen 37077
Germany Germany
Email: fu@cs.uni-goettingen.de EMail: fu@cs.uni-goettingen.de
Christian Dickmann Christian Dickmann
University of Goettingen University of Goettingen
Institute of Computer Science Institute of Computer Science
Goldschmidtstr. 7 Goldschmidtstr. 7
Goettingen 37077 Goettingen 37077
Germany Germany
Email: mail@christian-dickmann.de EMail: mail@christian-dickmann.de
Jon Crowcroft Jon Crowcroft
University of Cambridge University of Cambridge
Computer Laboratory Computer Laboratory
William Gates Building William Gates Building
15 JJ Thomson Avenue 15 JJ Thomson Avenue
Cambridge CB3 0FD Cambridge CB3 0FD
UK UK
Email: jon.crowcroft@cl.cam.ac.uk EMail: jon.crowcroft@cl.cam.ac.uk
 End of changes. 69 change blocks. 
176 lines changed or deleted 186 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/