idnits 2.17.1 draft-smith-6man-more-secure-rh-03.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 draft header indicates that this document updates RFC5095, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC8200, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5095, updated by this document, for RFC5378 checks: 2007-05-16) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (23 February 2022) is 793 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: 'IANA-TBD' is mentioned on line 151, but not defined ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M.R. Smith 3 Internet-Draft 23 February 2022 4 Updates: 5095, 8200 (if approved) 5 Intended status: Standards Track 6 Expires: 27 August 2022 8 More Secure IPv6 Routing Header Processing 9 draft-smith-6man-more-secure-rh-03 11 Abstract 13 The original IPv6 Type 0 Routing Header has been deprecated due to 14 the security risk of a packet forwarding loop being formed, by 15 specifying a large sequence of alternating IPv6 node addresses to 16 visit. This memo proposes a method to prevent these forwarding loops 17 forming, allowing the IPv6 Type 0 Routing Header to be more securely 18 and more safely used. The method may also be applicable to other 19 unicast source routing scenarios. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 27 August 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. The Fundamental Problem . . . . . . . . . . . . . . . . . . . 3 56 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 5. ICMPv6 Destination Unreachable, Routing Header RPF Check 59 Failed . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 6. Updates to RFC8200 . . . . . . . . . . . . . . . . . . . . . 4 61 7. More General Applicability . . . . . . . . . . . . . . . . . 4 62 8. Inspiration . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 66 12. Change Log [RFC Editor please remove] . . . . . . . . . . . . 5 67 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 13.1. Normative References . . . . . . . . . . . . . . . . . . 5 69 13.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 [RFC5095] deprecated the IPv6 Type 0 Routing Header as it could be 75 used to create a traffic loop, by specifying a large sequence of 76 alternating IPv6 node addresses to visit. This traffic loop could 77 consume large amounts of network capacity, causing congestion, and 78 possibly a network capacity denial of service attack. (The packets 79 caught in the forwarding loop would eventually be dropped as their 80 hop-count field will eventually reach zero.) 82 This memo specifies a method of preventing these traffic loops 83 occurring, which allows the IPv6 Type 0 to be more securely and more 84 safely used. This method may also be applicable to other unicast 85 source routing scenarios. 87 2. The Fundamental Problem 89 The fundamental problem with the type 0 RH, and other source Routing 90 Headers that support multiple routing hops in general, is that 91 packets can be made to travel back towards where they've come from. 92 This then facilitates the first step of a packet being able to enter 93 a forwarding loop. 95 3. Solution 97 Packets need to be prevented from travelling back towards where 98 they've come from, which then prevents a forwarding loop from being 99 formed. 101 The problem of packets going back towards where they've come from 102 exists in multicast, and has been solved by performing a Reverse Path 103 Forwarding (RPF) check on a packet as part of the multicast 104 forwarding procedure. 106 This RPF check ensures that a packet does not leave via the router in 107 direction back towards the packet's source address. This direction 108 back towards the packet's source may be via the packet's ingress 109 interface, or a different egress interface back towards the packet's 110 source in an asymmetric routing scenario. 112 This memo specifies that a Reverse Path Forwarding Check is peformed 113 when processing the IPv6 Type 0 Routing Header to prevent the packet 114 going back towards its source. 116 [RFC3704], although describing RPF checks to prevent source IP 117 address spoofing, provides good descriptions of the RPF checking 118 process. 120 4. Method 122 The following method is used to process IPv6 Type 0 Routing Headers 123 while also preventing their packets from entering a forwarding loop. 125 1. Perform the Type 0 Routing Header processing algorithm as 126 specified in [RFC2460], section 4.4. This will result in the 127 packet's Type 0 Routing Header and Destination Address being 128 updated to the next address specified in the routing header to 129 visit. 131 2. Perform an RPF check against the updated packet. 133 3. If the packet is to now travel back towards its source, discard 134 the packet, and generate an ICMPv6 Destination Unreachable, 135 Routing Header RPF Check Failed error (specified below), sending 136 it to the packet's source (address). 138 4. Otherwise, forward the packet to its new Destination Address. 140 Note that an implementation could perform the RPF check against the 141 next address specified in the Type 0 Routing Header before updating 142 the packet's Type 0 Routing Header and Destination Address field as a 143 processing optimisation. If the RPF check fails in this case, the 144 packet's Type 0 Routing Header and Destination Address will need to 145 be updated so that it can then be correctly used as the message body 146 for the ICMPv6 Destination Unreachable error message [RFC4443]. 148 5. ICMPv6 Destination Unreachable, Routing Header RPF Check Failed 150 A new ICMPv6 Destination Unreachable error message is defined for a 151 "Routing Header RPF Check Failed", Type 1, Code [IANA-TBD]. 152 Processing of this error message is as per the general Destination 153 Unreachable message processing specified in [RFC4443]. There is no 154 special handling of this error message at the receiver. 156 6. Updates to RFC8200 158 This memo makes the reason for the IPv6 Type 0 Routing Header 159 deprecation invalid. Consequently, [RFC8200] is updated to now 160 specify the Type 0 Routing Header formerly specified in [RFC2460]. 162 7. More General Applicability 164 The method of preventing a packet or a frame from travelling back 165 towards its origin when being forwarded can be applied to any unicast 166 source routing scenario where a forwarding loop is possible. 168 Examples of where it could be applied are the IPv6 Segment Routing 169 Header [RFC8754], Segment Routing over MPLS [RFC8660], the IPv6 170 Compressed Rouing Header [CRH] and IPv4 [RFC0791]. 172 8. Inspiration 174 The idea of using an RPF check to prevent forwarding loops when 175 performing unicast source routing was inspired by using an RPF check 176 to prevent forwarding loops in hop-by-hop forwarding through the 177 network using an anycast IPv6 address [FFANYCAST]. In this scenario, 178 a packet is forwarded towards the next closest instance of the 179 anycast address in the network, excluding anycast address instances 180 that are back towards the packet's source. 182 9. Security Considerations 184 This memo addresses the primary security issue that caused the Type 0 185 Routing Header to be deprecated. 187 This memo does not address other security issues related to routing 188 headers and source routing, such as using a routing header to bypass 189 a security policy enforcement device, or untrusted packets with 190 routing headers entering a routing header trusting domain. Other 191 mitigations to these security issues, such as source address 192 filtering at ingress to the local network, or packet authentication 193 [RFC4302], need to be deployed. 195 10. IANA Considerations 197 IANA are requested to allocate a suitable Type 1 Destination 198 Unreachable error code for "Routing Header RPF Check Failed". 200 11. Acknowledgements 202 Review and comments were provided by YOUR NAME HERE! 204 This memo was prepared using the xml2rfc tool. 206 12. Change Log [RFC Editor please remove] 208 draft-smith-6man-more-secure-rh-00, initial version, 2022-02-14 210 draft-smith-6man-more-secure-rh-01, 2022-02-17 212 * IEEE 802.2 Source Route Bridging does a check for a forwarding 213 loop when forwarding. 215 * Better wording and minor corrections. 217 draft-smith-6man-more-secure-rh-02, 2022-02-24 219 * Hop-by-hop anycast inspiration 221 draft-smith-6man-more-secure-rh-03, 2022-02-24 223 * Extra greater than sign 225 13. References 227 13.1. Normative References 229 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 230 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 231 December 1998, . 233 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 234 Control Message Protocol (ICMPv6) for the Internet 235 Protocol Version 6 (IPv6) Specification", STD 89, 236 RFC 4443, DOI 10.17487/RFC4443, March 2006, 237 . 239 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 240 (IPv6) Specification", STD 86, RFC 8200, 241 DOI 10.17487/RFC8200, July 2017, 242 . 244 13.2. Informative References 246 [CRH] "The IPv6 Compact Routing Header (CRH)", 247 . 250 [FFANYCAST] 251 "IPv6 Formal Anycast Addresses and Functional Anycast 252 Addresses", . 255 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 256 DOI 10.17487/RFC0791, September 1981, 257 . 259 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 260 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 261 2004, . 263 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 264 DOI 10.17487/RFC4302, December 2005, 265 . 267 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 268 of Type 0 Routing Headers in IPv6", RFC 5095, 269 DOI 10.17487/RFC5095, December 2007, 270 . 272 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 273 Decraene, B., Litkowski, S., and R. Shakir, "Segment 274 Routing with the MPLS Data Plane", RFC 8660, 275 DOI 10.17487/RFC8660, December 2019, 276 . 278 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 279 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 280 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 281 . 283 Author's Address 285 Mark Smith 286 PO BOX 521 287 HEIDELBERG VIC 3084 288 Australia 289 Email: markzzzsmith@gmail.com