Hi Ran, > > Sorry, I just read your ilnp-nonce draft. I felt that without the > > HIP/CGA tricks, this nonce mechanism itself only solves the session > > hijacking problem, and it doesn't prevent stealing and > spoofing of the > > identifiers. > > For example, an attacker could use somebody else's identifier to > > initiate communication with a given correspondent node. > > It is not possible for an off-path attacker to do what you > suggest when ILNP is in use. There is enough information > available on both ends of an ILNP session to distinguish > between two different nodes that have accidentally used the > same Node Identifier. > > Without repeating another paper at great length in this > email, here is a starting point to understanding: > > 1) Recall that all ILNP sessions will include a > Nonce Destination Option sent from the initiator node > to the responder node (and subsequently a Nonce > sent from the responder to the initiator). > 2) Nonces are unidirectional, so different nonce values > will be used (X->Y) and (Y->X). > > Let: > A, B are different initiator nodes using the same > Node ID value. > C is a responder node communicating with A, B > > > Observe: > 1) A and B will each select large (e.g. 96-bit) Nonce > values independently. If the operational risk is > lower, a smaller Nonce value could be selected instead. > 2) The probability of selecting the same Nonce value is now > 1 out of 2^^96 -- this is a lower probability than selecting > the same inputs for generating a common CGA value. However, > unlike the CGA, neither initiator nor responder need to > perform any significant computation -- so no new DOS attack > window is created by using the Nonce mechanism. > 3) Since A and B are using different Nonce values, C is > perfectly capable of distinguishing between A and B. > 4) As is already the case today with IPv6, it is not valid > to have 2 unrelated nodes on the same subnet use the > same Identifier (IID in the case of IPv6) value at the > same time. (I say "unrelated nodes" here to distinguish > crisply from some kind of "distributed system" where 2 > or more boxes form a single logical computing system.) > > Note 1: The same kind of analysis can be done to show that this > works generally, even if A, B are responders and C is > an initiator. The details are omitted here because this > is already a long email. > > Note 2: None of the above mechanisms or analysis involve either > cryptography or any other expensive mathematical operation. > > (If it is still confusing, I'd urge re-reading the published > ILNP papers and also the ILNP Internet-Drafts to gain more > clarity on this.) > > Finally, if some folks want to use CGAs, that is fine. ILNP > permits the existing CGA specifications to be used without > any modification.
Without any modification? in the current CGA specification [RFC3972], the prefix is used as one of the inputs for the hash algorithms. If the subnet prefix (locator in ILNP) changed due to mobility or multihoming event, should the identifier be regenerated? If so, it seems conflict with the statement of "constant identifier as node move " in your slides. As mentioned in the CGA specification, if the prefix is not included in the generating algorithm, the security strength will be weaken (see the following quoted statement ). " As computers become faster, the 64 bits of the interface identifier will not be sufficient to prevent attackers from searching for hash collisions. It helps somewhat that we include the subnet prefix of the address in the hash input. This prevents the attacker from using a single pre-computed database to attack addresses with different subnet prefixes. The attacker needs to create a separate database for each subnet prefix." Due to the above reasons, in my RANGI proposal (called HRA previously, http://www.ietf.org/id/draft-xu-rangi-01.txt), the Administrative Domain (AD) ID replaces the routing prefix as one of the inputs for generating host identifiers. The AD ID is stable and will remain constant during mobility and multihoming. > Again, we've shown that ILNP has security properties no worse > than IPv6. > > > 1) Based on the assumption that the identifier is not > globally unique, > > if two hosts using the same identifier initiate > communication with a > > third host, how could this third host distinguish the different > > sessions from these two hosts? > > Please see above. There is sufficient other information to > distinguish the sessions from each other. This is discussed > in more depth in other published drafts/documents. Then you must make some change to the session. e.g., extending the 5 tuples of TCP session to 6 tuples. > > 2) Based on the assumption that the idenfiters are only > needed to be > > unique within the context of a given Locator, if a mobile > node moved > > to a new subnet, and unfortunately there is a host within > this subnet > > which uses the same identifier as the mobile node, should be mobile > > node renumber its identifier? > > If the node wanted to change its Identifier, it could do so > without losing any existing sessions. Really? since the sessions are bound to identifiers, wouldn't the sessions be disrupted by changing the identifiers? > However, kindly recall IPv6. The IPv6 rules say that a given > IID must be unique within the context of a specific /64 > routing prefix. Yes, but the rules do not say the IID must be unique globally. Hence, there is a possiblity that two nodes located in different subnet use the same IID (i.e., identifier in ILNP) > The ILNP rule is not more strict than the IPv6 rule. So > again, ILNP does not fail to support any case that works > today with IPv6. Not exactly. IPv6 uses the combination of routing prefix+IID as session identifier, and this idenfier ought to be unique globally. However, in ILNP, the IID part is used as identifier, which is not globally unique. > In normal operation, the ILNP Identifier would probably be an > EUI-64 with the scope bit set to "global" and would be formed > by using some > EUI-48 or EUI-64 already associated with the node. Recall > this also is entirely consistent with IPv6 practices on > forming an IID. In this case, the IEEE allocation rules > combined with the EUI-64 formation rules ensure that the > scenario you describe will not occur. > In some different case where an ILNP Identifier is being > formed in some other way (e.g. some pseudo-anonymous ID > algorithm), then as with IPv6 some form of DAD would be > required because the scope bit is set to "local". ILNP never > requires that a node use this form of Identifier, although a > node might choose to do so if it wishes. > > So one can again see that ILNP is imposing no new constraints > beyond those imposed by IPv6 at present, and that deployments > that work today with IPv6 would also seamlessly work with ILNP. > > Of course, ILNP provides various benefits (described > throughout the talk and the various drafts/documents) that > IPv6 does not provide. > So there is a net benefit to migrating to ILNP from ordinary IPv6. > > > 3) If I understand your ILNP correctly, the DNS server will > be used as > > the rendezvous to deal with the simultaneous mobility issue. In > > pratice, multiple hosts could share a FQDN for > load-balancing purpose, > > that's to say, the mapping between FQDN and I/L is 1:N, not > 1:1, how > > could the mobile node know which I/L is corresponding to the > > communicating node? Or do you believe the DNS should be changed so > > that each host will have a globally unique FQDN in your ILNP > > architecture? > > In the scenario you describe, existing deployments of that > kind share session state among the N physical boxes that are > clustered to emulate a single node. > > That is, the case you describe is not really a case of N > separate nodes, but instead it is the case of a single > distributed system that happens to be built out of a number > of boxes. This sort of clustering has been commonplace for > decades. (I think I first encountered it with a DEC VAX/VMS > cluster. One imagines modern systems are most commonly built > out of some flavour(s) of UNIX.) > > Moreover, in such cases in the real-world today, multiple "back end" > servers are fronted by some commercial load-balancing > appliance. Those appliances ensure that requests are handled > consistently by the server cluster. Various session > management mechanisms have been built by various commercial > vendors, but they all have the same apparent external > behaviour (i.e. from the perspective of the client system). Yes, I know the load-balancing can be done by some applications. However, we shouldn't exclude the possibility of using DNS to realize the same goal. Best regards, Xiaohu > No DNS changes are needed for ILNP, other than adding the I > and L records. > Optionally, also adding the LP record optimises DNS > performance and scalability for mobile network cases or for > site multi-homing cases. > > Yours, > > Ran > > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
