Subject: [rrg] critique of RANGI

From: Paul Francis <[email-masked]>
Date: Mon, 18 Jan 2010 11:44:45 +0100

Hi Gang,

I've attached a critique of RANGI.

PF

---

From: Tony Li <[email-masked]>
Date: Mon, 18 Jan 2010 07:18:55 -0800

> I've attached a critique of RANGI.

Received and incorporated.

Tony

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 18 Jan 2010 12:36:17 -0800

On Jan 18, 2010, at 2:44 AM, Paul Francis wrote:

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

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 19 Jan 2010 10:47:51 +0800

Hi Lixia and Paul,

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

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Lixia
Zhang
> 发送时间: 2010年1月19日 4:36
> 收件人: Paul Francis
> 抄送: RRG
> 主题: Re: [rrg] critique of RANGI
> 
> 
> (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
> reuse of existing IP6 transport implementation).  

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

> More thought is

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.

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

> not validating, so that the sender can avoid locator changes.

OK, I will consider it.

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

> 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

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.

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

> otherwise clean end-to-end model.

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

> RANGI only need address dealing with legacy IPv6, which it appears to

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

Thanks to your insightful comments, again.

Best wishes,
Xiaohu

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

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 18 Jan 2010 20:22:51 -0800

On Jan 18, 2010, at 6:47 PM, Xu Xiaohu wrote:
>> .....

sorry, I missed the "-n" fine print :(
In your RRG presentation at Hiroshima, the slide says n=64.  if that  
is still the case, then your local hostID would have the same length  
as ILNP EID (though the latter requires global uniqueness, and I  
suppose yours not)

> infrastructure to make the authoritative server scale better.

The Hiroshima RRG talk showed the other way around ...

> This is my

DHT is used for lookups for systems with very large number of entries.  
With a hierarchical system, where the bottom level is not that big, I  
wonder what is the value of using DHT in the first place.

I did not following the first sentence below (what do you mean by  
using "AD ID as a key"?)

> system has reasonable business model and clear trust boundaries.

Wonder if you have this described somewhere?
I did not find it in http://tools.ietf.org/id/draft-xu-rangi-01.txt

>> .....
>> ......

this sounds like as if having a FQDN for each host a drawback?

> unique FQDN for ID and locator lookup.

could you elaborate what may be the problem with this as you see?

> .....

Is it fair to say that RANGI-PROXY is a similar idea to LISP's PTRs?

I am trying to identify commonalities among proposals.

Lixia

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 18 Jan 2010 20:36:10 -0800

based on Xiaohu's comments here is a revision to fix the minor  
technical errors I made earlier (I want to get it right because Tony  
will incorporate into the collection)

Lixia
PS: going through the text I realized the phrase "using DNS reverse  
lookup" is a bit misleading -- it is NOT about lookup from IP address  
to DNS names as the phrase literally means.
-----------------
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 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.  
RANGI ID uses 8-byte for the administrative hierarchy. More thought is  
needed as to what constitutes these levels, the use of "DNS reverse  
lookup" vs DHT for the ID-Locator resolution and their relations to  
administrative boundaries.

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 19 Jan 2010 15:33:02 +0800

> 发件人: Lixia Zhang [mailto:[email-masked]]

> 发送时间: 2010年1月19日 12:23

> 收件人: Xu Xiaohu

> 抄送: RRG; Paul Francis

> >> I did not know that you were working on RANGI critique; as I

> >> mentioned

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

> > the RANGI

> suppose yours not)

Yes. To simplify the implementation, we use CGA as host identifier
currently. Hence the value of n is set to 64.

> > In fact, we use the reverse DNS infrastructure as the id/locator

> > mapping

> > assumption of a hierarchical DHT. IMHO, the hierarchical DHT doesn't

> > mean

> wonder what is the value of using DHT in the first place.

I don't want to introduce too many levels in the hierarchy. Hence, in a
given administrative domain (e.g., a state or a province), there may be a
lot of entries to manage.

> using "AD ID as a key"?)

A detailed example is given as follows:

1. An AD ID is expressed as "country-code.authority-code.region-code" by
inserting dots between adjacent fields, then it is transformed into a FQDN
format string as "region-code.authority-code.country-code".

2. The above FQDN format string is used as a key in the reverse DNS
infrastructure to locate the corresponding authoritative server or the DHT
ring for that AD. If DHT is used to scale the bottom-level authoritative
name servers, the Local Host ID part is used as a key to locate the
corresponding peer which stores the mapping of that identifier.

3. The Local Host ID part is used as a key to locate the matching mapping
entry in the mapping table of the corresponding name server or the
corresponding peer.

The following figure is a demonstration of the mapping system to be used in
RANGI.

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

> I did not find it in http://tools.ietf.org/id/draft-xu-rangi-01.txt

Details about the id/locator mapping system will be included in that draft
or described in a separate draft soon.

> >> 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 sounds like as if having a FQDN for each host a drawback?

Not sure whether it is a drawback. However, since there is already a global
unique host identifier for each host in RANGI, which can be easily used for
id->locator lookup, it seems no need to assign each host a unique FQDN.

> > Yes, I know. However, ILNP design requires that every host should

> > have a

