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

[Christopher Morrow <[e-mail]>]

On Tue, May 20, 2014 at 5:42 AM, Nick Hilliard <[e-mail]> wrote:
> On 20/05/2014 02:11, Jared Mauch wrote:
>> Is there a need for this to be explicitly documented within the IETF?  I
>> certainly agree there is a problem, but this feels like operational
>> guidance or perhaps a BCP or similar document?  (eg: Filter your peer
>> ASNs from your other peers).
>
> Well-maintained prefix / asn filters work well up to a certain size, but no
> further.  Poorly maintained filters break connectivity in ways which
> surprise and amaze.  Operationally there is an intersection of operator
> clue, network size and peer network size where prefix filters can work
> really well, but thar be dragons outside that intersection.

one point of the draft (perhaps not the point people are hoping for)
is that 'bgpsec + rpki do not stop valley-free breakage'. I don't know
that this was ever a goal for bgpsec/rpki though.

One goal which I think people (me too) were hoping for with a draft in
GROW was: "Define what a route leak is" followed by: "Tell me if this
is a problem for operations of networks"

I think 'is this a problem" is fairly well coverved by:
   o increased latency (unplanned long paths)
   o increased loss (paths not properly sized/planned/capacity-ready)

There MAY be MiTM problems, but one argument is that there are
whenever a packet crosses out of your administrative control. I don't
know that the hyperbolic argument (everything is a mitm chance!) is
helpful here, so I'd skip that. I would say that there are certainly
cases where a well planned leak can cause traffic inspection to be
possible (and MiTM) where the network operators were previously
unaware of such hazards.

The draft with it's current goal, I think, is easily summed up by:
  "If you don't police the routes in/out of your network bad things
could happen. BGPSEC/RPKI do not inherently police the routes in/out
of your network."

so in like 2 sentences the point made by the authors is clear... Still
no definition of 'route leak' though.

-chris