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