Network Working Group Yang Shen Internet-Draft Zhang Hongke Expires: November, 2006 Zhang Sidong Beijing Jiaotong University Miao Fuyou Huawei Technologies May, 2006 Firewall State Update Process for Mobile IPv6 draft-zhang-mip6-fsup-01 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 November, 2006. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract A mobile IPv6 node remains reachable when it moves in a IPv6 Internet. However, if such a node, i.e. MN, moves to a network which is protected by firewalls, the communication that is already existed before its moving may be blocked by firewall. The document presents a mechanism to update the corresponding access control entry of firewall to avoid the communication interrupted. Zhang, et al. Expires: November 2006 [Page 1] draft-zhang-mip6-fsup-01 May 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statements . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of CGA. . . . . . . . . . . . . . . . . . . . . . . 5 4. New Mobile IPv6 Option . . . . . . . . . . . . . . . . . . . 5 4.1. CGA Parameter Option. . . . . . . . . . . . . . . . . 5 4.2. Public Key Option . . . . . . . . . . . . . . . . . . 7 5. New ICMPv6 Message . . . . . . . . . . . . . . . . . . . . . 7 5.1. state_create_request. . . . . . . . . . . . . . . . . 7 5.2. state_create_reply. . . . . . . . . . . . . . . . . . 9 6. Protocol Description . . . . . . . . . . . . . . . . . . . .12 6.1 Modification to Mobile IPv6 . . . . . . . . . . . . .13 6.2. Protocol Process. . . . . . . . . . . . . . . . . . .13 7. Security Considerations. . . . . . . . . . . . . . . . . . .15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . .15 9. References . . . . . . . . . . . . . . . . . . . . . . . . .15 10. Author's address . . . . . . . . . . . . . . . . . . . . . .16 Full Copyright Statement . . . . . . . . . . . . . . . . . . . .16 Intellectual Property Statement . . . . . . . . . . . . . . . . .17 Expiration. . . . . . . . . . . . . . . . . . . . . . . . . . . .17 Zhang, et al. Expires: November 2006 [Page 2] draft-zhang-mip6-fsup-01 May 2006 1. Introduction It's well known that Mobile IPv6 does not works well along with firewall. It's a very complex problem because there are different types of node (MN, CN and HA) and firewall may exist between any two nodes. The nature of firewall as a perimeter protection complicates the situation because the "direction" must also be considered. The document will address a subclass of the MIP6 firewall traversal problem and propose a simple solution. When MN moves in the internet, it may move into a new network that is protected by firewalls. In the other case, the MN's moving may cause the changing of the routing path, if the CN is protected by several firewalls, the incoming data traffic comes to another firewall different from the original one. In both scenarios, one or many firewalls without entry for the communication is inserted between MN and CN. The scenario is specific to mobile networks, and some new methods are desired to get entry updated/added by firewall in a secure manner. There is a binding update procedure after MN's moving. So the BU/BA message may be considered as an indicator of the potential data traffic in the same direction. When an incoming BU/BA is intercepted and if there is no existing filtering entry in firewall, a firewall update process is triggered. Otherwise, Cryptographically Generated Addresses (CGA) is introduced. A public key is associated with the IPv6 address in the CGA address and the corresponding private key may sign the packet. With the help of CGA address, the state update process could became more robust. Zhang, et al. Expires: November 2006 [Page 3] draft-zhang-mip6-fsup-01 May 2006 2. Problem Statements Scenario 1: MN moves into a new network protected by firewall. +----------------+ +----+ | | ***********| CN |~~~ | | * +----+ ~ | | * Correspondent ~ | +---+ +----+ * Node ~ | |MN |<*****| FW |**** ~ | +---+ +----+ ~ | ^ | +----+ ~ | |-----------|--<-------------| MN |<~~ | | +----+ +----------------+ Mobile Node Network protected by a firewall Figure 1: ------> MN's moving track ~~~~~~> traffic from CN to MN before MN's moving ******> traffic from CN to MN after MN's moving When communication is going on, a MN may move into a network which is protected by a firewall. It's assumed that the Return Routability Procedure and Binding Update had already finished. The incoming packets from CN to MN is dropped because there no filtering entry in the firewall. When MN is communicating with HA, the same scenario may also happen. Scenario 2: route path changing caused by MN's moving +----------------+ +----+ | | ***********| MN | | | * +----+ | +---+ +----+ * ^ | | |<*****| FW1|**** | | | | +----+ | | |CN | | | | | | +----+ | | | |<~~~~~| FW2|~~~~ | | +---+ +----+ ~ | | Correspondent | ~ +----+ | Node | ~~~~~~~~~~~| MN | | | +----+ +----------------+ Mobile Node Network protected by firewalls Zhang, et al. Expires: November 2006 [Page 4] draft-zhang-mip6-fsup-01 May 2006 Figure 2: ------> MN's moving track ~~~~~~> traffic from MN to CN before MN's moving ******> traffic from MN to CN after MN's moving Another similar scenario is that CN is in network with more than one firewall, Iif the MN moves, the incoming traffic may come to another firewall, because the new Care-of Address may cause the change of routing path. The same scenario is also applied to HA. 3. Overview of CGA Cryptographically Generated Addresses (CGA) is IPv6 address, whose interface identifier is computed by hashing the public key and auxiliary parameters. The corresponding private key could be used to sign the packets sent from this address. The CGA address is authenticated by recomputing the hash value and comparing it to the interface identifier. No CAs and infrastructure are needed in the implementation of CGA address. A parameter data structure is attached to the packets being protected. The receiver could use the parameters to recompute the hash value when authenticating the CGA address. The data structure contains four parameters: Modifier, Subnet Prefix, Collision Count and Public Key. The CGA address has four main advantages: a public key is bound to the IPv6 address; address spoofing attack is much more harder; the modification to packets could be detected; no more infrastructure is required. 4. New Mobility Option in Mobile IPv6 4.1. CGA Parameter Option The CGA Parameter Option is about the CGA parameter data structure that each CGA address must have. The receiver nodes can use the data structure to verify the CGA address. The option has the following format: Zhang, et al. Expires: November 2006 [Page 5] draft-zhang-mip6-fsup-01 May 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Modifier (16 octets) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Subnet Prefix (8 octets) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Collision Count| | +-+-+-+-+-+-+-+-+ | | | ~ Public Key (variable length) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be designed. Length The length field contains the length of the option in octets, excluding the type and length fields. Modifier This field contains a 128-bit unsigned integer, which can be any value. The modifier is used during CGA generation to implement the hash extension and to enhance privacy by adding randomness to the address. Subnet Prefix This field contains the 64-bit subnet prefix of the CGA. Collision Count This is an eight-bit unsigned integer that MUST be 0, 1, or 2. The collision count is incremented during CGA generation to recover from an address collision detected by duplicate address detection. Zhang, et al. Expires: November 2006 [Page 6] draft-zhang-mip6-fsup-01 May 2006 Public Key This is a variable-length field containing the public key of the address owner. The public key is the one that used to generate the CGA address. The concrete desire of the format of the public key is described in [3]. 4.2. Public Key Option The Public Key Option is about the public key that the destination node used in CGA address. It is mainly designed for firewalls. The option must be contained in BU and BA message and it has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + | | Public Key (variable length) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be designed. The identifier of the type of the mobility option. Length The option length field contains the length of the Public Key in octets. Public Key This is a variable-length field containing the public key of the the destination node. If the host is a MN, "the destination node" means a CN, and vice versa. The public key must be identical with the destination node's public key that used for generating CGA address. 5. New ICMPv6 Message 5.1. state_create_request The state_create_request message is a new type of ICMPv6 message, it is used by firewall to request inner node to update the related filtering entry. The message has the following format: Zhang, et al. Expires: November 2006 [Page 7] draft-zhang-mip6-fsup-01 May 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Encrypted Cookie (16 octets) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Inner Node Address (16 octets) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Outer Node Address (16 octets) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be designated. The type field contains the identifier of the type of the ICMPv6 message. Code To be designated. The code field depends on the message type. It is used to create an additional level of message granularity. Ckecksum The checksum field is used to detect data corruption in the ICMPv6 message and parts of the IPv6 header. Encrypted Cookie The encrypted cookie field contains the cookie that is encrypted with the inner node's public key. The cookie is generated by firewall randomly and identical for each inner node. Zhang, et al. Expires: November 2006 [Page 8] draft-zhang-mip6-fsup-01 May 2006 Inner Node Address The inner node address field contains the IPv6 address of the node that is protected by the firewall. If the inner node is MN, the address is the home address. Outer Node Address The outer node address field contains the IPv6 address of the node that is outside of the firewall. If the outer node is MN, the address is the home address. 5.2. state_create_reply The state_create_reply message is a new type of ICMPv6 message, it is used by inner node to inform the firewall of the traffic related information, with which the firewall could build filtering entry. The message has the following format: Zhang, et al. Expires: November 2006 [Page 9] draft-zhang-mip6-fsup-01 May 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Signature (16 octets) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Inner Node Address (16 octets) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Outer Node Address (16 octets) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Node Port (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Node Port (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Modifier (16 octets) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Subnet Prefix (8 octets) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Collision Count| | +-+-+-+-+-+-+-+-+ | | | ~ Public Key (variable length) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zhang, et al. Expires: November 2006 [Page 10] draft-zhang-mip6-fsup-01 May 2006 Type To be designated. The type field contains the identifier of the type of the ICMPv6 message. Code To be designated. The code field depends on the message type. It is used to create an additional level of message granularity. Ckecksum The checksum field is used to detect data corruption in the ICMPv6 message and parts of the IPv6 header. Signature The signature field contains the signature of state information and cookie, it is computed as, Signature = First (128, DSA (Cookie | Inner Node Address | Outer Node Address | Inner Node Port | Outer Node Port)). The inner node get the cookie from the state_create_request message, it decrypts the "encrypted cookie" field with its private key. The firewall uses the signature to authenticate the state information. Encrypted Cookie The encrypted cookie field contains the cookie that is encrypted with the inner node's public key. The cookie is generated by firewall randomly and identical for each inner node. Inner Node Address The inner node address field contains the IPv6 address of the node that is protected by the firewall. If the inner node is MN, the address is the home address. Outer Node Address The outer node address field contains the IPv6 address of the node that is outside of the firewall. If the outer node is MN, the address is the home address. Inner Node Port The inner node port field contains the transport layer port number of the node that is protected by the firewall. The firewall uses the port number to build the filterig entry. Zhang, et al. Expires: November 2006 [Page 10] draft-zhang-mip6-fsup-01 May 2006 Outer Node Port The outer node port field contains the transport layer port number of the node that is outside of the firewall. The firewall uses the port number to build the filtering entry. Modifier This field contains a 128-bit unsigned integer, which can be any value. The modifier is used during CGA generation to implement the hash extension and to enhance privacy by adding randomness to the address. Subnet Prefix This field contains the 64-bit subnet prefix of the CGA. Collision Count This is an eight-bit unsigned integer that MUST be 0, 1, or 2. The collision count is incremented during CGA generation to recover from an address collision detected by duplicate address detection. Public Key This is a variable-length field containing the public key of the address owner. The public key is the one that used to generate the CGA address. The concrete desire of the format of the public key is described in [3]. 6. Protocol Description In this document, we only focus on the data traffic between MN and CN/HA, but not the signaling message such as BU, BA, RRT and etc. In the real world, the signaling message will also be blocked by firewalls, but that case could be dealt with easily by other means. So in this document, it is assumed that the signaling messages could pass through the firewall freely, only the data traffic is concerned. Another assumption is that the firewall could identify the home address of MN, it means that firewall takes the HoA as the filtering information and also checks the packets with that address. This means could simplify the protocol and improve the efficiency. The implementation of the above two assumption is described clearly in the[5], draft-miao-mip6-ft-01. As described in section 2, there are some reasons that may cause the firewall switching. But, whatever the reason is, a binding update Zhang, et al. Expires: November 2006 [Page 12] draft-zhang-mip6-fsup-01 May 2006 procedure is always between the firewall switching and the following data traffic. The data traffic from MN to CN will be routed along the same path as BU message, and the data traffic from CN to MN will be routed along the same path as BA message. So the BU/BA message could be considered as the indication of the potential data traffic. 6.1 Modification to Mobile IPv6 All the MN/CN/HA must support the CGA address, they should be able to generate and verify the CGA address. In this document, the CGA address is used to authenticate the filtering state update message only, but it can be utilized for other purpose, such as protecting the binding update message in Mobile IPv6. Two mobility option, CGA Parameter Option and Public Key Option, are introduced into mobile IPv6 protocol. The CGA Parameter Option is required by CGA address, the receiver could use the parameter to authenticate the CGA address. In this document, the parameter is not used directly. The Public Key Option contains the public key of the destination node, that is to say, it contains the public key of CN in the BU message sent to CN, the public key of HA in the BU message sent to HA and public key of MN in the BA message. The firewall intercepts the incoming BU or BA message, gets the public key of the inner node and encrypts the cookie with it in the next state_create_request message. 6.2. Protocol Process The firewall intercepts the incoming BU or BA message, and gets the information of addresses in the IP header. The firewall uses the addrsses to search in the filtering state database. If there is matching entries, it lets the BU/BA pass through and nothing else is done. If there is no matching entry, it saves the address information in the IP header and public key information in the Public Key Option. After saving the related information, the firewall starts the state_create_request message. It first generates a cookie randomly for the inner node and then encrypts it using the inner node's public key. The public key is got from BU/BA message in the previous step. The cookie is stored in the local for authenticating the signature in state_create_reply message in the futuer. The IP addresses of the inner node and outer node and encrypted cookie are encapsulated into the state_create_request message, and then the message was sent to inner node. When the inner node receives a state_create_request message, it uses the IP information in the Inner Node Address and outer Node Address Zhang, et al. Expires: November 2006 [Page 13] draft-zhang-mip6-fsup-01 May 2006 fields as an indication to search in the kernel for the related transport layer port number. After gaining the traffic infromation, it then decrypts the cookie with the private key related with the CGA address and signs a signature. The cookie is in the encrypted cookie field, this could assure that only the node having the private key could know the cookie. The signature is computed as, Signature = First (128, DSA (Cookie | Inner Node Address | Outer Node Address | Inner Node Port | Outer Node Port)). The signature could guarantee that the traffic information is not modified and the information is indeed sent from the desired inner node. The state_create_reply message is then completed with the CGA parameter appended and sent to firewall. When the firewall receives the state_create_reply message, it must authenticate the message and the traffic state information. The authentication procedure is as follows: o Compare the public key previously stored locally with the public key in the state_create_reply message. o Authenticate the CGA address. The details of the authentication procedure is described in [3]. o Authenticate the signature by recomputing the signature with the locally stored cookie. This could assure the state_create_reply message is not replied, because the cookie is generated randomly each time for each node. After the authentication, the traffic state information is considered authentic. The firewall could use the provided information, inner node address, outer node address, inner node port and outer node port, to update the filtering state database securely. The following figure illustrates the signaling exchange procedure when the mobile node moves into a new network protected by firewall. The incoming BA message indicates the potential new MN, and the firewall configuration protocol is trigered. Zhang, et al. Expires: November 2006 [Page 14] draft-zhang-mip6-fsup-01 May 2006 ++++++++++++++++++++++++++++++++++++++ Correspondent node Firewall Mobile node + | + | + | Binding Update (BU) | + |<----------------------------------------------------| + | + | + | Binding Acknowledgement (BA) | + |---------------------------------------------------->| + | + | + | +| state_create_request | + | +|------------------------->| + | +| | + | +| state_create_reply | + | +|<-------------------------| + | +| | + ++++++++++++++++++++++++++++++++++++++ Figure 3: Signaling Exchange Procedure 7. Security Considerations The cookie generated by firewall must be different for each inner node and even each time moving happens. This state update process could not prevent hijacking attack, the information about IP address and transport layer port may be leaked. But it is not sensitive, the following communication between MN and CN may also expose the same thing. 8. Acknowledgments I would like to appreciate all the project members Chen Jian, Lu Hongmei, Ren Yan, Zhang Hui. 9. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [4] Fuyou Miao and Shen Yang, "Firewall Traversal for Mobile IPv6", draft-miao-mip6-ft-01 (work in progress), November 2005. Zhang, et al. Expires: November 2006 [Page 15] draft-zhang-mip6-fsup-01 May 2006 [5] Le, F., "Mobile IPv6 and Firewalls: Problem statement", draft-ietf-mip6-firewalls-03 (work in progress), October 2005. 10. Author's address Yang Shen Tel: +86 10 5168 5677 IP Lab,EIES Fax: +86 10 5168 3682 Beijing Jiaotong University of China Beijing http://iplab.njtu.edu.cn China,100044 EMail: belton.yang@hotmail.com Zhang Hongke Tel: +86 10 5168 5677 IP Lab,EIES Fax: +86 10 5168 3682 Beijing Jiaotong University of China Beijing http://iplab.njtu.edu.cn China,100044 EMail: hkzhang@center.njtu.edu.cn Zhang Sidong Tel: +86 10 5168 5677 IP Lab,EIES Fax: +86 10 5168 3682 Beijing Jiaotong University of China Beijing http://iplab.njtu.edu.cn China,100044 EMail: sdzhang@center.njtu.edu.cn Miao Fuyou Tel: +86 10 8288 2350 Huawei Technologies Fax: +86 10 8288 2537 No. 3, Xinxi Road, Shangdi, Haidian Beijing China,100085 Email: miaofy@huawei.com 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. Zhang, et al. Expires: November 2006 [Page 16] draft-zhang-mip6-fsup-01 May 2006 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 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 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. Expiration This Internet-Draft (draft-zhang-mip6-fsup-01) expires in November 2006. Zhang, et al. Expires: November 2006 [Page 17]