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

[Xu Xiaohu <[e-mail]>]

Hi Tony,

> -----邮件原件-----
> 发件人: Tony Li [mailto:[e-mail]]
> 发送时间: 2010年3月29日 13:59
> 收件人: xuxiaohu 41208
> 抄送: Christopher LILJENSTOLPE; Tony Li; [e-mail]; Scott Brim; Noel
> Chiappa
> 主题: Re: Some concerns about ILNP//:Re: [rrg] Recommendation
> 
> 
> Hi Xiaohu,
> 
> > CONCERN #1: Host ID Theft Threat
> 
> Given that the host ID is locally scoped, and ILNP does not claim to
provide
> any level of security above and beyond what legacy protocols provide
today,

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.

> could you please expound a bit on the threat?   What exactly do you expect
> an attacker to do with this stolen ID?  And how is it an attack that we
> wouldn't have today in v6?

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.

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.
 
> > If I understand it correctly, ILNP could also use some CGA like approach
to
> > deal with this issue.
> 
> 
> That would certainly be an extension, but is not covered today.
> 
> 
> > CONCERN #2: Host ID Global Uniqueness Assurance
> >
> > I know ILNP doesn't require the host identifer to be globally unique.
However,
> > it has to involve some other tricks (i.e., nounces) to deal with the
host
> ID
> > collision events.
> 
> More precisely, it uses nonces to confirm the association of one (locator,
> identifier) pair with another (locator', identifier) pair.

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? 
 
> > Without mentioning whether or not this choice has any extra advantage
over
> the
> > choice of global uniqueness ID, can we configure the filering-rule table
on
> a
> > given host based on these non-globally unique host IDs? Or do you have
any
> > better alternative for us to achieve the same goal as what we did today
(e.g.,
> > IP address (acting as identifier also in today's network) filtering
table)?
> 
> One could always filter on remote (locator, identifier) pairs, giving you
> the same semantics that you have today with source address filtering.
> However, the security of ANY remote source address is of questionable
value.
> This is already true today.
> 
> Filtering the destination address today for incoming packets is generally
> considered much safer, as the address is presumably under the (reasonably
> secure) management of the local network.  The analogous effect in ILNP is
to
> filter on incoming destination identifiers.  This allows filter rules to
be
> independent of the locator, thus easing renumbering chores.  If mobility
is
> not permitted within the local domain, then the destination locator can
also
> be included in a filter rule, in whole or in part.
> 
> 
> > CONCERN #3: Motivations for Earlier Adoption of ILNP
> >
> > Considering a scenario where a legacy IPv6 host initiates a session to
an
> ILNP
> > host which is a multi-homed host,  the legacy host will obtain several
PA
> > addresses for that ILNP host in a DNS reponse to its DNS query, then the
> > legacy host will use one of the PA addresses of that ILNP host for
initiating
> > a session. Once the ILNP host is rehomed, can the already established
session
> > still survive?
> 
> No, since one correspondent is a legacy host, you only have legacy
> capabilities.

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.

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

> > Maybe somebody will argue that it doesn't matter since the legacy host
will
> > attempt to use the other PA address once the previous one is failed.
However,
> > my concern is whether it is acceptable for the earlier adopters of ILNP.
I
> > roughly believe they will still prefer the PI addresses, rather than
ILNP.
> 
> 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?

> > Take IPv6 transition as an example, can the ISPs disable the IPv4 access
> > service while providing IPv6 access service to their customers? When the
ISPs
> > provide their customers some new choices, they can not deprive the
interests
> > and benefits that the customers has already have when using the current
> > choice.
> 
> As Randy Bush would say: I encourage all my competitors to disable IPv4,
> immediately.  ;-)

Perfect!

> v4 and v6 will continue to co-exist for some time, and IMHO, there will be
> NAT between the different versions to provide continuous service.
> 
> I'm not understanding the relevance of this to RRG.

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.

Best wishes,
Xiaohu

> > still survive

> > Maybe I am totally wrong.
> 
> And maybe not.
> 
> Regards,
> Tony