[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network working group                                    Dacheng Zhang
Internet Draft                                               Xiaohu Xu
Intended status: Experimental              Huawei Technologies Co.,Ltd
Created: March 8, 2010                                    Jiankang Yao
Expires: September 2010                                          CNNIC

                       Investigation in HIP Proxies
                  draft-zhang-hip-investigation-proxy-01



Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

   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 September 8, 2010.






Zhang and Xu.         Expires September 8, 2010               [Page 1]


Internet-Draft      Investigation in HIP Proxies            March 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.



Abstract

   HIP proxies play an important role in the transition from the
   current Internet architecture to the HIP architecture. A core
   objective of a HIP proxy is to facilitate the communications between
   legacy (or Non-HIP) hosts and HIP hosts while not modifying their
   protocol stacks. In this document, the legacy hosts served by
   proxies are referred to as the Made-up Legacy (ML) hosts. Currently,
   various designing solutions of HIP proxies have been proposed. These
   solutions may be applicable in different working circumstances. In
   this document, we attempt to investigate these solutions in detail
   and compare their performances 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. Terminologies................................................4
   3. HIP Proxies..................................................4
      3.1. Essential Operations of HIP Proxies.....................4
      3.2. A Taxonomy of HIP Proxies...............................5
      3.3. DI Proxies..............................................5
      3.4. N-DI Proxies............................................7
   4. Issues with LBMs in Supporting ML Hosts to Initiate Communication
    ...............................................................8
      4.1. An Issues Caused by Intercepting DNS Lookups............9



Zhang and Xu.         Expires September 8, 2010               [Page 2]


Internet-Draft      Investigation in HIP Proxies            March 2010


      4.2. Issues with LBMs in Capturing and Processing Replies from
      HIP hosts...................................................10
   5. Issues with LBMs which also Support HIP Hosts to Initiate
   Communication..................................................11
      5.1. DNS Resource Records for ML Hosts......................12
      5.2. An Asymmetric Path Issue...............................13
   6. Issues with LBMs in supporting dynamic load balance and
   redundancy.....................................................15
      6.1. Application of DI1 proxies in supporting dynamic load
      balance and redundancy......................................16
      6.2. Application of DI2 proxies in supporting dynamic load
      balance and redundancy......................................16
      6.3. Application of DI3 proxies in supporting dynamic load
      balance and redundancy......................................17
   7. Security Consideration......................................17
   8. Conclusions.................................................17
   9. IANA Considerations.........................................18
   10. Acknowledgments............................................18
   11. References.................................................18
   Authors' Addresses.............................................19

   1. Introduction

   As core components of HIP extensional solutions, HIP proxies have
   attracted increasing attention from both the industry and the
   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 several important designing solutions and
   compare their effectiveness in different scenarios. Actually, 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 the load-
   balancing mechanisms for HIP proxies and the necessary of extending
   the HIP RR for HIP proxies) are discussed. Theoretically, ML hosts
   and the HIP hosts they intend to communicate with can be located
   anywhere in the network. However, in this document, without
   mentioned otherwise, legacy hosts are located within a private
   network and HIP hosts are located in the public network, as this is
   the most important scenario that HIP proxies are expected to support
   [SAL05].

   The remainder of this document is organized as follows. Section 2
   lists the key terminologies used in this document. In section 3, we
   indicate the essential functions of HIP proxies and provide a
   classification. In section 4  we analyze the issues that HIP proxies
   have to face in constructing a LBM which facilitates communications



Zhang and Xu.         Expires September 8, 2010               [Page 3]


Internet-Draft      Investigation in HIP Proxies            March 2010


   initiated by ML hosts. Section 5 analyzes the issues that HIP
   proxies in a LBM have to face if they also need to support
   communications initiated by HIP hosts. Section 6 discusses an
   asymmetric path issue in details. In section 6, we analyze the
   issues that HIP proxies have to deal with in supporting dynamic load
   balancing and redundancy. Section 7 provides a brief discussion
   about the influence brought by DNSsec to the deployment of HIP
   proxies. Section 8 is the conclusion of the entire document.

   2. Terminologies

   BEX: HIP Base Exchange

   DI Proxy: DNS Inspecting Proxy

   HA: HIP association

   LBM: Load Balancing Mechanism

   N-DI proxy: Non-DNS Inspecting Proxy

   3. HIP Proxies

