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