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 [EMAIL PROTECTED] 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
