Hi Robin,
> 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.
ILNP has no basic flaws (as known to date). However, people seem to want to
reset the bar for it. ILNP already stipulates:
"the security properties
of the new proposal are never worse than for existing IPv6."
ILNP does not fix IPv6's (or IPv4's) security problems. It does not fix a MITM
attack. It will not prevent a DoS attack. It will not prevent SYN floods. It
will not fix prefix theft. It does not prevent L2 (MAC) layer spoofing. It
will not prevent Google from snooping your WiFi. And while it may be an
adequate sleep aid (sorry Ran), it is neither a dessert topping nor a floor wax.
> 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.
Agreed. However, we cannot introduce new security problems. Back when 8+8/GSE
was originally introduced, security folks pointed out that if hosts were
constrained to ONLY use a global identifier, then Bad Guys could track a host.
Privacy advocates were rightly concerned, and in today's environment of even
more sensitivity to privacy, that ILNP hosts (and their users) would
effectively have no privacy.
This will not fly.
Now I, and many others, don't particularly care. However, the fact of the
matter is that there are MANY others who do care. I concur that this needs to
be an option for those that want it. This implies that there needs to be a
mechanism for local identifiers, as Ran has proposed. As I've previously
mentioned, once you use a local identifier, you give up session continuity
across mobility. This seems only reasonable: if you want privacy, you can't
really expect the 'net to also track your movements.
Based on the behavior of most people today, I would expect that 99% of the
population would continue to use globally unique identifiers.
> 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.
Exactly. Good architecture does not introduce unnecessary bureaucracy. IPv4
addresses are hierarchically assigned and should be unique. Has anyone done
any significant amount of networking work and not seen duplicates?
Hierarchical assignment is also an imperfect solution.
> 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.
The basis of this problem is not small. Today, many folks are working on VM
migration for data centers. The lack of a globally unique MAC address in VM
implementations is causing some truly annoying problems, giving rise to some
very hacky 'solutions'.
Again, this problem is independent of ILNP and it's unreasonable to suggest
that ILNP solve it.
> 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.
Not at all. It only requires that hosts that choose to use a locally unique
identifier ensure that it is locally unique.
> 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.
Ergo, we use the EUI-64.
> 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.
Cell companies have already proven otherwise. It is possible to make the link
layer include sufficient authentication so that knowledge of a MAC address (or
any other on-air bits) is insufficient.
> 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.
The attack is already well known as MAC address spoofing. Again, ILNP does not
address it. Both Steve and I have pointed out the well known mechanisms to
address the problem.
You have not disagreed with any of those points.
Regards,
Tony
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
