idnits 2.17.1 draft-chen-mip6-gprs-00.txt: -(226): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(227): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(244): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(280): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(312): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(458): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(528): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(540): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(543): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 27 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 10) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 51 has weird spacing: '... source addre...' == Line 57 has weird spacing: '...ltering will ...' == Line 90 has weird spacing: '... mobile node ...' == Line 93 has weird spacing: '...portant and h...' == Line 99 has weird spacing: '...is used for d...' == (31 more instances...) == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 5, 2004) is 7357 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) == Unused Reference: '2' is defined on line 594, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 598, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 5 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MIP6 WG X. Chen 2 Internet-Draft Orange PCS Ltd. 3 Expires: August 5, 2004 M. Watson 4 Nortel Networks 5 M. Harris 6 Orange PCS Ltd. 7 February 5, 2004 9 Problem Statement for MIPv6 Interactions with GPRS/UMTS 10 Packet Filtering 11 draft-chen-mip6-gprs-00.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 5, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 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 GPRS/UMTS network. The inter-working problems are 44 caused by some specific packet filtering operations at the edge of 45 the GPRS/UMTS network which are applied to control access to the 46 GPRS/UMTS services and network resources. However, we believe that 47 other scenarios may exist in which similar packet filtering 48 operations may be applied and that similar problems would arise in 49 these, more general, scenarios. 51 The GGSN checks the source address or the destination address in the 52 basic IPv6 header of incoming or outgoing IP datagrams against a set 53 of packet filtering information established during the GPRS/UMTS 54 session set-up. The packet filtering information remains stable 55 during the sessions and independent of Mobile IP. When MIPv6 is 56 activated by either end of the IPv6 mobile nodes, the packet 57 filtering will fail to perform properly and subsequently block the 58 traffic due to the mismatch between the packet filters and the 59 current source address or destination address in the basic IPv6 60 header of the IP datagrams to and from the IPv6 mobile nodes. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Packet Filtering in GPRS . . . . . . . . . . . . . . . . . . 4 67 3.1 Mobile Terminal Defined Packet Filtering . . . . . . . . . . 4 68 3.2 Network Service Defined Packet Filtering . . . . . . . . . . 4 69 4. Problem statement . . . . . . . . . . . . . . . . . . . . . 5 70 4.1 GPRS node, B, acting as Correspondent Node . . . . . . . . . 5 71 4.1.1 Mobile Terminal defined Packet Filtering (TFTs) . . . . . . 5 72 4.1.2 Network Service defined Packet Filtering (SBLP) . . . . . . 7 73 4.2 GPRS node, B, acting as Mobile Node . . . . . . . . . . . . 9 74 4.2.1 Mobile Terminal defined Packet Filtering (TFTs) . . . . . . 9 75 4.2.2 Network Service defined packet filtering (SBLP) . . . . . . 10 76 5. Problem generalization . . . . . . . . . . . . . . . . . . . 12 77 6. Security Considerations . . . . . . . . . . . . . . . . . . 13 78 6.1 User security considerations . . . . . . . . . . . . . . . . 13 79 6.2 Network security considerations . . . . . . . . . . . . . . 13 80 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13 81 References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 83 Intellectual Property and Copyright Statements . . . . . . . 16 85 1. Introduction 87 Mobile IPv6 [1] allows a mobile node to maintain its IP connectivity 88 regardless of its network attachment point. Packets sent to the 89 mobile node may still use its home address, or the care-of address of 90 the mobile node as the destination address. The mobile node may 91 continue to communicate with its existing communication peers 92 (stationary or mobile) by using its topologically correct IP 93 addresses. An important and highly desirable feature of mobile IP 94 based mobility is that the control is transparent to transport and 95 higher-layer protocols and applications, i.e. the higher layer 96 protocols and applications function as if the mobile node is 97 "stationary". 99 Packet filtering in GPRS/UMTS is used for differentiating GPRS/UMTS 100 connections and QoS, and protecting the network resources and 101 services against Theft of Service attacks. It is achieved by 102 checking the header information of the incoming and outgoing IP 103 datagrams against a set of packet filtering information. The packet 104 filtering information is defined or authorised by the application 105 layer entities during the set-up of the GPRS/UMTS and IP Multimedia 106 Subsystem sessions and operates independently of Mobile IP. This 107 pre-defined packet filtering information is then used by the GGSN to 108 check the header of incoming or outgoing IP datagrams so as to 109 select the appropriate GPRS/UMTS sessions with QoS or control the 110 access to network resources and IMS services based on the operator 111 defined local policies. For example, the Service-based Local Policy 112 control (SBLP) in UMTS IP Multimedia Subsystems (IMS) enables the 113 GGSN to check the destination address for outgoing IP datagrams 114 according to policy information authorised by the Policy Decision 115 Function during the IMS session establishment. 117 When Mobile IPv6 is activated, an IPv6 node sends IP datagrams using 118 Care-of Address as either the destination address or source address 119 while its home address is carried in the extension headers. The 120 change of source address or destination address in the basic IPv6 121 header from the mobile node's home address to its care-of address or 122 from one care-of address to another during a session leads to a 123 mismatch with the header information such as the source address or 124 destination address in the set of parameters for packet filtering 125 information and, as a result, the discard of incoming or outgoing IP 126 datagrams by the GGSN. 128 In the following sections, the basic packet filtering operations in 129 GPRS/UMTS are described and followed by the analysis of the failure 130 of those operations when Mobile IPv6 is activated. 132 2. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED","SHALL","SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [4]. 138 3. Packet Filtering in GPRS 140 The following sections list some packet filtering operations in GPRS/ 141 UMTS. It is not intended to exhaust all the possible application 142 scenarios for packet filtering operations in 3G networks such as 143 those used by Firewalls. 145 3.1 Mobile Terminal Defined Packet Filtering 147 To support multimedia services with differentiated QoS, GPRS/UMTS 148 networks support multiple simultaneous sessions as typically 149 represented by multiple secondary PDP (Packet Data Protocol) 150 Contexts [5]. Each GPRS/UMTS session may be assigned specific QoS 151 with the necessary network resources (including radio resources). An 152 incoming IP datagram from the external public data network such as 153 Internet will be checked by the GGSN, to decide if there is an 154 existing GPRS/UMTS session to deliver the datagram through the 155 network to the mobile terminal. The basic IPv6 header as well as 156 some higher layer information such as the ports is checked against a 157 Traffic Flow Template (TFT) [6] that contains the packet filtering 158 information such as the IPv4/IPv6 Source Addresses, Protocol 159 Identifier, Source/Destination Ports, etc. 161 The TFT is generated by the mobile node and recorded by the GGSN upon 162 a successful establishment of a GPRS/UMTS session for the mobile 163 node. The GGSN will use at least one of those packet filter 164 parameters, primarily the Source Address, to check if an appropriate 165 GPRS/UMTS session has been set up for incoming traffic. The GGSN 166 searches for a GPRS/UMTS session with the TFT that contains the 167 parameter values matching those carried in the datagram. For example, 168 the Source IP Address field of each existing TFT will be compared 169 with the source address carried in the basic IPv6 header of an IPv6 170 datagram. If no matching TFT is found, the datagram may be discarded. 172 3.2 Network Service Defined Packet Filtering 174 The IP Multimedia Subsystem (IMS) [7] is defined by 3GPP to provide 175 SIP-based IP multimedia services. In IMS, Service-based Local Policy 176 control(SBLP) [8][9] is enforced by the GGSN to authorise and 177 control the access to the IMS services and the GPRS/UMTS network 178 resources based on operator defined local policies. 180 An IMS service request, a GPRS/UMTS session set-up request and the 181 subsequent data packets originated by the mobile terminal will be 182 checked by the GGSN against a set of policy control information 183 parameters such as Destination Address, Destination Port Number, 184 Transport Protocol ID, etc. The policy control information is issued 185 as an authorisation from the upper layer (the IMS/Policy Decision 186 Function -PDF). An IP datagram carrying a IMS service request or 187 user data will be blocked by the GGSN if mismatch is found between 188 the authorised policy information and those carried by the IP 189 datagram. For example, an IMS service request or a VoIP packet will 190 be blocked by the GGSN if the destination address carried by the IP 191 datagram does not match that authorised by the Policy Decision 192 Function. This is designed for protecting GPRS/UMTS and IMS against 193 ToS attacks. 195 4. Problem statement 197 The problem is stated in terms of an IPv6 node, A, communicating 198 with a second IPv6 node, B. B is connected to the GPRS/UMTS network. 199 We consider in turn the cases in which the GPRS node, B, is acting 200 either as a Correspondent Node or as a Mobile Node. 202 For each case, we consider sub-cases related to terminal defined 203 filters (i.e. TFTs) and network defined filters (i.e. SBLP). 205 Further, for each sub-case, we further consider the use of Home Agent 206 tunnelling and Route Optimisation by the Mobile Node. 208 4.1 GPRS node, B, acting as Correspondent Node 210 This is the case where A is a Mobile Node having live multimedia 211 sessions with a Correspondent Node, B. B is connected to a GPRS/UMTS 212 network. The sessions are set up when A is connected to its home 213 network link. 215 4.1.1 Mobile Terminal defined Packet Filtering (TFTs) 217 Upon an successful establishment of multimedia sessions between A and 218 B, each session is associated with a TFT packet filter(s) defined by 219 B which have A's home address as the source address for IP datagrams 220 sent from A to B. The GGSN uses these packet filters to decide which 221 PDP Context to use to deliver an incoming IP datagram to B. 223 4.1.1.1 Home Agent Tunnelling 225 The IP datagrams sent from A to B use the (reverse) tunnel from A�s 226 current CoA to its HA. IP datagrams exit the tunnel at A�s home agent 227 and transmit to B using A�s home address as the source address. Upon 228 arriving at the GGSN, the IP datagrams� source address matches the 229 IPv6 source address (A�s home address) recorded in one of the TFT 230 filters and, if other filtering parameters are matched as well, the 231 IP datagrams will be delivered to B through the PDP Context 232 corresponding to the TFT. No specific issues are identified for this 233 case. 235 4.1.1.2 Route Optimisation 237 When A moves away from its home network link and connects to a 238 foreign network link and attempts the Mobile IPv6 binding update 239 procedures, it starts sending IP datagrams to B directly using its 240 CoA address as the Source Address and carrying its Home Address in 241 the Home Address Destination Type 2. 243 When such an IP datagram sent from A arrives at the GGSN, it does not 244 match the TFT packet filters containing A�s home address as the IPv6 245 source address. As result, two possible decisions can be made by the 246 GGSN; If there happens to be a different PDP Context with a TFT which 247 does match A�s CoA or a PDP Context without an associated TFT, the 248 GGSN will decide to use it to deliver the IP datagram to B. But in 249 this case it may not receive the correct Quality of Service 250 treatment.Additionally, the PDP Context with the Quality of Service 251 appropriate for delivering the IP datagram is left unused. 253 The following diagram shows an example of two GPRS sessions that are 254 distinguished by GGSN using TFT packet filters, TFT1 and TFT2, 255 respectively. 257 TFT +--------+ 258 Packet / \ CN 259 MN Filter / TFT1->Sess.1 \+--+ 260 +-+ +---------+ +--------+ +----+/----->----------|B | 261 |A|->-| Foreign |->-|Internet|->-|GGSN| ----->----------| | 262 | | | Network | +--------+ +----+\ TFT2->Sess.2 +--+ 263 +-+ +---------+ | \ / 264 | \ / 265 | +----------+ 266 | 267 /\ | 268 || | 269 || | 270 +---------+ | 271 | Home |-------------+ 272 | Network | 273 +---------+ 274 Figure 1 276 Alternatively the GGSN will discard the IP datagram if all sessions 277 have TFT�s and none of them match the incoming packet. 279 The first such IP datagram sent by A will carry the �Care Of Test 280 Init� message of the Return Routability Procedure. If this message is 281 dropped, then Route Optimisation will not complete, and IP datagrams 282 from A to B will continue to be routed via the Home Agent instead 283 (see Section 4.1.1.1). 285 If, instead, this message is delivered to B by the GGSN, the Return 286 Routability procedure may complete and subsequent datagrams will be 287 routed in the same way as the Care Of Test Init. The session with 288 optimized route from A to B will therefore continue. 290 The major problem is then that the IP datagrams will not receive the 291 correct Quality of Service treatment. Since UMTS Quality of Service 292 can involve small constant bit-rate bandwidth reservations, this can 293 cause a complete loss of service, if the incorrect QoS treatment 294 involves a path with too low a bandwidth or no bandwidth guarantee at 295 all. 297 In addition, extra complexity or even difficulties will be incurred 298 in the system with respect to PDP Contexts and network resources, 299 especially, the radio resources, that remain unused but are being 300 paid for by the user. 302 4.1.2 Network Service defined Packet Filtering (SBLP) 304 4.1.2.1 Home Agent tunneling 306 We have not identified any issues with this case, for the same reason 307 as discussed in Section 4.1.1.1. 309 4.1.2.2 Route Optimization 311 When IMS multimedia sessions are set up between A and B, the SBLP 312 Policy Control authorizes IP datagrams to be sent from B to A�s home 313 address using assigned GPRS/UMTS network resources and the associated 314 QoS. When A moves away from its home network link and connects to 315 foreign network link, Mobile IPv6 Route Optimisation may be used to 316 allow B to continue sending IP datagrams to A by using A�s CoA. 318 Upon arrival at the GGSN, they will not match the SBLP filter for 319 the session which is authorized only for destination equal to A�s 320 home address. SBLP filters are associated with the particular UMTS 321 QoS reservation (PDP Context) for the session. If B continues to use 322 this QoS reservation for these packets, the GGSN will drop them as 323 they do not match the filter. 325 The following diagram shows an example of SBLP packet filtering for 326 IP datagrams sent from B through IMS sessions, 1 and 2, to A. 328 +----------+ 329 | SBLP | 330 | Control | 331 | Function | 332 +----------+ 333 | +----------+ 334 | / \ CN 335 MN | / IMS Sess. 1 \ +--+ 336 +-+ +---------+ +--------+ +----+/-----<---------- |B | 337 |A|---| Foreign |---|Internet|---|GGSN| -----<---------- | | 338 | | | Network | +--------+ +----+\ IMS Sess. 2 /+--+ 339 +-+ +---------+ | \ / 340 | \ / 341 | +----------+ 342 | 343 /\ | 344 || | 345 || | 346 +--------+ | 347 | Home |--------+ 348 | Network| 349 +--------+ 351 Figure 2 353 In practice, as discussed in Section 4.1.1.2, the Return Routability 354 procedure requires that there is a route for the Care Of Test Init 355 message from A to B. A route from B to A for the Care Of Test itself 356 is also required. 358 The means by which outgoing MIP control packets are allocated to QoS 359 reservation on the GPRS link by the UE are undefined in 3GPP, but we 360 note that such a message would not pass the SBLP filters (as 361 described above). 363 If the message is routed (i.e. on a different QoS reservation), then 364 Route Optimisation can be established with the consequences as 365 described above. 367 Similar considerations to those of Section 4.1.1.2 apply to IP 368 datagrams sent from A to B. 370 4.2 GPRS node, B, acting as Mobile Node 372 This is the case where the GPRS node ,B, is acting as MIPv6 Mobile 373 Node and has a live session such as VoIP with a Correspondent Node, 374 A. The MN, B, connects to the GPRS network after leaving either a 375 GPRS network or non-GPRS network. Therefore, the current GPRS link is 376 NOT taken to be B's Home link but a foreign link. 378 4.2.1 Mobile Terminal defined Packet Filtering (TFTs) 380 4.2.1.1 Home Agent Tunnelling 382 When B moves away from its home network link and connects to GPRS 383 network link, a PDP Context is set up and associated with a TFT 384 filter containing A's address as the Source Address for IP datagrams 385 sent from A to B. This will occur when the GPRS session control on 386 B�s terminal is not MIP-aware and the IP stack is not QoS/ 387 GPRS-aware. 389 The following diagram shows an example of two GPRS sessions, 1 and 2, 390 that are distinguished by GGSN using TFT filters, TFT1 and TFT2, for 391 incoming IP datagrams to be delivered to B. 393 TFT +--------+ 394 Packet / \ 395 Filter / \ MN 396 +------+ TFT1-Sess.1+---+ 397 *****| |---->-------| | 398 +-->--| GGSN | | B | 399 |*****| |---->-------| | 400 CN +-------+ | +------+ TFT2-Sess.2+---+ 401 +---+ | Local | +--------+ | \ GPRS / 402 | A |->-|Network|->-|Internet|== \ Network / 403 +---+ | A | +--------+ | +--------+ 404 +-------+ | 405 | +------+ 406 | | Home | /\ 407 |...********|+----+| || 408 +-------<---|| HA || || 409 ...********|+----+| 410 | Net- | 411 | work | 412 +------+ 414 Figure 3 416 The IP datagrams sent from A to B may use Home Agent Tunneling from 417 B's Home Agent to its current CoA. The IP datagrams tunneled from B's 418 Home Agent to B's CoA have the Home Agent address as the source 419 address in the outer header, while the TFT filter associated with the 420 existing session has A's address as the Source Address. When the IP 421 datagrams arrive at the GGSN, the source address in the outer header 422 does not match the Source Address in the TFT template associated with 423 the session. As a result, the IP datagrams may be discarded by the 424 GGSN or provided with incorrect QoS treatment. 426 4.2.1.2 Route Optimisation 428 For the Return Routability Procedure to complete, there needs to be 429 a route from HA to B to deliver the Home Test messages. If no 430 matching TFT is found by the GGSN for the tunneled Home Test 431 Messages and the GGSN chooses to drop the message, the Return 432 Routability procedure will fail and, as a result, the Route 433 Optimisation will not take place. 435 If tunnelled packets are routed at all from the Home Agent to B, then 436 the Return Routability procedure can complete successfully. 438 Packets from A are then sent directly to B's Care Of Address. These 439 will be correctly filtered by the TFTs and then delivered through the 440 corresponding PDP Context to B 442 4.2.2 Network Service defined packet filtering (SBLP) 444 4.2.2.1 Home Agent Tunnelling 446 When B moves away from its home network link and connects to a GPRS 447 network, it requests and acquires an IMS session with terminal A with 448 authorised SBLP information containing A's address as the Destination 449 Address for IP datagrams sent from B to A. 451 When Home Agent Tunnellling operation mode is used, B uses a 452 (reverse) tunnel from its CoA to its Home Agent to send IP datagrams 453 to A. In the reverse tunnel, the IP datagrams tunneled from B carry 454 its Home Agent address as the destination. 456 The following diagram shows an example of two IMS sessions, each of 457 which is associated with a SBLP filter, SBLP1 and SBLP2, for IP 458 datagrams to be sent to the authorised destination, i.e. A�s address. 460 TFT +-----------+ 461 Packet / \ 462 Filter / SBLP1 - Sess.1\ MN 463 +--------+*************** +---+ 464 *****| |----<-----------| | 465 |--<--| GGSN | SBLP2 - Sess.2 | B | 466 |*****| |----<-----------| | 467 CN +-------+ | +--------+****************+---+ 468 +---+ | Local | +--------+ | \ / 469 | A |-<-|Network|-<-|Internet|== \ GPRS Network / 470 +---+ | | +--------+ | +------------+ 471 +-------+ | 472 | +------+ 473 | | Home | /\ 474 | ********|+----+| || 475 +------->---|| HA || || 476 ********|+----+| 477 | Net- | 478 ---<---| work | 479 +------+ 481 Figure 4 483 When the IP datagrams in an IPinIP tunnel arrive at the GGSN, GGSN 484 will find no authorised SBLP matching the destination indicated by 485 the outer header of the tunnelled IP datagrams, and it will block 486 and drop them. 488 4.2.2.2 Route Optimisation 490 When Route Optimisation is used, IP datagrams from A to B (and B to 491 A) use B's Care of Address as destination (resp. source) and 492 therefore will not match any of the established SBLP filters. This 493 is because the pre-established SBLP filters authorise IP datagrams 494 sent to B�s Home Address to enter the GPRS/UMTS network. These will 495 either be blocked or carried with inappropriate QoS treatment. 497 The following diagram shows an example of filtering IP datagrams 498 sent from A directly to B using route optimization passing an SBLP 499 filter SBLP1 or SBLP2. Both authorize the use of IMS sessions and 500 associated network resources to deliver IP datagrams to B�s home 501 address. 503 SBLP +----------+ 504 Packet / \ 505 Filter / SBLP1-Sess.1 \ MN 506 +--------+ +---+ 507 | |---->--------| | 508 +->-| GGSN | | B | 509 | | |---->--------| | 510 CN +-------+ | +--------+ SBLP2-Sess.2+---+ 511 +---+ | Local | +--------+ | \ / 512 | A |->-|Network|->-|Internet|== \GPRS Network / 513 +---+ | | +--------+ | +-----------+ 514 +-------+ | 515 | 516 | /\ 517 | +-------+ || 518 +-----------| Home | || 519 |Network| 520 +-------+ 522 Figure 5 524 Depending on the policy applied to packets which do not match the 525 SBLP filters, the Return Routability procedure may not complete. This 526 is because the SBLP filters, SBLP1 and SBLP2, authorize IP datagrams 527 sent to B�s Home Address for accessing GPRS network resources and 528 IMS services. The �Care of Test� message in response to the �Care of 529 Test Init� message from B uses B�s Care-of Address as the 530 destination address. 532 5. Problem generalization 534 Although the description above is presented in terms of GPRS-specific 535 mechanisms for installing packet filters in the network. More general 536 situations may exist in which such filters are installed. This may 537 give rise to similar problems. 539 In the analysis above, we classify the filters as �mobile terminal 540 defined� and �network service defined�. This represents the source of 541 the information within the filters. 543 An example of a �terminal defined� filter in the network is a filter 544 installed as a result of RSVP (or in future NSIS protocols). Such 545 filters determine the QoS treatment that will be applied to packets 546 according to the user�s request and are therefore very similar to 547 Traffic Flow Templates. 549 An example of a �network service defined � filter would be one 550 installed through policy mechanisms. In this case it is in order to 551 apply appropriate network policy that packets filtered. 553 6. Security Considerations 555 6.1 User security considerations 557 No user security issues have been identified. 559 6.2 Network security considerations 561 In the case of network service defined filters (e.g. Service Based 562 Local Policy), the purpose of the filters is to ensure that 563 appropriate network policy for controlling access to network 564 resources and services is applied to the packets. 566 The problems described in this paper do not themselves represent 567 security issues for the network (for example users circumventing the 568 network�s policy). Indeed, the problems arise largely because the 569 policies cause packets to be dropped, or treated according to a 570 different policy which explicitly allows those packets to pass. 572 However, care must be taken in considering solutions to these 573 problems which cause modification of the network�s policies. Such 574 modification will necessarily be caused by the mobility event at one 575 or other user. These events can easily be faked by users. 577 For example, IP address spoofing could be used to convince the 578 network that a user has moved when in fact they have not. 579 Collaborating users could convince the network that a user has moved, 580 when in fact the new address belongs to a different host. 582 7. Acknowledgments 584 The authors would like to thank Paul Reynolds, Ric Bailey, Ronan Le 585 Bras, Graham Fisher, Stuart Shutt, Steve Blythe and Rob Allan for 586 their constant and valuable support for the work. 588 References 590 [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 591 IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July 592 2003. 594 [2] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating 595 Denial of Service Attacks which employ IP Source Address 596 Spoofing", BCP 38, RFC 2827, May 2000. 598 [3] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, 599 June 1995. 601 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 602 Levels", BCP 14, RFC 2119, March 1997. 604 [5] 3GPP, "3rd Generation Partnership Project; Technical 605 Specification Group Services and System Aspects; General Packet 606 Radio Services (GPRS); Service Description; Stage 2", 3GPP TS 607 23.060. 609 [6] 3GPP, "3rd Generation Partnership Project; Technical 610 Specification Group Core Network; Mobile Radio Interface Layer 3 611 Specifications; Core Network Protocols - Stage 3", 3GPP TS 612 23.008. 614 [7] 3GPP, "3rd Generation Partnership Project; Technical 615 Specification Group Services and System Aspects; IP Multimedia 616 Subsystem (IMS); Stage 2", 3GPP TS 23.228. 618 [8] 3GPP, "3rd Generation Partnership Project; Technical 619 Specification Group Services and System Aspects; End-to-end 620 Quality of Service; Concept and Architecture", 3GPP TS 23.207. 622 [9] 3GPP, "3rd Generation Partnership Project; Technical 623 Specification Group Core Network; Policy Control over Go 624 Interface", 3GPP TS 29.207. 626 Authors' Addresses 628 Xiaobao Chen 629 Orange PCS Ltd. 630 Keypoint 631 St. James Court, Almondsbury Park 632 Bradley Stoke 633 Bristol BS32 4QJ 634 UK 636 Phone: +44 7989 477679 637 EMail: xiaobao.chen@orange.co.uk 638 Mark Watson 639 Nortel Networks 640 Maidenhead Office Park 641 Westacott Way 642 Maidenhead, BERKS SL6 3QH 643 UK 645 Phone: +44 1628 434456 646 EMail: mwatson@nortelnetworks.com 648 Martin Harris 649 Orange PCS Ltd. 650 Keypoint 651 St. James Court, Almondsbury Park 652 Bradley Stoke 653 Bristol BS32 4QJ 654 UK 656 Phone: +44 7974 365080 657 EMail: martin.harris@orange.co.uk 659 Intellectual Property Statement 661 The IETF takes no position regarding the validity or scope of any 662 intellectual property or other rights that might be claimed to 663 pertain to the implementation or use of the technology described in 664 this document or the extent to which any license under such rights 665 might or might not be available; neither does it represent that it 666 has made any effort to identify any such rights. Information on the 667 IETF's procedures with respect to rights in standards-track and 668 standards-related documentation can be found in BCP-11. Copies of 669 claims of rights made available for publication and any assurances of 670 licenses to be made available, or the result of an attempt made to 671 obtain a general license or permission for the use of such 672 proprietary rights by implementors or users of this specification can 673 be obtained from the IETF Secretariat. 675 The IETF invites any interested party to bring to its attention any 676 copyrights, patents or patent applications, or other proprietary 677 rights which may cover technology that may be required to practice 678 this standard. Please address the information to the IETF Executive 679 Director. 681 Full Copyright Statement 683 Copyright (C) The Internet Society (2003). All Rights Reserved. 685 This document and translations of it may be copied and furnished to 686 others, and derivative works that comment on or otherwise explain it 687 or assist in its implementation may be prepared, copied, published 688 and distributed, in whole or in part, without restriction of any 689 kind, provided that the above copyright notice and this paragraph are 690 included on all such copies and derivative works. However, this 691 document itself may not be modified in any way, such as by removing 692 the copyright notice or references to the Internet Society or other 693 Internet organizations, except as needed for the purpose of 694 developing Internet standards in which case the procedures for 695 copyrights defined in the Internet Standards process must be 696 followed, or as required to translate it into languages other than 697 English. 699 The limited permissions granted above are perpetual and will not be 700 revoked by the Internet Society or its successors or assignees. 702 This document and the information contained herein is provided on an 703 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 704 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 705 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 706 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 707 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 709 Acknowledgment 711 Funding for the RFC Editor function is currently provided by the 712 Internet Society.