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