Short version: Steven acknowledges the validity of the attack
which Xiaohu Xu proposed.
He seems to think that SeND (Secure Neighbour
Discovery) can protect against it, but as far as I
can see, neither SeND nor any other mechanism can
protect against it.
If ILNP Identifiers were hierarchically assigned,
then there would be a way of looking them up in
the DNS. As far as I know, such lookups are not
possible. Therefore, there is no way of preventing
an attacker gaining an IP address GGGG-VVVV in the
GGGG /64, where VVVV is the Identifier of the
victim ILNP host. This attack prevents the victim
host from using the mobility aspect of ILNP to
operate from an access network which uses the GGGG
/64.
Hi Steven,
Thanks for your detailed reply, in which you wrote:
>>>> 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.
>
> They said that MAC address collisions are not unheard of. But MAC
> address collisions break Ethernet bridging and everything that runs on
> top of it, so when they occur they are a severity 1 problem that needs
> to be fixed ASAP. This is not a specific issue for ILNP.
I understand this - I was asking you about the critique, about the
attack Xiaohu Xu proposed. Below, you acknowledge it is valid.
The critique has nothing whatsoever to do with two hosts in an
Ethernet having the same MAC address.
>> 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.
>
> One can use the same reasoning to argue that a laptop cannot perform
> mobility because it cannot be sure that its 802.11 MAC address is unique
> on every possible WiFi network it might roam to. One can attack a host
> by stealing its MAC address just as effectively as by stealing its ILNP
> ID; most OSes don't have code to continually try new MAC addresses in
> case of collisions.
The attack Xiaohu suggested doesn't involve the attacker snooping a
MAC address from a LAN. It works from the victim's Identifier, which
the attacker can easily find out via ILNP's extensions to DNS, by
looking up the victim's FQDN.
The attack has nothing to do with LAN or any other L2 technologies.
It would work if the attacker had a cellphone on a 3G network and the
victim's cellphone then tried to get the IP address it needs on that
network, and so presumably in the same /64. As far as the network is
concerned, the attacker's cellphone is perfectly entitled to request
its IP address, which happens to have the lower 64 bits equal to the
Identifier of the victim's ILNP cellphone.
As far as I can see, the only way around this attack is a change to
IPv6 networks - to make them all check any request for an IP address
to make sure that it comes from a device which is authorised to
request it. That would be onerous enough, especially before IP
communications were fully up, if all hosts were ILNP aware - and if
this checking were possible. Below I argue that such security
measures are not possible with ILNP as currently described.
The attack works just fine with the attacker's host being an ordinary
IPv6 host which for some reason wants a particular IP address.
>> 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.
>
> I acknowledge that this attack exists.
OK - thanks.
> But if the link-layer is
> unauthenticated, the same attacker can launch much worse attacks on any
> node running plain IPv4 or IPv6.
Maybe so, but that only works on a LAN, and there will be billions of
mobile hosts in the form of 3G cellphones and the like. As far as I
know, those devices are not linking to their access networks via MAC
addresses in an Ethernet environment. So I suspect that these hosts
are not subject to link layer attacks, as you suggest, or at least
not the same link layer attacks. Considering the frightening size of
the GSM documentation (a metre of shelf space when I saw it in the
early 1990s) I guess that the 3G UMTS stuff is even more voluminous
and has much more robust security arrangements than Ethernet.
The nature of this attack is that it covers an entire /64 and
requires knowledge only of the Identifier, which is public knowledge.
> There are mechanisms that you can implement in access switches/APs to
> mitigate this, such as filtering NAs and binding MACs to global-scope
> IID/IDs, etc.
Yes, but this doesn't affect the attack, or apply to 3G access
networks, AFAIK.
>> 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.
>
> Correct for TCP/UDP, not correct for SCTP. If multi-path TCP takes off,
> then this problem could probably be addressed.
OK.
>> 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.
>
> See above.
OK.
>> 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.
>
> I didn't accuse you of that. I accussed you of missing one of the most
> basic points (using global-scope EUI-64s for IDs is pretty basic). You
> do understand that MAC addresses are allocated hierarchically, right?
I know they are allocated hierarchically.
>> 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?
>
> At the moment, to try to keep you from spreading false information.
Such as?
I was asking about the list of goals and perhaps non-goals for ILNP?
For the list of goals I assume, see these headings within the above
message:
17.2.3 Portability, Multihoming and inbound Traffic Engineering (TE)
17.2.3 IPv4 Address Exhaustion
17.2.4 Global Mobility
17.2.5 Security and robustness
>> 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/
>
> That is all your supposition. Fine. We agree to differ.
I have tried to update this page with any comments - but so far
no-one has pointed out what is fundamentally wrong with this.
Since you disagree with this attempt to list the constraints, I think
it would be helpful if you discuss on the RRG list what is wrong with
my attempt to list these constraints.
> People will choose to implement what they choose to implement, and
> deploy what they choose to deploy. What ever gets deployed will be a
> subset of whatever gets implemented.
Sure, but ILNP or any other CEE architecture faces such enormous
barriers to widespread voluntary adoption, that I think they are all
non-starters.
> Are you writing code?
Not yet.
> I'm not interested in being a partisan in any debate about the
> deployability of any scheme. It's pointless without running code.
What does "partisan" mean in this context? We are all arguing for
what we believe is best for the Net.
I think there is no practical purpose in writing code for an
architecture which has no hope of being sufficiently widely adopted.
A more fundamental critique of ILNP and other CEE architectures is
the extra delays they cause in communications, the extra burden they
place on all hosts, and the extra packets and/or longer packets they
involve:
http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html
(Dae Young Kim wrote in support of this: msg07074.)
>>> 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.
>
> Whatever.
OK.
(Lots of quotes deleted.)
>> Then this would mean its sessions with other hosts could not be
>> continued. So our critique is valid.
>
> True enough.
OK.
>>> 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.
>
> Are you aware that this is how IPv6 has worked (to generate IIDs) since
> around 1995?
Sure - but this attack works on publicly available information about
the victim host, before the victim host tried to connect to the new
access network. It covers an entire /64, no matter what the L2
technology is - and prevents ILNP from working for the victim host in
that /64. So it is unlike any LAN-based attack.
>> 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.
>
> That doesn't follow. IPv6 doesn't support network mobility at all,
> unless you deploy MIPv6. ILNP is not backwards compatible with MIPv6,
> if that is your concern.
What I meant was that if this attack is regarded as serious enough to
be a "show-stopper", then ILNP's mobility is not backwards compatible
with IPv6 networks - since there is no obvious workaround.
>> 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.
>
> It can't (strictly speaking, it can't prove that it owns that address
> via possession of a public key). That is the whole point of CGAs.
Yes - so SeND does not prevent the attack Xiaohu Xu proposed.
>> 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.
>
> You are misinformed.
How so?
Whether it is SeND or some other system, here is what would have to
happen in order to prevent the attack.
Attacker's host connects to, or is already connected to an access
network in /64 GGGG. It wants an IP address GGGG-VVVV where
VVVV is the Identifier of the victim. (I assume this is a globally
unique Identifier, since if the victim host only had a locally
unique Identifier, it wouldn't expect to be able to connect to the
AAAA access network.)
SeND etc. needs to somehow look up this Identifier to see if it
was being used by any ILNP host. I can't see how this could be
done. The host could provide a FQDN which when looked up by
SeND etc., returned an ID record equal to VVVV - but this is not
a mechanism by which SeND etc. could reliably verify whether
VVVV was being used as an ILNP identifier.
I understand that ILNP Identifiers are not hierarchically assigned,
so there is no possibility of a DNS lookup of VVVV to return some
information about a host which might be using it as an Identifier.
Even if this could somehow be done, then SeND etc. would need to
retrieve some certificate, crypto key or whatever, or communicate
with some distant server, and the do some kind of exchange with the
host by which the host could prove it was authorised to use this
VVVV value as its Identifier.
This would be inordinately expensive and would require central
coordination of ILNP Identifiers, perhaps with PKI etc. etc.
It would surely be too slow and expensive for mobile use.
Such a process would not be backwards compatible with IPv6 hosts.
At present, a plain IPv6 host could ask for GGGG-VVVV and it should
be able to get it - unless the SeND etc. system can somehow
determine that VVVV is an ILNP identifier. But without
hierarchical assignment of ILNP Identifiers, this is not possible.
>>> 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
>
> You'll be wanting RFC4861.
Yes - thanks.
>> 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
>
> Oops, my bad: I meant RFC3756.
>
> http://tools.ietf.org/html/rfc3756
OK: "IPv6 Neighbor Discovery (ND) Trust Models and Threats".
BTW, I think all Ran's references to "RFC 4219" are erroneous and
should be to RFC 4291.
>> 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.
>
> You're opposition has been duly noted.
OK. I am not convinced that reading these RFCs would affect my
understanding of the critique Xiaohu raised - and I need to
concentrate on other things, including reading the latest IRON I-D.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
