On Wed, 2010-07-07 at 21:21 +1000, Robin Whittle wrote: > Ten days ago (msg07042) Xiaohu Xu wrote (Re: [rrg] ILNP Identifiers) > about a problem with ILNPv6 and Mobility. > > An ILNPv6 host has an Identifier (64 bits): NNNN and as part of its > mobility operations needs to operate from an access network whose > Locator is AAAA. It might have been working fine on another network > whose Locator is BBBB, because it was able to get the IP address > BBBB-NNNN on that network. > > But let's say a second (presumably ordinary IPv6) host on the AAAA > network already has the address AAAA-NNNN. Then our mobile host > can't get this address in the AAAA network, so it can't operate as an > ILNPv6 host in that network. > > This is my understanding of the exchange, with Xiaohu quoting Ran, in > which Xiaohu was concerned about the second host getting AAAA-NNNN as > part of a DoS attack, rather than be accident: > > >> 3) ILNP is carefully engineered to be fully backwards > >> compatible with IPv[4,6] and also with ARP/IPv6 ND, > >> and to do so in a way with no changes being required > >> to any router prior to ILNP deployment. > > > > It seems that your answer to the following question is "YES": > > > > "If an attacker who steals your identifier accesses a subnet > > which you would access later during mobility, to avoid your > > established session from being broken, should your identifier be > > changed?" > > > > Then my doubt is why not directly use the Nonce value as an > > identifier since the current identifier (i.e., the rightmost 64 > > bits of the IPv6 address) can not be ensured to be permanent during > > a session in the above case of mobility. > > 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. > A nonce > wouldn't perform this function. Only a globally unique Identifier > can be used to reliably implement Loc/ID Separation. Mostly agreed. > >> 4) The need to deploy new IPv6 routers was and > >> is an barrier to IPv6 deployment. > >> > >> 5) There is widespread agreement that any proposal in > >> the IRTF Routing RG needs to be backwards compatible > >> with IP. > >> > >> 6) There is no new operational issue and no new security > >> issue with ILNP as compared with IPv[4,6]. > > > > For Mobile IP, the home address can be ensured stable since the CoA > > can be any of the available addresses within the foreign subnet. > > However, for ILNP, when there is an already allocated IPv6 address > > within the foreign subnet, which is conflicted with the > > to-be-formed (L, I) pair for a mobile ILNP node just attaching the > > above subnet, to be fully backwards compatible with IPv[4,6] and > > also with ARP/IPv6 ND, the I value (i.e., identifier) would > > have to be changed during a session. > > > > Best wishes, > > Xiaohu > > > 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? 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. > 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. > 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. 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). 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. Regards, // Steve _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
