On Thu, 2010-07-08 at 01:49 +1000, Robin Whittle wrote: > Hi Steven, > > You wrote, in part: > > >> My guess is that with ILNP or any other Core-Edge Elimination > >> architecture (AKA "Locator Identifier Separation") what uniquely > >> identifies a host is its Identifier, and this needs to remain stable > >> at all times - including with Mobility. Other hosts which want to > >> communicate with this one first need to know its Identifier. Only > >> then can they look up its one or more currently valid Locators - > >> which they must have before being able to send it a packet. > > > > This last sentence is false. Hosts first look up the locator + > > identifier for a correspondent via its FQDN. Hosts already in > > communication with the correspondent learn of locator updates via > > ICMP, or via DNS. > > OK, but as a brief explanation of my rejection of Xiaohu's nonce > suggestion, it remains true that host A needs to know the Identifier > of host B before it can send a packet to B. I agree that in ILNP > there are various ways of finding out the Identifier and Locator(s) of B. > > > >> A nonce > >> wouldn't perform this function. Only a globally unique Identifier > >> can be used to reliably implement Loc/ID Separation. > > > > Mostly agreed. > > OK - to what extent do you not agree? > > 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. > 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. > >> 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. 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. > > 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. Name one modern device that doesn't have a unique hardware ID that could be used to form a global-scope EUI-64? > 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. > >> 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. 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. If you are worried about this, deploy SeND. Most network operators don't seem to be terribly worried about this attack. > I think that what you wrote confirms my critique. > > > > This > > is due to a known security weakness with IPv6 Neighbor Discovery, which > > is why Secure Neighbor Discovery (SeND) was invented. This same attack > > can be executed in IPv6 today (i.e., a malicious host could use this > > attack to block a laptop from powering on and joining a wireless LAN, at > > least temporarily). > > 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. Nothing ILNP-specific here. > > 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. Regards, // Steve _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