3.1. Essential Operations of HIP Proxies

   A primary function of HIP proxies is to exchange messages with HIP
   hosts on the performance of legacy hosts, using standard HIP
   protocols. In order to achieve this, a HIP proxy needs to intercept
   the packets transported between legacy and HIP hosts before they
   arrive at their destinations. Upon capturing such a packet, a HIP
   proxy needs to transfer it into the format which can be recognized
   by the host which the packet is destined for. Assume a proxy
   captures a packet sent out by a ML host. If the packet is destined
   to a HIP host, the proxy first checks whether there is an
   appropriate HIP association (HA) in its local database which can be
   used to process the packet. If such a HA is found, the proxy then
   uses the HA to encrypt the packet and forwards it to the HIP host.
   However, if there is no such a HA or it has expired, the proxy needs
   to use the HI and HIT assigned to the ML host to carry out a HIP
   Base Exchange (BEX) with the HIP host to generate a new HIP
   association. The newly generated HIP association is then maintained
   in the local database. After capturing packet from a HIP host, the
   proxy also needs to use the keying material in the associated HA to
   decrypt the packet, transfer it into an ordinary IP packet, and
   forwards the IP packet to the legacy host.




Zhang and Xu.         Expires September 8, 2010               [Page 4]


Internet-Draft      Investigation in HIP Proxies            March 2010


3.2. A Taxonomy of HIP Proxies

   In practice, there are various design solutions for HIP proxies.
   These solutions are based on different presumptions and supposed to
   execute in different circumstances. 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, a DI proxy needs to intercept DNS lookups in
   order to correctly process the follow-up communication between
   legacy hosts and HIP hosts, while N-DI 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. The
   answer of a lookup is the response from a resolution server which
   terminates the lookup.

3.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, a DI proxy can effectively identify
   the hosts which legacy hosts may intend to contact by intercepting
   DNS lookups. In practice, it is common to deploy one more multiple
   local DNS servers (resolvers) for a private network. Therefore, the
   hosts in the network can send their queries to the resolver instead
   of communicating with authoritative DNS servers directly. If the
   resolver does not cache the inquired RR, it will try to contact
   authoritative DNS servers. The resolver may have to contact multiple
   authoritative DNS servers to get the IP address of the authoritative
   DNS server which actually contains desired DNS RRs. If the resolver
   is located out of the private network, a HIP proxy located at the
   border of the network can intercept an initial DNS query from a
   legacy host and then use the FQDN obtained from the query to
   initiate a new DNS lookup to the resolver to inquire about the
   information it needs (AAAA RRs, HIP RRs, and etc.). If the host that
   the legacy host intends to communicate with is HIP enabled, the DNS
   resolver will hand out a HIP RR associated with an AAAA RR to the
   proxy. After maintaining essential information (e.g., HITs, HIs, IPs
   addresses) in the local database, the proxy returns an answer with
   an AAAA RR to the legacy host.

   When the resolver is located inside the private network, conditions
   can be a little more complex. If a proxy can be located on the path
   between ML hosts and the resolver, it can work exactly as same as
   what is illustrated above. There are several kind of proxies can be



Zhang and Xu.         Expires September 8, 2010               [Page 5]


Internet-Draft      Investigation in HIP Proxies            March 2010


   deployed in this way, which will be introduced in the remainder of
   this sub-section. However, if a proxy is located at the border of
   the network, it has to spend more efforts to intercept and modify
   the lookups between the resolver and authoritative DNS servers,
   because the resolver may have to contact multiple authoritative DNS
   servers to get a desired answer. In this case, to be more efficient,
   the proxy can only inspect the responses from DNS services and find
   out DNS answers. Because the answers of DNS lookups do not contain
   any NS RRs, they can be easily distinguished from those intermediate
   responses. After identifying a DNS answer, a DI proxy can locate the
   DNS sever maintaining the desired RRs from the packet header and
   identify the FQDN of the inquired host from the packet payload. Then,
   the proxy initiates an independent lookup to the DNS server to check
   whether the host is HIP enabled. If it is, the proxy maintains the
   information of the host for future usage and returns an answer with
   an AAAA RR to the resolver.

   Besides intercepting DNS lookups, some kinds of DI proxies also
   modify the contents of the AAAA RRs in DNS answers for resolvers or
   ML hosts in order to benefit their following up operations. For
   instance, [RFC5338] indicates that a HIP proxy can returns HITs
   rather than IP addresses in DNS answers to ML hosts. Consequently,
   the data packets from ML hosts to HIP hosts will use HITs as
   destination addresses. In addition, [PAT07] proposes a solution in
   which a HIP proxy maintains an IP address pool. When sending a DNS
   answer to a ML host, the proxy selects an IP address from its pool
   and inserts it in the answer. The legacy host will regard this IP
   address as the IP address of the remote host it intends to
   communicate with. In the subsequent communication, when the host
   sends a packet for the remote HIP host, it will use the selected IP
   address as the destination address. In the remainder of this
   document, the proxies adopting the solutions depicted above are
   referred to as DI1 proxies and DI2 proxies respectively, and the
   proxies which do not modify the contents of DNS answers (i.e.,
   return the IP addresses of HIP hosts in answers) are referred to 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 to publish the IP address of its proxy in its DNS AAAA RR so
   that the packets for the host will be directly forwarded to the
   proxy. Therefore, when a ML host served by a DI3 proxy attempts to



