[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] RE: Is the flat identifier acceptable
|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.
to unsubscribe send a message to email@example.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