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
- Re: [RAM] Tunnelling Route Reduction Protocol Noel Chiappa
- Re: [RAM] Tunnelling Route Reduction Protocol William Herrin
- [RAM] Tunnelling Route Reduction Protocol William Herrin
- Re: [RAM] Tunnelling Route Reduction Protocol Robin Whittle
- Re: [RAM] Tunnelling Route Reduction Protocol William Herrin
- Re: [RAM] Tunnelling Route Reduction Protocol Robin Whittle
- Re: [RAM] Tunnelling Route Reduction Protocol William Herrin
- Re: [RAM] Tunnelling Route Reduction Protocol Brian E Carpenter
- Re: [RAM] Tunnelling Route Reduction Protocol Noel Chiappa
- Re: [RAM] Tunnelling Route Reduction Protocol William Herrin
- Re: [RAM] Tunnelling Route Reduction Protocol William Herrin