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

Christopher Morrow <christopher.morrow@gmail.com> Wed, 14 May 2014 20:11 UTC

Return-Path: <christopher.morrow@gmail.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 66CE41A017E for <grow@ietfa.amsl.com>; Wed, 14 May 2014 13:11:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 7j4vYci3748M for <grow@ietfa.amsl.com>; Wed, 14 May 2014 13:11:43 -0700 (PDT)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5C61A0176 for <grow@ietf.org>; Wed, 14 May 2014 13:11:42 -0700 (PDT)
Received: by mail-lb0-f180.google.com with SMTP id p9so51930lbv.25 for <grow@ietf.org>; Wed, 14 May 2014 13:11:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XIc3GJAFbsyDNg42socaNm3Wr6bShR3J6gJF9ssTmb4=; b=0MD+awzPSXGlRdt1x+Q1IsJ5TsZMOU+v1RGxbKfW+5lv+GkcXEe2Z+0oBSq8YzlioN qq4pSZFQ9GapM+qkZvGbWxoJhu3ZCZ7hOBJzDiPi8Mw+BDmaWRktiVgX4jp0NkId+Shz V/KUUZWPj0yesSy+WSr4P7UG01VEtSFTymDnE6f6qYYT2AgJD+ioBMR4uRnOD1iDlKki enrq8L2OtTSck+30H9f/l5egh5rRLhUwLeIdY0o6ER/95h7CusacNqXlR7a+Q2uaLPu1 KZ6zn6k5tSqyYy2XejDmTXnwKDapKhy49bRhyL5gPjFunsptBki/rwfeEzQj5+1mJ1Yh rLkg==
MIME-Version: 1.0
X-Received: by 10.112.189.138 with SMTP id gi10mr3789923lbc.15.1400098295179; Wed, 14 May 2014 13:11:35 -0700 (PDT)
Received: by 10.153.5.161 with HTTP; Wed, 14 May 2014 13:11:35 -0700 (PDT)
In-Reply-To: <CF98E925.1B9E1%wesley.george@twcable.com>
References: <CAL9jLabRKA2gezfRdzND1TSYMJO+a_4mVV+M302cLBFTUwYmTQ@mail.gmail.com> <CF96AEDB.1B684%wesley.george@twcable.com> <90570d084588512427a42c996c7827fe@tcb.net> <CF978ED2.1B75C%wesley.george@twcable.com> <0C1C347C-94C4-4C6E-9ADE-C9F3DC42046E@tcb.net> <CF98E925.1B9E1%wesley.george@twcable.com>
Date: Wed, 14 May 2014 16:11:35 -0400
Message-ID: <CAL9jLaYfwEPbXJUmXqAnTsz1EW7w_Tp8YoyyO71EgiMS6r1vaw@mail.gmail.com>
From: Christopher Morrow <christopher.morrow@gmail.com>
To: "George, Wes" <wesley.george@twcable.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/grow/Ohsizsmz54-AnznSS9GCXTIUu-c
Cc: "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: Wed, 14 May 2014 20:11:48 -0000

On Wed, May 14, 2014 at 3:59 PM, George, Wes <wesley.george@twcable.com> wrote:
> 1) route leaks are [definition, see text suggestion in previous message]
> 2) there are ways for this sort of leak to be used as a MITM attack
> [example from your draft]

I would actually argue that the general case of 'route leak' causes
things which are potentially more (broadly) harmful:
  latency increases
  loss increases
  blackholing

Sure, MiTM is a side effect of this, but really as soon as you cross
AS boundaries (even one you WANT to cross) you are open to MiTM
attacks. For GROW I would think the relevant bits are the latency,
loss, blackholing concerns.

MiTM gets good press, but isn't really required to discuss the actual
problem of 'oh crap why did my packets take a left turn THERE??'

> 3) these leaks occur very frequently [data citations from your draft]
>         3a) but not all are malicious, some are misconfigurations, some are
> intentional
> 4) routing hygiene helps to prevent, but not eliminate [discuss gaps]
> 5) BGPSec doesn’t fix, because it can only secure BGP attributes, and BGP
> has no semantics to convey intent or this type of inter-AS propagation
> boundary policy

(I agree with the rest of wes' points... I'm not sure it benefits
anyone in GROW land to hammer on bgpsec, especially when things like
rpki deployment would help stop leaks, if used in conjunction with
route filtering practices)

-chris
'just a guy' hat on.