> could you elaborate what may be the problem with this as you see?

The reason I can thought why ILNP requires each host has a unique FQDN is:
the flat EIDs to which the sessions are bound are not suitable for
EID->Locator resolution, so another namespace (i.e., FQDN) is referred to.

My doubt is how a legacy host continues the communication to an ILNP-aware
host once the latter changes its locator due to mobility or re-homing event.
Note that the legacy host will not resort the DNS to get the new locator of
the ILNP-aware host.

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

> Is it fair to say that RANGI-PROXY is a similar idea to LISP's PTRs?

To be more accurate, the site proxy is similar to LISP ITR while the transit
proxy is similar to LISP PTR.

Xiaohu

---

From: Paul Francis <[email-masked]>
Date: Tue, 19 Jan 2010 08:02:59 -0000

inline

[email-masked] wrote on 01/19/2010 05:36:10 AM:

> From: Lixia Zhang <[email-masked]>
> To: [email-masked]
> Date: 01/19/2010 05:36 AM
> Subject: [rrg] critique of RANGI: a revision
> Sent by: [email-masked]
> 

The ID->locator lookup is needed in any event.  Adding the locator to the 
FQDN->ID lookup is straightforward.  Your wording makes it sound like 
RANGI is opposed to returning both ID and locator in the FQDN, which I 
doubt is the case. 

My original text said:

The RANGI draft suggests FQDN->ID lookup through DNS, and separately an 
ID->locator lookup which may be DNS or may be something else.  I think it 
would be better if the FQDN lookup produces both ID and locators, and that 
it is sufficient that the ID->locator lookup be DNS.

I still kinda prefer the original wording, but if you want to include the 
comparison with ILNP, then how about this:

The RANGI draft suggests FQDN->ID lookup through DNS, and separately an 
ID->locator lookup which may be DNS or may be something else.  I think it 
would be better if the FQDN lookup produces both ID and locators (as does 
ILNP).  I also think that it is sufficient that the ID->locator lookup be 
DNS.

> Unfortunately the early-adopter incentive for host upgrade strikes me 

Adding the DFZ scaling sentence at the beginning of this paragraph 
produces a non-sequitur. 

More importantly, as Huawei mentioned in his last email, the rewriting is 
for incoming traffic engineering at multihomed sites, not for scaling DFZ 
routing.  I suggest we just remove the DFZ sentence (I'm not sure what 
point you are trying to make with it).

More generally, I wrote the initial critique in the first person, and 
included a few statements which are clearly meant to be my opinion rather 
than fact per se.  I was under the impression that there could be multiple 
critiques per proposal, each written by an individual or group.  Is this 
the case, or is there supposed to be one critique per proposal?  If the 
former, I'd prefer just to keep the critique as originally written. If the 
latter, then I'd like to modify the proposal to remove the first person 
perspective and opinions.

PF

---

From: Scott Brim <[email-masked]>
Date: Tue, 19 Jan 2010 03:17:20 -0500

I'm going to try to do some catching up ...

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

Speaking in general, not just about RANGI ... Falling back to the
mapping system would be adequate except that we also need
interoperability with others that don't speak your protocol -- either
because they are "legacy" or because your protocol has been superceded.
 As a general principle, any solution must include interoperating as a
major capability.

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 19 Jan 2010 00:23:30 -0800

On Dec 30, 2009, at 12:02 AM, Paul Francis wrote:
>> ....

I am trying to identify commonalities of mechanisms among different  
proposals.

> the case, or is there supposed to be one critique per proposal?

the latter, that's the only reason I changed your text

>  If the

please feel free to revise, and fix any errors you thought I introduced.

Lixia

---

From: Paul Francis <[email-masked]>
Date: Tue, 19 Jan 2010 09:59:57 +0100

Ok, here is the depersonalized RANGI critique.

PF

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 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.  More thought is needed as to what 
constitutes these levels with respect to these various roles.

The RANGI draft suggests FQDN->ID lookup through DNS, and separately an 
ID->locator lookup which may be DNS or may be something else (a hierarchy 
of DHTs).  It would be more efficient if the FQDN lookup produces both ID 
and locators (as does ILNP).  Probably DNS alone is sufficient for the 
ID->locator lookup since individual DNS servers can hold very large 
numbers of mappings.

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.

Architecturally there are many advantages to putting 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 
may not be adequate (HIP's lack of uptake being an example).

RANGI does not have an explicit solution for the mobility race condition 
(there is no mention of a home-agent like device).  However, host-to-host 
notification combined with fallback on the ID->locators lookup (assuming 
adequate dynamic update of the lookup system) may be 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).  These transition technologies are in any event being pursued 
outside of RRG and do not need to be specified in RANGI drafts per se. 
RANGI only needs to address how it interoperates with IPv4 and legacy 
IPv6, which through proxies it appears to do adequately well.

From:   Lixia Zhang <[email-masked]>
To:     Paul Francis <[email-masked]>
Cc:     [email-masked]
Date:   01/19/2010 09:24 AM
Subject:        Re: [rrg] critique of RANGI: a revision

Lixia

---

From: Tony Li <[email-masked]>
Date: Tue, 19 Jan 2010 15:41:19 -0800

Tony