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. A nonce wouldn't perform this function. Only a globally unique Identifier can be used to reliably implement Loc/ID Separation. >> 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. 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? I don't think there is a secure, robust, method of making ILNP work for Mobility. - Robin _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
