DIME WG V. Pascual Internet-Draft Acme Packet Intended status: Standards Track G. Camarillo Expires: May 11, 2011 Ericsson November 7, 2010 The Stream Control Transmission Protocol (SCTP) as a Transport for the Diameter Protocol draft-pascual-dime-sctp-00 Abstract This document provides the guidelines for usage of SCTP (the Stream Control Transmission Protocol) as the transport mechanism between Diameter entities. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 11, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Pascual & Camarillo Expires May 11, 2011 [Page 1] Internet-Draft SCTP for Diameter November 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. SCTP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Payload Protocol Identifier . . . . . . . . . . . . . . . . 3 3.2. Mapping of Diameter messages into SCTP Streams . . . . . . 3 3.3. Port Number . . . . . . . . . . . . . . . . . . . . . . . . 4 3.4. S-NAPTR Parameters . . . . . . . . . . . . . . . . . . . . 4 4. TLS over SCTP Usage . . . . . . . . . . . . . . . . . . . . . . 4 5. DTLS over SCTP Usage . . . . . . . . . . . . . . . . . . . . . 4 5.1. Payload Protocol Identifier . . . . . . . . . . . . . . . . 4 5.2. Mapping of Diameter messages into SCTP Streams . . . . . . 5 5.3. Port Number . . . . . . . . . . . . . . . . . . . . . . . . 5 5.4. S-NAPTR Parameters . . . . . . . . . . . . . . . . . . . . 5 6. SCTP over IPsec Usage . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . . 6 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 7 Pascual & Camarillo Expires May 11, 2011 [Page 2] Internet-Draft SCTP for Diameter November 2010 1. Introduction The Diameter base protocol [RFC3588] is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. Among other aspects, [RFC3588] specifies the transport service used by all Diameter applications. [draft-ietf-dime-rfc3588bis] (work in progress) aims to obsolete this specification. Diameter messages are either requests or answers and are sent over a reliable transport that offers congestion control; hence in [draft-ietf-dime-rfc3588bis] the base Diameter protocol is defined to run over TCP [RFC793], SCTP [RFC4960] or TLS [RFC5246], assuming that TLS is run on top of TCP when it is used. According to the same document, the use of a secured transport for exchanging Diameter messages is mandatory being TLS the primary method and IPsec a secondary alternative. However, TLS over SCTP [RFC3436] has some serious limitations. This document updates [draft-ietf-dime-rfc3588bis] by specifying the usage of Diameter over SCTP and its associated security mechanisms. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119]. The other concepts and terminology used in this document are compatible with [draft-ietf-dime-rfc3588bis], [draft-ietf-tsvwg-dtls-for-sctp], [RFC3436], [RFC3554] and [RFC4960]. 3. SCTP Usage 3.1. Payload Protocol Identifier No SCTP identifier needs to be defined for Diameter messages. Therefore, the Payload Protocol Identifier in SCTP DATA chunks transporting Diameter messages MUST be set to zero. [Editor's note: However, for protocol analyzers it is much easier if a specific PPID is used.] 3.2. Mapping of Diameter messages into SCTP Streams Diameter messages need to be mapped into SCTP streams in a way that avoids Head Of the Line (HOL) blocking. Among the different ways of Pascual & Camarillo Expires May 11, 2011 [Page 3] Internet-Draft SCTP for Diameter November 2010 performing this mapping that fulfill this requirement, the simplest alternative is proposed; a Diameter entity SHOULD send every Diameter message (request or response) over stream zero with the unordered flag set. On the receiving side, a Diameter entity MUST be ready to receive Diameter messages over any stream. Although both sides of the SCTP association SHOULD use stream 0 for Diameter requests and responses if they follow this recommendation, if a Diameter request arrives over a particular stream, the server is free to return responses over a different stream. This way, both sides manage the available streams in the sending direction, independently of the streams chosen by the other side to send a particular Diameter message. This avoids undesirable collisions when seizing a particular stream. 3.3. Port Number The IANA has assigned port number 3868 for SCTP. 3.4. S-NAPTR Parameters [draft-ietf-dime-rfc3588bis] registers a S-NAPTR Application Service Tag value of "aaa". Additionally, it also registers the S-NAPTR Application Protocol Tag for SCTP: diameter.sctp 4. TLS over SCTP Usage As exposed in [draft-ietf-tsvwg-dtls-for-sctp], TLS over SCTP [RFC3436] has some serious limitations. In order to overcome these limitations, Diameter over DTLS/SCTP [draft-ietf-tsvwg-dtls-for-sctp] is proposed as an alternative to TLS/SCTP. 5. DTLS over SCTP Usage DTLS over SCTP is described in [draft-ietf-tsvwg-dtls-for-sctp] and overcomes the limitations of TLS over SCTP. The IESG has recently approved DTLS over SCTP as a Proposed Standard and it will be published as a Standards Track RFC. SCTP over IPsec is the RECOMMENDED solution for securing Diameter messages until DTLS/SCTP gets widely adopted by the industry. 5.1. Payload Protocol Identifier No SCTP identifier needs to be defined for Diameter messages over DTLS. Therefore, the Payload Protocol Identifier in SCTP DATA chunks transporting DTLS-based Diameter messages MUST be set to zero. [Editor's note: However, for protocol analyzers it is much easier if Pascual & Camarillo Expires May 11, 2011 [Page 4] Internet-Draft SCTP for Diameter November 2010 a specific PPID is used.] 5.2. Mapping of Diameter messages into SCTP Streams Diameter messages need to be mapped into SCTP streams in a way that avoids Head Of the Line (HOL) blocking. Among the different ways of performing this mapping that fulfill this requirement, the simplest alternative is proposed; a Diameter entity SHOULD send every Diameter message (request or response) over stream zero with the unordered flag set. On the receiving side, a Diameter entity MUST be ready to receive Diameter messages over any stream. Although both sides of the SCTP association SHOULD use stream 0 for Diameter requests and responses if they follow this recommendation, if a Diameter request arrives over a particular stream, the server is free to return responses over a different stream. This way, both sides manage the available streams in the sending direction, independently of the streams chosen by the other side to send a particular Diameter message. This avoids undesirable collisions when seizing a particular stream. 5.3. Port Number The port number [TBD] has been assigned for DTLS/SCTP. 5.4. S-NAPTR Parameters [draft-ietf-dime-rfc3588bis] registers a S-NAPTR Application Service Tag value of "aaa". The present document registers the S-NAPTR Application Protocol Tag for DTLS/SCTP: diameter.dtls.sctp 6. SCTP over IPsec Usage When Diameter is used over SCTP over IPsec, two modes are possible. The straightforward way is to create an association and Security Policy Database (SPD) selector for each SCTP IP Address and port involved in an association, treating SCTP as any other layer above IP, and thus potentially creating multiple entries for a single SCTP association. Implementations MUST at least support this straightforward mode, if they support this document and Diameter over SCTP over IPsec. Alternatively, implementations MAY also support [RFC3554] which provides a minor optimization to reduce the number of IPsec associations/selectors for SCTP connections. Note that [RFC3554] creates a new IKE ID for this purpose. Generally such an optimization is unnecessary for Diameter applications, both because of the relatively low number of Diameter connections per system, and Pascual & Camarillo Expires May 11, 2011 [Page 5] Internet-Draft SCTP for Diameter November 2010 because one of the main advantages of SCTP is multi-homing across interfaces which makes [RFC3554] potentially impossible to implement. 7. Security Considerations TBD 8. IANA Considerations TBD 9. Acknowledgements The authors wish to thank Hadriel Kaplan (Acme Packet), Juan Luis Esteban (Acme Packet) and Michael Tuexen (Muenster Univ. of Applied Sciences) for their contributions to this work. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002. [RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", RFC 3554, July 2003. Pascual & Camarillo Expires May 11, 2011 [Page 6] Internet-Draft SCTP for Diameter November 2010 [draft-ietf-dime-rfc3588bis] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "I-D.draft-ietf-dime-rfc3588bis (work in progress)". [draft-ietf-tsvwg-dtls-for-sctp] Tuexen, M., Seggelmann, R., and E. Rescorla, "I-D.draft-ietf-tsvwg-dtls-for-sctp (work in progress)". Appendix A. Change Log New Document Authors' Addresses V. Pascual Acme Packet Anabel Segura 10 Madrid 28108 Spain EMail: VPascual@acmepacket.com G. Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com Pascual & Camarillo Expires May 11, 2011 [Page 7]