idnits 2.17.1 draft-hain-ipv6-fwrh-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 : ---------------------------------------------------------------------------- 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 10, 2010) is 5039 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) == Unused Reference: 'RFC5095' is defined on line 487, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hain 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track July 10, 2010 5 Expires: January 11, 2011 7 IPv6 Firewall Routing Header 8 draft-hain-ipv6-fwrh-03 10 Abstract 12 This document specifies a routing header for use by firewalls to 13 enforce routing symmetry. 15 The draft is being discussed on the ipv6@ietf.org list. 17 Legal 19 This documents and the information contained therein are provided on 20 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 21 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 22 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 23 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 24 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 25 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 26 FOR A PARTICULAR PURPOSE. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 11, 2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3.2. Firewall Routing Header Option . . . . . . . . . . . . . . 6 79 3.3. Routing Header Required ICMP Message . . . . . . . . . . . 8 80 3.4. ***** This needs to be a separate Doc ***** 81 ReturnPathForwarding ICMP Error Message . . . . . . . . . 9 82 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 86 8. Pending comments . . . . . . . . . . . . . . . . . . . . . . . 13 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 89 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 1. Introduction 94 With the deprecation of RH0 [RFC5095]the ability of a node to 95 influence traffic to traverse the same firewall in opposing 96 directions was eliminated. Operation of stateful firewalls requires 97 path symmetry at least through that device. The likelihood of 98 asymmetry is particularly true on the Internet side, but is also a 99 problem when the exit path changes on the private side during an 100 established packet exchange. This document targets the specific use 101 case of symmetric firewall selection, and then defines an IPv6 102 Firewall Routing Header and associated IPv6 ICMP error messages. 103 Other use cases may take advantage of these mechanisms, but are 104 explicitly out of scope for the development and definition here. 105 Also, this option is not trying to solve every possible topology of 106 firewall deployments, or source of asymmetry, but is should be useful 107 for the most common existing deployments. 109 While this Firewall Routing Header mechanism allows for changes in 110 the firewalls in use during a packet exchange, any mechanisms that 111 would be used to pass state between disperse firewalls is out of 112 scope here. If those state passing mechanisms exist, it will be 113 possible for an end-to-end packet exchange to persist during a 114 routing shift, even over vast geographic path changes. Since the 115 ability to force routing through a single intermediary can be used by 116 attackers to receive traffic they otherwise would not, the ICMP error 117 messages used here should be integrity protected, and in any event 118 should be dropped if originating outside of a policy domain. The 119 method that a node would use to verify that signature is out of scope 120 here. 122 2. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 3. Mechanisms 130 3.1. Overview 132 To deal with the asymmetry issue, a function specific IPv6 routing 133 header is defined, the Firewall Routing Header (FWRH). This routing 134 header is used to pass information to a correspondent, so that return 135 packets are routed through a firewall that is maintaining state for 136 this transaction. In the case where an organization deploys multiple 137 firewalls from different vendors in series to reduce vendor specific 138 issues, this option would be related to the most public facing 139 firewall of the set. A flag (Origin Flag) will be used to indicate 140 which instance this is in the case where there are firewalls on each 141 end (note: this assumes that a firewall would allow an initial 142 inbound packet, then enforce subsequent packets through itself). 143 There can be at most 2 (one with each value of the Origin Flag) 144 FWRH's in any given extension header chain. 146 An originating node is probably unaware of the presence of a firewall 147 on its path to any given destination, so it will likely send an 148 initial packet without the FWRH option. (It may have cached the 149 value received in a prior ICMP error message for non-local prefixes, 150 and if so can optimistically minimize the chance for an initial error 151 by including the cached value in the optional FWRH.) On receipt of 152 any ICMP Routing Header Required message, the origin node will 153 extract the return-via address from the ICMP, optionally verify any 154 signature that may be present, then cache it for use over the 155 lifetime of the current packet exchange, and optionally for use with 156 other non-local prefixes. The packet which generated the error is 157 reconstructed with the appropriate FWRH option, and resent. If the 158 FWRH option with the appropriate Origin Flag value is missing when a 159 packet is being sent outbound (from the perspective of the firewall - 160 private toward public), or if the return-via address in the FWRH 161 option does not match any address on the firewall that is processing 162 the packet, an ICMP error (RHR type ???) is returned to the source 163 address of the packet, indicating the value that is expected to 164 result in return-path symmetry through an interface on this specific 165 firewall. That ICMP error SHOULD be signed, and if so the ICMP 166 packet indicates which signing method was used. Outbound packets 167 with the matching Origin Flag and return-via address will receive 168 normal firewall handling before forwarding. If the source address 169 prefix does not match any prefix that being exchanged in routing 170 protocols with the next hop, an RPF-error (type ???+1) ICMP message 171 should be returned. 173 The correspondent node will extract the return-via address from a 174 received FWRH option with an Origin Flag that is opposite the one it 175 will use when sending, and cache it for use related to this specific 176 packet exchange. When constructing packets related to this specific 177 exchange; after all normal processing is complete, the ultimate 178 destination address will be swapped into the FWRH with the 179 appropriate Origin Flag, and the previously cached value from any 180 received FWRH with the opposing Origin Flag will be swapped as the 181 initial destination address of the packet. 183 Inbound packets to the public side of a firewall will be addressed 184 with it as the destination address of the base IPv6 header, and the 185 FWRH with the Origin flag matching existing state will contain the 186 address of the ultimate destination. The contents of the FWRH with 187 the matching Origin flag will be swapped with the destination 188 addresses in the packet, before normal firewall processing and 189 forwarding. 191 3.2. Firewall Routing Header Option 193 The Firewall Routing header is used by an IPv6 source to list a 194 single intermediate node to be "visited" by returning packets. The 195 Firewall Routing header is identified by a Next Header value of 43 in 196 the immediately preceding header, and has the following format: 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Next Header | Hdr Ext Len | Routing Type | Flags | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Reserved | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | | 206 + Address + 207 | return-via or | 208 + ultimate destination + 209 | | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Next Header 8-bit selector. 213 Identifies the type of header immediately following the 214 Routing header. Uses the same values as the IPv4 Protocol 215 field [RFC-1700 et seq.]. 217 Hdr Ext Len 8-bit unsigned integer. Length of the Routing 218 header in 8-octet units, not including the first 8 octets. 220 Routing Type 8-bit identifier of this particular Routing 221 header variant. 223 Origin Flag The Origin Flag (Flags - bit 0) 224 is used to indicate the direction that corresponds to 225 this instance of the FWRH. A value of 1 indicates 226 that a firewall exists in the initial packet direction 227 (for TCP this is the SYN), while a value of 0 indicates 228 that a firewall exists in the response direction 229 (for TCP this is the SYN-ACK). 231 Reserved 32-bit reserved field. 232 Initialized to zero for transmission; ignored on reception. 234 Address Direction/location dependent address, 235 where from the origin node toward a correspondent it 236 contains the address of the firewall to be returned 237 through and from the correspondent to the intermediate 238 firewall contains the ultimate destination address 239 that the firewall will deliver the packet to. 241 **** Within an enterprise network both FWRH options might contain the 242 same address if there was an audit function, or traffic engineering 243 reason to route both directions through the same mid-point. 245 A FWRH option SHOULD NOT contain an address that matches either the 246 source or destination addresses of the packet. If there are two FWRH 247 options present: Their Origin Flag values MUST be different Both 248 options SHOULD NOT contain the same address 250 3.3. Routing Header Required ICMP Message 252 Informing the originating endpoint that it needs to insert a routing 253 header is accomplished with a specific ICMP error - 'Routing Header 254 Required' (type ???). This ICMP error may optionally be signed to 255 mitigate a man-in-the-middle attack vector which could be used to 256 route all return-path traffic through an attacker's node. 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Type | Code | Checksum | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Reserved | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | | 266 + + 267 | Return-Via IPv6 address | 268 + + 269 | | 270 + + 271 | | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | MAC-type | MAC-length | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | | 276 + + 277 | Message Authentication Code | 278 + + 279 | | 280 + + 282 IPv6 Fields: 284 Destination Address 286 Copied from the Source Address field of the 287 invoking packet. 289 ICMPv6 Fields: 291 Type ???? --- 5 292 Code 0 - unsigned 293 1 - signed 295 Reserved 32-bit reserved field. Initialized to zero 296 for transmission; ignored on reception. 298 MAC-type 0 - unused 299 1 - HMAC-SHA1 300 2 - AES-CMAC 301 ... 303 MAC-length Length of the message authentication option 305 MAC Value of the message authenticator 307 The optional authentication covers the source and destination address 308 of this specific packet exchange, plus the return-via address. 310 3.4. ***** This needs to be a separate Doc ***** ReturnPathForwarding 311 ICMP Error Message 313 Informing the origin that the source prefix is not appropriate for 314 the next hop as a symmetric return path. 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type | Code | Checksum | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Prefix Length | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | | 323 + + 324 | Source Prefix for this Path | 325 + + 326 | | 327 + + 328 | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | MAC-type | MAC-length | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | | 333 + + 334 | Message Authentication Code | 335 + + 336 | | 337 + + 339 IPv6 Fields: 341 Destination Address 343 Copied from the Source Address field of the 344 invoking packet. 346 ICMPv6 Fields: 348 Type ???? --- 6 350 Code 0 - unsigned 351 1 - signed 353 Reserved 32-bit reserved field. Initialized to zero 354 for transmission; ignored on reception. 356 MAC-type 0 - unused 357 1 - HMAC-SHA1 358 2 - AES-CMAC 359 ... 361 MAC-length Length of the message authentication option 363 MAC Value of the message authenticator 365 The optional authentication covers the source and destination address 366 of this specific packet exchange, plus the return-via address. 368 4. Examples 370 Example 1 - Single firewall connecting a private network to the 371 Internet. 373 A FW1 B 374 |__Private__| |__Internet__| 376 Initial packet exchange sequence - 377 A ->> DST = B 378 FW1 ICMP(5) <<- DST = A : SRC = FW1(P) : value - FW1(I) 379 A ->> DST = B : FWRH(OF=1) = FW1(I) 380 B <<- DST = FW1(I) : FWRH(OF=1) = A 381 FW1 <<- DST = A : FWRH(OF=1) = FW1(I) 382 A ->> DST = B : FWRH(OF=1) = FW1(I) 383 B <<- DST = FW1(I) : FWRH(OF=1) = A 384 FW1 <<- DST = A : FWRH(OF=1) = FW1(I) 385 ... 387 Figure 1 389 In this case as node A attempts to connect to node B, FW1 rejects the 390 first attempt with an error message informing that the FWRH is 391 required. The subsequent packet including the FWRH with Origin Flag 392 set is forwarded by FW1 toward B. B sends the return packet to FW1, 393 where the DST is swapped with the locator for A in the FWRH with the 394 Origin Flag set. 395 A FW1 B 396 |__Private__| |__Internet__| 397 | | 398 FW2 _ Internet _| 400 Initial packet exchange sequence - 401 A ->> DST = B 402 FW1 ICMP(5) <<- DST = A : SRC = FW1(P) : value - FW1(I) 403 A ->> DST = B : FWRH(OF=1) = FW1(I) 404 B <<- DST = FW1(I) : FWRH(OF=1) = A 405 FW1 <<- DST = A : FWRH(OF=1) = FW1(I) 406 --- FW1 dies 407 A ->> DST = B : FWRH(OF=1) = FW1(I) 408 FW2 ICMP(5) <<- DST = A : SRC = FW2(P) : value - FW2(I) 409 FW2 ICMP(6) <<- DST = A : SRC = FW2(P) : value - /48 FW2(I) 410 A ->> DST = B : FWRH(OF=1) = FW2(I) 411 B <<- DST = FW2(I) : FWRH(OF=1) = A 412 FW2 <<- DST = A : FWRH(OF=1) = FW1(I) 413 ... 415 Figure 2 417 This case is the same as above, except there is an alternate firewall 418 available to A. At some point after the connection is established, 419 FW1 dies, and routing redirects packets to B through FW2. FW2 has 420 acquired state from FW1, so the connection between A & B does not 421 have to be reset, but FW2 still rejects the next packet with an error 422 message informing that the FWRH does not have the public address of 423 FW2. The subsequent packet including the FWRH with Origin Flag set 424 is forwarded by FW2 toward B. B sends the return packet to FW2, where 425 the DST is swapped with the locator for A in the FWRH with the Origin 426 Flag set. 427 A FW1 FW2 B 428 |__Private__| |__Internet__| |__Private__| 430 Initial packet exchange sequence - 431 A ->> DST = B 432 FW1 ICMP(5) <<- DST = A : SRC = FW1(P) : value - FW1(I) 433 A ->> DST = B : FWRH(OF=1) = FW1(I) 434 FW2 ->> (presumes that FW2 allows initial pkt without state) 435 B <<- DST = FW1(I) : FWRH(OF=1) = A 436 FW2 ICMP(5) ->> DST = B : SRC = FW2(P) : value - FW2(I) 437 B <<- DST = FW1(I) : FWRH(OF=1) = A : FWRH(OF=0) = FW2(I) 438 FW1 <<- DST = A : FWRH(OF=1) = FW1(I) : FWRH(OF=0) = FW2(I) 439 A ->> DST= FW2(I) : FWRH(OF=1) = FW1(I) : FWRH(OF=0) = B 440 FW2 ->> DST = B : FWRH(OF=1) = FW1(I) : FWRH(OF=0) = FW2(I) 441 ... 443 Figure 3 445 In this case there are firewalls at each end, and both require a 446 FWRH. The value of the Origin Flag identifies which FWRH option is 447 associated with each firewall. Note that before forwarding to the 448 private side of each firewall, the DST & FWRH(OF=1) was swapped at 449 FW1, while DST & FWRH(OF=0) was swapped at FW2. 451 5. IANA Considerations 453 This specification registers a Routing Header type & two ICMP message 454 types 456 6. Security Considerations 458 A routing header is used to cause packets to traverse a specific 459 node, and if used maliciously would allow an attacker to see all 460 packets in an exchange. The risk of this attack is minimized by 461 filtering out any ICMP Routing Header Required and ICMP RPF-error 462 messages that originate outside the policy domain, and/or signing & 463 verifying those ICMP error messages when generated internally. 465 7. Acknowledgements 467 The need to resolve routing symmetry for firewalls was initially 468 championed by William Dixon, and discussed with many attendees at 469 IETF 74. 471 8. Pending comments 473 It has been suggested the Origin Flag model will fail in 474 simultaneous-open situations. Recommendation to change the OF to 475 indicate src < dst. If that was done as a rule, there wouldn't need 476 to be a flag. 478 9. References 480 9.1. Normative References 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, March 1997. 485 9.2. Informative References 487 [RFC5095] Abley, J., "Deprecation of Type 0 Routing Headers in 488 IPv6", RFC 5095, December 2007. 490 Author's Address 492 Tony Hain 493 Cisco Systems 494 500 108th Ave NE 495 Bellevue, WA 98004 496 USA 498 Phone: +1 425 468-1061 499 Email: alh-ietf@tndh.net