re: [RRG] RE: Is the flat identifier acceptable

[Xu Xiaohu <xuxh@huawei.com>]

Hi Tony,

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

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?

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

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. 

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

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



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