idnits 2.17.1 draft-chen-mip6-gprs-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 3667, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 800. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 787), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 787. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == 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 Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1.1 Scope of this Document' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** 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.) ** There are 371 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 59 has weird spacing: '... source addre...' == Line 65 has weird spacing: '...ltering will ...' == Line 103 has weird spacing: '... mobile node ...' == Line 106 has weird spacing: '...portant and h...' == Line 112 has weird spacing: '...is used for d...' == (36 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 673 looks like a reference -- Missing reference section? '5' on line 686 looks like a reference -- Missing reference section? '12' on line 713 looks like a reference -- Missing reference section? '8' on line 700 looks like a reference -- Missing reference section? '9' on line 704 looks like a reference -- Missing reference section? '7' on line 696 looks like a reference -- Missing reference section? '13' on line 717 looks like a reference -- Missing reference section? '6' on line 691 looks like a reference -- Missing reference section? '14' on line 720 looks like a reference -- Missing reference section? '2' on line 676 looks like a reference -- Missing reference section? '3' on line 680 looks like a reference -- Missing reference section? '4' on line 683 looks like a reference -- Missing reference section? '10' on line 708 looks like a reference -- Missing reference section? '11' on line 710 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 8 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 WG X. Chen 3 Internet-Draft Orange PCS Ltd. 4 Expires: January, 2005 M. Watson 5 Nortel Networks 6 J. Wiljakka 7 Nokia 8 J. Rinne 9 Nokia 11 July, 2004 13 Problem Statement for MIPv6 Interactions with GPRS/UMTS 14 Packet Filtering 15 draft-chen-mip6-gprs-01.txt 17 Status of this Memo 19 By submitting this Internet-Draft, I certify that any applicable 20 patent or other IPR claims of which I am aware have been disclosed, 21 and any of which I become aware will be disclosed, in accordance with 22 RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). All Rights Reserved. 45 Abstract 47 This document provides an analysis of certain inter-working problems 48 between IPv6 nodes running Mobile IPv6, at least one of which is 49 connected to a Third Generation Partnership Project (3GPP) 50 specified General Packet Radio Service/Universal Mobile Tele- 51 communications System (GPRS/UMTS) network. The inter-working problems 52 are caused by some specific packet filtering operations at the edge 53 of the GPRS/UMTS network which are applied to control access to the 54 GPRS/UMTS services and network resources. However, we believe that 55 other scenarios may exist in which similar packet filtering 56 operations may be applied and that similar problems would arise in 57 these more general scenarios. 59 The GPRS Gateway Support Node (GGSN) checks the source address or 60 the destination address in the basic IPv6 header of incoming or 61 outgoing IP datagrams against a set of packet filtering information 62 established during the GPRS/UMTS session set-up. The packet filtering 63 information remains stable during the sessions and independent of 64 Mobile IP. When MIPv6 is activated by either end of the IPv6 mobile 65 nodes, the packet filtering will fail to perform properly and 66 subsequently block the traffic due to the mismatch between the packet 67 filters and the current source address or destination address in the 68 basic IPv6 header of the IP datagrams to and from the IPv6 mobile 69 nodes. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1 Scope of this Document . . . . . . . . . . . . . . . . . . . 4 75 1.2 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Packet Filtering in GPRS . . . . . . . . . . . . . . . . . . 4 78 3.1 Mobile Terminal Defined Packet Filtering for GPRS Services . 5 79 3.2 Mobile Terminal Defined Packet Filtering for IMS Services. . 5 80 3.3 Network Service Defined Packet Filtering for IMS Services. . 5 81 4. Problem statement . . . . . . . . . . . . . . . . . . . . . 6 82 4.1 GPRS node, B, acting as Correspondent Node . . . . . . . . . 6 83 4.1.1 Mobile Terminal defined Packet Filtering for GPRS Services . 6 84 4.1.2 Network Service defined Packet Filtering for IMS Services . 8 85 4.2 GPRS node, B, acting as Mobile Node . . . . . . . . . . . . 10 86 4.2.1 Mobile Terminal defined Packet Filtering for GPRS Services . 10 87 4.2.2 Network Service defined packet filtering for IMS Services . 11 88 4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 5. Problem generalisation . . . . . . . . . . . . . . . . . . . 13 90 6. Security Considerations . . . . . . . . . . . . . . . . . . 14 91 6.1 User security considerations . . . . . . . . . . . . . . . . 14 92 6.2 Network security considerations . . . . . . . . . . . . . . 14 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . .. . 14 94 References . . . . . . . . . . . . . . . . . . . . . . . . . 15 95 Authors' addresses . . . . . . . . . . . . . . . . . . . . . 16 96 Intellectual Property and Copyright Statements . . . . . . . 17 98 1. Introduction 100 Mobile IPv6 [1] allows a mobile node to maintain its IP connectivity 101 regardless of its network attachment point. Packets sent to the 102 mobile node may still use its home address, or the care-of address of 103 the mobile node as the destination address. The mobile node may 104 continue to communicate with its existing communication peers 105 (stationary or mobile) by using its topologically correct IP 106 addresses. An important and highly desirable feature of mobile IP 107 based mobility is that the control is transparent to transport and 108 higher-layer protocols and applications, i.e. the higher layer 109 protocols and applications function as if the mobile node is 110 "stationary". 112 Packet filtering in GPRS/UMTS[5][12] is used for differentiating 113 GPRS/UMTS connections and QoS, and protecting the network resources 114 and services against Theft of Service attacks. It is achieved by 115 checking the header information of the incoming and outgoing IP 116 datagrams against a set of packet filtering information. The packet 117 filtering information is defined or authorised by the application 118 layer entities during the set-up of the GPRS/UMTS and IP Multimedia 119 Subsystem sessions and operates independently of Mobile IP. This 120 pre-defined packet filtering information is then used by the GGSN to 121 check the header of incoming or outgoing IP datagrams so as to 122 select the appropriate GPRS/UMTS sessions with QoS or control the 123 access to network resources and IMS services based on the operator 124 defined local policies. For example, the Service-based Local Policy 125 control (SBLP) [8][9] in UMTS IP Multimedia Subsystems (IMS)[7][13] 126 enables the GGSN to check the destination address for outgoing IP 127 datagrams according to policy information authorised by the Policy 128 Decision Function during the IMS session establishment. 130 When Mobile IPv6 is activated, an IPv6 node sends IP datagrams using 131 Care-of Address as either the destination address or source address 132 while its home address is carried in the extension headers. The 133 change of source address or destination address in the basic IPv6 134 header from the mobile node's home address to its care-of address or 135 from one care-of address to another during a session leads to a 136 mismatch with the header information such as the source address or 137 destination address in the set of parameters for packet filtering 138 information and, as a result, the discard of incoming or outgoing IP 139 datagrams by the GGSN. 141 In the following sections, the basic packet filtering operations in 142 GPRS/UMTS are described and followed by the analysis of the failure 143 of those operations when Mobile IPv6 is activated. 145 1.1 Scope of this Document 147 This document provides information about the potential problems for 148 mobile terminals to use Mobile IPv6 when at least one of them 149 is connected to the GPRS/UMTS networks. It analyses the scenarios 150 when Mobile IPv6 is applied and how the problems occur. 152 Similar problems may also exist in CDMA2000 as defined by 3GPP2 153 and other Internet technologies such as firewalls. But the 154 discussions in this document are intended to apply to 3GPP compliant 155 GPRS/UMTS networks. 157 1.2 Abbreviations 159 3GPP Third Generation Partnership Project 160 3GPP2 Third Generation Partnership Project Two 161 GGSN Gateway GPRS Support Node (default router for 3GPP User 162 Equipment) 163 GPRS General Packet Radio Service 164 IMS IP Multimedia (Core Network) Subsystem, 3GPP Release 5 165 IPv6-only part of the network 166 NSIS Next Steps In Signalling 167 PDP Packet Data Protocol 168 RSVP Resource Reservation Protocol 169 SIP Session Initiation Protocol 170 SBLP Service Based Local Policy 171 TFT Traffic Flow Template 172 UE User Equipment, for example a UMTS mobile handset 173 UMTS Universal Mobile Telecommunications System 175 2. Terminology 177 GPRS services those services provided or accessed by the GPRS/UMTS 178 networks. They can be a single media service with one 179 traffic flow or a multimedia service with several 180 traffic flows. 182 IMS Services those services provided by the IP Multimedia (Core 183 Network) Subsystems (IMS). They are distinguished 184 from the general GPRS Services as defined above in 185 that the latter are not provided by the IMS. 187 3. Packet Filtering in GPRS 189 The following sections list some packet filtering operations in GPRS/ 190 UMTS. It is not intended to exhaust all the possible application 191 scenarios for packet filtering operations in 3G networks such as 192 those used by firewalls. 194 3.1 Mobile Terminal Defined Packet Filtering for GPRS Services 196 The GPRS Services are defined to be those services that are not run 197 on the IP Multimedia Subsystem (IMS) [7]. IMS is defined by 3GPP to 198 provide SIP-based IP multimedia services. To support GPRS services 199 with more than one traffic flow with differentiated QoS, GPRS/UMTS 200 networks support multiple simultaneous sessions as typically 201 represented by multiple secondary PDP (Packet Data Protocol) 202 Contexts [5]. Each GPRS/UMTS session may be assigned specific QoS 203 with the necessary network resources (including radio resources). An 204 incoming IP datagram from the external public data network such as 205 Internet will be checked by the GGSN, to decide if there is an 206 existing GPRS/UMTS session to deliver the datagram through the 207 network to the mobile terminal. The basic IPv6 header as well as 208 some higher layer information such as the ports is checked against a 209 Traffic Flow Template (TFT) [6] that contains the packet filtering 210 information such as the IPv4/IPv6 Source Addresses, Protocol 211 Identifier, Source/Destination Ports, etc. 213 The TFT is generated by the mobile node and recorded by the GGSN upon 214 a successful establishment of a GPRS/UMTS session for the mobile 215 node. The TFT only applies when secondary PDP contexts are activated 216 in which case only one PDP context among both the primary PDP context 217 and secondary PDP context(s) is allowed not to have a TFT associated 218 with it. 220 The GGSN will use at least one of those packet filter parameters 221 defined in the TFT, primarily the Source Address, to check if an 222 appropriate GPRS/UMTS session has been set up for incoming traffic. 223 The GGSN searches for a GPRS/UMTS session with the TFT that contains 224 the parameter values matching those carried in the datagram. For 225 example, the Source IP Address field of each existing TFT will be 226 compared with the source address carried in the basic IPv6 header of 227 an IPv6 datagram. If no matching TFT is found, the datagram may be 228 discarded. 230 3.2 Mobile Terminal Defined Packet Filtering for IMS Services 232 For UE's running IMS Services, the GGSN ignores any UE supplied TFT. 233 The filters in that TFT shall not installed the packet processing 234 table at the GGSN. The packet filtering for IMS services is based 235 on the Service-based Local Policy as discussed in the next section. 237 3.3 Network Service Defined Packet Filtering for IMS Services 239 In IMS, Service-based Local Policy (SBLP) [8][9] is enforced by the 240 GGSN to authorise and control the access to the IMS services and the 241 GPRS/UMTS network resources based on operator defined local policies. 242 The SBLP can be applied to both the traffic leaving the GPRS/UMTS 243 networks (uplink) and the traffic entering the GPRS/UMTS network 244 (downlink). 246 An IMS service request, a GPRS/UMTS session set-up request and the 247 subsequent data packets originated by the mobile terminal will be 248 checked by the GGSN against a set of policy control information 249 parameters such as Destination Address, Destination Port Number, 250 Transport Protocol ID, etc. The policy control information is issued 251 as an authorisation from the upper layer (the IMS/Policy Decision 252 Function -PDF). An IP datagram carrying a IMS service request or 253 user data will be blocked by the GGSN if mismatch is found between 254 the authorised policy information and those carried by the IP 255 datagram. For example, an IMS service request or a VoIP packet will 256 be blocked by the GGSN if the destination address carried by the IP 257 datagram does not match that authorised by the Policy Decision 258 Function. This is designed for protecting GPRS/UMTS and IMS against 259 ToS attacks. 261 4. Problem statement 263 The problem is stated in terms of an IPv6 node, A, communicating 264 with a second IPv6 node, B. B is connected to the GPRS/UMTS network. 265 We consider in turn the cases in which the GPRS node, B, is acting 266 either as a Correspondent Node or as a Mobile Node. 268 For each case, we consider sub-cases related to terminal defined 269 filters (i.e. TFTs) and network defined filters (i.e. SBLP). 271 Further, for each sub-case, we further consider the use of Home Agent 272 tunnelling and Route Optimisation by the Mobile Node. 274 4.1 GPRS node, B, acting as Correspondent Node 276 This is the case where A is a Mobile Node having live multimedia 277 sessions with a Correspondent Node, B. B is connected to a GPRS/UMTS 278 network. The sessions are set up when A is connected to its home 279 network link. 281 4.1.1 Mobile Terminal defined Packet Filtering for GPRS Services 283 Upon a successful establishment of multimedia sessions between A and 284 B, each session is associated with a TFT packet filter(s) defined by 285 B which have A's home address as the source address for IP datagrams 286 sent from A to B. The GGSN uses these packet filters to decide which 287 PDP Context to use to deliver an incoming IP datagram to B. 289 4.1.1.1 Home Agent Tunnelling 291 The IP datagrams sent from A to B use the (reverse) tunnel from A's 292 current CoA to its HA. IP datagrams exit the tunnel at A's home agent 293 and transmit to B using A's home address as the source address. Upon 294 arriving at the GGSN, the IP datagrams' source address matches the 295 IPv6 source address (A's home address) recorded in one of the TFT 296 filters and, if other filtering parameters are matched as well, the 297 IP datagrams will be delivered to B through the PDP Context 298 corresponding to the TFT. No specific issues are identified for this 299 case. 301 4.1.1.2 Route Optimisation 303 When A moves away from its home network link and connects to a 304 foreign network link and attempts the Mobile IPv6 binding update 305 procedures, it starts sending IP datagrams to B directly using its 306 CoA address as the Source Address and carrying its Home Address in 307 the Home Address Destination Type 2. 309 When such an IP datagram sent from A arrives at the GGSN, it does not 310 match the TFT packet filters containing A's home address as the IPv6 311 source address. As result, two possible decisions can be made by the 312 GGSN; If there happens to be a different PDP Context with a TFT which 313 does match A's CoA or a PDP Context without an associated TFT, the 314 GGSN will decide to use it to deliver the IP datagram to B. But in 315 this case it may not receive the correct Quality of Service 316 treatment. Additionally, the PDP Context with the Quality of Service 317 appropriate for delivering the IP datagram is left unused. 319 Figure 1 shows an example of two GPRS sessions that are distinguished 320 by GGSN using TFT packet filters, TFT1 and TFT2,respectively. 322 TFT +--------+ 323 Packet / \ CN 324 MN Filter / TFT1->Sess.1 \+--+ 325 +-+ +---------+ +--------+ +----+/----->----------|B | 326 |A|->-| Foreign |->-|Internet|->-|GGSN| ----->----------| | 327 | | | Network | +--------+ +----+\ TFT2->Sess.2 +--+ 328 +-+ +---------+ | \ / 329 | \ / 330 | +----------+ 331 | 332 /\ | 333 || | 334 || | 335 +---------+ | 336 | Home |-------------+ 337 | Network | 338 +---------+ 339 Figure 1. 341 Alternatively the GGSN will discard the IP datagram if all sessions 342 have TFT's and none of them match the incoming packet. 344 The first such IP datagram sent by A will carry the Care-of Test 345 Init message of the Return Routability Procedure. If this message is 346 dropped, then Route Optimisation will not complete, and IP datagrams 347 from A to B will continue to be routed via the Home Agent instead 348 (see Section 4.1.1.1). 350 If, instead, this message is delivered to B by the GGSN, the Return 351 Routability procedure may complete and subsequent datagrams will be 352 routed in the same way as the Care-of Test Init. The session with 353 optimised route from A to B will therefore continue. 355 The major problem is then that the IP datagrams will not receive the 356 correct Quality of Service treatment. Since UMTS Quality of Service 357 can involve small constant bit-rate bandwidth reservations, this can 358 cause a complete loss of service, if the incorrect QoS treatment 359 involves a path with too low a bandwidth or no bandwidth guarantee at 360 all. 362 In addition, extra complexity or even difficulties will be incurred 363 in the system with respect to PDP Contexts and network resources, 364 especially, the radio resources, that remain unused but are being 365 paid for by the user. 367 4.1.2 Network Service defined Packet Filtering for IMS Services 369 4.1.2.1 Home Agent tunneling 371 We have not identified any issues with this case, for the same reason 372 as discussed in Section 4.1.1.1. 374 4.1.2.2 Route Optimisation 376 When IMS multimedia sessions are set up between A and B, the SBLP 377 Policy Control authorises IP datagrams to be sent from B to A's home 378 address using assigned GPRS/UMTS network resources and the associated 379 QoS. When A moves away from its home network link and connects to 380 foreign network link, Mobile IPv6 Route Optimisation may be used to 381 allow B to continue sending IP datagrams to A by using A's CoA. 383 Upon arrival at the GGSN, they will not match the SBLP filter for 384 the session which is authorised only for destination equal to A's 385 home address. SBLP filters are associated with the particular UMTS 386 QoS reservation (PDP Context) for the session. If B continues to use 387 this QoS reservation for these packets, the GGSN will drop them as 388 they do not match the filter. 390 Figure 2 shows an example of SBLP packet filtering for IP datagrams 391 sent from B through IMS sessions, 1 and 2, to A. 393 +----------+ 394 | SBLP | 395 | Control | 396 | Function | 397 +----------+ 398 | +----------+ 399 | / \ CN 400 MN | / IMS Sess. 1 \ +--+ 401 +-+ +---------+ +--------+ +----+/-----<---------- |B | 402 |A|---| Foreign |---|Internet|---|GGSN| -----<---------- | | 403 | | | Network | +--------+ +----+\ IMS Sess. 2 /+--+ 404 +-+ +---------+ | \ / 405 | \ / 406 | +----------+ 407 | 408 /\ | 409 || | 410 || | 411 +--------+ | 412 | Home |--------+ 413 | Network| 414 +--------+ 416 Figure 2 418 In practice, as discussed in Section 4.1.1.2, the Return Routability 419 procedure requires that there is a route for the Care-of Test Init 420 message from A to B. A route from B to A for the Care-of Test itself 421 is also required. 423 The means by which outgoing MIP control packets are allocated to QoS 424 reservation on the PDP Context by the UE are undefined in 3GPP, but 425 we note that such a message would not pass the SBLP filters (as 426 described above). 428 If the message is routed (i.e. on a different QoS reservation), then 429 Route Optimisation can be established with the consequences as 430 described above. 432 Similar considerations to those of Section 4.1.1.2 apply to IP 433 datagrams sent from A to B. 435 4.2 GPRS node, B, acting as Mobile Node 437 This is the case where the GPRS node, B, is acting as MIPv6 Mobile 438 Node and has a live session such as VoIP with a Correspondent Node, 439 A. The MN, B, connects to the GPRS network after leaving either a 440 GPRS network or non-GPRS network. Therefore, the current GPRS network 441 is NOT taken to be B's home network but a foreign network. 443 4.2.1 Mobile Terminal defined Packet Filtering for GPRS Services 445 4.2.1.1 Home Agent Tunnelling 447 When B moves away from its home network link and connects to GPRS 448 network link, a PDP Context is set up and associated with a TFT 449 filter containing A's address as the Source Address for IP datagrams 450 sent from A to B. This will occur when the PDP Context(s) for B's 451 terminal is not MIP-aware and the IP stack is not QoS/GPRS-aware. 453 Figure 3 shows an example of two PDP Contexts representing two GPRS 454 sessions, 1 and 2,that are distinguished by GGSN using TFT filters, 455 TFT1 and TFT2, for incoming IP datagrams to be delivered to B. 457 TFT +--------+ 458 Packet / \ 459 Filter / \ MN 460 +------+ TFT1-Sess.1+---+ 461 *****| |---->-------| | 462 +-->--| GGSN | | B | 463 |*****| |---->-------| | 464 CN +-------+ | +------+ TFT2-Sess.2+---+ 465 +---+ | Local | +--------+ | \ GPRS / 466 | A |->-|Network|->-|Internet|== \ Network / 467 +---+ | A | +--------+ | +--------+ 468 +-------+ | 469 | +------+ 470 | | Home | /\ 471 |...********|+----+| || 472 +-------<---|| HA || || 473 ...********|+----+| 474 | Net- | 475 | work | 476 +------+ 478 Figure 3 480 The IP datagrams sent from A to B may use Home Agent Tunneling from 481 B's Home Agent to its current CoA. The IP datagrams tunnelled from 482 B's Home Agent to B's CoA have the Home Agent address as the source 483 address in the outer header, while the TFT filter associated with the 484 existing session has A's address as the Source Address. When the IP 485 datagrams arrive at the GGSN, the source address in the outer header 486 does not match the Source Address in the TFT template associated with 487 the session. As a result, the IP datagrams may be discarded by the 488 GGSN or provided with incorrect QoS treatment. 490 4.2.1.2 Route Optimisation 492 For the Return Routability Procedure to complete, there needs to be 493 a route from HA to B to deliver the Home Test messages. If no 494 matching TFT is found by the GGSN for the tunnelled Home Test 495 Messages and the GGSN chooses to drop the message, the Return 496 Routability procedure will fail and, as a result, the Route 497 Optimisation will not take place. 499 If tunnelled packets are routed at all from the Home Agent to B, then 500 the Return Routability procedure can complete successfully. 502 Packets from A are then sent directly to B's Care-of Address. These 503 will be correctly filtered by the TFTs and then delivered through the 504 corresponding PDP Context to B 506 4.2.2 Network Service defined packet filtering for IMS Services 508 4.2.2.1 Home Agent Tunnelling 510 When B moves away from its home network link and connects to a GPRS 511 network, it requests and acquires an IMS session with terminal A with 512 authorised SBLP information containing A's address as the Destination 513 Address for IP datagrams sent from B to A. 515 When Home Agent Tunnelling operation mode is used, B uses a 516 (reverse) tunnel from its CoA to its Home Agent to send IP datagrams 517 to A. In the reverse tunnel, the IP datagrams tunnelled from B carry 518 its Home Agent address as the destination. 520 Figure 4 shows an example of two IMS sessions, each of which is 521 associated with a SBLP filter, SBLP1 and SBLP2, for IP datagrams to 522 be sent to the authorised destination, i.e. A's address. 524 When the IP datagrams in an IP-in-IP tunnel arrive at the GGSN, GGSN 525 will find no authorised SBLP matching the destination indicated by 526 the outer header of the tunnelled IP datagrams, and it will block 527 and drop them. 529 TFT +-----------+ 530 Packet / \ 531 Filter / SBLP1 - Sess.1\ MN 532 +--------+*************** +---+ 533 *****| |----<-----------| | 534 |--<--| GGSN | SBLP2 - Sess.2 | B | 535 |*****| |----<-----------| | 536 CN +-------+ | +--------+****************+---+ 537 +---+ | Local | +--------+ | \ / 538 | A |-<-|Network|-<-|Internet|== \ GPRS Network / 539 +---+ | | +--------+ | +------------+ 540 +-------+ | 541 | +------+ 542 | | Home | /\ 543 | ********|+----+| || 544 +------->---|| HA || || 545 ********|+----+| 546 | Net- | 547 ---<---| work | 548 +------+ 550 Figure 4. 552 4.2.2.2 Route Optimisation 554 When Route Optimisation is used, IP datagrams from A to B (and B to 555 A) use B's Care-of Address as destination (resp. source) and 556 therefore will not match any of the established SBLP filters. This 557 is because the pre-established SBLP filters authorise IP datagrams 558 sent to B's Home Address to enter the GPRS/UMTS network. These will 559 be either blocked or carried with inappropriate QoS treatment. 561 The Figure 5 shows an example of filtering IP datagrams 562 sent from A directly to B using route optimisation passing an SBLP 563 filter SBLP1 or SBLP2. Both authorise the use of IMS sessions and 564 associated network resources to deliver IP datagrams to B's home 565 address. 567 Depending on the policy applied to packets which do not match the 568 SBLP filters, the Return Routability procedure may not complete. This 569 is because the SBLP filters, SBLP1 and SBLP2, authorise IP datagrams 570 sent to B's Home Address for accessing GPRS network resources and 571 IMS services. The 'Care of Test' message in response to the 'Care of 572 Test Init' message from B uses B's Care-of Address as the 573 destination address. 575 SBLP +----------+ 576 Packet / \ 577 Filter / SBLP1-Sess.1 \ MN 578 +--------+ +---+ 579 | |---->--------| | 580 +->-| GGSN | | B | 581 | | |---->--------| | 582 CN +-------+ | +--------+ SBLP2-Sess.2+---+ 583 +---+ | Local | +--------+ | \ / 584 | A |->-|Network|->-|Internet|== \GPRS Network / 585 +---+ | | +--------+ | +-----------+ 586 +-------+ | 587 | 588 | /\ 589 | +-------+ || 590 +-----------| Home | || 591 |Network| 592 +-------+ 594 Figure 5 596 4.3 Summary 598 GPRS Services will be disrupted when a mobile node that is 599 having more than one GPRS session with a GPRS mobile terminal 600 moves away from its home network and starts using Mobile IPv6 601 route optimisation. This will also happen when the GPRS mobile 602 terminal that is having more than one GPRS session with a 603 mobile node leaves its home network, enters GPRS/UMTS network 604 and starts using mobile IPv6 home agent tunnelling or route 605 optimisation. 607 IMS services will be disrupted when a mobile node that is having 608 an IMS session with a GPRS mobile terminal moves away from its home 609 network and starts using mobile IPv6 route optimisation. This will 610 also happen when the GPRS mobile terminal that is having a IMS 611 session with a mobile node leaves its home network, enters the GPRS/ 612 UMTS network and starts using mobile IPv6 home agent tunnelling or 613 route optimisation. 615 5. Problem generalisation 617 Although the description above is presented in terms of GPRS-specific 618 mechanisms for installing packet filters in the network. More general 619 situations may exist in which such filters are installed. This may 620 give rise to similar problems [14]. 622 In the analysis above, we classify the filters as mobile terminal 623 defined and network service defined. This represents the source of 624 the information within the filters. 626 An example of a 'terminal defined' filter in the network is a filter 627 installed as a result of RSVP (or in future NSIS protocols). Such 628 filters determine the QoS treatment that will be applied to packets 629 according to the user's request and are therefore very similar to 630 Traffic Flow Templates. 632 An example of a 'network service defined ' filter would be one 633 installed through policy mechanisms. In this case it is in order to 634 apply appropriate network policy that packets filtered. 636 6. Security Considerations 638 6.1 User security considerations 640 No user security issues have been identified. 642 6.2 Network security considerations 644 In the case of network service defined filters (e.g. Service Based 645 Local Policy), the purpose of the filters is to ensure that 646 appropriate network policy for controlling access to network 647 resources and services is applied to the packets. 649 The problems described in this paper do not themselves represent 650 security issues for the network (for example users circumventing the 651 network's policy). Indeed, the problems arise largely because the 652 policies cause packets to be dropped, or treated according to a 653 different policy which explicitly allows those packets to pass. 655 However, care must be taken in considering solutions to these 656 problems which cause modification of the network's policies. Such 657 modification will necessarily be caused by the mobility event at one 658 or other user. These events can easily be faked by users. 660 For example, IP address spoofing could be used to convince the 661 network that a user has moved when in fact they have not. 662 Collaborating users could convince the network that a user has moved, 663 when in fact the new address belongs to a different host. 665 7. Acknowledgements 667 The authors would like to thank Paul Reynolds, Ric Bailey, Ronan Le 668 Bras, Graham Fisher, Stuart Shutt, Steve Blythe and Rob Allan for 669 their constant and valuable support for the work. 671 References 673 [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 674 IPv6", RFC3775, June 2003. 676 [2] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating 677 Denial of Service Attacks which employ IP Source Address 678 Spoofing", BCP 38, RFC 2827, May 2000. 680 [3] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 681 June 1995. 683 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 684 Levels", BCP 14, RFC 2119, March 1997. 686 [5] 3GPP, "3rd Generation Partnership Project; Technical 687 Specification Group Services and System Aspects; General Packet 688 Radio Services (GPRS); Service Description; Stage 2", 3GPP TS 689 23.060. 691 [6] 3GPP, "3rd Generation Partnership Project; Technical 692 Specification Group Core Network; Mobile Radio Interface Layer 693 3 Specifications; Core Network Protocols - Stage 3", 3GPP TS 694 23.008. 696 [7] 3GPP, "3rd Generation Partnership Project; Technical 697 Specification Group Services and System Aspects; IP Multimedia 698 Subsystem (IMS); Stage 2", 3GPP TS 23.228. 700 [8] 3GPP, "3rd Generation Partnership Project; Technical 701 Specification Group Services and System Aspects; End-to-end 702 Quality of Service; Concept and Architecture", 3GPP TS 23.207. 704 [9] 3GPP, "3rd Generation Partnership Project; Technical 705 Specification Group Core Network; Policy Control over Go 706 Interface", 3GPP TS 29.207. 708 [10] Bradner, S.:IETF Rights in Contributions, RFC3667, February 2004 710 [11] Bradner, S.: Intellectual Property Rights in IETF Technology, 711 RFC 3668, February 2004. 713 [12] Wasserman, M, Ed. River, W.:Recommendations for IPv6 in Third 714 Generation Partnership Project (3GPP) Standards, RFC3314, 715 September, 2002 717 [13] Soininen, J Ed.:Transition Scenarios for 3GPP Networks, RFC3574, 718 August 2003. 720 [14] Le, F. et al.: draft-le-mip6-firewalls-00.txt, work in progress. 722 Authors' Addresses 724 Xiaobao Chen 725 Orange PCS Ltd. 726 Keypoint 727 St. James Court, Almondsbury Park 728 Bradley Stoke 729 Bristol BS32 4QJ 730 UK 732 Phone: +44 7989 477679 733 EMail: xiaobao.chen@orange.co.uk 735 Mark Watson 736 Nortel Networks 737 Maidenhead Office Park 738 Westacott Way 739 Maidenhead, BERKS SL6 3QH 740 UK 742 Phone: +44 1628 434456 743 EMail: mwatson@nortelnetworks.com 745 Juha Wiljakka 746 Nokia 747 Visiokatu 3 748 Tampere, FIN-33720 749 Finland 751 Phone: +358 7180 48372 752 EMail: juha.wiljakka@nokia.com 754 Janne Rinne 755 Nokia 756 Visiokatu 3 757 Tampere, FIN-33720 758 Finland 760 Phone: +358 7180 40995 761 EMail: janne.rinne@nokia.com 763 Intellectual Property Statement 765 The IETF takes no position regarding the validity or scope of any 766 intellectual property or other rights that might be claimed to 767 pertain to the implementation or use of the technology described in 768 this document or the extent to which any license under such rights 769 might or might not be available; neither does it represent that it 770 has made any effort to identify any such rights. Information on the 771 IETF's procedures with respect to rights in standards-track and 772 standards-related documentation can be found in BCP-11. Copies of 773 claims of rights made available for publication and any assurances of 774 licenses to be made available, or the result of an attempt made to 775 obtain a general license or permission for the use of such 776 proprietary rights by implementers or users of this specification can 777 be obtained from the IETF Secretariat. 779 The IETF invites any interested party to bring to its attention any 780 copyrights, patents or patent applications, or other proprietary 781 rights which may cover technology that may be required to practice 782 this standard. Please address the information to the IETF Executive 783 Director. 785 Full Copyright Statement 787 Copyright (C) The Internet Society (2004). All Rights Reserved. 789 This document is subject to the rights, licenses and restrictions 790 contained in BCP 78, and except as set forth therein, the authors 791 retain all their rights. 793 This document and the information contained herein are provided on 794 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 795 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 796 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 797 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 798 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 799 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 800 PARTICULAR PURPOSE. 802 Acknowledgement 804 Funding for the RFC Editor function is currently provided by the 805 Internet Society.