IETF Mobile IP Working Group Xiaobao Chen INTERNET-DRAFT Innovation Centre UK Orange PLC Martin Harris Innovation Centre UK Orange PLC Nick Sampson Innovation Centre UK Orange PLC 21 February 2003 MIPv6 Inter-working with Packet Filtering draft-chen-mobileip-packet-fitlering-xc-00.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 [Page i] INTERNET-DRAFT MIPv6 Interworking with Packet Filtering 24 Febuary,2003 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". The Packet filtering technology is used to distinguish and then control the access to network resources and services for protecting the network and the host(s) in question. 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 operational practices related to packet filtering by both ISP's and 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 [Page 1] INTERNET-DRAFT MIPv6 Interworking with Packet Filtering 24 February2003 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 MIPv6 on a wide-scale have been seen in the 3GPP community. The UMTS IMS services are IPv6 based and 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. As an example of packet filtering, two important packet filtering operations that take place at the gateway node in GPRS/UMTS networks, specifically at GGSN (GPRS Gateway Support Node), 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 filter 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 in order to deliver the packet to the mobile terminal. An incoming packet goes through the TFT-based packet filtering and finds a matching GPRS/UMTS session through which the packet is delivered to the mobile terminal. 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] has been by 3GPP defined to provide SIP-based IP multimedia services. It has been taken by 3G operators to be an essential feature in IMS that 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 [Page 2] INTERNET-DRAFT MIPv6 Interworking with Packet Filtering 24 February,2003 and the GPRS/UMTS network resources based on operator defined local policies. 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 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 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 GGSN makes no distinction between packets with or without MIPv6 extensions. The GGSN will use the IP address of the CN to decide if an incoming packet should be delivered to the MN using an existing UMTS session or discarded. 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 one node using MIPv6 moves into GPRS/UMTS. A mechanism that reads inner header of the tunnelling packet may not work when the gateway node fails to read the "payload" of the tunnelling packet due to the possible encryption on the payload such as those packets using 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 [Page 3] INTERNET-DRAFT MIPv6 Interworking with Packet Filtering 24 February,2003 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 disrupting 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 coming from the upper application layer that is unaware of mobile IP based mobility and therefore uses packet filtering information as if the MN is in its home network. 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 packet filter. 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 withPacket 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. * A gateway node performing packet filtering function should not be aware of the mobility control based on mobile IP. 6. A Recommended Practice As can be seen from the analysis in Section 4, the major issue for supporting traffic originated from IPv6 nodes operating Mobile IPv6 through packet filtering lies in the change of the source and/or destination addresses due to the movement of the mobile node while the packet filtering is controlled by upper layer applications that is unaware of mobile IP based mobility. Xiaobao Chen et al [Page 4] INTERNET-DRAFT MIPv6 Interworking with Packet Filtering 24 February,2003 A simple solution 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 shouldcomply with standard IPv6 specifications. According to standard IPv6,the Hop-by-Hop Options Header, is accessible to intermediate 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 Filed using standard IPv6 operations. Xiaobao Chen et al [Page 5] INTERNET-DRAFT MIPv6 Interworking with Packet Filtering 10 February, 2003 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 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 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. 8. Acknowledgment The authors would like to thank Phil Roberts and James Kemp for their valuable comments and feedbacks on the issues. Acknowledgements are be 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 in IPv6", Internet Draft, Internet Engineering Task Force, January 20, 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 [Page 6] NTERNET-DRAFT MIPv6 Interworking with Packet Filtering 10 February, 2003 [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 Innovation Centre UK Orange PLC 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 Innovation Centre UK Orange PLC 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 Innovation Centre UK Orange PLC Keypoint St. James Court,Almondsbury Park Bradley Stoke, Bristol BS32 4QJ UK Phone: +0044 (0)7973 963 519 EMail: nick.sampson@orange.co.uk