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

From: Xu Xiaohu <[email-masked]>
Date: Fri, 02 Apr 2010 18:01:48 +0800

<skiped>

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

IMHO, taking the above scenario into account, the following statement DOES
need some modifications:

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

Best wishes,
Xiaohu

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

---

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

Hi Xiaohu,

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

Regards,
Tony