idnits 2.17.1 draft-ietf-mip6-firewalls-03.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 685. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 662. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 675. ** 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 (October 17, 2005) is 6766 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: April 20, 2006 S. Faccin 5 B. Patil 6 Nokia 7 H. Tschofenig 8 Siemens 9 October 17, 2005 11 Mobile IPv6 and Firewalls: Problem statement 12 draft-ietf-mip6-firewalls-03.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 April 20, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 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 cdma2000 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 MN: Mobile Node 151 o RO: Route Optimization 153 o RRT: Return Routability Test 155 4. Overview of firewalls 157 The following section provides a brief overview of firewalls. It is 158 intended as background information so that issues with the Mobile 159 IPv6 protocol can then be presented in detail in the following 160 sections. 162 There are different types of firewalls and state can be created in 163 these firewalls through different methods. Independent of the 164 adopted method, firewalls typically look at five parameters of the 165 traffic arriving at the firewalls: 167 o Source IP address 169 o Destination IP address 171 o Protocol type 173 o Source port number 175 o Destination port number 177 Based on these parameters, firewalls usually decide whether to allow 178 the traffic or to drop the packets. Some firewalls may filter only 179 incoming traffic while others may also filter outgoing traffic. 181 According to Section 3.29 of RFC 2647 [2] stateful packet filtering 182 refers to the process of forwarding or rejecting traffic based on the 183 contents of a state table maintained by a firewall. These types of 184 firewalls are commonly deployed to protect networks from different 185 threats, such as blocking unsolicited incoming traffic from the 186 external networks. The following briefly describes how these 187 firewalls work since they can create additional problems with the 188 Mobile IPv6 protocol as described in the subsequent sections. 190 When a MN connects using TCP to another host in the Internet, it 191 sends a TCP SYN message to set up the connection. When that SYN 192 packet is routed through the firewall, the firewall creates an entry 193 in its state table containing the source IP address, the destination 194 IP address, the Protocol type, the source port number and the 195 destination port number indicated in that packet before forwarding 196 the packet to the destination. When an incoming message from the 197 external networks reaches the firewall, it searches the packet's 198 source IP address, destination IP address, Protocol type, source port 199 number and destination port number in its state table to see if the 200 packet matches the characteristics of a request sent previously. If 201 so, the firewall lets the packet pass. Otherwise, the packet is 202 dropped since it was not requested from inside the network. 204 The firewall removes the state table entries either when the TCP 205 close session negotiation packets are routed through, or after some 206 configurable timeout period. This ensures that dropped connections 207 do not leave holes in the table. 209 For UDP, similar state is created. However, since UDP is 210 connectionless and the protocol does not have an indication of the 211 beginning nor the end of a session, the state is based only on 212 timers. 214 5. Analysis of various scenarios involving MIP6 nodes and firewalls 216 The following section describes various scenarios involving MIP6 217 nodes and firewalls and also presents the issues related to each 218 scenario. 220 The Mobile IPv6 specifications define three main entities: the Mobile 221 Node (MN), the Correspondent Node (CN) and the Home Agent (HA). Each 222 of these entities may be in a network protected by one or many 223 firewalls: 225 o Section 5.1 analyzes the issues when the MN is in a network 226 protected by firewall(s) 228 o Section 5.2 analyzes the issues when the CN is in a network 229 protected by firewall(s) 231 o Section 5.3 analyzes the issues when the HA is in a network 232 protected by firewall(s) 234 The MN may also be moving from an external network, to a network 235 protected by firewall(s). The issues of this case are described in 236 Section 5.3. 238 Some of the described issues (e.g. Section 5.1 and Section 5.2) may 239 require modifications to the protocols or to the firewalls, and 240 others (e.g. Section 5.3) may require only appropriate rules and 241 configuration to be in place. 243 5.1. Scenario where the Mobile Node is in a network protected by 244 firewall(s) 246 Let's consider a MN A, in a network protected by firewall(s). 248 +----------------+ +----+ 249 | | | HA | 250 | | +----+ 251 | | Home Agent 252 | +---+ +----+ of A +---+ 253 | | A | | FW | | B | 254 | +---+ +----+ +---+ 255 |Internal | External 256 | MN | Node 257 | | 258 +----------------+ 259 Network protected 261 Figure 1: Issues between MIP6 and firewalls when MN is in a network 262 protected by firewalls 264 A number of issues need to be considered: 266 Issue 1: When the MN A connects to the network, it should acquire a 267 local IP address (CoA), and send a Binding Update to its Home 268 Agent to update the HA with its current point of attachment. The 269 Binding Updates and Acknowledgements should be protected by IPsec 270 ESP according to the MIPv6 specifications [1]. However, as a 271 default rule, many firewalls drop IPsec ESP packets because they 272 cannot determine whether inbound ESP packets are legitimate. It 273 is difficult or impossible to create useful state by observing the 274 outbound ESP packets. This may cause the Binding Updates and 275 Acknowledgements between the Mobile Nodes and their Home Agent to 276 be dropped. 278 Issue 2: Let's now consider a node in the external network, B, trying 279 to establish a communication with MN A. 281 * B sends a packet to the Mobile Node's home address. 283 * The packet is intercepted by the MN's Home Agent which tunnels 284 it to the MN's CoA [1]. 286 * When arriving at the firewall(s) protecting MN A, the packet 287 may be dropped since the incoming packet may not match any 288 existing state. As described in Section 4, stateful inspection 289 packet filters e.g. typically drop unsolicited incoming 290 traffic. 292 * B will thus not be able to contact the MN A and establish a 293 communication. 295 Even though the HA is updated with the location of a MN, firewalls 296 may prevent Correspondent nodes from establishing communications 297 when the MN is in a network protected by firewall(s). 299 Issue 3: Let's assume a communication between MN A and an external 300 node B. MN A may want to use Route Optimization (RO) so that 301 packets can be directly exchanged between the MN and the CN 302 without passing through the HA. However the firewalls protecting 303 the MN might present issues with the Return Routability procedure 304 that needs to be performed prior to using RO. 306 According to the MIPv6 specifications, the Home Test message of 307 the RRT must be protected by IPsec in tunnel mode. However, 308 firewalls might drop any packet protected by ESP, since the 309 firewalls cannot analyze the packets encrypted by ESP (e.g. port 310 numbers). The firewalls may thus drop the Home Test messages and 311 prevent the completion of the RRT procedure. 313 Issue 4: Let's assume that MN A successfully sends a Binding Update 314 to its Home Agent (resp. Correspondent nodes) - issues 1 (resp. 315 issue 3) solved - the subsequent traffic is sent from the HA 316 (resp. CN) to the MN's CoA. However there may not be any 317 corresponding state in the firewalls. The firewalls protecting A 318 may thus drop the incoming packets. 320 The appropriate states for the traffic to the MN's CoA need to be 321 created in the firewall(s). 323 Issue 5: When the MN A moves, it may move to a link that is served by 324 a different firewall. MN A might be sending a BU to its CN, 325 however incoming packets may be dropped at the firewall, since the 326 firewall on the new link that the MN attaches to does not have any 327 state that is associated with the MN. 329 The issues described above result from the fact that the MN is behind 330 the firewall. Consequently, the MN's communication capability with 331 other nodes is affected by the firewall rules. 333 5.2. Scenario where the Correspondent Node is in a network protected by 334 firewall(s) 336 Let's consider a MN in a network, communicating with a Correspondent 337 Node C in a network protected by firewall(s). There are no issues 338 with the presence of a firewall in the scenario where the MN is 339 sending packets to the CN via a reverse tunnel that is setup between 340 the MN and HA. However firewalls may present different issues to 341 Route Optimization. 343 +----------------+ +----+ 344 | | | HA | 345 | | +----+ 346 | | Home Agent 347 | +---+ +----+ of B 348 | |CN | | FW | 349 | | C | +----+ 350 | +---+ | +---+ 351 | | | B | 352 | | +---+ 353 +----------------+ External Mobile 354 Network protected Node 355 by a firewall 357 Figure 2: Issues between MIP6 and firewalls when a CN is in a network 358 protected by firewalls 360 The following issues need to be considered: 362 Issue 1: The MN, MN B, should use its Home Address, HoA B, when 363 establishing the communication with the CN (CN C) if the MN (MN B) 364 wants to take advantage of the mobility support provided by the 365 Mobile IPv6 protocol, for its communication with CN C. The state 366 created by the firewall protecting CN C is therefore created based 367 on the IP address of C (IP C) and the home address of the node B 368 (IP HoA B). The states may be created via different means and the 369 protocol type as well as the port numbers depend on the connection 370 set up. 372 Uplink packet filters (1) 374 Source IP address: IP C 376 Destination IP address: HoA B 378 Protocol Type: TCP/UDP 380 Source Port Number: #1 382 Destination Port Number: #2 384 Downlink packet filters (2) 386 Source IP address: HoA B 388 Destination IP address: IP C 390 Protocol Type: TCP/UDP 392 Source Port Number: #2 394 Destination Port Number: #1 396 Nodes C and B might be topologically close to each other while B's 397 Home Agent may be far away, resulting in a trombone effect that 398 can create delay and degrade the performance. The MN B may decide 399 to initiate the route optimization procedure with Node C. Route 400 optimization requires the MN B to send a Binding Update to Node C 401 in order to create an entry in its binding cache that maps the MNs 402 home address to its current care-of-address. However, prior to 403 sending the binding update, the Mobile Node must first execute a 404 Return Routability Test: 406 * the Mobile Node B has to send a Home Test Init (HoTI) message 407 via its Home Agent and 409 * a Care of Test Init (COTI) message directly to its 410 Correspondent Node C. 412 The Care of Test Init message is sent using the CoA of B as the 413 source address. Such a packet does not match any entry in the 414 protecting firewall (2). The CoTi message will thus be dropped by 415 the firewall. 417 The HoTI is a Mobility Header packet, and the protocol type 418 differs from the existing states (2), the HoTI packet will also be 419 dropped. 421 As a consequence, the RRT cannot be completed and route 422 optimization cannot be applied. Every packet has to go through 423 the node B's Home Agent and tunneled between B's Home Agent and B. 425 +----------------+ 426 | +----+ HoTI (HoA) +----+ 427 | | FW |X<---------------|HA B| 428 | +----X +----+ 429 | +------+ | ^ CoTI & HoTI ^ 430 | | CN C | | | dropped by FW | 431 | +------+ | | | HoTI 432 | | | | 433 | | | CoTI (CoA)+------+ 434 | | +------------------| MN B | 435 +----------------+ +------+ 436 Network protected External Mobile 437 by a firewall Node 439 Figure 3: Issues with Return Routability Test 441 Issue 2: Let's assume that the Binding Update to the CN is 442 successful, the firewall(s) might still drop packets 444 1. coming from the CoA, since these incoming packets are sent 445 from the CoA and do not match the Downlink Packet filter (2) 447 2. sent from the CN to the CoA if uplink packet filters are 448 implemented. The uplink packets are sent to the MN's CoA and 449 do not match the uplink packet filter (1). 451 The packet filters for the traffic sent to (resp. from) the CoA 452 need to be created in the firewall(s). 454 Requiring the firewalls to update the connection state upon 455 detecting Binding Update messages from a node outside the network 456 protected by the firewall does not appear feasible nor desirable, 457 since currently the firewall does not have any means to verify the 458 validity of Binding Update messages and to therefore securely 459 modify the state information. Changing the firewall states 460 without verifying the validity of the Binding Update messages 461 could lead to denial of service attacks. Malicious nodes may send 462 fake binding updates, forcing the firewall to change its state 463 information, and therefore leading the firewall to drop packets 464 from the connections that use the legitimate addresses. An 465 adversary might also use an address update to enable its own 466 traffic to pass through the firewall and enter the network. 468 Issue 3: Let's assume that the Binding Update to the CN is 469 successful. The CN may be protected by different firewalls and as 470 a result of the MN's change of IP address, incoming and outgoing 471 traffic may pass through a different firewall. The new firewall 472 may not have any state associated with the CN and incoming packets 473 (and potentially outgoing traffic as well) may be dropped at the 474 firewall. 476 Firewall technology allows clusters of firewalls to share state 477 [3]. This, for example, allows the support of routing asymmetry. 478 However, if the previous and the new firewalls, where the packets 479 are routed through after the Binding Update has been sent, do not 480 share state, this may result in packets being dropped at the new 481 firewall. The new firewall not having any state associated with 482 the CN, incoming packets (and potentially outgoing traffic as 483 well) may be dropped at the new firewall. 485 5.3. Scenario where the HA is in a network protected by firewall(s) 487 In the scenarios where the Home Agent is in a network protected by 488 firewall(s), the following issues may exist: 490 Issue 1: If the firewall(s) protecting the Home Agent block ESP 491 traffic, many of the MIPv6 signaling (e.g. Binding Update, HoT) 492 may be dropped at the firewall(s) preventing MN(s) from updating 493 their binding cache and performing Route Optimization, since 494 Binding Update, HoT and other MIPv6 signaling must be protected by 495 IPsec ESP. 497 Issue 2: If the firewall(s) protecting the Home Agent block 498 unsolicited incoming traffic (e.g. as stateful inspection packet 499 filters do), the firewall(s) may drop connection set up requests 500 from CN, and packets from MN. 502 Issue 3: If the Home Agent is in a network protected by several 503 firewalls, a MN/CN's change of IP address may result in the 504 traffic to and from the Home Agent passing through a different 505 firewall that may not have the states corresponding to the flows. 506 As a consequence, packets may be dropped at the firewall. 508 5.4. Scenario where MN moves to a network protected by firewall(s) 510 Let's consider a HA in a network protected by firewall(s). The 511 following issues need to be investigated: 513 Issue 1: Similarly to the issue 1 described in Section 5.1, the MN 514 will send a Binding Update to its Home Agent after acquiring a 515 local IP address (CoA). The Binding Updates and Acknowledgements 516 should be protected by IPsec ESP according to the MIPv6 517 specifications [1]. However, as a default rule, many firewalls 518 drop ESP packets. This may cause the Binding Updates and 519 Acknowledgements between the Mobile Nodes and their Home Agent to 520 be dropped. 522 Issue 2: The MN may be in a communication with a CN, or a CN may be 523 attempting to establish a connection with the MN. In both cases, 524 packets sent from the CN will be forwarded by the MN's HA to the 525 MN's CoA. However when the packets arrive at the firewall(s), the 526 incoming traffic may not match any existing state, and the 527 firewall(s) may therefore drop it. 529 Issue 3: If the MN is in a communication with a CN, the MN may 530 attempt to execute a RRT for packets to be route optimized. 531 Similarly to the issue 3, Section 5.1, the Home Test message which 532 should be protected by ESP may be dropped by firewall(s) 533 protecting the MN. Firewall(s) may as a default rule drop any ESP 534 traffic. As a consequence, the RRT cannot be completed. 536 Issue 4: If the MN is in a communication with a CN, and assuming that 537 the MN successfully sent a Binding Update to its CN to use Route 538 Optimization, packets will then be sent from the CN to the MN's 539 CoA and from the MN's CoA to the CN. 541 Packets sent from the CN to the MN's CoA may however not match any 542 existing entry in the firewall(s) protecting the MN, and therefore 543 be dropped by the firewall(s). 545 If packet filtering is applied to uplink traffic (i.e. traffic 546 sent by the MN), packets sent from the MN's CoA to the the CN may 547 not match any entry in the firewall(s) either and may be dropped 548 as well. 550 6. Conclusions 552 Current firewalls may not only prevent route optimization but may 553 also prevent regular TCP and UDP sessions from being established in 554 some cases. This document describes some of the issues between the 555 Mobile IPv6 protocol and current firewall technologies. 557 This document captures the various issues involved in the deployment 558 of Mobile IPv6 in networks that would invariably include firewalls. 559 A number of different scenarios are described which include 560 configurations where the mobile node, correspondent node and home 561 agent exist across various boundaries delimited by the firewalls. 562 This enables a better understanding of the issues when deploying 563 Mobile IPv6 as well as providing an understanding for firewall design 564 and policies to be installed therein. 566 7. Security Considerations 568 This document describes several issues that exist between the Mobile 569 IPv6 protocol and firewalls. 571 Firewalls may prevent Mobile IP6 signaling in addition to dropping 572 incoming/outgoing traffic. 574 If the firewall configuration is modified in order to support the 575 Mobile IPv6 protocol but not properly configured, many attacks may be 576 possible as outlined above: malicious nodes may be able to launch 577 different types of denial of service attacks. 579 8. Acknowledgments 581 We would like to thank James Kempf, Samita Chakrabarti, Giaretta 582 Gerardo, Steve Bellovin, Henrik Levkowetz and Spencer Dawkins for 583 their valuable comments. Their suggestions have helped to improve 584 both the presentation and the content of the document. 586 9. References 588 9.1. Normative References 590 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 591 IPv6", RFC 3775, June 2004. 593 9.2. Informative References 595 [2] Newman, D., "Benchmarking Terminology for Firewall Performance", 596 RFC 2647, August 1999. 598 [3] Noble, J., Doug, D., Hourihan, K., Hourihan, K., Stephens, R., 599 Stiefel, B., Amon, A., and C. Tobkin, "Check Point NG VPN-1/ 600 Firewall-1 Advanced Configuration and Troubleshooting", Syngress 601 Publishing Inc. , 2003. 603 [4] Chen, X., Watson, M., and M. Harris, "Problem Statement for 604 MIPv6 Interactions with GPRS/UMTS Packet Filtering", 605 draft-chen-mip6-gprs-03 (work in progress), February 2005. 607 Appendix A. Applicability to 3G Networks 609 In 3G networks, different packet filtering functionalities may be 610 implemented to prevent malicious nodes from flooding or launching 611 other attacks against the 3G subscribers. The packet filtering 612 functionality of 3G networks are further described in [4]. Packet 613 filters are set up and applied to both uplink and downlink traffic: 614 outgoing and incoming data not matching the packet filters is 615 dropped. The issues described in this document also apply to 3G 616 networks. 618 Authors' Addresses 620 Franck Le 621 Carnegie Mellon University 622 5000 Forbes Avenue 623 Pittsburgh, PA 15213 624 USA 626 Email: franckle@cmu.edu 628 Stefano Faccin 629 Nokia Research Center 630 6000 Connection Drive 631 Irving, TX 75039 632 USA 634 Email: stefano.faccin@nokia.com 636 Basavaraj Patil 637 Nokia 638 6000 Connection Drive 639 Irving, TX 75039 640 USA 642 Email: Basavaraj.Patil@nokia.com 644 Hannes Tschofenig 645 Siemens 646 Otto-Hahn-Ring 6 647 Munich, Bavaria 81739 648 Germany 650 Email: Hannes.Tschofenig@siemens.com 651 URI: http://www.tschofenig.com 653 Intellectual Property Statement 655 The IETF takes no position regarding the validity or scope of any 656 Intellectual Property Rights or other rights that might be claimed to 657 pertain to the implementation or use of the technology described in 658 this document or the extent to which any license under such rights 659 might or might not be available; nor does it represent that it has 660 made any independent effort to identify any such rights. Information 661 on the procedures with respect to rights in RFC documents can be 662 found in BCP 78 and BCP 79. 664 Copies of IPR disclosures made to the IETF Secretariat and any 665 assurances of licenses to be made available, or the result of an 666 attempt made to obtain a general license or permission for the use of 667 such proprietary rights by implementers or users of this 668 specification can be obtained from the IETF on-line IPR repository at 669 http://www.ietf.org/ipr. 671 The IETF invites any interested party to bring to its attention any 672 copyrights, patents or patent applications, or other proprietary 673 rights that may cover technology that may be required to implement 674 this standard. Please address the information to the IETF at 675 ietf-ipr@ietf.org. 677 Disclaimer of Validity 679 This document and the information contained herein are provided on an 680 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 681 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 682 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 683 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 684 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 685 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 687 Copyright Statement 689 Copyright (C) The Internet Society (2005). This document is subject 690 to the rights, licenses and restrictions contained in BCP 78, and 691 except as set forth therein, the authors retain all their rights. 693 Acknowledgment 695 Funding for the RFC Editor function is currently provided by the 696 Internet Society.