idnits 2.17.1 draft-ietf-mip6-firewalls-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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 687. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 671. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 677. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (January 25, 2006) is 6659 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 (ref. '1') (Obsoleted by RFC 6275) == Outdated reference: A later version (-07) exists of draft-chen-mip6-gprs-03 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 F. Le 3 Internet-Draft CMU 4 Expires: July 29, 2006 S. Faccin 5 B. Patil 6 Nokia 7 H. Tschofenig 8 Siemens 9 January 25, 2006 11 Mobile IPv6 and Firewalls: Problem statement 12 draft-ietf-mip6-firewalls-04.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on July 29, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 Network elements such as firewalls are an integral aspect of a 46 majority of IP networks today, given the state of security in the 47 Internet, threats, and vulnerabilities to data networks. Current IP 48 networks are predominantly based on IPv4 technology and hence 49 firewalls have been designed for these networks. Deployment of IPv6 50 networks is currently progressing, albeit at a slower pace. 51 Firewalls for IPv6 networks are still maturing and in development. 53 Mobility support for IPv6 has been standardized as specified in RFC 54 3775. Given the fact that Mobile IPv6 is a recent standard, most 55 firewalls available for IPv6 networks do not support Mobile IPv6. 57 Unless firewalls are aware of Mobile IPv6 protocol details, these 58 security devices will interfere in the smooth operation of the 59 protocol and can be a detriment to deployment. This document 60 captures the issues that may arise in the deployment of IPv6 networks 61 when they support Mobile IPv6 and firewalls. 63 The issues are not only applicable to firewalls protecting enterprise 64 networks, but are also applicable in 3G mobile networks such as GPRS/ 65 UMTS and CDMA 2000 networks. 67 The goal of this Internet draft is to highlight the issues with 68 firewalls and Mobile IPv6 and act as an enabler for further 69 discussion. Issues identified here can be solved by developing 70 appropriate solutions in the MIP6 WG. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 6 77 4. Overview of firewalls . . . . . . . . . . . . . . . . . . . . 7 78 5. Analysis of various scenarios involving MIP6 nodes and 79 firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 5.1. Scenario where the Mobile Node is in a network 81 protected by firewall(s) . . . . . . . . . . . . . . . . . 9 82 5.2. Scenario where the Correspondent Node is in a network 83 protected by firewall(s) . . . . . . . . . . . . . . . . . 11 84 5.3. Scenario where the HA is in a network protected by 85 firewall(s) . . . . . . . . . . . . . . . . . . . . . . . 15 86 5.4. Scenario where MN moves to a network protected by 87 firewall(s) . . . . . . . . . . . . . . . . . . . . . . . 15 88 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 90 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 94 Appendix A. Applicability to 3G Networks . . . . . . . . . . . . 21 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 96 Intellectual Property and Copyright Statements . . . . . . . . . . 23 98 1. Introduction 100 Mobile IPv6 enables IP mobility for IPv6 nodes. It allows a mobile 101 IPv6 node to be reachable via its home IPv6 address irrespective of 102 any link that the mobile attaches to. This is possible as a result 103 of the extensions to IPv6 defined in the Mobile IPv6 specification 104 [1]. 106 Mobile IPv6 protocol design also incorporates a feature termed as 107 Route Optimization. This set of extensions is a fundamental part of 108 the protocol that enables optimized routing of packets between a 109 Mobile Node and its correspondent node and therefore the performance 110 of the communication. 112 In most cases, current firewall technologies, however, do not support 113 Mobile IPv6 or are even aware of Mobile IPv6 headers and and 114 extensions. Since most networks in the current business environment 115 deploy firewalls, this may prevent future large-scale deployment of 116 the Mobile IPv6 protocol. 118 This document presents in detail some of the issues that firewalls 119 present for Mobile IPv6 deployment, as well as the impact of each 120 issue. 122 2. Terminology 124 Return Routability Test (RRT): The Return Routability Test is a 125 procedure defined in RFC 3775 [1]. It is performed prior to the 126 Route Optimization (RO), where a mobile node (MN) instructs a 127 correspondent node (CN) to direct the mobile node's data traffic 128 to its claimed care-of address (CoA). The Return Routability 129 procedure provides some security assurance and prevents the misuse 130 of Mobile IPv6 signaling to maliciously redirect the traffic or to 131 launch other attacks. 133 3. Abbreviations 135 This document uses the following abbreviations: 137 o CN: Correspondent Node 139 o CoA: Care of Address 141 o CoTI: Care of Test Init 143 o HA: Home Agent 145 o HoA: Home Address 147 o HoTI: Home Test Init 149 o HoT: Home Test 151 o MN: Mobile Node 153 o RO: Route Optimization 155 o RRT: Return Routability Test 157 4. Overview of firewalls 159 The following section provides a brief overview of firewalls. It is 160 intended as background information so that issues with the Mobile 161 IPv6 protocol can then be presented in detail in the following 162 sections. 164 There are different types of firewalls and state can be created in 165 these firewalls through different methods. Independent of the 166 adopted method, firewalls typically look at five parameters of the 167 traffic arriving at the firewalls: 169 o Source IP address 171 o Destination IP address 173 o Protocol type 175 o Source port number 177 o Destination port number 179 Based on these parameters, firewalls usually decide whether to allow 180 the traffic or to drop the packets. Some firewalls may filter only 181 incoming traffic while others may also filter outgoing traffic. 183 According to Section 3.29 of RFC 2647 [2] stateful packet filtering 184 refers to the process of forwarding or rejecting traffic based on the 185 contents of a state table maintained by a firewall. These types of 186 firewalls are commonly deployed to protect networks from different 187 threats, such as blocking unsolicited incoming traffic from the 188 external networks. The following briefly describes how these 189 firewalls work since they can create additional problems with the 190 Mobile IPv6 protocol as described in the subsequent sections. 192 When a MN connects using TCP to another host in the Internet, it 193 sends a TCP SYN message to set up the connection. When that SYN 194 packet is routed through the firewall, the firewall creates an entry 195 in its state table containing the source IP address, the destination 196 IP address, the Protocol type, the source port number and the 197 destination port number indicated in that packet before forwarding 198 the packet to the destination. When an incoming message from the 199 external networks reaches the firewall, it searches the packet's 200 source IP address, destination IP address, Protocol type, source port 201 number and destination port number in its state table to see if the 202 packet matches the characteristics of a request sent previously. If 203 so, the firewall lets the packet pass. Otherwise, the packet is 204 dropped since it was not requested from inside the network. 206 The firewall removes the state table entries either when the TCP 207 close session negotiation packets are routed through, or after some 208 configurable timeout period. This ensures that dropped connections 209 do not leave holes open in the firewall. 211 For UDP, similar state is created. However, since UDP is 212 connectionless and the protocol does not have an indication of the 213 beginning nor the end of a session, the state is based only on 214 timers. 216 5. Analysis of various scenarios involving MIP6 nodes and firewalls 218 The following section describes various scenarios involving MIP6 219 nodes and firewalls and also presents the issues related to each 220 scenario. 222 The Mobile IPv6 specifications define three main entities: the Mobile 223 Node (MN), the Correspondent Node (CN) and the Home Agent (HA). Each 224 of these entities may be in a network protected by one or many 225 firewalls: 227 o Section 5.1 analyzes the issues when the MN is in a network 228 protected by firewall(s) 230 o Section 5.2 analyzes the issues when the CN is in a network 231 protected by firewall(s) 233 o Section 5.3 analyzes the issues when the HA is in a network 234 protected by firewall(s) 236 The MN may also be moving from an external network, to a network 237 protected by firewall(s). The issues of this case are described in 238 Section 5.4. 240 Some of the described issues (e.g. Section 5.1 and Section 5.2) may 241 require modifications to the protocols or to the firewalls, and 242 others (e.g. Section 5.3) may require only appropriate rules and 243 configuration to be in place. 245 5.1. Scenario where the Mobile Node is in a network protected by 246 firewall(s) 248 Let's consider a MN A, in a network protected by firewall(s). 250 +----------------+ +----+ 251 | | | HA | 252 | | +----+ 253 | | Home Agent 254 | +---+ +----+ of A +---+ 255 | | A | | FW | | B | 256 | +---+ +----+ +---+ 257 |Internal | External 258 | MN | Node 259 | | 260 +----------------+ 261 Network protected 263 Figure 1: Issues between MIP6 and firewalls when MN is in a network 264 protected by firewalls 266 A number of issues need to be considered: 268 Issue 1: When the MN A connects to the network, it should acquire a 269 local IP address (CoA), and send a Binding Update to its Home 270 Agent to update the HA with its current point of attachment. The 271 Binding Updates and Acknowledgements should be protected by IPsec 272 ESP according to the MIPv6 specifications [1]. However, as a 273 default rule, many firewalls drop IPsec ESP packets because they 274 cannot determine whether inbound ESP packets are legitimate. It 275 is difficult or impossible to create useful state by observing the 276 outbound ESP packets. This may cause the Binding Updates and 277 Acknowledgements between the Mobile Nodes and their Home Agent to 278 be dropped. 280 Issue 2: Let's now consider a node in the external network, B, trying 281 to establish a communication with MN A. 283 * B sends a packet to the Mobile Node's home address. 285 * The packet is intercepted by the MN's Home Agent which tunnels 286 it to the MN's CoA [1]. 288 * When arriving at the firewall(s) protecting MN A, the packet 289 may be dropped since the incoming packet may not match any 290 existing state. As described in Section 4, stateful inspection 291 packet filters e.g. typically drop unsolicited incoming 292 traffic. 294 * B will thus not be able to contact the MN A and establish a 295 communication. 297 Even though the HA is updated with the location of a MN, firewalls 298 may prevent Correspondent nodes from establishing communications 299 when the MN is in a network protected by firewall(s). 301 Issue 3: Let's assume a communication between MN A and an external 302 node B. MN A may want to use Route Optimization (RO) so that 303 packets can be directly exchanged between the MN and the CN 304 without passing through the HA. However the firewalls protecting 305 the MN might present issues with the Return Routability procedure 306 that needs to be performed prior to using RO. 308 According to the MIPv6 specifications, the Home Test message of 309 the RRT must be protected by IPsec in tunnel mode. However, 310 firewalls might drop any packet protected by ESP, since the 311 firewalls cannot analyze the packets encrypted by ESP (e.g. port 312 numbers). The firewalls may thus drop the Home Test messages and 313 prevent the completion of the RRT procedure. 315 Issue 4: Let's assume that MN A successfully sends a Binding Update 316 to its Home Agent (resp. Correspondent nodes) - issues 1 (resp. 317 issue 3) solved - the subsequent traffic is sent from the HA 318 (resp. CN) to the MN's CoA. However there may not be any 319 corresponding state in the firewalls. The firewalls protecting A 320 may thus drop the incoming packets. 322 The appropriate states for the traffic to the MN's CoA need to be 323 created in the firewall(s). 325 Issue 5: When the MN A moves, it may move to a link that is served by 326 a different firewall. MN A might be sending a BU to its CN, 327 however incoming packets may be dropped at the firewall, since the 328 firewall on the new link that the MN attaches to does not have any 329 state that is associated with the MN. 331 The issues described above result from the fact that the MN is behind 332 the firewall. Consequently, the MN's communication capability with 333 other nodes is affected by the firewall rules. 335 5.2. Scenario where the Correspondent Node is in a network protected by 336 firewall(s) 338 Let's consider a MN in a network, communicating with a Correspondent 339 Node C in a network protected by firewall(s). There are no issues 340 with the presence of a firewall in the scenario where the MN is 341 sending packets to the CN via a reverse tunnel that is setup between 342 the MN and HA. However firewalls may present different issues to 343 Route Optimization. 345 +----------------+ +----+ 346 | | | HA | 347 | | +----+ 348 | | Home Agent 349 | +---+ +----+ of B 350 | |CN | | FW | 351 | | C | +----+ 352 | +---+ | +---+ 353 | | | B | 354 | | +---+ 355 +----------------+ External Mobile 356 Network protected Node 357 by a firewall 359 Figure 2: Issues between MIP6 and firewalls when a CN is in a network 360 protected by firewalls 362 The following issues need to be considered: 364 Issue 1: The MN, MN B, should use its Home Address, HoA B, when 365 establishing the communication with the CN (CN C) if the MN (MN B) 366 wants to take advantage of the mobility support provided by the 367 Mobile IPv6 protocol, for its communication with CN C. The state 368 created by the firewall protecting CN C is therefore created based 369 on the IP address of C (IP C) and the home address of the node B 370 (IP HoA B). The states may be created via different means and the 371 protocol type as well as the port numbers depend on the connection 372 set up. 374 Uplink packet filters (1) 376 Source IP address: IP C 378 Destination IP address: HoA B 380 Protocol Type: TCP/UDP 382 Source Port Number: #1 384 Destination Port Number: #2 386 Downlink packet filters (2) 388 Source IP address: HoA B 390 Destination IP address: IP C 392 Protocol Type: TCP/UDP 394 Source Port Number: #2 396 Destination Port Number: #1 398 Nodes C and B might be topologically close to each other while B's 399 Home Agent may be far away, resulting in a trombone effect that 400 can create delay and degrade the performance. The MN B may decide 401 to initiate the route optimization procedure with Node C. Route 402 optimization requires the MN B to send a Binding Update to Node C 403 in order to create an entry in its binding cache that maps the MNs 404 home address to its current care-of-address. However, prior to 405 sending the binding update, the Mobile Node must first execute a 406 Return Routability Test: 408 * the Mobile Node B has to send a Home Test Init (HoTI) message 409 via its Home Agent and 411 * a Care of Test Init (COTI) message directly to its 412 Correspondent Node C. 414 The Care of Test Init message is sent using the CoA of B as the 415 source address. Such a packet does not match any entry in the 416 protecting firewall (2). The CoTi message will thus be dropped by 417 the firewall. 419 The HoTI is a Mobility Header packet, and as the protocol type 420 differs from the established state in the firewall (see (2)), the 421 HoTI packet will also be dropped. 423 As a consequence, the RRT cannot be completed and route 424 optimization cannot be applied. Every packet has to go through 425 the node B's Home Agent and tunneled between B's Home Agent and B. 427 +----------------+ 428 | +----+ HoTI (HoA) +----+ 429 | | FW |X<---------------|HA B| 430 | +----X +----+ 431 | +------+ | ^ CoTI & HoTI ^ 432 | | CN C | | | dropped by FW | 433 | +------+ | | | HoTI 434 | | | | 435 | | | CoTI (CoA)+------+ 436 | | +------------------| MN B | 437 +----------------+ +------+ 438 Network protected External Mobile 439 by a firewall Node 441 Figure 3: Issues with Return Routability Test 443 Issue 2: Let's assume that the Binding Update to the CN is 444 successful, the firewall(s) might still drop packets 446 1. coming from the CoA, since these incoming packets are sent 447 from the CoA and do not match the Downlink Packet filter (2) 449 2. sent from the CN to the CoA if uplink packet filters are 450 implemented. The uplink packets are sent to the MN's CoA and 451 do not match the uplink packet filter (1). 453 The packet filters for the traffic sent to (resp. from) the CoA 454 need to be created in the firewall(s). 456 Requiring the firewalls to update the connection state upon 457 detecting Binding Update messages from a node outside the network 458 protected by the firewall does not appear feasible nor desirable, 459 since currently the firewall does not have any means to verify the 460 validity of Binding Update messages and to therefore securely 461 modify the state information. Changing the firewall states 462 without verifying the validity of the Binding Update messages 463 could lead to denial of service attacks. Malicious nodes may send 464 fake binding updates, forcing the firewall to change its state 465 information, and therefore leading the firewall to drop packets 466 from the connections that use the legitimate addresses. An 467 adversary might also use an address update to enable its own 468 traffic to pass through the firewall and enter the network. 470 Issue 3: Let's assume that the Binding Update to the CN is 471 successful. The CN may be protected by different firewalls and as 472 a result of the MN's change of IP address, incoming and outgoing 473 traffic may pass through a different firewall. The new firewall 474 may not have any state associated with the CN and incoming packets 475 (and potentially outgoing traffic as well) may be dropped at the 476 firewall. 478 Firewall technology allows clusters of firewalls to share state 479 [3]. This, for example, allows the support of routing asymmetry. 480 However, if the previous and the new firewalls, where the packets 481 are routed through after the Binding Update has been sent, do not 482 share state, this may result in packets being dropped at the new 483 firewall. The new firewall not having any state associated with 484 the CN, incoming packets (and potentially outgoing traffic as 485 well) may be dropped at the new firewall. 487 5.3. Scenario where the HA is in a network protected by firewall(s) 489 In the scenarios where the Home Agent is in a network protected by 490 firewall(s), the following issues may exist: 492 Issue 1: If the firewall(s) protecting the Home Agent block ESP 493 traffic, many of the MIPv6 signaling (e.g. Binding Update, HoT) 494 may be dropped at the firewall(s) preventing MN(s) from updating 495 their binding cache and performing Route Optimization, since 496 Binding Update, HoT and other MIPv6 signaling must be protected by 497 IPsec ESP. 499 Issue 2: If the firewall(s) protecting the Home Agent block 500 unsolicited incoming traffic (e.g. as stateful inspection packet 501 filters do), the firewall(s) may drop connection set up requests 502 from CN, and packets from MN. 504 Issue 3: If the Home Agent is in a network protected by several 505 firewalls, a MN/CN's change of IP address may result in the 506 traffic to and from the Home Agent passing through a different 507 firewall that may not have the states corresponding to the flows. 508 As a consequence, packets may be dropped at the firewall. 510 5.4. Scenario where MN moves to a network protected by firewall(s) 512 Let's consider a HA in a network protected by firewall(s). The 513 following issues need to be investigated: 515 Issue 1: Similarly to the issue 1 described in Section 5.1, the MN 516 will send a Binding Update to its Home Agent after acquiring a 517 local IP address (CoA). The Binding Updates and Acknowledgements 518 should be protected by IPsec ESP according to the MIPv6 519 specifications [1]. However, as a default rule, many firewalls 520 drop ESP packets. This may cause the Binding Updates and 521 Acknowledgements between the Mobile Nodes and their Home Agent to 522 be dropped. 524 Issue 2: The MN may be in a communication with a CN, or a CN may be 525 attempting to establish a connection with the MN. In both cases, 526 packets sent from the CN will be forwarded by the MN's HA to the 527 MN's CoA. However when the packets arrive at the firewall(s), the 528 incoming traffic may not match any existing state, and the 529 firewall(s) may therefore drop it. 531 Issue 3: If the MN is in a communication with a CN, the MN may 532 attempt to execute a RRT for packets to be route optimized. 533 Similarly to the issue 3, Section 5.1, the Home Test message which 534 should be protected by ESP may be dropped by firewall(s) 535 protecting the MN. Firewall(s) may as a default rule drop any ESP 536 traffic. As a consequence, the RRT cannot be completed. 538 Issue 4: If the MN is in a communication with a CN, and assuming that 539 the MN successfully sent a Binding Update to its CN to use Route 540 Optimization, packets will then be sent from the CN to the MN's 541 CoA and from the MN's CoA to the CN. 543 Packets sent from the CN to the MN's CoA may however not match any 544 existing entry in the firewall(s) protecting the MN, and therefore 545 be dropped by the firewall(s). 547 If packet filtering is applied to uplink traffic (i.e. traffic 548 sent by the MN), packets sent from the MN's CoA to the the CN may 549 not match any entry in the firewall(s) either and may be dropped 550 as well. 552 6. Conclusions 554 Current firewalls may not only prevent route optimization but may 555 also prevent regular TCP and UDP sessions from being established in 556 some cases. This document describes some of the issues between the 557 Mobile IPv6 protocol and current firewall technologies. 559 This document captures the various issues involved in the deployment 560 of Mobile IPv6 in networks that would invariably include firewalls. 561 A number of different scenarios are described which include 562 configurations where the mobile node, correspondent node and home 563 agent exist across various boundaries delimited by the firewalls. 564 This enables a better understanding of the issues when deploying 565 Mobile IPv6 as well as providing an understanding for firewall design 566 and policies to be installed therein. 568 7. Security Considerations 570 This document describes several issues that exist between the Mobile 571 IPv6 protocol and firewalls. 573 Firewalls may prevent Mobile IP6 signaling in addition to dropping 574 incoming/outgoing traffic. 576 If the firewall configuration is modified in order to support the 577 Mobile IPv6 protocol but not properly configured, many attacks may be 578 possible as outlined above: malicious nodes may be able to launch 579 different types of denial of service attacks. 581 8. Acknowledgments 583 We would like to thank James Kempf, Samita Chakrabarti, Giaretta 584 Gerardo, Steve Bellovin, Henrik Levkowetz and Spencer Dawkins for 585 their valuable comments. Their suggestions have helped to improve 586 both the presentation and the content of the document. 588 9. References 590 9.1. Normative References 592 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 593 IPv6", RFC 3775, June 2004. 595 9.2. Informative References 597 [2] Newman, D., "Benchmarking Terminology for Firewall Performance", 598 RFC 2647, August 1999. 600 [3] Noble, J., Doug, D., Hourihan, K., Hourihan, K., Stephens, R., 601 Stiefel, B., Amon, A., and C. Tobkin, "Check Point NG VPN-1/ 602 Firewall-1 Advanced Configuration and Troubleshooting", Syngress 603 Publishing Inc. , 2003. 605 [4] Chen, X., Watson, M., and M. Harris, "Problem Statement for 606 MIPv6 Interactions with GPRS/UMTS Packet Filtering", 607 draft-chen-mip6-gprs-03 (work in progress), February 2005. 609 Appendix A. Applicability to 3G Networks 611 In 3G networks, different packet filtering functionalities may be 612 implemented to prevent malicious nodes from flooding or launching 613 other attacks against the 3G subscribers. The packet filtering 614 functionality of 3G networks are further described in [4]. Packet 615 filters are set up and applied to both uplink and downlink traffic: 616 outgoing and incoming data not matching the packet filters is 617 dropped. The issues described in this document also apply to 3G 618 networks. 620 Authors' Addresses 622 Franck Le 623 Carnegie Mellon University 624 5000 Forbes Avenue 625 Pittsburgh, PA 15213 626 USA 628 Email: franckle@cmu.edu 630 Stefano Faccin 631 Nokia Research Center 632 6000 Connection Drive 633 Irving, TX 75039 634 USA 636 Email: stefano.faccin@nokia.com 638 Basavaraj Patil 639 Nokia 640 6000 Connection Drive 641 Irving, TX 75039 642 USA 644 Email: Basavaraj.Patil@nokia.com 646 Hannes Tschofenig 647 Siemens 648 Otto-Hahn-Ring 6 649 Munich, Bavaria 81739 650 Germany 652 Email: Hannes.Tschofenig@siemens.com 653 URI: http://www.tschofenig.com 655 Intellectual Property Statement 657 The IETF takes no position regarding the validity or scope of any 658 Intellectual Property Rights or other rights that might be claimed to 659 pertain to the implementation or use of the technology described in 660 this document or the extent to which any license under such rights 661 might or might not be available; nor does it represent that it has 662 made any independent effort to identify any such rights. Information 663 on the procedures with respect to rights in RFC documents can be 664 found in BCP 78 and BCP 79. 666 Copies of IPR disclosures made to the IETF Secretariat and any 667 assurances of licenses to be made available, or the result of an 668 attempt made to obtain a general license or permission for the use of 669 such proprietary rights by implementers or users of this 670 specification can be obtained from the IETF on-line IPR repository at 671 http://www.ietf.org/ipr. 673 The IETF invites any interested party to bring to its attention any 674 copyrights, patents or patent applications, or other proprietary 675 rights that may cover technology that may be required to implement 676 this standard. Please address the information to the IETF at 677 ietf-ipr@ietf.org. 679 Disclaimer of Validity 681 This document and the information contained herein are provided on an 682 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 683 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 684 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 685 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 686 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 687 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 689 Copyright Statement 691 Copyright (C) The Internet Society (2006). This document is subject 692 to the rights, licenses and restrictions contained in BCP 78, and 693 except as set forth therein, the authors retain all their rights. 695 Acknowledgment 697 Funding for the RFC Editor function is currently provided by the 698 Internet Society.