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

[Tony Li <[e-mail]>]

Hi Xiaohu,

>>> CONCERN #1: Host ID Theft Threat
> 
> In the current Internet architecture, uRPF can be used to avoid IP address
> (acting as host identifier) theft to some extent. In an ID/locator split
> architecture, without any ID authentication mechanism, it will become much
> easier for a malicious host to theft other hosts' identifiers.


True, you can steal anyone's identifier, just like you can today.  However,
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.

Relative to security, the ILNP identifier has properties very similar to the
low order bits of the IPv4 address: they are irrelevant without being bound
to a particular set of high order bits.  Stealing just the identifier
doesn't help you unless you can alter the binding of identifier to locator.
This is why the nonce's help protect against that change and why DNSSec is a
requirement.

Note that uRPF today only verifies your high order bits against your routing
prefix.  You can do the exact same thing with ILNP and you get exactly the
same level of security.  [Note that not enough people will, so it won't stop
spoofing.  Just like today.  ;-(  ]

 
> Some firewalls allow users to configure filters based on IP addresses
> (acting as host identifier). Similarly, some cell phones allow users to
> configure a black-list based on phone numbers to block incoming calls.
> Provided host identifiers were much easy to be stolen, all the above
> benefits would be lost.


Again, if someone is foolish enough to filter on source addresses, you can
do that with ILNP and it is just as (in)secure.  No change.

 
> Besides, in Section 5.5 of draft-ietf-ipngwg-esd-analysis-05, several
> denial-of-service attack examples are also mentioned. I wonder whether ILNP
> has already successfully dealt with them.


You'll note that if you carefully compare ILNP with GSE (the subject of that
draft), that there are several changes that impact directly on those points.


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