idnits 2.17.1 draft-chen-mobileip-packet-fitlering-xc-01.txt: 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 1) being 67 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 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 14 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 27 has weird spacing: '... months and m...' == Line 34 has weird spacing: '... The list o...' == Line 66 has weird spacing: '... mobile node ...' == Line 68 has weird spacing: '...portant and h...' == Line 76 has weird spacing: '...ing and outgo...' == (37 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 (17 June 2003) is 7618 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- 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' Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Mobile IP Working Group Xiaobao Chen 2 INTERNET-DRAFT Orange PCS Ltd. 3 Expires: 17 December 2003 4 Martin Harris 5 Orange PCS Ltd. 7 Nick Sampson 8 Orange PCS Ltd. 10 17 June 2003 12 MIPv6 Inter-working with Packet Filtering 14 draft-chen-mobileip-packet-fitlering-xc-01.txt 16 Status of This Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or made obsolete by other 28 documents at any time. It is inappropriate to use Internet-Drafts 29 as reference material or to cite them other than as "work in 30 progress." 32 The list of current Internet-Drafts can be accessed at 33 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 Abstract 39 This document provides considerations for some requirements on 40 the IPv6 nodes using MIPv6 to communicate with their peers across 41 a network boundary where some specific packet filtering is 42 deployed for operator and service provider controlled access to 43 the services and network resources. Depending on the operational 44 policies, the packet filtering can be applied on either the 45 incoming packets or the outgoing packets or in both directions. 46 A mobile node using MIPv6 sends packets with Home IP address in 47 the extension headers, while the packet filtering is often based 48 on either the source address or the destination address or both 49 in the basic IPv6 header.Packet filtering that complies with the 50 policies from the mobility unaware applications will fail to 51 perform properly due to the change of the source and destination 52 addresses in the basic IPv6 header when MIPv6 is used. This 53 document provides an analysis on the operation requirements on 54 packet filtering and then proposes a simple solution that does 55 not impose any change on IPv6 but requires an addition to IPv6 56 nodes using MIPv6. 58 INTERNET-DRAFT MIPv6 Interworking with Packet Filtering 60 1 Introduction 62 Mobile IPv6 (MIPv6)[1] allows a mobile node to maintain its IP 63 connectivity regardless of its network attachment point. 64 Packets sent to the mobile node may still use its home address, or 65 the care-of address of the mobile node as the destination address. 66 The mobile node may continue to communicate with its existing 67 communication peers (stationary or mobile) by using its 68 topologically correct IP addresses. An important and highly 69 desirable feature of mobile IP based mobility is that the control 70 is transparent to transport and higher-layer protocols and 71 applications, i.e. the higher layer protocols and applications 72 function as if the mobile node is "stationary". 74 Packet filtering is used by operators and service providers for 75 protecting the network and the host(s). It is achieved by 76 distinguishing incoming and outgoing packets and then control 77 the access to network resources and services based on operator or 78 service provider defined policies. 80 An IPv6 node using MIPv6 sends packets with home address carried 81 in the extension headers of the IPv6 packets, while the packet 82 filtering can be based on either the source address or the 83 destination address or both in the basic IPv6 header. This is 84 usually because the packet filtering complies with policy control 85 information that comes from an application server or the upper 86 layers which operate independently from mobile IP . A packet that 87 fails to match either the source address or the destination IP 88 address in its basic IP header will be discarded by the gateway 89 node that performs packet filtering based on the 90 source or destination addresses in the basic IPv6 header. 92 In this document some common operational practices of packet 93 filtering are described. Then operational issues and requirements 94 are discussed when an IPv6 node uses MIPv6 to communicate with 95 its peers through a network boundary that performs a network 96 address based packet filtering. It then proposes a simple 97 solution of an addition to IPv6 nodes using MIPv6 without any 98 restrictions on standard IPv6 operations. 100 2 Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED","SHALL","SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 104 this document are to be interpreted as described in RFC 2119. 106 3 Some Common Packet Filtering Practices 108 The following sections list some packet filtering operations 109 deployed by ISP's or 3G operators. It is not intended to 110 exhaust all the possible application scenarios for packet 111 filtering. 113 3.1 Network Ingress Filtering by ISP's 115 Some typical example are given in RFC2827[2] about ingress 116 filtering used to protect network and hosts against Denial of 117 Service Attacks using IP Source Address Spoofing. An attacker 118 using a forged but "valid" IP source address (e.g. those 119 that appear in the global routing tables) can launch an attack on 121 INTERNET-DRAFT MIPv6 Interworking with Packet Filtering 123 a network or a host and cause serious disruptions or even a crash 124 of the network and service operations. The proposed operational 125 practice for an ISP is to restrict transit traffic which 126 originates from a downstream network to known, and intentionally 127 advertised, prefix(es). This "ingress filtering" would check if an 128 incoming packet uses a legitimate source address, i.e. the address 129 assigned by the ISP from which the packet is originated. For 130 example, the only valid source address for packets originating 131 from a PC is the one assigned by the ISP after successful log-in 132 process which usually involves the use of authentication and 133 authorisation procedures. This packet filtering based on valid 134 source address is also recommended on edge routers [3] to 135 validate the source IP address of the sender. 137 3.2 Network Packet Filtering by 3G Operators 139 Some strong driving factors for deploying IPv6 and mobility 140 support in IPv6 on a wide-scale have been seen in the 3GPP 141 community. The UMTS IP Multimedia Subsystem (IMS)[6] is based on 142 IPv6. Mobile IP has been identified by 3GPP as a solution for 143 providing mobility control between wireless LAN and GPRS/UMTS 144 networks to support 3G services including IMS services. Supporting 145 IPv6/MIPv6 in GPRS/UMTS networks has become an imminent and 146 important issue to 3G community, especially 3G operators. Two 147 important packet filtering operations that take place at the 148 GPRS Gateway Support Node (GGSN) in GPRS/UMTS networks are 149 described in the following sections. 151 3.2.1 Ingress Filtering at the GPRS/UMTS Gateway Node 153 To support IP multimedia services with differentiated QoS, 154 GPRS/UMTS networks support multiple simultaneous GPRS/UMTS 155 sessions as typically represented by multiple secondary PDP 156 (Packet Data Protocol) Contexts[4]. Each GPRS/UMTS session may be 157 assigned specific QoS with the necessary network resources 158 (including radio resources). An incoming packet from the external 159 IP network will be checked by the gateway node, GGSN, to decide if 160 there is an existing GPRS/UMTS session to deliver the packet 161 through the network to the mobile terminal. The packet is checked 162 against a Traffic Flow Template [5] (TFT) that contains the packet 163 filtering information such as the IPv4/IPv6 Source Addresses, 164 Protocol Identifier, Source/Destination Ports, etc. The packet 165 filtering operation will use at least one of those 166 packet filter parameters, primarily the Source Address, to choose 167 the appropriate GPRS/UMTS session. 169 On receiving an packet, the GGSN will search for a GPRS/UMTS 170 session with the TFT that contains the parameter values matching 171 those carried in the packet. For example, the Source IP Address 172 field of each existing TFT will be compared with the source address 173 carried by the packet.If no matching TFT is found, the packet may 174 be discarded. 176 3.2.2 Egress Filtering for IMS Services at the GPRS/UMTS Gateway Node 178 The IP Multimedia Subsystem (IMS) [6] is defined by 3GPP to 179 provide SIP-based IP multimedia services. In IMS, Service-based 180 Local Policy control(SBLP) [7, 8] is enforced by the gateway node, 181 GGSN, to authorise and control the access to the IMS services and 183 INTERNET-DRAFT MIPv6 Interworking with Packet Filtering 185 the GPRS/UMTS network resources based on operator defined 186 local policies. For example, an IMS service request, a 187 GPRS/UMTS session set-up request and the subsequent data packets 188 originated by the mobile terminal will be checked at the gateway 189 node, GGSN, against a set of policy control information 190 parameters such as Destination Address, Destination Port Number, 191 Transport Protocol ID, etc. The policy control information is 192 issued as an authorisation from the upper layer (the IMS/Policy 193 Control Function -PCF). A service request or a packet will be 194 blocked the GGSN if it fails the packet filtering based on the 195 policy control information. 197 4. Problem statements 199 When a mobile node (MN) leaves its home network link and connects 200 to a foreign network that deploys the packet filtering described 201 in section 3.2, the MN will encounter some difficulties 202 communicating with its peers using MIPv6 and its upper layers 203 sessions will be disrupted. 205 4.1 Source Address based Ingress Filtering 207 For packets sent from the Correspondent Node) (CN) to the MN, 208 the packets may either be tunneled by the MN's Home Agent(HA) to 209 the MN or sent from the CN directly to the MN. 211 4.1.1 The Case of HA Tunneling 213 When the packets travel through the tunnel from the HA to the 214 MN, the source address in the outer header of the tunnelled packet 215 is the address of the HA. The gateway node in the foreign network 216 is likely to perform ingress filtering based on the original source 217 address, i.e., the address of the CN, despite the fact that the HA 218 will still tunnel packets to the MN. This is the case especially 219 when the ingress packet filtering function is not mobility aware, 220 i.e. it makes no distinction between a stationary node or mobile 221 node using mobile IPv6. 223 A typical example is the Ingress Filtering at GGSN in GPRS/UMTS 224 networks as described in section 3.2.1 where the UMTS sessions are 225 set up and operated independent of the mobile IP control. The GPRS 226 /UMTS sessions makes no distinction between packets with or without 227 MIPv6 extensions. An incoming packet with a source address (i.e. 228 the address of the HA) different from the address used for packet 229 filtering (i.e. the IP address of the CN) will fail to find a 230 matching UMTS session and may be discarded. This has some serious 231 implications. For example, a live IMS session between two IPv6 232 nodes will be broken when any one of them leaves its home network, 233 moves into GPRS/UMTS and start using MIPv6. 235 A mechanism that reads inner header of the tunnelling packet may 236 not work. For example, the gateway node fails to read the payload 237 of the tunnelling packet due to the possible encryption, e.g. 238 IPSec ESP. 240 4.1.2 The Case of Route Optimisation when the CN is mobile 242 When Route Optimisation is used, the packets are sent directly 243 from the CN to the MN with the source address being the address of 245 INTERNET-DRAFT MIPv6 Interworking with Packet Filtering 247 the CN. When the CN is a mobile node itself and attached to a 248 foreign network, the source address of the packets sent from CN 249 will be its Care-of Address (CoA). When packet filtering is 250 based on the original source address of the CN, i.e. its home 251 address, packets sent from the CN will be discarded by the gateway 252 node. 254 A typical example is the case when the GSSN uses ingress 255 filtering for selecting the UMTS sessions.Although the packet sent 256 from the mobile CN to the MN has the "Home Address Destination 257 Option" containing its Home address[1], a gateway node as 258 an intermediate node operating standard IPv6 does not read it. 259 This will have some serious implications such as the disruption of 260 existing live sessions. 262 4.2 Destination Address based Egress Filtering 264 For packets sent directly from the CN to the MN that is attached 265 to a foreign network, the destination address will be the CoA of 266 the MN. The gateway node such as the GGSN in the GPRS/UMTS 267 networks that is not mobile IP aware will still use the original 268 destination IP address, i.e. the home address of the MN to perform 269 the Egress Filtering. 271 Section 3.2.2 describes the egress filtering using the Service- 272 based Local Policy Decision provided by the Policy Control Function 273 that operates independently from mobile ip based mobility control. 275 When an IPv6 node in the GPRS/UMTS network is to initiate or having a 276 IMS session with a MN that is away from its home network, the 277 packets sent from CN directly to the MN using MIPv6 compliant 278 header will fail to pass through the SBLP based packet filtering. 279 Although the packet sent from the CN to the MN has the Routing 280 Header Type 2 in its option headers field[1], a standard IPv6 281 operating gateway node as an intermediate node does not read 282 this header. 284 5. Requirements on Inter-working Mobile IPv6 with Packet Filtering 286 The following requirements are recommended for a gateway node that 287 performs source address and/or destination address based packet 288 filtering: 290 * A gateway node running standard IPv6 should not be required to 291 change to support packet filtering function. 293 * The policy control functions for packet filtering such as the PCF 294 should not be aware of the mobility control based on mobile IP. 296 6. A Recommended Practice 298 A simple solution to the above inter-working problem with MIPv6 299 and packet filtering is to enable the gateway node to access the 300 required information to perform the packet filtering while in the 301 meantime the operations on packets in the gateway node should comply 302 with standard IPv6 specifications. According to standard 303 IPv6,the Hop-by-Hop Options Header, is accessible to intermediate 305 INTERNET-DRAFT MIPv6 Interworking with Packet Filtering 307 IPv6 nodes between the source and the destination.The Hop-by-Hop 308 Options Header carries information that intermediate nodes between 309 a source and destination needs to know. Every node along a 310 packet's path examines the Hop-by-Hop options header for the 311 required information. 313 6.1 MIPv6 Interworking with Source IP Address based Ingress Filtering 315 The following recommended practice will enable the gateway node, 316 such as the GGSN in GPRS/UMTS networks, to perform source address 317 based Ingress Filtering because a standard IPv6 gateway node, as 318 an intermediate node, is able to access the information contained 319 in the Hop-by-Hop Options Field. 321 6.1.1 The Recommended Practice in case of HA Tunnelling 323 For a CN communicating to its MN using HA tunnelling, the HA 324 should insert original IP address of the CN in the Hop-by-Hop 325 Options Header in the outer IP header of the tunnelling packet. 326 In the case when the CN is a mobile node itself and away from its 327 home network, the CN may need to insert its Home IP address in 328 the Hop-by-Hop Options Field for packets sent to the MN's Home 329 IP address. The HA, as an intermediate IPv6 node, will read the 330 Hop-by-Hop Options Field and access the information and then 331 put the original IP address (the Home IP address) of the (mobile) 332 MN in the Hop-by-Hop Options Header in the outer header of the 333 tunnelling packets. 335 6.1.2 The Recommended Practice in case of Route Optimisation 337 For a CN communicating to a MN using route optimisation 338 to send packets directly to the MN, the CN should insert its IP 339 address in the Hop-by-Hop Options Header. In the case where the CN 340 is a mobile itself and away from its network, the CN should insert 341 its Home IP address in the Options filed in the Hop-by-Hop Options 342 Header. 344 6.2 MIPv6 Interworking with Destination IP Address based Egress 345 Filtering 347 For a CN communicating to a MN using Route Optimisation 348 to send packets directly to the MN, the CN should insert 349 the Home IP Address of the MN in the Hop-by-Hop Options Header 350 using standard IPv6 operations. 352 The above recommended practice will enable the gateway node, such 353 as the GGSN in GPRS/UMTS network, to perform destination 354 address based Egress Filtering such as SBLP because a standard 355 IPv6 gateway node, as an intermediate node, is able to access the 356 information in the Hopy-by-Hop Options Field using standard IPv6 357 operations. 359 INTERNET-DRAFT MIPv6 Interworking with Packet Filtering 361 6.3 MIPv6 Interworking with Source and Destination IP Address based 362 Packet Filtering 364 It is likely that a packet sent from the HA or the CN to the MN 365 may need to pass through Egress Filtering (for packets leaving 366 the network where the CN or the HA is located) as well as Ingress 367 Filtering (for packets coming into the network where the MN is 368 located). Both the gateway node performing the Egress Filtering 369 and the one performing Ingress Filtering will need to acquire the 370 necessary information to perform the filtering function. It is 371 recommended that the CN and HA (in the case when the HA 372 tunneling is used) should insert the both the IP 373 address of the CN and the Home IP address of the MN in the Options 374 Field of Hop-by-Hop Options Header. The CN's IP Address is 375 placed before the MN's IP Address. 377 The above recommended operation is applied only to the outer IP 378 header of the packet when HA tunnelling is used. 380 The gateway node that performs the packet filtering will read the 381 data in the first 16 octets of the option field as the source IP 382 Address and the data in the following 16 octets of the option 383 field as the destination IP address. 385 7. Security Considerations 387 7.1 Ingress Filtering 389 It may well be likely that a malicious node launches attacks 390 against the MN by spoofing the Original Source IP Address (the 391 legitimate CN) or/and the Original Destination Address (the Home 392 IP Address of the MN) in its Hop-by-Hop Options Field to pass the 393 gateways that performs ingress packet filtering. 395 The recommended practice to tackle this problem is using the 396 Ingress Packet Filtering described in RFC2827[2]. The Ingress 397 gateway checks if the packet has the topologically correct 398 source IP address representing a legitimate CN or HA in the 399 network from which the packet comes from. 401 7.2 Egress Filtering 403 A potential risk may arise for operators running IMS with SBLP when 404 the GGSN checks the Hop-by-Hop Options Header for the destination 405 address (Sections 4.2, 6.2). After initial successful IMS SBLP 406 authorisation, a CN attached to a GPRS/UMTS network may insert 407 the address of an unauthorised destination (e.g. sites barred by 408 the operator) in the IPv6 basic header while it inserts the 409 authorised MN's home address in the Hop-by-Hop Options Field. This 410 will enable the packets to pass the SBLP based packet filtering at 411 the GGSN to reach un-authorised destinations. 413 To tackle this potential risk, the GGSN should associate the 414 current destination address of the MN, i.e. its CoA, with the 415 original destination address, i.e. the MN's home address of the MN 416 that is authorised by the IMS SBLP. The following approach may be 417 used by GGSN to establish such an association. 419 A MN attached to a foreign network may send a Binding Update 421 INTERNET-DRAFT MIPv6 Interworking with Packet Filtering 423 message [1] to the CN attached to the GPRS/UMTS network. The 424 binding update message using the MN's CoA as the Source Address 425 may therefore be blocked by the GGSN's TFT packet filtering 426 function. Instead of blocking the packet, the GGSN may 427 also need to check if the packet carries the Binding Update 428 Message by looking at the MH Type Value. If it is "5"[1], the 429 GGSN recognises that it is a binding update message and record the 430 Source Address of the binding update message as the 431 current address of the MN. 433 To guarantee that the recorded address obtained from the Binding 434 Update Message is the MN's current address, the GGSN may need to 435 wait until a Binding Acknowledgement Message is sent from the CN 436 withe MH Type Value "6". The GGSN will establish an association 437 between the MN's current address (CoA) to be used by the CN in 438 IPv6 basic header and the MN's Home Address in the Hop-by-Hop 439 Options Field for sending packets to the MN. 441 For a secure SBLP operation, the GGSN will check both the 442 destination address in the IPv6 basic header and the Hop-by-Hop 443 Options Field in the IPv6 extension headers. Those packets found 444 with destination address unmatching the association with 445 the MN's Home Address will be blocked by the GGSN. 447 8. Acknowledgment 449 The authors would like to thank Phil Roberts and James Kemp for 450 their valuable comments and feedbacks on the issues. 451 Acknowledgements are made to Paul Reynolds, Ric Bailey, Ronan 452 Le Bras, Graham Fisher, Stuart Shutt, Steve Blythe and Rob Allan 453 for their constant and valuable support for the work. 455 9. References 457 [1] D. Johnson, C. Parkins. J. Arkko. "Mobility Support in IPv6", 459 [2] P. Ferguson, D. Senie. "Network Ingress Filtering: Defeating 460 Denial of Service Attacks which employ IP Source Address 461 Spoofing. RFC2827, BCP38 Internet Engineering Task Force, May 2002 463 [3] F. Baker. "Requirements for IP Version 4 Routers", RFC1812, June 1995. 465 NTERNET-DRAFT MIPv6 Interworking with Packet Filtering 467 [4] 3GPP TS23.060, "3rd Generation Partnership Project; 468 Technical Specification Group Services and System Aspects; General 469 Packet Radio Services (GPRS); Service Description; Stage 2 (Release 470 1999)". 472 [5] 3GPP TS23.008, "3rd Generation Partnership Project; 473 Technical Specification Group Core Network; Mobile Radio Interface Layer 474 3 Specifications; Core Network Protocols - Stage 3 (Release 1999)". 476 [6] 3GPP TS23.228, "3rd Generation Partnership Project; 477 Technical Specification Group Services and System Aspects; (Release 5)". 479 [7] 3GPP TS23.207, "3rd Generation Partnership Project; 480 Technical Specification Group Services and System Aspects;End-to-End 481 QoS Concept and Architecture (Release 5)". 483 [8] 3GPP TS29.207, "3rd Generation Partnership Project; 484 Technical Specification Group Core Network; Policy Control over Go 485 Interface (Release 5)". 487 9 Authors' Addresses 489 Xiaobao Chen 490 Orange PCS Ltd. 491 Keypoint 492 St. James Court, Almondsbury Park 493 Bradley Stoke, Bristol, BS32 4QJ 494 UK 496 Phone: +0044 (0)7989 477 679 497 EMail: xiaobao.chen@orange.co.uk 499 Martin Harris 500 Orange PCS Ltd. 501 Keypoint 502 St. James Court, Almondsbury Park 503 Bradley Stoke, Bristol BS32 4QJ 504 UK 506 Phone: +0044 (0)7974 365 080 507 EMail: martin.harris@orange.co.uk 509 Nick Sampson 510 Orange PCS Ltd. 511 Keypoint 512 St. James Court,Almondsbury Park 513 Bradley Stoke, Bristol BS32 4QJ 514 UK 516 Phone: +0044 (0)7973 963 519 517 EMail: nick.sampson@orange.co.uk