Subject: [RRG] Is the flat identifier acceptable

From: Xu Xiaohu <[email-masked]>
Date: Thu, 24 Jul 2008 11:55:28 +0800

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Jari Arkko
> 发送时间: 2008年7月23日 22:18
> 收件人: Dino Farinacci
> 抄送: [email-masked]; 'RJ Atkinson'; 'IRTF Routing RG'
> 主题: Re: [RRG] IEEE EUI-64 as an Identifier format
> 
> Dino,
> 
> > However, you get zero aggregation of ID space with EUI-64 assignments.
> > Not good for a mapping database.
> 
> Yes. But I suspect that wishes about the aggregatability of the ID space
> are similar to past wishes about aggregatability of addresses. I.e.,
> wishes that do not necessarily become true.
> 
> Note that aggregation of the ID space can come in two ways: ability to
> map range of IDs belonging to an organization vs. ability map an
> individual host's ID. I would suggest that we need the former. The
> latter would replace current scalability and aggregation problems with
> different scalability and aggregation problems.

Besides of the above mentioned issue, there are also some other issues with the flat identifier:

1) Burden the control policy configuration.

Since the flat identifier has no hierarchy, it's hard to enforce identifier-block based security control policy on firewalls. That's to say, only host granularity access control list is available.

2) Lack of trust and economic model in the id/locator mapping system.

Since these flat identifiers are randomly scattered across the namespace and stored at essentially random nodes, the id/locator resolution infrastructure has no "pay-for-your-own" model, unless the id/locator resolution infrastructure is managed by one and only one authority. 

So I wonder whether the flat identifier is acceptable for the id/locator split architecture. 

Xiaohu Xu

--
to unsubscribe send a message to [email-masked] 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

---

From: "Tony Li" <[email-masked]>
Date: Wed, 23 Jul 2008 21:53:50 -0700

Hi Xiaohu,

|1) Burden the control policy configuration.
|
|Since the flat identifier has no hierarchy, it's hard to 
|enforce identifier-block based security control policy on 
|firewalls. That's to say, only host granularity access control 
|list is available.

True, but even with aggregatability, you still have an issue.  What happens
when the aggregation mechanism doesn't match your desired identifier block?
Not everyone is clever enough to allocate addresses to match their security
policies and the results are predictable: really long ACLs.  

In fact, what you're asking for is another semantic overload: easy grouping
of identifiers for instantiating security policy.  Isn't that the same type
of problem that got us here in the first place, with a semantic overload
between transport and routing?

Perhaps security should be set based.

|2) Lack of trust and economic model in the id/locator mapping system.
|
|Since these flat identifiers are randomly scattered across the 
|namespace and stored at essentially random nodes, the 
|id/locator resolution infrastructure has no "pay-for-your-own" 
|model, unless the id/locator resolution infrastructure is 
|managed by one and only one authority. 
|
|So I wonder whether the flat identifier is acceptable for the 
|id/locator split architecture. 

Again, not all proposals seem to require an id to locator mapping.  If none
is needed, then there is no need to pay for it.

Tony

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 24 Jul 2008 13:47:25 +0800

Hi Tony,

> policies and the results are predictable: really long ACLs.

As I remembered, in the earlier thread about what we have reached consensus
on, most people believe that the identifier should be aggregatable. Is my
memory correct?

> between transport and routing?

I think the passport ID in real life is a good example for the host
identifier, since the passport ID has a hierarchy, it's easy to enforce
organization-level allocation, management and security control. 

> is needed, then there is no need to pay for it.

Yes, shim6 alike proposals do not need a resolution infrastructure. However,
those proposals alone can not support mobility since there is no such
id-locator indirection infrastructure. Some other proposal does not need an
id-locator mapping infrastructure. However, it requires every host to have a
FQDN name. In nature, the FQDN name plays the role of the identifier in the
resolution infrastructure, on behave of the IDENTIFIER of the session. This
way, two name entities together play the role of the identifier, with each
one of them suitable for different context.

Xiaohu XU

---

From: "Tony Li" <[email-masked]>
Date: Wed, 23 Jul 2008 23:09:31 -0700

|As I remembered, in the earlier thread about what we have 
|reached consensus
|on, most people believe that the identifier should be 
|aggregatable. Is my
|memory correct?

Ummm.... No.  I don't believe that we did a consensus check on that.  There
were some opinions, but I don't believe it was a represenative sample.

|I think the passport ID in real life is a good example for the host
|identifier, since the passport ID has a hierarchy, it's easy to enforce
|organization-level allocation, management and security control. 

Dunno about your passport, but mine doesn't say anything except something
about the issuing post office.

|Yes, shim6 alike proposals do not need a resolution 
|infrastructure. However,
|those proposals alone can not support mobility since there is no such
|id-locator indirection infrastructure. 

?  Such an infrastructure is not a requirement, and we derated the mobility
requirement some time ago.

|Some other proposal 
|does not need an
|id-locator mapping infrastructure. However, it requires every 
|host to have a
|FQDN name. In nature, the FQDN name plays the role of the 
|identifier in the
|resolution infrastructure, on behave of the IDENTIFIER of the 
|session. This
|way, two name entities together play the role of the 
|identifier, with each
|one of them suitable for different context.

And since the FQDN does aggregate nicely, there's no problem.

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 24 Jul 2008 09:58:56 +0200

On 24 jul 2008, at 6:53, Tony Li wrote:

> What happens

If we accept the desire to base security policies on identifier  
semantics as a requirement we're going to get nowhere fast.

---

From: "William Herrin" <[email-masked]>
Date: Thu, 24 Jul 2008 07:04:11 -0400

On Thu, Jul 24, 2008 at 1:47 AM, Xu Xiaohu <[email-masked]> wrote:
> Some other proposal does not need an

If you you change the IP address so it has -only- locator semantics,
what makes you think a DNS A record -isn't- an id, and the DNS -isn't-
an id-locator mapping infrastructure?

Regards,
Bill

-- 
William D. Herrin ................ [email-masked] [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Jul 2008 09:33:10 +1200

> semantics as a requirement we're going to get nowhere fast.

Agreed. After all, if you do a serious job on trust mechanisms
and verifiable identities, you'll end up re-inventing X.509
certificate semantics, and that probably won't fit into 128 bits.

I haven't followed HIP for quite a while, but something tells me
those people must have had this conversation a few years ago.

   Bria

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 24 Jul 2008 18:30:21 -0700

>> wishes that do not necessarily become true.

Well, it came true for LISP using LISP-ALT. But you have to use all  
128-bits and not the low-order 64-bits which is random and flat. If  
you are flat then there is a mapping entry for every host in the  
Internet. Clearly a non-starter.

> Since the flat identifier has no hierarchy, it's hard to enforce  
> identifier-block based security control policy on firewalls. That's  
> to say, only host granularity access control list is available.
>
> Since these flat identifiers are randomly scattered across the  
> namespace and stored at essentially random nodes, the id/locator  
> resolution infrastructure has no "pay-for-your-own" model, unless  
> the id/locator resolution infrastructure is managed by one and only  
> one authority.
>

Agree with your points.

Dino

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 25 Jul 2008 10:36:33 +0800

> > id-locator mapping infrastructure. However, it requires every host to
have
> a

Hi Bill,

I agree with your points. But what I referred to in the above text is some
proposal like GSE/ILNP in which the IP address is split into locator and
identifier. Due to the lack of an independent id/locator mapping system, it
still depends on the DNS to resolve the map between id and locator. And so
it requires every host to have a FQDN name which, in nature, plays the role
of the identifier to some extent. 

Xiaohu XU