Network working group Dacheng Zhang Internet Draft Xiaohu Xu Intended status: Experimental Huawei Technologies Co.,Ltd Created: October 19, 2009 Jiankang Yao Expires: April 2010 CNNIC Investigation in HIP Proxies draft-zhang-hip-investigation-proxy-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Zhang and Xu. Expires April 19, 2010 [Page 1] Internet-Draft Investigation in HIP Proxies October 2009 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Abstract HIP proxies play an important role in the transition from the current Internet architecture to the HIP architecture. The major function of HIP proxies is to make up legacy (or Non-HIP) hosts as HIP hosts and enable them to communicate with HIP hosts without upgrading their protocol stacks. In this document, the legacy hosts served by proxies is referred to as the Made-up Legacy (ML) hosts. Currently, various design solutions of HIP proxies have been proposed for different working circumstances, and the effectiveness of these solutions can be influenced by various factors (e.g., the information of HIP hosts maintained in DNS servers, the position where a proxy is located, etc.). In this document, we attempt to investigate these solutions in detail and compare their performance in different scenarios. Conventions used in this document 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 [RFC2119]. Table of Contents 1. Introduction...................................................3 2. HIP Proxies....................................................3 2.1. Essential Operations of HIP Proxies.......................3 2.2. A Taxonomy of HIP Proxies.................................4 2.3. DI Proxies................................................4 2.4. N-DI Proxies..............................................6 3. Issues with HIP proxies in the Load Balancing Scenarios........7 3.1. Issues with HIP Proxies in Supporting ML Hosts to Initiate Communication..................................................7 3.1.1. The Asymmetric Path Issue............................7 3.1.2. Issues with Routing packets sent by HIP hosts........8 3.2. Issues with HIP Proxies in Supporting HIP Hosts to Initiate Communication..................................................9 3.2.1. DNS Resource Records for Made-up Legacy Hosts........9 3.2.2. The Asymmetric Path Issue...........................10 4. Security Consideration........................................13 5. Conclusions...................................................13 6. IANA Considerations...........................................13 Zhang and Xu. Expires April 19, 2010 [Page 2] Internet-Draft Investigation in HIP Proxies October 2009 7. Acknowledgments...............................................13 8. References....................................................13 Authors' Addresses...............................................14 1. Introduction As core components of HIP extensional solutions, HIP proxies have attracted increasing attention from both industry and academia. Currently, multiple research work is engaged in the design and the performance assessment of HIP proxies. In this document, we attempt to investigate the design issues with HIP proxies, provide a taxonomy of HIP proxies, and compare the effectiveness of different types of HIP proxies in different scenarios. There has been a detailed discussion of HIP proxies in [SAL05]. This document can be regarded as a complement of that paper. Some new topics (e.g., the asymmetric path issues occurred in HIP proxy based load-balancing mechanisms and the necessary of extending HIP RR for HIP proxies) are discussed. Theoretically, there is no restriction on the locations of the ML hosts and the HIP host they intend to communicate with. However, in this document, we only consider the most important scenario that HIP proxies are expected to support [SAL05]. That is, without mentioned otherwise, legacy hosts are located within a private network and HIP hosts are located in the public network. The content of the remaining paper is organized as follows. In section 2, we first briefly introduce the essential functions of HIP proxies and provide a taxonomy of HIP proxies according to their implementation styles. In section 3 we compare the performances of different types of HIP proxies in load balancing scenarios. Section 4 provides a brief discussion about the influence brought by DNSsec to the deployment of HIP proxies. Section 5 is the conclusion of the whole document. 2. HIP Proxies 2.1. Essential Operations of HIP Proxies A primary function of HIP proxies is to represent legacy hosts to communicate with HIP hosts by using standard HIP protocols. In order to achieve this function, a HIP proxy needs to be located on the path of data packets transported between legacy and HIP hosts. Upon capturing a packet from a legacy host, the proxy needs to verify whether this packet is destined to a HIP host. If it is, the proxy then tries to find out an appropriate HIP association (HA) from its local database. If the HA is found, the proxy uses the HA to Zhang and Xu. Expires April 19, 2010 [Page 3] Internet-Draft Investigation in HIP Proxies October 2009 encapsulate the packet and forwards it to its destination. However, if there is no such a HA, the proxy needs to represent the legacy host to carry out a HIP base-exchange with the HIP host to generate a new one, using the HI and HIT assigned to the legacy host. The newly generated HIP association is then maintained in the local database. After capturing a responding packet from the HIP host, the proxy also uses the key material in the HA to decapsulate the packet and then forwards it to the legacy host. 2.2. A Taxonomy of HIP Proxies In practice, there are various design solutions for HIP proxies which are based on different presumptions and supposed to execute in different circumstances. In this section, these solutions are investigated in detail. To benefit the analysis, we classify HIP proxies into DNS lookups Intercepting Proxies (DI proxies) and Non- DNS lookups Intercepting Proxies (N-DI proxies). As indicated by the name, DI proxies need to intercept DNS lookups in order to correctly process the follow-up communication between legacy hosts and their peers, while NDI proxies do not have to. To avoid confusion, in the remainder of this document we use the terms "lookup" and "answer" in specific ways. A lookup refers to the entire process of translating a domain name for a legacy host. An answer is a DNS response that terminates the lookup. 2.3. DI Proxies Usually, before a legacy host communicates with a remote host, it needs to query DNS servers to obtain the IP address of its destination. On this premise, it is effective for DI proxies to identify the hosts which legacy hosts may intends to contact by intercepting DNS lookups. Specifically, the initial DNS queries or DNS answers are most valuable for DI proxies. For instance, after intercepting an initial query from a legacy host, a DI proxy can take advantage of the FQDN in the query to initiate a new DNS lookup to enquire the information it needs (AAAA RRs, HIP RRs, and etc.). After maintaining such information in the local database, the proxy returns an answer with an AAAA RR to the legacy host. On the occasions where DI proxies intercept DNS answers, a DI proxy can directly locate the DNS severs maintaining the desired RRs from the packet headers of DNS answers and contact the DNS servers directly in the subsequent lookups. However, because the lookups initiated by legacy hosts and proxies are carried out in a sequent Zhang and Xu. Expires April 19, 2010 [Page 4] Internet-Draft Investigation in HIP Proxies October 2009 way, the DI proxies intercepting answers may introduce more delays than those intercepting initial queries in certain circumstances. Besides intercepting DNS lookups, some kinds of DI proxies also modify the contents of the AAAA RRs in DNS answers to benefit their following up operations. For instance, [RFC5338] indicate that a HIP proxy can returns HITs rather than IP addresses in the DNS answers to legacy hosts. Consequently, the data packets destined to HIP hosts will use HITs as destination addresses. In addition, [PAT07] proposes a solution where a HIP proxy maintains an IP address pool and returns the IP addresses selected from the pool in DNS answers. As a result, the IP addresses selected by the proxy are used to route the packets destined to HIP hosts within the private network. In the remainder of this document, the proxies adopting the solutions depicted above are referred to as DI1 proxies and DI2 proxies respectively. In addition, we refer to the proxies which do not modify the contents of DNS answers (i.e., return the IP addresses of HIP hosts in answers) as DI3 proxies. Different modifications on DNS answers introduce different influences on the performances of DI proxies and impose different restrictions on their locations. Compared with DI1 and DI2 proxies, DI3 proxies show their limitations in many aspects. For instance, it is common for a ML host served by a proxy to publish the IP address of its proxy in its DNS AAAA RR. Therefore, when a user served by a DI3 proxy attempts to communicate with such two remote ML hosts served by a same HIP proxy, it is difficult for the user to distinguish an ML host from the other as they both use the same IP address. In addition, DI3 proxies cannot work properly in the circumstance where HIP hosts renumber their IP addresses during the communication due to mobility and re-homing reasons. In DI1 or DI2-proxy-based Load Balancing mechanisms (LBMs), these issues can be avoided, since the IP addresses of HIP hosts are not used for routing packets within private networks. Moreover, it is difficult for DI3 proxies to advertise routes for their desired packets, and consequently they can only be deployed at the borders of private networks. DI1 (or DI2) proxies, however, can attract the packets for HIP hosts to themselves by advertising associated routes because the packets destined to HIP hosts have HITs (or the IP addresses selected from pools) in their destination address fields. Therefore, in private networks with resolvers (local DNS servers), DI1 and DI2 proxies can also be located on the paths of DNS packets transported between resolvers and legacy hosts, where Zhang and Xu. Expires April 19, 2010 [Page 5] Internet-Draft Investigation in HIP Proxies October 2009 proxies do not have to process undesired packets (e.g., the packets exchanged between legacy hosts). 2.4. N-DI Proxies Unlike DI proxies, an N-DI proxy never attempts to intercept DNS lookups to find out the potential destinations of legacy hosts in the subsequent communication. Instead, it verifies whether the destination of a data packet is HIP enabled, using the information in the packet header. To facilitate such verifications, an N-DI proxy may need to maintain a list of mapping information between HITs and IP addresses. Therefore, if the destination address of a received packet is maintained in the list, the proxy can ensure the packet is for a HIP hosts [SAL05]. Obviously, this solution is infeasible in the cases where the HIP hosts that ML hosts intend to communicate with are unpredictable. This issue can be addressed by storing HITs (which have a prefix different from that of ordinary IP addresses) instead of IPv6 addresses in the AAAA RRs of HIP hosts in DNS servers. When receiving an answer containing the AAAA RR of a HIP host, a legacy host (e.g., host A) will treat the HIT in the answer as the IPv6 address of its desired host (e.g., host B). When sending a data packet to B, A puts the HIT of B in the destination address fields of the packet headers. Therefore, the packets for legacy hosts and the packets for HIP hosts can be distinguished by comparing their contents in the destination address fields, and an N-DI proxy (e.g., proxy P) can route the packet for B to itself by distributing an associated route. Upon receiving the packet, P uses the associated HA to encapsulate the packet. In order to forward the encapsulated packet to its destination, P may need to get the associated IP address from DHT servers using the HIT of B. Also, P can try to send the packet to an overlay facilitating HIT-based routing in the public network. Compared with DI proxies, N-DI proxies show advantages on some occassions. For instance, in order to facilitate the legacy hosts in the private networks without HIP proxies to communicate with HIP hosts, ISPs may try to deploy HIP proxies in transit networks. However, in order to work properly in a transit network, a DI proxy may have to process all the packets transported inside the network to find out the desired DNS lookups. This issue can seriously affect its scalability. In this case, an N-DI proxy can be more efficient as it can advertise routes in the network to attract its desired packets to itself. However, there is a realistic problem which may prevent N-DI proxies from being widely employed. It is predicable that, in the initial Zhang and Xu. Expires April 19, 2010 [Page 6] Internet-Draft Investigation in HIP Proxies October 2009 period of widely deploying HIP hosts, various HIP proxy solutions will be adopted by different organizations and the information of HIP hosts in DNS servers will organized in an ad hoc way. At least in this period, it is extremely difficult to guarantee that all the RRs of HIP hosts are modified appropriately. However, if this prerequisite is not fulfilled, N-DI proxies cannot work as what they are expected. From this perspective, modifying DNS answers is a valuable capability of DI proxies. 3. Issues with HIP proxies in the Load Balancing Scenarios If there is only a single HIP proxy deployed for a private network, the proxy may become the cause of a single-point-of-failure. In addition, when the number of the users increases, the overhead imposed on the proxy may overwhelm its capability, which makes it the bottleneck of the whole mechanism. Load-balancing is a widely exploited solution to mitigate such issues. By sharing overheads amongst multiple HIP proxies, a LBM can be more scalable and more capable to tolerate the failures of a sub-set of HIP proxies. However, a LBM is not just a collection of multiple HIP proxies. Lots of issues need to be carefully considered. 3.1. Issues with HIP Proxies in Supporting ML Hosts to Initiate Communication 3.1.1. The Asymmetric Path Issue +-------------------------+ +------------------------+ | | | | | +---+-------+ | | | +-----------+ |HIP proxy 1+----+ +---------+ | | |Legacy Host| +---+-------+ | |HIP Host | | | +-----------+ | . | | (HH1) | | | | . | +---------+ | | +---+--------+ | | | |HIP proxy n +---+ | | Private Network +---+--------+ | Public Network | | | | | +-------------------------+ +------------------------+ Figure 1: An example of LBM Figure 1 illustrates a example of LBM. In this mechanism, n DI1 proxies are deployed at the border of a private network. In order to share the overhead of processing data packets, each proxy needs to advertise a route of the HIT section it manages. In addition, each Zhang and Xu. Expires April 19, 2010 [Page 7] Internet-Draft Investigation in HIP Proxies October 2009 proxy also needs to advise a route of a section of IP addresses (or a default route) inside the private network to intercept DNS lookups. Therefore, the DNS queries and the data packets sent by a legacy host may be intercepted by different proxies. In such cases, the proxy intercepting the data packets lacks essential knowledge to correctly process them because it did not intercept the associated DNS communication. If the proxies in Figure 1 are DI3 proxies, then each proxy only needs to advertise a route of a section of IP addresses. However, if a HIP host and the DNS server maintaining its RR fall into two different IP sections, the proxy intercepting the lookups for the HIP host will not be the one intercepting subsequent data packets. Therefore, DI3-proxy-based LBMs also suffer from this problem. A candidate solution to this problem is to propagate the knowledge obtained from DNS lookups amongst HIP proxies. Therefore, after intercepting a DNS conversation, a proxy can forward the information it gained to the proxy which is expected to process the subsequent data packets. Alternatively, a proxy can attempt to collect required information from resolution systems after intercepting a data packet, which, however, may impose addition overhead to resolution systems and introduce delays in processing data packets. If the proxies in Figure 1 are DI2 proxies, the problem can be eliminated. In such a DI2-proxy-based LBM, each DI2 proxy has a pool of IP addresses and needs to advertise a route of the section of IP addresses in the pool, besides advertising a route of a section of IP address for intercepting DNS lookups. After intercepting a DNS lookup, a DI2 proxy will return an IP address within the pool in the answer. Therefore, the subsequent data packets will be routed to the proxy it as well. 3.1.2. Issues with Routing packets sent by HIP hosts When representing a ML host to communicate with a HIP host in the public network, a HIP proxy needs to capture the packets sent by the HIP host. In order to achieve this, the HIP proxy can either use an IP address it manages as the source address of the packets forwarded to the HIP host, or advertise the routes for all the legacy hosts it serves. The preceding solution is feasible in the load balancing scenarios where multiple HIP proxies serve a same group of ML hosts while the succeeding solution may cause a kind of asymmetric path issue. Using the succeeding solution, the HIP hosts in an LBM may advertise the routes which have overlaps in IP addresses. As a result, the packets in a same HIP context may traverse different HIP Zhang and Xu. Expires April 19, 2010 [Page 8] Internet-Draft Investigation in HIP Proxies October 2009 proxies, and the proxy intercepting a packet may lack the proper HIP association to process it. This issue theatrically can be addressed by sharing HIP context information (e.g., HIP associations, sequence number of IP packets) amongst related proxies in a real-in-time fashion. However, this solution may result in the highly frequent update of the HIP context information. During communication, some context information such as the sequence numbers of packets can change very fast, and thus a HIP host has to exchange update messages in an extreme high frequency in order to guarantee that other proxies can get the latest context information. Large amounts of bandwidth and the computing resources will be occupied to transport and process the update messages, which can seriously affect the performances of HIP proxies. A similar issue is discussed in [TSC05], and an extended HIP base exchange is proposed to address it. The proposed solution can also be proposed to address issue caused by the succeeding solution. However, we argue the preceding solution is more desired as it introduces little modification to HIP protocols. 3.2. Issues with HIP Proxies in Supporting HIP Hosts to Initiate Communication In the discussion in section 3.1, we only consider the conditions where legacy hosts initiate communication with HIP hosts. In this section, we analyze the issues that HIP proxies have to encounter in the conditions where HIP hosts proactively initiate communication with legacy hosts. In order to support the communication initiated by HIP hosts, the HIP proxies of a private network should have the knowledge necessary for representing inside legacy hosts to perform the HIP base- exchange. Such knowledge consists of the IP addresses of the legacy hosts, their pre-assigned HITs, the corresponding public key pairs, and any other necessary information. In addition, the information of the ML hosts should be advertised in resolution systems (e.g., DNS and DHT) as HIP hosts. Otherwise, a HIP host has to obtain the HIT of the ML host using opportunistic model which is not adopted in insecure networks. 3.2.1. DNS Resource Records for Made-up Legacy Hosts In practice, the AAAA RR of a ML host can consist of either the IP address of the legacy host or the address of its HIP proxy. In the preceding approach, the packets destined to legacy hosts are transported to their destinations directly, and thus HIP proxies must be located on the path of such packets to intercept them. In Zhang and Xu. Expires April 19, 2010 [Page 9] Internet-Draft Investigation in HIP Proxies October 2009 the succeeding approach, the packets for a legacy host are firstly transported to an associated HIP proxy. Therefore the proxy can be deployed anywhere desired. In addition, the succeeding approach is more efficient that the preceding one in private networks where legacy hosts and HIP hosts are deployed in an intermixed way, since the HIP proxy only need to process the packets for ML hosts. However, the succeeding approach may cause problems in the process of packets sent by legacy hosts in the public network. Assume a HIP proxy serves multiple ML hosts. According to the succeeding approach, the packets for these ML hosts have the same destination address (i.e., the IP address of the proxy). Therefore, when receiving a packet from a legacy host locating in the public network, the proxy may find it is difficult to identify the ML host the packet destines to. A simple approach combining the advantages of the above two solutions but avoiding their disadvantages is to extend the RDATA in HIP RR [RFC5205] with a new proxy field, which contains the IP address of a HIP proxy. In the extended HIP RR of a ML host, the proxy field consists of the IP address of its HIP proxy, while the proxy field in the RR of an ordinary HIP host is left empty. Therefore, a HIP host intending to communicate with the ML host can obtain the IP address of the proxy from DNS servers and set it as the destination address of the packets. The packets are then routed to the proxy. When a non-HIP host intends to communicate with the legacy host, it can obtain the IP address of the legacy host from the AAAA RR from the DNS answer and set it as the destination address of the packets; the packets are then transported to legacy host directly. It is also possible to use the RVS field in a HIP RR to transport the information of a HIP proxy. However, the proxy field can bring benefits in security. For instance, it is normally assumed that the base-exchange protocol is able to establish a security channel for the hosts on the both sides of communication to securely exchange messages. However, this presumption may be no longer valid in the presence of HIP proxies, as the messages between legacy hosts and proxies can be transported in plain text. With the Proxy field, it is easy to distinguish the legacy hosts made up by HIP proxies from the ordinary HIP hosts. Therefore, a HIP host can assess the risks of exchanging sensitive information with its communicating peers in a more specific way. 3.2.2. The Asymmetric Path Issue In a load balancing scenario where multiple HIP proxies are deployed at the border of a private network, the packets transported between Zhang and Xu. Expires April 19, 2010 [Page 10] Internet-Draft Investigation in HIP Proxies October 2009 a legacy host and a HIP host may be routed via different HIP proxies. Therefore, when a packet is intercepted by a HIP proxy, the proxy may find that it lacks essential knowledge to appropriately process the packet. This issue is referred to as the asymmetric path issue. In order to explain the asymmetric path issue in more detail, let us revisit the LBM illustrated in Figure 1. In addition, assume that the IP addresses of both proxies are maintained in the RRs of the ML hosts. When a HIP host (e.g., HH1) looks up a legacy host at a DNS server, the DNS server returns the IP addresses of the two HIP proxies in an answer. Upon receiving the answer, HH1 selects an address, e.g., the address of HIP proxy1, and sends HIP control packets to HIP proxy1. After successfully performing a base exchange, both HIP proxy1 and HH1 establish a HIP association respectively. Therefore, upon receiving the first data packet from HH1, the HIP proxy uses the HIP association to decapsulate the packet and forwards it to the legacy host. The source IP address of the forwarded packet is the HIT of HH1. Thus, the legacy host will set the HIT of HH1 as the destination address of the reply packets. Assume that the HIT of HH1 is within the section managed by HIP proxyn. According the routes to HIT range published by the proxies, the packet is forwarded to the HIP proxyn which, however, does not have the corresponding HIP association to deal with the packet. Similarly with DI1 proxies, DI3 proxies and N-DI proxies also suffer from the asymmetric path issue in the load balancing scenarios, since they cannot guarantee the data transported between a legacy host and a HIP host can only pass a single HIP proxy too. +-------------------------+ +-------------------------------------+ | | | | | +---+-------+ | (3) | | (4) -|HIP proxy 1+----+< - | | / +---+-------+ | \ +---------+ (1) +--------+| | +-----------+< - | . | -- |HIP Host |----- > | DNS || | |Legacy Host|- | . | | (HH1) |< ----- | Server || | +-----------+ \ +---+--------+ | +---------+ (2) +--------+| | (5) - >|HIP proxy n +---+ | | Private Network +---+--------+ | Public Network | | | | | +-------------------------+ +-------------------------------------+ Figure 2. An example of the asymmetric path issue Several candidate solutions can be used to address this issue. In the simplest solution, a HIP proxy just simply discards an I1 packet if it is not original from a HIP host which the proxy takes in Zhang and Xu. Expires April 19, 2010 [Page 11] Internet-Draft Investigation in HIP Proxies October 2009 charge of. In addition, using ICMP packets, the proxy can inform the HIP hosts of the incidents. Therefore, after waiting for a certain period or receiving ICMP packets from the HIP proxy, the HIP host will attempt to resend the I1 packet to another HIP proxy. This process can be recursive, until all the HIP proxies available have been contacted. Because a HIP host may need to send the multiple I1 messages in order to communicate with a ML host, this solution can yield a long delay. Note that in some DNS based load balancing approaches, a DNS server only returns one HIP proxy in an answer. Under such a circumstance, HIP hosts have to also communicate with DNS servers repeatedly, and thus the negative influence caused by this solution can be even exacerbated. A candidate solution which can avoid the delay issue is to extend DNS servers so that a DNS server can return the IP address of an appropriate HIP proxy in an answer according to the HIT (if the proxy is a DI1 proxy or a N-DI proxy) or the IP address (if the proxy is a DI3 proxy) of the requester. That is, the HIP proxy described in a DNS answer should be the one which takes in charge of the packets sent by DNS requester. In order to achieve such capability, DNS servers need to 1) maintain the information about the sections of the namespace that HIP proxies take in charge of, 2) locate the appropriate HIP proxy according to the HIT or the IP address of a HIP requester. These requirements result in modifications to current DNS servers in terms of the format of RRs, the functionality the DNS server applications and the conversation protocol between requesters and DNS servers. For instance, HIP hosts need to transport their HITs in DNS requests so that DNS servers can use them to locate appropriate HIP proxies. It is also possible to select a HIP proxy and endow it with the capability of RVS. The IP address of the proxy should be maintained in the RVS fields of the HIP RRs of the ML hosts so that HIP-aware requesters will send I1 packets to the HIP proxy directly. When obtaining an I1 packet, the proxy can forward it to the corresponding proxy to process. If DI2 proxies are adopted in the scenario depicted in Figure 1, the asymmetric path issue can be eliminated. A DI2 proxy located at the border of a private network maintains a pool of IP addresses which are routable in the private network. After receiving a packet from a HIP host, the DI2 proxy processes the packet and forwards it to the destination legacy host. In addition, an IP address selected from the pool is adopted as the source address of the packet. Therefore, when the legacy host sends responding packets to the HIP host, the Zhang and Xu. Expires April 19, 2010 [Page 12] Internet-Draft Investigation in HIP Proxies October 2009 packets will be transported to the same HIP proxy. The asymmetric path issue is thus avoided. 4. Security Consideration Security is an important benefit introduced by HIP. In the basic HIP architecture, security requirement on DNS communications is not compelled. But in practice, DNSSEC [RFC4305] is recommended in order to prevent attackers from tampering or forging DNS lookups between resolvers and DNS server. This solution may affect the deployment of HIP proxies. For instance, DI1 and DI2 proxies need to modify the contents of NDS answers, and thus they should be only deployed on the path between legacy hosts and their resolvers. Therefore, a DI1 proxy (or a DI2 proxy) should not be deployed at the border of a private network if there is a DNSsec-enabled resolver. 5. Conclusions The different types of HIP proxies are designed based on different presumptions. The presumptions of different type of HIP proxies maybe conflict with each other. Then how to make a trade-off and enable different types of proxies work cooperatively is an important issue that the designers of HIP extensible solutions have to consider. 6. IANA Considerations No such considerations. 7. Acknowledgments 8. References [PAT07] P. Salmela, J. Wall and P. Jokela, "Addressing Method and Method and Apparatus for Establishing Host Identity Protocol (Hip) Connections Between Legacy and Hip Nodes," US. 20070274312, 2007. [SAL05]P. Salmela, "Host Identity Protocol proxy in a 3G system," Master's thesis. Helsinki University of Technology 2005. [TSC05] H. Tschofenig, A. Gurtov, J. Ylitalo, A. Nagarajan and M. Shanmugam, "Traversing Middleboxes with the Host Identity Protocol," Proc. ACISP, 2005. [RFC5338] T. Henderson, P. Nikander and M. Komu, "Using the Host Identity Protocol with Legacy Applications," RFC 5338, Sep. 2008. Zhang and Xu. Expires April 19, 2010 [Page 13] Internet-Draft Investigation in HIP Proxies October 2009 [RFC5205] P. Nikander and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extension," RFC 5205, April 2008. [RFC4035] R. Arends, R. Austein , M. Larson, D. Massey and S. Rose, "Protocol Modifications for the DNS Security Extensions," RFC 4035, March 2005. Authors' Addresses Dacheng Zhang Huawei Technologies Co.,Ltd KuiKe Building, No.9 Xinxi Rd., Hai-Dian District Beijing, 100085 P.R. China Email: zhangdacheng@huawei.com Xiaohu Xu Huawei Technologies Co.,Ltd KuiKe Building, No.9 Xinxi Rd., Hai-Dian District Beijing, 100085 P.R. China Email: xuxh@huawei.com Jiankang Yao CNNIC No.4 South 4th Street, Zhongguancun Bejing, P.R. China Phone: +86 10 58813007 Email: yaojk@cnnic.cn Zhang and Xu. Expires April 19, 2010 [Page 14]