Re: [RAM] Tunnelling Route Reduction Protocol

Robin Whittle <rw@firstpr.com.au> Tue, 21 August 2007 02:42 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INJhF-0005Ga-MX; Mon, 20 Aug 2007 22:42:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INJhF-0005Fu-9P for ram@iab.org; Mon, 20 Aug 2007 22:42:21 -0400
Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INJhA-0001c6-Vg for ram@iab.org; Mon, 20 Aug 2007 22:42:21 -0400
Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 485D859DA1; Tue, 21 Aug 2007 12:42:14 +1000 (EST)
Message-ID: <46CA50F0.2040001@firstpr.com.au>
Date: Tue, 21 Aug 2007 12:41:52 +1000
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: ram@iab.org
Subject: Re: [RAM] Tunnelling Route Reduction Protocol
References: <3c3e3fca0708200646j391fd621n568f2b791c93a36f@mail.gmail.com>
In-Reply-To: <3c3e3fca0708200646j391fd621n568f2b791c93a36f@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc:
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

Hi Bill,

Here are some thoughts after I had a quick read of:

  http://bill.herrin.us/network/trrp.html
  http://bill.herrin.us/network/trrp-implementation.html

Very roughly, I think TRRP is like LISP 2, with a transitional
arrangement for continued reachability during introduction, with
longer-term administrative arrangements for removing prefixes of
mapped addresses from the global BGP routing table.

I think the biggest problem TRRP faces is that when a packet arrives
at an ITR which has no mapping information, that the ITR must hold
the packet until it gets that information.  Via DNS, I guess that
could take a second or two or more.  Generally, I think this is an
unacceptable delay, since the application which sent the packet will
assume the packet or its response is lost, and will send another
one.  I think this is one major reason why no-one is seriously
proposing LISP 2 as a solution to the routing and addressing
problems.  Another concern might be about overloading the DNS system
with  more tasks.


Your multihoming service restoration system seems to rely on the ITR
getting a "destination unreachable" response when it sends a data
packet.  Without this, the ITR assumes that the packet is received
by the ETR and that the ETR can send the packet to the final
destination.  I think this would be a poor way of ensuring that the
packets really do reach their destination.  "Destination
unreachable" packets could get dropped, and you would need to ensure
there was no filtering of such packets between all ITRs and ETRs.
Yet some networks like to drop "destination unreachable" packets to
reduce the ability of an attacker to probe the existence of hosts in
their network.  This might limit how deep the ETRs are located.  Yet
having a deeper placement of ETRs helps with scaling - spreading the
load among more of them.  Deeper, closer, ETRs also reduces the path
length to the destination host.

So like LISP and eFIT-APT, TRRP's multihoming service restoration
functions are hard-coded into the protocol and are implemented
independently by each ITR.

In contrast, Ivip has no built-in multihoming service restoration
functions.  It is up to the end user to choose and supply their own
monitoring system, which can be arbitrarily flexible, complex and
costly as they choose.  This system is then given the power to
control the mapping of their addresses.  The Ivip system simply
follows these instructions.  The ITRs do not attempt to determine
reachability or decide on alternative ETRs to tunnel packets to.

This makes the Ivip system a relatively simple component, to be used
with other user-supplied components, to achieve a variety of
benefits - multihoming, TE, portability and mobility with generally
highly optimal path length.

You don't explain how an ETR can get packets to the intended
destination.  Presumably they could do so via a tunnel, in which
case each host requires special software to decapsulate the packet.
 Otherwise, the ETR needs a direct link to each destination host, or
the local routing system needs to be able to route the packets with
their raw addresses (the IP address of the destination host).  You
would need to ensure that all packets addressed to the hosts with
TRRP mapped addresses were sent via an ITR (apart from those
emanating from an ETR).  This is because only the ITR can have the
latest information on where the packets should be sent to.  The
local routing system can't be expected to change so rapidly, or to
make multihoming service restoration decisions.  I think this is a
common problem for LISP and Ivip (eFIT-APT too?).

Also, I understand the outer packet source address of TRRP's
tunneled packets is that of the ITR.  This makes it very difficult
for ETRs to protect against spoofed local source addresses when they
decapsulate packets.  Ivip uses the source address of the sending
host as the source address of the outer IP header of the
encapsulated packet.  This enables the ETR to perform some simple
tests when decapsulating the packet, which extends the reach of the
network's border router's filtering of source address of incoming
packets, to solve this problem:

http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-arch-00.html#anchor67


 - Robin


_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram