idnits 2.17.1 draft-templin-6man-jumbofrag-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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (18 November 2021) is 883 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) == Outdated reference: A later version (-63) exists of draft-templin-6man-aero-36 == Outdated reference: A later version (-74) exists of draft-templin-6man-omni-49 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. L. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Updates: RFC2675 (if approved) 18 November 2021 5 Intended status: Standards Track 6 Expires: 22 May 2022 8 IPv6 Packet Identification 9 draft-templin-6man-jumbofrag-01 11 Abstract 13 Unlike Internet Protocol, version 4 (IPv4), Internet Protocol, 14 version 6 (IPv6) does not include an Identification field in the 15 basic packet header. Instead, IPv6 includes a 32-bit Identification 16 field in a Fragment Header extension since the architecture assumed 17 that the sole purpose for the Identification is to support the 18 fragmentation and reassembly process. This document asserts that 19 per-packet Identifications may be useful for other purposes, e.g., to 20 allow recipients to detect spurious packets that may have been 21 injected into the network by an attacker. But, rather than defining 22 a new extension header, this document recommends employing the 23 existing Fragment Header for per-packet identification even if the 24 packet itself appears as an "atomic fragment". 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 22 May 2022. 43 Copyright Notice 45 Copyright (c) 2021 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 Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. IPv6 Packet Identification . . . . . . . . . . . . . . . . . 3 61 3. RFC2675 Updates . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 3 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 68 8.2. Informative References . . . . . . . . . . . . . . . . . 4 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 71 1. Introduction 73 Unlike Internet Protocol, version 4 (IPv4) [RFC0791], Internet 74 Protocol, version 6 (IPv6) [RFC8200] does not include an 75 Identification field in the basic packet header. Instead, IPv6 76 includes a 32-bit Identification field in a Fragment Header extension 77 since the architecture assumed that the sole purpose for an 78 Identification is to support the fragmentation and reassembly 79 process. This document asserts that per-packet Identifications may 80 be useful for other purposes, e.g., to allow recipients to detect 81 spurious packets that may have been injected into the network by an 82 attacker. But, rather than defining a new extension header, this 83 document recommends employing the existing Fragment Header for per- 84 packet identification even if the packet itself appears as an "atomic 85 fragment". 87 Atomic fragments are defined as "IPv6 packets that contain a Fragment 88 Header with the Fragment Offset set to 0 and the M flag set to 0" 89 [RFC6946]. When an IPv6 source includes a Fragment Header (i.e., 90 either in an atomic fragment or in multiple fragments), only the 91 source itself and not an intermediate IPv6 node on the path is 92 permitted to alter its contents. This is mandated in the base IPv6 93 specification which states "unlike IPv4, fragmentation in IPv6 is 94 performed only by source nodes, not by routers along a packet's 95 delivery path". 97 IPv6 sources that include a Fragment Header include an unpredictable 98 Identification value with each packet [RFC7739]. If the IPv6 source 99 and destination maintain a "window" of acceptable Identification 100 values, this may allow the destination to discern packets originated 101 by the true IPv6 source from spurious packets injected into the 102 network by an attacker. 104 This document therefore asserts that IPv6 sources are permitted to 105 include a Fragment Header in their packet transmissions (i.e., 106 whether as atomic fragments or in multiple fragments) as long as they 107 include suitable unpredictable Identification values. This includes 108 IPv6 "jumbograms" (i.e., packets larger than 65,535 octets [RFC2675]) 109 which can only be prepared as atomic fragments since they are not 110 eligible for fragmentation. Since the current jumbogram 111 specification forbids sources from including a Fragment Header of any 112 kind, this document updates [RFC2675]. 114 2. IPv6 Packet Identification 116 When IPv6 sources and destinations have some way of maintaining 117 "windows" of acceptable Identification values, the destination may be 118 able to examine received packet Identifications to determine whether 119 they likely originated from the source. The AERO 120 [I-D.templin-6man-aero] and OMNI [I-D.templin-6man-omni] 121 specifications discuss methods for maintaining windows of 122 unpredictable values that may reduce attack profiles in some 123 environments. 125 3. RFC2675 Updates 127 The following updates to [RFC2675] are requested: 129 * Section 3, third paragraph, change: "The Jumbo Payload option must 130 not be used in a packet that carries a Fragment header" to: "The 131 Jumbo Payload option must not be used in a packet that carries a 132 non-atomic Fragment header [RFC6946]". 134 * Section 3, in the list of errors, change: "error: Jumbo Payload 135 option present and Fragment header present" to: "error: Jumbo 136 Payload option present and non-atomic Fragment header present". 138 * Add [RFC6946] to Informative References. 140 4. Implementation Status 142 TBD. 144 5. IANA Considerations 146 This document has no IANA considerations. 148 6. Security Considerations 150 Communications networking security is necessary to preserve 151 confidentiality, integrity and availability. 153 7. Acknowledgements 155 This work was inspired by ongoing AERO/OMNI/DTN investigations. 157 . 159 8. References 161 8.1. Normative References 163 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 164 DOI 10.17487/RFC0791, September 1981, 165 . 167 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 168 RFC 2675, DOI 10.17487/RFC2675, August 1999, 169 . 171 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 172 (IPv6) Specification", STD 86, RFC 8200, 173 DOI 10.17487/RFC8200, July 2017, 174 . 176 8.2. Informative References 178 [I-D.templin-6man-aero] 179 Templin, F. L., "Automatic Extended Route Optimization 180 (AERO)", Work in Progress, Internet-Draft, draft-templin- 181 6man-aero-36, 25 October 2021, 182 . 185 [I-D.templin-6man-omni] 186 Templin, F. L. and T. Whyman, "Transmission of IP Packets 187 over Overlay Multilink Network (OMNI) Interfaces", Work in 188 Progress, Internet-Draft, draft-templin-6man-omni-49, 25 189 October 2021, . 192 [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", 193 RFC 6946, DOI 10.17487/RFC6946, May 2013, 194 . 196 [RFC7739] Gont, F., "Security Implications of Predictable Fragment 197 Identification Values", RFC 7739, DOI 10.17487/RFC7739, 198 February 2016, . 200 Author's Address 202 Fred L. Templin (editor) 203 Boeing Research & Technology 204 P.O. Box 3707 205 Seattle, WA 98124 206 United States of America 208 Email: fltemplin@acm.org