idnits 2.17.1 draft-ietf-mext-firewall-admin-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (October 27, 2009) is 5267 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-ietf-mext-firewall-vendor-0 - is the name correct? ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 2 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 S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Informational N. Steinleitner 5 Expires: April 30, 2010 University of Goettingen 6 Y. Qiu 7 Institute for Infocomm Research 8 G. Bajko 9 Nokia 10 October 27, 2009 12 Guidelines for firewall administrators regarding MIPv6 traffic 13 draft-ietf-mext-firewall-admin-02 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 30, 2010. 38 Copyright Notice 40 Copyright (c) 2009 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 in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This document presents some recommendations for firewall 52 administrators to help them configure their existing firewalls in a 53 way that allows in certain deployment scenarios the Mobile IPv6 and 54 DSMIPv6 signaling and data messages to pass through. For other 55 scenarios, the support of additional mechanisms to create pinholes 56 required for MIPv6 will be necessary. This document assumes that the 57 firewalls in question include some kind of stateful packet filtering 58 capability. 60 Table of Contents 62 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Home Agent behind a firewall . . . . . . . . . . . . . . . . . 4 66 4.1. Signaling between the MN and the HA . . . . . . . . . . . 5 67 4.2. IKEv2 signaling between MN and HA for establishing SAs . . 5 68 5. Correspondent Node behind a firewall . . . . . . . . . . . . . 6 69 5.1. Route optimization signaling between MN and CN through 70 HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 5.2. Route optimization signaling between MN and CN . . . . . . 7 72 5.3. Binding Update from MN to CN . . . . . . . . . . . . . . . 7 73 5.4. Route Optimization data traffic from MN . . . . . . . . . 7 74 6. Mobile Node behind a firewall . . . . . . . . . . . . . . . . 8 75 6.1. Signaling between MN and HA . . . . . . . . . . . . . . . 8 76 6.2. Data packets between DSMIPv6 . . . . . . . . . . . . . . . 9 77 6.3. Signaling between MN and CN . . . . . . . . . . . . . . . 9 78 6.4. IKEv2 signaling between MN and HA for establishing SAs . . 10 79 7. Related documents . . . . . . . . . . . . . . . . . . . . . . 10 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Requirements notation 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 2. Introduction 96 Network elements such as firewalls are an integral aspect of a 97 majority of IP networks today, given the state of security in the 98 Internet, threats, and vulnerabilities to data networks. MIPv6 99 [RFC3775] defines mobility support for IPv6 nodes. Firewalls will 100 interfere with the smooth operation of the MIPv6 protocol unless 101 specific steps are taken to allow Mobile IPv6 signaling and data 102 messages to pass through the firewall. The problems caused by 103 firewalls to Mobile IPv6 are documented in [RFC4487]. 105 This document presents some recommendations for firewall 106 administrators to help them configure their firewalls in a way that 107 allows the Mobile IPv6 signaling and data messages to pass through. 108 This document assumes that the firewalls in question include some 109 kind of stateful packet filtering capability. The static rules that 110 need to be configured are described in this document. In some 111 scenarios, the support of additional mechanisms to create pinholes 112 required for MIPv6 signalling and data traffic to pass through will 113 be necessary. A possible solution, describing the dynamic 114 capabilities needed for the firewalls to create pinholes based on 115 MIPv6 signalling traffic is described in a companion document 116 [MIP6FWVENDOR]. Other solutions may also be possible. 118 Some Mobile IPv6 signalling messages require the use of encryption to 119 protect the confidentiality of the payload (e.g. the HoTI and HoT 120 messages between the MN and the HA). The other signalling messages 121 allow the use of encryption. If encryption is being used, it is not 122 possible to inspect the contents of the signalling packets. For 123 these messages to get through, a generic rule needs to be added in 124 the firewall to let ESP packets through without further inspection. 126 3. Abbreviations 128 This document uses the following abbreviations: 130 o CN: Correspondent Node 132 o CoA: Care of Address 133 o CoTI: Care of Test Init 135 o HA: Home Agent 137 o HoA: Home Address 139 o HoTI: Home Test Init 141 o HoT: Home Test 143 o MN: Mobile Node 145 o RO: Route Optimization 147 o RRT: Return Routability Test 149 4. Home Agent behind a firewall 151 This section presents the recommendations for configuring a firewall 152 that protects a home agent. 154 +----------------+ +---+ 155 | | | A | 156 | | +---+ 157 | +----+ | External 158 | | HA | +----+ MN 159 | +----+ | FW | +---+ 160 | Home Agent +----+ | B | 161 | of A | +---+ 162 | | External 163 | | Node 164 +----------------+ 165 Network protected 166 by a firewall 168 Figure 1: HA behind a firewall 170 For each type of traffic that needs to pass through this firewall, 171 recommendations are presented on how to identify that traffic. The 172 following types of traffic are considered 174 o Signaling between the MN and the HA 176 o IKEv2 signaling between MN and HA for establishing SAs 178 4.1. Signaling between the MN and the HA 180 The signaling between the MN and HA is protected using IPSec ESP. 181 These messages are critical to the MIPv6 protocol and if these 182 messages are discarded, Mobile IPv6 as specified today will cease to 183 work. In order to permit these messages through, the firewall has to 184 detect the messages using the following patterns. 186 Destination Address: Address of HA 187 Next Header: 50 (ESP) 188 Mobility Header Type: 5 (BU) 190 This pattern will allow the BU messages from MNs to HA to pass 191 through. 193 When an HA supporting DSMIPv6 clients is behind firewall, in order 194 for DSMIPv6 signalling to reach the HA, the firewall has to allow 195 signaling packets sent to HA's UDP port 4191 to pass through: 197 Destination Address: IPv4 address of HA 198 Protocol: 17 (UDP) 199 Port: 4191 201 The firewall may also have a rule allowing IP-in-IP encapsulated 202 traffic to pass through to the HA: 204 Destination Address: IPv4 address of HA 205 Protocol: 4 (IP-in-IP) 207 If the above rule is not created by the firewall, IP encapsulated 208 DSMIPv6 signalling will not reach the HA. A client compliant with , 209 when it does not get a response to the BU, is supposed to resend the 210 BU encapsulated into UDP, with destination port 4191. Thus, even if 211 the above rule is not created the signaling may pass through with the 212 (IPv4 HA, UDP 4191) rule. 214 4.2. IKEv2 signaling between MN and HA for establishing SAs 216 The MN and HA exchange IKEv2 signaling in order to establish the 217 security associations. The security associations so established will 218 later be used for securing the mobility signaling messages. Hence 219 these messages need to be permitted to pass through the firewalls. 220 The following pattern will detect these messages. 222 Destination Address: Address of HA 223 Transport Protocol: UDP 224 Destination UDP Port: 500 226 5. Correspondent Node behind a firewall 228 This section presents the recommendations for configuring a firewall 229 if a node behind it should be able to act as Mobile IPv6 CN. 231 +----------------+ +----+ 232 | | | HA | 233 | | +----+ 234 | | Home Agent 235 | +---+ +----+ of B 236 | |CN | | FW | 237 | | C | +----+ 238 | +---+ | +---+ 239 | | | B | 240 | | +---+ 241 +----------------+ External Mobile 242 Network protected Node 243 by a firewall 245 Figure 2: CN behind a firewall 247 For each type of traffic that needs to pass through this firewall, 248 recommendations are presented on how to identify that traffic. The 249 following types of traffic are considered 251 o Route optimization signaling between MN and CN through HA 253 o Route optimization signaling between MN and CN 255 o Binding Update from MN to CN 257 o Route Optimization data traffic from MN 259 5.1. Route optimization signaling between MN and CN through HA 261 Parts of the initial route optimization signaling has to pass through 262 the HA, namely the HoTI and the HoT messages. Without assistance, 263 the HoTI message from the HA to the CN is not able to traverse the 264 firewall. When only a few priviledged nodes (like servers) are 265 allowed to be contacted by outside nodes, then the following pattern 266 will allow the HoTI messages to reach these nodes: 268 Destination Address: CN Address 270 Mobility Header Type: 1 (HoTI) 272 where CN Address describes the address(es) of the priviledged 273 node(s). This pinhole allows the HoTI message from the HA to the CN 274 to traverse the firewall. The HoT message from the CN to the MN 275 through the HA can traverse the firewall without any assistance. 276 Hence no pinhole is required. 278 5.2. Route optimization signaling between MN and CN 280 Route Optimization allows direct communication of data packets 281 between the MN and a CN without tunnelling it back through the HA. 282 To get route optimization work, the MN has to send a CoTI message 283 directly to the CN, which response with a CoT message. However, a 284 stateful firewall would prevent the CoTI message to pass through as 285 there is no established state on the firewall. When only a few 286 priviledged nodes (like servers) are allowed to be contacted by 287 outside nodes, then the following pattern will allow the CoTI 288 messages to reach these nodes: 290 Destination Address: CN Address 292 Mobility Header Type: 2 (CoTI) 294 where CN Address describes the address(es) of the priviledged 295 node(s).The CoT message from the CN to the MN can traverse the 296 firewall without any assistance. Hence no pinhole is required. 298 5.3. Binding Update from MN to CN 300 After successfully performing the return routability procedure, the 301 MN sends the BU to the CN and expects the BA. Since this BU does not 302 match any previous installed pinhole rules, an additional pinhole 303 with the following format is required.When only a few priviledged 304 nodes (like servers) are allowed to be contacted by outside nodes, 305 then the following pattern will allow the BU messages to reach these 306 nodes: 308 Destination Address: CN Address 310 Mobility Header Type: 5 312 where CN Address describes the address(es) of the priviledged 313 node(s).This allows the BU to traverse the firewall and the BA can 314 pass the firewall without any assistance. Therefore, the Binding 315 Update sequence can be performed successfully. 317 5.4. Route Optimization data traffic from MN 319 Also the Route Optimization data traffic from MN directly to the CN 320 can not traverse the firewall without assistance. A dynamically 321 created pinhole such as the one specified in [MIP6FWVENDOR] will 322 allow this traffic to pass. 324 6. Mobile Node behind a firewall 326 This section presents the recommendations for configuring a firewall 327 that protects the network a mobile node visiting. 329 +----------------+ +----+ 330 | | | HA | 331 | | +----+ 332 | | Home Agent 333 | +---+ +----+ of A +---+ 334 | | A | | FW | | B | 335 | +---+ +----+ +---+ 336 |Internal | External 337 | MN | Node 338 | | 339 +----------------+ 340 Network protected 341 by a firewall 343 Figure 3: MN behind a firewall 345 For each type of traffic that needs to pass through this firewall, 346 recommendations are presented on how to identify that traffic. The 347 following types of traffic are considered 349 o Signaling between MN and HA 351 o Route Optimization Signaling between MN and CN 353 o IKEv2 signaling between MN and HA for establishing SAs 355 6.1. Signaling between MN and HA 357 As described in Section 4.1, the signaling between the MN and HA is 358 protected using IPSec ESP. Currently, a lot of firewalls are 359 configured to block the incoming ESP packets. Moreover, from the 360 view of the firewall, both source and destination addresses of these 361 messages from/to mobile node are variable. Fortunately, for a 362 stateful firewall, if the initial traffic is allowed through the 363 firewall, then the return traffic is also allowed. A mobile node is 364 always the initiator for the BU. Since MN's CoA is not able to be 365 known in advance, the firewall can use following patterns to permit 366 these messages through. 368 Source Address: Visited subnet prefix 369 Destination Address: Address of HA 370 Next Header: 50 (ESP) 371 Mobility Header Type: 5 (BU) 373 This pattern will allow the Binding Update packets to pass through 374 the firewall. Then the return packets (BA from HA to MN) will also 375 able to pass through accordingly. 377 6.2. Data packets between DSMIPv6 379 In case of a DSMIPv6 client with only a v4 CoA, the dynamic rules set 380 by the firewall to allow DSMIPv6 signalling packets pass through 381 between the MN and the HA, may time out and be closed. If that 382 happens, data packets sent by a CN to the MN through the HA will not 383 reach the MN. Therefore, the firewall will need to set a static rule 384 to allow data packets sent from the HA's IPv4 address to the MN's 385 IPv4 CoA using either protocol number 4 (IP-in-IP encapsulation) or 386 17 (UDP), depending on the value of the F bit, to pass through. The 387 UDP port numbers for the rule are to be read from the BU/BA message 388 exchange [RFC5555]. When the firewall chooses to create static rules 389 (without traffic based timeout) for allowing DSMIPv6 signalling pass 390 between the MN and HA, then no further rules need to be created by 391 the firewall, as data packets follow the same tunnel as the 392 signaling. 394 6.3. Signaling between MN and CN 396 Route Optimization allows direct communication of data packets 397 between the MN and a CN without tunneling it back through the HA. It 398 includes 3 pairs of messages: HoTI/HoT, CoTI/CoT and BU/BA. The 399 first pair can pass through the firewall using the pattern described 400 in section 5.1. Here we discuss CoTI/CoT and BU/BA messages. 401 Following pattern permits these messages through the firewall. 403 Source Address: Visited subnet prefix 404 Mobility Header Type: 2 (CoTI) 406 Source Address: Visited subnet prefix 407 Mobility Header Type: 5 (BU) 409 This pattern allows the initial messages (CoTI and BU) from the MN to 410 the CN pass through the firewall. The return messages (CoT and BA) 411 from the CN to the MN can also passes through the firewall 412 accordingly. 414 6.4. IKEv2 signaling between MN and HA for establishing SAs 416 The MN and HA exchange IKEv2 signaling in order to establish the 417 security associations. The security associations so established will 418 later be used for securing the mobility signaling messages. Due to 419 variable source/destination IP addresses and MN always as initiator, 420 the following pattern will let the negotiation pass. 422 Source Address: Visited subnet prefix 423 Transport Protocol: UDP 424 Destination UDP Port: 500 426 7. Related documents 428 There are other IETF published documents that provide recommendations 429 for firewall configuration that can affect Mobile IPv6 messages. 430 [RFC4890] that provides recommendations for filtering ICMPv6 messages 431 (especially Section 4.3.2). [RFC4942] describes security issues 432 present in IPv6 and related protocols (especially Sections 2.1.2 and 433 2.1.15). 435 8. Acknowledgements 437 The authors would like to thank the following members of the MIPv6 438 firewall design team for contributing to this document: Hannes 439 Tschofenig, Hesham Soliman, Yaron Sheffer, and Vijay Devarapalli. 440 The authors would also like to thank William Ivancic, Ryuji Wakikawa, 441 Jari Arkko, Henrik Levkowetz, Pasi Eronen and Noriaki Takamiya for 442 their thorough reviews of the document and for providing comments to 443 improve the quality of the document. 445 9. IANA Considerations 447 This document does not require any IANA action. 449 10. Security Considerations 451 This document specifies recommendations for firewall administrators 452 to allow Mobile IPv6 traffic to pass through unhindered. Since some 453 of this traffic is encrypted it is not possible for firewalls to 454 discern whether it is safe or not. This document recommends a 455 liberal setting so that all legitimate traffic can pass. This means 456 that some malicious traffic may be permitted by these rules. These 457 rules may allow the initiation of Denial of Service attacks against 458 Mobile IPv6 capable nodes (the MNs, CNs and the HAs). 460 11. References 462 11.1. Normative References 464 [MIP6FWVENDOR] 465 Krishnan, S., Sheffer, Y., Steinleitner, N., and G. Bajko, 466 "Guidelines for firewall vendors regarding MIPv6 traffic", 467 draft-ietf-mext-firewall-vendor-0 (work in progress), 468 October 2008. 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, March 1997. 473 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 474 in IPv6", RFC 3775, June 2004. 476 [RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile 477 IPv6 and Firewalls: Problem Statement", RFC 4487, 478 May 2006. 480 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 481 Routers", RFC 5555, June 2009. 483 11.2. Informative References 485 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 486 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 488 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 489 Co-existence Security Considerations", RFC 4942, 490 September 2007. 492 Authors' Addresses 494 Suresh Krishnan 495 Ericsson 496 8400 Decarie Blvd. 497 Town of Mount Royal, QC 498 Canada 500 Phone: +1 514 345 7900 x42871 501 Email: suresh.krishnan@ericsson.com 502 Niklas Steinleitner 503 University of Goettingen 504 Lotzestr. 16-18 505 Goettingen 506 Germany 508 Email: steinleitner@cs.uni-goettingen.de 510 Ying Qiu 511 Institute for Infocomm Research 512 21 Heng Mui Keng Terrace 513 Singapore 515 Phone: +65-6874-6742 516 Email: qiuying@i2r.a-star.edu.sg 518 Gabor Bajko 519 Nokia 521 Email: gabor.bajko@nokia.com