Re: [rrg] Fwd: I-D Action:draft-irtf-rrg-recommendation-09.txt - ILNP problems

Robin Whittle <rw@firstpr.com.au> Sun, 01 August 2010 03:20 UTC

Return-Path: <rw@firstpr.com.au>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CA813A6AC8 for <rrg@core3.amsl.com>; Sat, 31 Jul 2010 20:20:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.116
X-Spam-Level: *
X-Spam-Status: No, score=1.116 tagged_above=-999 required=5 tests=[AWL=-0.388, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lhxy9VPe21yQ for <rrg@core3.amsl.com>; Sat, 31 Jul 2010 20:20:38 -0700 (PDT)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 55C223A67CF for <rrg@irtf.org>; Sat, 31 Jul 2010 20:20:37 -0700 (PDT)
Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id E0312175CCB; Sun, 1 Aug 2010 13:20:55 +1000 (EST)
Message-ID: <4C54E81E.8060602@firstpr.com.au>
Date: Sun, 01 Aug 2010 13:21:02 +1000
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
MIME-Version: 1.0
To: RRG <rrg@irtf.org>
References: <20100730074502.17AD23A6AAE@core3.amsl.com> <66FBF08D-CCEC-45F6-9188-D0950681FD4C@tony.li>
In-Reply-To: <66FBF08D-CCEC-45F6-9188-D0950681FD4C@tony.li>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Ran Atkinson <ran.atkinson@gmail.com>
Subject: Re: [rrg] Fwd: I-D Action:draft-irtf-rrg-recommendation-09.txt - ILNP problems
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Aug 2010 03:20:52 -0000

Short version:   Draft 09 of the Report contains omissions and
                 misleading statements concerning Core-Edge
                 Elimination architectures in general and ILNP
                 in particular.


Hi Tony,

In the ILNP summary is the text:

  ILNP can be implemented such that existing applications (e.g.
  applications using the BSD Sockets API) do NOT need any changes or
  modifications to use ILNP.

I spent a day and a half trying to figure out how ILNPv6 could
support existing IPv6 applications - and I decided tentatively that
it couldn't be done.  Ran hasn't responded to my messages on this,
but you did - and you couldn't come up with a way of making it work
either:

   ILNP: stack behavior to work with IPv6 apps?
   http://www.ietf.org/mail-archive/web/rrg/current/msg07108.html

and 4 more messages in that thread.

The Critique assumes that ILNP can work with IPv6 applications -
although it notes that IP-address referrals won't work without
"additional mechanisms".  In practice, this means that some or many
IPv6 applications can't work with ILNP.

However, my attempt to see how ILNP would support IPv6 application
ran into trouble even without considering IP address referrals.  A
major difficulty was that when the app asks the stack to look up an
IP address, what does the stack give the app?  All attempts to figure
this out, by you and me, lead to outcomes which were clearly not
going to support IPv6 applications.

So I think the ILNP Summary as it stands contains a significant false
claim which is not tackled in the Critique.

Also, regarding ILNP, your Recommendation includes:

   It separates location from identity in a clear,
   straightforward way that is consistent with the
   remainder of the Internet architecture and makes
   both first-class citizens.

This is not true with ILNP mobility, since when the host roams to
another /64, there is no way of ensuring that some other host hasn't
already taken the IP address there with this hosts ID bits in the
lower 64 bits.   This has been extensively discussed in the threads:

   ILNPv6 Mobility problem
   ILNP Identifier and Locator semantics are muddled and !crisp
   ILNP Identifiers are not "first class citizens"
   ILNPv6 Mobility problem (attempt at summary)
   ILNPv6 Mobility - ILNP can't work with SEND (AFAIK)

ILNP mobility is subject to an "Identifier squatting" DoS attack,
which is easy to launch (look up the victim's FQDN and get its ID) by
the attacking host behaving in a manner which is indistinguishable to
the network from proper behaviour of any IPv6 or ILNP host.

Also, the Report doesn't distinguish between ILNPv6 and ILNPv4.
ILNPv4 makes all packets longer, and can only be introduced at all
once most or all DFZ and other routers have been upgraded.

For instance, in the Summary:

    Locators name subnetworks, rather than interfaces, so they
    are equivalent to an IP routing prefix.

is only true of ILNPv6.

Reading the Report as it stands, one might think:

  ILNP is for IPv4 and IPv6.

  ILNP doesn't require any changes to routers.

  ILNP mobility has no particular weaknesses specific to ILNP.

  ILNP supports existing applications.


But for ILNPv6:

  All applications must be rewritten.  (This places a huge
  additional burden on those who try to test ILNP - they
  will need to get a bunch of open-source apps and significantly
  rewrite them - and this may break the application's on-the-wire
  protocols.)

  Mobility is not robust against a simple DoS attack, or against
  a chance situation where the ID in the new /64 is already taken.

In addition, for ILNPv4:

  Most or all DFZ and other routers need to be upgraded before
  any ILNP hosts can communicate over the IPv4 Internet.


The Critique fails to capture two other objections to ILNP and other
CEE architectures:

  1 - They typically involve extra packets being sent and received
      by hosts (such as for DNS lookups) and so extra delays in the
      establishment of communications.

      For instance, A looks up B and sends B a packet.  If B's
      application needs to ensure its reply can only go to A, then
      B needs to find A's FQDN (AFAIK, by relying on reverse DNS
      lookup of A's IP address returning the FQDN) and then do a
      lookup of that FQDN to get A's Locator.  B cannot trust the
      Locator which came with A's initial packet since that
      packet could contain a locator not of the real A, but of a
      network where the attacker's machine has A's ID.

      Some applications don't actually need to do this, so if the
      applications are rewritten for ILNP, this will be less of a
      problem.  However, if ILNP is to support IPv6 applications,
      the stack in B needs to do these lookups before it can send
      B's application's reply packet - since IPv4/6 applications
      are written on the assumption that the routing system will
      never deliver a packet to a host with an Identity different
      from that of the packet's destination address.

      These DNS lookups take time.  They may involve intermediate
      lookups too.

      These delays to establishing communications, and the extra
      packets are particularly onerous for devices on 3G etc,
      wireless links which involve delays, costs, lost packets and
      bandwidth restrictions which are worse than what most of us
      are used to at home via a DSL service.

  2 - Substantial benefits to scalable routing and to anyone who
      adopts ILNP (or any other CEE architecture) only arise once
      all, or virtually all, hosts adopt it.  This is covered in:

        http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

      and so involves much greater hurdles to widespread adoption,
      while also requiring almost ubiquitous adoption before there
      can be substantial benefits.  Until all hosts (and so I think
      all apps) are upgraded, a significant proportion of
      communications will still rely on the old IPv4 or IPv6 system
      - so multihoming and mobility won't work for all
      communications.  Until then, networks will still want and need
      PI space to support the old style of communications.


With these omissions, and the false statements about ILNP, the 09
draft fails to inform readers of the major problems with CEE
architectures in general, and with some problems which are specific
to ILNP.

  - Robin