idnits 2.17.1 draft-ietf-mext-firewall-vendor-04.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 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 (March 14, 2011) is 4792 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: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 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: September 15, 2011 Check Point 6 N. Steinleitner 7 University of Goettingen 8 G. Bajko 9 Nokia 10 March 14, 2011 12 Guidelines for firewall vendors regarding MIPv6 traffic 13 draft-ietf-mext-firewall-vendor-04 15 Abstract 17 This document presents some recommendations for firewall vendors to 18 help them implement their firewalls in a way that allows Mobile IPv6 19 and DSMIPv6 signaling and data messages to pass through. This 20 document describes how to implement stateful packet filtering 21 capability for MIPv6 and DSMIPv6. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 15, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. MIPv6 Firewall Primitives . . . . . . . . . . . . . . . . . . . 3 60 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. Detecting and parsing the Mobility Header . . . . . . . . . 3 62 3.3. Parsing Mobility Options . . . . . . . . . . . . . . . . . 4 63 4. Allowing signaling response packets . . . . . . . . . . . . . . 4 64 5. Allowing data packets based on signaling . . . . . . . . . . . 5 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 68 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Requirements notation 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 2. Introduction 79 Network elements such as firewalls are an integral aspect of a 80 majority of IP networks today, given the state of security in the 81 Internet, threats, and vulnerabilities to data networks. MIPv6 82 [RFC3775] defines mobility support for IPv6 nodes. Since firewalls 83 are not aware of MIPv6 protocol details, they will probably interfere 84 with the smooth operation of the protocol. The problems caused by 85 firewalls to Mobile IPv6 are documented in [RFC4487]. 87 This document presents some recommendations for firewall vendors to 88 help them implement their firewalls in a way that allows Mobile IPv6 89 signaling and data messags to pass through. This document describes 90 how to implement stateful packet filtering capability for MIPv6. 92 Some Mobile IPv6 signalling messages require the use of encryption to 93 protect the confidentiality of the payload (e.g. the HoTI and HoT 94 messages between the MN and the HA). The other signalling messages 95 allow the use of encryption. If encryption is being used, it is not 96 possible to inspect the contents of the signalling packets. For 97 these messages to get through, a generic rule needs to be added in 98 the firewall to let ESP packets through without further inspection. 100 3. MIPv6 Firewall Primitives 102 3.1. Requirements 104 This document assumes that the firewalls are capable of deep packet 105 inspection at least until the mobility header. This implies that 106 they are capable of parsing ICMPv6 packets and options in addition to 107 understanding the mobility header. It also assumes that the 108 firewalls are capable of creating filters based on arbitrary fields 109 based on the contents of a signaling packet. 111 3.2. Detecting and parsing the Mobility Header 113 The Mobility Header is the basic primitive in all MIPv6 signaling 114 messages. Thus the firewalls need to be able to recognize the 115 presence of the mobility header and be able to parse the contents of 116 the Mobility Header. The MH is described in section 6.1 of [RFC3775] 117 and the format of the same is described in section 6.1.1 of 118 [RFC3775]. Firewalls need to be able to at least understand the 119 contents of the MH Type field that describes the type of signaling 120 message carried. 122 3.3. Parsing Mobility Options 124 The Mobility Header can carry additional information in the form of 125 mobility options as described in section 6.2 of [RFC3775] and section 126 3 of [RFC5555]. Some of these mobility options need to be understood 127 for proper creation of state on the firewalls. Hence firewalls must 128 be able to parse the mobility options defined in [RFC3775] and 129 [RFC5555]. 131 4. Allowing signaling response packets 133 The MIPv6 signalling messages are usually performed as a request- 134 response pair. The request message is usually allowed by setting up 135 a static firewall rule to allow the traffic to pass through. The 136 response message on the other hand can be dynamically allowed if the 137 firewall can automatically setup a filter for the response packets 138 when the request packet passes through. This is not trivial, but 139 fortunately is straightforward. There are 3 message pairs that are 140 of importance to MIPv6 signaling. They are the BU/BA, HoTI/HoT and 141 CoTI/CoT pairs. When the first message in the pair traverses the 142 firewall in one direction, the firewall must setup a filter rule to 143 allow the second message through in the other direction. 145 Consider a packet that matches a static rule configured on a firewall 147 Destination Address: Address of HA 148 Next Header: 50 (ESP) 149 Mobility Header Type: 5 (BU) 151 This rule allows a binding update message from a MN to pass through 152 to the HA. Once a packet that matches this rule passes through the 153 firewall, the firewall must setup a dynamic filter for the return 154 packet 156 Source Address: Destination Address from Packet 158 Destination Address: Source Address from Packet 159 Next Header: 50 (ESP) 160 Mobility Header Type: 6 (BA) 162 This rule ensures that the return BA packet will pass through 163 unhindered. The rules can be generalized as summarized in the table 164 below. 166 +---------------------------------+---------------------------------+ 167 | Passing packet MH Type | Setup return filter with MH | 168 | | Type | 169 +---------------------------------+---------------------------------+ 170 | Mobility Header Type:1(HoTI) | Mobility Header Type:3(HoT) | 171 | Mobility Header Type:2(CoTI) | Mobility Header Type:4(CoT) | 172 | Mobility Header Type:5(BU) | Mobility Header Type:6(BA) | 173 +---------------------------------+---------------------------------+ 175 Table 1: Message Pairs in MIPv6 177 Such dynamic rules can be timed out after a configurable period 178 STATEFUL_PINHOLE_LIFETIME, unless renewed by new mobility messages. 179 This document recommends that the default value of 180 STATEFUL_PINHOLE_LIFETIME be set to 30 seconds. 182 These dynamic rules MUST be immediately deleted after the return 183 message passes through. e.g. Once a return HoT message for a HoTI 184 passes through, the pinhole must be immediately removed. 186 A DSMIPv6 client [RFC5555] having been configured with only a v4 CoA, 187 will tunnel the MIP6 signaling messages to the HA's IPv4 address 188 using its IPv4 CoA. These messages are either IP-in-IP encapsulated 189 (protocol number 4) or UDP&IP encapsulated and sent to the 190 destination UDP port number 4191. 192 The firewall SHOULD understand the Binding Update and Binding 193 Acknowledgement Message Extensions and check the status of the F 194 flag. If the F flag is set to zero in both the BU and the BA, the 195 firewall MUST set up a dynamic filter for the return packets: 197 Destination Address: IPv4 CoA of the MN 198 Protocol: 4 (IP-in-IP) 199 Source Address: IPv4 address of the HA 201 When the F flag is set to 1 in either the BU and BA, the firewall 202 does not need to take any special action, as the signaling packets 203 will be UDP encapsulated. 205 5. Allowing data packets based on signaling 207 Once the MIPv6 signaling completes, the data traffic can begin to 208 flow. The traffic filters for the data traffic can be inferred from 209 the contents of the signaling messages that setup the session. This 210 section describes how firewalls can intelligently setup filters for 211 data traffic based on signaling traffic.The following example 212 describes how to setup a filter for allowing incoming route optimized 213 messages from a CN to an MN after the MN sent a BU message to a CN. 215 When the BU message from MN to CN (MH Type 5) traverses through the 216 firewall the firewall extracts the home address (HoA) from the Home 217 Address Option (section 6.3 of [RFC3775]) of the packet. 219 The firewall adds the following rule in order to let the return 220 traffic pass. 222 Destination Address: Source Address of the packet (MN CoA) 223 Source Address: Destination Address of packet (CN) 224 Routing Header Type 2 Address: HoA 226 This pattern allows all route optimized traffic coming from the CN to 227 the MN to pass through. 229 Additionally, the firewall adds a second rule in order to let the 230 data traffic from the MN to the CN pass through. 232 Source Address: Source Address of the packet (MN CoA) 233 Destination Address: Destination Address of packet (CN) 234 Next Header: IPv6 Destination Options Header(60) 235 Home Address Dest. Option: MN HoA 237 This pattern allows all route optimized traffic coming from the MN to 238 the CN to pass through. 240 A firewall protecting the HA can add the following rule on reception 241 of a HA binding update, in order to let the incoming bi-directional 242 tunneled traffic pass. 244 Destination Address: Source Address of the packet (MN HoA) 245 Source Address: Destination Address of packet (CN) 247 6. Acknowledgements 249 The authors would like to thank the following members of the MIPv6 250 firewall design team for contributing to this document: Hannes 251 Tschofenig, Hesham Soliman, Qiu Ying, and Vijay Devarapalli. The 252 authors would also like to thank William Ivancic, Ryuji Wakikawa, 253 Jari Arkko, Henrik Levkowetz, Pasi Eronen, Noriaki Takamiya and 254 Arnaud Ebalard for their thorough reviews of the document and for 255 providing comments to improve the quality of the document. 257 7. IANA Considerations 259 This document does not require any IANA action. 261 8. Security Considerations 263 This document specifies recommendations for firewall vendors to allow 264 Mobile IPv6 traffic to pass through unhindered. This document 265 recommends a liberal setting of firewall rules so that all legitimate 266 traffic may be allowed to pass. This means that some malicious 267 traffic may be permitted by these rules. These rules may allow the 268 initiation of Denial of Service attacks against Mobile IPv6 capable 269 nodes (the MNs, CNs and the HAs). 271 One of the main goals of any firewall is to prevent unsolicited 272 traffic from entering the network. The proposed solution allows such 273 traffic into the network, albeit with a number of restrictions. 275 In a typical enterprise environment, an administrator cannot 276 distinguish Mobile IPv6 capable nodes from other nodes. In such a 277 situation any node in the protected network may end up receiving 278 unsolicited packets from outside the firewall. The risk in this case 279 is that such packets could trigger unknown vulnerabilities in any of 280 these nodes, causing denial-of-service or worse attacks. This issue 281 is compounded in a mobile service provider environment by the risks 282 specific to such environments like endpoint battery exhaustion and 283 spectrum misuse. 285 9. Normative References 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, March 1997. 290 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 291 in IPv6", RFC 3775, June 2004. 293 [RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile 294 IPv6 and Firewalls: Problem Statement", RFC 4487, 295 May 2006. 297 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 298 Routers", RFC 5555, June 2009. 300 Authors' Addresses 302 Suresh Krishnan 303 Ericsson 304 8400 Decarie Blvd. 305 Town of Mount Royal, QC 306 Canada 308 Phone: +1 514 345 7900 x42871 309 Email: suresh.krishnan@ericsson.com 311 Yaron Sheffer 312 Check Point 313 5 Hasolelim St. 314 Tel Aviv 67897 315 Israel 317 Email: yaronf@checkpoint.com 319 Niklas Steinleitner 320 University of Goettingen 321 Lotzestr. 16-18 322 Goettingen 323 Germany 325 Email: steinleitner@cs.uni-goettingen.de 327 Gabor Bajko 328 Nokia 330 Email: gabor.bajko@nokia.com