Re: [RAM] Tunnelling Route Reduction Protocol

"William Herrin" <bill@herrin.us> Tue, 21 August 2007 18:25 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 1INYPf-0003Bg-O4; Tue, 21 Aug 2007 14:25:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INYPe-0003Ba-2t for ram@iab.org; Tue, 21 Aug 2007 14:25:10 -0400
Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INYPd-0003Ew-4L for ram@iab.org; Tue, 21 Aug 2007 14:25:10 -0400
Received: by nz-out-0506.google.com with SMTP id i28so605109nzi for <ram@iab.org>; Tue, 21 Aug 2007 11:25:08 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=d+xMDtHrmXJgjpEul/akzG3UJNpU3qZ4k6/RFE9BMKXOu6nbTl87aZGcwnCJMtKm3VHmKbeA0yyFRglJjwZikqj7Zuj3CgiISP65pcMPjo+AozFYT9aKCeZ3eMpmU0ABSYhwzCZOm2UHwlMbreimS2LSW3Sq4weh5BUJ1YhkB9o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=kQzSzTrVgBIS+UvqK108Ll+7BvUcv+OSbnuGSu6i0tYkFSUjET/pep7k2aLaEocwoY/HRjIgVK4mBoz3NUCFX1M9aXiI82/NUtLb6T9YdJGAgVo0XanSpAI3a24kWDP5rE3dFhmRSFC5q1+mMDSziI5Jx7MSmvZgATyxNrqlp9U=
Received: by 10.142.246.8 with SMTP id t8mr1028746wfh.1187720706990; Tue, 21 Aug 2007 11:25:06 -0700 (PDT)
Received: by 10.143.159.7 with HTTP; Tue, 21 Aug 2007 11:25:04 -0700 (PDT)
Message-ID: <3c3e3fca0708211125k4cf981c5i3c58c9c606a63cfc@mail.gmail.com>
Date: Tue, 21 Aug 2007 14:25:04 -0400
From: William Herrin <bill@herrin.us>
To: ram@iab.org
Subject: Re: [RAM] Tunnelling Route Reduction Protocol
In-Reply-To: <46CAF9EB.1010406@firstpr.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <3c3e3fca0708200646j391fd621n568f2b791c93a36f@mail.gmail.com> <46CA50F0.2040001@firstpr.com.au> <3c3e3fca0708210630r7d559c6fk94bc38c1aaa68df7@mail.gmail.com> <46CAF9EB.1010406@firstpr.com.au>
X-Google-Sender-Auth: f9b18a09a29c3796
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48
Cc: Robin Whittle <rw@firstpr.com.au>
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

On 8/21/07, Robin Whittle <rw@firstpr.com.au> wrote:
> I understand - as I should have earlier - that your proposal
> involves a separate set of nameservers, which can be scaled to deal
> with the load of queries, including I guess by using anycast servers
> in multiple locations, as with the root nameservers.

Hi Robin,

That's essentially correct. It starts at the same root as everything
else but follows its own branch of the tree.

> OK - I understand from this that TRRP and Ivip are both relatively
> simple "components" of the complete multihoming solution, with the
> end-user supplying their own monitoring system to update the mapping
> database.

Correct.


> I figure that either the operator of the DNS server covers address
> space for many end-user networks, and that each end-user might want
> to choose some monitoring system which is different from whatever
> the DNS operator has available - and so would pay someone else to
> run that monitoring service and tell the DNS operator what changes
> to make to the mapping of their address space . . .  Or that the
> authoritative controller of the DNS information (a subset of what a
> whole server controls) is the end-user organisation themselves.

Correct. I envision both operating mechanisms being used. I also
expect a market to develop for an optimizing server which offers
different answers depending on the source of the query, much like
companies such as Akamai do now for http content. Such a device could
take factors like latency, packet loss, the relative sizes of the
customer's upstream connections and current use data to optimize
traffic engineering.

Because its keyed to individual IP addresses, the traffic engineering
can extend all the way down to the host level if desired. Perhaps
you'll program the mail servers to prefer the least-cost path while
the web servers prefer the best performance path. Today this can only
be done at the coarse /24 level and then only by deaggregating and
polluting the DFZ.


> With Ivip, I aim to get those changes to ITRs within a few seconds.
>  Your TRRP arrangement relies on cache time expiration, so the
> response speed for multihoming service restoration needs to be
> traded off against the amount of query traffic to the nameservers.

Correct, although there is an optional component that allows the
information to be propagated sooner, within a few seconds of the
change.