Zhang and Xu.         Expires September 8, 2010               [Page 6]


Internet-Draft      Investigation in HIP Proxies            March 2010


   communicate with two remote ML hosts served by a same HIP proxy, it
   is difficult for the host to distinguish one remote 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, e.g., mobility
   and re-homing. For DI1 or DI2 proxies, these issues can be largely
   mitigated. When DI1 or DI2 proxies are deployed, the IP addresses of
   HIP hosts are covered from ML hosts; and in the communications
   between HIP proxies and HIP hosts HITs are used to identify
   communicating partners.

   Moreover, it is difficult for DI3 proxies to advertise routing
   information to attract the packets they needs to process.
   Consequently, they can be only 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 use HITs (or the IP addresses
   selected from pools) as their destination addresses. Hence, they can
   locate inside the networks, which may bring benefit in various cases.
   For instance, in a private network whose resolver are located inside,
   a DI1 or a DI2 proxy can be deployed on the path between the
   resolver and legacy hosts. Therefore, the proxy needs only to
   intercept, modify and forward the queries from legacy host to the
   resolver. Compared with deploying HIP proxies at the border of the
   network, this deployment can reduce the overhead on the proxy
   imposed by intercepting DNS lookups.

3.4. N-DI Proxies

   Unlike DI proxies, an N-DI proxy does not attempt to find out the
   HIP hosts a legacy host may contact in prior by intercepting DNS
   lookups transported between legacy hosts and DNS servers. Instead,
   it identifies whether the receiver of a packet is HIP enabled when
   it capture the packet. Typically, an N-DI proxy achieves this by
   inspecting the destination address of the packet. When the HIP hosts
   that ML hosts intend to contact are predicable and the number of the
   HIP hosts is finite, an N-DI proxy can 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 scenarios where it is
   difficult to identify the HIP hosts that ML hosts intend to contact
   in advance. This issue can be addressed by storing HITs 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 (e.g., host
   B), a legacy host (e.g., host A) will regard the HIT in the answer



Zhang and Xu.         Expires September 8, 2010               [Page 7]


Internet-Draft      Investigation in HIP Proxies            March 2010


   as the IPv6 address of B. Afterwards, when A sends a data packet to
   B, it use the HIT of B as the destination address. Because HITs
   share a prefix which is different from those of ordinary IP
   addresses, when an N-DI proxy (e.g., proxy P) catches the packet, P
   can easily distinguish it from the packets for legacy hosts. In
   addition, P can advertise a route of the prefix of HITs within the
   private network so as to avoid dealing with the packets for legacy
   hosts. After processing the packet, P may need to get the associated
   IP address from resolution servers which provide ID to locator
   mapping information (e.g., DHT servers), using the HIT found in the
   packet header. Otherwise, P can try to send the packet to an overlay
   facilitating HIT-based routing in the public network (e.g., HIP
   Bone).

   Compared with DI proxies, N-DI proxies can be deployed in more
   flexible way. For instance, in order to facilitate the legacy hosts
   in the private networks without HIP proxies to communicate with HIP
   hosts, ISPs may deploy HIP proxies in transit networks. If DI
   proxies are adopted, they need to locate in the places where they
   can intercept all the packets transported inside the transit network
   to find out DNS lookups because the IP addresses of DNS servers are
   unknown in advance. The jobs of processing packets are cumbersome.
   In addition, such locations may be quite difficult to find out. In
   this case, N-DI proxies show their advantages; an N-DI proxy can
   advertise a route of the HIT prefix (or a sub-prefix of HIT) in the
   transit network and easily attract the desired packets to it.
   Therefore, they can be deployed in a more flexible way and have to
   process fewer packets. However, there is a realistic problem which
   may prevent N-DI proxies from being widely employed. It is
   predicable that, in the initial 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. This issue makes it difficult for N-DI proxies to
   effectively distinguish packets for HIP hosts from those for legacy
   packets. From this perspective, the capability of DI proxies in
   modifying DNS answers is desirable.

   4. Issues with LBMs in Supporting ML Hosts to Initiate Communication

   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. A typical solution to



