draft-ietf-nsis-ntlp-sctp-12.txt   draft-ietf-nsis-ntlp-sctp-13.txt 
Network Working Group X. Fu Network Working Group X. Fu
Internet-Draft C. Dickmann Internet-Draft C. Dickmann
Intended status: Experimental University of Goettingen Intended status: Experimental University of Goettingen
Expires: November 18, 2010 J. Crowcroft Expires: December 26, 2010 J. Crowcroft
University of Cambridge University of Cambridge
May 17, 2010 June 24, 2010
General Internet Signaling Transport (GIST) over Stream Control General Internet Signaling Transport (GIST) over Stream Control
Transmission Protocol (SCTP) and Datagram Transport Layer Security Transmission Protocol (SCTP) and Datagram Transport Layer Security
(DTLS) (DTLS)
draft-ietf-nsis-ntlp-sctp-12.txt draft-ietf-nsis-ntlp-sctp-13.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). The use of SCTP can take advantage of Layer Security (DTLS). It discusses how the use of SCTP can take
features provided by SCTP, namely streaming-based transport, support advantage of features provided by SCTP, as well as how to establish
of multiple streams to avoid head of line blocking, the support of GIST security over datagram transport protocols with DTLS.
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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 18, 2010. This Internet-Draft will expire on December 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 3, line 28 skipping to change at page 3, line 28
5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 8 5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 8
5.1. Multi-homing support of SCTP . . . . . . . . . . . . . . . 8 5.1. Multi-homing support of SCTP . . . . . . . . . . . . . . . 8
5.2. Streaming support in SCTP . . . . . . . . . . . . . . . . 9 5.2. Streaming support in SCTP . . . . . . . . . . . . . . . . 9
6. NAT Traversal Issue . . . . . . . . . . . . . . . . . . . . . 9 6. NAT Traversal Issue . . . . . . . . . . . . . . . . . . . . . 9
7. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 9 7. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 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] over the Stream Control Transmission Protocol (SCTP) [3]. (DTLS) [2] over the Stream Control Transmission Protocol (SCTP) [3].
GIST, in its initial specification for connection mode operation, GIST, in its initial specification for connection mode operation,
runs on top of a byte-stream oriented transport protocol providing a runs on top of a byte-stream oriented transport protocol providing a
reliable, in-sequence delivery, i.e., using the Transmission Control reliable, in-sequence delivery, i.e., using the Transmission Control
Protocol (TCP) [7] for signaling message transport. However, some Protocol (TCP) [9] for signaling message transport. However, some
Next Steps in Signaling (NSIS) Signaling Layer Protocol (NSLP) [8] Next Steps in Signaling (NSIS) Signaling Layer Protocol (NSLP) [10]
context information has a definite lifetime, therefore, the GIST context information has a definite lifetime, therefore, the GIST
transport protocol could benefit from flexible retransmission, so transport protocol could benefit from flexible retransmission, so
stale NSLP messages that are held up by congestion can be dropped. stale NSLP messages that are held up by congestion can be dropped.
Together with the head-of-line blocking and multihoming issues with Together with the head-of-line blocking and multihoming issues with
TCP, these considerations argue that implementations of GIST should TCP, these considerations argue that implementations of GIST should
support SCTP as an optional transport protocol for GIST. Like TCP, support SCTP as an optional transport protocol for GIST. Like TCP,
SCTP supports reliability, congestion control and fragmentation. SCTP supports reliability, congestion control and fragmentation.
Unlike TCP, SCTP provides a number of functions that are desirable Unlike TCP, SCTP provides a number of functions that are desirable
for signaling transport, such as multiple streams and multiple IP for signaling transport, such as multiple streams and multiple IP
addresses for path failure recovery. Furthermore, SCTP offers an addresses for path failure recovery. Furthermore, SCTP offers an
advantage of message-oriented transport instead of using the byte advantage of message-oriented transport instead of using the byte
stream oriented TCP where one has to provide its own framing stream oriented TCP where one has to provide its own framing
mechanisms. In addition, its Partial Reliability extension (PR-SCTP) mechanisms. In addition, its Partial Reliability extension (PR-SCTP)
[4] supports partial retransmission based on a programmable [4] supports partial retransmission based on a programmable
retransmission timer. Furthermore, DTLS provides a viable solution retransmission timer. Furthermore, DTLS provides a viable solution
for securing SCTP [5], which allows SCTP to use almost all its for securing SCTP [5], which allows SCTP to use almost all its
transport features and its extensions. transport features and its extensions.
This document defines the use of SCTP as a transport protocol and the This document defines the use of SCTP as the underlying transport
use of DTLS as a security mechanism for GIST Messaging Associations protocol for GIST and the use of DTLS as a security mechanism for
and discusses the implications on GIST state maintenance and API protecting GIST Messaging Associations and discusses the implications
between GIST and NSLPs. Furthermore, this document describes how on GIST state maintenance and API between GIST and NSLPs.
GIST should be interfaced to SCTP and used by NSLPs in order to Furthermore, this document describes how GIST is transported over
exploit the additional capabilities offered by SCTP to deliver GIST SCTP and used by NSLPs in order to exploit the additional
C-mode messages more effectively. More specifically: 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 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. o How to take advantage of the multi-homing support of SCTP.
The methods of using an unchanged SCTP with GIST described in this GIST over SCTP described in this document do not require any changes
document do not require any changes to the high level operation and to the high level operation and structure of GIST. However, adding
structure of GIST. Addition of new transport options requires new transport options requires additional interface code and
additional interface code and configuration support to allow configuration support to allow applications to exploit the additional
applications to exploit the additional transport when appropriate. transport when appropriate. In addition, SCTP implementions to
In addition, SCTP implementions to transport GIST MUST support the transport GIST MUST support the optional feature of fragmentation of
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 [6]. Other document are to be interpreted as described in [6]. Other
terminologies and abbreviations used in this document are taken from terminologies and abbreviations used in this document are taken from
skipping to change at page 5, line 26 skipping to change at page 5, line 26
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 o Messaging Association (MA) - a single connection between two
explicitly identified GIST adjacent peers, i.e. between a given explicitly identified GIST adjacent peers, i.e. between a given
signalling source and destination address. A messaging signalling source and destination address. A messaging
association may use a transport protocol; if security protection association may use a transport protocol; if security protection
is required, it may use a specific network layer security is required, it may use a specific network layer security
association, or use a transport layer security association association, or use a transport layer security association
internally. A messaging association is bidirectional. A internally. A messaging association is bi-directional; signaling
messaging association is bi-directional: signaling messages can be messages can be sent over it in either direction, referring to
sent over it in either direction, referring to flows of either flows of either direction.
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.
skipping to change at page 6, line 16 skipping to change at page 6, line 16
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" as another possible protocol
option. In Forwards-SCTP, analog to Forwards-TCP, connections option. In Forwards-SCTP, analog to Forwards-TCP, connections
between peers are opened in the forwards direction, from the querying between peers are opened in the forwards direction, from the querying
node, towards the responder. node, towards the responder.
3.1.2. Protocol-Definition: Forwards-SCTP 3.1.2. Protocol-Definition: Forwards-SCTP
This 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 from 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[9], 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 multi-homing 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 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.
skipping to change at page 7, line 25 skipping to change at page 7, line 25
Multiple sessions MAY share the same SCTP stream based on local Multiple sessions MAY share the same SCTP stream based on local
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 [4] provides a "timed reliability" A variant of SCTP, PR-SCTP [4] provides a "timed reliability"
service, which would be particular 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.
In a standard SCTP, instead, if a node has sent the first When using a normally reliable session (as opposed to a partially
transmission before the lifetime expires, then the message MUST be reliable session), if a node has sent the first transmission before
sent as a normal reliable message. During episodes of congestion the lifetime expires, then the message MUST be sent as a normal
this is particularly unfortunate, as retransmission wastes bandwidth reliable message. During episodes of congestion this is particularly
that could have been used for other (non-lifetime expired) messages. unfortunate, as retransmission wastes bandwidth that could have been
The "timed reliability" service in PR-SCTP eliminates this issue and used for other (non-lifetime expired) messages. The "timed
is hence RECOMMENDED to be used for GIST over PR-SCTP. 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 3.4. API between GIST and NSLP
GIST specification defines an abstract API between GIST and NSLPs. GIST specification defines an abstract API between GIST and NSLPs.
While this document does not change the API itself, the semantics of While this document does not change the API itself, the semantics of
some parameters have slightly different interpretation in the context some parameters have slightly different interpretation in the context
of SCTP. This section only lists those primitives and parameters, of SCTP. This section only lists those primitives and parameters,
that need special consideration when used in the context of SCTP. that need special consideration when used in the context of SCTP.
The relevant primitives from [1] are as follows: 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 PR-
SCTP, this parameter is used as the timeout for the "timed 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,
skipping to change at page 9, line 38 skipping to change at page 9, line 39
belonging to different sessions may be blocked if another message is belonging to different sessions may be blocked if another message is
dropped. In the case of SCTP, this can be avoided as different dropped. In the case of SCTP, this can be avoided as different
sessions having different requirements can belong to different sessions having different requirements can belong to different
streams, thus a message loss or reordering in a stream will only streams, thus a message loss or reordering in a stream will only
affect the delivery of messages within that particular stream, and affect the delivery of messages within that particular stream, and
not any other streams. 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 [10]. 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 procedure 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
[11]. [13].
7. Use of DTLS with GIST 7. Use of DTLS with GIST
This section specifies a new "MA-Protocol-ID" for the use of DTLS in This section specifies a new MA-Protocol-ID "DTLS" for the use of
GIST, which denotes a basic use of datagram transport layer channel DTLS in GIST, which denotes a basic use of datagram transport layer
security, initially in conjunction with GIST over SCTP. It provides channel security, initially in conjunction with GIST over SCTP. It
authentication, integrity and optionally replay protection for provides server (i.e., GIST transport receiver) authentication and
control packets. The use of DTLS for securing GIST over SCTP allows integrity (as long as the NULL cipher suite is not selected during
GIST to take the advantage of features provided by SCTP and its cipher suite negotiation), as well as optionally replay protection
extensions. Note replay protection is not available for DTLS over for control packets. The use of DTLS for securing GIST over SCTP
SCTP [5]. The usage of DTLS for GIST over SCTP is similar to TLS for allows GIST to take the advantage of features provided by SCTP and
GIST as specified in [1], where a stack-proposal containing both MA- its extensions. The usage of DTLS for GIST over SCTP is similar to
Protocol-IDs for SCTP and DTLS during the GIST handshake phase. 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 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. GIST nodes supporting DTLS MUST be able to 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 DTLS NULL and block ciphers and SHOULD be able to
negotiate the new cipher suites. They MAY negotiate any mutually negotiate the new cipher suites. They MAY negotiate any mutually
acceptable ciphersuite that provides authentication, integrity, and acceptable ciphersuite that provides authentication, integrity, and
confidentiality. The same rules for negotiating TLS cipher suites as confidentiality. The same rules for negotiating TLS cipher suites as
specified in Section 5.7.3 of [1] apply. 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 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], [3] and [2] apply. Following The security considerations of [1], [3] and [2] apply. Additionally,
[5], replay detection of DTLS over SCTP is not supported. although [5] does not support replay detection in the DTLS over SCTP,
the SCTP replay protection mechanisms [3] [8] should be able to
The usage of DTLS [2] for securing GIST over datagram transport protect NSIS messages transported using GIST over (DTLS over) SCTP
protocols MUST be implemented and SHOULD be used. An implementation from replay attacks.
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.
9. IANA Considerations 9. IANA Considerations
This specification requests the following codepoints (MA-Protocol- This specification requests the following codepoints (MA-Protocol-
IDs) be assigned in a registry created by [1]: IDs) be assigned 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 4 is never used alone but always coupled Note that MA-Protocol-ID "DTLS" is never used alone but always
with a transport protocol in the stack proposal. coupled with a transport protocol specified in the stack proposal.
10. Acknowledgments 10. Acknowledgments
The authors would like to thank John Loughney, Jukka Manner, Magnus The authors would like to thank John Loughney, Jukka Manner, Magnus
Westerlund, Robert Hancock, Andrew McDonald, Martin Stiemerling, Westerlund, Sean Turner, Lars Eggert, Jeffrey Hutzelman, Robert
Fang-Chun Kuo, Jan Demter, Lauri Liuhto, Michael Tuexen, and Roland Hancock, Andrew McDonald, Martin Stiemerling, Fang-Chun Kuo, Jan
Bless for their helpful suggestions. Demter, Lauri Liuhto, Michael Tuexen, and Roland Bless for their
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 M. Stiemerling, "GIST: General Internet
Signalling Transport", draft-ietf-nsis-ntlp-20 (work in Signalling Transport", draft-ietf-nsis-ntlp-20 (work in
progress), June 2009. progress), June 2009.
[2] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [2] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
skipping to change at page 11, line 41 skipping to change at page 12, line 5
Reliability Extension", RFC 3758, May 2004. Reliability Extension", RFC 3758, May 2004.
[5] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram [5] 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)", draft-ietf-tsvwg-dtls-for-sctp-05 (work in
progress), March 2010. progress), March 2010.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement [6] 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.
[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 11.2. Informative References
[7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [9] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[8] 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.
[9] 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)", draft-ietf-tsvwg-sctpsocket-22 (work in
progress), March 2010. progress), March 2010.
[10] 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", draft-ietf-nsis-ext-07
(work in progress), April 2010. (work in progress), April 2010.
[11] 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",
draft-ietf-behave-sctpnat-02 (work in progress), December 2009. draft-ietf-behave-sctpnat-02 (work in progress), December 2009.
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
 End of changes. 28 change blocks. 
73 lines changed or deleted 85 lines changed or added

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