On Thu, 2010-07-08 at 13:59 +1000, Robin Whittle wrote: > 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.
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. > 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. > 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. But if the link-layer is unauthenticated, the same attacker can launch much worse attacks on any node running plain IPv4 or IPv6. 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. > 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. > 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. > >>>> 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. 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? > 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. > 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. 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. Are you writing code? I'm not interested in being a partisan in any debate about the deployability of any scheme. It's pointless without running code. > > 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. > >>> 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. True enough. > > 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? > 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. > 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. > 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. > > 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. > 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 > 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. Regards, // Steve _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
