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

[Christopher Morrow <[e-mail]>]

In the vein of 'eggs':
  Shane Amante
   Level 3 Communications, Inc.
   1025 Eldorado Boulevard
   Broomfield, CO  80021
   US

   Phone: [phone]
   Email: [e-mail]

someone should probably update that...

In the vein of 'suggestions':
>From the introduction section, this sentence is a bit rough to parse:

  "This document describes a very simple attack vector that illustrates
   how RPKI-enabled BGPSEC [I-D.ietf-sidr-bgpsec-protocol] machinery, as
   currently defined, can be easily circumvented in order to launch a
   Man In The Middle (MITM) attack via BGP [RFC4271]."

Maybe, given the goal is to say: "Hey, rpki/bgpsec isn't going to help
stop a leak, which could be used to MITM user traffic." Something
like:

  "This document describes a very simple attack vector that illustrates how
   RPKI-enabled BGPSEC (reference) networks, as currently defined, can
   be easily circumvented in order to lanuch a Man in the Middle (MitM) attack
   against a targeted set of users."

I changed 'machinery' to 'networks' since there are less gears and
moving metal these days... and I don't think 'via BGP' is particularly
helpful, though I get the point that 'manipulating routing data has
caused the MitM to come into existence', I just couldn't come up with
a phrasing that worked and wasn't cumbersome :(

Also, in the suggestions bucket:
>From the Discussion section, third paragraph:

  "Assume that an RPKI-enabled BGPSEC deployment
   [I-D.ietf-sidr-bgpsec-protocol] is currently operational by all
   parties in the scenario and functioning as designed.


The description and assumption is that with BGPSEC/RPKI no one in the
picture would do route filtering of their customers, I think? I'm not
sure that BGPSEC/RPKI designs assume that happening.

The above also comes back into play here:
  "In order for an attacker (AS1) to divert traffic from ISP1 toward
   prefix P through their AS, AS1 must simply fail to scope the
   propagation of the target prefix P (1.1.1.0/24), received from ISP2.
   This is completed by announcing a syntactically correct BGPSEC update
   for prefix P to ISP1."

if ISP1 were doing things properly they'd also filter their customer's
prefixes...

Also, later on it's probably worth swapping out real-ip-addresses for
test-net space. I already get enough traffic to 1.1.1.0/24 ... I don't
need more as people try to experiment. :)

This sentence is redundant, since you cover default-bgp behaviour previously:
  "As a matter of fact,
   advertising these prefixes is the default behavior of many BGP
   implementations and explicit action must be taken to not advertise
   all prefixes learned in BGP."


This paragraph (still in the discussion part of the doc):
  " Google is the largest Internet site and processes billions of end-
   user transactions per day.  It became unreachable for approximately
   27 minutes.  At their scale, an outage of 27 minutes is extremely
   visible and, most likely, a financially measurable event.  In this
   example, its services became unreachable because a BGP peer
   improperly propagated the company's prefixes.  Because this was a
   highly visible outage, there exists a public acknowledgment of
   improper intent executed by one of Google's peers, proving that
   [RFC6480] and [I-D.ietf-sidr-bgpsec-protocol] would be unable to
   detect or prevent this type of attack."

has a bunch of speculative bits... mainly:
  "is the largest internet site"

  "At their scale, an outage of 27 minutes is extremely
   visible and, most likely, a financially measurable event."

I don't know that there's a study to support the first item, and i'm
not sure that the second is relevant... or supportable with data. I do
know that the particular incident noted was relatively press-heavy,
but didn't actually divert a meaningful amount of traffic.

The point in the last 2 sentences though that a peer mis-propagated a
route(s), and that their upstream accepted that route(s) still
certainly holds true. So does the point that just bgpsec+rpki isn't
helpful for this scenario. I'd remove the speculative bits and just
stick to the facts, if you wanted a larger incident to point at though
you could have used the 2007 PKtelecom incident, of course.

thanks for including the route-filtering-solves-this in the
penultimate paragraph though.

-chris



On Mon, May 12, 2014 at 9:59 AM, Christopher Morrow
<[e-mail]> wrote:
> Working Group Folks:
>
> The authors of draft-ietf-grow-simple-leak-attack-bgpsec-no-help would
> like to bring the draft to WGLC, this is that LC. Please have a read
> through:
>
>   <https://datatracker.ietf.org/doc/draft-ietf-grow-simple-leak-attack-bgpsec-no-help/?include_text=1>
>
> Who's abstract is:
>   "This document describes a very simple attack vector that illustrates
>    how RPKI-enabled BGPSEC machinery as currently defined can be easily
>    circumvented in order to launch a Man In The Middle (MITM) attack via
>    BGP.  It is meant to serve as input to the IETF's Global Routing
>    Operations Working group (GROW) during routing security requirements
>    discussions and subsequent specification."
>
> and raise questions/comments/suggestions/eggs on this list.
>
> I expect this WGLC to last for the normal 2wk period ending:
>   26-May-2014
>
> -chris
> grow-co-chair