Short version: I think Steven Blake and Tony Li have not
successfully responded to this critique. I reply
to them both.
Steve also seems to claim that there is a robust
method of every host now - and implicitly in the
future - developing a unique 64 bit address purely
based on its own hardware configuration. I will
pursue that in a separate thread.
Hi Steven,
You wrote:
>> Do you agree that a nonce, as suggested by Xiaohu, couldn't do the
>> same job as an ILNPv6 64 bit Identifier?
>
> Yes. The nonce is only used to (a) indicate the start of a ILNP
> session, and (b) secure ICMP messages.
OK - we agree on this.
>> Do you think ILNP could be reliable and robust if the Identifiers
>> used by hosts are not in actual fact globally unique? If so, please
>> give some examples.
>
> I think they need to be unique on a subnet. Being globally unique with
> high probability makes uniqueness on a subnet easier to achieve.
This doesn't alter the nature of the problem Xiaohu and I are
concerned about. It seems Fred Templin and Eric Fleischman agree
with this critique, since they have added notes to this thread about
MAC address uniqueness, without disagreeing with the critique.
The latest I-D:
http://tools.ietf.org/html/draft-rja-ilnp-intro-05
states that the Identifier is recommended to be globally unique. If
a host's Identifier is not globally unique, but is only unique on a
particular /64, then they should not be used on any other /64 without
first checking that in the second /64, there is not already a host
using these same Identifier bits in its lower 64 bits:
Locally-unique Identifiers MUST be unique within the context
of their Locators. The existing mechanisms of the IPv4 Address
Resolution Protocol [RFC 826] and IPv6 Neighbour Discovery
Protocol [RFC 4861] automatically enforce this constraint.
Locally-unique Identifiers MUST NOT be used with other Locators
without first ensuring uniqueness in the context of those other
Locators (e.g. by using IPv6 Neighbour Discovery's Duplicate
Address Detection mechanism).
It seems that ILNPv6 can't do Mobility if the mobile host's
Identifier is only known to be unique on some particular /64 AAAA -
because as a mobile host, it may soon need to use an access network
in /64 BBBB and find that it can't get an IP address there with its
current Identifier in the lower 64 bits.
Our critique goes beyond whether the Identifier NNNN is globally
unique or not. Even if it is globally unique, an attacker can easily
find it via DNS and have their host in /64 BBBB gain the address
BBBB-NNNN. Then when our mobile host - whose Identifier NNNN is fine
on /64 AAAA, because only this host has the IP address AAAA-NNNN -
tries to continue its ILNP sessions when using an access network in
/64 BBBB, it can't do so, because the IP address it needs (BBBB-NNNN)
is already in use.
ILNP mobility involves the mobile host telling other hosts that its
Locator(s) have changed. There is no way of continuing user sessions
with another Identifier, as far as I know.
With ILNP, network mobility (as well as node mobility)
is considered a special case of multihoming. That is,
when a network moves, it uses a new Locator value for all
of its communications sessions. So, the same mechanism,
using a new or additional Locator value, also supports
network mobility.
This is crisp and clear. The node needs to retain its original
Identifier in order to be able to successfully achieve mobility -
implicitly with continuing higher level sessions.
>>>> For ILNP to work robustly, I guess it would be necessary to allocate
>>>> portions of the Identifier namespace hierarchically to ensure that
>>>> there are no disputes or accidental clashes - that each host can have
>>>> its own globally unique Identifier.
>>>
>>> Have you read the draft? Where do you get off complaining about other's
>>> ability to handle details?
>>
>> I read all the material of all the proposals, including ILNP, and
>> commented on them all on the list. I haven't read the very latest
>> versions of the proposals. My critiques of ILNP and other such
>> Loc/ID Separation (Core-Edge Elimination) architectures are well known:
>>
>> http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html
>>
>> and are not solvable by the small details which change from one
>> version of a draft to another. So forgive me if I haven't read all
>> of Ran's latest versions end-to-end.
>
> Get real.
I don't understand how this sentence or the next is relevant to me
defending myself against your complaint that I haven't read every
part of Ran's latest versions.
If you want to give me a hard time about lack of attention to detail,
you might like to demonstrate your own attention to it by responding to:
http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html
What are your list of goals and non-goals?
Why should ILNP or any other CEE architecture be chosen when it
forces all hosts to do more work and generally will add delays and
extra packets for all Internet communications?
How can any CEE architecture overcome the barriers to widespread
voluntary adoption mentioned in the above and detailed here?:
http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/
> The recommendation to use global-scope EUI-64s for IDs has
> existed since day one, and has been common practice in IPv6 (for IIDs)
> for over a decade.
I know. This doesn't affect the critique we are discussing.
>>> As has been documented for years, and has been patiently explained many
>>> times on this list, it is recommended to synthesize a global-scope
>>> EUI-64 ID from one of a host's globally unique hardware IDs, such as an
>>> Ethernet MAC address.
>> Sure - but that doesn't eliminate the possibility of clashes.
>>
>> There could be two Ethernet interfaces with the same MAC - and there
>> will be many devices which have no Ethernet interface or other
>> component with a MAC.
>
> Two hosts on the same link with the same MAC address can't communicate
> using any protocol (IPv4, IPv6, ILNP, etc.). Fortunately, the
> occurrence of duplicate MACs is extremely rare.
Eric and Fred wrote that duplicate MAC addresses are common enough to
be considered a serious problem by people who have studied these
matters more than I have. Unless I see substantial evidence to the
contrary, I will share their concern.
But this doesn't affect the critique.
> Name one modern device that doesn't have a unique hardware ID that could
> be used to form a global-scope EUI-64?
This is not the primary subject of this thread - since Xiaohu and I
are discussing an attack. Now you are expanding the discussion to
encompass the question of how the ILNPv6 (ILNPv4 too?) stack would
generate a globally unique 64 bit Identifier without reference to
anything outside its own physical device.
I will discuss this in a separate thread.
>> I still think that hierarchical division of the Identifier space is
>> the best approach.
>>
>>
>>>> But how can this work with existing IPv6 networks, where (frequently,
>>>> typically or perhaps always) any host can get any address with lower
>>>> 64 bits of its own choosing, provided no other host has got it already?
>>> IPv6 hosts typically synthesize global-scope EUI-64 IIDs from an
>>> interface's globally unique Ethernet MAC address. Less commonly, they
>>> can synthesize a random, local-scope EUI-64 IID (privacy address), or
>>> use CGAs or HBAs. In all cases, the probability that two hosts on the
>>> same subnet would accidentally configure the same IID (ID in ILNP) is
>>> astronomically low.
>>
>> Unless there is a DoS attack or some kind of clash due to the
>> algorithm you suggest not working well, as noted above.
>>
>> But what if two hosts A and B in separate subnets have the same
>> Identifier? This is Locator - Identifier Separation, where the
>> Identifier has crisp semantics: it identifies a host!
>
> Nothing breaks if two hosts on separate subnets share the same ID, even
> if a separate host is communicating simultaneously with both of them.
More on this below.
>>>> I don't think there is a secure, robust, method of making ILNP work
>>>> for Mobility.
>>>
>>> A malicious host on subnet X that wanted to execute a DoS attack on a
>>> mobile ILNP host H moving onto subnet X could lookup all of H's IDs via
>>> DNS, and then "steal" them on X before H arrives, causing H to have to
>>> drop all of its on-going TCP/UDP connections when it moves onto X.
>>
>> It would be worse than that. It would cause H to be unable to use
>> its connection on network X, due to it being unable to use its one or
>> more Identifiers - all of which have been "stolen".
>
> Host H can synthesize a new ID.
Then this would mean its sessions with other hosts could not be
continued. So our critique is valid.
> Nothing prevents a malicious host from sending bogus NAs for any
> address/ID on a subnet (just like nothing prevents a malicious IPv4 host
> from sending bogus ARP responses). So in theory a malicious host can
> "steal" any possible ID on a subnet. This vulnerability is not
> ILNP-specific.
Only ILNP uses the lower 64 bits as an Identifier, which should have
global scope - as you seem to acknowledge by your interest in arguing
that generating unique Identifiers from device hardware is practical.
Any host on a physical Ethernet or in an IP subnet can make a mess of
that Ethernet or subnet, subject to various mechanisms in the switch
or router.
The critique is that a host on any kind of physical network, where it
is able to request and obtain a global unicast IP address with a
specific set of lower 64 bits, can do so, and be totally compliant
with IPv6 protocols - and still achieve the DoS attack Xiaohu and I
are writing about.
This means that ILNP, for mobility at least, is not backwards
compatible with IPv6.
Hosts need to be able to request and gain an IP address with a
specific set of 64 lower bits in order to be able to implement ILNPv6.
> If you are worried about this, deploy SeND.
I am not sure how SeND prevents the attack. If an attacker knows the
ILNP ID of a mobile host it wants to DoS, before that host gets an
address on a particular /64, and if it can request and gain an IP
address with a lower 64 bits of its choosing, then it can do so and
therefore prevent the mobile host from using its ILNP Identifier when
it connects to this /64.
I assume that any IPv6 host can request an IP address with a specific
lower 64 bits - otherwise, how could the ILNP mobile host get the IP
address which has its pre-existing ILNP Identifier as the lower 64 bits?
The attack doesn't depend on any lack of security in the /64 network
- just the ability of the attacker to know the ILNP Identifier of the
one or more hosts it is targeting. It can easily find this out by DNS.
> Most network operators don't seem to be terribly worried about
> this attack.
But we are discussing a scenario which doesn't occur today - a host
turning up in a /64 and requiring a particular IP address within that
/64, so it can continue its sessions and therefore be successfully
Mobile.
>> I don't see how this could be the case, since the laptop can always
>> obtain an address with a lower 64 bits which is not currently used.
>> However, I haven't thought much about IPv6 Neighbor Discovery for a
>> while and I have not read about attacks on it. Can you point to a
>> mechanism by which the laptop could be prevented from joining the LAN?
>
> If I know (from previous observation, or DNS query) that your laptop
> performs SLAAC using an IID formed from its MAC address, I can cause
> your laptop's DAD to fail. So as you said, you will then have to go
> form a new IID and try again. If I am really malicious, I can track you
> by your MAC address and cause all of your future DAD attempts to fail.
Maybe so - I don't know enough about it. Presumably SeND fixes this.
But AFAIK, SeND wouldn't prevent the attack we are discussing.
> Nothing ILNP-specific here.
The attack we are discussing is ILNP-specific.
>>> The fact that SeND isn't widely deployed is an indication that this
>>> attack can be detected and mitigated by network management and isn't
>>> seen as a particularly serious risk.
>>
>> But how would SeND protect against the DoS attack which Xiaohu Xu and
>> I are discussing? SeND can't very well prevent the attacker from
>> getting 64 bits of lower address which are guaranteed to be different
>> from all the 64 bit Identifiers used by all the ILNP hosts in the world.
>
> Go read RFCs 3956 & 3972.
I think you are attempting distract me with a lengthy reading
assignment. These seem pertinent:
Neighbor Discovery for IP Version 6 (IPv6)
http://tools.ietf.org/html/rfc2461
SEcure Neighbor Discovery (SEND)
http://tools.ietf.org/html/rfc3971
but I don't see how this one is relevant:
Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast
Address
http://tools.ietf.org/html/rfc3956
Even if you and Ran can successfully counter this critique, I am
still completely opposed to ILNP or any other CEE (Locator /
Identifier Separation) architecture. So I don't want to spend a lot
of time on this critique. I raised it in its own thread because I
was concerned that Xiaohu's message would be forgotten.
Hi Tony,
You wrote:
> If the malicious host chooses to attack the CoA, then the attacks
> that Steve outlines above can be applied as well. Or, the
> malicious host can get even more primitive and simply duplicate any
> MAC that it sees on its subnet.
But how would the attacker know the mobile host's MAC address in time
to steal it - before the mobile host tries to connect to the BBBB /64?
I understand that there are typically mechanisms which prevent a
second host which tries to use the BBBB-NNNN address from disrupting
the first which has this address.
Steve's response to this critique seems to be that the mobile node
would simply get a new Identifier. But I argue above that this
proves the validity of the critique - since this would not allow the
continuity of higher level sessions.
> The fact of the matter is that if the link layer provides no
> authentication, then its not an appropriate media for secure
> mobility. Ergo, sites that are trying to supply true mobility
> should provide some form of link layer authentication (see 802.1x
> and better).
I don't see how SeND would counter the attack Xiaohu proposed.
> Most link layers that we associate with real mobility (i.e., cell
> protocols) do provide link layer authentication for precisely this
> reason.
>
> Note that this is wholly independent of ILNP and mostly also
> independent of IP. Mobile DECnet would have the same issues. ;-)
I don't see anything in what you wrote which disproves the validity
of this critique.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
