Short version: It would be better if there were no locally unique
Identifiers and if Identifiers were guaranteed to be
globally unique - ideally via being hierarchically
allocated.
Still, when it comes to Mobility, it seems that
Xu Xiaohu's proposed attack, (which I dub "Identifier
squatting") means an ILNP Identifier can't be a first
class citizen.
Only perhaps with hierarchically assigned Identifiers
and with very expensive, global, cryptographic,
measures to control which lower 64 bits every host
gets (to be retrofitted to any IPv6 network an ILNP
host might want to roam to) might it be possible to
make ILNP Identifiers "first class". I think this
would probably be too onerous and slow to support
Mobility with a VoIP conversation in progress.
Hi Tony,
In "Re: [rrg] ILNPv6 Mobility problem" (msg07096 - and BTW, each
paragraph is a very long line in the archives) you wrote:
> In the real world, there are no perfect solutions. Why is
> everyone insistent on an architecture that solves all problems,
> even in the face of equipment that clearly does NOT follow
> existing architectures?
Further to Toni Stoev's message, one reason a person might expect an
architecture such as ILNP not to have basic flaws, such as I think
Xiaohu Xu pointed out, is we can think of other architectures with
fewer flaws. Another reason is that you and a few others are making
great claims for ILNP as being superior to any other architecture.
So it had better be good.
You wrote:
http://tools.ietf.org/html/draft-irtf-rrg-recommendation-08
These changes should be cleanly integrated, first-class
citizens within the architecture. That is to say that any new
elements that are integrated into the architecture should be
fundamental primitives, on par with the other existing legacy
primitives in the architecture, that interact naturally and
logically when in combination with other elements of the
architecture.
If ILNP continues to include an option for locally unique
Identifiers, then these will always be second-rate things compared to
a proper globally unique Identifier. As I wrote:
ILNP Identifier and Locator semantics are muddled and !crisp
http://www.ietf.org/mail-archive/web/rrg/current/msg07091.html
the inclusion of locally unique Identifiers means:
the true semantics of Identifier and Locator are muddled
and not at all crisp. Likewise, the ILNP functionality in
the stack will be much more complex.
I think that it would be no great loss to get rid of these locally
unique Identifiers.
Likewise, Identifiers which are not guaranteed to be globally unique
- as is currently the case with ILNP's lack of hierarchical
assignment of Identifier space - means these are not first-class
citizens.
This too is easily fixed - implement a hierarchical assignment system
like IP addresses today.
Then you could add a DNS system which is indexed on Identifier - to
return an FQDN (or more than one?) and one or more Locators. That
DNS system would be run by organizations which are responsible for
each subset of the Identifier namespace, just as is the case for
reverse DNS of IP addresses today.
As ILNP is today, I understand you can't look up an Identifier unless
you have a Locator which belongs with it, and only if the network
whose Locator this is implements its own reverse DNS, which has been
securely and promptly updated. Even then, you can't trust the
results - because there is no guarantee that this network was
correctly instructed. So you would have to get the resulting FQDN
and do the existing secure ILNP DNS lookup before you could get the
one or more Locators which are genuinely in use with this Identifier.
With hierarchically assigned Identifiers, the reverse DNS would be
authoritative - so only a single lookup would be required.
I don't understand why you, Ran and I guess others want to build a
host's Identifier from a hardware ID in the device itself. Saving on
administrative structures I guess.
You referred - "equipment that clearly does NOT follow existing
architectures" - to Ethernet interfaces with MAC addresses which were
not globally unique. This is only causes a clash, and therefore a
problem, if two devices with the same MAC are connected to the same
Ethernet.
Extending the reach of potentially duplicate MAC addresses and other
forms of hardware identification numbers directly to ILNP's
supposedly globally unique Identifier system seems like a bad idea to
me. Likewise, I think, to other people: Roland Bless (msg07092),
Mikael Abrahamsson (msg07094) and Klaas Wierenga (msg07095).
The current ILNP design makes a device's participation in a global
system - you intend it to be *the* global system - dependent on the
correct behaviour and configuration of other devices the world over.
So the clash scope is not a LAN - it is the entire world.
Unfortunately, I don't see a practical way you can make even a
hierarchically assigned, actually globally unique, Identifier into a
truly first-class entity - at least where Mobility is concerned. I
think every scalable routing solution should have very good support
for Mobility.
Because ILNP relies on new semantics for the IPv6 lower 64 bits, it
would be at least extremely expensive (msg07088) to make each /64
network robust against the attack Xiaohu Xu devised. Even if this
could be done, I think it would be too slow to support mobility in a
manner suitable for VoIP.
Xiaohu Xu's attack, which might be known as "Identifier squatting",
involves the attacker's host gaining publicly available information
about the victim host and then behaving in a manner which is
indistinguishable from an ordinary IPv6 host, or an ordinary ILNP host.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
