idnits 2.17.1 draft-ietf-mip6-firewalls-01.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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 616. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 606. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 (February 20, 2005) is 6997 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-02 Summary: 7 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 S. Faccin 4 Expires: August 24, 2005 B. Patil 5 Nokia 6 H. Tschofenig 7 Siemens 8 February 20, 2005 10 Mobile IPv6 and Firewalls Problem statement 11 draft-ietf-mip6-firewalls-01.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 24, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 Firewalls are an integral aspect of a majority of IP networks today 47 given the state of security in the Internet, threats and 48 vulnerabilities to data networks. Current IP networks are 49 predominantly based on IPv4 technology and hence firewalls have been 50 designed for these networks. Deployment of IPv6 networks is 51 currently progressing, albeit at a slower pace. Firewalls for IPv6 52 networks are still maturing and in development. 54 Mobility support for IPv6 has now been standardized as specified in 55 RFC 3775. Given the fact that Mobile IPv6 is a recent standard, most 56 firewalls available for IPv6 networks do not support Mobile IPv6. 58 Unless firewalls are aware of Mobile IPv6 protocol details, these 59 security devices will interfere in the smooth operation of the 60 protocol and can be a detriment to deployment. This document 61 presents deployment of IPv6 networks when they support Mobile IPv6 62 and firewalls. 64 The issues are not only applicable to firewalls protecting enterprise 65 networks, but are also applicable in 3G mobile networks such as 66 GPRS/UMTS and CDMA2000 networks, where packet filters are implemented 67 in the GGSN in GPRS/UMTS networks and the PDSN in CDMA2000 networks. 69 The goal of this Internet draft is to highlight the issues with 70 firewalls and Mobile IPv6 and act as an enabler for further 71 discussion. Issues identified here can be solved by developing 72 appropriate solutions in the MIP6 WG. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 6 79 4. Overview of firewalls . . . . . . . . . . . . . . . . . . . . 7 80 5. Analysis of various scenarios involving MIP6 nodes and 81 firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 5.1 Scenario where the Mobile Node is in a network 83 protected by firewall(s) . . . . . . . . . . . . . . . . . 9 84 5.2 Scenario where the Correspondent Node is in a network 85 protected by firewall(s) . . . . . . . . . . . . . . . . . 11 86 5.3 Scenario where the HA is in a network protected by 87 firewall(s) . . . . . . . . . . . . . . . . . . . . . . . 14 88 5.4 Scenario where MN moves to a network protected by 89 firewall(s) . . . . . . . . . . . . . . . . . . . . . . . 14 90 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 92 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 9.1 Normative References . . . . . . . . . . . . . . . . . . . 19 95 9.2 Informative References . . . . . . . . . . . . . . . . . . 19 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 97 A. Applicability to 3G Networks . . . . . . . . . . . . . . . . . 21 98 Intellectual Property and Copyright Statements . . . . . . . . 22 100 1. Introduction 102 Mobile IPv6 enables IP mobility for IPv6 nodes. It allows a mobile 103 IPv6 node to be reachable via its home IPv6 address irrespective of 104 any link that the mobile attaches to. This is possible as a result 105 of the extensions to IPv6 defined in the Mobile IPv6 specification 106 [1]. 108 Mobile IPv6 protocol design also incorporates a feature termed as 109 Route Optimization. This set of extensions is a fundamental part of 110 the protocol that enables optimized routing of packets between a 111 Mobile Node and its correspondent node and therefore the performance 112 of the communication. 114 In most cases, current firewall technologies, however, do not support 115 Mobile IPv6 or are even unaware of Mobile IPv6 headers and 116 extensions. Since most networks in the current business environment 117 deploy firewalls, this may prevent future large-scale deployment of 118 the Mobile IPv6 protocol. 120 This document presents in detail about some of the issues that 121 firewalls present for Mobile IPv6 deployment, as well as the impact 122 of each issue. 124 2. Terminology 126 Return Routability Test (RRT): The Return Routability Test is a 127 procedure defined in RFC 3775 [1]. It is performed prior to the 128 Route Optimization (RO), where a mobile node (MN) instructs a 129 correspondent node (CN) to direct the mobile node's data traffic 130 to its claimed care-of address (CoA). The Return Routability 131 procedure provides some security assurance and prevents the misuse 132 of Mobile IPv6 signaling to maliciously redirect the traffic or to 133 launch other attacks. 135 3. Abbreviations 137 This document uses the following abbreviations: 138 o CN Correspondent Node 139 o CoA Care of Address 140 o CoTI Care of Test Init 141 o HA Home Agent 142 o HoA Home Address 143 o HoTI Home Test Init 144 o MN Mobile Node 145 o RO Route Optimization 146 o RRT Return Routability Test 148 4. Overview of firewalls 150 The following provides a brief overview of firewalls. This section 151 is intended as a background information so that issues with the 152 Mobile IPv6 protocol can then be presented in detail in the following 153 sections. Readers familiar with firewall technology may skip this 154 section. 156 There are different types of firewalls and state can be created in 157 these firewalls through different methods. Independent of the 158 adopted method, firewalls typically look at five parameters of the 159 traffic arriving at the firewalls: 161 o Source IP address 162 o Destination IP address 163 o Protocol type 164 o Source port number 165 o Destination port number 167 Based on these parameters, firewalls usually decide whether to allow 168 the traffic or to drop the packets. Some firewalls may filter only 169 incoming traffic while others may also filter outgoing traffic. 171 Stateful packet filters are a specific type of firewalls. They are 172 commonly deployed to protect networks from different threats. 173 Stateful packet filters typically block unsolicited incoming traffic 174 from the external networks. The following briefly describe how these 175 firewalls work since they can create additional issues with the 176 Mobile IPv6 protocol as described in the subsequent sections. 178 When a MN connects using TCP to another host in the Internet, it 179 sends a TCP SYN message to set up the connection. When that SYN 180 packet is routed through the firewall, the firewall creates an entry 181 in its state table containing the source IP address, the destination 182 IP address, the Protocol type, the source port number and the 183 destination port number indicated in that packet and then forwards 184 the packet to the destination. When the response comes back, the 185 filter looks up the packet's source IP address, destination IP 186 address, Protocol type, source port number and destination port 187 number in its state table: If they match an expected response, the 188 firewall let the packet to pass. If no table entry exists, the 189 packet is dropped since it was not requested from inside the network. 191 The filter removes the state table entries when the TCP close session 192 negotiation packets are routed through, or after some period of 193 delay, usually a few minutes. This ensures that dropped connections 194 do not leave table holes open. 196 For UDP, similar state is created but since UDP is connectionless and 197 the protocol does not have indication of the beginning nor the end of 198 a session, the state is based only on timers. 200 5. Analysis of various scenarios involving MIP6 nodes and firewalls 202 The following section describes various scenarios involving MIP6 203 nodes and firewalls and also presents the issues related to each 204 scenario. 206 The Mobile IPv6 specifications define three main entities: the Mobile 207 Node (MN), the Correspondent Node (CN) and the Home Agent (HA). Each 208 of these entities may be in a network protected by one or many 209 firewalls: 211 o Section 5.1 analyzes the issues when the MN is in a network 212 protected by firewall(s) 213 o Section 5.2 analyzes the issues when the CN is in a network 214 protected by firewall(s) 215 o Section 5.3 analyzes the issues when the HA is in a network 216 protected by firewall(s) 218 The MN may also be moving from an external network, to a network 219 protected by firewall(s). The issues of this case are described in 220 Section 5.3. 222 5.1 Scenario where the Mobile Node is in a network protected by 223 firewall(s) 225 Let's consider a MN A, in a network protected by firewall(s). 227 +----------------+ +----+ 228 | | | HA | 229 | | +----+ 230 | | Home Agent 231 | +---+ +----+ of A +---+ 232 | | A | | FW | | B | 233 | +---+ +----+ +---+ 234 |Internal | External 235 | MN | Node 236 | | 237 +----------------+ 238 Network protected 240 Figure 1: Issues between MIP6 and firewalls when MN is in a network 241 protected by firewalls 243 A number of issues need to be considered: 245 Issue 1: When the MN A connects to the network, it should acquire a 246 local IP address (CoA), and send a Binding Update to its Home 247 Agent to update the HA with its current point of attachment. The 248 Binding Updates and Acknowledgements should be protected by IPsec 249 ESP according to the MIPv6 specifications [1]. However, as a 250 default rule, many firewalls drop ESP packets. This may cause the 251 Binding Updates and Acknowledgements between the Mobile Nodes and 252 their Home Agent to be dropped. 254 Issue 2: Let's now consider a node in the external network, B, trying 255 to establish a communication with MN A. 257 * B sends a packet to the Mobile Node's home address. 258 * The packet is intercepted by the MN's Home Agent which tunnels 259 it to the MN's CoA [1]. 260 * When arriving at the firewall(s) protecting MN A, the packet 261 may be dropped since the incoming packet may not match any 262 existing state. As described in Section 4, stateful inspection 263 packet filters e.g. typically drop unsolicited incoming 264 traffic. 265 * B will thus not be able to contact the MN A and establish a 266 communication. 268 Even though the HA is updated with the location of a MN, firewalls 269 may prevent Correspondent nodes from establishing communications 270 when the MN is in a network protected by firewall(s). 272 Issue 3: Let's assume a communication between MN A and an external 273 node B. MN A may want to use Route Optimization (RO) so that 274 packets can be directly exchanged between the MN and the CN 275 without passing through the HA. However the firewalls protecting 276 the MN might present issues with the Return Routability procedure 277 that needs to be performed prior to using RO. 279 According to the MIPv6 specifications, the Home Test message of 280 the RRT must be protected by IPsec in tunnel mode. However, 281 firewalls might drop any packet protected by ESP, since the 282 firewalls cannot analyze the packets encrypted by ESP (e.g. port 283 numbers). The firewalls may thus drop the Home Test messages and 284 prevent the completion of the RRT procedure. 286 Issue 4: Let's assume that MN A successfully sends a Binding Update 287 to its Home Agent (resp. Correspondent nodes) - issues 1 (resp. 288 issue 3) solved - the subsequent traffic is sent from the HA 289 (resp. CN) to the MN's CoA. However there may not be any 290 corresponding state in the firewalls. The firewalls protecting A 291 may thus drop the incoming packets. 293 The appropriate states for the traffic to the MN's CoA need to be 294 created in the firewall(s). 296 Issue 5: When the MN A moves, it may move to a link that is served by 297 a different firewall. MN A might be sending a BU to its CN, 298 however incoming packets may be dropped at the firewall, since the 299 firewall on the new link that the MN attaches to does not have any 300 state that is associated with the MN. 302 5.2 Scenario where the Correspondent Node is in a network protected by 303 firewall(s) 305 Let's consider a MN in a network, communicating with a Correspondent 306 Node A in a network protected by firewall(s). There is no issue with 307 Reverse Tunneling. However firewalls may present different issues to 308 Route Optimization. 310 +----------------+ +----+ 311 | | | HA | 312 | | +----+ 313 | | Home Agent 314 | +---+ +----+ of B 315 | |CN | | FW | 316 | +---+ +----+ 317 | | +---+ 318 | | | B | 319 | | +---+ 320 +----------------+ External Mobile 321 Network protected Node 322 by a firewall 324 Figure 2: Issues between MIP6 and firewalls when a CN is in a network 325 protected by firewalls 327 The following issues need to be considered: 329 Issue 1: The MN, MN B, should use its Home Address, HoA B, when 330 establishing the communication with the CN (CN A) if the MN (MN B) 331 wants to take advantage of the mobility support provided by the 332 Mobile IPv6 protocol, for its communication with CN A. The state 333 created by the firewall protecting CN A is therefore created based 334 on the IP address of A (IP A) and the home address of the node B 335 (IP HoA B). The states may be created via different means and the 336 protocol type as well as the port numbers depend on the connection 337 set up. 339 Uplink packet filters (1) 340 Source IP address: IP A 341 Destination IP address: HoA B 342 Protocol Type: TCP/UDP 343 Source Port Number: #1 344 Destination Port Number: #2 346 Downlink packet filters (2) 347 Source IP address: HoA B 348 Destination IP address: IP A 349 Protocol Type: TCP/UDP 350 Source Port Number: #2 351 Destination Port Number: #1 353 Nodes A and B might be topologically close to each other while B's 354 Home Agent may be far away, resulting in a trombone effect that 355 can create delay and degrade the performance. The MN B may decide 356 to initiate the route optimization procedure with Node A. Route 357 optimization requires the MN B to send a Binding Update to Node A 358 in order to create an entry in its binding cache that maps the MNs 359 home address to its current care-of-address. However, prior to 360 sending the binding update, the Mobile Node must first execute a 361 Return Routability Test: 363 * the Mobile Node B has to send a Home Test Init (HoTI) message 364 via its Home Agent and 365 * a Care of Test Init (COTI) message directly to its 366 Correspondent Node A. 368 The Care of Test Init message is sent using the CoA of B as the 369 source address. Such a packet does not match any entry in the 370 protecting firewall (2). The CoTi message will thus be dropped by 371 the firewall. 373 The HoTI is a Mobility Header packet, and the protocol type 374 differing from the existing states (2), the HoTI packet will also 375 be dropped. 377 As a consequence, the RRT cannot be completed and route 378 optimization cannot be applied. Every packet has to go through 379 the node B's Home Agent and tunneled between B's Home Agent and B. 381 +----------------+ 382 | +----+ HoTI (HoA) +----+ 383 | | FW |X<---------------|HA B| 384 | +----X +----+ 385 | +---+ | ^ CoTI & HoTI ^ 386 | | A | | | dropped by FW | 387 | +---+ | | | HoTI 388 | | | | 389 | | | CoTI (CoA)+---+ 390 | | +------------------| B | 391 +----------------+ +---+ 392 Network protected External Mobile 393 by a firewall Node 395 Figure 3: Issues with Return Routability Test 397 Issue 2: Let's assume that the Binding Update to the CN is 398 successful, the firewall(s) might still drop packets 400 1. coming from the CoA, since these incoming packets are sent 401 from the CoA and do not match the Downlink Packet filter (2) 402 2. sent from the CN to the CoA if uplink packet filters are 403 implemented. The uplink packets are sent to the MN's CoA and 404 do not match the uplink packet filter (1). 406 The packet filters for the traffic sent to (resp. from) the CoA 407 need to be created in the firewall(s). 409 Requiring the firewalls to update the connection state upon 410 detecting Binding Update messages from a node outside the network 411 protected by the firewall does not appear feasible nor desirable, 412 since currently the firewall does not have any means to verify the 413 validity of Binding Update messages and to therefore securely 414 modify the state information. Changing the firewall states 415 without verifying the validity of the Binding Update messages 416 could lead to denial of service attacks. Malicious nodes may send 417 faked Binding Update forcing the firewall to change its state 418 information, and therefore leading the firewall to drop packets 419 from the connections that use the legitimate addresses. An 420 adversary might also use an address update to enable its own 421 traffic to enter the network. 423 Issue 3: Let's assume that the Binding Update to the CN is 424 successful. The CN may be protected by different firewalls and as 425 a result of the MN's change of IP address, incoming and outgoing 426 traffic may pass through a different firewall. The new firewall 427 may not have any state associated with the CN and incoming 428 (potentially outgoing traffic) may be dropped at the firewall. 430 5.3 Scenario where the HA is in a network protected by firewall(s) 432 Let's consider a MN moving into a network protected by firewall(s). 433 The following issues may exist: 435 Issue 1: If the firewall(s) block ESP traffic, many of the MIPv6 436 signaling (e.g. Binding Update, HoT) may be dropped at the 437 firewall(s) preventing MN(s) from updating their binding cache and 438 performing Route Optimization, since Binding Update, HoT and other 439 MIPv6 signaling must be protected by IPsec ESP. 441 Issue 2: If the firewall(s) protecting the Home Agent block 442 unsolicited incoming traffic (e.g. as stateful inspection packet 443 filters do), the firewall(s) may drop connection set up requests 444 from CN, and packets from MN. 446 Issue 3: If the Home Agent is in a network protected by several 447 firewalls, a MN/CN's change of IP address may result in the 448 traffic to and from the Home Agent passing through a different 449 firewall that may not have the states corresponding to the flows. 450 As a consequence, packets may be dropped at the firewall. 452 5.4 Scenario where MN moves to a network protected by firewall(s) 454 Let's consider a HA in a network protected by firewall(s). The 455 following issues need to be investigated: 457 Issue 1: Similarly to the issue 1 described in Section 5.1, the MN 458 will send a Binding Update to its Home Agent after acquiring a 459 local IP address (CoA). The Binding Updates and Acknowledgements 460 should be protected by IPsec ESP according to the MIPv6 461 specifications [1]. However, as a default rule, many firewalls 462 drop ESP packets. This may cause the Binding Updates and 463 Acknowledgements between the Mobile Nodes and their Home Agent to 464 be dropped. 466 Issue 2: The MN may be in a communication with a CN, or a CN may be 467 attempting to establish a connection with the MN. In both cases, 468 packets sent from the CN will be forwarded by the MN's HA to the 469 MN's CoA. However when the packets arrive at the firewall(s), the 470 incoming traffic may not match any existing state, and the 471 firewall(s) may therefore drop it. 473 Issue 3: If the MN is in a communication with a CN, the MN may 474 attempt to execute a RRT for packets to be route optimized. 475 Similarly to the issue 3, Section 5.1, the Home Test message which 476 should be protected by ESP may be dropped by firewall(s) 477 protecting the MN. Firewall(s) may as a default rule drop any ESP 478 traffic. As a consequence, the RRT cannot be completed. 480 Issue 4: If the MN is in a communication with a CN, and assuming that 481 the MN successfully sent a Binding Update to its CN to use Route 482 Optimization, packets will then be sent from the CN to the MN's 483 CoA and from the MN's CoA to the CN. 484 Packets sent from the CN to the MN's CoA may however not match any 485 existing entry in the firewall(s) protecting the MN, and therefore 486 be dropped by the firewall(s). 488 If packet filtering is applied to uplink traffic (i.e. traffic 489 sent by the MN), packets sent from the MN's CoA to the the CN may 490 not match any entry in the firewall(s) either and may be dropped 491 as well. 493 6. Conclusions 495 Current firewalls may not only prevent route optimization but may 496 also prevent communications to be established in some cases. This 497 document describes some of the issues between the Mobile IP protocol 498 and current firewall technologies. 500 This document captures the various issues involved in the deployment 501 of Mobile IPv6 in networks that would invariably include firewalls. 502 A number of different scenarios are described which include 503 configurations where the mobile node, correspondent node and home 504 agent exist across various boundaries delimited by the firewalls. 505 This enables a better understanding of the issues when deploying 506 Mobile IPv6 as well as providing an understanding for firewall design 507 and policies to be installed therein. 509 7. Security Considerations 511 This document describes several issues that exist between the Mobile 512 IPv6 protocol and firewalls. 514 Firewalls may prevent Mobile IP6 traffic and drop incoming/outgoing 515 traffic. 517 If the firewall configuration is modified in order to support the 518 Mobile IPv6 protocol but not properly configured, many attacks may be 519 possible as outlined above: malicious nodes may be able to launch 520 different types of denial of service attacks. 522 8. Acknowledgments 524 We would like to thank James Kempf, Samita Chakrabarti and Giaretta 525 Gerardo for their valuable comments. Their suggestions have helped 526 to improve both the presentation and the content of the document. 528 9. References 530 9.1 Normative References 532 [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 533 IPv6", RFC 3775, June 2004. 535 9.2 Informative References 537 [2] Chen, X., Watson, M. and M. Harris, "Problem Statement for MIPv6 538 Interactions with GPRS/UMTS Packet Filtering", 539 Internet-Draft draft-chen-mip6-gprs-02, October 2004. 541 Authors' Addresses 543 Franck Le 544 Nokia Research Center 545 6000 Connection Drive 546 Irving, TX 75039 547 USA 549 Email: franck.le@nokia.com 551 Stefano Faccin 552 Nokia Research Center 553 6000 Connection Drive 554 Irving, TX 75039 555 USA 557 Email: stefano.faccin@nokia.com 559 Basavaraj Patil 560 Nokia Research Center 561 6000 Connection Drive 562 Irving, TX 75039 563 USA 565 Email: Basavaraj.Patil@nokia.com 566 Hannes Tschofenig 567 Siemens 568 Otto-Hahn-Ring 6 569 Munich, Bavaria 81739 570 Germany 572 Email: Hannes.Tschofenig@siemens.com 574 Appendix A. Applicability to 3G Networks 576 In 3G networks, different packet filtering functionalities may be 577 implemented to prevent malicious nodes from flooding or launching 578 other attacks against the 3G subscribers. The packet filtering 579 functionality of 3G networks are further described in [2]. Packet 580 filters are set up and applied to both uplink and downlink traffic: 581 outgoing and incoming data not matching the packet filters is dropped 582 . The issues described in this document also apply to 3G networks. 584 Intellectual Property Statement 586 The IETF takes no position regarding the validity or scope of any 587 Intellectual Property Rights or other rights that might be claimed to 588 pertain to the implementation or use of the technology described in 589 this document or the extent to which any license under such rights 590 might or might not be available; nor does it represent that it has 591 made any independent effort to identify any such rights. Information 592 on the procedures with respect to rights in RFC documents can be 593 found in BCP 78 and BCP 79. 595 Copies of IPR disclosures made to the IETF Secretariat and any 596 assurances of licenses to be made available, or the result of an 597 attempt made to obtain a general license or permission for the use of 598 such proprietary rights by implementers or users of this 599 specification can be obtained from the IETF on-line IPR repository at 600 http://www.ietf.org/ipr. 602 The IETF invites any interested party to bring to its attention any 603 copyrights, patents or patent applications, or other proprietary 604 rights that may cover technology that may be required to implement 605 this standard. Please address the information to the IETF at 606 ietf-ipr@ietf.org. 608 Disclaimer of Validity 610 This document and the information contained herein are provided on an 611 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 612 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 613 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 614 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 615 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 616 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 618 Copyright Statement 620 Copyright (C) The Internet Society (2005). This document is subject 621 to the rights, licenses and restrictions contained in BCP 78, and 622 except as set forth therein, the authors retain all their rights. 624 Acknowledgment 626 Funding for the RFC Editor function is currently provided by the 627 Internet Society.