idnits 2.17.1 draft-tuexen-tsvwg-sctp-udp-encaps-cons-05.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(265): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 5 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 February 2022) is 787 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: 'RFCXXXX' is mentioned on line 242, but not defined ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Tüxen 3 Internet-Draft Münster Univ. of Appl. Sciences 4 Updates: 6951 (if approved) R. R. Stewart 5 Intended status: Standards Track Netflix, Inc. 6 Expires: 31 August 2022 27 February 2022 8 Additional Considerations for UDP Encapsulation of Stream Control 9 Transmission Protocol (SCTP) Packets 10 draft-tuexen-tsvwg-sctp-udp-encaps-cons-05 12 Abstract 14 RFC 6951 specifies the UDP encapsulation of SCTP packets. The 15 described handling of received packets requires the check of the 16 verification tag. However, RFC 6951 misses a specification of the 17 handling of received packets for which this check is not possible. 19 This document updates RFC 6951 by specifying the handling of received 20 packets for which the verification tag can not be checked. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 31 August 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Handling of Out of the Blue Packets . . . . . . . . . . . . . 3 58 4. Handling of SCTP Packets Containing an INIT Chunk Matching an 59 Existing Associations . . . . . . . . . . . . . . . . . . 3 60 5. Middlebox Considerations . . . . . . . . . . . . . . . . . . 5 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 64 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 [RFC6951] specifies the UDP encapsulation of SCTP packets. To be 70 able to adopt automatically to changes of the remote UDP 71 encapsulation port number, it is updated when processing received 72 packets. This includes automatic enabling and disabling of UDP 73 encapsulation. 75 Section 5.4 of [RFC6951] describes the processing of received packets 76 and requires the check of the verification tag before updating the 77 remote UDP encapsulation port and the possible enabling or disabling 78 of UDP encapsulation. 80 [RFC6951] basically misses a description of the handling of received 81 packets where checking the verification tag is not possible. This 82 includes packets for which no association can be found and packets 83 containing an INIT chunk, since the verification tag of these packets 84 is 0. 86 2. Conventions 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 90 "OPTIONAL" in this document are to be interpreted as described in BCP 91 14 [RFC2119] [RFC8174] when, and only when, they appear in all 92 capitals, as shown here. 94 3. Handling of Out of the Blue Packets 96 If the processing of an out of the blue packet requires the sending 97 of a packet in response according to the rules specified in 98 Section 8.4 of [RFC4960], the following rules apply: 100 1. If the received packet was encapsulated in UDP, the response 101 packets MUST also be encapsulated in UDP. The UDP source port 102 and UDP destination port used for sending the response packet are 103 the UDP destination port and UDP source port of the received 104 packet. 106 2. If the received packet was not encapsulated in UDP, the response 107 packet MUST NOT be encapsulated in UDP. 109 Please note that in these cases a check of the verification tag is 110 not possible. 112 4. Handling of SCTP Packets Containing an INIT Chunk Matching an 113 Existing Associations 115 SCTP packets containing an INIT chunk have the verification tag 0 in 116 the common header. Therefore the verification tag can't be checked. 118 The following rules apply when processing the received packet: 120 1. The remote UDP encapsulation port for the source address of the 121 received SCTP packet MUST NOT be updated if the encapsulation of 122 outgoing packets is enabled and the received SCTP packet is 123 encapsulated. 125 2. The UDP encapsulation for outgoing packets towards the source 126 address of the received SCTP packet MUST NOT be enabled, if it is 127 disabled and the received SCTP packet is encapsulated. 129 3. The UDP encapsulation for outgoing packets towards the source 130 address of the received SCTP packet MUST NOT be disabled, if it 131 is enabled and the received SCTP packet is not encapsulated. 133 4. If the UDP encapsulation for outgoing packets towards the source 134 address of the received SCTP packet is disabled and the received 135 SCTP packet is encapsulated, an SCTP packet containing an ABORT 136 chunk MUST be sent. The ABORT chunk MAY include the error cause 137 defined below indicating an "Restart of an Association with New 138 Encapsulation Port". This packet containing the ABORT chunk MUST 139 be encapsulated in UDP. The UDP source port and UDP destination 140 port used for sending the packet containing the ABORT chunk are 141 the UDP destination port and UDP source port of the received 142 packet containing the INIT chunk. 144 5. If the UDP encapsulation for outgoing packets towards the source 145 address of the received SCTP packet is disabled and the received 146 SCTP packet is not encapsulated, the processing defined in 147 [RFC4960] MUST be performed. If a packet is sent in response, it 148 MUST NOT be encapsulated. 150 6. If the UDP encapsulation for outgoing packets towards the source 151 address of the received SCTP packet is enabled and the received 152 SCTP packet is not encapsulated, an SCTP packet containing an 153 ABORT chunk MUST be sent. The ABORT chunk MAY include the error 154 cause defined below indicating an "Restart of an Association with 155 New Encapsulation Port". This packet containing the ABORT chunk 156 MUST NOT be encapsulated in UDP. 158 7. If the UDP encapsulation for outgoing packets towards the source 159 address of the received SCTP packet is enabled and the received 160 SCTP packet is encapsulated, but the UDP source port of the 161 received SCTP packet is not equal to the remote UDP encapsulation 162 port for the source address of the received SCTP packet, an SCTP 163 packet containing an ABORT chunk MUST be sent. The ABORT chunk 164 MAY include the error cause defined below indicating an "Restart 165 of an Association with New Encapsulation Port". This packet 166 containing the ABORT chunk MUST be encapsulated in UDP. The UDP 167 source port and UDP destination port used for sending the packet 168 containing the ABORT chunk are the UDP destination port and UDP 169 source port of the received packet containing the INIT chunk. 171 8. If the UDP encapsulation for outgoing packets towards the source 172 address of the received SCTP packet is enabled and the received 173 SCTP packet is encapsulated and the UDP source port of the 174 received SCTP packet is equal to the remote UDP encapsulation 175 port for the source address of the received SCTP packet, the 176 processing defined in [RFC4960] MUST be performed. If a packet 177 is sent in response, it MUST be encapsulated. The UDP source 178 port and UDP destination port used for sending the packet 179 containing the ABORT chunk are the UDP destination port and UDP 180 source port of the received packet containing the INIT chunk. 182 The error cause indicating an "Restart of an Association with New 183 Encapsulation Port" is defined by the following figure. 185 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Cause Code = 14 | Cause Length = 8 | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Current Encapsulation Port | New Encapsulation Port | 190 +-------------------------------+-------------------------------+ 192 Figure 1: Restart of an Association with New Encapsulation Port 193 error cause 195 Cause Code: 2 bytes (unsigned integer) 196 This field holds the IANA defined cause code for the "Restart of 197 an Association with New Encapsulation Port" error cause. IANA is 198 requested to assign the value 14 for this cause code. 200 Cause Length: 2 bytes (unsigned integer) 201 This field holds the length in bytes of the error cause; the value 202 MUST be 8. 204 Current Encapsulation Port: 2 bytes (unsigned integer) 205 This field holds the remote encapsulation port currently being 206 used for the destination address the received packet containing 207 the INIT chunk was sent from. If the UDP encapsulation for 208 destination address is currently disabled, 0 is used. 210 New Encapsulation Port: 2 bytes (unsigned integer) 211 If the received SCTP packet containing the INIT chunk is 212 encapsulated in UDP, this field holds the UDP source port number 213 of the UDP packet. If the received SCTP packet is not 214 encapsulated in UDP, this field is 0. 216 All transported integer numbers are in "network byte order" a.k.a., 217 Big Endian. 219 5. Middlebox Considerations 221 Middleboxes often use different timeouts for UDP based flows than for 222 other flows. Therefore the HEARTBEAT.Interval parameter SHOULD be 223 lowered to 15 seconds when UDP encapsulation is used. 225 6. IANA Considerations 227 [NOTE to RFC-Editor: "RFCXXXX" is to be replaced by the RFC number 228 you assign this document.] 230 [NOTE to RFC-Editor: The requested values for the cause code are 231 tentative and to be confirmed by IANA.] 233 This document (RFCXXXX) is the reference for the registration 234 described in this section. 236 A new error cause code has to be assigned by IANA. This requires an 237 additional line in the "Error Cause Codes" registry for SCTP: 239 +=======+=============================+===========+ 240 | Value | Cause Code | Reference | 241 +=======+=============================+===========+ 242 | 14 | Restart of an Association | [RFCXXXX] | 243 | | with New Encapsulation Port | | 244 +-------+-----------------------------+-----------+ 246 Table 1: New entry in Error Cause Codes registry 248 7. Security Considerations 250 This document does not change the considerations given in [RFC6951]. 252 However, not following the procedures given in this document might 253 allow an attacker to take over SCTP associations. The attacker needs 254 only to share the IP address of an existing SCTP association. 256 It should also be noted that if firewalls will be applied at the SCTP 257 association level they have to take the UDP encapsulation into 258 account. 260 8. Acknowledgments 262 The authors wish to thank Georgios Papastergiou for the initial 263 problem report. 265 The authors wish to thank Irene Rüngeler and Felix Weinrank for their 266 invaluable comments. 268 This work has received funding from the European Union's Horizon 2020 269 research and innovation programme under grant agreement No. 644334 270 (NEAT). The views expressed are solely those of the author(s). 272 9. Normative References 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, 276 DOI 10.17487/RFC2119, March 1997, 277 . 279 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 280 RFC 4960, DOI 10.17487/RFC4960, September 2007, 281 . 283 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 284 Control Transmission Protocol (SCTP) Packets for End-Host 285 to End-Host Communication", RFC 6951, 286 DOI 10.17487/RFC6951, May 2013, 287 . 289 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 290 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 291 May 2017, . 293 Authors' Addresses 295 Michael Tüxen 296 Münster University of Applied Sciences 297 Stegerwaldstrasse 39 298 48565 Steinfurt 299 Germany 300 Email: tuexen@fh-muenster.de 302 Randall R. Stewart 303 Netflix, Inc. 304 2455 Heritage Green Ave 305 Davenport, FL 33837 306 United States 307 Email: randall@lakerest.net