> > Note that that the ITR has no other mechanism for detecting a failure
> > downstream from the ETR. If the ETR is reachable but it can't reach
> > the end-user network, the destination unreachable goes back to the
> > sender, not the ITR itself.
>
> OK - so the ITR is not involved in this.  Some separate monitoring
> system is required to find out which is the best ETR to use,
> irrespective of whether traffic packets are being sent to the
> destination host or not.

Correct.

> I don't clearly understand quite a few of the next paragraphs - but
> it is late in the evening ....  I will read them again in the next
> day or two.

Its more likely that I didn't explain myself well. I'll take another stab at it.

The ITR primarily relies on the TTL offered in the DNS response packet
to determine how long to cache the destination ETR before checking to
see if its still valid. Even if you set the TTL to something like 60
seconds, that means a slow recovery to failure. I don't tackle this
problem directly. Instead, I come at it from several sides:

1. ETR unreachable. The ITR ignores the TTL and performs a new lookup
immediately. If the DNS hasn't been updated yet, it discards the
unreachable ETR from the results and tries the next best.

2. No direct route to the Destination from the ETR. The packet moves
towards the default route inside the AS which ends at another "end of
the line mode" ITR. The ITR recognizes that there should have been a
local route for the packet. As a result, it re-encapsulates the packet
and sends it to the next best ETR which isn't local. This rerouting
continues briefly until the DNS is updated and the ITR's copy of the
DNS record expires.

3. No direct route to the Destination from the ETR. The ETR optionally
sends a preemptive change notification to the ITR, advising it that it
has no route to the destination. If the ITR is paying attention, it
eliminates the ETR as a candidate for that destination.
http://bill.herrin.us/network/trrp-preempt.html

4. DNS updated with new routes. The DNS server optionally sends a
preemptive change notification to all addresses which recently
requested the now-updated record. Where those DNS resolvers are also
the ITRs, they'll re-lookup the route.
http://bill.herrin.us/network/trrp-preempt.html

5. ITR is in "passthrough mode" rather than "end of the line" mode. In
passthrough mode, the ITR attempts to encapsulate packets but
retransmits them as raw IP towards the default route if it can't
quickly do so. Passthrough mode is intended for a NAT firewall or the
packet's originating host. These systems have state information about
a number of the protocols moving through them. The ITR component can
take a hint from lower-level retransmits and switch to an alternate
ETR if the chosen ETR isn't getting the job done.

The ITR has to be outside any NAT firewall for obvious reasons. As a
result, "passthrough mode" is of limited utility in IPv4. IPv6 has no
NAT, thus it should be possible to implement a passthrough-mode ITR on
every IPv6 host that wants to with the resulting improvement in
performance.

6. Simple case: the addresses are single-homed to a classic multihomed
organization. For example, a customer of one ISP where the ISP is a
DFZ participant. In this case, only one ETR is offered. Plain old BGP
finds the new route to the CIDR block containing the ETR. The ETR
itself is stateless; within the AS its address can be anycasted by any
ETR device capable of doing the job.

7. Silent death. Either the ETR or destination is unreachable but none
of the notifications make it back to the ITR. The destination remains
unreachable until the TTL on the DNS response that provided it
expires. The relookup is expected to withdraw the bad ETR and provide
a new valid ETR.


> > Hmm. Would you jimmie up an example of aberrant behavior you feel
> > couldn't be adequately addressed within the ETR or ITR, or via
> > existing mechanisms for protecting against spoofed addresses?
>
> Sections 14.1 to 14.1.2.5 cover this:
>
> http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-arch-00.html#anchor67

Thanks. I've read that, but I could use help constructing a scenario
that behaves aberrantly under TRRP.

For example, the ETR can be expected to filter packets claiming to be
both from and to an address on its local lan. No properly configured
ITR will generate such a packet. So, that case is eliminated as a
spoofing possibility.

Another example: an end-user org wants to stop spoofing at its
upstream border even though it has multiple LANs and ITRs operating in
passthrough mode. This remains possible. Implement a trivial
split-horizon DNS at the resolver so that internal addresses are
always directly routed. Then filter any packets with an internal
source address at the ETR. So, this case is eliminated as a spoofing
possibility.

A bad example: an ISP wants to stop spoofing at its upstream borders.
It can't do this for multihomed customers now. Packets from the
customer could legitimately arrive from somewhere other than the
customer's link.

What's an example of a case that isn't susceptible to spoofing in
today's network designs but would be susceptible with TRRP?

Thanks,
Bill Herrin



-- 
William D. Herrin                  herrin@dirtside.com  bill@herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

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