Hi Xiaohu, > CONCERN #1: Host ID Theft Threat
Given that the host ID is locally scoped, and ILNP does not claim to provide any level of security above and beyond what legacy protocols provide today, could you please expound a bit on the threat? What exactly do you expect an attacker to do with this stolen ID? And how is it an attack that we wouldn't have today in v6? > If I understand it correctly, ILNP could also use some CGA like approach to > deal with this issue. That would certainly be an extension, but is not covered today. > CONCERN #2: Host ID Global Uniqueness Assurance > > I know ILNP doesn't require the host identifer to be globally unique. However, > it has to involve some other tricks (i.e., nounces) to deal with the host ID > collision events. More precisely, it uses nonces to confirm the association of one (locator, identifier) pair with another (locator', identifier) pair. > Without mentioning whether or not this choice has any extra advantage over the > choice of global uniqueness ID, can we configure the filering-rule table on a > given host based on these non-globally unique host IDs? Or do you have any > better alternative for us to achieve the same goal as what we did today (e.g., > IP address (acting as identifier also in today's network) filtering table)? One could always filter on remote (locator, identifier) pairs, giving you the same semantics that you have today with source address filtering. However, the security of ANY remote source address is of questionable value. This is already true today. Filtering the destination address today for incoming packets is generally considered much safer, as the address is presumably under the (reasonably secure) management of the local network. The analogous effect in ILNP is to filter on incoming destination identifiers. This allows filter rules to be independent of the locator, thus easing renumbering chores. If mobility is not permitted within the local domain, then the destination locator can also be included in a filter rule, in whole or in part. > CONCERN #3: Motivations for Earlier Adoption of ILNP > > Considering a scenario where a legacy IPv6 host initiates a session to an ILNP > host which is a multi-homed host, the legacy host will obtain several PA > addresses for that ILNP host in a DNS reponse to its DNS query, then the > legacy host will use one of the PA addresses of that ILNP host for initiating > a session. Once the ILNP host is rehomed, can the already established session > still survive? No, since one correspondent is a legacy host, you only have legacy capabilities. This points out that the primary hosts that want to migrate to ILNP are those that are mobile and those that correspond with mobile hosts. Therefore, I propose that we start with the smart phones. > Maybe somebody will argue that it doesn't matter since the legacy host will > attempt to use the other PA address once the previous one is failed. However, > my concern is whether it is acceptable for the earlier adopters of ILNP. I > roughly believe they will still prefer the PI addresses, rather than ILNP. Perhaps, but deploying PI addresses and ILNP is far preferable than doing nothing and deploying PI addresses without ILNP. ;-) > Take IPv6 transition as an example, can the ISPs disable the IPv4 access > service while providing IPv6 access service to their customers? When the ISPs > provide their customers some new choices, they can not deprive the interests > and benefits that the customers has already have when using the current > choice. As Randy Bush would say: I encourage all my competitors to disable IPv4, immediately. ;-) v4 and v6 will continue to co-exist for some time, and IMHO, there will be NAT between the different versions to provide continuous service. I'm not understanding the relevance of this to RRG. > Maybe I am totally wrong. And maybe not. Regards, Tony _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
