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

From: Xu Xiaohu <[email-masked]>
Date: Fri, 02 Apr 2010 11:39:05 +0800

Hi Tony,

> -----邮件原件-----
> 发件人: Tony Li [mailto:[email-masked]]
> 发送时间: 2010年3月29日 13:59
> 收件人: xuxiaohu 41208
> 抄送: Christopher LILJENSTOLPE; Tony Li; [email-masked]; 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

---

From: Tony Li <[email-masked]>
Date: Fri, 02 Apr 2010 00:45:37 -0700

Hi Xiaohu,

> 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.  ;-(  ]

> Provided host identifiers were much easy to be stolen, all the above

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.

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

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

> established sessions should still survive.

Disagree.  That's service above and beyond what a legacy host would provide.

> Is mobility the first object of RRG?

Nope.  But it is one of the selling points.  ;-)

> Are these the only choices we have?

No, there are ever worse ones.  ;-)

> 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

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 2 Apr 2010 17:14:33 +0900

Below.

Regards,
DY

> Disagree.  That's service above and beyond what a legacy host would provide.

I'd believe that such a session will persist/survive in ILNP. Since ID
is used in a TCP connection in ILNP, even if the Locator changes by
moving, the TCP connection (or session, if people would continue to
call it that way confusingly) would survive/persist.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 03 Apr 2010 02:22:49 +1300

> Disagree.  That's service above and beyond what a legacy host would provide.

Today's session survival is provided by the RFC 4116 method,
i.e. it only occurs if the locator is unchanged.

RFC 3582 introduced a *new* requirement, namely that session
survival should occur even if the locator changes. Hence
shim6, of course.

So, we have two options (legacy behaviour and RFC 3582) and people
need to be clear which option they are referring to. I agree that
ILNP in legacy mode appears to be identical to RFC 4116. An analysis
of ILNP (and LISP) against RFC 3582 would be interesting.

    Brian