Re: [sidr] Route Leaks and BGP Security

Robert Raszuk <robert@raszuk.net> Mon, 21 November 2011 19:53 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D904F11E80C0 for <sidr@ietfa.amsl.com>; Mon, 21 Nov 2011 11:53:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEfvWgC9ZIpa for <sidr@ietfa.amsl.com>; Mon, 21 Nov 2011 11:53:25 -0800 (PST)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id A279611E8096 for <sidr@ietf.org>; Mon, 21 Nov 2011 11:53:25 -0800 (PST)
Received: (qmail 22463 invoked by uid 399); 21 Nov 2011 19:53:24 -0000
Received: from unknown (HELO ?192.168.1.57?) (83.24.180.210) by mail1310.opentransfer.com with ESMTP; 21 Nov 2011 19:53:24 -0000
X-Originating-IP: 83.24.180.210
Message-ID: <4ECAAC34.8080204@raszuk.net>
Date: Mon, 21 Nov 2011 20:53:24 +0100
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Russ White <russw@riw.us>, Randy Bush <randy@psg.com>
References: <20111117040124.18551.47190.idtracker@ietfa.amsl.com> <0863194F-7564-40A9-BB73-ABF8BB97C3AB@tcb.net> <7309FCBCAE981B43ABBE69B31C8D21391A4704525E@EUSAACMS0701.eamcs.ericsson.se> <CAL9jLabbHVauBYUkXCxdpWW90Vt+fMRzATr-aOrdU912ibxJeQ@mail.gmail.com> <4ECA44E2.1050402@riw.us> <m2ty5xo3si.wl%randy@psg.com> <4ECA8306.9070009@riw.us>
In-Reply-To: <4ECA8306.9070009@riw.us>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: sidr@ietf.org
Subject: Re: [sidr] Route Leaks and BGP Security
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Nov 2011 19:53:30 -0000

 >>    o a significant portion of the internet's isps will not publish
 >>      peering and customer business relationships,

Randy,

This is very true statement how every last week we have had a number of 
conversations where the same significant portions of ISPs expressed very 
great interest in increase their revenues in the context of CDNs.

So to get some money from the large content providers like Akamai or 
Google they are willing to expose their peering relations just to let 
those big guys may an intelligent content query redirection.

I do know this is a bit outside of the scope of this WG, but the 
requirement is common and with addressing one we could perhaps address 
the other one in one shot.

So if we would propose a solution which only asks to advertise given 
AS's neighboring ASes by peering to them of course without disclosing 
any policy one may have .. do you think this would not be a doable 
proposal ?

Regards,
R.

 > On 2011-11-21 17:57, Russ White wrote:
>
>>    o a significant portion of the internet's isps will not publish
>>      peering and customer business relationships,
>
> You can't secure what you don't tell anyone about. Security is about
> allowing others to compare the current state against what the state
> should be. What you're asking for is to ask someone else to take some
> specific action for you without telling them what that action should be.
> An impossibility.
>
>>    o ASs are not homogenous, A gives B local peering and international
>>      transit in frankfurt, but B may have no relationship with A in
>>      new york, or B may be A's customer in new york, and you will never
>>      know (and you do not want to see how this is done if you are
>>      anywhere near a meal)
>
> These can be accounted for in some of the systems that have been
> proposed in the past, or are now available.
>
>>    o this is just a repeat of the non-sense which wasted years of time
>>      of the last ietf attempt in this area,
>
> Which is a worse waste of time --designing a solution first, then
> fitting the requirements around it, or figuring out what the problem is,
> then thinking through possible solutions?
>
> :-)
>
> Russ
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
>