Zhang and Xu.         Expires September 8, 2010               [Page 8]


Internet-Draft      Investigation in HIP Proxies            March 2010


   mitigate this issue is to organize multiple proxies to construct a
   LBM. By sharing overheads amongst multiple HIP proxies, a LBM can be
   more scalable and 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.

   Generally, there are two solutions to share communication between ML
   hosts and HIP hosts among different HIP proxies. The first solution
   is to divided the ML hosts in the private network into multiple
   sections (e.g., according to their IP addresses), and the ML hosts
   in different section is taken in charge of by different HIP proxies.
   The second solution is to divide the HIP hosts in the Internet into
   multiple sections (e.g., according to their HITs or IP addresses),
   every HIP proxy serves all the ML hosts in the private network but
   only take in charge of the packets to and from the HIP hosts in a
   section. Abstractly, the two solutions are identical. However, the
   first solution actually attempts to divide a private network into
   multiple sub-networks, and each of them is served by a HIP proxy.
   This may introduce additional modification to the topology of the
   private network, which is not desirable in many cases. Therefore, in
   existing LBM solutions, the second type of solution is widely
   adopted. In the remainder of this document, we mainly consider the
   second one.

4.1. An Issues Caused by Intercepting DNS Lookups

   +--------------------+           +------------------+
   |                    |           |                  |
   |                +---+-------+   |                  |
   | +-----------+  |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 simple LBM. In this mechanism, n proxies are
   deployed at the border of a private network. If such proxies are DI1
   proxies, in order to share the overheads of processing data packets,
   each proxy needs to advertise a route of the HIT section it takes in
   charge of. In addition, each proxy also needs to advise a route of a



Zhang and Xu.         Expires September 8, 2010               [Page 9]


Internet-Draft      Investigation in HIP Proxies            March 2010


   section of IP addresses (or a default route) inside the private
   network to intercept DNS lookups. A problem occurs when the DNS
   lookups and the data packets sent by a legacy host are intercepted
   by different proxies. In such a case, the proxy which intercepts
   data packets will lack essential knowledge to correctly process them.
   If the proxies adopted in Figure 1 are DI3 proxies, then each proxy
   only needs to advertise a route of a section of IP addresses which
   is adopted to intercept both DNS lookups and data packets. On this
   occasion, if a HIP host and the DNS server maintaining its RR fall
   into two different IP sections, the DI3 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 the
   above problem.

   A candidate solution to the problem is to propagate the mapping
   information 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. This approach, however, imposes addition
   overheads to DI-proxies in communicating with resolution servers.

   If the proxies in Figure 1 are DI2 proxies, the problem can be
   eliminated. In such a DI2-proxy-based LBM, each DI2 proxy needs to
   advertise two routes, one of the IP addresses in the pool and the
   other of a section of IP addresses for intercepting DNS lookups.
   After intercepting a DNS lookup, a DI2 proxy will return an IP
   address within the pool in the answer to the requester (a ML host or
   a resolver). Therefore, the subsequent data packets will be stuck to
   the same proxy.

4.2. Issues with LBMs in Capturing and Processing Replies from HIP hosts

   Theoretically, when representing a ML host to communicate with a HIP
   host in the public network, a HIP host can use either an IP address
   it possesses or the IP address of the ML host as the source address
   of the packets forwarded to the HIP host. However, in practice, the
   succeeding option may cause several issues. For instance, in the
   succeeding option, a Hip proxy must be located on the path of the
   packets transferred between HIP hosts and the ML hosts it serves in
   order to capture the reply packets from the HIP host. In addition,
   the succeeding solution may cause problems in the load balancing
   scenarios where multiple HIP proxies provide services for a same
   group of ML hosts. To benefit the discussion, assume there are two
   HIP proxies located at the border of a private network. If the



