idnits 2.17.1 draft-le-mip6-firewalls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 268: '..., the Home Agent MUST support tunnel m...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 59 has weird spacing: '... node and t...' == Line 326 has weird spacing: '...problem secti...' -- 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 (February 2004) is 7369 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) == Missing Reference: 'RFC2026' is mentioned on line 16, but not defined == Unused Reference: 'GONC' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'STRE' is defined on line 360, but no explicit reference was found in the text == Unused Reference: 'CHES' is defined on line 363, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GONC' -- Possible downref: Non-RFC (?) normative reference: ref. 'STRE' -- Possible downref: Non-RFC (?) normative reference: ref. 'CHES' Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Franck Le 3 File: draft-le-mip6-firewalls-00.txt Stefano Faccin 4 Expires: August 2004 Basavaraj Patil 5 Nokia Research Center 6 Dallas 7 February 2004 9 Mobile IPv6 and Firewalls 10 Problem statement 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of [RFC2026]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 Firewalls are an integral part of most IP networks deployed today. 36 Firewall technology available today is predominantly for IPv4 37 networks. Firewalls for IPv6 networks are slowly becoming 38 available. In most cases, current firewall technologies do not 39 support Mobile IPv6. Unless firewalls are aware of Mobile IPv6 40 protocol details, these security devices will hamper large-scale 41 deployment of the protocol. This document presents in detail some 42 of the issues that firewalls present for Mobile IPv6 deployment. 43 The goal of this Internet draft is to highlight the issues with 44 firewalls and Mobile IPv6 and act as an enabler for further 45 discussion. Issues identified here can be solved by developing 46 appropriate solutions in the MIP6 WG. 48 1. Introduction 50 Mobile IPv6 enables IP mobility for IPv6 nodes. It allows a mobile 51 IPv6 node to be reachable via its home IPv6 address irrespective of 52 any link that the mobile attaches to. This is possible as a result 53 of the extensions to IPv6 defined by Mobile IPv6. 55 Mobile IPv6 protocol design also incorporates a feature termed as 56 Route Optimization. This is not a nonstandard set of extensions 57 but a fundamental part of the protocol that allows to optimize the 58 routing of the packets between a Mobile Node and its correspondent 59 node and therefore the performance of the communication. 61 In most cases, current firewall technologies however do not support 62 Mobile IPv6 or are even aware of Mobile IPv6 headers and 63 extensions. Since most networks in the current business environment 64 deploy firewalls, this may prevent future large-scale deployment of 65 the Mobile IPv6 protocol. 67 This document presents in detail some of the issues that firewalls 68 present for Mobile IPv6 deployment, and the impact of each issue is 69 also described. The goal of this Internet draft is to highlight the 70 issues and act as an enabler for further discussion. Issues 71 identified here can be solved by developing appropriate solutions 72 in the MIP6 WG. 74 2. Background information 76 One set of issues is related to the way IP addresses are used in 77 Mobile IP, and the way state information is created and mintained 78 in stateful inspection packet filters. We refer to the internal 79 node as the node connected to the network protected by the 80 firewall, and to external node as the node outside the boundaries 81 of the network protected by the firewall. 83 The following describes how stateful inspection packet filters 84 work: 86 When a MN connects to a TCP socket on another host in the 87 Internet, it provides, at the connection synchronization, the 88 socket (IP address and port) on which it expects to receive a 89 response. 91 When that SYN packet is routed through the firewall, the 92 firewall makes an entry in its state table containing the 93 destination socket and the response socket, and then forwards 94 the packet to the destination. 96 When the response comes back, the filter looks up the packets 97 source and destination sockets in its state table: If they 98 match an expected response, the firewall lets the packet pass. 99 If no table entry exists, the packet is dropped since it was 100 not requested from inside the network. 102 The filter removes the state table entries when the TCP close 103 session negotiation packets are routed through, or after some 104 period of delay, usually a few minutes. This ensures that 105 dropped connections dont leave table holes open. 107 For UDP, similar state is created but since UDP is 108 connectionless and the protocol does not have indication of 109 the beginning nor the end of a session, the state is based 110 only on timers. 112 3. Scenario where the external node is a Mobile Node 114 Lets assume a communication between an internal node A, and an 115 external Mobile Node B. 117 +----------------+ +----+ 118 | | | HA | 119 | | +----+ 120 | | Home Agent 121 | +---+ +----+ of B 122 | | A | | FW | 123 | +---+ +----+ 124 | | +---+ 125 | | | B | 126 | | +---+ 127 +----------------+ External Mobile 128 Network protected Node 129 by a firewall 131 3.1 Issues with Return Routability Test 133 As specified in Mobile IP [MIP6], the tranport and above layers of 134 the ongoing communications should be based on the Home IP address 135 of B, IP HoA B, and not the local IP address that B might get while 136 roaming in order to support mobility. 138 The state created in the stateful inspection packet filter 139 protecting A is therefore initially based on the IP address of A, 140 IP A, and the home address of the node B, IP HoA B. 142 If the Mobile Node B is connected to the home network, packets are 143 directly exchanged between the nodes A and B. If the Mobile Node B 144 is roaming to a vsited network, the session can be maintained 145 thanks to the Home Agent of B and the reverse tunneling mechanism 146 [MIP6]. Packets forwarded by the Home Agent to the node A will have 147 the source IP address indicating the Home IP address of B and the 148 destination IP address indicating the IP address of A. Such packets 149 can thus pass the stateful inspection packet filter protecting A. 151 However nodes A and B might be close while B's Home Agent may be 152 far, resulting in a trombone effect that can create delay and 153 degrade the performance. 155 The Mobile IP specifications have defined the route optimization 156 procedure [MIP6] in order to solve this issue and, to send a 157 Binding Update, the Mobile Node should first execute a Return 158 Routability Test: the Mobile Node B should send a Home Test Init 159 message via its Home Agent and a Care of Test Init message directly 160 to its correspondent node A. 162 The Care of Test Init message is sent using the new CoA of B as 163 source address, however such a packet does not match any entry in 164 the stateful inspection packet filter and as described in section 165 2. The COTi message will thus be dropped by the firewall. As a 166 consequence, the RRT cannot be completed and route optimization 167 cannot be applied. Every packet has to go through the node Bs Home 168 Agent and tunneled between Bs Home Agent and B. 170 3.2 Issues with Firewall Status Update 172 Assuming alternatives mechanisms are developed for authenticating 173 the Binding Update, or other mechanisms are developed to let the 174 RRT packets pass through the stateful inspection packet filter 175 (e.g. rate limiting), the firewall may still drop the packets 176 coming from the new CoA since these incoming packets do not match 177 any existing entry. 179 Requiring the stateful inspection filters to update the connection 180 state upon detecting Binding Update messages from a node outside 181 the network protected by the firewall does not appear feasible nor 182 desirable, since currently the firewall does not have any mean to 183 verify the validity of Binding Update messages and to therefore 184 securely modify the sate information. .sp Changing the firewall 185 states without verifying the validity of the Binding Update 186 messages could lead to Denial of service attacks: malicious nodes 187 may send fake Binding Update forcing the firewall to change the 188 state information, and therefore leading the firewall to drop 189 packets from the connections that use the legitimate addresses. 191 4. Scenario where the internal node is a Mobile Node 193 Lets assume a communication between an internal Mobile Node A, and 194 an external node B. B can also be a Mobile Node and issues raised 195 in section 3 still apply. 197 +----------------+ +----+ 198 | | | HA | 199 | | +----+ 200 | | Home Agent 201 | +---+ +----+ of A +---+ 202 | | A | | FW | | B | 203 | +---+ +----+ +---+ 204 |Internal | External 205 | MN | Node 206 | | 207 +----------------+ 208 Network protected 209 by a firewall 211 4.1 Issues with Triangular Routing 213 One of the main advantages claimed by Mobile IP is that it allows 214 the Mobile Node to be always reachable thanks to the Home Agent. A 215 node desiring to establish a communication will send a packet to 216 the Home Address of the Mobile Node which forwards it to the CoA of 217 the MN. 219 When considering stateful inspection packet filters, e.g. when the 220 Mobile Node roams to a network protected by a firewall with such 221 filters, the packet forwarded from the Home Agent to the Mobile 222 Node CoA may be dropped at the firewall since it does not match any 223 existing entry. 225 When entering the visited network, the MN first acquires a Care of 226 Address and then sends a Binding Update to its Home Agent. This 227 message creates as specified in section 1 a state in the firewall 228 so that the response can pass the firewall and be delivered to the 229 Mobile Node. The state created in the firewall is specific to the 230 Mobility Header being used for the Mobile IPv6 signalling. Also 231 some FW may leave this state open for a while (implementation 232 dependent), whereas other firewalls may delete the state upon 233 receiving the Binding Acknowledgement message. 235 Lets assume a Correspondent node trying to initiate a communication 236 with the Mobile Node. The Correspondent node sends a packet to the 237 Mobile Nodes home address. The packet is intercepted by the MNs 238 Home Agent which tunnels it to the MNs CoA. 240 As described in section 1, the lifetime corresponding to the state 241 in the firewall may have expired and the state may have been 242 removed. In such case, the incoming packet sent from the CN does 243 not match any existing entry and is therefore dropped at the 244 firewall. 246 Even if the state created above has not expired yet, the state 247 created is for the Binding Update message (Mobility Header) whereas 248 the packet sent from the CN is received under the form of an IP in 249 IP packet. The latter does not match any existing entry and is also 250 dropped. 252 4.2 Issues with Return Routability Test 254 Security of Mobile IPv6 Binding Update is based on the RRT 255 mechanism [MIP6]. RRT robustness and security level relies on the 256 application of IPsec ESP between the Home Agent and the MN. As 257 specified in Mobile IPv6 [MIP6] in section 5.2.5 'For improved 258 security, the data passed between the Home Agent and the Mobile 259 Node is made immune to inspection and passive attacks. Such 260 protection is gained by encrypting the home keygen token as it is 261 tunneled from the Home Agent to the Mobile Node as specified in 262 Section 10.4.6.' 264 Also section 10.4.6 specifies that 'The return routability 265 procedure described in Section 5.2.5 assumes that the 266 confidentiality of the Home Test Init and Home Test messages is 267 protected as they are tunneled between the Home Agent to the Mobile 268 Node. Therefore, the Home Agent MUST support tunnel mode IPsec ESP 269 for the protection of packets belonging to the return routability 270 procedure.' This assumption is valid in some environments, however 271 for networks protected by a firewall, the requirement can be an 272 issue. 274 Typically firewalls need to filter the packets based on the 275 source/destination IP addresses and the TCP/UDP source/destination 276 ports numbers. When a packet is encrypted using IPsec ESP, such 277 information is not available (in particular the port numbers), 278 therefore firewalls may drop the Home Test messages forwarded by 279 the HA to the MNs CoA. The result is that the MN cannot complete 280 the RRT procedure, and consequently cannot perform route 281 optimization by sending any Binding Update messages. 283 When ESP is applied, the firewall cannot differentiate packets 284 containing the Mobility Header defined by MIPv6 i.e. packets for 285 which Mobile IPv6 is used, from other packets. In order to support 286 RRT, one possible idea could be to let the firewall pass all ESP 287 packets coming from the MN Home Agent. This may however not be 288 desirable since it would allow several types of attacks (e.g. 289 flooding) to be carried out against the MN. In cellular networks 290 such flooding may result in e.g. overbilling attacks since the user 291 has to pay for the air interface utilization. 293 4.3 Issues with Change of CoA 295 The internal node A may change CoA within the network protected by 296 the firewall. In such instances A updates its Home Agent with its 297 current location by sending a Binding Update. This Binding Update 298 message may present issues with the firewall if encrypted. Lets 299 assume that the Mobile Node therefore only integrity protects the 300 Binding Update message. 302 When passing the firewall, this message creates a state in the 303 firewall that will allow the response to pass the firewall and 304 reach the Mobile Node. The state information includes the Mobile 305 Node, the Home Agents IP addresses, and the Protocol Identifier 306 indicating a a packet containing a Mobility Header 308 The Home Agent updates its binding cache and replies with a Binding 309 Acknowledgement message. The latter can pass the firewall and reach 310 the Mobile Node thanks to the state previously created in the 311 firewall. After this procedure the Home Agent forwards subsequent 312 packets destined to the Mobile Node to the new CoA. 314 The firewall however does not have any state for the new incoming 315 data packets, since such packets are addressed to the new CoA of 316 the Mobile Node, whereas the firewall state was created based on 317 the old CoA. The incoming packets are therefore dropped at the 318 firewall. If the Mobile Node were communicating with correspondent 319 nodes, all the states in the firewall had been created for the 320 previous MNs CoA. 322 4.4 Change of firewall 324 When the MN A moves, it may roams to a subnet served by a different 325 firewall. A might be sending BU to the CN (even assuming RRT 326 problem section 4.2 - can be solved or other authentication 327 mechanism is developed), incoming packets may however be dropped at 328 the firewall since this latter does not have any state. 330 5. Conclusion 332 Current firewalls may not only prevent route optimization but may 333 also prevent communications to be established in some cases. This 334 document describes some of the issues between the Mobile IP 335 protocol and current firewall technologies, but the issues are not 336 limited to the ones described in this document. There are other 337 ones and the next version of this Internet draft will detail other 338 issues. 340 However the authors considered relevant to present these problems 341 as soon as possible, so that network administrators who intend to 342 deploy Mobile IPv6 can consider them, and so that solutions/tools 343 can be developed to solve the identified problems. 345 6. Security Considerations 347 This document describes the issues between current firewall 348 technology and the Mobile IP protocol. No solution is being 349 proposed, and therefore no security risks are being introduced. 351 7. References 353 [MIP6] 354 D. Johnson, C. Perkins, J. Arkko, "Mobility Support in in 355 IPv6", draft-ietf-mobileip-ipv6-24.txt, June 30, 2003 357 [GONC] 358 Firewalls complete / Marcus Goncalves 360 [STRE] 361 Firewalls 24 seven / Matthew Strebe and Charles Perkins 363 [CHES] 364 Firewalls and Internet Security, Repelling the Wily Hacker / 365 William R. Cheswick and Steve M. Bellovin 367 Author's Address: 369 Franck Le Stefano Faccin 370 Nokia Research Center, Dallas Nokia Research Center, Dallas 371 6000 Connection Drive 6000 Connection Drive 372 Irving, TX-75063, USA. Irving, TX-75063. USA. 374 E-Mail: franck.le@nokia.com E-Mail: stefano.faccin@nokia.com 375 Phone : +1 972 374 1256 Phone : +1 972 894 4994 377 Basavaraj Patil 378 Nokia, Dallas 379 6000 Connection Drive 380 Irving, TX-75063, USA. 382 EMail: Basavaraj.Patil@nokia.com 383 Phone: +1 972-894-6709