Mobopts Working Group F. Bao Internet-Draft Y. Qiu Expires: April 15, 2007 J.Y. Zhou Network Working Group October 16, 2006 Solution of MIPv6 Friendly Firewall Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 obsoleted 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. This Internet-Draft will expire on April 15, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Qiu, et al. Expires April 15, 2006 [Page 1] Internet-Draft MIP6 location privacy solutions June 2006 Abstract The mobile communication becomes the mainstream because more and more mobile devices, such as mobile phones, personal digital assistants, notebooks, etc., are used to access the Internet. In order to be reachable, the mobile devices need frequently change their communication IP addresses in mobile IPv6 network according to its current attached domain. However, the conventional firewalls are primarily based on IPv4 network where the security criteria are specified only to the fixed IP addresses or subnets. The goal of the document is to solve the conflict and propose some approaches to make the firewall friendly in mobile IPv6 network. Table of Contents ¡¡ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3. Brief Overview of Location Privacy in MIP6 . . . . . . . . . 6 4. Location Privacy Using Return Routability Signaling . . . . 7 5. IP Address Location Privacy with Pseudo Home Address . . . . 10 5.1. Pseudo Home Address Generation . . . . . . . . . . . . . . 10 5.2. Home Binding Updates and Acknowledgements . . . . . . . . 12 6. Profiling Attack . . . . . . . . . . . . . . . . . . . . . . 25 7. Security Consideration . . . . . . . . . . . . . . . . . . . . 8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30 10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 31 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 31 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . .. . . . . . . . . . . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . . . 34 Qiu, et al. Expires April 15, 2006 [Page 2] Internet-Draft MIP6 location privacy solutions June 2006 1. INTRODUCTION Firewalls are frequently used to prevent unauthorized Internet users from accessing private networks connected to the Internet, especially intranets. All messages entering or leaving the intranet pass through the firewall, which examines each message and blocks those that do not meet the specified security criteria. In most cases, the security criteria are specified only to the fixed IP addresses or subnets. On the other hand, along with the increasing number of 3G networks and WiFi hotspots, people can now easily gain access to the Internet anywhere using their mobile devices, such as mobile phones, personal digital assistants (PDA) and laptop computers. Mobile IPv6 [1] enables IP mobility for IPv6 nodes. It allows a mobile IPv6 node to be reachable via its home IPv6 address irrespective of any link that the mobile attaches to. The Route Optimization is also supported in the mobile IPv6 specification. The Route Optimization technology enables optimized routing of packets between a mobile node and its correspondent nodes. Therefore the conflict rises: the firewalls need a series of fixed IP addresses or subnets to specify the security criteria, meanwhile the roaming mobile nodes need variable IP addresses to indicate the current location so that the mobile nodes can be reached seamlessly. This document analyzes the mobile IPv6 specification and the firewall technology, and then presents in detail on building a MIPv6 friendly firewall in mobile IPv6 environment. The rest of this document is organized as follows. Section 3 reviews the basic operation of Mobile IPv6 and firewall. Section 4 presents our solution for configuring the firewall rules in mobile IPv6 network. Section 5 is the analysis of security and performance. Section 6 concludes the document. 2. Terminology Throughout this document we use the commonly adopted terminology defined in [1] and [2]. The keywords "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. The other notations used throughout this document are listed below for ease of reference: Qiu, et al. Expires April 15, 2006 [Page 3] Internet-Draft MIP6 location privacy solutions June 2006 h( ): a one-way hash function, such as SHA1 [11]. prf(k, m): a keyed pseudo random function - often a keyed hash function [12]. It accepts a secret key k and a message m, and generates a pseudo random output. This function is used for both message authentication and cryptographic key derivations. ESP( ): IPsec ESP encapsulation. It could be either in transport mode or in tunneling mode [13]. m|n: concatenation of two messages m and n. 3. Mobile IPv6 and Firewall 3.1 Mobility Support in IPv6 In the current IETF Mobile IPv6 specifications [1], every mobile node (MN) has a home address (HoA), an IP address assigned to a mobile node within its home subnet. A MN is always addressable by its home address, whether it is currently attached to its home subnet or is away from home. While a mobile node roams and attaches to some foreign subnet, it is also addressable by one or more care-of addresses (CoAs), in addition to its home address. A care-of address is an IP address associated with a mobile node while visiting a particular foreign subnet. The subnet prefix of the mobile node¡¯s care-of address is the subnet prefix of the foreign subnet being visited by the node. A mobile node typically acquires its CoA through stateless [3] or stateful (eg., DHCPv6 [4]) address autoconfiguration. After getting a new CoA on the foreign subnet, a mobile node informs its current CoA to its home agent (HA) [1,5] by sending a Home Binding Update message to the home agent: BU_HA = {Src=CoA, Dst=HA, Opt=HoA, ESP(Seq#, Lifetime, ... ... )}. The home binding update message creates an association between HoA and CoA for the mobile node with the specified lifetime at the home agent. HA thereafter uses proxy Neighbor Discovery [6] to intercept any IPv6 packets addressed to MN¡¯s HoA on the home subnet, and tunnels each intercepted packet to MN¡¯s CoA [1]. To tunnel intercepted packets, HA encapsulates the packets using IPv6 encapsulation, with the outer IPv6 header addressed to MN¡¯s CoA. The mobile node may also initiates route optimization operation with its correspondent node (CN) to inform its current CoA by sending a Correspondent Binding Update message to the correspondent nodes. Qiu, et al. Expires April 15, 2006 [Page 4] Internet-Draft MIP6 location privacy solutions June 2006 When MN wants to perform route optimization, it sends HoTI = {Src=HoA, Dst=CN, rH} and CoTI = {Src=CoA, Dst=CN, rC}. to CN. HoTI tells MN¡¯s home address HoA to CN. It is reverse tunneled through the home agent HA, while CoTI informs MN¡¯s care-of address CoA and is sent directly to CN. When CN receives HoTI, it takes the source IP address of HoTI as input and generates a home cookie C_H and replies MN with HoT = {Src=CN, Dst=HoA, rH, C_H, j}, Similarly, when CN receives CoTI, it takes the source IP address of CoTI as input and generates a care-of cookie C_C and sends CoT ={Src=CN, Dst=CoA, rC, C_C, i} to MN. Note that HoT is sent via MN¡¯s home agent HA while CoT is delivered directly to MN. When MN receives both HoT and CoT, it hashes together the two cookies to form a session key k_BU, which is then used to authenticate the correspondent binding update message to CN: BU_CN = {Src=CoA, Dst=CN, HoA, Seq#, i, j, MACBU}, Note that CN is stateless until it receives BUCN and verifies MACBU. If MAC_BU is verified positive, CN may reply with a binding acknowledgement message BA_CN = {CN, CoA, HoA, Seq#, MACBA}, CN then creates a binding cache entry for the mobile node MN. The binding cache entry binds HoA with CoA which allows future packets to MN be sent to CoA directly. When sending a packet to the mobile node, the correspondent node checks its cached bindings for an entry for the packet¡¯s destination address. If a cached binding for this destination address is found, the node uses an IPv6 Routing Header [7] to route the packet to the mobile node by way of the CoA indicated in this binding. If, instead, the correspondent node has no cached binding for this destination address, the node sends the packet normally (i.e., to the mobile node¡¯s home address with no routing header), and the packet is subsequently intercepted and tunneled to the mobile node by its home Qiu, et al. Expires April 15, 2006 [Page 5] Internet-Draft MIP6 location privacy solutions June 2006 agent as described above. Therefore, route optimization allows a correspondent node to communicate directly with the mobile node, avoiding delivering traffic via the mobile node¡¯s home agent. From the above brief review, we observed that the source/ destination addresses in the packets from/to mobile nodes are not fixed. 3.2 Problem Statement of Mobile IPv6 and Firewall However, firewalls usually decide whether to allow the traffic or to drop the packets based on source IP address and destination address as well as protocol type and port numbers. RFC4487 [2] analyzed various scenarios involving MIP6 and firewalls. It classified three scenarios of firewall networks: 1) When the correspondent node is within a network protected by firewall(s), the major issue is how the firewall accepts the packets from/to the address CoA, which has no associated rule with the diverse CoA in the firewall. Requiring the firewalls to update the connection state upon detecting Binding Update messages from a node outside the network protected by the firewall does not appear feasible or desirable, because changing the firewall states without verifying the validity of the Binding Update messages could lead to denial of service attacks. 2) When the home agent is within a network protected by a firewall(s), the firewall(s) may drop connection setup requests from CNs and packets from MNs¡¯ CoAs if the firewall(s) protecting the home agent block unsolicited incoming traffic (e.g., as stateful inspection packet filters do). 3) When a mobile node is within or moves from outside into a network protected by firewall(s), the firewall blocks the traffic to the mobile node due to the new CoA of mobile nodes. 3.3 IPv6 Address Generation An interface which uses IPv6 usually gets link-local address and global address allocated at least. Link-local address is used for control functions, while global address is used for usual data communications. In mobile IPv6, IP address is usually generated by the following three methods: Stateless Address Autoconfiguration, Stateful Address Autoconfiguration & Manual Configuration. Qiu, et al. Expires April 15, 2006 [Page 6] Internet-Draft MIP6 location privacy solutions June 2006 3.3.1 Stateless Address Autoconfiguration [3]: Address autoconfiguration in IPv6 usually means that a node can configure its own IP address, using information on the network. In IPv6, 128 bit IP address is separated to two parts: i) network prefix (64 bits), which identifies network; and ii) interface ID (64 bits), which identifies a node (interface). Interface ID is configured by the node on its own (usually derived from the MAC address), and prefix is notified by the network (usually router). These two parts are combined to form an IPv6 address. The following is the actual procedure for IPv6 stateless address autoconfiguration: 1) The new node on the network generates link-local address and allocates it to the interface. Link-local address takes the following form: local prefix (fe80:0000:0000:0000) + Interface ID (xxxx:xxff:fexx:xxxx). 2) The node confirms that generated link-local address is not already used on the same network (DAD: Duplicate Address Detection). At first, the node transmits Neighbor Solicitation (NS) message on the network. If another node is already using the same address, this node sends Neighbor Advertisement (NA) message. The new node that transmitted NS message will use the original link-local address if it receives no NA message after a certain time. If the new node is notified of the duplicate address situation, it will not allocate the link-local address and terminates the interface. 3) The new node sends Router Solicitation (RS) message on the network to request information, using the link-local address just allocated. RS message transmission is not a must. The node can passively wait for (4). 4) The node that received RS message (usually a router) sends back Router Advertisement (RA) message. RA message is transmitted periodically, so nodes do not necessarily have to send RS message. 5) The node receives RA and gets IPv6 address prefix. 6) The node forms the global IPv6 address by combining prefix and interface ID, just as it did for link-local address. Qiu, et al. Expires April 15, 2006 [Page 7] Internet-Draft MIP6 location privacy solutions June 2006 3.3.2 Stateful Address Autoconfiguration: Stateful Address Autoconfiguration uses a server, such as DHCPv6 [4], to manage and allocate address to nodes. With DHCPv6, DHCP servers are placed on the network to allocate addresses with the following procedure: 1) A node sends DHCP_DISCOVER, and finds a DHCP server. 2) DHCP server receives DHCP_DISCOVER and returns DHCP_OFFER. 3) The node receives DHCP_OFFER and sends DHCP_ REQUEST 4) DHCP server receives DHCP_REQUEST and returns DHCP_ACK. 5) The node receives DHCP_ACK and configures its interface. Note that the DHCP server manages address information and maintains which address is allocated to whom. In address allocation with DHCP, a node can use only one DHCP server (although there may be multiple DHCP servers on the same network). Therefore, only one IP address is allocated to the interface of a node. 3.3.3 Manual Configuration It means to set IP address to an interface manually. This also includes setting pre-configured address based on a config- uration file at the boot. 4. Deploying Firewall in Mobile IPv6 4.1 Traceable IP address and Untraceable IP address From the brief description in subsection 3.C, we know the IP address generated by the method of stateless address autoconfiguration is traceable, because its low 64 bits is fixed even though its prefix depends on the router. Contrastively, the IP address got by the method of stateful address auto- configuration is untraceable because there is no association between the previous and subsequent addresses of an interface if it attaches different routers. Qiu, et al. Expires April 15, 2006 [Page 8] Internet-Draft MIP6 location privacy solutions June 2006 DEFINITION: TRACEABLE ADDRESS: If the series of IP addresses for an interface are derived from certain data (e.g. MAC address), no matter it is generated by manual configuration or stateless autoconfiguration, we call the IP addresses are traceable. UNTRACEABLE ADDRESS: If the series of IP addresses for an interface are not derived from certain data, no matter it is generated by manual configuration or stateful auto- configuration or other stateless autoconfiguration [8, 9], we call the IP addresses are untraceable. In the following subsections, we will discuss how to configure and deploy the firewall in a variety of scenarios. We will focus on how to manage the variation of MN¡¯s IP address. Other firewall filtering issues, such as protocol type, port number, etc., will be ignored because they are not changed along with the locations of mobile nodes and can be set in advance. 4.2 Scenario of the CN Protected by Firewall(s) 4.2.1 Firewall Configuration if MN¡¯s CoA is Traceable Address The disadvantage of IPv4 is that its address is only 32 bits meanwhile the MAC address is 48 bits. Therefore the IPv4 address is not able to include the MAC address information. If a mobile node roams to foreign networks, its new IPv4 address is totally different from its previous IPv4 address and we are not able to trace back any information of its previous address from its new address. In IPv6, if a mobile node¡¯s IPv6 address is generated by the stateless address autoconfiguration, the IPv6 address always contains the interface identity (derived from the unique MAC address). Hence, if two IPv6 addresses share the same 64-bit interface identity, we thought that they are the same device. Therefore, the firewall rules for a mobile node could mask the low 64-bits of the IPv6 address. For example, if a mobile node¡¯s home address (HoA) is y:y:y:y:xxxx:xxff:fexx:xxxx. Its care-of address in the network A would be a:a:a:a:xxxx:xxff: fexx:xxxx and its IPv6 address in network B would be b:b:b:b: xxxx:xxff:fexx:xxxx, we could set the firewall rules for the mobile node with mask 0::ffff:ffff:ffff:ffff Qiu, et al. Expires April 15, 2006 [Page 9] Internet-Draft MIP6 location privacy solutions June 2006 ip6tables -A FORWARD -s y:y:y:y:xxxx:xxff:fexx:xxxx /0::ffff:ffff:ffff:ffff -d address_of_CN -p 135 -j ACCEPT ip6tables -A OUTPUT -d y:y:y:y:xxxx:xxff:fexx:xxxx /0::ffff:ffff:ffff:ffff -s address_of_CN -p 135 -j ACCEPT where -p 135 specifies the protocol of Mobility Header. In subsection 3.1, we described the messages/packets between mobile node and its correspondence node. Now we analyze each messes/packet going through the firewall. After masking by 0::ffff:ffff:ffff:ffff, the address of MN¡¯s HoA becomes xxxx:xxff:fexx:xxxx in the firewall rules. The HoTI message: its source address is y:y:y:y:xxxx:xxff: fexx:xxxx and destination address is address_of_CN. After masking by 0::ffff:ffff:ffff:ffff in firewall, the source address become xxxx:xxff:fexx:xxxx, then the HoTI message meets the firewall rules and passes the firewall. The HoT message: its destination address is y:y:y:y:xxxx: xxff:fexx:xxxx and source address is address_of_CN. After masking by 0::ffff:ffff:ffff:ffff in firewall, the destination address become xxxx:xxff:fexx:xxxx, then the HoT message meets the firewall rules and passes the firewall. The CoTI message: its source address is a:a:a:a:xxxx:xxff: fexx:xxxx and destination address is address_of_CN. After masking by 0::ffff:ffff:ffff:ffff in firewall, the source address become xxxx:xxff:fexx:xxxx, then the CoTI message meets the firewall rules and passes the firewall. The CoT message: its destination address is a:a:a:a:xxxx: xxff:fexx:xxxx and source address is address_of_CN. After masking by 0::ffff:ffff:ffff:ffff in firewall, the destination address become xxxx:xxff:fexx:xxxx, then the CoT message meets the firewall rules and passes the firewall. The BUCN message: its source address is a:a:a:a:xxxx: xxff:fexx:xxxx and destination address is address_of_CN. After masking by 0::ffff:ffff:ffff:ffff in firewall, the source address become xxxx:xxff:fexx:xxxx, then the BUCN message meets the firewall rules and passes the firewall. Qiu, et al. Expires April 15, 2006 [Page 10] Internet-Draft MIP6 location privacy solutions June 2006 The BACN message: its destination address is a:a:a:a:xxxx: xxff:fexx:xxxx and source address is address_of_CN. After masking by 0::ffff:ffff:ffff:ffff in firewall, the destination address become xxxx:xxff:fexx:xxxx, then the BACN message meets the firewall rules and passes the firewall. From above analysis, we could summarize that the firewall, which protects the correspond node of mobile node, does not block the communication between the mobile node with traceable address and the correspondent nodes. However, the traceable addresses are not always available. The next subsection will discuss solution for mobile nodes with untraceable addresses. 4.2.2 Firewall Configuration if MN¡¯s CoA is UntraceableAddress If the mobile device is an Ethernet device, we could use the MAC feature in firewall to filter it: ip6tables -A FORWARD --mac-source xx:xx:xx:xx:xx:xx -d address_of_CN -j ACCEPT where, xx:xx:xx:xx:xx:xx is the MAC address of the mobile node. However, the filter feature for MAC source addresses only makes sense for packets coming from an Ethernet device. It is not suitable for the mobile devices that do not support Ethernet, such as mobile phone. Therefore, we have to come back IP layer. In the perspective of the correspondent node, the care-of address of mobile node is an untraceable address. It is not able to set up firewall rules based on the kind of addresses. Mobile IPv6 specification [1] introduces a new herder ¡°Type 2 Routing Header¡± which carries the home address of the mobile node. The new routing header uses a different type than defined for "regular" IPv6 source routing, enabling firewalls to apply different rules to source routed packets than to Mobile IPv6. Therefore, we suggest that the current firewalls extend a feature to filter the field of Home Address Option in the mobility header as well as the field Type 2 Routing Header. With the new feature, the firewall rules for the mobile node, which home address is y:y:y:y:xxxx:xxff:fexx:xxxx and its current care-of address is a:a:a:a:xxxx:xxff:fexx:xxxx, looks like ip6tables -A FORWARD -s y:y:y:y:xxxx:xxff:fexx:xxxx -d address_of_CN -j ACCEPT Qiu, et al. Expires April 15, 2006 [Page 11] Internet-Draft MIP6 location privacy solutions June 2006 ip6tables -A OUTPUT -d y:y:y:y:xxxx:xxff:fexx:xxxx -s address_of_CN -j ACCEPT and ip6tables -A FORWARD --home-address y:y:y:y:xxxx:xxff:fexx:xxxx -p 135 -j ACCEPT where -p 135 specifies the protocol of Mobility Header. Accordingly, we proposed an improved Return Routability (RR) procedure [10] in which the message of HoTI, HoT, CoTI and CoT bundles HoA and CoA together instead of HoA or CoA alone in the original RR procedure. (The analysis in [10] indicated that binding HoA and CoA together makes the original RR protocol much stronger.) Now let¡¯s look every message in the improved RR procedure: The HoTI message: its source address is y:y:y:y:x:xxxx: xxff:fexx:xxxx and destination address is address_of_CN. The HoTI message meets the firewall rules and then passes the firewall. The HoT message: its destination address is y:y:y:y:xxxx: xxff:fexx:xxxx and source address is address_of_CN. The HoT message meets the firewall rules and then passes the firewall. The CoTI message: the message with source address a:a:a:a:xxxx:xxff:fexx:xxxx, destination address addressOfCN, home address y:y:y:y:xxxx:xxff:fexx:xxxx and mobility header protocol 135. The CoTI message meets the extended firewall rule and is also able to pass the firewall. The CoT message: the message with destination address a:a:a:a:xxxx:xxff:fexx:xxxx, source address address_of_CN, home address y:y:y:y:x:xxff:fexx:xxxx and mobility header protocol 135. The CoT message meets the extended firewall rule and is also able to pass the firewall. The BUCN message: the message with source address a:a:a:a:xxxx:xxff:fexx:xxxx and destination address address_of_CN, home address y:y:y:y:x:xxff:fexx:xxxx and mobility header protocol 135. The BUCN message meets the extended firewall rule and can pass the firewall. The BACN message: the message with destination address a:a:a:a:xxxx:xxff:fexx:xxxx, source address address_of_CN, home address y:y:y:y:x:xxff:fexx:xxxx and mobility header protocol 135. The BACN message meets the extended firewall rule and can pass the firewall. Qiu, et al. Expires April 15, 2006 [Page 12] Internet-Draft MIP6 location privacy solutions June 2006 Upon receiving the BUCN message, the correspondent node opens a dynamic pinhole for the address a:a:a:a:xxxx:xxff: fexx:xxxx so that following traffic packets from this address with any protocols can reach the correspondent node. After this modification, the firewall, which protects the correspond node of mobile node, will not block any more the communication between the mobile node with untraceable address and the correspondent nodes. Of course, the application of the solution is more general. It is certainly suitable for the mobile nodes with traceable addresses. Based on the same mechanism, the description of other scenarios is simple in the following subsections. 4.3 Scenario of the HA Protected by Firewall(s) In the specification of mobile IPv6 [1, 5], the following messages from the mobile node will send to/through its home agent: Home Binding Update BU_HA, Home Test Init HoTI and Home Test HoT. 4.3.1 Firewall Configuration if MN¡¯s CoA is Traceable Address If the care-of address of a mobile node is a traceable address and the mobile node¡¯s home address (HoA) is y:y:y:y:xxxx: xxff:fexx:xxxx as above subsection, then its care-of address in the network A would be a:a:a:a:xxxx:xxff:fexx:xxxx and its IP address in network B would be b:b:b:b:xxxx:xxff:fexx:xxxx. We could set the firewall rules for the mobile node with mask 0::ffff:ffff:ffff:ffff ip6tables -A FORWARD -s y:y:y:y:xxxx:xxff:fexx:xxxx/ 0::ffff:ffff:ffff:ffff -d address_of_HA -p 135 -j ACCEPT ip6tables -A OUTPUT -d y:y:y:y:xxxx:xxff:fexx:xxxx/ 0::ffff:ffff:ffff:ffff -s address_of_HA -p 135 -j ACCEPT After masking by 0::ffff:ffff:ffff:ffff, the address of MN¡¯s HoA becomes xxxx:xxff:fexx:xxxx in the firewall rules. Then the BU_HA message, its source address is a:a:a:a:xxxx: xxff:fexx:xxxx and the destination address is address_of_HA. After masking by 0::ffff:ffff:ffff:ffff in firewall, the source address become xxxx:xxff:fexx:xxxx, then the BUHA message meets the firewall rules and passes the firewall. Qiu, et al. Expires April 15, 2006 [Page 13] Internet-Draft MIP6 location privacy solutions June 2006 The BA_HA message: its destination address is a:a:a:a: xxxx:xxff:fexx:xxxx and source address is address_of_HA. After masking by 0::ffff:ffff:ffff:ffff in firewall, the destination address become xxxx:xxff:fexx:xxxx, then the BAHA message meets the firewall rules and passes the firewall. The HoTI message: According to RFC 3776 [5], the HoTI message is encapsulated by ESP tunneling mode in the MN-HA path, so its source address of the message is the care-of address a:a:a:a:xxxx:xxff:fexx:xxxx and destination address is address_of_HA. After masking by 0::ffff:ffff:ffff:ffff in firewall, the source address become xxxx:xxff:fexx:xxxx, then the HoTI message meets the firewall rules and reach the home agent. The HoT message: Due to encapsulated by ESP tunneling mode, its destination address of the message is also the care-of address a:a:a:a:xxxx:xxff:fexx:xxxx and source address is address_of_CN. After masking by 0::ffff:ffff:ffff:ffff in firewall, the destination address become xxxx:xxff:fexx:xxxx, then the HoT message meets the firewall rules and passes the firewall. From above analysis, we could summarize that the firewall, which protect the home agent of mobile node, does not block the communication between the mobile node with traceable address and the home agent. 4.3.2 Firewall Configuration if MN¡¯s CoA is UntraceableAddress If the mobile device is an Ethernet device, we could use the MAC feature in firewall to filter it: ip6tables -A FORWARD --mac-source xx:xx:xx:xx:xx:xx -d address_of_HA -j ACCEPT where, xx:xx:xx:xx:xx:xx is the MAC address of the mobile node. For general purpose, we propose a firewall configuration based on the improved RR protocol and extended firewall described above. ip6tables -A FORWARD -s y:y:y:y:xxxx:xxff:fexx:xxxx -d address_of_HA -j ACCEPT ip6tables -A OUTPUT -s address_of_HA -d y:y:y:y:xxxx:xxff:fexx:xxxx -j ACCEPT and ip6tables -A FORWARD --home-address y:y:y:y:xxxx:xxff:fexx:xxxx -p 135 -j ACCEPT Qiu, et al. Expires April 15, 2006 [Page 14] Internet-Draft MIP6 location privacy solutions June 2006 where -p 135 specifies the protocol of Mobility Header. Now let¡¯s look every message in the improved RR procedure in which the HoA and CoA are bundled together: The BU_HA message: the message with source address a:a:a:a:xxxx:xxff:fexx:xxxx and destination address address_of_HA, home address y:y:y:y:x:xxff:fexx:xxxx and mobility header protocol 135. The BUCN message meets the extended firewall rule and can pass the firewall. The BA_HA message: the message with destination address a:a:a:a:xxxx:xxff:fexx:xxxx, source address address_of_HA, home address y:y:y:y:x:xxff:fexx:xxxx and mobility header protocol 135. The BAHA message meets the extended firewall rule and can pass the firewall. Upon receiving the BUHA message, the home agent opens a dynamic pinhole and sets up a security tunnel for the address a:a:a:a:xxxx:xxff:fexx:xxxx so that following traffic packets from this address with any protocols can reach the home agent. Thereafter, the encapsulated HoTI and HoT can pass through the firewall. 4.4 Scenario of the MN Protected by Firewall(s) In the specification of mobile IPv6 [1, 5], the mobile node will send/receive following messages: BUHA, BAHA, HoTI, HoT, CoTI, CoT, BUCN and BACN. No matter whether a mobile node roams into a visiting network or already stays in the visiting network, after allocated or authorized a care-of address, it informs its current care-of address to its home agent and correspondent nodes. Since the mobile node is always the initiator, it is able to apply the pinholes from the firewall for the communications with other parties. The procedure of the home binding update is: 1) the mobile node gets current care-of address; 2) the mobile node solicits a firewall pinhole for the communications between the care-of address and its home agent (a fixed address) with the protocol number 50 (ESP) and 135 (Mobility Header); 3) the mobile node sends the home binding update message BUHA to its home agent through the pinhole; Qiu, et al. Expires April 15, 2006 [Page 1] Internet-Draft MIP6 location privacy solutions June 2006 4) the home agent sends back a acknowledgement BAHA through the pinholes and set up security tunnel between the home agent and its home agent; 5) thereafter every packet between the mobile node and its home agent goes through the security tunnel. The procedure of the correspondent binding update is: 1) the mobile node sends the HoTI message to its home agent through the security tunnel; 2) after receiving the HoT message from the correspondent node, the home agent forwards the HoT message to the mobile node through the security tunnel, too; 3) the mobile node solicits a firewall pinhole with protocol number 135 for the communications between the care-of address and the correspondent node; 4) the mobile node sends the CoTI message to its correspondent node through the pinhole; 5) the correspondent node sends back the CoT message through the pinhole; 6) the mobile send the binding update message BUCN to its correspondent node through the pinhole; 7) the correspondent node sends back a acknowledgement BACN through the pinholes; 8) the mobile node requires to open more ports for the pinhole; 9) thereafter every packet between the mobile node and its correspondent node goes through the pinhole. 5. Security Considerations and Performance Analysis In order to make the firewall suitable for mobile IPv6 network, the document proposed three methods: filtering MAC address, masking low 64 bits of source address and extending the firewall functions. 1) Method of filtering MAC address: Since the method just employs the feature of the ordinary firewalls, it does not bring any further security issue. However, its application scope is limited due to the restriction of Ethernet devices. Qiu, et al. Expires April 15, 2006 [Page 1] Internet-Draft MIP6 location privacy solutions June 2006 2) Method of masking low 64 bits: As the method ignores the address prefix, it abnegates to detect the source location of the packets. This brings the threat of address spoofing because the firewall is opened to all nodes if they have the same interface identity, no matter where these nodes are. In order to reduce the risk, the protocol option is switch on to filter the mobility header (135). As the messages with mobility header are very small in term of size and need a little processing, it would not bring a serious threat. The method does not introduce any new fields and operations. Hence its performance is the same as the ordinary firewall. The application scope is also restricted due to the requirement of traceable addresses. 3) Method of extending the firewall function: In mobile IPv6 network, the CoA in the source address field of binding update message is no sense to the firewall rules, an identity field is required so that the firewall recognizes the packets¡¯ owner. The method extends the ordinary ip6tables¡¯ features to filter the home address in the home address option header or in typing 2 routing header. The improved RR protocol [10] is also needed as the CoTI/CoT messages in original RR protocol do not contain the home address information. The improved RR protocol provides much stronger security than the original RR protocol. It can prevent three redirect attacks: Session Hijacking Attacks, movement Halting Attacks and Traffic Permutation Attacks. This protocol just bundles HoA and CoA together in the messages of HoTI, HoT, CoTI and CoT, and does not change the original RR¡¯s architecture. The concern of performance by the modification is minor because the architecture and operation are the similar as the original one. 6. Conclusion We first reviewed the mechanism of mobile IPv6 networking and analyzed the exchanging messages among the mobile nodes, home agents and correspondent nodes. Then we proposed three potential solutions to make the firewall friendly in mobile IPv6 network. For Ethernet devices, we suggested to employ the feature of MAC address filter. Qiu, et al. Expires April 15, 2006 [Page 1] Internet-Draft MIP6 location privacy solutions June 2006 For the mobile nodes with traceable addresses, masking the low 64-bits of source address is a simple and efficient solution. For general mobile nodes, we introduced an extended firewall and the improved Return Routability protocol. The extended firewall could always monitor the home addresses of mobile nodes as well as the care-of addresses. It also improved the security capability of the original RR protocol without changing its architecture. References [1] D. Johnson, C. Perkins, and J. Arkko, ¡°Mobility Support in IPv6¡±, IETF RFC 3775, June 2004. [2] F. Le, S. Faccin, B. Patil and H. Tschofenig, ¡°Mobile IPv6 and Firewalls: Problem Statement¡±, IETF RFC 4487, May 2006 [3] S. Thomson and T. Narten, ¡°IPv6 Stateless Address Autoconfiguration¡±, IETF RFC 2462, December 1998. [4] R. Droms, et al., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", IETF RFC 3315, July 2003. [5] J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", IETF RFC 3776, June 2004 [6] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for IP Version 6", IETF RFC 2461, December 1998 [7] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", IETF RFC 2460, December 1998 [8] T. Narten and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", IETF RFC 3041, January 2001 [9]T. Aura, "Cryptographically Generated Addresses (CGA)", IETF RFC 3972, March 2005 [10] Y. Qiu, J.Y. Zhou and R. Deng, "Security Analysis and Improvement of Return Routability Protocol", Secure Mobile Ad-hoc Networks and Sensors 2005, Lecture Notes in Computer Science, Volume 4074/2006, pp. 174-181, August 2006 [11]NIST, ¡°Secure Hash Standard¡±, NIST FIPS PUB 180, May 1993. [12] H. Krawczyk, M. Bellare, and R. Canetti, ¡°HMAC: Keyed-Hashing for Messaging Authentication¡±, IETF RFC 2104, February 1997. [13] S. Kent and R. Atkinson, ¡°IP Encapsulating Security Payload (ESP)¡±, IETF RFC 2406, November 1998. [14] Linux HOWTO: ip6tables Qiu, et al. Expires April 15, 2006 [Page 1] Internet-Draft MIP6 location privacy solutions June 2006 Authors' Addresses Ying Qiu Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65-6874-6742 Email: qiuying@i2r.a-star.edu.sg Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at Qiu, et al. Expires April 15, 2006 [Page 1] Internet-Draft MIP6 location privacy solutions June 2006 http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). ¡¡ ?? ?? ??