idnits 2.17.1 draft-ietf-6man-mtu-option-03.txt: -(783): 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 2 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 (14 September 2020) is 1320 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1063 (Obsoleted by RFC 1191) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Hinden 3 Internet-Draft Check Point Software 4 Intended status: Experimental G. Fairhurst 5 Expires: 18 March 2021 University of Aberdeen 6 14 September 2020 8 IPv6 Minimum Path MTU Hop-by-Hop Option 9 draft-ietf-6man-mtu-option-03 11 Abstract 13 This document specifies a new Hop-by-Hop IPv6 option that is used to 14 record the minimum Path MTU along the forward path between a source 15 host to a destination host. This collects a minimum Path MTU 16 recorded along the path to the destination. The value can then be 17 communicated back to the source using the return Path MTU field in 18 the option. 20 This Hop-by-Hop option is intended to be used in environments like 21 Data Centers and on paths between Data Centers, to allow them to 22 better take advantage of paths able to support a large Path MTU. The 23 method could also be useful in other environments, including the 24 general Internet. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 18 March 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Example Operation . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Use of the IPv6 Hop-by-Hop Options Header . . . . . . . . 4 62 2. Motivation and Problem Solved . . . . . . . . . . . . . . . . 5 63 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 64 4. Applicability Statements . . . . . . . . . . . . . . . . . . 6 65 5. IPv6 Minimum Path MTU Hop-by-Hop Option . . . . . . . . . . . 6 66 6. Router, Host, and Transport Behaviors . . . . . . . . . . . . 7 67 6.1. Router Behaviour . . . . . . . . . . . . . . . . . . . . 7 68 6.2. Host Behavior . . . . . . . . . . . . . . . . . . . . . . 8 69 6.3. Transport Behavior . . . . . . . . . . . . . . . . . . . 8 70 6.3.1. Including the Option in an Outgoing Packet . . . . . 8 71 6.3.2. Validation by the Upper Layer Protocol . . . . . . . 10 72 6.3.3. Receiving the Option . . . . . . . . . . . . . . . . 10 73 6.3.4. Using the Rtn-PMTU Field . . . . . . . . . . . . . . 11 74 6.3.5. Detection of Droping Packets that include the 75 Option . . . . . . . . . . . . . . . . . . . . . . . 12 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 8.1. Network Layer Host Processing . . . . . . . . . . . . . . 13 79 8.2. Validating use of the Option Data . . . . . . . . . . . . 13 80 8.3. Direct use of the Rtn-PMTU Value . . . . . . . . . . . . 14 81 8.4. Using the Rtn-PMTU Value as a Hint for Probing . . . . . 14 82 8.5. Impact of Middleboxes . . . . . . . . . . . . . . . . . . 15 83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 84 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 15 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 87 11.2. Informative References . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Introduction 92 This draft proposes a new IPv6 Hop-by-Hop Option to be used to record 93 the minimum of the Maxmim Transmission Unit (MTU) along the forward 94 path between the source and destination hosts. The source host 95 creates a packet with this Hop-by-Hop Option and fills the Min-PMTU 96 field in the option with the value of the MTU for the outbound link 97 that will be used to forward the packet towards the destination host. 98 This option is carried in the IPv6 Hop-by-Hop Options Header. 100 At each subsequent hop where the option is processed, the router 101 compares the value of the Min-PMTU Field in the option and the MTU of 102 its outgoing link. If the MTU of the outgoing link is less than the 103 Min-PMTU specified in the option, it rewrites the value in the option 104 data with the smaller value. When the packet arrives at the 105 destination host, the destination host can send the value of the 106 minimum reported MTU for the path back to the source host using the 107 Rtn-PMTU field in the option. The source host can then use this 108 value as an input to the method used to set the Path MTU (PMTU) used 109 by upper layer protocols. 111 1.1. Example Operation 113 The figure below illustrates the operation of the method. In this 114 case, the path between the source and destination hosts comprises 115 three links, the sender has a link MTU of size MTU-S, the link 116 between routers R1 and R2 has an MTU of size 9000 bytes, and the 117 final link to the destination has an MTU of size MTU-D. 119 +--------+ +----+ +----+ +-------+ 120 | | | | | | | | 121 | Sender +---------+ R1 +--------+ R2 +-------- + Dest. | 122 | | | | | | | | 123 +--------+ MTU-S +----+ 9000B +----+ MTU-D +-------+ 125 Three scenarios are described: 127 * Scenario 1, considers all links to have an 9000 byte MTU and the 128 method is supported by both routers. The PMTU is therefore 9000 129 bytes. 131 * Scenario 2, considers the link to the destination host (MTU-D) to 132 have an MTU of 1500 bytes. This is the smallest MTU, router R2 133 updates the Min-PMTU to 1500 bytes and the method correctly 134 updates the PMTU to 1500 bytes. Had there been another smaller 135 MTU at a link further along the path that also supports the 136 method, the lower MTU would also have been detected. 138 * Scenario 3, considers the case where the router preceding the 139 smallest link (R2) does not support the method, and the link to 140 the destination host (MTU-D) has an MTU of 1500 bytes. Therefore, 141 router R2 does not update the Min-PMTU to 1500 bytes. The method 142 then fails to detect the actual PMTU. 144 In Scenarios 2 and 3, a lower PMTU would also fail to be detected in 145 the case where PMTUD had been used and an ICMPv6 Packet to Big (PTB) 146 message had not been delivered to the sender [RFC8201]. 148 These scenarios are summarized in the table below. 150 +-+-----+-----+----+----+----------+-----------------------+ 151 | |MTU-S|MTU-D| R1 | R2 | Rec PMTU | Note | 152 +-+-----+-----+----+----+----------+-----------------------+ 153 |1|9000B|9000B| H | H | 9000 B | Endpoints attempt to | 154 | | | | | | use an 9000 B PMTU. | 155 +-+-----+-----+----+----+----------+-----------------------+ 156 |2|9000B|1500B| H | H | 1500 B | Endpoints attempt to | 157 | | | | | | | use a 1500 B PMTU. | 158 +-+-----+-----+----+----+----------+-----------------------+ 159 |3|9000B|1500B| H | - | 9000 B | Endpoints attempt to | 160 | | | | | | | use an 9000 B PMTU, | 161 | | | | | | | but need to implement | 162 | | | | | | | a method to fall back | 163 | | | | | | | to discover and use a | 164 | | | | | | | 1500 B PMTU. | 165 +-+-----+-----+----+----+----------+-----------------------+ 167 1.2. Use of the IPv6 Hop-by-Hop Options Header 169 IPv6 as specified in [RFC8200] allows nodes to optionally process 170 Hop-by-Hop headers. Specifically from Section 4: 172 * The Hop-by-Hop Options header is not inserted or deleted, but may 173 be examined or processed by any node along a packet's delivery 174 path, until the packet reaches the node (or each of the set of 175 nodes, in the case of multicast) identified in the Destination 176 Address field of the IPv6 header. The Hop-by-Hop Options header, 177 when present, must immediately follow the IPv6 header. Its 178 presence is indicated by the value zero in the Next Header field 179 of the IPv6 header. 181 * NOTE: While [RFC2460] required that all nodes must examine and 182 process the Hop-by-Hop Options header, it is now expected that 183 nodes along a packet's delivery path only examine and process the 184 Hop-by-Hop Options header if explicitly configured to do so. 186 The Hop-by-Hop Option defined in this document is designed to take 187 advantage of this property of how Hop-by-Hop options are processed. 188 Nodes that do not support this Option SHOULD ignore them. This can 189 mean that the Min-PMTU value does not account for all links along a 190 path. 192 2. Motivation and Problem Solved 194 The current state of Path MTU Discovery on the Internet is 195 problematic. The mechanisms defined in [RFC8201] are known to not 196 work well in all environments. This fails to work in various cases, 197 including when nodes in the middle of the network do not send ICMP 198 PTB messages, or rate-limited messages to the point of not making 199 them a useful mechanism, or do not have a return path to the source 200 host. 202 This results in many transport connections being configured to use 203 smaller packets (e.g., 1280 bytes) by default and makes it difficult 204 to take advantage of paths with a larger PMTU where they do exist. 205 Applications that can gain benefit from sending large packets are 206 forced to use IPv6 Fragmentation [RFC8200], which can reduce the 207 reliability of Internet communication [RFC8900]. 209 Transport encapsulations and network-layer tunnels further reduce the 210 the payload size available for a transport to use. Also, some use- 211 cases increase packet overhead, for example, Network Virtualization 212 Using Generic Routing Encapsulation (NVGRE) [RFC7637] encapsulates L2 213 packets in an outer IP header and does not allow IP Fragmentation. 215 Sending small packets can limit performance, e.g., when packet 216 processing is limited by the packet rate. The potential of multi- 217 gigabit Ethernet will not be realized if the packet size is limited 218 to 1280 bytes, because this exceeds the packet per second rate that 219 most nodes can process. For example, the packet per second rate 220 required to reach wire speed on a 10G Ethernet link with 1280 byte 221 packets is about 977K packets per second (pps), vs. 139K pps for 9000 222 byte packets. A significant difference. 224 The purpose of the this draft is to improve the situation by defining 225 a mechanism that does not rely on reception of ICMPv6 Packet Too Big 226 messages from nodes in the middle of the network. Instead, this 227 provides information to the destination host about the minimum Path 228 MTU, and sends this information back to the source host. This is 229 expected to work better than the current RFC8201-based mechanisms. 231 3. Requirements Language 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 235 "OPTIONAL" in this document are to be interpreted as described in BCP 236 14 [RFC2119] [RFC8174] when, and only when, they appear in all 237 capitals, as shown here. 239 4. Applicability Statements 241 This Hop-by-Hop Option header is intended to be used in environments 242 such as Data Centers and on paths between Data Centers, to allow a 243 host to better take advantage of a path that is able to support a 244 large PMTU. 246 The design of the option is sufficiently simple that it could be 247 executed on a router's fast path. A strong pull from router vendors 248 customers will be required to create critical mass for this to 249 happen. This could initially be the case for connections within and 250 between Data Centers. 252 The method could also be useful in other environments, including the 253 general Internet, if and when this Hop-by-Hop Option is supported on 254 these paths. 256 5. IPv6 Minimum Path MTU Hop-by-Hop Option 258 The Minimum Path MTU Hop-by-Hop Option has the following format: 260 Option Option Option 261 Type Data Len Data 262 +--------+--------+--------+--------+---------+-------+-+ 263 |BBCTTTTT|00000100| Min-PMTU | Rtn-PMTU |R| 264 +--------+--------+--------+--------+---------+-------+-+ 266 Option Type (see Section 4.2 of [RFC8200]): 268 BB 00 Skip over this option and continue processing. 270 C 1 Option data can change en route to the packet's final 271 destination. 273 TTTTT 10000 Option Type assigned from IANA [IANA-HBH]. 275 Length: 4 The size of the each value field in Option Data 276 field supports PMTU values from 0 to 65,535 octets. 278 Min-PMTU: n 16-bits. The minimum MTU recorded along the path 279 in octets, reflecting the smallest link MTU that 280 the packet experienced along the path. 281 A value less than the IPv6 minimum link 282 MTU [RFC8200] should be ignored. 284 Rtn-PMTU: n 15-bits. The returned Path MTU field, carrying the 15 285 most significant bits of the latest received Min-PMTU 286 field for the forward path. The value zero means that 287 no Reported MTU is being returned. 289 R n 1-bit. R-Flag. Set by the source to signal that 290 the destination host should include the received 291 Rtn-PMTU field updated by the reported Min-PMTU value. 293 NOTE: The encoding of the final two octets (Rtn-PMTU and R-Flag) 294 could be implemented by a mask of the latest received Min-PMTU value 295 with 0xFFFE, discarding the right-most bit and then performing a 296 logical 'OR' with the R-Flag value of the sender. 298 6. Router, Host, and Transport Behaviors 300 6.1. Router Behaviour 302 Routers that are not configured to support Hop-by-Hop Options SHOULD 303 ignore this option and SHOULD forward the packet. 305 Routers that support Hop-by-Hop Options, but that are not configured 306 to support this option SHOULD ignore the option and SHOULD forward 307 the packet. 309 Routers that recognize this option SHOULD compare the value of the 310 Min-PMTU field with the MTU configured for the outgoing link. If the 311 MTU of the outgoing link is less than the Min-PMTU, the router 312 rewrites the Min-PMTU in the Option to use the smaller value. 314 A router MUST ignore and MUST NOT change the Rtn-PMTU field or the 315 R-Flag in the option. 317 Discussion: 319 * The design of this option makes it feasible to be implemented 320 within the fast path of a router, because the processing 321 requirements are minimal. 323 6.2. Host Behavior 325 When requested to send an IPv6 packet with the Minimum Path MTU 326 option, the source host includes the option in an outgoing packet. 327 The source host SHOULD fill the Min-PMTU field with the MTU 328 configured for the link over which it will send the packet on the 329 next hop towards the destination host. If this value is not updated, 330 the field MUST be set to zero. 332 The source host SHOULD set the Rtn-PMTU field to the cached value of 333 the reported Min-PMTU value for the flow ( see Section 6.3.3). If 334 this value is not set, for example, because there is no cached 335 reported Min-PMTU value, the field MUST be set to zero. 337 The source host MAY request the destination host to return the 338 reported Min-PMTU value by setting the R-Flag in the option of an 339 outgoing packet. 341 6.3. Transport Behavior 343 6.3.1. Including the Option in an Outgoing Packet 345 The upper layer protocol can request the Minimum Path MTU option is 346 included in an outgoing IPv6 packet. This option does not need to be 347 included in all packets belonging to a flow. A transport protocol 348 (or upper layer protocol) can include this option only on specific 349 packets used to test the path. 351 When it includes the option, the host supplies the previously cached 352 value of the received Minimum Path MTU for the flow to set the Rtn- 353 PMTU field (see Section 6.3.3). If a valid cached received Minimum 354 Path MTU is not available, the Rtn-PMTU field value MUST be set to 355 zero. 357 The source host MAY request the destination host to send a packet 358 carrying the option by setting the R-Flag. The R-Flag SHOULD NOT be 359 set when the Minimum Path MTU Option was sent solely to feedback the 360 return Path MTU. 362 NOTE: Including this option in a large packet (e.g., one larger than 363 the present PMTU) is not likely to be useful, since the large packet 364 would itself be dropped by any link along the path with a smaller 365 MTU, preventing the Min-PMTU information from reaching the 366 destination host. 368 Discussion: 370 * In the case of TCP, the option could be included in packets 371 carrying a SYN segment as part of the connection set up, or can 372 periodically be sent in packets carrying other segments. 373 Including this packet in a SYN could increase the probability that 374 the SYN segment is lost when routers on the path drop packets with 375 this option (see Section 6.3.5). NOTE: A TCP connection can also 376 negotiate the Maximum Segment Size (MSS), which acts as an upper 377 limit to the packet size that can be sent by a TCP sender. 379 * The use with datagram transport protocols (e.g., UDP) is harder to 380 characterize because applications using datagram transports range 381 from very short-lived (low data-volume applications) exchanges, to 382 longer (bulk) exchanges of packets between the source and 383 destination hosts [RFC8085]. 385 * Simple-exchange protocols (i.e., low data-volume applications 386 [RFC8085] that only send one or a few packets per transaction, 387 might assume that the PMTU is symmetrical. That is, the PMTU is 388 the same in both directions, or at least not smaller for the 389 return path. This optimisation does not hold when the paths are 390 not symmetric. 392 * The use of this option with DNS and DNSSEC over UDP ought to work, 393 for symmetric paths. The DNS server will learn the PMTU from the 394 DNS query messages. If the Rtn-PMTU value is smaller, then a 395 large DNSSEC response might be dropped and the known problems with 396 PMTUD will occur. DNS and DNSSEC over transport protocols that 397 can carry the PMTU ought to work. 399 * Applications that use Anycast should include this option in all 400 packets, because the actual destination host will vary due to the 401 nature of Anycast. 403 6.3.2. Validation by the Upper Layer Protocol 405 An upper layer protocol (e.g., transport endpoint) using this option 406 needs to provide protection from data injection attacks by off-path 407 devices [RFC8085]. This requires a method to assure that the 408 information in the Option Data is provided by a node on the path. 409 For example, a TCP connection or UDP application that maintains the 410 related state and uses a randomised ephemeral port would provide this 411 basic validation to protect from off-path data injection. IPsec 412 [RFC4301] and TLS [RFC8446] provide greater assurance. 414 The Upper Layer discards any received packet when the packet 415 validation fails. When this packet validation fails, the Upper Layer 416 MUST also discard the associated Option Data from the minimum Path 417 MTU option without further processing. 419 6.3.3. Receiving the Option 421 An upper layer protocol that receives a Minimum Path MTU Option 422 iccnluded with a valid packet caches the value of the last received 423 Min-PMTU. This value is specific to the instance of the upper layer 424 protocol (i.e., matching the IPv6 flow ID, port-fields in UDP or the 425 SPI in IPsec [RFC4301], etc), not to the pair of source and 426 destination addresses, because network devices can make forwarding 427 decisions that impact the PMTU of a flow based on the presence and 428 value of the packet's upper layer fields. 430 For a connection-oriented upper layer protocol, caching of the 431 received Min-PMTU could be implemented by saving the value in the 432 connection context at the transport layer. A connection-less upper 433 layer (e.g., one using UDP), requires the upper layer protocol to 434 cache the value for each flow it uses. 436 A destination host that receives a Minimum Path MTU Option with the 437 R-Flag SHOULD include the Minimum Path MTU option in the next 438 outgoing IPv6 packet for the corresponding flow. 440 A simple mechanism could only include this option (with the Rtn-PMTU 441 field set) the first time this option is received or when it notifies 442 a change in the Minimum Path MTU. This limits the number of packets 443 including the option packets that are sent. However, this does not 444 provide robustness to packet loss or recovery after a sender looses 445 state. 447 Path characteristics can change and the actual PMTU could increase or 448 decrease over time. For instance, following a path change when 449 packets are then forwarded over a link with a different MTU than that 450 previously used. To bound the delay in discovering a change in the 451 actual PMTU, a sender with a link MTU larger than the current PMTU 452 SHOULD periodically send the Minimum Path MTU Option with the R-bit 453 set. DPLPMTUD provides recommendations concerning how this could be 454 implemented (see Section 5.3 of [RFC8899]). Since the option 455 consumes less capacity than a full-sized probe packet, there can be 456 advantage in using this to detect a change in the path 457 characteristics. 459 Discussion: 461 * Some upper layer protocols send packets less frequently than 462 packets that the host receives packets. This provides less 463 frequent feedback of the received Rtn-PMTU value. However, a host 464 always sends the most recent Rtn-PMTU value. 466 6.3.4. Using the Rtn-PMTU Field 468 The Rtn-PMTU field provides an indication of the PMTU from on-path 469 routers. It does not necessarily reflect the actual PMTU between the 470 sender and destination. Care therefore needs to be exercised in 471 using the Rtn-PMTU value. Specifically: 473 * The actual PMTU can be lower than the Rtn-PMTU value because Min- 474 PMTU field was not updated by a router on the path that did not 475 process the option. 477 * The actual PMTU may be lower than the Rtn-PMTU value because the 478 there is a layer 2 device with a lower MTU that does not perform 479 IPv6 forwarding. 481 * The actual PMTU may be larger than the Rtn-PMTU value because of a 482 corrupted, delayed or mis-ordered response. A source host SHOULD 483 ignore a Rtn-PMTU value larger than the MTU configured for the 484 outgoing link. 486 Using the method has the potential to complete discovery of the 487 correct value in a single round trip time, even over paths that have 488 successive links each configured with a lower MTU. 490 To avoid unintentional dropping of packets that exceed the actual 491 PMTU (e.g., Scenario 3 in Section 1.1), the source host can delay 492 increasing the PMTU until a probe packet with the size of the Rtn- 493 PMTU value has been sucessfuly acknowledged by the upper layer, 494 confirming that the path supports the larger PMTU. This probing 495 increases robustness, but adds one additional path round trip time 496 before the PMTU is updated. This use resembles that of PTB messages 497 in section 4.6 of DPLPMTUD [RFC8899] (with the important difference 498 that a PTB message can only seek to lower the PMTU, whereas this 499 option could trigger a probe packet to seek to increase the PMTU.) 501 Section 5.2 of [RFC8201] provides guidance on the caching of PMTU 502 information and also the relation to IPv6 flow labels. 503 Implementations should consider the impact of Equal Cost Multipath 504 (ECMP) [RFC6438]. Specifically, whether a PMTU ought be maintained 505 for each transport endpoint, or for each network address. 507 6.3.5. Detection of Droping Packets that include the Option 509 There is evidence that some middleboxes drop packets that include 510 Hop-by-Hop options. For example, a firewall might drop a packet that 511 carries an unknown extension header or option. This practice is 512 expected to decrease as an option becomes more widely used. It could 513 result in generation of an ICMPv6 message indicating the problem. 514 This could be used to (temporarily) suspend use of this option. 516 A middlebox that silently discards a packet with this option, results 517 in dropping of any packet using the option. This dropping be avoided 518 by appropiate configuration in a controlled environment, such as 519 within a data centre, but needs to be considered for Internet usage. 520 Section 6.2 recommends that this option is not used on packets where 521 loss might adversely impact performance. 523 7. IANA Considerations 525 No IANA actions are requested in this document. 527 IANA has assigned and registered a new IPv6 Hop-by-Hop Option type 528 from the "Destination Options and Hop-by-Hop Options" registry 529 [IANA-HBH]. This assignment is shown in Section 5. 531 8. Security Considerations 533 This section discusses the security considerations. It first reviews 534 host processing when receiving this option at the network layer. It 535 then considers two ways in which the Option Data can be processed, 536 followed by two approaches for using the Option Data. Finally, it 537 discusses middlebox implications related to use in the general 538 Interent. 540 8.1. Network Layer Host Processing 542 A malicious attacker can forge a packet directed at a host that 543 carries the minimum Path MTU option. By design, the fields of this 544 IP option can be modified by the network. 546 Network layer option processing is normally done before any upper 547 layer protocol delivery checks are performed. Reception of this 548 packet will incur receive processing as the network stack parses the 549 packet before the packet is delivered to the upper layer protocol. 551 The network layer does not normally have sufficient information to 552 validate that the packet carrying an option originated from the 553 destination (or an on-path node). It also does not typically have 554 sufficient context to demultiplex the packet to identify the related 555 transport flow. This can mean that any changes resulting from 556 reception of the option apply to all flows between a pair of 557 endpoints. 559 These considerations are no different to other uses of Hop-by-Hop 560 options, and this is the use case for PMTUD. The following section 561 describes a mitigation for this attack. 563 8.2. Validating use of the Option Data 565 Transport protocols should be designed to provide protection from 566 data injection attacks by off-path devices and mechanisms should be 567 described in the Security Considerations for each transport 568 specification (see Section 5.1 of the UDP Guidelines [RFC8085]). For 569 example, a TCP or UDP application that maintains the related state 570 and uses a randomised ephemeral port would provide basic protection. 571 TLS [RFC8446] or IPsec [RFC4301] provide cryptographic 572 authentication. An upper layer protocol that validates each received 573 packet discards any packet when this validation fails. In this case, 574 the host MUST also discard the associated Option Data from the 575 minimum Path MTU option without further processing (Section 6.3). 577 A network node on the path has visibility of all packets it forwards. 578 By observing the network packet payload, the node might be able to 579 construct a packet might be validated by the destination host. Such 580 a node would also be able to drop or limit the flow in other ways 581 that could be potentially more disruptive. Authenticating the 582 packet, for example, using IPsec [RFC4301] or TLS [RFC8446] mitigates 583 this attack. 585 8.3. Direct use of the Rtn-PMTU Value 587 The simplest way to utilise the Rtn-PMTU value is to directly use 588 this to update PMTU. This approach results in a set of security 589 issues when the option carries malicious data: 591 * A direct update of the PMTU using the Rtn-PMTU value could result 592 in an attacker inflating or reducing the size of the host PMTU for 593 the destination. Forcing a reduction in the PMTU can decrease the 594 efficiency of network use, might increase the number of packets/ 595 fragments required to send the same volume of payload data, and 596 prevents sending an unfragmented datagram larger than the PMTU. 597 Increasing the PMTU can result in black-holing (see Section 1.1 of 598 [RFC8899]) when the source sends packets larger than the actual 599 PMTU. This persists until the PMTU is next updated. 601 * The method can be used to solicit a response from the destination 602 host. A malicious attacker could forge a packet that cause the 603 sender to add the option to a packet sent to the source. A forged 604 value of Rtn-PMTU in the Option Data might also impact the remote 605 endpoint, as described in the previous bullet. This persists 606 until a valid minimum Path MTU option is received. This attack 607 could be mitigated by limiting the sending of the minimum Path MTU 608 option in reply to incoming packets that carry the option. 610 8.4. Using the Rtn-PMTU Value as a Hint for Probing 612 Another way to utilise the Rtn-PMTU value is to indirectly trigger a 613 probe to determine if the path supports a PMTU of size Rtn-PMTU. 614 This approach needs context for the flow, and hence assumes an upper 615 layer protocol that validates the packet that carries the option 616 Section 8.2. This is the case when used in combination with DPLPMTUD 617 [RFC8899]. A set of security considerations result when an option 618 carries malicious data: 620 * If the forged packet carries a validated option with a non-zero 621 Rtn-PMTU field, the upper layer protocol can utilise the 622 information in the Rtn-PMTU field. A Rtn-PMTU larger than the 623 current PMTU can trigger a probe for a new size. 625 * If the forged packet carries a non-zero Min-PMTU field, the upper 626 layer protocol would change the cached information about the path 627 from the source. The cached information at the destination host 628 will be overwritten when the host receives another packet that 629 includes a minimum Path MTU option corresponding to the flow. 631 * Processing of the option could cause a destination host to add the 632 minimum Path MTU option to a packet sent to the source host. This 633 option will carry a Rtn-PMTU value that could have been updated by 634 the forged packet. The impact of the source host receiving this 635 resembles that discussed previously. 637 8.5. Impact of Middleboxes 639 There is evidence that some middleboxes drop packets that include 640 Hop-by-Hop options. For example, a firewall might drop a packet that 641 carries an unknown extension header or option. This practice is 642 expected to decrease as the option becomes more widely used. Methods 643 to address this are discussed in Section 6.3.5. 645 When a forged packet cause a packet to be sent including the minimum 646 Path MTU option, and the return path does not forward packets with 647 this option, the packet will be dropped Section 6.3.5. This attack 648 is mitigated by validating the option data before use and by limiting 649 the rate of responses generated. An upper layer could further 650 mitigate the impact by responding to a R-Flag by including the option 651 in a packet that does not carry application data. 653 9. Acknowledgments 655 A somewhat similar mechanism was proposed for IPv4 in 1988 in 656 [RFC1063] by Jeff Mogul, C. Kent, Craig Partridge, and Keith 657 McCloghire. It was later obsoleted in 1990 by [RFC1191] the current 658 deployed approach to Path MTU Discovery. 660 Helpful comments were received from Tom Herbert, Tom Jones, Fred 661 Templin, Ole Troan, [Your name here], and other members of the 6MAN 662 working group. 664 10. Change log [RFC Editor: Please remove] 666 draft-ietf-6man-mtu-option-03, 2020-Sept-14 668 * Rewrite to make text and terminology more consistent. 669 * Added the notion of validating the packet before use of the HBH 670 option data. 671 * Method aligned with the way common APIs send/receive HBH option 672 data. 674 * Added reference to DPLPMTUD and clarified upper layer usage. 675 * Completed security considerations section. 677 draft-ietf-6man-mtu-option-02, 2020-March-9 679 * Editorial changes to make text and terminology more consistent. 680 * Added reference to DPLPMTUD. 682 draft-ietf-6man-mtu-option-01, 2019-September-13 684 * Changes to show IANA assigned code point. 685 * Editorial changes to make text and terminology more consistent. 686 * Added a reference to RFC8200 in Section 2 and a reference to 687 RFC6438 in Section 6.3. 689 draft-ietf-6man-mtu-option-00, 2019-August-9 691 * First 6man w.g. draft version. 692 * Changes to request IANA allocation of code point. 693 * Editorial changes. 695 draft-hinden-6man-mtu-option-02, 2019-July-5 697 * Changed option format to also include the Returned PMTU value and 698 Return flag and made related text changes in Section 6.2 to 699 describe this behaviour. 700 * ICMP Packet Too Big messages are no longer used for feedback to 701 the source host. 702 * Added to Acknowledgements Section that a similar mechanism was 703 proposed for IPv4 in 1988 in [RFC1063]. 704 * Editorial changes. 706 draft-hinden-6man-mtu-option-01, 2019-March-05 708 * Changed requested status from Standards Track to Experimental to 709 allow use of experimental option type (11110) to allow for 710 experimentation. Removed request for IANA Option assignment. 711 * Added Section 2 "Motivation and Problem Solved" section to better 712 describe what the purpose of this document is. 713 * Added appendix describing planned experiments and how the results 714 will be measured. 715 * Editorial changes. 717 draft-hinden-6man-mtu-option-00, 2018-Oct-16 719 * Initial draft. 721 11. References 722 11.1. Normative References 724 [IANA-HBH] "Destination Options and Hop-by-Hop Options", 725 . 728 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 729 Requirement Levels", BCP 14, RFC 2119, 730 DOI 10.17487/RFC2119, March 1997, 731 . 733 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 734 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 735 May 2017, . 737 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 738 (IPv6) Specification", STD 86, RFC 8200, 739 DOI 10.17487/RFC8200, July 2017, 740 . 742 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 743 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 744 DOI 10.17487/RFC8201, July 2017, 745 . 747 11.2. Informative References 749 [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP 750 MTU discovery options", RFC 1063, DOI 10.17487/RFC1063, 751 July 1988, . 753 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 754 DOI 10.17487/RFC1191, November 1990, 755 . 757 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 758 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 759 December 1998, . 761 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 762 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 763 December 2005, . 765 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 766 for Equal Cost Multipath Routing and Link Aggregation in 767 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 768 . 770 [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network 771 Virtualization Using Generic Routing Encapsulation", 772 RFC 7637, DOI 10.17487/RFC7637, September 2015, 773 . 775 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 776 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 777 March 2017, . 779 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 780 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 781 . 783 [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. 784 Völker, "Packetization Layer Path MTU Discovery for 785 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 786 September 2020, . 788 [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 789 and F. Gont, "IP Fragmentation Considered Fragile", 790 BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, 791 . 793 Authors' Addresses 795 Robert M. Hinden 796 Check Point Software 797 959 Skyway Road 798 San Carlos, CA 94070 799 United States of America 801 Email: bob.hinden@gmail.com 803 Godred Fairhurst 804 University of Aberdeen 805 School of Engineering 806 Fraser Noble Building 807 Aberdeen 808 AB24 3UE 809 United Kingdom 811 Email: gorry@erg.abdn.ac.uk