Re: [RAM] Tunnelling Route Reduction Protocol
"William Herrin" <bill@herrin.us> Wed, 22 August 2007 23:52 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 1INzzt-0005aa-3e; Wed, 22 Aug 2007 19:52:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INzzr-0005We-P6 for ram@iab.org; Wed, 22 Aug 2007 19:52:23 -0400
Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INzzq-0007Js-Qw for ram@iab.org; Wed, 22 Aug 2007 19:52:23 -0400
Received: by nz-out-0506.google.com with SMTP id i28so205482nzi for <ram@iab.org>; Wed, 22 Aug 2007 16:52:20 -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=YHAOLN20FZGSRrPNGhZ5JiZnSMSV0UKnw+6s24cijJ8clkAiUcdN4wGQfMfWclkDuVt5E0i7cp0lgalygd70ffEDBCkpe0+nO/S7geDm3Stw/R+Act12zo7Qid7ErIxdZRr3plgXkIoY8PtzftmBMupOQLkRILUTdOHT6swcV+M=
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=Y0avGEAVhniyhNHa9vXc18sCVAZxFM4utyKAtaEtVdJeMdoCLx/aEsJDBXlNaUIUvah9spyeCKRUO2uKBvTasVns1puuGPoDMJpYygDr8Vv99MW12IOUz2It3cu9kjXmpF3Jry8zRQG8Pe9+smxVF11y/45Dmg+C8KKPKWa01bE=
Received: by 10.143.10.15 with SMTP id n15mr147421wfi.1187826739858; Wed, 22 Aug 2007 16:52:19 -0700 (PDT)
Received: by 10.143.159.7 with HTTP; Wed, 22 Aug 2007 16:52:19 -0700 (PDT)
Message-ID: <3c3e3fca0708221652h4baffd8dia3dcfe338b258f8c@mail.gmail.com>
Date: Wed, 22 Aug 2007 19:52:19 -0400
From: William Herrin <bill@herrin.us>
To: ram@iab.org
Subject: Re: [RAM] Tunnelling Route Reduction Protocol
In-Reply-To: <20070822231449.B474986AE1@mercury.lcs.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20070822231449.B474986AE1@mercury.lcs.mit.edu>
X-Google-Sender-Auth: aa9c75767e52aa50
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: Noel Chiappa <jnc@mercury.lcs.mit.edu>
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/22/07, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote: > > There are several potential problems but the most serious is > > authentication. > > Yeah, I know - I've been doing some thinking in this area myself recently. > I know about the authentication - what are the other problems? Hi Noel, Well, if the ITR is expected to encode the return information in its communication with the ETR then every possible ITR for a given source address needs authoritative knowledge of every possible ETR for that address and it has to be able to implement the policy rules for traffic engineering with respect to those addresses. That requires significant complexity in the ITRs and since the policy rules have to match what the ITRs are capable of implementing, they're not likely to be very flexible. With strictly forward-lookups like what I have in TRRP, traffic engineering is the responsibility of the route-server and it can be arbitrarily complex. > > Theoretically a man-in-the-middle attack is possible, but > > operationally it has proven to be a non-issue. > > Well, there's also plain DoS - someone sends a packet claiming to be from > X, with a mapping for X, and the mapping is bogus, and sends the traffic to > somewhere random, or non-existent. I meant that man-in-the-middle is a theoretical issue with a DNS lookup like proposed in TRRP. A MitM could forge the DNS reply, causing the ITR to route traffic by way of an ETR on a network that should never see it. That's what DNSSEC is all about: it eliminates the attack vector. DNSSEC hasn't been widely adopted because operationally the attack vector hasn't proven to be a enough of a problem. If its not a problem when mapping www.google.com to 1.2.3.4 then its not likely to be a problem for mapping IP addresses to ETRs. Regards, 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