[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] loc/id split and HIP (was LISP)



On 9 Oct 2007, at 04:22, Sheng Jiang wrote:
For example, HIP, it requests ALL end devices change their stacks, ALL
applications to be modified in order to support HIT, and to deploy a global mapping real-time system in order to translate the identifier (HIT) into
locator (IP).

Well, that is not quite true. While that all may be *eventually* required to reap all the potential benefits of HIP, in the short term much less is needed. For example, in order to deploy HIP in a small scale, all that is needed is to *some* end devices to change their stacks. There is no need to modify applications [1]. For stationary hosts, the mapping of HIT to locators can be stationary, requiring no new infrastructure. Additionally, the HIP-enabled hosts can continue to communicate with non-HIP-enabled hosts as if HIP wasn't there at all.

Using HIP for a purpose similar to LISP would be a slightly different story. Then all hosts would need to support HIP, either natively or through proxying [2]. However, still no modifications would be needed to applications. A global mapping would be needed, but I fail to see how its cost would be considerably higher than a corresponding mapping for LISP. Maybe someone can help me to understand how the investment or operational costs of a distributed, global HIT->IP address mapping service would be any larger than for a IP->IP mapping service?

Incidentally, I happened to write yesterday some raw text about what would be needed in order to make HIP a better solution to help with routing scalability. I'm copying that below, in its raw form. Take it with a grain of salt.

--Pekka

[1] http://www.ietf.org/internet-drafts/draft-ietf-hip- applications-01.txt
[2] http://tools.ietf.org/html/draft-nikander-ram-generix-proxying-00

As briefly mentioned in the end of Section XXX, the separation of identifiers and locators allows HIP to provide for locator agility. When HIP is used, the actual underlying IP addresses do not matter any more. Only the most central infrastructure services, such as DNS and Rendezvous servers, need to be reachable on well known addresses. However, it is conceivable that one could use pre-defined anycast addresses for such services, allowing the hosts to autoconfigure themselves more easily. In that way, the system bootstrapping information would be confined within the routing system and not exposed in the locator system at all. Such a practise would eventually lift pressure to hoard IP addresses or to stick to certain, pre-defined IP addresses, thereby allowing the routing system to assign the addresses in a topologically optimal way and to renumber whole networks rapidly as the topology changes.

Even if we don’t go that far as deprecating static IP addresses altogether, with the exception of a few well known anycast-based services, the routing system could benefit from wide spread use of HIP. As discussed above, the HIP mobility and multi-homing extension allows active hosts to signal changes in addressing without disrupting existing connections. Hence, in a situation where a network needs to be renumbered, if the network provides the nodes with new addresses slightly before the existing ones are deprecated, HIP would allow renumbering to take place in minutes rather than days or months, as it requires today. The only services that need to remain accessible longer at their existing addresses are the DNS and the Rendezvous.

From the routing system point of view, a big remaining problem is that HIP is unlikely to be deployed any time soon. One potential way to address this problem would be to add HIP proxies at strategic places in the system. Such proxies would allow large numbers of non- HIP-enabled hosts to appear as HIP-enabled to the rest of the network. Compared to some other approaches currently discussed at the IETF, a HIP-based approach appears better in the sense that there are also other incentives to implement HIP but to lift pressure from the routing system. Hence, it is easy to imagine that at least some end- nodes and a largish number of end-sites might be willing to invest in HIP proxies, while in the case of solely-routing based approaches the main pressure would need to be carried by the large ISPs, i.e., those that directly suffer the pain.

While it is relatively easy to see how HIP with its identifier / locator split and the mobility and multi-homing protocol could form a baseline for allowing the routing system to better manage IP addresses, as outlined above, the details of large-scale HIP proxying remains to be engineered. According to the present discussions, the following sore points would need to be addresses:

o In very large proxies the public key operations, as currently employed by HIP, may become a computational bottleneck. One potential approach would be to use the so called Light Weight variant of HIP (LHIP), defined by Tobias Heer [XXX], as the default protocol between HIP proxies. The main difference between LHIP and vanilla HIP is that in LHIP the public key operations are replaced with hash chains. As a result, the protocol is computationally much lighter, but it does not allow the Host Identities to be authenticated. However, as a fallback, LHIP allows an existing association to be upgraded to use full HIP, for example, in the case more than one host claims ownership to a single Host Identity.

o The only currently defined HIP data carrier protocol, ESP, appears excessive and unnecessary. However, as HIP allows new data carrier protocols to be defined, it would be relatively simple to support lighter alternatives, such as plain IP-in-IP wrapping [XXX] or the so called shim headers from the IPv6 multi-homing protocol SHIM6 [XXX].

o It is unrealistic to imagine that all sites would update their configuration files any soon, even if they would be placed behind HIP proxies. Consequently, even when most of the sites would have minimally upgraded to HIP by placing information about Host Identities and Rendezvous Servers into the DNS, some amount of vanilla IPv4 and IPv6 traffic would still reach the HIP proxies from the legacy side. Hence, there is a need to handle this remaining traffic even when the core network has been completely converted to HIP use and therefore unable to pass vanilla IP datagrams destined to legacy services. o At the baseline, a HIP proxies-based solution requires both that all hosts either upgrade to HIP or are placed behind HIP proxies and that the DNS and other configuration data is upgraded to include Host Identifiers and Rendezvous Servers. This is a clear drawback to some other proposals discussed in the IETF, which aim towards "jacking up" the IP stack by allowing hosts to continue to use their existing configuration while the core network uses new, differently allocated addresses. One potential way forward might be to allow existing IPv4 and IPv6 addresses to be used as host identifiers for remote hosts, such as servers. Hence, by simply installing a HIP proxy in the front of a legacy network, all the outgoing packets would be interpreted as containing "legacy-look-alike" host identifiers in their destination address. These look-alike identities would then be used in the LHIP protocol between the proxies. Unfortunately, there appears a number of thorny security problems related to such a practise; the exact details of the problems and their potential solutions fall beyond the scope of this paper.

Hence, we can say that number of problems and starting points exist.


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg