idnits 2.17.1 draft-krishnan-mip6-firewall-vendor-04.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 311. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 329. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 335. 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 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 (April 30, 2008) is 5833 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) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 4487 Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 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: Standards Track Y. Sheffer 5 Expires: November 1, 2008 Check Point 6 N. Steinleitner 7 University of Goettingen 8 G. Bajko 9 Nokia 10 April 30, 2008 12 Guidelines for firewall vendors regarding MIPv6 traffic 13 draft-krishnan-mip6-firewall-vendor-04 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 1, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This document presents some recommendations for firewall vendors to 47 help them implement their firewalls in a way that allows Mobile IPv6 48 signaling and data messages to pass through. This document describes 49 how to implement stateful packet filtering capability for MIPv6. 51 Table of Contents 53 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. MIPv6 Firewall Primitives . . . . . . . . . . . . . . . . . . . 3 56 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Detecting and parsing the Mobility Header . . . . . . . . . 3 58 3.3. Parsing Mobility Options . . . . . . . . . . . . . . . . . 3 59 4. Allowing signaling response packets . . . . . . . . . . . . . . 4 60 5. Allowing data packets based on signaling . . . . . . . . . . . 5 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 64 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 66 Intellectual Property and Copyright Statements . . . . . . . . . . 8 68 1. Requirements notation 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in [RFC2119]. 74 2. Introduction 76 Network elements such as firewalls are an integral aspect of a 77 majority of IP networks today, given the state of security in the 78 Internet, threats, and vulnerabilities to data networks. MIPv6 79 [RFC3775] defines mobility support for IPv6 nodes. Since firewalls 80 are not aware of MIPv6 protocol details, they will probably interfere 81 with the smooth operation of the protocol. The problems caused by 82 firewalls to Mobile IPv6 are documented in [RFC4487]. 84 This document presents some recommendations for firewall vendors to 85 help them implement their firewalls in a way that allows Mobile IPv6 86 signaling and data messags to pass through. This document describes 87 how to implement stateful packet filtering capability for MIPv6. 89 3. MIPv6 Firewall Primitives 91 3.1. Requirements 93 This document assumes that the firewalls are capable of deep packet 94 inspection at least until the mobility header. It also assumes that 95 the firewalls are capable of creating filters based on arbitrary 96 fields based on the contents of a signaling packet. 98 3.2. Detecting and parsing the Mobility Header 100 The Mobility Header is the basic primitive in all MIPv6 signaling 101 messages. Thus the firewalls need to be able to recognize the 102 presence of the mobility header and be able to parse the contents of 103 the Mobility Header. The MH is described in section 6.1 of [RFC3775] 104 and the format of the same is scribed in section 6.1.1 of [RFC3775]. 105 Firewalls need to be able to at least understand the contents of the 106 MH Type field that describes the type of signaling message carried. 108 3.3. Parsing Mobility Options 110 The Mobility Header can carry additional information in the form of 111 mobility options as described in section 6.2 of [RFC3775]. Some of 112 these mobility options need to be understood for proper creation of 113 state on the firewalls. Hence firewalls must be able to parse the 114 mobility options defined in [RFC3775]. 116 4. Allowing signaling response packets 118 The MIPv6 signalling messages are usually performed as a request- 119 response pair. The request message is usually allowed by setting up 120 a static firewall rule to allow the traffic to pass through. The 121 response message on the other hand can be dynamically allowed if the 122 firewall can automatically setup a filter for the response packets 123 when the request packet passes through. This is not trivial, but 124 fortunately is straightforward. There are 3 message pairs that are 125 of importance to MIPv6 signaling. They are the BU/BA, HoTI/HoT and 126 CoTI/CoT pairs. When the first message in the pair traverses the 127 firewall in one direction, the firewall must setup a filter rule to 128 allow the second message through in the other direction. 130 Consider a packet that matches a static rule configured on a firewall 132 Destination Address: Address of HA 133 Next Header: 50 (ESP) 134 Mobility Header Type: 5 (BU) 136 This rule allows a binding update message from a MN to pass through 137 to the HA. Once a packet that matches this rule passes through the 138 firewall, the firewall must setup a dynamic filter for the return 139 packet 141 Source Address: Destination Address from Packet 143 Destination Address: Source Address from Packet 144 Next Header: 50 (ESP) 145 Mobility Header Type: 6 (BA) 147 This rule ensures that the return BA packet will pass through 148 unhindered. The rules can be generalized as summarized in the table 149 below. 151 +---------------------------------+---------------------------------+ 152 | Passing packet MH Type | Setup return filter with MH | 153 | | Type | 154 +---------------------------------+---------------------------------+ 155 | Mobility Header Type:1(HoTI) | Mobility Header Type:3(HoT) | 156 | Mobility Header Type:2(CoTI) | Mobility Header Type:4(CoT) | 157 | Mobility Header Type:5(BU) | Mobility Header Type:6(BA) | 158 +---------------------------------+---------------------------------+ 160 Table 1: Message Pairs in MIPv6 162 Such dynamic rules can be timed out after a configurable period 163 STATEFUL_PINHOLE_LIFETIME, unless renewed by new mobility messages. 164 This document recommends that the default value of 165 STATEFUL_PINHOLE_LIFETIME be set to 30 seconds. 167 These dynamic rules MUST be immediately deleted after the return 168 message passes through. e.g. Once a return HoT message for a HoTI 169 passes through, the pinhole must be immediately removed. The loss of 170 the HoT packet after passing the firewall needs to be handled by the 171 original MN retransmitting the HoTI message. 173 5. Allowing data packets based on signaling 175 Once the MIPv6 signaling completes, the data traffic can begin to 176 flow. The traffic filters for the data traffic can be inferred from 177 the contents of the signaling messages that setup the session. This 178 section describes how firewalls can intelligently setup filters for 179 data traffic based on signaling traffic.The following example 180 describes how to setup a filter for allowing incoming route optimized 181 messages from a CN to an MN after the MN sent a BU message to a CN. 183 When the BU message from MN to CN (MH Type 5) traverses through the 184 firewall the firewall extracts the home address (HoA) from the Home 185 Address Option (section 6.3 of [RFC3775]) of the packet. 187 The firewall adds the following rule in order to let the return 188 traffic pass. 190 Destination Address: Source Address of the packet (MN CoA) 191 Source Address: Destination Address of packet (CN) 192 Routing Header Type 2 Address: HoA 194 This pattern allows all route optimized traffic coming from the CN to 195 the MN to pass through. 197 Additionally, the firewall adds a second rule in order to let the 198 data traffic from the MN to the CN pass through. 200 Source Address: Source Address of the packet (MN CoA) 201 Destination Address: Destination Address of packet (CN) 202 Next Header: IPv6 Destination Options Header(60) 203 Home Address Dest. Option: MN HoA 205 This pattern allows all route optimized traffic coming from the MN to 206 the CN to pass through. 208 A firewall protecting the HA can add the following rule on reception 209 of a HA binding update, in order to let the incoming bi-directional 210 tunneled traffic pass. 212 Destination Address: Source Address of the packet (MN HoA) 213 Source Address: Destination Address of packet (CN) 215 6. Acknowledgements 217 The authors would like to thank the following members of the MIPv6 218 firewall design team for contributing to this document: Hannes 219 Tschofenig, Hesham Soliman, Qiu Ying, and Vijay Devarapalli. The 220 authors would also like to thank William Ivancic, Ryuji Wakikawa, 221 Jari Arkko and Henrik Levkowetz for their thorough reviews of the 222 document and for providing comments to improve the quality of the 223 document. 225 7. IANA Considerations 227 This document does not require any IANA action. 229 8. Security Considerations 231 This document specifies recommendations for firewall vendors to allow 232 Mobile IPv6 traffic to pass through unhindered. This document 233 recommends a liberal setting of firewall rules so that all legitimate 234 traffic may be allowed to pass. This means that some malicious 235 traffic may be permitted by these rules. These rules may allow the 236 initiation of Denial of Service attacks against Mobile IPv6 capable 237 nodes (the MNs, CNs and the HAs). 239 One of the main goals of any firewall is to prevent unsolicited 240 traffic from entering the network. The proposed solution allows such 241 traffic into the network, albeit with a number of restrictions. 243 In a typical enterprise environment, an administrator cannot 244 distinguish Mobile IPv6 capable nodes from other nodes. In such a 245 situation any node in the protected network may end up receiving 246 unsolicited packets from outside the firewall. The risk in this case 247 is that such packets could trigger unknown vulnerabilities in any of 248 these nodes, causing denial-of-service or worse attacks. This issue 249 is compounded in a mobile service provider environment by the risks 250 specific to such environments like endpoint battery exhaustion and 251 spectrum misuse. 253 9. Normative References 255 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 256 Requirement Levels", BCP 14, RFC 2119, March 1997. 258 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 259 in IPv6", RFC 3775, June 2004. 261 [RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile 262 IPv6 and Firewalls: Problem Statement", RFC 4487, 263 May 2006. 265 Authors' Addresses 267 Suresh Krishnan 268 Ericsson 269 8400 Decarie Blvd. 270 Town of Mount Royal, QC 271 Canada 273 Phone: +1 514 345 7900 x42871 274 Email: suresh.krishnan@ericsson.com 276 Yaron Sheffer 277 Check Point 278 5 Hasolelim St. 279 Tel Aviv 67897 280 Israel 282 Email: yaronf@checkpoint.com 284 Niklas Steinleitner 285 University of Goettingen 286 Lotzestr. 16-18 287 Goettingen 288 Germany 290 Email: steinleitner@cs.uni-goettingen.de 292 Gabor Bajko 293 Nokia 295 Email: gabor.bajko@nokia.com 297 Full Copyright Statement 299 Copyright (C) The IETF Trust (2008). 301 This document is subject to the rights, licenses and restrictions 302 contained in BCP 78, and except as set forth therein, the authors 303 retain all their rights. 305 This document and the information contained herein are provided on an 306 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 307 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 308 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 309 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 310 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 311 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 313 Intellectual Property 315 The IETF takes no position regarding the validity or scope of any 316 Intellectual Property Rights or other rights that might be claimed to 317 pertain to the implementation or use of the technology described in 318 this document or the extent to which any license under such rights 319 might or might not be available; nor does it represent that it has 320 made any independent effort to identify any such rights. Information 321 on the procedures with respect to rights in RFC documents can be 322 found in BCP 78 and BCP 79. 324 Copies of IPR disclosures made to the IETF Secretariat and any 325 assurances of licenses to be made available, or the result of an 326 attempt made to obtain a general license or permission for the use of 327 such proprietary rights by implementers or users of this 328 specification can be obtained from the IETF on-line IPR repository at 329 http://www.ietf.org/ipr. 331 The IETF invites any interested party to bring to its attention any 332 copyrights, patents or patent applications, or other proprietary 333 rights that may cover technology that may be required to implement 334 this standard. Please address the information to the IETF at 335 ietf-ipr@ietf.org. 337 Acknowledgment 339 Funding for the RFC Editor function is provided by the IETF 340 Administrative Support Activity (IASA).