Zhang and Xu.         Expires September 8, 2010              [Page 10]


Internet-Draft      Investigation in HIP Proxies            March 2010


   proxies adopt the succeeding solution, they need to advertise the
   routes of the ML hosts in the public network respectively. As a
   result, it is difficult to guarantee the packets transported between
   a legacy host and a HIP host are intercepted by a same HIP proxy,
   and thus after a proxy intercepts a packet it may lack the proper
   HIP association to process it.

   A possible solution to address this issue is to share HIP state
   information (e.g., HIP associations, sequence number of IPsec
   packets) amongst the related HIP proxies in a real-in-time fashion.
   However, during communication, some context information such as the
   sequence numbers of IPsec packets can change very fast. It is
   infeasible to synchronize the IPsec message counters for every IPsec
   packet transmitted or received, because this will occupy large
   amounts of bandwidth and seriously affect the performances of HIP
   proxies. [Nir 2009] indicates that this issue can be partially
   mitigated by synchronizing IPsec message counters only at regular
   intervals, for instance, every 10,000 packets.

   An issue similar with the one mentioned above is discussed in
   [TSC05], and an extended HIP base exchange is proposed. But the
   proposed solution only tries to help HIP-aware middle boxes obtain
   the SPIs used in a HIP base exchange and cannot be directly used to
   address the issue mentioned above.

   Note that all these issues can be simply addressed by adopting the
   preceding option. Therefore, in the following discussions, we assume
   that a HIP proxy use one of its IP addresses as the source IP
   address of a packet which it sends to a HIP host.

   5. Issues with LBMs which also Support HIP Hosts to Initiate
      Communication

   Apart from the basic functions (i.e., supporting ML hosts to
   communicate with HIP hosts), in many typical scenarios, HIP proxies
   may also need to facilitate the communication initiated by HIP hosts.
   In this section, we attempt to analyze the issues that a HIP proxy
   has to face 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 essential
   to represent the ML hosts to perform HIP BEXs. Such knowledge
   consists of the IP addresses of the legacy hosts, their pre-assigned
   HITs, the corresponding HI key pairs, and any other necessary
   information. In addition, such information of the ML hosts should be



Zhang and Xu.         Expires September 8, 2010              [Page 11]


Internet-Draft      Investigation in HIP Proxies            March 2010


   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 should only be adopted in secure
   environments.

