Subject: Re: [rrg] Some concerns about ILNP//:Re: Recommendation

From: Tony Li <[email-masked]>
Date: Sun, 04 Apr 2010 16:36:51 -0700

Hi Xiaohu,

>>>>> CONCERN #1: Host ID Theft Threat
>> 
>> True, you can steal anyone's identifier, just like you can today.
> However,
> 
> This is true for ILNP, but not true for today's architecture. In today's
> architecture with uRPF enabled, you can only steal the identifier of
> somebody who is located in the same network as you are located in. In
> addition, if uRPF is enabled on each subnet, ID (a.k.a. IP address) theft
> becomes impossible due to DAD mechanism.

And in an ILNP architecture with uRPF enabled, you cannot steal someone's
address.  If you use the same identifier as someone else, you cannot simply
claim to be that host, as you cannot share their locators and cannot subvert
their connections.

Theft of a name when you cannot use it is wholly irrelevant.

>> what can you do with it?  Today, you can forge a source address and send a
>> packet with that forgery.  Unfortunately, the response will follow
> routing,
>> and unless routing has been compromised, the packet will not come back to
>> you.
>> 
>> This is still true under ILNP.
> 
> Then where the response packets will be really forwarded to? Whether to the
> malicious host or to the legitimate owner of that identifier?

Since you forged the locator, the responses will go back to the legitimate
owner.

> Here I'm not talking about connection hijacking issue.

Then what are we talking about?

>>>>> CONCERN #2: Host ID Global Uniqueness Assurance
>>> 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.

You're correct.  I should have said that the packet does NOT match any
current connection and thus appears to be an independent entity.

> 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?

No, since a new connection was established.

Regards,
Xiaohu

---

From: Tony Li <[email-masked]>
Date: Mon, 05 Apr 2010 17:59:44 -0700

Hi Xiaohu,

> My concern is how could the transport layer distinguish session A (Locator
> A, Identifier I, Nonce N, Destination D) from session B (Locator B,
> Identifier I, Nonce K, Destination D) once we use the trick mentioned below.

The transport layer connection lookup is keyed by (I, N, D).

Regards,
Tony

>>> "   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.
>>> "
>> 
>> 
>> Since the current TCP/UDP checksum is just a straight summation, zeroing
> out
>> the bits or excluding them are functionally identical and that what you
>> propose binds us to one implementation approach unnecessarily.

---

From: Tony Li <[email-masked]>
Date: Mon, 05 Apr 2010 18:11:51 -0700

> If so, does it mean the current transport protocols should be upgraded in
> order to support ILNP?

Yes, that's been the message all along.

Regards,
Tony