Re: [rrg] critique of RANGI

[Xu Xiaohu <[e-mail]>]

Hi Lixia and Paul,

Thanks for your valuable critiques. My responses are in line.

> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]] 代表 Lixia
Zhang
> 发送时间: 2010年1月19日 4:36
> 收件人: Paul Francis
> 抄送: RRG
> 主题: Re: [rrg] critique of RANGI
> 
> 
> 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, 

No, RANGI ID is 16-byte long. The following is a demonstration of the RANGI
ID.

       |<------- n bits --------->|<-- 128-n bits-->|
       +--------------------------+-----------------+               
       | Administrative Domain ID |   Local Host ID |               
       +--------------------------+-----------------+               
       |                            \                               
       |                              \                             
       |                                \                           
       |                                   \                        
       |                                      \                     
       +-----------+-------------+-------------+                    
       | Country ID| Authority ID| Region ID   | <------Example     
       +-----------+-------------+-------------+                    
                                                                    

(2)doing ID looking
> using DHT raises trust issue; 

In fact, we use the reverse DNS infrastructure as the id/locator mapping
system, while the DHT is optionally used at the bottom level of this
infrastructure to make the authoritative server scale better. This is my
assumption of a hierarchical DHT. IMHO, the hierarchical DHT doesn't mean
DHT should be used in each level.

The structured AD ID is used as a key in the reverse DNS infrastructure to
locate the corresponding super authoritative server (or the corresponding
DHT ring when using DHT to make the authoritative server scale better) which
maintains mappings for the identifiers belonging to that Administration
Domain. If DHT is used to scale the authoritative server, the Local Host ID
(flat label) is then used as a key in that corresponding DHT ring to locate
the node which holds the mapping for that identifier. Hence, this mapping
system has reasonable business model and clear trust boundaries.

(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).  

No. RANGI host identifier is a 16-byte long label. Please see the above
statement.

> 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

Yes, the reverse DNS is used as an ID->locator mapping system in RANGI, with
this approach there is no need for every host to have a unique FQDN.

> 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?

Yes, I know. However, ILNP design requires that every host should have a
unique FQDN for ID and locator lookup. 

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

OK, I will consider it.

> In terms of scaling the DFZ routing, RANGI's solution closely
> resembles that of ILNP based on locator rewrite at border routers.

In fact, ID/locator split is the key to solve the routing scalability issue.
For a host located in a multi-home site, multiple PA locators will be
allocated to it. Then the host could choose one as the source locator (i.e.,
the source address in the IPv6 header) of the outgoing packet. Upon
receiving the above packet, the border router needs to perform source-based
policy routing.

As for rewriting the source locator of the outgoing packets by the border
router, it is used to realize the site-controlled traffic-engineering.
That's to say, the source host could suggest the upstream ISP path by using
the locator from that ISP as source locator, while the border router has the
final decision on the path selection since it could rewrite the source
locator of the outgoing packets before performing source-based policy
routing.

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

Yes, the above are the major reasons why the mapping function is put on the
end hosts in RANGI.

> Unfortunately the early-adopter incentive for host upgrade strikes me
> as weak at best.

We have the RANGI-PROXY [I-D.draft-xu-rangi-proxy-01] mechanisms with which
legacy hosts could initiate communications to RANGI-aware hosts, and vice
verse.

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

In the RANGI-PROXY draft, there is some description about the transit proxy
which is a home-agent like device. For more details, please see the section
2.2 of [RANGI-PROXY] "Communication between IPv6 and RANGI hosts without
Site Proxy".

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

Yes, the edge-to-edge aliveness issue should be explored in the latter
revision.

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

Sound reasonable. I will consider it in the latter revision.

Thanks to your insightful comments, again.

Best wishes,
Xiaohu

> _______________________________________________
> rrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/rrg