Short version: A long exchange with Tony, regarding various things
including the effectiveness of changing the lower
64 bits in an IPv6 address (either for IPv6 or as
Identifier changes for ILNP) and how this supposedly
helps with privacy / anonymity.
I think it doesn't help much - but I can't think of
any robust system which assures such privacy /
anonymity.
Tony attests that this approach is strongly desired
by many people, but the only documented evidence of
this he cites is the archives of a mailing list
which closed in 1997.
To achieve this frequent change of Identifier, ILNP
uses locally unique Identifiers - and I am sure this
makes the ILNP stack much more complex. I am sure it
makes the semantics of Locator and Identifier
horribly messy, when Ran attests they are "crisp and
clear". Tony agrees that the locally unique
Identifiers are not "first class citizens".
Despite repeated discussions, Tony seems to think
that the "Identifier squatting" DoS attack against
ILNP mobility, developed by Xiaohu Xu, is identical
to MAC spoofing on a LAN. I tried to explain in
several ways that it is not, but Tony attests that
it is the same thing, and that I don't understand
this attack.
His defence against the attack would not work.
Yet Steve Blake agrees the attack is real.
Hi Tony,
Thanks for your detailed reply, in which you wrote:
>>> ILNP has no basic flaws (as known to date).
>>
>> That's a matter of opinion.
>
> That's correct. While your opinion does not match mine, you
> happen to be incorrect.
OK - I'll bite:
I think there is no objective test for whether ILNP has any flaws
which doesn't rely on people's opinions. Can you nominate one?
>> 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.
>
> ILNP resolves its mapping as part of normal DNS lookups. There are
> no extra sessions and no extra packets during connection setup.
So you disagree with my argument:
"Overloading" of Loc & ID functions is good for hosts and should
be maintained
http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html
I will write another message in that thread and attempt to explain
it, specifically for ILNP.
>> 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/
>
> The lure of seamless mobility is ample motivation.
Yes, but ILNP only provides mobility for communications with other
ILNP hosts, of which there initially very few.
By contrast, TTR Mobility - as would be implemented with Ivip and now
I think IRON - supports communication sessions with all hosts: all
IPv4 or IPv6 hosts which are not in upgraded networks, as well as all
Ivip/IRON hosts, mobile or not.
I don't recall you giving a critique of this page, yet some other
folks found it to be a reasonable statement of the barriers to
widespread adoption, in the form of constraints on architectures such
that they may be widely enough adopted to solve the routing scaling
problem.
Core-Edge Separation architectures are much more capable of meeting
these constraints. I think Ivip meets them and LISP, ideally, would
too - but I don't think it would work as well. Perhaps IRON could
meet them too.
I think ILNPv6 fails to meet constraints 1 to 5 and that ILNPv4 fails
to meet constraints 1 to 6.
1 - The solution must provide immediate and
compelling benefits to any new or existing
end-user networks which adopt it, irrespective
of how many other networks have so far adopted
it.
ILNP multihoming and mobility only works for sessions with other ILNP
hosts, which will initially be a very small proportion of hosts. So
except perhaps within particular inter-communicating groups of users
who all adopt ILNP, there is little or no benefit to early ILNP
adoptors. So there's no strong reason for most people to adopt it
and user numbers will remain low indefinitely.
2 - Therefore, it must provide multihoming, TE and
portability for the adopting networks in a
manner which fully supports communications with
all hosts - including all hosts in non-upgraded
networks.
Likewise, ILNP's benefits don't extend to sessions with non-upgraded
hosts.
3 - Therefore, the solution must be compatible with
all hosts (stacks and applications) and routers
in non-upgraded networks.
As above.
4 - The solution must be compatible with all
existing applications in the adopting networks.
While ILNP is not supposed to require new applications, its benefits
only apply to communications with applications running in hosts with
upgraded stacks.
5 - Although in principle, some or many host stacks
could be upgraded in the adopting networks, the
difficulties this presents means that a scalable
routing solution will only be widely enough
adopted on a voluntary basis if no such upgrades
are required in order for the new system to
provide compelling benefits.
Firstly, there are difficulties in motivating
operating system / stack programmers to add and
test new facilities. Secondly there may be
costs and disruption for the adopting network in
upgrading the stacks. Thirdly, in many or most
end-user networks, some or many hosts will not
be amenable to stack upgrades due to them using
operating systems which are no longer being
maintained or developed. This is especially
the case for devices such as printers, routers
etc. which do not use one of the major
operating systems.
ILNP involves stack upgrades. So it doesn't meet this constraint either.
6 - If the solution requires extra functionality in
interdomain routers, . . .
I understand ILNPv6 meets this constraint, since it doesn't require
any changes to IPv6 routers. For ILNPv4, DFZ and other routers need
to be upgraded before any upgraded hosts can use ILNP. Hopefully
this can be done by firmware - but ILNPv4 can only work once
essentially all IPv4 DFZ and many other routers are upgraded. Host
stacks need upgrading too.
I think that if ILNP could have met the above constraints, then it
could also meet the remaining constraints 7, 8, 9 and 10.
>> 3 - Applicable only to IPv6, since ILNPv4 requires all DFZ and
>> other routers be upgraded to handle the new header option.
>
> Both necessary and sufficient.
Your interest in IPv4 is apparently zero or negative. Google:
"Tony Li" IPv4 toast
Most people care a lot about IPv4 and will continue to do so for many
years to com.
>> 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
>
> Globally unique identifiers are not brittle.
They are if they are generated from MAC addresses and the like, which
is what my statement says.
Klaas Wierenga, Mikael Abrahamsson and Toni Stoev have all written
with concerns about the ability of a MAC etc. based system to
generate genuinely unique Identifiers.
How would you convince these people, and me, that into the indefinite
future, either every host which could be an ILNP host will have a
suitable unique hardware identifier, or that alternatively the
instances of Identifier clashes resulting from this will be
sufficiently low not to be a significant problem for ILNP adoption?
>> 5 - Inability to look up an Identifier to find its one or more
>> Locators.
>
> This is not necessary.
Please see my forthcoming message in the "Overloading of Loc & ID
functions ..." thread.
>> 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.
>
> Why?
As above.
>> 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.
>
> There are no additional packets. Where did this alleged latency
> come from?
Actually there can be additional packets, for instance, from
draft-rja-ilnp-intro-05:
The receiver(s) of such a UDP session SHOULD send a gratuitous
IP packet containing an ILNP Nonce option to the sender, in
order to enable the receiver to subsequently send ICMP Locator
Updates if appropriate.
Also, there can be additional lookups if the first DNS lookup returns
an LP record - which requires a second DNS lookup to get the current
Locator(s).
I was thinking of a perhaps hypothetical protocol which involves
scattered UDP unidirectional communications with large numbers of
hosts - but I don't have a concrete example, so this is not a very
good argument.
I am now more concerned about how ILNP seems to assume that each
communication must start with a FQDN. If it starts with an IP
address - that is a currently valid Locator-Identifier pair, then I
think the stack has to do extra lookups. I explore this in the
forthcoming message.
>> Can you cite an instance where people are expecting ILNP to be
>> more secure, or better in any way, than IPv6 today?
>
> All of the attacks listed are exactly identical to ones that can
> be done on IPv6 today.
The "Locator squatting" attack is not related to any existing IPv6
functionality - only to ILNP's mobility functionality.
I am not sure what other security concerns have been expressed about
ILNP. Can you recall others?
>> 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.
>
> Locally unique identifiers are intentionally not first class
> citizens.
OK.
> Globally unique ones are.
If they are genuinely globally unique. But I and some other people
believe this can only be achieved via hierarchical assignment, rather
than the current ILNP approach of making them from MAC addresses and
the like.
Still, the inclusion of locally unique Identifiers means that the
class of objects known as ILNP Identifiers are not all "first class
citizens" - and that the semantics of Locator and Identifier are
anything but "clear and crisp" as Ran frequently claims.
The bunch of statements I quoted from his intro I-D would be true if
Identifiers were all genuinely globally unique.
But since the current arrangements allow also for locally unique
Locators, those statements are misleading.
>>> 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?
>
> Please see the archives of the big-internet mailing list.
OK. The list ran from 1992 to 1997:
ftp://munnari.oz.au/big-internet/list-archive/
You wrote about the present day - "do care" - regarding an IPv6 host
switching to new IP addresses frequently, within the same /64:
> the fact of the matter is that there are MANY others who do care.
>> 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?
>
> The entire security directorate, security AD, the IESG and the
> IANA.
Maybe so - but if this is the case, I hope you will point to some
kind of documents to this effect, say from 2006 onwards.
Since almost no-one uses IPv6 and since there is a desire or need for
anonymity, I think various approaches different to this have been
developed for IPv4. These should work fine for IPv6 too. To what
extent they would work for ILNP or for LISP, Ivip etc. would have to
be carefully considered.
That said, I think trying to ensure anonymity in a given set of user
actions, with particular servers, particular kinds of scrutiny, and
particular sets of other users' activity to blend into, is an
extraordinarily complex social and technical thing to achieve. I
doubt it can be achieved to a high degree without a great deal of
thought and careful work.
I suspect Internet anonymity needs to be added to Romana Machado's
list of unsolved engineering problems, which currently stands at
"death and taxes".
>> OK - but it makes the host stack much more complex,
>
> Agreed, however, it is still vitally important.
On the list, so far, I think only Klaas Wierenga has expressed an
interest in anything like this. He wants to be able to change his
Identifier frequently (msg07104) and my understanding of msg07095 is
that he doesn't want to be stuck with persistent Identifiers.
In msg07095 I don't think he is expressing a lack of interest in
globally unique Identifiers, since he says he is a "mobility junkie"
and since, by your own account and I think Ran's I-D, locally unique
Identifiers should not or can't be used for mobility.
So my guess is that Klaas wants to be able to switch between multiple
Identifiers which are globally unique, but which he or his host
somehow has a role in generating or selecting, I guess in part to
avoid any path of detection arising from his host requesting these
numbers from any particular place and to avoid having to trust
external systems.
I don't care about how much ILNP supports this particular approach to
privacy / anonymity, since I am opposed to ILNP anyway and am
convinced it will never by widely deployed. (I am only writing this
stuff to learn about scalable routing in general and to help convince
people to devote their energies to CES architectures.)
Its just that I think you could much improve ILNP and could only live
up to your own and Ran's claims about "clear and crisp semantics" by
ditching these locally unique Identifiers.
At least you admit that the stack will be made more complex by these
locally unique Identifiers. This will make ILNP harder to introduce.
>> 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.
>
> Note that a locally unique identifier effectively gives the host
> the same capabilities as a legacy v6 host plus multi-homing
> support. But not mobility.
Yes - I understand this. It will provide multihoming via the
currently established two or more Locators, because somehow the host
will only choose a "locally unique" Identifier after it tests it for
uniqueness in each of the the /64 ISP networks it is using - one for
each Locator. However, it can't (or might not be able to) suddenly
go off and get another Locator in another access network, since there
is no guarantee that its current Identifier can be used in that /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.
>
> While it may not be a solution, I suspect that you will concur
> that a trail of a permanent, globally unique identifier is an even
> larger privacy issue. It's the logical equivalent of a
> continually updated Google maps page with a red pin stuck in it
> that says "Robin is here right now". ;-)
I agree. Its just that changing only the lower 64 bits doesn't
really impress me. If someone or some process was scrutinizing
server logs then this would only be effective to the degree that many
other sessions other than the one from my host were arriving from the
same /64s as I am using. Perhaps I could deliberately use some ISP
or VPN or whatever which did this, but that would require a large
number of presumably privacy sensitive people also using the same
/64. Inquiring minds would be wise to this, so this may not result
in any gains.
I can't think of any approach which would work well.
>> 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.
>
> Except that the number of identifiers necessary for a host
> balloons, as they basically need to be a one-time pad. This
> depletes the address space unnecessarily quickly.
Yes, but there are 2^64 locally unique Identifiers to share around,
so this should not be a problem. They don't really need to be
"one-time" - as long as a host uses a sequence of Identifiers which
don't repeat and don't have any discernible relationship to each
other, that's the best you can do in this scheme.
> If, instead, the locally unique pool is dynamically assigned and
> reused, in much the same way that DHCP assigns addresses today, we
> avoid this issue, we get local uniqueness, and identifier reuse.
Yes - I can see that if you have enough similar users in the /64 and
they are all sharing or not sharing a bunch of Identifiers, then my
particular session would be mixed up with theirs. But how many of
those people will be accessing the particular servers I am accessing?
Probably far too few - like none - to give my sessions any kind of
anonymity.
>> I still think ILNP would be significantly improved by getting
>> rid of locally unique Identifiers and using only globally
>> unique, hierarchically assigned Identifiers.
>
> Sorry, that won't be happening. Get over it.
OK. The extra complexity in the stack and the failure to meet Ran's
claims about "crisp, clear semantics" are further reasons to think
dimly of ILNP.
>> 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.
>
> Fortunately, I'm a _recovering_ perfectionist. There is such a
> thing as good enough.
OK. I reckon that by retaining locally unique Identifiers, the
semantics of ILNP Identifiers and Locators becomes a foetid swamp
which only the bravest or most foolhardy programmer would want to try
to implement.
Maybe this muddle is good enough for you - but I suggest you pull
down the "crisp and clear" billboards to avoid further discussions
such as this one.
>> 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.
>
> Bureaucracy NEVER is robust. A glance at any front page should
> tell you this.
I and some other folk believe that globally unique Identifiers will
better result from hierarchical assignment than from the current ILNP
approach.
This is another reason for us to think dimly of ILNP.
>>> 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?
>
> Hundreds, personally. Prior to the advent of DHCP (and even in
> the early days of DHCP), getting duplicates was trivial. And it
> still happens in the lab, when some enterprising soul decides that
> allocating an address manually is too hard and simple "makes one
> up". In defense of that, every OS that I can think of has
> duplicate address detection logic. And also why DAD is built into
> IPv6 ND.
>
> Oh, and that's just for /32's.
Sure - but this doesn't have any global significance.
Duplicate IP addresses are only a problem in a local network which
covers that address space.
Duplicate supposedly globally unique ILNP Identifiers clobber or
threaten the ability of a host to operate on a global basis. The
catchment area is the world, not your LAN or corporate / campus network.
>> 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.
>
> But that's not very robust, is it now? You seem to want
> perfection. This is clearly imperfect and therefore unacceptable.
I am not insisting on perfection.
I am suggesting that one way to make people happier about ILNP is to
ensure all Identifiers are genuinely globally unique.
You don't want to do it, and I guess Ran thinks the same way.
> <Insert Kirk's monologue from The Changeling.>
Sorry - I only watched a few episodes of Star Trek.
>> Sure, but they are localised to Ethernets or whatever
>> non-globally significant domains a MAC address is used.
>
> Sorry, but no. People are talking about trans-oceanic data center
> migration for disaster recovery. Necessary as certain parts of
> the world are considered likely to slip off into the ocean.
OK - but the catchment area is still within some private system.
With duplicate supposedly globally unique ILNP Identifiers, the
catchment area is global.
>> Neither I nor anyone else is expecting ILNP to solve problems
>> caused by MAC clashes.
>
> Yet you consider Xu's 'attack' to be a flaw. It is EXACTLY a MAC
> collision.
I am sure it is not exactly like a MAC clash. If Xiaohu Xu agrees
with me, then I would say you don't understand the attack.
Steve Blake seems to understand it - and he admits it is real.
> And to be frank, you can execute it today: go to your
> favorite WiFi hotspot. Sniff the traffic. Copy down someone's
> MAC address. Go again tomorrow, and use their MAC address before
> they show up.
Sure - but I have to find out the victim's MAC address first, which I
can only do via the LAN it happens to be on. Then I can only mount
the attack on a LAN it connects to.
With the "Identifier squatting" attack, the attacker can gain the
information he or she needs anonymously from public resources -
looking up the FQDN of the victim host to gaining its Identifier.
Then, the attacker only needs to be in the same /64 as the victim -
though the attacker has to connect there and squat on the victim's
Identifier as the lower order 64 bits before the victim's mobile host
tries to connect to any access network which uses this /64. This
could cover a whole 3G network in a city or other large area.
> Your logic is inconsistent.
Your response make me think you do not understand the attack. I
can't think of what more I can say to explain it. Steve thinks it is
real and you don't. Perhaps you can discuss it with him.
>> 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.
>
> The point is that if an attacker has your identifier/MAC address
> and is authorized to join a subnet without any link level
> authentication, then they can either impersonate you and/or DoS
> you. We'll ignore the fact that they can also snoop you.
>
> The remedies for this are well known and have been mentioned to
> you, yet you fail to accept them or explain why they are
> problematic.
>
> Again: 802.1x, SeND.
>
> Instead, you endlessly repeat your allegations.
>
> Do you understand why discussions with you are pointless? You
> accuse, but you do not listen to responses.
You do not appear to understand how this attack differs from the
LAN-based MAC attack, which is only very roughly comparable.
>> 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.
>
> Problems from hierarchical assignment are provably FAR worse.
> Experience in the field has made this very clear.
There's nothing in what you wrote to convince me of these assertions.
>> 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.
>
> Yes, mistakes happen. If you want a world without mistakes, you
> first need to remove all humans. Sorry, but you're on the wrong
> planet.
>
> You need to weight the probability of mistakes. So far, the odds
> of a duplicate MAC are FAR lower than a duplicate manually
> assigned /128 or /64.
Mikael Abrahamsson, in his two recent messages, indicates the problem
of duplicate MAC addresses is significant.
No-one is advocating manually configured ILNP Identifiers. With the
hierarchically assigned Identifier system I have in mind, and I guess
which others have in mind, the ILNP stack would be be manually
configured with a FQDN or some other way so it can figure out its
place in a hierarchy, and request an IP address from that system.
>> But that rules out mobility. I and I guess many other people
>> believe that a scalable routing solution without mobility is a
>> non-starter.
>
> Asked and answered.
So we agree that mobility is vital to the success of any scalable
routing system?
If so, this is another reason to think poorly of ILNP compared to
Ivip or probably IRON and LISP (assuming LISP is able to do mobility,
which at present I think they can't). These 3 CES architectures
promise to do mobility with any correspondent host. ILNP can only do
it for ILNP upgraded hosts.
ILNP mobility only works with the MN getting a global unicast address
- not behind NAT. This might be likely on IPv6, but it is highly
unlikely for numerous mobile devices if ILNP was ever made to work
for IPv4.
TTR Mobility can work with the MN on IPv4 or IPv6, behind one or more
layers of NAT, and even on an address which itself is provided by TTR
Mobility. There can be any recursion of NAT and mobility in the
path between the MN's point of connection and the open Internet. In
all cases, the MN establishes a 2-way tunnel to the TTR, and
everything will work fine.
>> 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
>
> False. Do you understand how much code I've written? And where
> it runs? Hint: this message will not get to you without it. ;-)
So I believe. That's why I am perplexed that you go along with
claims of "crisp and clear semantics" for Locators and Identifiers,
when locally unique Identifiers lead to a horrible muddle between them.
You and Ran have consistently championed a "high-level", supposedly
"architectural" design process - leaving out all sorts of concerns
about details.
I guess that is how Ran started off with ILNP - globally unique
Identifiers = "crisp and clean semantics". So far, so good.
But then, I guess, he added locally unique Identifiers, without
considering the details of this - how this completely destroys the
original "crisp and clean" semantics, and how messy it will be to
implement a stack which can do all this, while maintaining an
interface to standard IPv6 applications which respects their
expectations about the IP addresses the stack gives them, and which
the applications give to the stack.
>> - 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.
>
> Incorrect. This is not even hard.
It looks very messy to me. If you can do it without fuss, then good
luck to you!
>> 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).
>
> I'm trying to respond to your comments. It's not my fault if your
> line of discussion is confusing.
But how am I to respond if you repeatedly write in a manner which
indicates you do not understand the "Identifier squatting" attack,
and how it differs from LAN-based attacks involving MAC addresses?
>> 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.
>
> Until you apply the remedies as discussed.
>
> Similarly, other IPv6 attacks will work, until you apply IPsec.
> Nothing new here.
As above.
>> 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.
>
> Incorrect. You're correct about roaming dropping calls, but the
> ability of a handset to authenticate itself and have a unique
> identifier (IMEI) are well known. In the cell world, the analog
> to the locator squatting attack resulted in theft of services, so
> non-cleartext link layer authentication was introduced. We simply
> need the same.
As previously noted, link-layer encryption or authentication can't
protect against the "Identifier squatting" attack. To do so, you
need an elaborate, global-scale, arrangement which would rely, I
believe, on hierarchically assigned Identifiers - as I explored in a
section of my previous message below.
>> The cellphone companies run their own access network so the
>> whole thing is integrated.
>
> The architecture is almost identical to the Internet's. Many
> different bands, several different protocols, all resulting in
> roaming with authentication and end-to-end calls.
Maybe so, but to prevent the "Identifier squatting" attack, each
access network needs to coordinate with a central hierarchy which
assigns Identifiers, as I described in my previous message quoted below.
>> 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.
>
> Disagree. If you want secure mobility (not everyone does), you
> need authentication.
TTR Mobility doesn't require any authentication or special
arrangements in the access network. The MN needs to authenticate
itself to the typically nearby TTR, but that is not necessarily -
probably not - in the access network.
>> 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.
This was my approach to protecting against the attack.
You added this, so I guess you think this is all that is needed:
> 3 - The host accessing the network was a cryptographically
> authenticated known host, with a non-cleartext protocol, with
> known host attributes, such as the MAC address and identifier.
This doesn't protect against the attack - your approach concerns
authentication between the access network and the host. It doesn't
concern whether the lower 64 bits the host wants to use is an ILNP
Identifier, or whether this host is authorised 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.
>
> Only if you care about secure mobility. If you don't, you can
> visit Starbuck's today and squat away with IPv6 today.
The attack is not against the security of ILNP mobility. It is a
Denial of Service attack against ILNP mobility.
>> 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.
>
> I think YOU don't understand the attack. If I sniff your IPv6
> address today and arrive at Starbuck's ahead of you, I've done
> _exactly_ the same thing.
At the time you wrote this, I believe you did not understand this attack.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