5.1. DNS Resource Records for ML Hosts

   In practice, the AAAA RR of a ML host can consist of either the IP
   address of the associate legacy host or the address of its HIP proxy.
   In the preceding approach, the packets destined to a legacy host are
   transported to the host directly, and thus HIP proxies must be
   located on the path of such packets to intercept them. In the
   succeeding approach, the packets for a legacy host are firstly
   transported to the associated HIP proxy. Therefore the proxy can be
   deployed anywhere desired. In addition, the succeeding approach is
   more efficient than 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 rather
   than intercept all the packets transported across the network border.
   However, the succeeding approach may cause problems in the process
   of packets sent by legacy hosts in the public network. Normally, a
   HIP proxy needs to serve a number of ML hosts. When using the
   succeeding approach, the packets sent to these ML hosts will have a
   same destination address (i.e., the IP address of the proxy).
   Therefore, when receiving a packet from a legacy host located in the
   public network, the proxy may find it is difficult to identify the
   ML host which the packet should be forwarded to.

   A simple approach which combines the advantages of the above two
   solutions but avoids their disadvantages is to extend the RDATA
   field in HIP RRs [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 as usual and set it as the destination address of the
   packets; the packets are then transported to legacy host directly.

   Although it is also possible to use the RVS field in a HIP RR to
   transport the information of a HIP proxy, the proxy field can bring
   additional benefits in security. For instance, it is normally
   assumed that the base-exchange protocol is able to establish a



Zhang and Xu.         Expires September 8, 2010              [Page 12]


Internet-Draft      Investigation in HIP Proxies            March 2010


   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.

5.2. An 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
   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. Hence, an asymmetric path issue occurs.

   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 HIP proxies are DI1 proxies and their IP addresses are
   maintained in the DNS 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 all the HIP proxies in an answer (see Figure 2).
   Upon receiving the answer, HH1 needs to select an IP address and
   sends an I1 packet to the associated HIP proxy. Assume the HIP proxy
   1 is selected. Then after a base exchange, HIP proxy1 and HH1
   establish a HIP association respectively. Upon receiving the first
   data packet from HH1, the HIP proxy uses the HIP association to de-
   capsulate the packet and forwards it to the legacy host. In the
   forwarded packets, the HIT of HH1 is adopted as the source IP
   address, and thus the HIT of HHI is adopted as the destination
   address in the reply packets sent by the legacy host. Assume that
   the HIT of HH1 is within the section managed by HIP proxy n.
   According the routes advertised by the proxy n, the packet is
   forwarded to the HIP proxy n 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 packets which are transported between a
   legacy host and a HIP host stick to a single HIP proxy too.








Zhang and Xu.         Expires September 8, 2010              [Page 13]


Internet-Draft      Investigation in HIP Proxies            March 2010



   +----------------------+         +--------------------------+
   |                      |         |                          |
   |                  +---+-------+ | (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

   As we mentioned in section 3.3.1, the approach of sharing HIP
   associations and IPsec association amongst HIP proxies can be used
   to address this issue. However, this issue will introduce addition
   communication overhead on HIP proxies. Here, we discuss several
   other alternative solutions.

   The simplest solution is to allow a HIP proxy to discard the I1
   packets it receivers if they are not original from HIP hosts which
   the proxy takes in charge of. In addition, the proxy can inform the
   senders of the incidents using ICMP packets. Therefore, after
   waiting for a certain period or upon receiving the ICMP packets, a
   HIP host will try to select another HIP proxy from the list in the
   DNS answer and send an I1 packet it. In the worst case, this process
   needs to be recursive until all the HIP proxies in the list have
   been contacted. Because a HIP host may have to send the multiple I1
   packets in order to communicate with a ML host, this solution may
   yield a long delay. Note that in some DNS based load balancing
   approaches, a DNS server only returns one HIP proxy in an answer. On
   such occasions, HIP hosts have to communicate with DNS servers
   repeatedly, and the negative influence caused by the communication
   delay can be even exacerbated.

   A solution which is able to avoid the delay issue is to endow DNS
   servers with the capability of returning 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 a requester. That is, the HIP proxy
   described in a DNS answer should take in charge of the namespace
   section which the requester belongs to. In order to achieve this,
   DNS servers need to 1) maintain the information about the sections
   of the namespaces that HIP proxies take in charge of, 2) locate the



Zhang and Xu.         Expires September 8, 2010              [Page 14]


Internet-Draft      Investigation in HIP Proxies            March 2010


   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 the implementation of the DNS server applications and
   the conversation protocols between requesters and DNS servers. For
   instance, a HIP host may need to transport its HIT in DNS requests
   in order to help DNS servers locate an appropriate HIP proxy.

   It is also possible to register HIP proxies to a RVS server.
   Therefore, upon receiving an I1 packet, the RVS server can forward
   it to a proper proxy to process.

   If DI2 proxies are adopted in the LBM 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
   packets will be transported to the same HIP proxy. The asymmetric
   path issue is thus eliminated.

6. Issues with LBMs in supporting dynamic load balance and redundancy

   The load balancing solutions discussed above are simple and static.
   They cannot modify routes of packets according to the loads on
   different HIP proxies. In practice, there are requirements for LBMs
   to support dynamic load balance and redundancy. That is, when a
   proxy (called a prim proxy) in a LBM is not able to work properly or
   the overheads imposed on it surpass a threshold, the proxy can
   delegate all of (or a part of) its job to other proxies (called
   backup proxies). In this section, we analyze the performance of
   different types of HIP proxies in supporting dynamic load balance
   and redundancy.

   In order to provide backup services, a backup proxy needs to
   advertise the same routes as those advertised by the prim proxy in
   both the private and the public networks. To avoid affecting the
   normal operations of the prim proxy, the routes advertised by the
   backup proxy have a much higher cost than that of the routes
   advertised by the prim proxy. When the abnormal conditions mentioned
   above occurs, the prim proxy can withdraw the routes it previously
   advertised so that the packets supposed to be processed by the prim
   proxy will be forwarded to the backup proxy. We refer to the routes
   advertised by a proxy for backup purposes as the backup routes of
   the proxy. In contrast, we refer to the routes advertised by a proxy



Zhang and Xu.         Expires September 8, 2010              [Page 15]


