IETF Mobile IP Working Group Xiaobao Chen INTERNET-DRAFT Orange PCS Ltd. Expires: 17 December 2003 Martin Harris Orange PCS Ltd. Nick Sampson Orange PCS Ltd. 17 June 2003 MIPv6 Inter-working with Packet Filtering draft-chen-mobileip-packet-fitlering-xc-01.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document provides considerations for some requirements on the IPv6 nodes using MIPv6 to communicate with their peers across a network boundary where some specific packet filtering is deployed for operator and service provider controlled access to the services and network resources. Depending on the operational policies, the packet filtering can be applied on either the incoming packets or the outgoing packets or in both directions. A mobile node using MIPv6 sends packets with Home IP address in the extension headers, while the packet filtering is often based on either the source address or the destination address or both in the basic IPv6 header.Packet filtering that complies with the policies from the mobility unaware applications will fail to perform properly due to the change of the source and destination addresses in the basic IPv6 header when MIPv6 is used. This document provides an analysis on the operation requirements on packet filtering and then proposes a simple solution that does not impose any change on IPv6 but requires an addition to IPv6 nodes using MIPv6. Xiaobao Chen et al Expires 17 December 2003 [Page i] INTERNET-DRAFT MIPv6 Interworking with Packet Filtering 1 Introduction Mobile IPv6 (MIPv6)[1] allows a mobile node to maintain its IP connectivity regardless of its network attachment point. Packets sent to the mobile node may still use its home address, or the care-of address of the mobile node as the destination address. The mobile node may continue to communicate with its existing communication peers (stationary or mobile) by using its topologically correct IP addresses. An important and highly desirable feature of mobile IP based mobility is that the control is transparent to transport and higher-layer protocols and applications, i.e. the higher layer protocols and applications function as if the mobile node is "stationary". Packet filtering is used by operators and service providers for protecting the network and the host(s). It is achieved by distinguishing incoming and outgoing packets and then control the access to network resources and services based on operator or service provider defined policies. An IPv6 node using MIPv6 sends packets with home address carried in the extension headers of the IPv6 packets, while the packet filtering can be based on either the source address or the destination address or both in the basic IPv6 header. This is usually because the packet filtering complies with policy control information that comes from an application server or the upper layers which operate independently from mobile IP . A packet that fails to match either the source address or the destination IP address in its basic IP header will be discarded by the gateway node that performs packet filtering based on the source or destination addresses in the basic IPv6 header. In this document some common operational practices of packet filtering are described. Then operational issues and requirements are discussed when an IPv6 node uses MIPv6 to communicate with its peers through a network boundary that performs a network address based packet filtering. It then proposes a simple solution of an addition to IPv6 nodes using MIPv6 without any restrictions on standard IPv6 operations. 2 Terminology The key words "MUST", "MUST NOT", "REQUIRED","SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 3 Some Common Packet Filtering Practices The following sections list some packet filtering operations deployed by ISP's or 3G operators. It is not intended to exhaust all the possible application scenarios for packet filtering. 3.1 Network Ingress Filtering by ISP's Some typical example are given in RFC2827[2] about ingress filtering used to protect network and hosts against Denial of Service Attacks using IP Source Address Spoofing. An attacker using a forged but "valid" IP source address (e.g. those that appear in the global routing tables) can launch an attack on Xiaobao Chen et al Expires 17 December 2003 [Page 1] INTERNET-DRAFT MIPv6 Interworking with Packet Filtering a network or a host and cause serious disruptions or even a crash of the network and service operations. The proposed operational practice for an ISP is to restrict transit traffic which originates from a downstream network to known, and intentionally advertised, prefix(es). This "ingress filtering" would check if an incoming packet uses a legitimate source address, i.e. the address assigned by the ISP from which the packet is originated. For example, the only valid source address for packets originating from a PC is the one assigned by the ISP after successful log-in process which usually involves the use of authentication and authorisation procedures. This packet filtering based on valid source address is also recommended on edge routers [3] to validate the source IP address of the sender. 3.2 Network Packet Filtering by 3G Operators Some strong driving factors for deploying IPv6 and mobility support in IPv6 on a wide-scale have been seen in the 3GPP community. The UMTS IP Multimedia Subsystem (IMS)[6] is based on IPv6. Mobile IP has been identified by 3GPP as a solution for providing mobility control between wireless LAN and GPRS/UMTS networks to support 3G services including IMS services. Supporting IPv6/MIPv6 in GPRS/UMTS networks has become an imminent and important issue to 3G community, especially 3G operators. Two important packet filtering operations that take place at the GPRS Gateway Support Node (GGSN) in GPRS/UMTS networks are described in the following sections. 3.2.1 Ingress Filtering at the GPRS/UMTS Gateway Node To support IP multimedia services with differentiated QoS, GPRS/UMTS networks support multiple simultaneous GPRS/UMTS sessions as typically represented by multiple secondary PDP (Packet Data Protocol) Contexts[4]. Each GPRS/UMTS session may be assigned specific QoS with the necessary network resources (including radio resources). An incoming packet from the external IP network will be checked by the gateway node, GGSN, to decide if there is an existing GPRS/UMTS session to deliver the packet through the network to the mobile terminal. The packet is checked against a Traffic Flow Template [5] (TFT) that contains the packet filtering information such as the IPv4/IPv6 Source Addresses, Protocol Identifier, Source/Destination Ports, etc. The packet filtering operation will use at least one of those packet filter parameters, primarily the Source Address, to choose the appropriate GPRS/UMTS session. On receiving an packet, the GGSN will search for a GPRS/UMTS session with the TFT that contains the parameter values matching those carried in the packet. For example, the Source IP Address field of each existing TFT will be compared with the source address carried by the packet.If no matching TFT is found, the packet may be discarded. 3.2.2 Egress Filtering for IMS Services at the GPRS/UMTS Gateway Node The IP Multimedia Subsystem (IMS) [6] is defined by 3GPP to provide SIP-based IP multimedia services. In IMS, Service-based Local Policy control(SBLP) [7, 8] is enforced by the gateway node, GGSN, to authorise and control the access to the IMS services and Xiaobao Chen et al Expires 17 December 2003 [Page 2] INTERNET-DRAFT MIPv6 Interworking with Packet Filtering the GPRS/UMTS network resources based on operator defined local policies. For example, an IMS service request, a GPRS/UMTS session set-up request and the subsequent data packets originated by the mobile terminal will be checked at the gateway node, GGSN, against a set of policy control information parameters such as Destination Address, Destination Port Number, Transport Protocol ID, etc. The policy control information is issued as an authorisation from the upper layer (the IMS/Policy Control Function -PCF). A service request or a packet will be blocked the GGSN if it fails the packet filtering based on the policy control information. 4. Problem statements When a mobile node (MN) leaves its home network link and connects to a foreign network that deploys the packet filtering described in section 3.2, the MN will encounter some difficulties communicating with its peers using MIPv6 and its upper layers sessions will be disrupted. 4.1 Source Address based Ingress Filtering For packets sent from the Correspondent Node) (CN) to the MN, the packets may either be tunneled by the MN's Home Agent(HA) to the MN or sent from the CN directly to the MN. 4.1.1 The Case of HA Tunneling When the packets travel through the tunnel from the HA to the MN, the source address in the outer header of the tunnelled packet is the address of the HA. The gateway node in the foreign network is likely to perform ingress filtering based on the original source address, i.e., the address of the CN, despite the fact that the HA will still tunnel packets to the MN. This is the case especially when the ingress packet filtering function is not mobility aware, i.e. it makes no distinction between a stationary node or mobile node using mobile IPv6. A typical example is the Ingress Filtering at GGSN in GPRS/UMTS networks as described in section 3.2.1 where the UMTS sessions are set up and operated independent of the mobile IP control. The GPRS /UMTS sessions makes no distinction between packets with or without MIPv6 extensions. An incoming packet with a source address (i.e. the address of the HA) different from the address used for packet filtering (i.e. the IP address of the CN) will fail to find a matching UMTS session and may be discarded. This has some serious implications. For example, a live IMS session between two IPv6 nodes will be broken when any one of them leaves its home network, moves into GPRS/UMTS and start using MIPv6. A mechanism that reads inner header of the tunnelling packet may not work. For example, the gateway node fails to read the payload of the tunnelling packet due to the possible encryption, e.g. IPSec ESP. 4.1.2 The Case of Route Optimisation when the CN is mobile When Route Optimisation is used, the packets are sent directly from the CN to the MN with the source address being the address of Xiaobao Chen et al Expires 17 December 2003 [Page 3] INTERNET-DRAFT MIPv6 Interworking with Packet Filtering the CN. When the CN is a mobile node itself and attached to a foreign network, the source address of the packets sent from CN will be its Care-of Address (CoA). When packet filtering is based on the original source address of the CN, i.e. its home address, packets sent from the CN will be discarded by the gateway node. A typical example is the case when the GSSN uses ingress filtering for selecting the UMTS sessions.Although the packet sent from the mobile CN to the MN has the "Home Address Destination Option" containing its Home address[1], a gateway node as an intermediate node operating standard IPv6 does not read it. This will have some serious implications such as the disruption of existing live sessions. 4.2 Destination Address based Egress Filtering For packets sent directly from the CN to the MN that is attached to a foreign network, the destination address will be the CoA of the MN. The gateway node such as the GGSN in the GPRS/UMTS networks that is not mobile IP aware will still use the original destination IP address, i.e. the home address of the MN to perform the Egress Filtering. Section 3.2.2 describes the egress filtering using the Service- based Local Policy Decision provided by the Policy Control Function that operates independently from mobile ip based mobility control. When an IPv6 node in the GPRS/UMTS network is to initiate or having a IMS session with a MN that is away from its home network, the packets sent from CN directly to the MN using MIPv6 compliant header will fail to pass through the SBLP based packet filtering. Although the packet sent from the CN to the MN has the Routing Header Type 2 in its option headers field[1], a standard IPv6 operating gateway node as an intermediate node does not read this header. 5. Requirements on Inter-working Mobile IPv6 with Packet Filtering The following requirements are recommended for a gateway node that performs source address and/or destination address based packet filtering: * A gateway node running standard IPv6 should not be required to change to support packet filtering function. * The policy control functions for packet filtering such as the PCF should not be aware of the mobility control based on mobile IP. 6. A Recommended Practice A simple solution to the above inter-working problem with MIPv6 and packet filtering is to enable the gateway node to access the required information to perform the packet filtering while in the meantime the operations on packets in the gateway node should comply with standard IPv6 specifications. According to standard IPv6,the Hop-by-Hop Options Header, is accessible to intermediate Xiaobao Chen et al Expires 17 December 2003 [Page 4] INTERNET-DRAFT MIPv6 Interworking with Packet Filtering IPv6 nodes between the source and the destination.The Hop-by-Hop Options Header carries information that intermediate nodes between a source and destination needs to know. Every node along a packet's path examines the Hop-by-Hop options header for the required information. 6.1 MIPv6 Interworking with Source IP Address based Ingress Filtering The following recommended practice will enable the gateway node, such as the GGSN in GPRS/UMTS networks, to perform source address based Ingress Filtering because a standard IPv6 gateway node, as an intermediate node, is able to access the information contained in the Hop-by-Hop Options Field. 6.1.1 The Recommended Practice in case of HA Tunnelling For a CN communicating to its MN using HA tunnelling, the HA should insert original IP address of the CN in the Hop-by-Hop Options Header in the outer IP header of the tunnelling packet. In the case when the CN is a mobile node itself and away from its home network, the CN may need to insert its Home IP address in the Hop-by-Hop Options Field for packets sent to the MN's Home IP address. The HA, as an intermediate IPv6 node, will read the Hop-by-Hop Options Field and access the information and then put the original IP address (the Home IP address) of the (mobile) MN in the Hop-by-Hop Options Header in the outer header of the tunnelling packets. 6.1.2 The Recommended Practice in case of Route Optimisation For a CN communicating to a MN using route optimisation to send packets directly to the MN, the CN should insert its IP address in the Hop-by-Hop Options Header. In the case where the CN is a mobile itself and away from its network, the CN should insert its Home IP address in the Options filed in the Hop-by-Hop Options Header. 6.2 MIPv6 Interworking with Destination IP Address based Egress Filtering For a CN communicating to a MN using Route Optimisation to send packets directly to the MN, the CN should insert the Home IP Address of the MN in the Hop-by-Hop Options Header using standard IPv6 operations. The above recommended practice will enable the gateway node, such as the GGSN in GPRS/UMTS network, to perform destination address based Egress Filtering such as SBLP because a standard IPv6 gateway node, as an intermediate node, is able to access the information in the Hopy-by-Hop Options Field using standard IPv6 operations. Xiaobao Chen et al Expires 17 December 2003 [Page 5] INTERNET-DRAFT MIPv6 Interworking with Packet Filtering 6.3 MIPv6 Interworking with Source and Destination IP Address based Packet Filtering It is likely that a packet sent from the HA or the CN to the MN may need to pass through Egress Filtering (for packets leaving the network where the CN or the HA is located) as well as Ingress Filtering (for packets coming into the network where the MN is located). Both the gateway node performing the Egress Filtering and the one performing Ingress Filtering will need to acquire the necessary information to perform the filtering function. It is recommended that the CN and HA (in the case when the HA tunneling is used) should insert the both the IP address of the CN and the Home IP address of the MN in the Options Field of Hop-by-Hop Options Header. The CN's IP Address is placed before the MN's IP Address. The above recommended operation is applied only to the outer IP header of the packet when HA tunnelling is used. The gateway node that performs the packet filtering will read the data in the first 16 octets of the option field as the source IP Address and the data in the following 16 octets of the option field as the destination IP address. 7. Security Considerations 7.1 Ingress Filtering It may well be likely that a malicious node launches attacks against the MN by spoofing the Original Source IP Address (the legitimate CN) or/and the Original Destination Address (the Home IP Address of the MN) in its Hop-by-Hop Options Field to pass the gateways that performs ingress packet filtering. The recommended practice to tackle this problem is using the Ingress Packet Filtering described in RFC2827[2]. The Ingress gateway checks if the packet has the topologically correct source IP address representing a legitimate CN or HA in the network from which the packet comes from. 7.2 Egress Filtering A potential risk may arise for operators running IMS with SBLP when the GGSN checks the Hop-by-Hop Options Header for the destination address (Sections 4.2, 6.2). After initial successful IMS SBLP authorisation, a CN attached to a GPRS/UMTS network may insert the address of an unauthorised destination (e.g. sites barred by the operator) in the IPv6 basic header while it inserts the authorised MN's home address in the Hop-by-Hop Options Field. This will enable the packets to pass the SBLP based packet filtering at the GGSN to reach un-authorised destinations. To tackle this potential risk, the GGSN should associate the current destination address of the MN, i.e. its CoA, with the original destination address, i.e. the MN's home address of the MN that is authorised by the IMS SBLP. The following approach may be used by GGSN to establish such an association. A MN attached to a foreign network may send a Binding Update Xiaobao Chen et al Expires 17 December 2003 [Page 6] INTERNET-DRAFT MIPv6 Interworking with Packet Filtering message [1] to the CN attached to the GPRS/UMTS network. The binding update message using the MN's CoA as the Source Address may therefore be blocked by the GGSN's TFT packet filtering function. Instead of blocking the packet, the GGSN may also need to check if the packet carries the Binding Update Message by looking at the MH Type Value. If it is "5"[1], the GGSN recognises that it is a binding update message and record the Source Address of the binding update message as the current address of the MN. To guarantee that the recorded address obtained from the Binding Update Message is the MN's current address, the GGSN may need to wait until a Binding Acknowledgement Message is sent from the CN withe MH Type Value "6". The GGSN will establish an association between the MN's current address (CoA) to be used by the CN in IPv6 basic header and the MN's Home Address in the Hop-by-Hop Options Field for sending packets to the MN. For a secure SBLP operation, the GGSN will check both the destination address in the IPv6 basic header and the Hop-by-Hop Options Field in the IPv6 extension headers. Those packets found with destination address unmatching the association with the MN's Home Address will be blocked by the GGSN. 8. Acknowledgment The authors would like to thank Phil Roberts and James Kemp for their valuable comments and feedbacks on the issues. Acknowledgements are made to Paul Reynolds, Ric Bailey, Ronan Le Bras, Graham Fisher, Stuart Shutt, Steve Blythe and Rob Allan for their constant and valuable support for the work. 9. References [1] D. Johnson, C. Parkins. J. Arkko. "Mobility Support in IPv6", Internet Draft, Internet Engineering Task Force, May 26, 2003 [2] P. Ferguson, D. Senie. "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. RFC2827, BCP38 Internet Engineering Task Force, May 2002 [3] F. Baker. "Requirements for IP Version 4 Routers", RFC1812, June 1995. Xiaobao Chen et al Expires 17 December 2003 [Page 7] NTERNET-DRAFT MIPv6 Interworking with Packet Filtering [4] 3GPP TS23.060, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Services (GPRS); Service Description; Stage 2 (Release 1999)". [5] 3GPP TS23.008, "3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile Radio Interface Layer 3 Specifications; Core Network Protocols - Stage 3 (Release 1999)". [6] 3GPP TS23.228, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; (Release 5)". [7] 3GPP TS23.207, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects;End-to-End QoS Concept and Architecture (Release 5)". [8] 3GPP TS29.207, "3rd Generation Partnership Project; Technical Specification Group Core Network; Policy Control over Go Interface (Release 5)". 9 Authors' Addresses Xiaobao Chen Orange PCS Ltd. Keypoint St. James Court, Almondsbury Park Bradley Stoke, Bristol, BS32 4QJ UK Phone: +0044 (0)7989 477 679 EMail: xiaobao.chen@orange.co.uk Martin Harris Orange PCS Ltd. Keypoint St. James Court, Almondsbury Park Bradley Stoke, Bristol BS32 4QJ UK Phone: +0044 (0)7974 365 080 EMail: martin.harris@orange.co.uk Nick Sampson Orange PCS Ltd. Keypoint St. James Court,Almondsbury Park Bradley Stoke, Bristol BS32 4QJ UK Phone: +0044 (0)7973 963 519 EMail: nick.sampson@orange.co.uk