On Jan 18, 2010, at 2:44 AM, Paul Francis wrote:
Hi Gang,
I've attached a critique of RANGI.
PF
<rangi-critique.txt>
Hi Paul,
I did not know that you were working on RANGI critique; as I mentioned
to Xiaohu I could do one.
So what I just did now is some minor additions to your text
(1)pointing out that RAGNI ID is 24-byte long, (2)doing ID looking
using DHT raises trust issue; (3)in routing scalability its scheme is
similar to ILNP.
see attached below, see you still agree with it.
Xiaohu, please comment if I get any technical point wrong.
Lixia
--------
RANGI critique
RANGI is an ID/locator split protocol that, like HIP, places a
cryptographically signed ID between the network layer (IPv6) and
transport. Unlike the HIP ID, the RANGI ID has a hierarchical
structure that allows it to support ID->locator lookups. This
hierarchical structure addresses two major weaknesses of the flat HIP
ID: the difficulty of doing the ID->locator lookup, and the
administrative scalability of doing firewall filtering on flat IDs.
The usage of this hierarchy is overloaded: it serves to make the ID
unique, to drive the lookup process, and possibly other things like
firewall filtering. To accommodate the administrative hierarchy, RANGI
ID is 24-byte long, which requires new implementation of protocol
stacks on all hosts (in contrast to HIP's 16-byte ID which allows
reuse of existing IP6 transport implementation). More thought is
needed as to what constitutes these levels, and what is the trust
relation among the ID-Locator resolution servers that use DHT for
lookup.
The RANGI draft suggests FQDN->ID lookup through DNS, and separately
an ID->locator lookup which may be DNS or may be something else. This
represents additional cost compared to ILNP design where FQDN lookup
produces both ID and locators. Can one quantify the gain by one
additional lookup to justify the cost?
RANGI provides strong sender identification, but at the cost of
computing crypto. Many hosts (public web servers) may prefer to forgo
the crypto at the expense of losing some functionality (receiver
mobility or dynamic multihome load balance). While RANGI doesn't
require that the receiver validate the sender, it may be good to have
a mechanism whereby the receiver can signal to the sender that it is
not validating, so that the sender can avoid locator changes.
In terms of scaling the DFZ routing, RANGI's solution closely
resembles that of ILNP based on locator rewrite at border routers.
Architecturally it seems best to put the mapping function at the end
host (versus at the edge). This simplifies the neighbor aliveness and
delayed first packet problems, and avoids stateful middleboxes.
Unfortunately the early-adopter incentive for host upgrade strikes me
as weak at best.
RANGI suffers from the mobility race condition (there is no mention of
a home-agent like device), though my personal opinion is that host-to-
host notification combined with fallback on the ID->locators lookup
(assuming adequate dynamic update of the lookup system) is good enough
for the vast majority of mobility situations.
RANGI uses proxies to deal with both "legacy IPv6" and IPv4 sites.
RANGI proxies have no mechanisms to deal with the edge-to-edge
aliveness problem. The edge-to-edge proxy approach dirties-up an
otherwise clean end-to-end model.
RANGI exploits existing IPv6 transition technologies (ISATAP and
softwire), but it seems to me that these transition issues are
orthogonal and don't need to be specified in RANGI drafts per se.
RANGI only need address dealing with legacy IPv6, which it appears to
do adequately well.
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
