draft-ietf-nsis-ntlp-sctp-11.txt   draft-ietf-nsis-ntlp-sctp-12.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 30, 2010 J. Crowcroft Expires: November 18, 2010 J. Crowcroft
University of Cambridge University of Cambridge
April 28, 2010 May 17, 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-11.txt draft-ietf-nsis-ntlp-sctp-12.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). The use of SCTP can take advantage of
features provided by SCTP, namely streaming-based transport, support features provided by SCTP, namely streaming-based transport, support
of multiple streams to avoid head of line blocking, the support of of multiple streams to avoid head of line blocking, the support of
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 30, 2010. This Internet-Draft will expire on November 18, 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
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
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 5
3. GIST Over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 4 3. GIST Over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Message Association Setup . . . . . . . . . . . . . . . . 4 3.1. Message Association Setup . . . . . . . . . . . . . . . . 5
3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 4 3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 6
3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 5 3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 6
3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 5 3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 7
3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 6 3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 7
4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 6 4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 8
4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 6 4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 8
5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 7 5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 8
5.1. Multi-homing support of SCTP . . . . . . . . . . . . . . . 7 5.1. Multi-homing support of SCTP . . . . . . . . . . . . . . . 8
5.2. Streaming support in SCTP . . . . . . . . . . . . . . . . 7 5.2. Streaming support in SCTP . . . . . . . . . . . . . . . . 9
6. NAT Traversal Issue . . . . . . . . . . . . . . . . . . . . . 8 6. NAT Traversal Issue . . . . . . . . . . . . . . . . . . . . . 9
7. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 8 7. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 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) over the Stream Control Transmission Protocol (SCTP) [2]. (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) [7] 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) [8]
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 the Stream Control Transport Protocol (SCTP)[2] as an support SCTP as an optional transport protocol for GIST. Like TCP,
optional transport protocol for GIST. Like TCP, SCTP supports SCTP supports reliability, congestion control and fragmentation.
reliability, congestion control and fragmentation. Unlike TCP, SCTP Unlike TCP, SCTP provides a number of functions that are desirable
provides a number of functions that are desirable for signaling for signaling transport, such as multiple streams and multiple IP
transport, such as multiple streams and multiple IP addresses for addresses for path failure recovery. Furthermore, SCTP offers an
path failure recovery. Furthermore, SCTP offers an advantage of advantage of message-oriented transport instead of using the byte
message-oriented transport instead of using the byte stream oriented stream oriented TCP where one has to provide its own framing
TCP where one has to provide its own framing mechanisms. In mechanisms. In addition, its Partial Reliability extension (PR-SCTP)
addition, its Partial Reliability extension (PR-SCTP) [3] supports [4] supports partial retransmission based on a programmable
partial retransmission based on a programmable retransmission timer. retransmission timer. Furthermore, DTLS provides a viable solution
Furthermore, Datagram Transport Layer Security (DTLS) [4] provides a for securing SCTP [5], which allows SCTP to use almost all its
viable solution for securing SCTP [5], which allows SCTP to use transport features and its 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 describes how between GIST and NSLPs. Furthermore, this document describes how
GIST should be interfaced to SCTP and used by NSLPs in order to GIST should be interfaced to SCTP and used by NSLPs in order to
exploit the additional capabilities offered by SCTP to deliver GIST exploit the additional capabilities offered by SCTP to deliver GIST
C-mode 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 over GIST implementations MUST support the optional In addition, SCTP implementions to transport GIST MUST support the
feature of fragmentation of SCTP user messages. optional 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]). related specifications ([1], [2], [3], [4]):
o SCTP - Stream Control Transmission Protocol
o PR-SCTP - SCTP Partial Reliability Extension
o MRM - Message Routing Method
o MRI - Message Routing Information
o SCD - Stack-Configuration-Data
o Messaging Association (MA) - a single connection between two
explicitly identified GIST adjacent peers, i.e. between a given
signalling source and destination address. A messaging
association may use a transport protocol; if security protection
is required, it may use a specific network layer security
association, or use a transport layer security association
internally. A messaging association is bidirectional. A
messaging association is bi-directional: signaling messages can be
sent over it in either direction, referring to flows of either
direction.
o SCTP Association - A protocol relationship between SCTP endpoints,
composed of the two SCTP endpoints and protocol state information.
An association can be uniquely identified by the transport
addresses used by the endpoints in the association. Two SCTP
endpoints MUST NOT have more than one SCTP association between
them at any given time.
o Stream - A unidirectional logical channel established from one to
another associated SCTP endpoint, within which all user messages
are delivered in sequence except for those submitted to the
unordered delivery service.
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. using SCTP as GIST transport protocol. The use of DTLS in GIST 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 are main part of the Stack Configuration Data (SCD) This information is a main part of the Stack Configuration Data (SCD)
[1]. This document adds Forwards-SCTP and DTLS as another two [1]. This section adds "Forwards-SCTP" as another possible protocol
possible protocol options. In Forwards-SCTP, analog to Forwards-TCP, option. In Forwards-SCTP, analog to Forwards-TCP, connections
connections between peers are opened in the forwards direction, from between peers are opened in the forwards direction, from the querying
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 This 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.
skipping to change at page 5, line 33 skipping to change at page 7, line 12
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
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. All GIST messages for a particular session MUST be sent streaming. When an SCTP implementation is used for GIST transport,
over the same SCTP stream to assure the NSLP assumption of in-order all GIST messages for a particular session MUST be sent over the same
delivery. Multiple sessions MAY share the same SCTP stream based on SCTP stream to assure the NSLP assumption of in-order delivery.
local policy. Multiple sessions MAY share the same SCTP stream based on local
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 [4] provides a "timed reliability"
service, which would be particular useful for delivering GIST service, which would be particular 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, a GIST over SCTP implementation SHOULD association. Therefore, an SCTP implementation for GIST transport
attempt to establish a PR-SCTP association using "timed reliability" SHOULD attempt to establish a PR-SCTP association using "timed
service instead of a standard SCTP association, if available, to reliability" service instead of a standard SCTP association, if
support more flexible transport features for potential needs of available, to support more flexible transport features for potential
different NSLPs. needs of different NSLPs.
In a standard SCTP, instead, if a node has sent the first In a standard SCTP, instead, if a node has sent the first
transmission before the lifetime expires, then the message MUST be transmission before the lifetime expires, then the message MUST be
sent as a normal reliable message. During episodes of congestion sent as a normal reliable message. During episodes of congestion
this is particularly unfortunate, as retransmission wastes bandwidth this is particularly unfortunate, as retransmission wastes bandwidth
that could have been used for other (non-lifetime expired) messages. that could have been used for other (non-lifetime expired) messages.
The "timed reliability" service in PR-SCTP eliminates this issue and The "timed reliability" service in PR-SCTP eliminates this issue and
is hence RECOMMENDED to be used for GIST over PR-SCTP. 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
skipping to change at page 8, line 21 skipping to change at page 9, line 47
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
This section specifies a new "MA-Protocol-ID" for the use of DTLS in This section specifies a new "MA-Protocol-ID" for the use of DTLS in
GIST, which denotes a basic use of datagram transport layer channel GIST, which denotes a basic use of datagram transport layer channel
security, initially in conjunction with SCTP over GIST. It provides security, initially in conjunction with GIST over SCTP. It provides
authentication, integrity and optionally replay protection for authentication, integrity and optionally replay protection for
control packets. The use of DTLS for securing GIST over SCTP allows control packets. The use of DTLS for securing GIST over SCTP allows
GIST to take the advantage of features provided by SCTP and its GIST to take the advantage of features provided by SCTP and its
extensions. Note replay protection is not available for DTLS over extensions. Note replay protection is not available for DTLS over
SCTP [5]. The usage of DTLS for GIST over SCTP is similar to TLS for SCTP [5]. The usage of DTLS for GIST over SCTP is similar to TLS for
GIST as specified in [1], where a stack-proposal containing both MA- GIST as specified in [1], where a stack-proposal containing both MA-
Protocol-IDs for SCTP and DTLS during the GIST handshake 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
skipping to change at page 9, line 7 skipping to change at page 10, line 29
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
The security considerations of [1], [2] and [4] apply. Following The security considerations of [1], [3] and [2] 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 [2] 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 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]:
+---------------------+------------------------------------------+ +---------------------+------------------------------------------+
skipping to change at page 9, line 46 skipping to change at page 11, line 23
Bless for their helpful suggestions. 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] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, [2] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[3] Stewart, R., "Stream Control Transmission Protocol", RFC 4960,
September 2007. September 2007.
[3] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, [4] 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] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[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.
11.2. Informative References 11.2. Informative References
 End of changes. 22 change blocks. 
69 lines changed or deleted 106 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/