draft-ietf-nsis-ntlp-sctp-10.txt   draft-ietf-nsis-ntlp-sctp-11.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: October 22, 2010 J. Crowcroft Expires: October 30, 2010 J. Crowcroft
University of Cambridge University of Cambridge
April 20, 2010 April 28, 2010
General Internet Signaling Transport (GIST) over SCTP and Datagram TLS General Internet Signaling Transport (GIST) over Stream Control
draft-ietf-nsis-ntlp-sctp-10.txt Transmission Protocol (SCTP) and Datagram Transport Layer Security
(DTLS)
draft-ietf-nsis-ntlp-sctp-11.txt
Abstract Abstract
The General Internet Signaling Transport (GIST) protocol currently The General Internet Signaling Transport (GIST) protocol currently
uses TCP or TLS over TCP for connection mode operation. This uses TCP or Transport Layer Security (TLS) over TCP for connection
document describes the usage of GIST over the Stream Control mode operation. This document describes the usage of GIST over the
Transmission Protocol (SCTP) and Datagram Transport Layer Security Stream Control Transmission Protocol (SCTP) and Datagram Transport
(DTLS). The use of SCTP can take advantage of features provided by Layer Security (DTLS). The use of SCTP can take advantage of
SCTP, namely streaming-based transport, support of multiple streams features provided by SCTP, namely streaming-based transport, support
to avoid head of line blocking, the support of multi-homing to of multiple streams to avoid head of line blocking, the support of
provide network level fault tolerance, as well as partial reliability multi-homing to provide network level fault tolerance, as well as
extension for partially reliable data transmission. This document partial reliability extension for partially reliable data
also specifies how to establish GIST security over datagram transport transmission. This document also specifies how to establish GIST
protocols using an extension to DTLS. security over datagram transport protocols using an extension to
DTLS.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF 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 October 22, 2010. This Internet-Draft will expire on October 30, 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 2, line 20 skipping to change at page 2, line 23
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. GIST Over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 4 3. GIST Over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Message Association Setup . . . . . . . . . . . . . . . . 4 3.1. Message Association Setup . . . . . . . . . . . . . . . . 4
3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 5 3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 4
3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 5 3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 5
3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 6 3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 5
3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 6 3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 6
4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 7 4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 6
4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 7 4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 6
5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 7 5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 7
5.1. Multi-homing support of SCTP . . . . . . . . . . . . . . . 7 5.1. Multi-homing support of SCTP . . . . . . . . . . . . . . . 7
5.2. Streaming support in SCTP . . . . . . . . . . . . . . . . 8 5.2. Streaming support in SCTP . . . . . . . . . . . . . . . . 7
6. NAT Traversal Issue . . . . . . . . . . . . . . . . . . . . . 8 6. NAT Traversal Issue . . . . . . . . . . . . . . . . . . . . . 8
7. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 8 7. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
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] over the Stream Control Transmission Transport (GIST) protocol [1] and Datagram Transport Layer Security
Protocol (SCTP) [2]. (DTLS) over the Stream Control Transmission Protocol (SCTP) [2].
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) [7] for signaling message transport. However, some
NSIS Signaling Layer Protocol (NSLP) [8] context information has a Next Steps in Signaling (NSIS) Signaling Layer Protocol (NSLP) [8]
definite lifetime, therefore, the GIST transport protocol could context information has a definite lifetime, therefore, the GIST
benefit from flexible retransmission, so stale NSLP messages that are transport protocol could benefit from flexible retransmission, so
held up by congestion can be dropped. Together with the head-of-line stale NSLP messages that are held up by congestion can be dropped.
blocking and multihoming issues with TCP, these considerations argue Together with the head-of-line blocking and multihoming issues with
that implementations of GIST should support the Stream Control TCP, these considerations argue that implementations of GIST should
Transport Protocol (SCTP)[2] as an optional transport protocol for support the Stream Control Transport Protocol (SCTP)[2] as an
GIST. Like TCP, SCTP supports reliability, congestion control and optional transport protocol for GIST. Like TCP, SCTP supports
fragmentation. Unlike TCP, SCTP provides a number of functions that reliability, congestion control and fragmentation. Unlike TCP, SCTP
are desirable for signaling transport, such as multiple streams and provides a number of functions that are desirable for signaling
multiple IP addresses for path failure recovery. Furthermore, SCTP transport, such as multiple streams and multiple IP addresses for
offers an advantage of message-oriented transport instead of using path failure recovery. Furthermore, SCTP offers an advantage of
the byte stream oriented TCP where one has to provide its own framing message-oriented transport instead of using the byte stream oriented
mechanisms. In addition, its Partial Reliability extension (PR-SCTP) TCP where one has to provide its own framing mechanisms. In
[3] supports partial retransmission based on a programmable addition, its Partial Reliability extension (PR-SCTP) [3] supports
retransmission timer. Furthermore, Datagram Transport Layer Security partial retransmission based on a programmable retransmission timer.
(DTLS) [4] provides a viable solution for securing SCTP [5], which Furthermore, Datagram Transport Layer Security (DTLS) [4] provides a
allows SCTP to use almost all its transport features and its viable solution for securing SCTP [5], which allows SCTP to use
extensions. almost all its 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 a transport protocol and the
use of DTLS as a security mechanism for GIST Messaging Associations use of DTLS as a security mechanism for GIST Messaging Associations
and discusses the implications on GIST State Maintenance and API and discusses the implications on GIST state maintenance and API
between GIST and NSLPs. Furthermore, this document descibes how GIST between GIST and NSLPs. Furthermore, this document describes how
should be interfaced to SCTP and used by NSLPs in order to exploit GIST should be interfaced to SCTP and used by NSLPs in order to
the additional capabilties offered by SCTP to deliver GIST C-mode exploit the additional capabilities offered by SCTP to deliver GIST
messages more effectively. More specifically: 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 The methods of using an unchanged SCTP with GIST described in this
document do not require any changes to the high level operation and document do not require any changes to the high level operation and
structure of GIST. Addition of new transport options requires structure of GIST. Addition of new transport options requires
additional interface code and configuration support to allow additional interface code and configuration support to allow
applications to exploit the additional transport when appropriate. applications to exploit the additional transport when appropriate.
In addition, SCTP implementations MUST support the optional feature In addition, SCTP over GIST implementations MUST support the optional
of fragmentation of SCTP user messages. feature of fragmentation of 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
related specifications (e.g., [1] and [2]) as follows: related specifications (e.g., [1] and [2]).
o SCTP - Stream Control Transmission Protocol
o PR-SCTP - SCTP Partial Reliability Extension
o MRM - Message Routing Method
o MRI - Message Routing Information
o MRS - Message Routing State
o SCD - Stack Configuration Data
o MA - A GIST Messaging Association is a single connection between
two explicitly identified GIST adjacent peers on the data path. A
messaging association may use a specific transport protocol and
known ports. If security protection is required, it may use a
specific network layer security association, or use a transport
layer security association internally. A messaging association is
bidirectional; signaling messages can be sent over it in either
direction, and can refer to flows of either direction.
o SCTP Association - A protocol relationship between SCTP endpoints,
composed of the two SCTP endpoints and protocol state information.
An association can be uniquely identified by the set of transport
addresses used by the endpoints in the association. All transport
addresses used by an SCTP endpoint must use the same port number,
but can use multiple IP addresses. A transport address used by an
SCTP endpoint must not be used by another SCTP endpoint. In other
words, a transport address is unique to an SCTP endpoint. Two
SCTP endpoints MUST NOT have more than one SCTP association
between them at any given time [2].
o Stream - A sequence of user messages that are to be delivered to
the upper-layer protocol in order with respect to other messages
within the same stream.
3. GIST Over SCTP 3. GIST Over SCTP
This section defines a new MA-Protocol-ID type, "Forwards-SCTP", for
using SCTP as GIST transport protocol.
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 are main part of the Stack Configuration Data (SCD)
These information are main part of the Stack Configuration Data [1]. [1]. This document adds Forwards-SCTP and DTLS as another two
This document adds Forwards-SCTP as another possible protocol option. possible protocol options. In Forwards-SCTP, analog to Forwards-TCP,
In Forwards-SCTP, analog to Forwards-TCP, connections between peers connections between peers are opened in the forwards direction, from
are opened in the forwards direction, from the querying node, towards the querying node, towards the responder.
the responder.
A new MA-Protocol-ID type, "Forwards-SCTP", is defined in this
document for using SCTP as GIST transport protocol. A formal
definition of Forwards-SCTP is given in the following section.
3.1.2. Protocol-Definition: Forwards-SCTP 3.1.2. Protocol-Definition: Forwards-SCTP
This MA-Protocol-ID denotes a basic use of SCTP between peers. This MA-Protocol-ID "Forwards-SCTP" denotes a basic use of SCTP
Support for this protocol is OPTIONAL. If this protocol is offered, between peers. Support for this protocol is OPTIONAL. If this
MA-protocol-options data MUST also be carried in the SCD object. The protocol is offered, MA-protocol-options data MUST also be carried in
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
skipping to change at page 5, line 44 skipping to change at page 5, line 16
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[9], 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
This document defines the use of SCTP as a transport protocol for As SCTP provides additional functionality over TCP, this section
GIST Messaging Associations. As SCTP provides additional discusses the implications of using GIST over SCTP on GIST State
functionality over TCP, this section dicusses the implications of Maintenance.
using GIST over SCTP on GIST State Maintenance.
While SCTP defines uni-directional streams, for the purpose of this While SCTP defines uni-directional streams, for the purpose of this
document, the concept of a bi-directional stream is used. document, the concept of a bi-directional stream is used.
Implementations MUST establish downstream and upstream (uni- Implementations MUST establish downstream and upstream (uni-
directional) SCTP streams always together and use the same stream directional) SCTP streams always together and use the same stream
identifier in both directions. Thus, the two uni-directional streams identifier in both directions. Thus, the two uni-directional streams
(in opposite directions) form a bi-directional stream. (in opposite directions) form a bi-directional 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
skipping to change at page 8, line 7 skipping to change at page 7, line 28
5.1. Multi-homing support of SCTP 5.1. Multi-homing support of SCTP
In general, the multi-homing support of SCTP can be used to improve 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 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 a
feature is only of limited use. The default MRM is path-coupled, 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 for the IP traffic that is
signaled for. Thus, GIST would need to perform a refresh anyway to signaled for. Thus, GIST would need to perform a refresh to the NSIS
cope with the route change. When the endpoints of the multi-homed nodes to the alternative path anyway to cope with the route change.
paths (instead of the nodes between them) support NSIS, GIST over When the two endpoints of a multi-homed SCTP association (but none of
SCTP provides a robust means for GIST to deliver NSLP messages even the intermediate nodes between them) support NSIS, GIST over SCTP
when some paths fail but at least one path is available. 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 Additionally, the use of the multi-homing 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. multi-homing more broadly.
5.2. Streaming support in SCTP 5.2. Streaming support in SCTP
skipping to change at page 8, line 43 skipping to change at page 8, line 19
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 [10]. 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]. [11].
7. Use of DTLS with GIST 7. Use of DTLS with GIST
The MA-Protocol-ID for DTLS denotes a basic use of datagram transport This section specifies a new "MA-Protocol-ID" for the use of DTLS in
layer channel security, initially in conjunction with SCTP. It GIST, which denotes a basic use of datagram transport layer channel
provides authentication, integrity and optionally replay protection security, initially in conjunction with SCTP over GIST. It provides
for control packets. The use of DTLS for securing GIST over SCTP authentication, integrity and optionally replay protection for
allows GIST to take the advantage of features provided by SCTP and control packets. The use of DTLS for securing GIST over SCTP allows
its extensions. Note replay protection is not available for DTLS GIST to take the advantage of features provided by SCTP and its
over SCTP [5]. The usage of DTLS for GIST over SCTP is similar to extensions. Note replay protection is not available for DTLS over
TLS for GIST as specified in [1], where a stack-proposal containing SCTP [5]. The usage of DTLS for GIST over SCTP is similar to TLS for
both MA-Protocol-IDs for SCTP and DTLS during the GIST handshake GIST as specified in [1], where a stack-proposal containing both MA-
phase. Protocol-IDs for SCTP and DTLS during the GIST handshake phase.
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 cipher ciphers and SHOULD be able negotiate the DTLS NULL and block ciphers and SHOULD be able to
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.
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
skipping to change at page 9, line 37 skipping to change at page 9, line 17
The security considerations of [1], [2] and [4] apply. Following The security considerations of [1], [2] and [4] apply. Following
[5], replay detection of DTLS over SCTP is not supported. [5], replay detection of DTLS over SCTP is not supported.
The usage of DTLS [4] for securing GIST over datagram transport The usage of DTLS [4] for securing GIST over datagram transport
protocols MUST be implemented and SHOULD be used. An implementation 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 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. security, when DTLS is not available between two GIST peers.
9. IANA Considerations 9. IANA Considerations
This specification extends [1] by introducing two additional MA- This specification requests the following codepoints (MA-Protocol-
Protocol-IDs: 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 4 is never used alone but always coupled
 End of changes. 25 change blocks. 
118 lines changed or deleted 93 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/