One document matched: draft-irtf-hiprg-proxies-00.txt
Network working group Dacheng Zhang
Internet Draft Xiaohu Xu
Intended status: Experimental Huawei Technologies Co.,Ltd
Created: May 24, 2010 Jiankang Yao
Expires: November 2010 CNNIC
Investigation in HIP Proxies
draft-irtf-hiprg-proxies-00
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 November 24, 2010.
Zhang Xu and Jiankang. Expires November 24, 2010 [Page 1]
Internet-Draft Investigation in HIP Proxies May 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
..................................................................9
4.1. An Issues Caused by Intercepting DNS Lookups..............9
Zhang Xu and Jiankang. Expires November 24, 2010 [Page 2]
Internet-Draft Investigation in HIP Proxies May 2010
4.2. Issues with LBMs in Capturing and Processing Replies from
HIP hosts.....................................................11
5. Issues with LBMs which also Support HIP Hosts to Initiate
Communication....................................................12
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........................................17
6.3. Application of DI3 proxies in supporting dynamic load
balance and redundancy........................................17
7. Security Consideration........................................17
8. Conclusions...................................................18
9. IANA Considerations...........................................18
10. Acknowledgments..............................................18
11. References...................................................18
Authors' Addresses...............................................20
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 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 in the draft.
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 Load Balancing Mechanism (LBM) which
Zhang Xu and Jiankang. Expires November 24, 2010 [Page 3]
Internet-Draft Investigation in HIP Proxies May 2010
facilitates communications 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. In section 6, we
investigate 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 located, the proxy then
find the proper key maintained in the HA and use it to encrypt the
payload in the packet. The packet is then forwarded to the HIP host.
However, if there is no such an 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) and generate a new HA with the HIP host. The
newly generated HA 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 Xu and Jiankang. Expires November 24, 2010 [Page 4]
Internet-Draft Investigation in HIP Proxies May 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 contact in near future 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 RRs, it will
try to obtain them from 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 with the
resolver to inquire about the desired information (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 the
needed 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
are 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
Zhang Xu and Jiankang. Expires November 24, 2010 [Page 5]
Internet-Draft Investigation in HIP Proxies May 2010
what is illustrated above. The proxies which can be deployed in this
way are 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 DNS 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 answer of a DNS lookup does not contain any NS RR, it
can be easily distinguished from the 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 the HITs of the
HIP hosts as destination addresses. [PAT07] also proposes a proxy
solution which requires a HIP proxy to maintain 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 peer 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, these two types of proxies 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 a practical
solution 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
Zhang Xu and Jiankang. Expires November 24, 2010 [Page 6]
Internet-Draft Investigation in HIP Proxies May 2010
proxy attempts to 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 or re-homing. For DI1 or DI2 proxies, these
issues can be largely mitigated as the IP addresses of HIP hosts
will never be used by DI1 or DI2 proxies to identity hosts.
Moreover, it is difficult for DI3 proxies to advertise routing
information to attract the packets they needs to process (i.e., the
packets transported between ML hosts and remote HIP hosts).
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. Therefore, 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, and it 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 deploying solution 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 advance by intercepting DNS
lookups transported between legacy hosts (or resolvers) 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[SAL05]. After intercepting a packet from a legacy host,
the proxy can ensure the packet is for a HIP host, if the
destination address of the packet is maintained in the list.
Obviously, this solution is infeasible in the circumstances where it
is difficult to identify the HIP hosts that ML hosts intend to
contact in advance. On such occasions, an N-DI proxy has to find out
whether a packet from a ML host is destined to a HIP host and or a
legacy host. It is infeasible for an N-DI proxy to consult
resolution systems to find out whether an IP address belongs to a
HIP host or a legacy host. Therefore, the N-DI proxy has to maintain
Zhang Xu and Jiankang. Expires November 24, 2010 [Page 7]
Internet-Draft Investigation in HIP Proxies May 2010
to list of IP addresses. One is for HIP hosts, and the other is for
legacy hosts. When intercepting a packet, the N-DI can compare the
destination address of the packet against the addresses in the lists
to find out whether the packet is destined to a HIP host. If no
address is matched, the proxy has to consult resolution systems and
maintain the address in the associated list according the answer
from resolution systems. Obviously, an N-DI proxy may have to
maintain a large amount of state information, which makes it less
efficient and scaleable than DI-proxies. Fortunately, this issue can
be mitigated by inserting 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 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 transported between 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 which
supports HIT-based routing in the public network (e.g., HIP Bone).
Compared with DI proxies, N-DI proxies can be deployed in a more
flexible way. For instance, in order to facilitate the legacy hosts
in the private networks without HIP proxies to communicate with HIP
hosts, Internet services providers (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 normally 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
Zhang Xu and Jiankang. Expires November 24, 2010 [Page 8]
Internet-Draft Investigation in HIP Proxies May 2010
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
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 different
groups (e.g., according to their IP addresses), and the ML hosts in
different sections are taken in charge of by different HIP proxies.
The second solution is to divide the HIP hosts in the Internet into
multiple groups (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
group. 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 desired in many cases. Therefore, in
the design of existing LBM solutions, the second type of solution is
more preferred. In the remainder of this document, we mainly
consider the second one.
4.1. An Issues Caused by Intercepting DNS Lookups
Zhang Xu and Jiankang. Expires November 24, 2010 [Page 9]
Internet-Draft Investigation in HIP Proxies May 2010
+--------------------+ +------------------+
| | | |
| +---+-------+ | |
| +-----------+ |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
section of IP addresses (or a default route for the entire IP
address namespace) 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 intercepting a data packet will lack essential
knowledge to correctly process it. 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 a same problem with DI1-proxy-based LBMs.
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
gained information to the proxy 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 a DI2-proxy-based LBM, each DI2 proxy needs to
advertise two routes, one of the IP addresses in the pool and one of
Zhang Xu and Jiankang. Expires November 24, 2010 [Page 10]
Internet-Draft Investigation in HIP Proxies May 2010
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), which can ensure the subsequent data packets will be
transported 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 porxy 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 placed on the path of the
packets transferred between HIP hosts and the ML hosts it serves in
order to capture the reply packets from HIP hosts. 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. Assume there are two HIP proxies located at the
border of a private network. If the 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 stuck to 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 problem 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
transmitted or received IPsec packet, since such operations 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.
Zhang Xu and Jiankang. Expires November 24, 2010 [Page 11]
Internet-Draft Investigation in HIP Proxies May 2010
Note that all these issues can be simply addressed by adopting the
preceding option because it can guarantee the packets transported
between a ML host and a HIP host are intercepted by a same proxy.
Therefore, in the following discussions, without mentioned otherwise
we assume that a HIP proxy uses 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
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 in the
opportunistic model which, however, 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 ML host or the address of its HIP proxy. In the
preceding case, 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 case, 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 will not have to process the packets transported
between HIP hosts. 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 destined to
these ML hosts will have a same destination address (i.e., the IP
Zhang Xu and Jiankang. Expires November 24, 2010 [Page 12]
Internet-Draft Investigation in HIP Proxies May 2010
address of the proxy). Therefore, when receiving a packet from a
legacy host located in the public network, the proxy may find it
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, a special proxy field can
bring additional 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.
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
Zhang Xu and Jiankang. Expires November 24, 2010 [Page 13]
Internet-Draft Investigation in HIP Proxies May 2010
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.
+----------------------+ +--------------------------+
| | | |
| +---+-------+ | (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 receives 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 a ICMP packet, a HIP
host will try to select another HIP proxy from the list in the DNS
Zhang Xu and Jiankang. Expires November 24, 2010 [Page 14]
Internet-Draft Investigation in HIP Proxies May 2010
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
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.
The asymmetric path issue can be eliminated by adopting DI2 proxies.
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
Zhang Xu and Jiankang. Expires November 24, 2010 [Page 15]
Internet-Draft Investigation in HIP Proxies May 2010
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
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.
Zhang Xu and Jiankang. Expires November 24, 2010 [Page 16]
Internet-Draft Investigation in HIP Proxies May 2010
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 multiple 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.
Moreover, apart from synchronizing HIP associations, the
synchronization of mappings from IP addresses to HITs is also
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
Zhang Xu and Jiankang. Expires November 24, 2010 [Page 17]
Internet-Draft Investigation in HIP Proxies May 2010
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
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
Normative references
[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.
Zhang Xu and Jiankang. Expires November 24, 2010 [Page 18]
Internet-Draft Investigation in HIP Proxies May 2010
[RFC4035] R. Arends, R. Austein , M. Larson, D. Massey and S. Rose,
"Protocol Modifications for the DNS Security Extensions," RFC 4035,
March 2005.
Informative references
[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.
[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.
Zhang Xu and Jiankang. Expires November 24, 2010 [Page 19]
Internet-Draft Investigation in HIP Proxies May 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 Xu and Jiankang. Expires November 24, 2010 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-23 19:23:39 |