Re: [GROW] RouteLeaks - problem or not?
Arturo Servin <aservin@lacnic.net> Thu, 15 November 2012 01:08 UTC
Return-Path: <aservin@lacnic.net>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C105721E8030 for <grow@ietfa.amsl.com>; Wed, 14 Nov 2012 17:08:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pb2iy9hEbi8s for <grow@ietfa.amsl.com>; Wed, 14 Nov 2012 17:08:20 -0800 (PST)
Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id B2CCC21E802E for <grow@ietf.org>; Wed, 14 Nov 2012 17:08:19 -0800 (PST)
Received: from [IPv6:2800:af:ba30:fc38:e451:718e:d470:1cae] (unknown [IPv6:2800:af:ba30:fc38:e451:718e:d470:1cae]) by mail.lacnic.net.uy (Postfix) with ESMTP id 39942308444 for <grow@ietf.org>; Wed, 14 Nov 2012 23:08:18 -0200 (UYST)
Message-ID: <50A44080.8020704@lacnic.net>
Date: Wed, 14 Nov 2012 23:08:16 -0200
From: Arturo Servin <aservin@lacnic.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: grow@ietf.org
References: <CAL9jLaagY5bBe_8eRST8noEp2-o00Zkm2Qc59Ys7pak++EPGNw@mail.gmail.com> <CAL9jLaZT43OBwHqWs-xzy8qCm1UEyfN+hDKTgdrrvCc09xWNHw@mail.gmail.com>
In-Reply-To: <CAL9jLaZT43OBwHqWs-xzy8qCm1UEyfN+hDKTgdrrvCc09xWNHw@mail.gmail.com>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information
X-LACNIC.uy-MailScanner: Found to be clean
X-LACNIC.uy-MailScanner-SpamCheck:
X-LACNIC.uy-MailScanner-From: aservin@lacnic.net
Subject: Re: [GROW] RouteLeaks - problem or not?
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/grow>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2012 01:08:21 -0000
Chris, I think that draft-foo-sidr-simple-leak-attack-bgpsec-no-help-02 shows very well why rpki-origin-validation and bgpsec are vulerable to route leaks. Also it has a good and simple example of a route leak. One drawback that I see is that it does not explain the problem in general, the document is focused on route leaks as result of Man-in-the-middle-attack. Recent events relating leaks showed us that an attack it is not necessary, just some fat fingers in the right place and you are done. draft-dickson-sidr-route-leak-def-03 is more general, it tries to explain route leaks as an event and not as an attack. However the level of granularity and detail makes the document and the concept of leak hard to understand (perhaps it is because English is not my first language) and I found the simpler example in draft-foo-sidr-simple-leak-attack-bgpsec-no-help-02 much easier to follow. The other two documents (draft-dickson-sidr-route-leak-solns-01 and draft-dickson-sidr-route-leak-reqts-02) are about solutions and requirements of a solution. I think for now are beyond us. First I would prefer to define very well a route leak and then finding a solution. In my opinion some merging or re-writting of draft-foo-sidr-simple-leak-attack-bgpsec-no-help-02 and draft-dickson-sidr-route-leak-def-03 could result in a good explanation of leaks and why they are a problem. However, what ever were the next step, I would suggest to keep draft-foo-sidr-simple-leak-attack-bgpsec-no-help-02 or some sort of it because it may be useful in the future (or now) to describe the limitations of rpki-origin-validation and bgpsec. And finally, I would prefer (now that sidr and idr have stepped out to) to work on the definition of the route-leak problem here. After defined, we could move it either to sidr or idr (although I think both have a said on the possible solution). my 20 cents, as On 14/11/2012 20:44, Christopher Morrow wrote: > Apologies for the extra spam, there was a topic point I missed in this > mail, see below please. > > On Wed, Nov 14, 2012 at 5:18 PM, Christopher Morrow > <christopher.morrow@gmail.com> wrote: >> GROW Folks, >> The SIDR working group is working on security for origination and path >> data related to BGP routes. There has been a note (a few) about SIDR's >> effect(s) or not on 'route leaks'. There have even been a few notes on >> 'what is a route leak'. To date there is a draft which discusses route >> leaks: >> <http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-02> >> >> where the authors have attempted to describe one (or many possible) >> situations which are called 'route leaks'. They also attempt to >> outline security issues which are follow-on effects of the situation >> described. >> > > Additionally there were several drafts written by Brian Dickson aiming > to provide some definitions about route-leaks and some direction for a > solution, they are: > <http://tools.ietf.org/html/draft-dickson-sidr-route-leak-def-03> > <http://tools.ietf.org/html/draft-dickson-sidr-route-leak-solns-01> > <http://tools.ietf.org/html/draft-dickson-sidr-route-leak-reqts-02> > > These are probably best read in reverse numerical order: > definition > requirements > solution > > I believe the author aimed to talk about this in a GROW meeting, or on > the GROW list, I have not seen him pipe up as of yet to that end, > however. > > -chris > >> SIDR attempted to look at route-leaks and came up a bit stymied, they >> asked IDR for some assistance with the issue, IDR pushed back to GROW >> to decide: >> 1) What is a 'route leak' (perhaps the above draft identifies one >> examplar to be used in that definition) >> 2) Are 'route leaks' a problem that Operations folks care about >> 3) Should IDR (or the IETF proper) address 'route leaks' with some >> form(s) of fix action. >> >> The end result of the above 3 steps is to push back into IDR one of >> two action requests: >> 1) "Yes, route leaks are a problem, please fix them." >> or >> 2) "No, route leaks are not a problem, take no action." >> >> If #1 above is the answer, and IDR decides that changes to the BGP >> protocol are warranted (or are a possible solution to the problem) >> then SIDR has agreed to do what they can to 'secure' the bits >> added/changed/used in that endeavor. >> >> Could we have some discussion on-list about this problem, and some >> discussion about whether or not the draft referenced above fits the >> definition we would like to use for 'route leak'? I would also like >> the authors of the draft to decide where they would like to take their >> draft: >> 1) SIDR >> 2) IDR >> 3) GROW >> 4) other >> >> Thanks! >> -Chris >> (co-chair 1:2 of grow, and 1:3 in sidr) > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow >
- Re: [GROW] RouteLeaks - problem or not? Arturo Servin
- [GROW] RouteLeaks - problem or not? Christopher Morrow
- Re: [GROW] RouteLeaks - problem or not? Christopher Morrow
- Re: [GROW] RouteLeaks - problem or not? Jared Mauch
- Re: [GROW] RouteLeaks - problem or not? McPherson, Danny
- Re: [GROW] RouteLeaks - problem or not? Nick Hilliard
- Re: [GROW] RouteLeaks - problem or not? Jared Mauch
- Re: [GROW] RouteLeaks - problem or not? Christopher Morrow
- Re: [GROW] RouteLeaks - problem or not? Nick Hilliard
- Re: [GROW] RouteLeaks - problem or not? Nick Hilliard
- Re: [GROW] RouteLeaks - problem or not? Arturo Servin
- Re: [GROW] RouteLeaks - problem or not? Shane Amante
- Re: [GROW] RouteLeaks - problem or not? Christopher Morrow
- Re: [GROW] RouteLeaks - problem or not? Job Snijders
- Re: [GROW] RouteLeaks - problem or not? Warren Kumari
- Re: [GROW] RouteLeaks - problem or not? Shane Amante
- Re: [GROW] RouteLeaks - problem or not? Christopher Morrow
- Re: [GROW] RouteLeaks - problem or not? Warren Kumari
- Re: [GROW] RouteLeaks - problem or not? MAWATARI Masataka
- Re: [GROW] RouteLeaks - problem or not? Rob Shakir
- Re: [GROW] RouteLeaks - problem or not? Sonalker, Anuja
- Re: [GROW] RouteLeaks - problem or not? Michael Hallgren
- Re: [GROW] RouteLeaks - problem or not? Russ White
- Re: [GROW] RouteLeaks - problem or not? rob.shakir
- Re: [GROW] RouteLeaks - problem or not? Christopher Morrow
- Re: [GROW] RouteLeaks - problem or not? Arturo Servin
- Re: [GROW] RouteLeaks - problem or not? Christopher Morrow
- Re: [GROW] RouteLeaks - problem or not? Smith, Donald
- Re: [GROW] RouteLeaks - problem or not? Christopher Morrow
- Re: [GROW] RouteLeaks - problem or not? Murphy, Sandra
- Re: [GROW] RouteLeaks - problem or not? Danny McPherson