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
>