idnits 2.17.1 draft-ietf-mext-firewall-vendor-03.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 (June 27, 2010) is 5052 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: December 29, 2010 Check Point 6 N. Steinleitner 7 University of Goettingen 8 G. Bajko 9 Nokia 10 June 27, 2010 12 Guidelines for firewall vendors regarding MIPv6 traffic 13 draft-ietf-mext-firewall-vendor-03 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 December 29, 2010. 40 Copyright Notice 42 Copyright (c) 2010 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. It also assumes that 106 the firewalls are capable of creating filters based on arbitrary 107 fields based on the contents of a signaling packet. 109 3.2. Detecting and parsing the Mobility Header 111 The Mobility Header is the basic primitive in all MIPv6 signaling 112 messages. Thus the firewalls need to be able to recognize the 113 presence of the mobility header and be able to parse the contents of 114 the Mobility Header. The MH is described in section 6.1 of [RFC3775] 115 and the format of the same is scribed in section 6.1.1 of [RFC3775]. 116 Firewalls need to be able to at least understand the contents of the 117 MH Type field that describes the type of signaling message carried. 119 3.3. Parsing Mobility Options 121 The Mobility Header can carry additional information in the form of 122 mobility options as described in section 6.2 of [RFC3775] and section 123 3 of [RFC5555]. Some of these mobility options need to be understood 124 for proper creation of state on the firewalls. Hence firewalls must 125 be able to parse the mobility options defined in [RFC3775] and 126 [RFC5555]. 128 4. Allowing signaling response packets 130 The MIPv6 signalling messages are usually performed as a request- 131 response pair. The request message is usually allowed by setting up 132 a static firewall rule to allow the traffic to pass through. The 133 response message on the other hand can be dynamically allowed if the 134 firewall can automatically setup a filter for the response packets 135 when the request packet passes through. This is not trivial, but 136 fortunately is straightforward. There are 3 message pairs that are 137 of importance to MIPv6 signaling. They are the BU/BA, HoTI/HoT and 138 CoTI/CoT pairs. When the first message in the pair traverses the 139 firewall in one direction, the firewall must setup a filter rule to 140 allow the second message through in the other direction. 142 Consider a packet that matches a static rule configured on a firewall 144 Destination Address: Address of HA 145 Next Header: 50 (ESP) 146 Mobility Header Type: 5 (BU) 148 This rule allows a binding update message from a MN to pass through 149 to the HA. Once a packet that matches this rule passes through the 150 firewall, the firewall must setup a dynamic filter for the return 151 packet 153 Source Address: Destination Address from Packet 155 Destination Address: Source Address from Packet 156 Next Header: 50 (ESP) 157 Mobility Header Type: 6 (BA) 159 This rule ensures that the return BA packet will pass through 160 unhindered. The rules can be generalized as summarized in the table 161 below. 163 +---------------------------------+---------------------------------+ 164 | Passing packet MH Type | Setup return filter with MH | 165 | | Type | 166 +---------------------------------+---------------------------------+ 167 | Mobility Header Type:1(HoTI) | Mobility Header Type:3(HoT) | 168 | Mobility Header Type:2(CoTI) | Mobility Header Type:4(CoT) | 169 | Mobility Header Type:5(BU) | Mobility Header Type:6(BA) | 170 +---------------------------------+---------------------------------+ 172 Table 1: Message Pairs in MIPv6 174 Such dynamic rules can be timed out after a configurable period 175 STATEFUL_PINHOLE_LIFETIME, unless renewed by new mobility messages. 176 This document recommends that the default value of 177 STATEFUL_PINHOLE_LIFETIME be set to 30 seconds. 179 These dynamic rules MUST be immediately deleted after the return 180 message passes through. e.g. Once a return HoT message for a HoTI 181 passes through, the pinhole must be immediately removed. The loss of 182 the HoT packet after passing the firewall needs to be handled by the 183 original MN retransmitting the HoTI message. 185 A DSMIPv6 client [RFC5555] having been configured with only a v4 CoA, 186 will tunnel the MIP6 signaling messages to the HA's IPv4 address 187 using its IPv4 CoA. These messages are either IP-in-IP encapsulated 188 (protocol number 4) or UDP&IP encapsulated and sent to the 189 destination UDP port number 4191. 191 The firewall SHOULD understand the Binding Update and Biding 192 Acknowledgement Message Extensions and check the status of the F 193 flag. If the F flag is set to zero in both the BU and the BA, the 194 firewall MUST set up a dynamic filter for the return packets: 196 Destination Address: IPv4 CoA of the MN 197 Protocol: 4 (IP-in-IP) 198 Source Address: IPv4 address of the HA 200 When the F flag is set to 1 in either the BU and BA, the firewall 201 does not need to take any special action, as the signaling packets 202 will be UDP encapsulated. 204 5. Allowing data packets based on signaling 206 Once the MIPv6 signaling completes, the data traffic can begin to 207 flow. The traffic filters for the data traffic can be inferred from 208 the contents of the signaling messages that setup the session. This 209 section describes how firewalls can intelligently setup filters for 210 data traffic based on signaling traffic.The following example 211 describes how to setup a filter for allowing incoming route optimized 212 messages from a CN to an MN after the MN sent a BU message to a CN. 214 When the BU message from MN to CN (MH Type 5) traverses through the 215 firewall the firewall extracts the home address (HoA) from the Home 216 Address Option (section 6.3 of [RFC3775]) of the packet. 218 The firewall adds the following rule in order to let the return 219 traffic pass. 221 Destination Address: Source Address of the packet (MN CoA) 222 Source Address: Destination Address of packet (CN) 223 Routing Header Type 2 Address: HoA 225 This pattern allows all route optimized traffic coming from the CN to 226 the MN to pass through. 228 Additionally, the firewall adds a second rule in order to let the 229 data traffic from the MN to the CN pass through. 231 Source Address: Source Address of the packet (MN CoA) 232 Destination Address: Destination Address of packet (CN) 233 Next Header: IPv6 Destination Options Header(60) 234 Home Address Dest. Option: MN HoA 236 This pattern allows all route optimized traffic coming from the MN to 237 the CN to pass through. 239 A firewall protecting the HA can add the following rule on reception 240 of a HA binding update, in order to let the incoming bi-directional 241 tunneled traffic pass. 243 Destination Address: Source Address of the packet (MN HoA) 244 Source Address: Destination Address of packet (CN) 246 6. Acknowledgements 248 The authors would like to thank the following members of the MIPv6 249 firewall design team for contributing to this document: Hannes 250 Tschofenig, Hesham Soliman, Qiu Ying, and Vijay Devarapalli. The 251 authors would also like to thank William Ivancic, Ryuji Wakikawa, 252 Jari Arkko, Henrik Levkowetz, Pasi Eronen and Noriaki Takamiya for 253 their thorough reviews of the document and for providing comments to 254 improve the quality of the document. 256 7. IANA Considerations 258 This document does not require any IANA action. 260 8. Security Considerations 262 This document specifies recommendations for firewall vendors to allow 263 Mobile IPv6 traffic to pass through unhindered. This document 264 recommends a liberal setting of firewall rules so that all legitimate 265 traffic may be allowed to pass. This means that some malicious 266 traffic may be permitted by these rules. These rules may allow the 267 initiation of Denial of Service attacks against Mobile IPv6 capable 268 nodes (the MNs, CNs and the HAs). 270 One of the main goals of any firewall is to prevent unsolicited 271 traffic from entering the network. The proposed solution allows such 272 traffic into the network, albeit with a number of restrictions. 274 In a typical enterprise environment, an administrator cannot 275 distinguish Mobile IPv6 capable nodes from other nodes. In such a 276 situation any node in the protected network may end up receiving 277 unsolicited packets from outside the firewall. The risk in this case 278 is that such packets could trigger unknown vulnerabilities in any of 279 these nodes, causing denial-of-service or worse attacks. This issue 280 is compounded in a mobile service provider environment by the risks 281 specific to such environments like endpoint battery exhaustion and 282 spectrum misuse. 284 9. Normative References 286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, March 1997. 289 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 290 in IPv6", RFC 3775, June 2004. 292 [RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile 293 IPv6 and Firewalls: Problem Statement", RFC 4487, 294 May 2006. 296 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 297 Routers", RFC 5555, June 2009. 299 Authors' Addresses 301 Suresh Krishnan 302 Ericsson 303 8400 Decarie Blvd. 304 Town of Mount Royal, QC 305 Canada 307 Phone: +1 514 345 7900 x42871 308 Email: suresh.krishnan@ericsson.com 310 Yaron Sheffer 311 Check Point 312 5 Hasolelim St. 313 Tel Aviv 67897 314 Israel 316 Email: yaronf@checkpoint.com 318 Niklas Steinleitner 319 University of Goettingen 320 Lotzestr. 16-18 321 Goettingen 322 Germany 324 Email: steinleitner@cs.uni-goettingen.de 326 Gabor Bajko 327 Nokia 329 Email: gabor.bajko@nokia.com