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