idnits 2.17.1 draft-pascual-dime-sctp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 7, 2010) is 4919 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC793' is mentioned on line 87, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Missing Reference: 'RFC5246' is mentioned on line 87, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Missing Reference: 'TBD' is mentioned on line 193, but not defined -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DIME WG V. Pascual 3 Internet-Draft Acme Packet 4 Intended status: Standards Track G. Camarillo 5 Expires: May 11, 2011 Ericsson 6 November 7, 2010 8 The Stream Control Transmission Protocol (SCTP) as a Transport for the 9 Diameter Protocol 10 draft-pascual-dime-sctp-00 12 Abstract 14 This document provides the guidelines for usage of SCTP (the Stream 15 Control Transmission Protocol) as the transport mechanism between 16 Diameter entities. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 11, 2011. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. SCTP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Payload Protocol Identifier . . . . . . . . . . . . . . . . 3 56 3.2. Mapping of Diameter messages into SCTP Streams . . . . . . 3 57 3.3. Port Number . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.4. S-NAPTR Parameters . . . . . . . . . . . . . . . . . . . . 4 59 4. TLS over SCTP Usage . . . . . . . . . . . . . . . . . . . . . . 4 60 5. DTLS over SCTP Usage . . . . . . . . . . . . . . . . . . . . . 4 61 5.1. Payload Protocol Identifier . . . . . . . . . . . . . . . . 4 62 5.2. Mapping of Diameter messages into SCTP Streams . . . . . . 5 63 5.3. Port Number . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5.4. S-NAPTR Parameters . . . . . . . . . . . . . . . . . . . . 5 65 6. SCTP over IPsec Usage . . . . . . . . . . . . . . . . . . . . . 5 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 71 10.2. Informative References . . . . . . . . . . . . . . . . . . 6 72 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 The Diameter base protocol [RFC3588] is intended to provide an 77 Authentication, Authorization and Accounting (AAA) framework for 78 applications such as network access or IP mobility in both local and 79 roaming situations. Among other aspects, [RFC3588] specifies the 80 transport service used by all Diameter applications. 81 [draft-ietf-dime-rfc3588bis] (work in progress) aims to obsolete this 82 specification. 84 Diameter messages are either requests or answers and are sent over a 85 reliable transport that offers congestion control; hence in 86 [draft-ietf-dime-rfc3588bis] the base Diameter protocol is defined to 87 run over TCP [RFC793], SCTP [RFC4960] or TLS [RFC5246], assuming that 88 TLS is run on top of TCP when it is used. According to the same 89 document, the use of a secured transport for exchanging Diameter 90 messages is mandatory being TLS the primary method and IPsec a 91 secondary alternative. However, TLS over SCTP [RFC3436] has some 92 serious limitations. 94 This document updates [draft-ietf-dime-rfc3588bis] by specifying the 95 usage of Diameter over SCTP and its associated security mechanisms. 97 2. Terminology 99 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 100 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 101 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 102 described in [RFC2119]. 104 The other concepts and terminology used in this document are 105 compatible with [draft-ietf-dime-rfc3588bis], 106 [draft-ietf-tsvwg-dtls-for-sctp], [RFC3436], [RFC3554] and [RFC4960]. 108 3. SCTP Usage 110 3.1. Payload Protocol Identifier 112 No SCTP identifier needs to be defined for Diameter messages. 113 Therefore, the Payload Protocol Identifier in SCTP DATA chunks 114 transporting Diameter messages MUST be set to zero. [Editor's note: 115 However, for protocol analyzers it is much easier if a specific PPID 116 is used.] 118 3.2. Mapping of Diameter messages into SCTP Streams 120 Diameter messages need to be mapped into SCTP streams in a way that 121 avoids Head Of the Line (HOL) blocking. Among the different ways of 122 performing this mapping that fulfill this requirement, the simplest 123 alternative is proposed; a Diameter entity SHOULD send every Diameter 124 message (request or response) over stream zero with the unordered 125 flag set. On the receiving side, a Diameter entity MUST be ready to 126 receive Diameter messages over any stream. 128 Although both sides of the SCTP association SHOULD use stream 0 for 129 Diameter requests and responses if they follow this recommendation, 130 if a Diameter request arrives over a particular stream, the server is 131 free to return responses over a different stream. This way, both 132 sides manage the available streams in the sending direction, 133 independently of the streams chosen by the other side to send a 134 particular Diameter message. This avoids undesirable collisions when 135 seizing a particular stream. 137 3.3. Port Number 139 The IANA has assigned port number 3868 for SCTP. 141 3.4. S-NAPTR Parameters 143 [draft-ietf-dime-rfc3588bis] registers a S-NAPTR Application Service 144 Tag value of "aaa". Additionally, it also registers the S-NAPTR 145 Application Protocol Tag for SCTP: diameter.sctp 147 4. TLS over SCTP Usage 149 As exposed in [draft-ietf-tsvwg-dtls-for-sctp], TLS over SCTP 150 [RFC3436] has some serious limitations. In order to overcome these 151 limitations, Diameter over DTLS/SCTP [draft-ietf-tsvwg-dtls-for-sctp] 152 is proposed as an alternative to TLS/SCTP. 154 5. DTLS over SCTP Usage 156 DTLS over SCTP is described in [draft-ietf-tsvwg-dtls-for-sctp] and 157 overcomes the limitations of TLS over SCTP. 159 The IESG has recently approved DTLS over SCTP as a Proposed Standard 160 and it will be published as a Standards Track RFC. SCTP over IPsec 161 is the RECOMMENDED solution for securing Diameter messages until 162 DTLS/SCTP gets widely adopted by the industry. 164 5.1. Payload Protocol Identifier 166 No SCTP identifier needs to be defined for Diameter messages over 167 DTLS. Therefore, the Payload Protocol Identifier in SCTP DATA chunks 168 transporting DTLS-based Diameter messages MUST be set to zero. 169 [Editor's note: However, for protocol analyzers it is much easier if 170 a specific PPID is used.] 172 5.2. Mapping of Diameter messages into SCTP Streams 174 Diameter messages need to be mapped into SCTP streams in a way that 175 avoids Head Of the Line (HOL) blocking. Among the different ways of 176 performing this mapping that fulfill this requirement, the simplest 177 alternative is proposed; a Diameter entity SHOULD send every Diameter 178 message (request or response) over stream zero with the unordered 179 flag set. On the receiving side, a Diameter entity MUST be ready to 180 receive Diameter messages over any stream. 182 Although both sides of the SCTP association SHOULD use stream 0 for 183 Diameter requests and responses if they follow this recommendation, 184 if a Diameter request arrives over a particular stream, the server is 185 free to return responses over a different stream. This way, both 186 sides manage the available streams in the sending direction, 187 independently of the streams chosen by the other side to send a 188 particular Diameter message. This avoids undesirable collisions when 189 seizing a particular stream. 191 5.3. Port Number 193 The port number [TBD] has been assigned for DTLS/SCTP. 195 5.4. S-NAPTR Parameters 197 [draft-ietf-dime-rfc3588bis] registers a S-NAPTR Application Service 198 Tag value of "aaa". The present document registers the S-NAPTR 199 Application Protocol Tag for DTLS/SCTP: diameter.dtls.sctp 201 6. SCTP over IPsec Usage 203 When Diameter is used over SCTP over IPsec, two modes are possible. 204 The straightforward way is to create an association and Security 205 Policy Database (SPD) selector for each SCTP IP Address and port 206 involved in an association, treating SCTP as any other layer above 207 IP, and thus potentially creating multiple entries for a single SCTP 208 association. Implementations MUST at least support this 209 straightforward mode, if they support this document and Diameter over 210 SCTP over IPsec. 212 Alternatively, implementations MAY also support [RFC3554] which 213 provides a minor optimization to reduce the number of IPsec 214 associations/selectors for SCTP connections. Note that [RFC3554] 215 creates a new IKE ID for this purpose. Generally such an 216 optimization is unnecessary for Diameter applications, both because 217 of the relatively low number of Diameter connections per system, and 218 because one of the main advantages of SCTP is multi-homing across 219 interfaces which makes [RFC3554] potentially impossible to implement. 221 7. Security Considerations 223 TBD 225 8. IANA Considerations 227 TBD 229 9. Acknowledgements 231 The authors wish to thank Hadriel Kaplan (Acme Packet), Juan Luis 232 Esteban (Acme Packet) and Michael Tuexen (Muenster Univ. of Applied 233 Sciences) for their contributions to this work. 235 10. References 237 10.1. Normative References 239 [RFC2119] Bradner, S., "Key words for use in 240 RFCs to Indicate Requirement 241 Levels", BCP 14, RFC 2119, 242 March 1997. 244 10.2. Informative References 246 [RFC4960] Stewart, R., "Stream Control 247 Transmission Protocol", RFC 4960, 248 September 2007. 250 [RFC3588] Calhoun, P., Loughney, J., Guttman, 251 E., Zorn, G., and J. Arkko, 252 "Diameter Base Protocol", RFC 3588, 253 September 2003. 255 [RFC3436] Jungmaier, A., Rescorla, E., and M. 256 Tuexen, "Transport Layer Security 257 over Stream Control Transmission 258 Protocol", RFC 3436, December 2002. 260 [RFC3554] Bellovin, S., Ioannidis, J., 261 Keromytis, A., and R. Stewart, "On 262 the Use of Stream Control 263 Transmission Protocol (SCTP) with 264 IPsec", RFC 3554, July 2003. 266 [draft-ietf-dime-rfc3588bis] Fajardo, V., Arkko, J., Loughney, 267 J., and G. Zorn, 268 "I-D.draft-ietf-dime-rfc3588bis 269 (work in progress)". 271 [draft-ietf-tsvwg-dtls-for-sctp] Tuexen, M., Seggelmann, R., and E. 272 Rescorla, 273 "I-D.draft-ietf-tsvwg-dtls-for-sctp 274 (work in progress)". 276 Appendix A. Change Log 278 New Document 280 Authors' Addresses 282 V. Pascual 283 Acme Packet 284 Anabel Segura 10 285 Madrid 28108 286 Spain 288 EMail: VPascual@acmepacket.com 290 G. Camarillo 291 Ericsson 292 Hirsalantie 11 293 Jorvas 02420 294 Finland 296 EMail: Gonzalo.Camarillo@ericsson.com