<skiped> > > >>> CONCERN #2: Host ID Global Uniqueness Assurance > > > > > > By the way, I noticed a statement in draft-rja-ilnp-nonce-02 as follows: > > > "In the deployed Internet, packets sometimes arrive at a > > > destination out of order. A receiving node MUST drop a packet > > > arriving from a correspondent if the Source Locator of the > > > received packet is not in the receiving node's ILNP Session > > > Cache's Set of Correspondent Locator(s) UNLESS that packet > > > contains a Nonce Option with the appropriate nonce value for that > > > Source Identifier and Destination Identifier pair. This is done > > > to reduce the risk of session hijacking or session interference > > > attacks." > > > > > > I wonder what will happen if two hosts owning the same host identifier > > > occasionally communicate with a third party in accordance with the above > > > guidance as " A receiving node MUST drop a packet > > > arriving from a correspondent if the Source Locator of the > > > received packet is not in the receiving node's ILNP Session > > > Cache's Set of Correspondent Locator(s) UNLESS that packet > > > contains a Nonce Option with the appropriate nonce value for that > > > Source Identifier and Destination Identifier pair." > > > > > > If this case has been mentioned somewhere, would you please kindly tell > me > > > which section of which draft? > > > > > > Again, absolutely nothing will happen. Identifiers are not global, they are > > only unique _within_ a locator. Thus, if your cache contains: > > > > (Locator A, Identifier I, Nonce N, Destination D) > > (Locator B, Identifier I, Nonce K, Destination D) > > > > And you now receive a packet with > > > > (Locator C, Identifier I, Nonce L, Destination D) > > > > Then the receiver drops it per the above rule. It's clearly a forgery. > > Why do you clearly believe the packet with (Locator C, Identifier I, Nonce L, > Destination D) is a forgery? ILNP doesn't require the identifier to be globally > unique. In other words, it is absolutely possible and legitimate that two hosts > having the same identifier communicate with a third party at the same time. > > According to your above logic, if a malicious host impersonates the legitimate > identifier owner and establishes a session with a given server in advance, does > that mean the legitimate identifier owner will not be able to access that server > later?
IMHO, taking the above scenario into account, the following statement DOES need some modifications: " With this proposal, transport protocols include only the Identifier in their pseudo-header calculations, but do not include the Locator in their pseudo-header calculations. To minimise the changes required within transport protocol implementations, when this proposal is in use for a communications session, the Locator fields are zeroed for the purpose of transport-layer pseudo-header calculations. " Best wishes, Xiaohu > > > However, if it receives: > > > > (Locator C, Identifier I, Nonce N, Destination D) > > > > Then it falls into the latter clause. It takes knowledge of both identifier > > and nonce to disrupt communications. > > > > > > >>> CONCERN #3: Motivations for Earlier Adoption of ILNP > > > > > > No, IMHO, the ILNP hosts should provide the same connectivity service to > > > the legacy hosts as today. That's to say, once the ILNP host moves from > one > > > attachment point to anther due to re-homing (or mobility), the already > > > established sessions should still survive. > > > > Disagree. That's service above and beyond what a legacy host would provide. > > > > > > >> 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. > > > > > > Is mobility the first object of RRG? > > > > > > Nope. But it is one of the selling points. ;-) > > > > > > >> Perhaps, but deploying PI addresses and ILNP is far preferable than doing > > >> nothing and deploying PI addresses without ILNP. ;-) > > > > > > Are these the only choices we have? > > > > > > No, there are ever worse ones. ;-) > > > > > > > My point is that subscribes would not prefer ILNP to PI addresses if ILNP > > > would degrade the already obtained benefits from PI address usage. E.g., > > > once the ILNP host is re-homed, the already established sessions between > > > this ILNP host and legacy hosts will be interrupted. > > > > True, ILNP will not provide benefits until the correspondents are upgraded. > > Asked and answered. > > > > Regards, > > Tony _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
