Hi, Ran,
Another way of asking the same question to you.. just to reconfirm our
common understanding.
Two tuples:
(I, N1, D)
(I, N2, D)
Would these two be two different connections?
If it is true, then ID collision (from different locations) won't be a
problem as long as Nonce values are different.
On Wed, Apr 7, 2010 at 9:25 AM, RJ Atkinson <[email protected]> wrote:
>
> Earlier, Tony Li wrote:
>> The transport layer connection lookup is keyed by (I, N, D).
>
> Yes.
>
>
> And this is the essence of how ILNP can continue to work properly
> even if 2 nodes (1) use some locally generated Identifier
> [setting the Scope bit of the ID value to local, of course] and
> (2) collide to the same Identifier value. Given that there are
> 62 arbitrary bits in a local-scope Identifier, such a collision
> is remarkably unlikely to occur in normal operation.
>
> The separation/differentiation of different sessions using the
> same ID pair can be implemented either at the top of the network
> layer or at the bottom of the transport layer. I don't see a
> compelling reason to require one implementation approach
> over another.
>
> (If it were my code, I'd probably do it at the top of the Network
> layer, in order to minimise transport protocol implementation edits,
> but other folks' mileage could well vary for implementation-specific
> reasons.)
>
> Since Tony has expressed this MUCH more clearly than the
> current Internet-Drafts do, I plan to borrow the above
> language from Tony when I edit the drafts to try to clarify
> this question.
>
> More generally, it is my belief that deploying ILNP creates
> no new vulnerabilities as compared with ordinary (i.e. IPsec
> NOT in use) IP. Kindly recall that even without IPsec, the
> use of the nonce protects against off-path attackers, and
> please also recall that existing ordinary IP is vulnerable
> in various ways to on-path attackers. If someone believes that
> ILNP has created some new vulnerability not present in ordinary IP,
> a very clear and precise description of the perceived issue
> would be useful. Also, please note that the "analysis" of the
> never-published I-D on GSE was rejected by the IETF Security
> Area at the time that I-D was written and (in any event) was
> about GSE rather than ILNP.
>
> Of course, IPsec can be used with either ILNP or IP,
> should stronger cryptographic protection be desired.
> Even if IPsec is in use, the ILNP Nonce is still required,
> which preserves the ability to distinguish different ILNP
> sessions that happen to use the same ID pair.
>
> In the case of ILNP, IPsec even works if Locator values change,
> since ILNP IPsec binds only to the Identifiers, and does NOT
> bind to the Locator values. So in this respect, ILNP IPsec
> is architecturally better than ordinary IPsec.
>
> Yours,
>
> Ran Atkinson
>
> PS: My thanks to Tony for taking the time to respond to these questions,
> and my apology for not being able to spend more time staying current
> with this list.
>
>
>
> _______________________________________________
> rrg mailing list
> [email protected]
> http://www.irtf.org/mailman/listinfo/rrg
>
--
Regards,
DY
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg