idnits 2.17.1 draft-ietf-mext-firewall-admin-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 488. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 512. 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 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 (May 19, 2009) is 5455 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-mext-firewall-vendor-00 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 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: November 20, 2009 University of Goettingen 6 Y. Qiu 7 Institute for Infocomm Research 8 G. Bajko 9 Nokia 10 May 19, 2009 12 Guidelines for firewall administrators regarding MIPv6 traffic 13 draft-ietf-mext-firewall-admin-01 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on November 20, 2009. 40 Abstract 42 This document presents some recommendations for firewall 43 administrators to help them configure their existing firewalls in a 44 way that allows in certain deployment scenarios the Mobile IPv6 45 signaling and data messages to pass through. For other scenarios, 46 the support of additional mechanisms to create pinholes required for 47 MIPv6 will be necessary. This document assumes that the firewalls in 48 question include some kind of stateful packet filtering capability. 50 Table of Contents 52 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Home Agent behind a firewall . . . . . . . . . . . . . . . . . 4 56 4.1. Signaling between the MN and the HA . . . . . . . . . . . 5 57 4.2. IKEv2 signaling between MN and HA for establishing SAs . . 5 58 5. Correspondent Node behind a firewall . . . . . . . . . . . . . 5 59 5.1. Route optimization signaling between MN and CN through 60 HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.2. Route optimization signaling between MN and CN . . . . . . 6 62 5.3. Binding Update from MN to CN . . . . . . . . . . . . . . . 7 63 5.4. Route Optimization data traffic from MN . . . . . . . . . 7 64 6. Mobile Node behind a firewall . . . . . . . . . . . . . . . . 7 65 6.1. Signaling between MN and HA . . . . . . . . . . . . . . . 8 66 6.2. Signaling between MN and CN . . . . . . . . . . . . . . . 9 67 6.3. IKEv2 signaling between MN and HA for establishing SAs . . 9 68 7. Related documents . . . . . . . . . . . . . . . . . . . . . . 9 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 74 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 76 Intellectual Property and Copyright Statements . . . . . . . . . . 12 78 1. Requirements notation 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 2. Introduction 86 Network elements such as firewalls are an integral aspect of a 87 majority of IP networks today, given the state of security in the 88 Internet, threats, and vulnerabilities to data networks. MIPv6 89 [RFC3775] defines mobility support for IPv6 nodes. Firewalls will 90 interfere with the smooth operation of the MIPv6 protocol unless 91 specific steps are taken to allow Mobile IPv6 signaling and data 92 messages to pass through the firewall. The problems caused by 93 firewalls to Mobile IPv6 are documented in [RFC4487]. 95 This document presents some recommendations for firewall 96 administrators to help them configure their firewalls in a way that 97 allows the Mobile IPv6 signaling and data messages to pass through. 98 This document assumes that the firewalls in question include some 99 kind of stateful packet filtering capability. The static rules that 100 need to be configured are described in this document. In some 101 scenarios, the support of additional mechanisms to create pinholes 102 required for MIPv6 signalling and data traffic to pass through will 103 be necessary. A possible solution, describing the dynamic 104 capabilities needed for the firewalls to create pinholes based on 105 MIPv6 signalling traffic is described in a companion document 106 [I-D.ietf-mext-firewall-vendor]. Other solutions may also be 107 possible. 109 Some Mobile IPv6 signalling messages require the use of encryption to 110 protect the confidentiality of the payload (e.g. the HoTI and HoT 111 messages between the MN and the HA). The other signalling messages 112 allow the use of encryption. If encryption is being used, it is not 113 possible to inspect the contents of the signalling packets. For 114 these messages to get through, a generic rule needs to be added in 115 the firewall to let ESP packets through without further inspection. 117 3. Abbreviations 119 This document uses the following abbreviations: 121 o CN: Correspondent Node 122 o CoA: Care of Address 124 o CoTI: Care of Test Init 126 o HA: Home Agent 128 o HoA: Home Address 130 o HoTI: Home Test Init 132 o HoT: Home Test 134 o MN: Mobile Node 136 o RO: Route Optimization 138 o RRT: Return Routability Test 140 4. Home Agent behind a firewall 142 This section presents the recommendations for configuring a firewall 143 that protects a home agent. 145 +----------------+ +---+ 146 | | | A | 147 | | +---+ 148 | +----+ | External 149 | | HA | +----+ MN 150 | +----+ | FW | +---+ 151 | Home Agent +----+ | B | 152 | of A | +---+ 153 | | External 154 | | Node 155 +----------------+ 156 Network protected 157 by a firewall 159 Figure 1: HA behind a firewall 161 For each type of traffic that needs to pass through this firewall, 162 recommendations are presented on how to identify that traffic. The 163 following types of traffic are considered 165 o Signaling between the MN and the HA 167 o IKEv2 signaling between MN and HA for establishing SAs 169 4.1. Signaling between the MN and the HA 171 The signaling between the MN and HA is protected using IPSec ESP. 172 These messages are critical to the MIPv6 protocol and if these 173 messages are discarded, Mobile IPv6 as specified today will cease to 174 work. In order to permit these messages through, the firewall has to 175 detect the messages using the following patterns. 177 Destination Address: Address of HA 178 Next Header: 50 (ESP) 179 Mobility Header Type: 5 (BU) 181 This pattern will allow the BU messages from MNs to HA to pass 182 through. 184 4.2. IKEv2 signaling between MN and HA for establishing SAs 186 The MN and HA exchange IKEv2 signaling in order to establish the 187 security associations. The security associations so established will 188 later be used for securing the mobility signaling messages. Hence 189 these messages need to be permitted to pass through the firewalls. 190 The following pattern will detect these messages. 192 Destination Address: Address of HA 193 Transport Protocol: UDP 194 Destination UDP Port: 500 196 5. Correspondent Node behind a firewall 198 This section presents the recommendations for configuring a firewall 199 if a node behind it should be able to act as Mobile IPv6 CN. 201 +----------------+ +----+ 202 | | | HA | 203 | | +----+ 204 | | Home Agent 205 | +---+ +----+ of B 206 | |CN | | FW | 207 | | C | +----+ 208 | +---+ | +---+ 209 | | | B | 210 | | +---+ 211 +----------------+ External Mobile 212 Network protected Node 213 by a firewall 214 Figure 2: CN behind a firewall 216 For each type of traffic that needs to pass through this firewall, 217 recommendations are presented on how to identify that traffic. The 218 following types of traffic are considered 220 o Route optimization signaling between MN and CN through HA 222 o Route optimization signaling between MN and CN 224 o Binding Update from MN to CN 226 o Route Optimization data traffic from MN 228 5.1. Route optimization signaling between MN and CN through HA 230 Parts of the initial route optimization signaling has to pass through 231 the HA, namely the HoTI and the HoT messages. Without assistance, 232 the HoTI message from the HA to the CN is not able to traverse the 233 firewall. When only a few priviledged nodes (like servers) are 234 allowed to be contacted by outside nodes, then the following pattern 235 will allow the HoTI messages to reach these nodes: 237 Destination Address: CN Address 239 Mobility Header Type: 1 (HoTI) 241 where CN Address describes the address(es) of the priviledged 242 node(s). This pinhole allows the HoTI message from the HA to the CN 243 to traverse the firewall. The HoT message from the CN to the MN 244 through the HA can traverse the firewall without any assistance. 245 Hence no pinhole is required. 247 5.2. Route optimization signaling between MN and CN 249 Route Optimization allows direct communication of data packets 250 between the MN and a CN without tunnelling it back through the HA. 251 To get route optimization work, the MN has to send a CoTI message 252 directly to the CN, which response with a CoT message. However, a 253 stateful firewall would prevent the CoTI message to pass through as 254 there is no established state on the firewall. When only a few 255 priviledged nodes (like servers) are allowed to be contacted by 256 outside nodes, then the following pattern will allow the CoTI 257 messages to reach these nodes: 259 Destination Address: CN Address 261 Mobility Header Type: 2 (CoTI) 263 where CN Address describes the address(es) of the priviledged 264 node(s).The CoT message from the CN to the MN can traverse the 265 firewall without any assistance. Hence no pinhole is required. 267 5.3. Binding Update from MN to CN 269 After successfully performing the return routability procedure, the 270 MN sends the BU to the CN and expects the BA. Since this BU does not 271 match any previous installed pinhole rules, an additional pinhole 272 with the following format is required.When only a few priviledged 273 nodes (like servers) are allowed to be contacted by outside nodes, 274 then the following pattern will allow the BU messages to reach these 275 nodes: 277 Destination Address: CN Address 279 Mobility Header Type: 5 281 where CN Address describes the address(es) of the priviledged 282 node(s).This allows the BU to traverse the firewall and the BA can 283 pass the firewall without any assistance. Therefore, the Binding 284 Update sequence can be performed successfully. 286 5.4. Route Optimization data traffic from MN 288 Also the Route Optimization data traffic from MN directly to the CN 289 can not traverse the firewall without assistance. A dynamically 290 created pinhole such as the one specified in 291 [I-D.ietf-mext-firewall-vendor] will allow this traffic to pass. 293 6. Mobile Node behind a firewall 295 This section presents the recommendations for configuring a firewall 296 that protects the network a mobile node visiting. 298 +----------------+ +----+ 299 | | | HA | 300 | | +----+ 301 | | Home Agent 302 | +---+ +----+ of A +---+ 303 | | A | | FW | | B | 304 | +---+ +----+ +---+ 305 |Internal | External 306 | MN | Node 307 | | 308 +----------------+ 309 Network protected 310 by a firewall 312 Figure 3: MN behind a firewall 314 For each type of traffic that needs to pass through this firewall, 315 recommendations are presented on how to identify that traffic. The 316 following types of traffic are considered 318 o Signaling between MN and HA 320 o Route Optimization Signaling between MN and CN 322 o IKEv2 signaling between MN and HA for establishing SAs 324 6.1. Signaling between MN and HA 326 As described in Section 4.1, the signaling between the MN and HA is 327 protected using IPSec ESP. Currently, a lot of firewalls are 328 configured to block the incoming ESP packets. Moreover, from the 329 view of the firewall, both source and destination addresses of these 330 messages from/to mobile node are variable. Fortunately, for a 331 stateful firewall, if the initial traffic is allowed through the 332 firewall, then the return traffic is also allowed. A mobile node is 333 always the initiator for the BU. Since MN's CoA is not able to be 334 known in advance, the firewall can use following patterns to permit 335 these messages through. 337 Source Address: Visited subnet prefix 339 Destination Address: Address of HA 340 Next Header: 50 (ESP) 341 Mobility Header Type: 5 (BU) 343 This pattern will allow the Binding Update packets to pass through 344 the firewall. Then the return packets (BA from HA to MN) will also 345 able to pass through accordingly. 347 6.2. Signaling between MN and CN 349 Route Optimization allows direct communication of data packets 350 between the MN and a CN without tunneling it back through the HA. It 351 includes 3 pairs of messages: HoTI/HoT, CoTI/CoT and BU/BA. The 352 first pair can pass through the firewall using the pattern described 353 in section 5.1. Here we discuss CoTI/CoT and BU/BA messages. 354 Following pattern permits these messages through the firewall. 356 Source Address: Visited subnet prefix 357 Mobility Header Type: 2 (CoTI) 359 Source Address: Visited subnet prefix 360 Mobility Header Type: 5 (BU) 362 This pattern allows the initial messages (CoTI and BU) from the MN to 363 the CN pass through the firewall. The return messages (CoT and BA) 364 from the CN to the MN can also passes through the firewall 365 accordingly. 367 6.3. IKEv2 signaling between MN and HA for establishing SAs 369 The MN and HA exchange IKEv2 signaling in order to establish the 370 security associations. The security associations so established will 371 later be used for securing the mobility signaling messages. Due to 372 variable source/destination IP addresses and MN always as initiator, 373 the following pattern will let the negotiation pass. 375 Source Address: Visited subnet prefix 376 Transport Protocol: UDP 377 Destination UDP Port: 500 379 7. Related documents 381 There are other IETF published documents that provide recommendations 382 for firewall configuration that can affect Mobile IPv6 messages. 383 [RFC4890] that provides recommendations for filtering ICMPv6 messages 384 (especially Section 4.3.2). [RFC4942] describes security issues 385 present in IPv6 and related protocols (especially Sections 2.1.2 and 386 2.1.15). 388 8. Acknowledgements 390 The authors would like to thank the following members of the MIPv6 391 firewall design team for contributing to this document: Hannes 392 Tschofenig, Hesham Soliman, Yaron Sheffer, and Vijay Devarapalli. 393 The authors would also like to thank William Ivancic, Ryuji Wakikawa, 394 Jari Arkko, Henrik Levkowetz, Pasi Eronen and Noriaki Takamiya for 395 their thorough reviews of the document and for providing comments to 396 improve the quality of the document. 398 9. IANA Considerations 400 This document does not require any IANA action. 402 10. Security Considerations 404 This document specifies recommendations for firewall administrators 405 to allow Mobile IPv6 traffic to pass through unhindered. Since some 406 of this traffic is encrypted it is not possible for firewalls to 407 discern whether it is safe or not. This document recommends a 408 liberal setting so that all legitimate traffic can pass. This means 409 that some malicious traffic may be permitted by these rules. These 410 rules may allow the initiation of Denial of Service attacks against 411 Mobile IPv6 capable nodes (the MNs, CNs and the HAs). 413 11. References 415 11.1. Normative References 417 [I-D.ietf-mext-firewall-vendor] 418 Krishnan, S., Sheffer, Y., Steinleitner, N., and G. Bajko, 419 "Guidelines for firewall vendors regarding MIPv6 traffic", 420 draft-ietf-mext-firewall-vendor-00 (work in progress), 421 October 2008. 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, March 1997. 426 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 427 in IPv6", RFC 3775, June 2004. 429 [RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile 430 IPv6 and Firewalls: Problem Statement", RFC 4487, 431 May 2006. 433 11.2. Informative References 435 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 436 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 438 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 439 Co-existence Security Considerations", RFC 4942, 440 September 2007. 442 Authors' Addresses 444 Suresh Krishnan 445 Ericsson 446 8400 Decarie Blvd. 447 Town of Mount Royal, QC 448 Canada 450 Phone: +1 514 345 7900 x42871 451 Email: suresh.krishnan@ericsson.com 453 Niklas Steinleitner 454 University of Goettingen 455 Lotzestr. 16-18 456 Goettingen 457 Germany 459 Email: steinleitner@cs.uni-goettingen.de 461 Ying Qiu 462 Institute for Infocomm Research 463 21 Heng Mui Keng Terrace 464 Singapore 466 Phone: +65-6874-6742 467 Email: qiuying@i2r.a-star.edu.sg 469 Gabor Bajko 470 Nokia 472 Email: gabor.bajko@nokia.com 474 Full Copyright Statement 476 Copyright (C) The IETF Trust (2009). 478 This document is subject to the rights, licenses and restrictions 479 contained in BCP 78, and except as set forth therein, the authors 480 retain all their rights. 482 This document and the information contained herein are provided on an 483 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 484 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 485 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 486 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 487 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 488 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 490 Intellectual Property 492 The IETF takes no position regarding the validity or scope of any 493 Intellectual Property Rights or other rights that might be claimed to 494 pertain to the implementation or use of the technology described in 495 this document or the extent to which any license under such rights 496 might or might not be available; nor does it represent that it has 497 made any independent effort to identify any such rights. Information 498 on the procedures with respect to rights in RFC documents can be 499 found in BCP 78 and BCP 79. 501 Copies of IPR disclosures made to the IETF Secretariat and any 502 assurances of licenses to be made available, or the result of an 503 attempt made to obtain a general license or permission for the use of 504 such proprietary rights by implementers or users of this 505 specification can be obtained from the IETF on-line IPR repository at 506 http://www.ietf.org/ipr. 508 The IETF invites any interested party to bring to its attention any 509 copyrights, patents or patent applications, or other proprietary 510 rights that may cover technology that may be required to implement 511 this standard. Please address the information to the IETF at 512 ietf-ipr@ietf.org.