idnits 2.17.1 draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-01.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 : ---------------------------------------------------------------------------- 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 (February 28, 2018) is 2248 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSECME Working Group S. Piriyath 3 Internet-Draft U. Mangla 4 Intended status: Standards Track N. Melam 5 Expires: September 1, 2018 R. Bonica 6 Juniper Networks 7 February 28, 2018 9 Packetization Layer Path Maximum Transmission Unit Discovery (PLPMTUD) 10 For IPsec Tunnels 11 draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-01 13 Abstract 15 This document describes Packetization Layer PMTU Discovery (PLPMTUD) 16 procedures for IPSec tunnels. In these procedures, the encrypting 17 node discovers and maintains a running estimate of the tunnel MTU. 18 In order to do this, the encrypting nodes sends Probe Packets of 19 various size through the IPSec tunnel. If the size of Probe Packet 20 exceeds the tunnel MTU, a downstream node discards the packet and 21 sends an ICMP PTB message to the encrypting node. The encrypting 22 node ignores the ICMP PTB message. If the size of the Probe Packet 23 does not exceed the tunnel MTU and the decrypting node receives the 24 Probe Packet, the decrypting node sends an Acknowledgement Packet to 25 encrypting node through the IPSec tunnel. The Acknowledgement Packet 26 indicates the size of the Probe Packet. 28 The procedures described in this document are applicable to IPSec 29 tunnels that are signaled by IKEv2 and provide authentication 30 services. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 1, 2018. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 68 3. PLPMTU Discovery Procedures . . . . . . . . . . . . . . . . . 4 69 3.1. Method of Operation . . . . . . . . . . . . . . . . . . . 4 70 3.2. PLPMTUD Probe . . . . . . . . . . . . . . . . . . . . . . 6 71 3.3. PLPMTUD Acknowledgement . . . . . . . . . . . . . . . . . 8 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 5. ECMP Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 78 8.2. Informative References . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 IPsec [RFC4301] tunnels provides private and/or authenticated 84 connectivity between an encrypting node and a decrypting node. An 85 IPsec tunnel is constrained by the number of bytes that it can convey 86 in a single packet, without fragmentation of any kind. This 87 constraint is called the tunnel Maximum Transmission Unit (MTU). An 88 IPSec tunnel's MTU can be calculated as its Path MTU (PMTU) minus 89 IPSec tunnel overhead, where: 91 o PMTU is the smallest MTU of all the links forming a path between 92 the encrypting node and the decrypting node. 94 o IPSec tunnel overhead is the maximum number of bytes required for 95 padding (by the encryption algorithm) plus the number of bytes 96 required for IPSec encapsulation. 98 When forwarding a packet through an IPSec tunnel, the encrypting node 99 compares the packet's length to the tunnel MTU. If the packet length 100 is less than or equal to the tunnel MTU, the encrypting node encrypts 101 the packet, encapsulates it and forwards it through the IPSec tunnel. 103 If the packet length is greater than the tunnel MTU and the packet 104 cannot be fragmented, the encrypting node discards the packet and 105 sends an ICMP [RFC0792] [RFC4443] Packet Too Big (PTB) message to the 106 packet's source. 108 If the packet length is greater than the tunnel MTU and the packet 109 can be fragmented, the encrypting node can execute either of the 110 following procedures: 112 o Fragment, encrypt and encapsulate (FEE) 114 o Encrypt, encapsulate and fragment (EEF) 116 If the encrypting node executes FEE procedures, it fragments the 117 packet first. Then it encrypts, encapsulates and forwards each 118 fragment. When a fragment arrives at the decrypting node, the 119 decrypting node decapsulates and decrypts the fragment. Finally, the 120 decrypting node forwards the fragment to its ultimate destination, 121 where it can be reassembled. 123 If the encrypting node executes EEF procedures, it encrypts and 124 encapsulates the packet first. Then it fragments the resulting 125 packet and forwards each fragment to the decrypting node. When the 126 decrypting node has received all fragments, it reassembles the 127 packet, decapsulates and decrypts it. Finally, it forwards the 128 packet, in one piece, to its ultimate destination. 130 In the paragraphs above, IPv4 [RFC0791] packets with the Don't 131 Fragment (DF) bit set to zero can be fragmented. IPv6 [RFC8200] 132 packets and IPv4 packets with the DF bit set to one cannot be 133 fragmented. 135 In the above-described procedure, the encrypting node maintains an 136 estimate of the tunnel MTU. Network operators can configure the 137 tunnel MTU on the encrypting node. Alternatively, they can configure 138 the encrypting node to automatically discover and maintain a running 139 estimate of the tunnel MTU. Today, when a encrypting node is 140 configured to automatically discover the tunnel MTU, it executes 141 ICMP-based PMTU Discovery (PMTUD) [RFC1191] [RFC8201] procedures. 142 Having discovered the PMTU, it calculates the tunnel MTU by 143 subtracting the IPSec tunnel overhead from the PMTU. 145 The above-mentioned ICMP-based PMTUD procedures are susceptible to 146 attack [I-D.roca-ipsecme-ptb-pts-attack]. An attacker can forge an 147 ICMP PTB message, setting the MTU to a low value. When the 148 encrypting node receives the forged ICMP PTB message, it decreases 149 its estimate of tunnel MTU, causing unnecessary fragmentation. 150 Therefore, many IPsec implementations do not implement tunnel MTU 151 discovery at all. 153 This document describes Packetization Layer PMTU Discovery (PLPMTUD) 154 procedures for IPSec tunnels. In these procedures, the encrypting 155 node discovers and maintains a running estimate of the tunnel MTU. 156 In order to do this, the encrypting nodes sends Probe Packets of 157 various size through the IPSec tunnel. If the size of Probe Packet 158 exceeds the tunnel MTU, a downstream node discards the packet and 159 sends an ICMP PTB message to the encrypting node. The encrypting 160 node ignores the ICMP PTB message. If the size of the Probe Packet 161 does not exceed the tunnel MTU and the decrypting node receives the 162 Probe Packet, the decrypting node sends an Acknowledgement Packet to 163 encrypting node through the IPSec tunnel. The Acknowledgement Packet 164 indicates the size of the Probe Packet. Unlike ICMP PTB messages, 165 this Acknowledgement Packet cannot be forged. 167 The procedures described in this document are applicable to IPSec 168 tunnels that are signaled by Internet Key Exchange version 2 (IKEv2) 169 [RFC7296] and provide authentication services. 171 2. Requirements Language 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 175 "OPTIONAL" in this document are to be interpreted as described in BCP 176 14 [RFC2119] [RFC8174] when, and only when, they appear in all 177 capitals, as shown here. 179 3. PLPMTU Discovery Procedures 181 3.1. Method of Operation 183 A special loopback interface is configured on the encrypting and 184 decrypting nodes. In this document, these loopback interfaces are 185 called the IPSec PLPMTUD interfaces. 187 The encrypting node executes IKEv2 procedures to signal an IPSec 188 tunnel between itself and a decrypting node. The IPSec tunnel MUST 189 provide authentication services. It MAY also provide privacy 190 services. If the outermost header of the IPSec tunnel is an IPv4 191 header, the DF bit must be set. IKEv2 endpoints MUST exchange 192 traffic selectors advertising their IPSec PLPMTUD interface 193 addresses. Implementations MUST ensure that traffic from one IPSec 194 PLPMTUD address to another traverses the appropriate tunnel using the 195 correct security association. 197 As part of the tunnel establishment process, the encrypting node 198 produces an initial estimate of the tunnel MTU. The encrypting 199 node's initial estimate of the tunnel MTU is equal to its initial 200 PMTU estimate minus IPSec tunnel overhead, where: 202 o The initial PMTU estimate is equal to the MTU of the first link 203 along the path between the encrypting node and the decrypting 204 node. 206 o IPSec tunnel overhead is the maximum number of bytes required for 207 padding (by the encryption algorithm) plus the number of bytes 208 required for IPSec encapsulation. 210 This initial estimate may be greater than the actual tunnel MTU. 212 Having established the IPSec tunnel, the ingress node begins to 213 refine its estimate of the tunnel MTU. It MAY pass traffic through 214 the tunnel as it refines the tunnel MTU estimate. 216 In order to refine its estimate of the tunnel MTU, the ingress node 217 executes the Packetization Layer PMTU Discovery (PLPMTUD) procedures 218 described in Section 4 of [I-D.fairhurst-tsvwg-datagram-plpmtud]. 219 When applied to IPSec tunnels, these procedures can be summarized as 220 follows: 222 o The encrypting node sends Probe Packets of various size through 223 the IPSec tunnel. 225 o If the size of the Probe Packet exceeds the tunnel MTU, a 226 downstream device drops the packet and sends an ICMP Packet Too 227 Big (PTB) message to the encrypting node. The encrypting node 228 ignores the ICMP PTB message. 230 o If the Probe Packet reaches the decrypting node, the decrypting 231 node acknowledges receipt of the Probe Packet. 233 Section 3.2 of this document describes the Probe Packet. Section 3.3 234 of this document describes how the decrypting node acknowledges 235 receipt of the Probe Packet. 237 3.2. PLPMTUD Probe 239 The encrypting node can probe the IPSec tunnel using an IPv4 packet 240 or an IPv6 packet. Figure 1 depicts the IPv4 Probe Packet while 241 Figure 2 depicts the IPv6 Probe Packet. In either case, the 242 encrypting node forwards the Probe Packet through the IPSec tunnel. 244 0 1 2 3 245 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 246 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | |Version| IHL |Type of Service| Total Length | 248 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | | Identification |Flags| Fragment Offset | 250 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | | Time to Live | Protocol | Header Checksum | 252 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 IPv4 | Source Address | 254 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | | Destination Address | 256 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | | Source Port | Dest Port | 258 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | | UDP Length | UDP Checksum | 260 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | |P| Reserved | 262 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | | | 264 | // Padding // 265 | | | 266 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Figure 1: IPv4 Probe Packet 270 0 1 2 3 271 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 272 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | |Version| Traffic Class | Flow Label | 274 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | | Payload Length | Next Header | Hop Limit | 276 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | | | 278 | + + 279 | | | 280 | + Source Address + 281 IPv6 | | 282 | + + 283 | | | 284 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | | | 286 | + + 287 | | | 288 | + Destination Address + 289 | | | 290 | + + 291 | | | 292 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | | Source Port | Dest Port | 294 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | | UDP Length | UDP Checksum | 296 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | |P| Reserved | 298 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | | | 300 | // Padding // 301 | | | 302 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 2: IPv6 Probe Packet 306 Regardless of whether the Probe Packet is IPv4 or IPv6: 308 o The Source Address is the encrypting node's IPSec PLPMTUD 309 interface address. 311 o The Destination Address is the decrypting node's IPSec PLPMTUD 312 interface address. 314 o The Source Port is chosen from the dynamic port range 315 (49152-65535) [RFC6335] 317 o The Destination Port is equal to IPSec PLPMTUD. (Value TBD by 318 IANA). 320 o The P-bit is set to indicate that this is a Probe Packet. 322 o The Reserved Field MUST be set to zero and MUST be ignored upon 323 receipt. 325 o The Padding field is used to vary the size of the packet. 327 3.3. PLPMTUD Acknowledgement 329 When the decrypting node receives a Probe Packet, it returns an 330 Acknowledgment Packet. The Acknowledgment Packet can be an IPv4 331 packet or an IPv6 packet. Figure 3 depicts the IPv4 Acknowledgment 332 Packet while Figure 4 depicts the IPv6 Acknowledgment Packet. In 333 either case, the decrypting node forwards the Acknowledgment Packet 334 through the IPSec tunnel that connects it to the encrypting node. 336 0 1 2 3 337 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 338 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | |Version| IHL |Type of Service| Total Length | 340 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | | Identification |Flags| Fragment Offset | 342 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | | Time to Live | Protocol | Header Checksum | 344 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 IPv4 | Source Address | 346 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | | Destination Address | 348 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | | Source Port | Dest Port | 350 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 UDP | UDP Length | UDP Checksum | 352 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | |P| Reserved | Probe Length | 354 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Figure 3: IPv4 Acknowledgement Packet 358 0 1 2 3 359 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 360 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | |Version| Traffic Class | Flow Label | 362 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | | Payload Length | Next Header | Hop Limit | 364 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | | | 366 | + + 367 | | | 368 | + Source Address + 369 IPv6 | | 370 | + + 371 | | | 372 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | | | 374 | + + 375 | | | 376 | + Destination Address + 377 | | | 378 | + + 379 | | | 380 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | | Source Port | Dest Port | 382 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 UDP | UDP Length | UDP Checksum | 384 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | |P| Reserved | Probe Length | 386 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 Figure 4: IPv6 Acknowledgement Packet 390 Regardless of whether the Acknowledgment Packet is IPv4 or IPv6: 392 o The Source Address is copied from the Destination Address of the 393 corresponding Probe Packet 395 o The Destination Address is copied from the Source Address of the 396 corresponding Probe Packet 398 o The Source Port is copied from the Destination Port of the 399 corresponding Probe Packet 401 o The Destination Port copied from the Source Port of the 402 corresponding Probe Packet 404 o The P-bit is clear to indicate that this is an Acknowledgement 405 Packet. 407 o The Reserved Field MUST be set to zero and MUST be ignored upon 408 receipt. 410 o The Probe length represents the total length of the corresponding 411 Probe Packet, measured in bytes and not counting IPSec overhead 413 4. Security Considerations 415 The procedures described herein are an improvement upon ICMP-based 416 PMTUD procedures because unlike ICMP PTB messages, the 417 Acknowledgement Packets described herein cannot be forged. 419 The decrypting node MUST protect the encrypting node from forged 420 Acknowledgement Packets. Therefore, the decrypting MAY originate 421 packets whose source address is its PLPMTUD interface address. 422 However, it MUST NOT forward packets whose source address is its 423 PLPMTUD interface address. 425 5. ECMP Considerations 427 Packets traversing a network, with multi paths (ECMP), would end up 428 picking the lowest MTU available in any of the ECMP paths, when the 429 proposed solution is employed (assuming that paths have different MTU 430 values for the sake of analysis). This might cause some additional 431 load on the encryption end, due to the lower MTU level fragmentation. 432 This wouldn't be a major issue, as even otherwise, these loads would 433 have got processed on the receiving side (decryption side) for 434 reassembly and holding the packets in memory. It is worth noting 435 that, at the encryption side it is more of 'stateless' action in 436 terms of packet fragmentation is concerned as compared to at 437 decryption side it is more of a 'stateful' action, where in, it need 438 to maintain the fragments queue for reassembly. Moreover, reassembly 439 node has no control over arrival of the fragments. So, when a choice 440 has to be made for loading the end between encryption and decryption 441 end, it is always better to load the encryption side due to the fact 442 that the operation is stateless and less costly to perform 443 comparatively. 445 6. IANA Considerations 447 IANA is request to allocate a UDP port called "IPSec PLPMTUD" from 448 the Registered Port Range (1024 to 49151). 450 7. Acknowledgements 452 Thanks to Yoav Nir, Joe Touch, and Dan Wing for their review and 453 comments. 455 8. References 457 8.1. Normative References 459 [I-D.fairhurst-tsvwg-datagram-plpmtud] 460 Fairhurst, G., Jones, T., Tuexen, M., and I. Ruengeler, 461 "Packetization Layer Path MTU Discovery for Datagram 462 Transports", draft-fairhurst-tsvwg-datagram-plpmtud-02 463 (work in progress), December 2017. 465 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 466 DOI 10.17487/RFC0791, September 1981, 467 . 469 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 470 RFC 792, DOI 10.17487/RFC0792, September 1981, 471 . 473 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 474 DOI 10.17487/RFC1191, November 1990, 475 . 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, 479 DOI 10.17487/RFC2119, March 1997, 480 . 482 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 483 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 484 December 2005, . 486 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 487 Control Message Protocol (ICMPv6) for the Internet 488 Protocol Version 6 (IPv6) Specification", STD 89, 489 RFC 4443, DOI 10.17487/RFC4443, March 2006, 490 . 492 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 493 Cheshire, "Internet Assigned Numbers Authority (IANA) 494 Procedures for the Management of the Service Name and 495 Transport Protocol Port Number Registry", BCP 165, 496 RFC 6335, DOI 10.17487/RFC6335, August 2011, 497 . 499 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 500 Kivinen, "Internet Key Exchange Protocol Version 2 501 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 502 2014, . 504 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 505 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 506 May 2017, . 508 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 509 (IPv6) Specification", STD 86, RFC 8200, 510 DOI 10.17487/RFC8200, July 2017, 511 . 513 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 514 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 515 DOI 10.17487/RFC8201, July 2017, 516 . 518 8.2. Informative References 520 [I-D.roca-ipsecme-ptb-pts-attack] 521 Roca, V. and S. Fall, "Too Big or Too Small? The PTB-PTS 522 ICMP-based Attack against IPsec Gateways", draft-roca- 523 ipsecme-ptb-pts-attack-00 (work in progress), July 2015. 525 Authors' Addresses 527 Shibu Piriyath 528 Juniper Networks 529 Elnath-Exora Business Park 530 Bangalore, KA 93117 531 India 533 Email: spiriyath@juniper.net 535 Umesh Mangla 536 Juniper Networks 537 1133 Innovation Way 538 Sunnyvale, CA 94089 539 USA 541 Email: umangla@juniper.net 543 Nagavenkata Suresh Melam 544 Juniper Networks 545 1133 Innovation Way 546 Sunnyvale, CA 94089 547 USA 549 Email: nmelam@juniper.net 550 Ron Bonica 551 Juniper Networks 552 2251 Corporate Park Drive 553 Herndon, Virginia 20171 554 USA 556 Email: rbonica@juniper.net