Re: [GROW] WGLC: draft-ietf-grow-simple-leak-attack-bgpsec-no-help

"George, Wes" <wesley.george@twcable.com> Tue, 13 May 2014 13:48 UTC

Return-Path: <wesley.george@twcable.com>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F9D1A0096; Tue, 13 May 2014 06:48:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.416
X-Spam-Level:
X-Spam-Status: No, score=-0.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJAML3R-7sPl; Tue, 13 May 2014 06:48:34 -0700 (PDT)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9A72E1A00BC; Tue, 13 May 2014 06:48:34 -0700 (PDT)
X-SENDER-IP: 10.136.163.13
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.97,1044,1389762000"; d="scan'208";a="301437860"
Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 13 May 2014 09:48:08 -0400
Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Tue, 13 May 2014 09:48:27 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: Christopher Morrow <christopher.morrow@gmail.com>
Date: Tue, 13 May 2014 09:48:32 -0400
Thread-Topic: [GROW] WGLC: draft-ietf-grow-simple-leak-attack-bgpsec-no-help
Thread-Index: Ac9usgSNLG/F6m/MTxCMtfQp1oUacg==
Message-ID: <CF978B01.1B737%wesley.george@twcable.com>
References: <CAL9jLabRKA2gezfRdzND1TSYMJO+a_4mVV+M302cLBFTUwYmTQ@mail.gmail.com> <CF96AEDB.1B684%wesley.george@twcable.com> <CAL9jLaZ9J52Dt5n1Wk2KYTqwzmefGxvq-bRcfMfhWBNwf_6ZGg@mail.gmail.com>
In-Reply-To: <CAL9jLaZ9J52Dt5n1Wk2KYTqwzmefGxvq-bRcfMfhWBNwf_6ZGg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.1.140326
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/grow/LG_sFHALZN9bOcsjenDk8-swmAY
Cc: "grow-chairs@ietf.org" <grow-chairs@ietf.org>, "grow@ietf.org grow@ietf.org" <grow@ietf.org>
Subject: Re: [GROW] WGLC: draft-ietf-grow-simple-leak-attack-bgpsec-no-help
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 13 May 2014 13:48:36 -0000

On 5/12/14, 11:35 PM, "Christopher Morrow" <christopher.morrow@gmail.com>
wrote:


>possibly the authors are aiming at just defining what a leak is (one
>example type) so discussions can progress beyond 'what is a route leak
>again? can you point me at an RFC/definition of same?'

Well, not to be pedantic here, but since this has been adopted as a WG
document, the question is no longer what the authors’ intent was. The
question is what is the WG’s consensus of what this document is meant to
accomplish, and does it do so?

My view is that this document doesn’t define a route leak. It provides an
example of a route leak, but otherwise it mainly seems to follow that old
(and mostly useless) test for obscenity, “I’ll know it when I see it…”

In the interest of “send text”:

If I were to define a route leak succinctly, I’d say something like:

A route leak occurs when a valid (in this document’s case, valid=
validated by RPKI Origin Validation and BGPSec) route announcement is
propagated beyond its intended AS boundary. The AS boundary can be one, or
an arbitrary number of ASNs away, and may be different for different BGP
Peer ASNs. These leaks can occur due to either misconfigurations or
malicious intent (I.e. An attempt to perform a MITM attack), (and any
solution should provide means to prevent both types of leak).

But getting away from succinct toward complete requires defining what
route policy is and what intent means in this context, which should
include a discussion about how much info about policy or intent can be
derived from available data and tools today (perhaps with references to
the IRR data and other analysis tools) and whether there is enough
information there to distinguish an intentional route leak (i.e. A
conscious deviation from standard routing policy to allow a subset of
routes or ASNs to be propagated to a type of peer that normally wouldn’t
see them) from an unintentional one.

Thanks,
Wes


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.