Network Working Group Feng BAO INTERNET-DRAFT Robert DENG Expires: September 14, 2005 Ying QIU Network Working Group Jianying ZHOU March 15, 2005 A Scheme of Mobile Firewall in Mobile IPv6 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC 2026. This document is an Internet-Draft. 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. Distribution of this memo is unlimited. ABSTRACT More and more activities rely on mobile devices. It is an important issue on how to protect mobile users engaged in mobile services. Unfortunately, the conventional firewalls are in appropriate for mobile network. Furthermore, with a conventional firewall, an administrator of mobile nodes is not able to monitor / control dynamically the mobile node's activities when the mobile node roams. In this draft, we introduce a new concept of mobile personal firewall and propose a concrete scheme that matches mobile environment and exploits mobile network facilities. Expires: September 14, 2005 [Page 1] Internet Draft Mobile Firewall March 15, 2005 When a mobile node (MN) roams into a foreign network managed by a mobility anchor point (MAP), the home agent (HA) will authorize the MAP to serve as a security proxy. The HA will negotiate with the MAP on the security association and then transfer to the MAP the defined security rules that will be applied on all communications to the MN. According to HMIPv6 protocol, all packets to MN will go through MAP. Therefore, the MAP has the ability of filtering packets. The MAP could also send the MN's traffic logs to the HA. The MN's administrator could dynamically monitor the MN's activities by retrieving the MN's traffic logs through the HA. If necessary, the MN's administrator could update the security rules so that the MN's activities could be controlled dynamically. All the operations are transparent to the MN, and the MN will be served in the way specified by its administrator no matter where it roams. Table of Contents 1. Introduction ................................................. 3 2. Location of Mobile Firewall .................................. 4 3. Security Tables .............................................. 5 4. Firewall Setup ............................................... 7 5. Communication Analysis ....................................... 9 6. Security Consideration ...................................... 11 7. Conclusion .................................................. 11 8. Acknowledgements ............................................ 11 9. References .................................................. 12 10. Authors' Addresses .......................................... 12 Intellectual Property and Copyright Statements .................. 13 Expires: September 14, 2005 [Page 2] Internet Draft Mobile Firewall March 15, 2005 1. INTRODUCTION More and more activities rely on mobile devices. It becomes an important issue on how to protect mobile users engaged in mobile services. Firewall is one of the security solutions. In this draft, we focus on the general gateway firewalls (i.e. the node is in a network and is protected by a firewall) and ignore the onboard firewalls. The latter is a slim version of conventional firewalls and must be installed in the individual mobile devices. In this draft, we introduce a new concept of mobile firewall to meet the requirement in mobile networks. A concrete scheme is proposed. The scheme is designed based on HMIPv6 protocol [1]. In the scheme, the Home Agent (HA) authorizes the Mobility Anchor Point (MAP) as the security proxy on behalf of the home agent when the mobile node (MN) visits the MAP subnet. After negotiating with the MAP about security association (SA) and shared keys, the HA transfers the defined security rules for the MN to the MAP. After receiving the security rules and the MN's binding update message, the MAP creates an entry for the MN that includes home address (HoA) as index, Regional Care-of-Address (RCoA), On-Link Care-of-Address (LCoA), security keys and the security rules, and adds it to the MAP's access control cache. When the MN leaves the MAP, the MAP can delete this entry from the access control cache. When a packet routes through the MAP to the MN, the MAP will retrieve the MN's entry and decide whether to forward or to drop the packet. Meanwhile, the MAP can send the MN's traffic logs to the HA at specified intervals. The administrators can monitor the MN's activities by reviewing the MN's traffic logs from a remote machine. If necessary, the administrators can modify the security policy stored in the HA for the MN, then the HA sends the updated security rules to the MAP. Afterwards, the MAP updates its access control cache automatically. The operation is transparent to the MN. The MN will be served in a way specified by it administrator no matter where it roams. Furthermore, before the MN could finally register with the MAP, the MAP should be authenticated by the HA. If the MAP is a denied router on the HA's access control list, the HA could inform the MN to choose another nearby MAP. Expires: September 14, 2005 [Page 3] Internet Draft Mobile Firewall March 15, 2005 2. LOCATION OF MOBILE FIREWALL In the HMIPv6 framework [1], the Mobility Anchor Point (MAP) is introduced. The MAP is a router located in a domain visited by mobile nodes. The MAP provides the localized mobility management for the visiting mobile nodes. Every MN bundles three addresses: home address (HoA), Regional Care-of-Address (RCoA), On-Link Care-of- Address (LCoA). If the MN sends the packets to its HA or CNs, the source address of the packets would be set to RCoA. On the contrary, when the MAP receives packets with the destination address RCoA from the CN or the HA, the MAP tunnels the packets to the related LCoA. The CNs and HA always connect to the MN with its RCoA. According to HMIPv6 framework, every packet from the CN to the MN will pass through the router MAP. Hence, in our scheme, the HA authorizes the MAP as the security proxy (firewall) on behalf of the HA when the MN visits the MAP subnet. Figure 1 shows the firewall location in HMIPv6 framework. +-------+ | HA | +-------+ +----+ | | CN | | +----+ | | +-------+-----+ | | +----------------|-----------------------+ | | RCoA | | Firewall +-------+ | | | MAP | | | +-------+ | | | | | | | +--------+ | | | | | | | | | | +-----+ +-----+ | | | AR1 | | AR2 | | Network | +-----+ +-----+ | Protected | LCoA1 LCoA2 | | | | +----+ | | | MN | | | +----+ ------------> | | Movement | | | +----------------------------------------+ Figure 1: Hierarchical Mobile IPv6 domain and the firewall location Expires: September 14, 2005 [Page 4] Internet Draft Mobile Firewall March 15, 2005 3. SECURITY TABLES In our scheme, 6 cache tables will be established. The HA holds 3 cache tables: a trusted MAP cache, a security rule cache and a security association cache for MAP. The MAP holds 2 cache tables: another security rule cache, and another security association cache for MN and HA. In addition, the MN holds the third security association cache for the MAP. Table 1: An entry in the trusted MAP cache MAP address Accepted / Denied The trust MAP cache indicates which MAP the mobile node can or cannot register with. If the MAP submitted by MN is not acceptable, the HA will inform MN to try other nearby MAPs. The trusted MAP cache is configured by the administrator of mobile nodes and kept in home agent. Table 2: The content of an entry in the security rule cache Local Address: MN's HoA (at HA) / MN's RCoA (at MAP) Remote Address: CN's address Action: Accept / Pass / Drop Life time: Bytes / Time / Both Restriction: Application protocols / Ports A home agent could serve a number of registered mobile nodes, which we call local devices. Each local device could be connected to several correspondent nodes, which we call remote devices. The connection between a local device and a remote device is called a channel. We can assign different security rules for every channel, which we call an entry of security rules. We retrieve an entry of this security rule cache by both the MN's local address and its remote address. The local address is the MN's HoA in HA site or MN's RCoA in MAP site. The remote address could be the CN's static address with/without subnet mask or its domain name if the CN is a wired machine, or the CN's home address if the CN is a mobile device. The item of "Action" specifies which operation will be performed on the packet between the local device and the remote device. Pass Option: the firewall will be transparent to the packet between the MN and the CN; Drop Option: the firewall will discourage the communication between the MN and the CN. Expires: September 14, 2005 [Page 5] Internet Draft Mobile Firewall March 15, 2005 The item of "Lifetime" indicates how long the communication is allowed. It could be based on the transferred data, on the transferring time, or on both. It could even be specified for a special period of a day. The item of "Restriction" specifies which application protocols or ports would be affected by the term of Action. The security rule cache is configured by the administrator of mobile nodes and will be transferred to the MAP. Then the MAP generates a copy of the security rule entry, and uses it to control the communication between the registered MN and its CN. Table 3: An entry of security association cache in HA MN's HoA MAP Address MN's RCoA MAP's RSA Public Key (P_map) Encryption Key (k_en) Binding Update Key (k_bu) Acknowledgement / Request Key (k_ba) Time Stamp Table 4: An entry of security association cache in MAP MN's HoA MN's RCoA MN's LCoA MN's RSA Public Key (P_h) Encryption Key (k_en) Binding Update Key (k_bu) Acknowledgement / Request Key (k_ba) Time Stamp Table 5: An entry of security association cache in MN MAP Address Binding Update Key (k_bu) Acknowledgement / Request Key (k_ba) Time Stamp The security association cache stores a series of keys for secure communication. The entry of security association caches located in the HA, the MAP and the MN are showed in Tables 3, 4, 5, respectively. These security association caches are generated automatically in the period of negotiation. Expires: September 14, 2005 [Page 6] Internet Draft Mobile Firewall March 15, 2005 4. FIREWALL SETUP Before building a channel between a mobile node and its correspondent node, the registering MAP must negotiate with the home agent of the mobile node to generate a security association, which includes Diffie-Hellman key pair for both the MAP and the HA, secure session keys, etc. The process can employ IKE protocol. When a MN enters a MAP domain and informs its HA that it would like to register under this MAP as a router, it sends a route optimization request REG_REQ = {Src=HoA, Des=HA, RCoA, MAP, Flag, Ran} to the HA via reserve tunnelling, where Flag signals the start of the protocol and Ran is a random number. Here MAP represents both the mobile anchor point and its IP address. Message REG_REQ is sent to MN's home link via the IPSec protected secure tunnel [2]. IPSec provides replay protection only when dynamic security association establishment is used. This may not always be possible and manual keying might be preferred in certain circumstances. For this reason, we have included a random number Ran in REG_REQ to counter message replay. MN MAP HA | | | |=====REG_REQ================>| | | | long term |<-----------------MAP_DENY---| messages | | | | |<---IKE_MSG---| | | ... | set up | | ... | VPN channel | | ... | | |----IKE_MSG-->| | | | ------------------------------------------------------ | | | | |===INI_REQ===>| | | | | |<===SEC_RUL===| | | | short term | |====MN_LOG===>| message for | |----MN_LOG--->| monitor/control | |----MN_LOG--->| | | | ------------------------------------------------------ | | | | |<===MN_LEV====| | | | Figure 2: Firewall Setup Expires: September 14, 2005 [Page 7] Internet Draft Mobile Firewall March 15, 2005 Upon receiving message REG_REQ, the HA will check whether the MAP is an acceptable router according to the HA's own trusted MAP cache. If the MAP is a denied router, then HA will send back a message MAP_DNY = {Src=HA, Des=RCoA, HoA, MAP, Denial, Ran} to the MN. After receiving this message, the MN will select another nearby MAP and resend message REG_REQ to HA. (Please refer to HMIPv6 [1] for choice of a proper MAP.) If the MAP is acceptable, the HA initiates an IKE process with MAP in order to set up the VPN channel as well as authenticate each other. Then both HA and MAP add the negotiated security association to their security association cache respectively. When a MN and its CN begin the communication, the firewall for the path CN-MN is launched. As soon as the HA intercepts the initial message INI_REQ INI_REQ = {Src=HoA, Des=CN, CoA(RCoA), Req, Ran} from the MN, the HA will get the encryption key k_en and will retrieve the security rule cache to get the security rule entry based on both MN's HoA and CN (or CN's HoA). If no security rule entry is available for the HoA and CN, the default security rule will be used. Then the HA will send to the MAP a message SEC_RUL SEC_RUL = {Src=HoA, Des=MAP, rules*, SIGH}, where, rules* is the security rules encrypted by the encryption key k_en, rules*= e(k_en, security_rules), and SIG_h is the signature of the security rules signed by the home link's private key S_h, SIG_h = (S_h, HoA|MAP|rules*) When the MAP receives the message SEC_RUL, the MAP retrieves from its security association cache the related public key P_h and encryption key k_en. After validating the signature SIG_h and getting the positive result, the MAP generates an entry for the security rule and adds to its security rule cache. According to HMIPv6 framework [1], every packet from the CN to the MN will pass through the router MAP. The MAP can capture all these packets, and decide how to process these pockets according to the related security rule: forwarding or dropping the packets. As the Expires: September 14, 2005 [Page 8] Internet Draft Mobile Firewall March 15, 2005 security rule is configured based on the source address, destination address, application protocols and ports, our solution could implement all the features of a normal firewall [3]. Moreover, the MAP could also count the connecting time and the size of data transferred between the CN and the MN. If they exceed the specified value in the security rule, the MAP may break the communication. Further, the MAP may log the MN's activities and report the activity logs to the home agent at specified intervals: MN_LOG = {Src=MAP, Des=HoA, i, HoA, log*} where, HoA is used to indicate the mobile node, i is used to indicate the sequence number of the log, and log* is the encrypted activity log of mobile node at the specified interval, log*= e(k_en, activity_log), where, k_en is the encryption key between the MAP and the HA generated in the negotiation process. νννν The administrator of the MN can monitor the MN's activities by reviewing the MN's logs from a remote machine. If necessary, the administrator can remotely modify the security rules stored in the HA for the MN, then the HA can send the updated message SEC_RUL to the MAP again so that the MAP can update the MN's security rules for synchronization. All the operation in the firewall process is transparent to the MN. 5. Communication Analysis Draft [4] describes some scenarios that should be considered in mobile network firewall. The draft analyzes two scenario modes involving MIP6 nodes and firewalls. One is inner mobile node mode, the other is external node. Since our scheme is to protect the mobile node, below communication analysis is focus on the inner mobile node mode. 5.1 Issues with Binding Updates and Acknowledgements between the Mobile Nodes and their Home Agent Many firewalls would not filter outbound messages. Hence, the requesting message REG_REQ (or the BU message to MN's home agent) can go through the firewall. After receiving the request message, the HA and MAP negotiate and build a VPN tunnel between them. Then MAP (the firewall) can forward the BA massage to MN from the home agent. Expires: September 14, 2005 [Page 9] Internet Draft Mobile Firewall March 15, 2005 5.2 Issues with Reachability The draft [4] described "the packet forwarded from the Home Agent to the Mobile Node CoA may be dropped at the firewall since it does not match any existing entry." The issue is not occurred in this scheme. In the protocol, after building a VPN tunnel between HA and MAP, HA will send to MAP (the firewall) the security rules in regard to MN. The security rules may include a rule of always opening the path HA-MN. After receiving the security rule table, MAP will translate the HoA to RCoA in its own security rule table in order to efficiently process the traffic packets. Therefore, all of packets to MN's CoA, will be processed based on the rules (drop or pass). 5.3 Issues with change of CoA The draft [4] also mentioned that the change of MN's CoA within a network would occur the packet dropping and need update the firewall rules. Since the mobile firewall scheme is based on the HMIPv6 architecture, a moving mobile node does not change its RCoA when it roams within the MAP domain. Therefore, the security rules do not need update in the scheme. 5.4 Issues with change of firewall If a mobile node moves to other domain, according to this mobile firewall protocol, the home agent will authenticate the new MAP and authorize the new MAP as the new firewall for the mobile node. So we are come back session 5.1 regarding to transferring the BU and BA. 5.5 Issues of communication with mobile correspondent nodes If the correspondent node is also a mobile node, the MAP will do a bit more work. In this case, MAP would be the mobile agent as well as the firewall. Here, we use CN_MN to denoted the mobile correspondent node. According to HMIPv6, every packet to MN from outside uses the RCoA as the destination address and is interrupted by MAP, then MAP forward the packet to MN's LCoA. Actually, the RCoA could be considered as one of addresses of MAP. Expires: September 14, 2005 [Page 10] Internet Draft Mobile Firewall March 15, 2005 Here, we use CN_MN to denote the mobile correspondent node. When CN_MN moves to a new network and will inform the MN its new address CoA_CN, CN_MN will not negotiate the RR process with MN directly. CN_MN will do the RR process with MAP instead. In CN_MN point, it always communicates with a fixed node, MAP, which address is RCoA. So MAP gets the HoTI and CoTI messages from CN_MN and replies HoT and CoT messages to CN_MN on behalf of MN. After getting the BU message from CN_MN, MAP forward CN_MN's new address CoA_CN to MN and then MN updates CN_MN's address to CoA_CN. Meanwhile, MAP update its entries regarding to CN_MN to the new address CoA_CN. 6. SECURITY CONSIDERATIONS The draft proposes a new concept of mobile firewall to prevent and monitor/control mobile nodes when they roam. 7. CONCLUSION As a conventional firewall is unsuitable for mobile networks, we introduced the concept of mobile personal firewall, and described how to implement a stateful firewall in the mobile IP infrastructure. There are three main parts in our scheme: - Authentication and authorization: this part focuses on how to authenticate between the HA and the MAP as well as between the MN and the MAP. - Control and monitor: this part focuses on how the guardian of the MN can control and monitor the MN's activities. - Management: this part focuses on how to effectively manage the security stuff. All the operations are transparent to the mobile user, and he will be served in a way specified by his guardian no matter where he roams. The mobile firewall could have full features of a conventional stateful firewall. 8. ACKNOWLEDGEMENTS Thank Franck Le for the comments on the mobile correspondent nodes. Expires: September 14, 2005 [Page 11] Internet Draft Mobile Firewall March 15, 2005 9. REFERENCES [1] H Soliman, C. Catelluccia and K. El-Malki, "Hierarchical MIPv6 Mobility Management(HMIPv6)", IETF INTERNET-DRAFT, October 2004 [2] J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [3] Linux iptable HOWTO [4] F. Le, B. Patil and H. Tschofenig, "Mobile IPv6 and Firewalls Problem statement", IETF INTERNET-DRAFT, February, 2005. 10. AUTHORS' ADDRESSES Feng BAO Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65-6874-8456 EMail: baofeng@i2r.a-star.edu.sg Robert DENG Singapore Management University 469 Bukit Timah Road Singapore 259756 Phone: +65-6822-0920 EMail: robertdeng@smu.edu.sg Ying QIU Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65-6874-6742 EMail: qiuying@i2r.a-star.edu.sg Jianying ZHOU Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65-6874-6668 EMail: jyzhou@i2r.a-star.edu.sg Expires: September 14, 2005 [Page 12] Internet Draft Mobile Firewall March 15, 2005 INTELLECTUAL PROPERTY STATEMENT 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 IETF's procedures with respect to rights in IETF 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 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. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. DISCLAIMER OF VALIDITY 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. COPYRIGHT STATEMENT Copyright (C) The Internet Society (2004). 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. ACKNOWLEDGMENT Funding for the RFC Editor function is currently provided by the Internet Society. Expires: September 14, 2005 [Page 13]