Short version: I think Tony misunderstands the "Identifier
squatting" DoS attack proposed by Xiaohu Xu:
msg07042 --> msg07057.
This vulnerability of ILNP mobility to a DoS
attack is quite independent of the questions of
1 - How to generate globally unique Identifiers
(from MAC addresses etc. or via hierarchical
assignment).
2 - How locally unique Identifiers cause great
complexity for the ILNP stack, and make ILNP's
Locator and Identity semantics seriously
muddled.
Tony also states that ILNP has no known faults.
I list some of what I consider to be its faults.
Hi Tony,
Thanks for your detailed reply, in which you wrote:
>> 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).
That's a matter of opinion. In addition to the "Identifier squatting"
DoS vulnerability for mobile ILNP which Xiaohu Xu proposed, these
come to mind:
1 - Extra delays establishing communication sessions,
extra packets and/or longer packets, plus extra CPU
effort for all hosts. (Common to all CEE Loc/ID Separation
architectures.) msg07017.
2 - No prospects of wide enough voluntary adoption to provide
substantial benefits to adoptors or to scalable routing - due
in part to the benefits arising only when essentially all
hosts have adopted it:
http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/
3 - Applicable only to IPv6, since ILNPv4 requires all DFZ and
other routers be upgraded to handle the new header option.
4 - Identifier uniqueness is brittle due to dependence on host-
generated identifiers from MAC addresses and the like, which
may not be unique. Also, it is not assured that all hosts
now or in the future have any unique hardware from which
to derive a unique hardware identifying number
5 - Inability to look up an Identifier to find its one or more
Locators. This is because neither type of Identifier:
a - MAC-etc. generated supposedly globally unique.
b - However generated and only locally (within a /64) unique.
is suitable for creating an kind of lookup system, such as
one based on DNS, which is indexable on Identifier. Please
see my previous msg07099 for discussion of this.
In today's IP protocols, the IP address is both the Identifier
and the locator, so a host can use this to send a packet, with
the knowledge that the packet will either get to the host
which has this identity, or will be dropped and therefore not
delivered to a host with any other identity.
Therefore (according to my potentially faulty understanding),
ILNP relies on starting with a FQDN or from an Identifier-
Locator pair, where the /64 of this Locator has a correctly
updated reverse DNS, which will return an FQDN. Then, you look
up the FQDN to reliably obtain the one or more Locators which
are currently used by the host with this Identifier.
That said, in IPv6, ILNP does not involve longer packets - which is a
blessing compared to CES architectures which use encapsulation.
ILNPv4 does involve longer packets, but this should not cause as much
trouble with Path MTU Discovery as a CES architecture which uses
encapsulation, since the sending host adds the option - the packet is
not made any longer in transit.
An ILNP-aware stack is intended to work with existing applications -
while some other CEE architectures (such as Name Based Sockets)
require applications to be rewritten, which would raise a still
steeper barrier to any level of adoption. Furthermore, I think such
rewriting would force changes to some application protocols, with the
new protocols probably being less efficient. So the NBS-compatible
version of the application would not be backwards compatible with the
original protocol.
As long as ILNP supports all current applications (which remains to
be seen), it should be able to support all existing protocols. If
this can be done, I think these protocols will run slower (at least
in the initial exchanges) under ILNP than they do on native IPv6.
Some protocols may become very slow and inefficient under ILNP, such
as any protocol which involves UDP packets flying back and forth
between a large number of hosts, rather than concentrating on simple
two-way sessions. This should probably count as a flaw too.
> 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.
Can you cite an instance where people are expecting ILNP to be more
secure, or better in any way, than IPv6 today?
I can't think of anyone expecting this.
ILNP's mobility is unlike anything in IPv4 or IPv6 today, but it is
reasonable to expect that it doesn't introduce a simple DoS
vulnerability like we have been discussing.
>> 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.
OK - hence the title of this thread. Therefore, this option in ILNP
doesn't accord with the text you wrote in the RRG Recommendation,
regarding the architecture using constructs which are first-class
citizens.
> 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.
"Many" is a big word. Can you document this?
Who really cares about the ability of an IPv6 host to repeatedly
choose a fresh lower 64 bits for its IP address, thereby breaking
all sessions, but supposedly achieving a degree of privacy not
possible if it retains the one set of bits?
Just because it is an option in IPv6 doesn't mean anyone was
clamouring for it (maybe some were - I wasn't involved in IPng), or
whether anyone uses it now or would use it if IPv6 was widely adopted.
> I concur that this needs to be an option for those that want it.
OK - but it makes the host stack much more complex, because there are
two classes of Identifier, and for locally unique ones, there are all
sorts of combinations for host AAAA to consider when communicating
with a host BBBB which has an identifier which is only locally unique:
DNS lookup of FQDN returns BBBB with locators XXXX and YYYY.
AAAA needs to distinguish this BBBB from any other hosts it is
communicating with which also have an Identifier BBBB, and which
have different Locators. So the semantics are not at all
"crisp and clean".
Also, AAAA needs to cope with the situation of its own Identifier
being locally unique, but communicating with one or more other
hosts whose Identifier is also AAAA.
When AAAA receives a packet from XXXX-BBBB it can't just send a
packet back to that address, as if that packet would definitely
reach the host whose Identifier is genuinely BBBB. It first
needs to use BBBB to securely find which Locators the real BBBB
host currently uses.
Since there is no ability to look up anything based on just an
Identifier (as noted above, due to the lack of hierarchical
assignment of Identifiers) AAAA must do a reverse lookup of
the IP address XXXX-BBBB. That will only be possible if the
XXXX /64 network runs reverse DNS with ILNP extensions and
has had its information correctly set up. This will return
a FQDN and perhaps some Locators. If the reverse DNS can't be
assumed to be totally up-to-date with Locators, then AAAA needs
to use the FQDN via the main secure ILNP DNS extensions to look
up the Identifier (which should be BBBB) and potentially multiple
Locators. Only then can host AAAA know how to send a packet to
the host whose Identifier really is BBBB in the XXXX /64 without
a chance that the packet will arrive at any other host.
All this is mandatory, since the ILNP stack is required to
support existing applications - and existing applications
assume that sending a packet to any host whose Identity is
that of a particular IP address will not result in the
packet being received by any other host. (This is discussed
in msg07017 too.)
I guess there would be other complications - I haven't tried to think
of every one. I assume that a host using XXXX-BBBB can communicate
with hosts in /64s other than XXXX - otherwise, this would be no use
for privacy. So three hosts all with the same Identifier, locally
unique in their own /64s, and so with IP addresses XXXX-BBBB,
YYYY-BBBB and ZZZZ-BBBB should all be able to communicate.
Compare this complex, muddled, semantics for "Locator" and
"Identifier" with the text I quoted from Ran's I-D in msg07091 - and
you will see that most of the ILNP explanation assumes crisp, clear,
semantics which are impossible with Identifiers which are only
locally unique.
However, I understand you want to retain locally unique Identifiers
as an option, in the knowledge they can't be used for Mobility -
primarily or purely for its ability to provide some anonymity (AKA
privacy) when used on the global Internet.
I guess this may help with the privacy aspect, since the one host
could regularly change its Identifier (breaking sessions, of course)
and so avoid leaving a pattern of the same IP address and therefore
the one ILNP Identifier at servers all around the world. Still, as
long as this all happens in a single /64, the privacy benefits are
limited - dependent largely on how many other broadly similar usage
patterns are observed by the servers in hosts with other IP addresses
in the same /64.
I am a privacy advocate and I was never much impressed by IPv6's
option for rapidly changing lower 64 bits as a privacy enhancement
measure.
I think you could get much the same level of privacy by having the
host switch between a large number of pre-existing globally unique
Identifiers. All will use the same /64 prefix for their Locators, I
guess - so this would be equivalent to the current "privacy"
arrangements in IPv6.
The host needs access to some very large pool of such Identifiers,
each with a usable Locator. But there's plenty of Identifier space
in 64 bits, so this should not be a problem.
To maximise privacy properly in this manner, the host would probably
want to choose between Identifiers from multiple different
organisations - multiple divisions of the Identifier hierarchy.
Still, the Locator will be the same /64, and it would be well known
to enquiring minds poring over the logs of one or more servers which
parts of the Identifier space were frequently used in this way.
(BTW, see http://panopticlick.eff.org for how a Java applet, I
guess, reports browser plugins, screen size, system fonts etc.
which will frequently identify individual hosts.)
I think IPv6's "privacy" arrangements are pretty weak. I can't think
of anything much better in any architecture, short of using TOR or an
anonymizing proxy. Perhaps what I suggest above - switching between
a bunch of Identifiers from various parts of a hierarchically
assigned Identifier space - would be judged somewhat less
satisfactory than the existing IPv6 arrangements, but I think they
are not much value anyway.
I guess there is no documented use of the existing IPv6 privacy
functions, partly because these folks don't want to talk about it and
also because so few people use IPv6.
I still think ILNP would be significantly improved by getting rid of
locally unique Identifiers and using only globally unique,
hierarchically assigned Identifiers.
> 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.
OK.
> Based on the behavior of most people today, I would expect that
> 99% of the population would continue to use globally unique
> identifiers.
I agree - I think the actual utilization of these locally unique
identifiers would be so low as to not justify the great complexities
in the ILNP stack which are required to support it.
As I wrote recently:
ILNP Identifier and Locator semantics are muddled and soggy
http://www.ietf.org/mail-archive/web/rrg/current/msg07091.html
I believe you can't claim that the Identifier and Locator semantics
are crisp and clear as long as you allow these locally 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.
Yes - but good architecture is robust and not overly dependent on
correct configuration of external systems. As far as I know, the
only way to get robustly globally unique Identifiers involves
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.
Can you cite any actual examples? I know sometimes by accident or
design a whole prefix is advertised in the DFZ in a way which hijacks
traffic from the router which properly advertises this prefix. That
is not altered by any of the proposed architectures. But that kind
of attack is generally very public, easy to detect and at odds with
accepted standards of router administration.
>> 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'.
Sure, but they are localised to Ethernets or whatever non-globally
significant domains a MAC address is used.
> Again, this problem is independent of ILNP and it's unreasonable
> to suggest that ILNP solve it.
Neither I nor anyone else is expecting ILNP to solve problems caused
by MAC clashes.
There have been three lines of discussion here - which have been
somewhat entwined:
1 - The DoS attack I call "Identity squatting", as proposed by
Xiaohu Xu. This has nothing to do with MAC addresses. It
doesn't matter whether the supposedly globally unique
ILNP Identifier results from hierarchical assignment,
MAC addresses, or radioactive decay.
It is an intentional attack which Steven Blake acknowledges as
real, against a victim host going mobile to another /64. It
is based on publicly available information about the victim
host (its Identifier). To any IPv6 or ILNP-enhanced IPv6
network, the actions of the attacker are indistinguishable
from the ordinary behaviour of an IPv6 or ILNP host.
2 - Problems resulting from non-hierarchical assignment of
Identifiers - specifically the current plan of using a
MAC address or some other hardware identifier to generate
the Identifier, in a direct, deterministic, manner by the
host itself.
Several folks have written about MAC addresses not being
unique, and of (virtual) hosts not having any unique
hardware to gain a MAC address or any other globally
unique number from.
Since you want the ILNP identifiers to be "first class",
I think you need to avoid this MAC address etc. reliance
and use another approach. The only approach I can imagine
working is hierarchical assignment.
3 - The problems arising from allowing locally unique Identifiers
no matter how the Identifiers are generated.
>> 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.
But that rules out mobility. I and I guess many other people believe
that a scalable routing solution without mobility is a non-starter.
Keeping the option of locally unique Identifiers will make writing
the stack code a can of worms.
Because Ran and I think you set such an elevated threshold between
"architecture" and "engineering" and since it seems the details of
the stack code fall into the latter - which you have little interest
in - I don't think you have fully considered what a horror it will be
to write this stuff, and somehow support existing applications with
the assumptions they currently make about the properties of IP addresses.
>> 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.
I think you are failing to distinguish between what I am discussing
here - the "Identifier squatting" attack (1) - and the matter of
whether supposedly globally unique Identifiers result from
hierarchical assignment or are generated by each host from a MAC
address or the like (2).
It doesn't matter how you generate globally unique Identifiers or
whether or not they are in fact globally unique - the "Identifier
squatting" attack will still work.
>> 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.
Not counting international roaming and switching from one 3G/GSM
network to another (which may clobber the call, for all I know) the
situation with cellphone companies is rather different than what
would be required to protect ILNP from the "Locator squatting" attack.
The cellphone companies run their own access network so the whole
thing is integrated.
Global mobility of the kind that ILNP aims to provide (as does TTR
Mobility, and now Fred Templin's IRON, using similar techniques)
requires that the host be able to use some access network which has
no relationship with the Mobility provider. The access network
cannot be assumed to have any special mechanisms.
To prevent the "Locator squatting" attack, every protected access
network would need to prevent a host getting a lower 64 bits QQQQ
until one of these was true:
1 - The system had determined that QQQQ was not used as a
globally unique ILNP identifier by any host whatsoever.
(This could only be done with an Identifier indexed lookup
system, which I think would only be possible if all
Identifiers were hierarchically assigned.)
This would require an explicit negative response from a
single global lookup system.
2 - The lookup indicates that QQQQ is being used as an ILNP
Identifier. Then the routing system needs to engage in
a cryptographically secure exchange with the host, and
probably with whichever organisation administers this
part of the Identifier hierarchy, so that the host can
prove it is authorized to use this Identifier.
So this would involve retrofitting every IPv6 network which could be
used for mobility, in order to protect against this attack.
My impression is that this is bound to be slower than whatever the
cell-phone companies do - since they are running their own access
networks which include the authentication stuff for their customers -
and which are more tightly integrated (than what I suggest above)
with other cellphone companies for the purpose of supporting roaming.
>> 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.
I think you do not understand this attack. It has nothing at all to
do with MAC addresses. It is arguably spoofing an ILNP Identifier,
since there is nothing to prevent this from happening at present.
The attack only works if the attacker moves first and grabs the IP
address with the victim's Identifier in the lower 64 bits before the
victim's host attempts to use ILNP Mobility to connect to the same
/64 in which the attackers host is based.
The attacker can't cause any trouble if the victim's host gets this
address first.
This attack is only very vaguely related to 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.
Sure - but the attack has nothing to do with MAC address spoofing.
Steve seems to understand the attack and has acknowledged it is real:
http://www.ietf.org/mail-archive/web/rrg/current/msg07086.html
"I acknowledge that this attack exists."
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