Internet-Draft      Investigation in HIP Proxies            March 2010


   to achieve its primary job as the prim routes of the proxy. In
   practice, the proxies in a LBM can provide backup services for one
   another. Therefore, a proxy in such a LBM may needs to advertise
   both prim and backup routes.

   The synchronization of state information between prim and backup
   proxies is also very important. Without proper HIP associations, a
   backup proxy cannot correctly take place of the prim proxy to
   process the packets. The state synchronization problem has been
   discussed above. If there is no state synchronization, a backup
   proxy may select to send signaling packets to HIP hosts to initiate
   new HIP BEXs.

   In the remainder of this section, we attempt to analyze the
   performance of different types of HIP proxies in supporting dynamic
   load balance and redundancy respectively.

6.1. Application of DI1 proxies in supporting dynamic load balance and
redundancy

   As mentioned in section 3.1, a DI1 proxy needs to at least advertise
   two prim routes in the private network, one for a section of HITs,
   which is used to intercept data packets, and the other for a section
   of IP addresses, which is used to intercept DNS lookups. When the
   proxy cannot work properly, it can withdraw both routes to enable a
   backup proxy to take over its job.

   In some cases, a DI1 proxy may only want to delegate a part of its
   job to others so as to reduce the overloads it undertakes. To
   achieve this objective, the proxy can advertise more specific prim
   routes. When the overload on the proxy is high, it can only withdraw
   a subset of those advertised routes. For instance, a DI1 proxy can
   selectively only delegate a part of the responsibility in processing
   DNS lookups to a backup proxy by withdrawing one of its lookup
   intercepting routes.

6.2. Application of DI2 proxies in supporting dynamic load balance and
redundancy

   A DI2 proxy needs to at least advertise two prim routes in the
   private network, a route for its IP address pool, used to intercept
   data packets, and the other for an IP address section, is used to
   intercept DNS lookups. When the proxy cannot work properly, it can
   withdraw both routes to enable a backup proxy to take over its job.
   In this case, the delegated backup proxy needs to maintain an IP
   address pool identical to the one maintained by the prim proxy.



Zhang and Xu.         Expires September 8, 2010              [Page 16]


Internet-Draft      Investigation in HIP Proxies            March 2010


   Moreover, the synchronization of mappings from IP addresses to HITs
   is required. Otherwise, the backup proxy cannot translate the
   received packet correctly.

   If a DI2 proxy only intends to maintain existing communications
   between ML hosts and HIP hosts while not facilitating any more, it
   can withdraw the lookup intercepting route. As mentioned previously,
   DI2 proxies have the capability to stick the DNS lookups and the
   subsequent data packets to the same proxy. Therefore, the backup
   proxy can intercept DNS lookups as well as process the subsequent
   communications.

6.3. Application of DI3 proxies in supporting dynamic load balance and
redundancy

   Unlike DI1 and DI2 proxies, the routes advertised by a DI3 proxy are
   used for intercepting both DNS lookups and data packets. Therefore,
   before a DI3 proxy withdraws a route, it needs to synchronize the
   states of the on-going communications affected by the routing
   adjustment to its backup proxies.

   7. 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 in the middle of
   DNSsec-enabled resolvers and authoritative DNS servers.

   When sharing HIP state information amongst HIP proxies, the
   integrity and confidentiality of the state information should be
   protected. The discussion about the similar issues can be found in
   [Nir 2009] and [Narayanan 07].

   8. Conclusions

   This document mainly analyzes and compares the performance of
   different kinds of HIP proxies in LBMs. Amongst the HIP proxies
   discussed in the document, DI2 proxies show its advantages in
   multiple scenarios. In addition, we argue that the state
   synchronization among HIP proxies is very important to achieve



Zhang and Xu.         Expires September 8, 2010              [Page 17]


Internet-Draft      Investigation in HIP Proxies            March 2010


   academic load balancing and redundancy. There is a topic which is
   important but not covered in this document is the compatibility
   among different HIP proxies. 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.

   9. IANA Considerations

   No such considerations.

   10. Acknowledgments

   11. 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.

   [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.

   [Nir 2009] Y. Nir, "IPsec High Availability Problem Statement,"
   Internet Draft, 2009.

   [Narayanan 07] V. Narayanan, "IPsec Gateway Failover and Redundancy
   - Problem Statement and Goals," Internet Draft, 2007.






Zhang and Xu.         Expires September 8, 2010              [Page 18]


Internet-Draft      Investigation in HIP Proxies            March 2010


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 September 8, 2010              [Page 19]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/