idnits 2.17.1 draft-chen-mip6-gprs-05.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 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 788. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 775), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 775. ** 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 == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 7) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages 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 364 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 14 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 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...' == (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.) -- 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 676 looks like a reference -- Missing reference section? '2' on line 679 looks like a reference -- Missing reference section? '5' on line 693 looks like a reference -- Missing reference section? '6' on line 697 looks like a reference -- Missing reference section? '4' on line 689 looks like a reference -- Missing reference section? '3' on line 684 looks like a reference -- Missing reference section? '9' on line 708 looks like a reference -- Missing reference section? '7' on line 701 looks like a reference -- Missing reference section? '8' on line 703 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 10 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft X. Chen 3 Expires: July 2006 Orange PCS Ltd 4 J. Rinne 5 Nokia 6 J. Wiljakka 7 Nokia 8 M. Watson 9 Nortel Networks 11 July, 2006 13 Problem Statement for MIPv6 Interactions with GPRS/UMTS 14 Packet Filtering 15 draft-chen-mip6-gprs-05.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 July, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 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 [2] is used for differentiating 113 GPRS/UMTS connections and Quality of Service (QoS), and protecting 114 the network resources and services against Theft of Service attacks. 115 It is achieved by checking the header information of the incoming and 116 outgoing IP datagrams against a set of packet filtering information. 117 The packet filtering information is defined or authorised by the 118 application layer entities during the set-up of the GPRS/UMTS and IP 119 Multimedia Subsystem sessions operating independently of Mobile IP. 120 This pre-defined packet filtering information is used by the GGSN 121 to 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) [5][6] in UMTS IP Multimedia Subsystems (IMS)[4] 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 3GPP Networks 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) [4]. 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[2] in association with one Primary PDP Context for each of 203 its IP address. Each GPRS/UMTS session may be assigned specific QoS 204 with the necessary network resources (including radio resources). An 205 incoming IP datagram from the external public data network such as 206 Internet will be checked by the GGSN, to decide if there is an 207 existing GPRS/UMTS session to deliver the datagram through the 208 network to the mobile terminal. The basic IPv6 header as well as 209 some higher layer information such as the ports is checked against a 210 Traffic Flow Template (TFT) [3] that contains the packet filtering 211 information such as the IPv4/IPv6 Source Addresses, Protocol 212 Identifier, Source/Destination Ports, etc. 214 The TFT is generated by the mobile node and recorded by the GGSN upon 215 a successful establishment of a GPRS/UMTS session for the mobile 216 node. The TFT only applies when secondary PDP contexts are activated 217 in which case only one PDP context among both the primary PDP context 218 and secondary PDP context(s) is allowed not to have a TFT associated 219 with it. 221 The GGSN will use at least one of those packet filter parameters 222 defined in the TFT, primarily the Source Address, to check if an 223 appropriate GPRS/UMTS session has been set up for incoming traffic. 224 The GGSN searches for a GPRS/UMTS session with the TFT that contains 225 the parameter values matching those carried in the datagram. For 226 example, the Source IP Address field of each existing TFT will be 227 compared with the source address carried in the basic IPv6 header of 228 an IPv6 datagram. If no matching TFT is found, the datagram may be 229 discarded. 231 3.2 Mobile Terminal Defined Packet Filtering for IMS Services 233 For a UE running IMS Services, the GGSN ignores any UE supplied TFT. 234 The filters in that TFT are not installed in the packet processing 235 table at the GGSN. The packet filtering for IMS services is based 236 on the Service Based Local Policy as discussed in the next section. 238 3.3 Network Service Defined Packet Filtering for IMS Services 240 In IMS, Service Based Local Policy (SBLP) [5][6] is enforced by the 241 GGSN to authorise and control the access to the IMS services and the 242 GPRS/UMTS network resources based on operator defined local policies. 243 The SBLP can be applied to both the traffic leaving the GPRS/UMTS 244 networks (uplink) and the traffic entering the GPRS/UMTS network 245 (downlink). 247 An IMS service request, a GPRS/UMTS session set-up request and the 248 subsequent data packets originated by the mobile terminal will be 249 checked by the GGSN against a set of policy control information 250 parameters such as Destination Address, Destination Port Number, 251 Transport Protocol ID, etc. The policy control information is issued 252 as an authorisation from the IMS application layer (the IMS/Policy 253 Decision Function -PDF). An IP datagram carrying an IMS service 254 request or user data will be blocked by the GGSN if mismatch is found 255 between the authorised policy information and those carried by the IP 256 datagram. For example, an IMS service request or a VoIP packet will 257 be blocked by the GGSN if the destination address carried by the IP 258 datagram does not match that authorised by the Policy Decision 259 Function. This is designed for protecting GPRS/UMTS and IMS against 260 ToS attacks. 262 4. Problem statement 264 The problem is stated in terms of an IPv6 node, A, communicating 265 with a second IPv6 node, B. B is connected to the GPRS/UMTS network. 266 The Internet or IP networks are between A's local network and B's 267 GPRS/UMTS network. 269 We consider in turn the cases in which the GPRS node, B, is acting 270 either as a Correspondent Node or as a Mobile Node. For each case, 271 we consider sub-cases related to terminal defined filters 272 (i.e. TFTs) and network defined filters (i.e. SBLP). 274 Further, for each sub-case, we further consider the use of Home Agent 275 tunnelling and Route Optimisation by the Mobile Node. 277 4.1 GPRS node, B, acting as Correspondent Node 279 This is the case where A is a Mobile Node that is having multimedia 280 sessions with a Correspondent Node, B. B is connected to a GPRS/UMTS 281 network. The sessions are set up when A is connected to its home 282 network link. 284 4.1.1 Mobile Terminal defined Packet Filtering for GPRS Services 286 Upon a successful establishment of multimedia sessions between A and 287 B, each session is associated with a TFT packet filter(s) defined by 288 B which have A's home address as the source address for IP datagrams 289 sent from A to B. The GGSN uses these packet filters to decide which 290 PDP Context to use to deliver an incoming IP datagram to B. 292 4.1.1.1 Home Agent Tunnelling 294 The IP datagrams sent from A to B use the (reverse) tunnel from A's 295 current CoA to its HA. IP datagrams exit the tunnel at A's home agent 296 and transmit to B using A's home address as the source address. Upon 297 arriving at the GGSN, the IP datagrams' source address matches the 298 IPv6 source address (A's home address) recorded in one of the TFT 299 filters and, if other filtering parameters are matched as well, the 300 IP datagrams will be delivered to B through the PDP Context 301 corresponding to the TFT. No specific issues are identified for this 302 case. 304 4.1.1.2 Route Optimisation 306 When A moves away from its home network link and connects to a 307 foreign network link and attempts the Mobile IPv6 binding update 308 procedures, it starts sending IP datagrams to B directly using its 309 CoA address as the Source Address and carrying its Home Address in 310 the Home Address destination option extension header. 312 When such an IP datagram sent from A arrives at the GGSN, it does not 313 match the TFT packet filters containing A's home address as the IPv6 314 source address. As result, two possible decisions can be made by the 315 GGSN; If there happens to be a different PDP Context with a TFT which 316 does match A's CoA or a PDP Context without an associated TFT, the 317 GGSN will decide to use it to deliver the IP datagram to B. But in 318 this case it may not receive the correct Quality of Service 319 treatment. Additionally, the PDP Context with the Quality of Service 320 appropriate for delivering the IP datagram is left unused. 322 Figure 1 shows an example of two GPRS sessions that are distinguished 323 by GGSN using TFT packet filters, TFT1 and TFT2,respectively. 325 TFT +--------+ 326 Packet / \ CN 327 MN Filter / TFT1->Sess.1 \+--+ 328 +-+ +---------+ +--------+ +----+/----->----------|B | 329 |A|->-| Foreign |->-|Internet|->-|GGSN| ----->----------| | 330 | | | Network | +--------+ +----+\ TFT2->Sess.2 +--+ 331 +-+ +---------+ | \ / 332 | \ / 333 | +----------+ 334 | 335 /\ | 336 || | 337 || | 338 +---------+ | 339 | Home |-------------+ 340 | Network | 341 +---------+ 343 Figure 1. Route Optimization with TFT-based Packet Filtering in GGSN 344 Alternatively the GGSN will discard the IP datagram if all sessions 345 have TFTs and none of them match the incoming packet. 347 The first IP datagram sent out by A will carry the Care-of Test 348 Init message of the Return Routability Procedure. If this message is 349 dropped, then Route Optimisation will not complete, and IP datagrams 350 from A to B will continue to be routed via the Home Agent instead 351 (see Section 4.1.1.1). 353 If, instead, this message is delivered to B by the GGSN, the Return 354 Routability procedure may complete and subsequent datagrams will be 355 routed in the same way as the Care-of Test Init. The session with 356 optimised route from A to B will therefore continue. 358 The major problem is then that the IP datagrams will not receive the 359 correct Quality of Service treatment. Since UMTS Quality of Service 360 can involve small constant bit-rate bandwidth reservations, this can 361 cause a complete loss of service, if the incorrect QoS treatment 362 involves a path with too low a bandwidth or no bandwidth guarantee at 363 all. 365 In addition, extra complexity or even difficulties will be incurred 366 in the system with respect to PDP Contexts and network resources, 367 especially, the radio resources, that remain unused but are being 368 paid for by the user. 370 4.1.2 Network Service defined Packet Filtering for IMS Services 372 4.1.2.1 Home Agent tunnelling 374 We have not identified any issues with this case, for the same reason 375 as discussed in Section 4.1.1.1. 377 4.1.2.2 Route Optimisation 379 When IMS multimedia sessions are set up between A and B, the SBLP 380 Policy Control authorises IP datagrams to be sent from B to A's home 381 address using assigned GPRS/UMTS network resources and the associated 382 QoS. When A moves away from its home network link and connects to 383 foreign network link, Mobile IPv6 Route Optimisation may be used to 384 allow B to continue sending IP datagrams to A by using A's CoA. 386 Upon arrival at the GGSN, they will not match the SBLP filter for 387 the session which is authorised only for destination equal to A's 388 home address. SBLP filters are associated with the particular UMTS 389 QoS reservation (PDP Context) for the session. If B continues to use 390 this QoS reservation for these packets, the GGSN will drop them as 391 they do not match the filter. 393 Figure 2 shows an example of SBLP packet filtering for IP datagrams 394 sent from B through IMS sessions, 1 and 2, to A. 396 +----------+ 397 | SBLP | 398 | Control | 399 | Function | 400 +----------+ 401 | +----------+ 402 | / \ CN 403 MN | / IMS Sess. 1 \ +--+ 404 +-+ +---------+ +--------+ +----+/-----<---------- |B | 405 |A|---| Foreign |---|Internet|---|GGSN| -----<---------- | | 406 | | | Network | +--------+ +----+\ IMS Sess. 2 /+--+ 407 +-+ +---------+ | \ / 408 | \ / 409 | +----------+ 410 | 411 /\ | 412 || | 413 || | 414 +--------+ | 415 | Home |--------+ 416 | Network| 417 +--------+ 419 Figure 2. Route Optimization with SBLP-based Packet Filtering in GGSN 421 In practice, as discussed in Section 4.1.1.2, the Return Routability 422 procedure requires that there is a route for the Care-of Test Init 423 message from A to B. A route from B to A for the Care-of Test itself 424 is also required. 426 The means by which outgoing MIP control packets are allocated to QoS 427 reservation on the PDP Context by the UE are undefined in 3GPP, but 428 we note that such a message would not pass the SBLP filters (as 429 described above). 431 If the message is routed (i.e. on a different QoS reservation), then 432 Route Optimisation can be established with the consequences as 433 described above. 435 Similar considerations to those of Section 4.1.1.2 apply to IP 436 datagrams sent from A to B. 438 4.2 GPRS node, B, acting as Mobile Node 440 This is the case where the GPRS node, B, is acting as MIPv6 Mobile 441 Node and has a live session such as VoIP with a Correspondent Node, 442 A. The MN, B, connects to the GPRS network after leaving either a 443 GPRS network or non-GPRS network. Therefore, the current GPRS network 444 is NOT taken to be B's home network but a foreign network. 446 4.2.1 Mobile Terminal defined Packet Filtering for GPRS Services 448 4.2.1.1 Home Agent Tunnelling 450 When B moves away from its home network link and connects to GPRS 451 network link, a PDP Context is set up and associated with a TFT 452 filter containing A's address as the Source Address for IP datagrams 453 sent from A to B. 455 Figure 3 shows an example of two PDP Contexts representing two GPRS 456 sessions, 1 and 2, that are distinguished by GGSN using TFT filters, 457 TFT1 and TFT2, for incoming IP datagrams to be delivered to B. 459 TFT +--------+ 460 Packet / \ 461 Filter / \ MN 462 +------+ TFT1-Sess.1+---+ 463 *****| |---->-------| | 464 +-->--| GGSN | | B | 465 |*****| |---->-------| | 466 CN +-------+ | +------+ TFT2-Sess.2+---+ 467 +---+ | Local | +--------+ | \ GPRS / 468 | A |->-|Network|->-|Internet|== \ Network / 469 +---+ | A | +--------+ | +--------+ 470 +-------+ | 471 | +------+ 472 | | Home | /\ 473 |...********|+----+| || 474 +-------<---|| HA || || 475 ...********|+----+| 476 | Net- | 477 | work | 478 +------+ 480 Figure 3. HA Tunnelling with TFT-based Packet Filtering in GGSN 481 The IP datagrams sent from A to B may use Home Agent Tunnelling from 482 B's Home Agent to its current CoA. The IP datagrams tunnelled from 483 B's Home Agent to B's CoA have the Home Agent address as the source 484 address in the outer header, while the TFT filter associated with the 485 existing session has A's address as the Source Address. When the IP 486 datagrams arrive at the GGSN, the source address in the outer header 487 does not match the Source Address in the TFT template associated with 488 the session. As a result, the IP datagrams may be discarded by the 489 GGSN or provided with incorrect QoS treatment. 491 4.2.1.2 Route Optimisation 493 For the Return Routability Procedure to complete, there needs to be 494 a route from HA to B to deliver the Home Test messages. If no 495 matching TFT is found by the GGSN for the tunnelled Home Test 496 Messages and the GGSN chooses to drop the message, the Return 497 Routability procedure will fail and, as a result, the Route 498 Optimisation will not take place. 500 If tunnelled packets are routed at all from the Home Agent to B, then 501 the Return Routability procedure can complete successfully. 503 Packets from A are then sent directly to B's Care-of Address. These 504 will be correctly filtered by the TFTs and then delivered through the 505 corresponding PDP Context to B. 507 4.2.2 Network Service defined packet filtering for IMS Services 509 4.2.2.1 Home Agent Tunnelling 511 When B moves away from its home network link and connects to a GPRS 512 network, it requests and acquires an IMS session with terminal A with 513 authorised SBLP information containing A's address as the Destination 514 Address for IP datagrams sent from B to A. 516 When Home Agent Tunnelling operation mode is used, B uses a 517 (reverse) tunnel from its CoA to its Home Agent to send IP datagrams 518 to A. In the reverse tunnel, the IP datagrams tunnelled from B carry 519 its Home Agent address as the destination. 521 Figure 4 shows an example of two IMS sessions, each of which is 522 associated with a SBLP filter, SBLP1 and SBLP2, for IP datagrams to 523 be sent to the authorised destination, i.e. A's address. 525 When the IP datagrams in an IP-in-IP tunnel arrive at the GGSN, GGSN 526 will find no authorised SBLP matching the destination indicated by 527 the outer header of the tunnelled IP datagrams, and it will block 528 and drop them. 530 TFT +-----------+ 531 Packet / \ 532 Filter / SBLP1 - Sess.1\ MN 533 +--------+*************** +---+ 534 *****| |----<-----------| | 535 |--<--| GGSN | SBLP2 - Sess.2 | B | 536 |*****| |----<-----------| | 537 CN +-------+ | +--------+****************+---+ 538 +---+ | Local | +--------+ | \ / 539 | A |-<-|Network|-<-|Internet|== \ GPRS Network / 540 +---+ | | +--------+ | +------------+ 541 +-------+ | 542 | +------+ 543 | | Home | /\ 544 | ********|+----+| || 545 +------->---|| HA || || 546 ********|+----+| 547 | Net- | 548 ---<---| work | 549 +------+ 551 Figure 4. HA Tunnelling with SBLP-based Packet Filtering in GGSN 553 4.2.2.2 Route Optimisation 555 When Route Optimisation is used, IP datagrams from A to B (and B to 556 A) use B's Care-of Address as destination (resp. source) and 557 therefore will not match any of the established SBLP filters. This 558 is because the pre-established SBLP filters authorise IP datagrams 559 sent to B's Home Address to enter the GPRS/UMTS network. These will 560 be either blocked or carried with inappropriate QoS treatment. 562 The Figure 5 shows an example of filtering IP datagrams 563 sent from A directly to B using route optimisation passing an SBLP 564 filter SBLP1 or SBLP2. Both authorise the use of IMS sessions and 565 associated network resources to deliver IP datagrams to B's home 566 address. 568 Depending on the policy applied to packets which do not match the 569 SBLP filters, the Return Routability procedure may not complete. This 570 is because the SBLP filters, SBLP1 and SBLP2, authorise IP datagrams 571 sent to B's Home Address for accessing GPRS network resources and 572 IMS services. The 'Care of Test' message in response to the 'Care of 573 Test Init' message from B uses B's Care-of Address as the 574 destination address. 576 SBLP +----------+ 577 Packet / \ 578 Filter / SBLP1-Sess.1 \ MN 579 +--------+ +---+ 580 | |---->--------| | 581 +->-| GGSN | | B | 582 | | |---->--------| | 583 CN +-------+ | +--------+ SBLP2-Sess.2+---+ 584 +---+ | Local | +--------+ | \ / 585 | A |->-|Network|->-|Internet|== \GPRS Network / 586 +---+ | | +--------+ | +-----------+ 587 +-------+ | 588 | 589 | /\ 590 | +-------+ || 591 +-----------| Home | || 592 |Network| 593 +-------+ 595 Figure 5. Route Optimization with SBLP-based Packet Filtering in GGSN 597 4.3 Summary 599 GPRS Services will be disrupted when a GPRS mobile terminal 600 have multiple secondary PDP Contexts to communicate with a 601 mobile node which changes its network attachment point and starts 602 using Mobile IPv6 route optimisation. This will also happen 603 when the GPRS mobile terminal that is having more than one GPRS 604 session with a mobile node leaves its home network, enters GPRS 605 network and starts using mobile IPv6 home agent tunnelling or 606 route optimisation. 608 IMS services will be disrupted when a mobile node that is having 609 an IMS session with a GPRS mobile terminal changes its network 610 attachment point and starts using mobile IPv6 route optimisation. 611 This will also happen when the GPRS mobile terminal that is having 612 an IMS session with a mobile node leaves its home network, enters 613 the GPRS/UMTS network and starts using mobile IPv6 home agent 614 tunnelling or route optimisation. 616 5. Problem generalisation 618 Although the description above is presented in terms of GPRS-specific 619 mechanisms for installing packet filters in the network. More general 620 situations may exist in which such filters are installed. This may 621 give rise to similar problems [9]. 623 In the analysis above, we classify the filters as mobile terminal 624 defined and network service defined. This represents the source of 625 the information within the filters. 627 An example of a 'terminal defined' filter in the network is a filter 628 installed as a result of RSVP (or in future NSIS protocols). Such 629 filters determine the QoS treatment that will be applied to packets 630 according to the user's request and are therefore very similar to 631 Traffic Flow Templates. 633 An example of a 'network service defined ' filter would be one 634 installed through policy mechanisms. In this case it is in order to 635 apply appropriate network policy that packets filtered. 637 6. Security Considerations 639 6.1 User security considerations 641 No user security issues have been identified. 643 6.2 Network security considerations 645 In the case of network service defined filters (e.g. Service Based 646 Local Policy), the purpose of the filters is to ensure that 647 appropriate network policy for controlling access to network 648 resources and services is applied to the packets. 650 The problems described in this paper do not themselves represent 651 security issues for the network (for example users circumventing the 652 network's policy). Indeed, the problems arise largely because the 653 policies cause packets to be dropped, or treated according to a 654 different policy which explicitly allows those packets to pass. 656 However, care must be taken in considering solutions to these 657 problems which cause modification of the network's policies. Such 658 modification will necessarily be caused by the mobility event at one 659 or other user. These events can easily be faked by users. 661 For example, IP address spoofing could be used to convince the 662 network that a user has moved when in fact they have not. 663 Collaborating users could convince the network that a user has moved, 664 when in fact the new address belongs to a different host. 666 7. Acknowledgements 668 The authors would like to thank Paul Reynolds, Ric Bailey, Ronan Le 669 Bras, Graham Fisher, Stuart Shutt, Steve Blythe and Rob Allan for 670 their constant and valuable support for the work. 672 References 674 Normative: 676 [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 677 IPv6", RFC3775, June 2003. 679 [2] 3GPP, "3rd Generation Partnership Project; Technical 680 Specification Group Services and System Aspects; General Packet 681 Radio Services (GPRS); Service Description; Stage 2", 3GPP TS 682 23.060. 684 [3] 3GPP, "3rd Generation Partnership Project; Technical 685 Specification Group Core Network; Mobile Radio Interface Layer 686 3 Specifications; Core Network Protocols - Stage 3", 3GPP TS 687 23.008. 689 [4] 3GPP, "3rd Generation Partnership Project; Technical 690 Specification Group Services and System Aspects; IP Multimedia 691 Subsystem (IMS); Stage 2", 3GPP TS 23.228. 693 [5] 3GPP, "3rd Generation Partnership Project; Technical 694 Specification Group Services and System Aspects; End-to-end 695 Quality of Service; Concept and Architecture", 3GPP TS 23.207. 697 [6] 3GPP, "3rd Generation Partnership Project; Technical 698 Specification Group Core Network; Policy Control over Go 699 Interface", 3GPP TS 29.207. 701 [7] Bradner, S.:IETF Rights in Contributions, RFC3667, February 2004 703 [8] Bradner, S.: Intellectual Property Rights in IETF Technology, 704 RFC 3668, February 2004. 706 Informational: 708 [9] Le, F. et al.: draft-le-mip6-firewalls-01.txt, work in progress. 710 Authors' Addresses 712 Xiaobao Chen 713 Orange PCS Ltd. 714 Keypoint 715 St. James Court, Almondsbury Park 716 Bradley Stoke 717 Bristol BS32 4QJ 718 UK 720 Phone: +44 7989 477679 721 Email: xiaobao.chen@orange.co.uk 723 Janne Rinne 724 Nokia 725 Visiokatu 3 726 Tampere, FIN-33720 727 Finland 729 Phone: +358 7180 40995 730 Email: janne.rinne@nokia.com 732 Juha Wiljakka 733 Nokia 734 Visiokatu 3 735 Tampere, FIN-33720 736 Finland 738 Phone: +358 7180 48372 739 Email: juha.wiljakka@nokia.com 741 Mark Watson 742 Nortel Networks 743 Maidenhead Office Park 744 Westacott Way 745 Maidenhead, BERKS SL6 3QH 746 UK 748 Phone: +44 1628 434456 749 Email: mwatson@nortelnetworks.com 751 Intellectual Property Statement 753 The IETF takes no position regarding the validity or scope of any 754 intellectual property or other rights that might be claimed to 755 pertain to the implementation or use of the technology described in 756 this document or the extent to which any license under such rights 757 might or might not be available; neither does it represent that it 758 has made any effort to identify any such rights. Information on the 759 IETF's procedures with respect to rights in standards-track and 760 standards-related documentation can be found in BCP-11. Copies of 761 claims of rights made available for publication and any assurances of 762 licenses to be made available, or the result of an attempt made to 763 obtain a general license or permission for the use of such 764 proprietary rights by implementers or users of this specification can 765 be obtained from the IETF Secretariat. 767 The IETF invites any interested party to bring to its attention any 768 copyrights, patents or patent applications, or other proprietary 769 rights which may cover technology that may be required to practice 770 this standard. Please address the information to the IETF Executive 771 Director. 773 Full Copyright Statement 775 Copyright (C) The Internet Society (2005). All Rights Reserved. 777 This document is subject to the rights, licenses and restrictions 778 contained in BCP 78, and except as set forth therein, the authors 779 retain all their rights. 781 This document and the information contained herein are provided on 782 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 783 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 784 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 785 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 786 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 787 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 788 PARTICULAR PURPOSE. 790 Acknowledgement 792 Funding for the RFC Editor function is currently provided by the 793 Internet Society.