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 > >
- Re: [sidr] Route Leaks and BGP Security Christopher Morrow
- [sidr] Route Leaks and BGP Security Danny McPherson
- Re: [sidr] Route Leaks and BGP Security Jakob Heitz
- Re: [sidr] Route Leaks and BGP Security Russ White
- Re: [sidr] Route Leaks and BGP Security Christopher Morrow
- Re: [sidr] Route Leaks and BGP Security Jakob Heitz
- Re: [sidr] Route Leaks and BGP Security Jakob Heitz
- Re: [sidr] Route Leaks and BGP Security Randy Bush
- Re: [sidr] Route Leaks and BGP Security Russ White
- Re: [sidr] Route Leaks and BGP Security Robert Raszuk
- Re: [sidr] Route Leaks and BGP Security Shane Amante
- Re: [sidr] Route Leaks and BGP Security Christopher Morrow
- Re: [sidr] Route Leaks and BGP Security Terry Manderson
- Re: [sidr] Route Leaks and BGP Security Christopher Morrow
- Re: [sidr] Route Leaks and BGP Security Terry Manderson
- Re: [sidr] Route Leaks and BGP Security Christopher Morrow
- Re: [sidr] Route Leaks and BGP Security Danny McPherson
- Re: [sidr] Route Leaks and BGP Security Russ White
- Re: [sidr] Route Leaks and BGP Security Christopher Morrow
- Re: [sidr] Route Leaks and BGP Security Brian Dickson