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

From: Christopher Morrow <[email-masked]>
Date: Mon, 12 May 2014 09:59:44 -0400

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

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 12 May 2014 14:12:17 -0400

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

   Phone: +1 720.888.1000
   Email: [email-masked]

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

---

From: "George, Wes" <[email-masked]>
Date: Mon, 12 May 2014 17:42:13 -0400

I see a thread dated 2013 Nov in GROW, in which substantive discussion and
comments were provided after -03 was published, in which the authors
mainly just expressed why they were frustrated with SIDR and the IETF in
general for in their minds, ignoring this problem because it was hard,
rather than addressing the concerns raised within the WG. -04 is a
keepalive to reset the expiration date with no substantive updates. Why
are we now talking about WGLC?
Chris, you were one of the ones who said that your comments hadn’t been
addressed yet.
(https://mailarchive.ietf.org/arch/msg/grow/0ho_RU3e15TCvp4p8ScCeObk42Y)

Substantive comments:
This document provides one example of a route leak causing a problem that
BGPSec does not protect against, but still does not do much to provide
guidance on how such a leak would be systematically identified, It does
note that there are data supporting the assertion that this is a real
problem, and imply that perhaps additional analysis of that data would
reveal more information. I don’t think that anyone would dispute that this
is a valid attack. However:
        "This document is meant to provide input into routing protocol design
choices being
        considered within the IETF, and to foster discussion of the practical
        implications of "policy" and "intent" in operational routing system
        security."

This document provides no actionable guidance beyond articulating the
basics of the attack, certainly no meaningful discussion of policy vs
intent other than to note that discerning intent is difficult, and as such
the draft is absolutely not ready for publication if the above is its
goal. We’re not hiding behind SIDR’s carefully crafted requirements and
charter here, so let’s actually have the discussion about policy and
intent and see if we can come to some consensus on how to use that info to
define a route leak such that we can first systematically find, and then
protect against it. I absolutely want to see a solution to this problem,
but one example/existence proof isn’t enough to get us moving in that
direction.

Thanks,

Wes

On 5/12/14, 9:59 AM, "Christopher Morrow" <[email-masked]>
wrote:

>_______________________________________________
>GROW mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/grow

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.

---

From: Danny McPherson <[email-masked]>
Date: Mon, 12 May 2014 16:06:20 -0600

> are we now talking about WGLC?

Because we'd like this memorialized in an Informational RFC, that's the 
purpose, methinks.

> (https://mailarchive.ietf.org/arch/msg/grow/0ho_RU3e15TCvp4p8ScCeObk42Y)

Eric owns comments follow-up, I'll defer to him on responding to that 
bit....

> guidance on how such a leak would be systematically identified,

Nor does it have to in any programmatic way, IMO.  It's easy for an 
entry level routing person to understand what the problem is here, hell, 
they have to deal with them every day.  It doesn't have to expand to 
every possible reason or define detection mechanisms.  We hope folks 
that read such things will be as clever as the SIDR folks and solve this 
solution :-)

However, if you can be more specific about examples not covered or send 
text then we'd be happy to incorporate it.

> It does
> goal.

We didn't say we'd proclaim all is accomplished, we said we'd like to 
foster discussions of policy v. intent.  This very discussion makes me 
think it works, and given that even you don't think anyone would dispute 
that this is a valid attack, I claim success and request publication -- 
although perhaps we should update with more recent leak references and 
we can certainly encourage more folks to do research, with a stable 
reference, which was precisely the intent.

> We’re not hiding behind SIDR’s carefully crafted requirements and
> protect against it.

I'm glad you agree it was carefully crafted.  This draft is only meant 
to document the issue above, which you seem to agree that no one would 
dispute.  It doesn't need to be the kitchen sink for attack vectors.

> I absolutely want to see a solution to this problem,

I don't think that's a surprise Wes.  We should document what some 
believe the problems are before we begin designing solutions, else we'll 
end up with more complicated solutions that don't address what me 
operators believe to be the key issues.

-danny

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 12 May 2014 23:35:52 -0400

I should have noted in my follow-up email: "I'm not expressing an
opinion about the document, but here are a few suggestions/questions"
Sorry for not being clear about that.

> Chris, you were one of the ones who said that your comments hadn’t been

yup, and there was some discussion which petered out after a while.
Regarding my questions/comments/suggestions to the previous (or
original even) version of the document, I don't recall hearing back
about those, i figured that either I was in the weeds (I didn't think
so) or someone else decided that my suggestions/comments didn't quite
fit into the document.

that's sort of a shame, but if i'm in the weeds: "ok".

> intent other than to note that discerning intent is difficult, and as such

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?'

I think this was part of the impetus for the document, or that's what I recall.

---

From: "George, Wes" <[email-masked]>
Date: Tue, 13 May 2014 09:48:32 -0400

>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

---

From: "George, Wes" <[email-masked]>
Date: Tue, 13 May 2014 09:51:06 -0400

On 5/12/14, 6:06 PM, "Danny McPherson" <[email-masked]> wrote:

>>still does not do much to provide
>every possible reason or define detection mechanisms.

That’s exactly my point. We don’t need better understanding of the
symptom, which is what documenting an example (or many examples) provides.
What we need is a discussion around WHY it’s not possible or practical to
prevent unintentional route leaks with existing or proposed (BGPSec) tools
- i.e. can’t know intent and/or may not be able to represent intent in
existing policy language such that it can be derived from available info.

>think it works,
Well, yes, the words “policy” and “intent” did occur more than once, so I
guess that’s a discussion in the strictest sense of the word. However I
don’t think that it’s been adequately covered in the document even to the
point that it would spur a follow-on document. And though it might seem
otherwise, IETF shouldn’t be generating documents for the sake of having
documents. I don’t see any reason why the discussion of some of the
challenges around this problem should be punted to a separate
document/discussion. Put another way, I don’t think that this document has
enough meat to stand alone with just the example of the problem.

>This draft is only meant
I’m not suggesting that it needs to be the kitchen sink for attack
vectors. I’m suggesting that it needs to discuss this *one* more
thoroughly, such that folks can actually understand the underlying
challenge about why it hasn’t already been addressed and still exists as a
real problem in the wild. That will be significantly more helpful if folks
are to do research into solutions, or even see if data analysis can lead
to a way to derive things like intent and policy more effectively.

> We should document what some

Yes. That’s what I’m asking you to do. I’m not asking for you to design a
solution, but discussing existing solutions that don’t work, and why they
don’t work helps to more completely define the problem. I consider that a
key issue that the document currently does not discuss.

Thanks
Wes

---

From: Danny McPherson <[email-masked]>
Date: Wed, 14 May 2014 08:38:58 -0400

> symptom, which is what documenting an example (or many examples) provides.

Actually, I disagree.  I believe it’s precisely what we need, unless you’re aware of it documented and understood elsewhere?
 
> existing policy language such that it can be derived from available info.

You can prevent most of these attacks today with IRR-based filtering and the sort of things that some folks do (e.g., accept only customer registered prefixes, don’t allow customers to send me prefixes with AS paths of my peers, etc..), things that many of us did from a policy perspective 20 years ago, literally.

The SIDR WG considered this out of scope of their threats and subsequent requirements documents (which I believe both were subsequent to the solutions provided) because the solution they developed didn’t give ANY consideration to these frequent operational and security issues.  With their frequency and ease of occurrence we figured it was important for folks to be aware and consider the issues, ideally, operators smart folk outside of the SIDR circle, else they could be fooled into thinking these problems are solved by BGPSEC, when they are not. 

We could write a lot of text about why some operators believe where SIDR is and how they got there was not appropriate, and how tightly coupling resource certification to routing is a bad idea, particularly within the IETF and the current Internet governance climate, but I don’t think that’s going to do anyone any good here and we’d be forever getting this document published.  If others want to do that work so be it.  I know some new work is happening with IRRs informed by resource certification and driving *persistent* policy configurations in routers and IMO, that solves 99% of what I care about, whereas, BGPSEC solves very little of what I’m concerned about. YMMV.

> enough meat to stand alone with just the example of the problem.

Is this attack vector documented somewhere else?  So unless we can enumerate some broad array of stuff we shouldn’t document a trivial attack vector, all while the SIDR WG is solving [creating] other problems for us?

> to a way to derive things like intent and policy more effectively.

That document, coupled with the IRR document, do provide a lot of this context, hence their parallel progression.  If you have other ideas or other work items or text then I’m sure folks here would welcome them.

> key issue that the document currently does not discuss.

This document discusses precisely why BGPSEC doesn’t solve this problem in section 2.  What do you believe is missing there?  

FWIW, I’m reluctant to use this document to point out all the other warts with BGPSEC for an array of reasons (e.g., only covers prefix/path, not attributes, tightly coupled to external system new parties and dependencies and control points, not persistent state in routers and bootstrap issues, unlikely to ever have a single RPKI root TA, dependencies on RPKI with own attack vectors and other issues, requires topology exposure with per-router keying globally published, new control regime for routing system makes operator lose autonomy, signature/validation and timing dependencies with external systems and other ASNs) turns BGP into RIPv1 with periodic updates, …) but I don’t really care about BGPSEC that much anymore and the SIDR WG is on greased rails so I’d rather not spend any more cycles on it.  

-danny

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 14 May 2014 09:58:04 -0400

[picking on this message to base my comments]

On Tue, May 13, 2014 at 09:48:32AM -0400, George, Wes wrote:
> 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=

This to a large extent identifies the problem: BGP *as a protocol* has no
idea what these boundaries are.  Thus, "intent" is up to the perception of
the involved parties.

This thread has looped a few iterations with "this is a problem!" and SIDR
basically saying "there's nothing in BGP here to secure".  Both things are
still true.

I think documenting route-leaks and their potential negative (or malicious)
consequences is worth GROW doing.

I think this issue exists even without bgpsec being involved.  While it's
correct that bgpsec doesn't add anything here, until the underlying base
protocol has some idea of what we can do, picking on bgpsec doesn't help.
If anything, I'd probably take the route-leak document and say "here's the
problem" with a one or two sentence note that bgpsec doesn't do much. 

In it's current form, I don't think the document is ready to progress.  I'd
even suggest it needs to be rescoped.

The interesting work is resurrecting the thread on injecting routing policy
intent into some system we can secure. :-)

-- Jeff

---

From: Danny McPherson <[email-masked]>
Date: Wed, 14 May 2014 10:13:13 -0600

> idea what these boundaries are.  Thus, "intent" is up to the 

Ans therefore, the solve need not necessarily be IN BGP itself.

> basically saying "there's nothing in BGP here to secure".  Both 

Heh, perhaps.

> consequences is worth GROW doing.

Concur, especially since it's a global routing operations related issue 
that happens all the time, and persists whether BGPSEC is deployed fully 
or not.

> problem" with a one or two sentence note that bgpsec doesn't do much.

I don't agree, and I don't believe this problem needs to be solved IN 
BGP.  And I do believe it's extremely important to provide a stable 
reference to these attacks in order for folks to realize it doesn't 
solve this very basic problem.

> In it's current form, I don't think the document is ready to 
> progress.

What specifically would you change in the document, given that it's 
intent is to highlight how BGPSEC does not address the route leak issue, 
and that it's a real operational issue that at least the authors are 
concerned with?

> I'd even suggest it needs to be rescoped.

If folks are interested in doing work more broadly than this then 
they're certainly welcome to.  If they're not interested in doing the 
work then it's disingenuous to suggest it be rescoped as such, 
particularly at this stage.

> intent into some system we can secure. :-)

I suppose degrees of "interesting" is a matter of perspective, and the 
notion of strict linear thinking that suggests "injecting" it into the 
active routing system is the only way to solve the problem is perhaps 
why we keep dancing around this (and other adjacent topics such as 
anti-spoofing in the datapath).  Quite frankly, I prefer inter-domain 
static routing or SDN over what I see BGPSEC-enabled RPKI bringing to 
the table - and I seriously mean that --  and they might well beat 
BGPSEC off the launchpad :-)

-danny

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 14 May 2014 12:43:43 -0400

On Wed, May 14, 2014 at 10:13:13AM -0600, Danny McPherson wrote:
> I don't agree, and I don't believe this problem needs to be solved
> IN BGP.  And I do believe it's extremely important to provide a
> stable reference to these attacks in order for folks to realize it
> doesn't solve this very basic problem.

Fine, let me amend that:
Unless there is something that documents/formalizes the scoping of
advertisements for a given prefix, and that informatoin can be distributed
for use of validation of right to propagate, then there's nothing to be
secured.  Whether this is in BGP or bgpsec or something new isn't the
important bit.

FWIW, I did a rough proof of concept that such scoping could be modeled in
RPSL a number of years ago when I was doing a lot of IRR related stuff.  It
*can* be modeled, but not really in a tractable fashion.  The addition of
some recursive elements (my customer as-set includes the following as-sets
I've received from this upstream) in the language helped, but it was still
ugly.

What was a particularly ugly observation from that was that one person's
mechanism for preventing route leaking was another person's mechanism to
lock a customer into a relationship tighter than a set of mutual parties
were willing to be contractually bound by.  (The best part of policies are
the exceptions, as someone once said to me.)

> intent is to highlight how BGPSEC does not address the route leak
> issue, and that it's a real operational issue that at least the
> authors are concerned with?
> 
> they're certainly welcome to.  If they're not interested in doing
> the work then it's disingenuous to suggest it be rescoped as such,

It's worth noting that I've had a TODO in my IETF list to review this
document for over a year.  WGLC is what finally made me check that off. :-)
So yes, mea culpa, I'm just as bad as many other IETFers.

My point was that you want to illustrate route-leaks are bad, and that
bgpsec won't help.  By framing this strictly in the terms of a
man-in-the-middle attack, I think you're going contrary to what bgpsec
claims it is doing: validating that an announcement has traversed a set of
ASes.  bgpsec doesn't claim to stop this.  (I am further behind in my SIDR
reading than in grow, so if they do, I'll stand corrected.)

If you stop claiming that bgpsec is there to prevent this and reframe the
document as "bgpsec can't stop route leaks", I'm fine with that.

> I suppose degrees of "interesting" is a matter of perspective, and
> the notion of strict linear thinking that suggests "injecting" it
> into the active routing system is the only way to solve the problem

Note I didn't say the routing system. :-)

> is perhaps why we keep dancing around this (and other adjacent
> topics such as anti-spoofing in the datapath).  Quite frankly, I
> prefer inter-domain static routing or SDN over what I see
> BGPSEC-enabled RPKI bringing to the table - and I seriously mean
> that --  and they might well beat BGPSEC off the launchpad :-)

I think you'll find that particular bit of state and rate of state
scaling... fun.  Bar conversation.

-- Jeff

---

From: Danny McPherson <[email-masked]>
Date: Wed, 14 May 2014 12:08:51 -0600

> document as "bgpsec can't stop route leaks", I'm fine with that.

Indeed it's not about MITM to BGPSEC itself, it's about BGPSEC not 
solving this problem.

Perhaps "the MITM attack enabled by the route leak that even a 
fully-deployed BGPSEC is unable to prevent" is indeed the crux of the 
issue ;-) .. and I understand your point.  Let me circle back with see 
if we can find a way to accommodate this distinction.

-danny

---

From: "George, Wes" <[email-masked]>
Date: Wed, 14 May 2014 15:59:05 -0400

On 5/14/14, 8:38 AM, "Danny McPherson" <[email-masked]> wrote:

>You can prevent most of these attacks today with IRR-based filtering and
>the sort of things that some folks do (e.g., accept only customer
>registered prefixes, don’t allow customers to send me prefixes with AS
>paths of my peers, etc..), things that many of us did from a policy
>perspective 20 years ago, literally.
So at a minimum your draft should include references to the relevant
sections of http://tools.ietf.org/html/draft-ietf-opsec-bgp-security and
probably the routing-policy-considerations doc along with discussion of
what gaps still exist in those tools’ ability to prevent the attack
described in this document. I’m not suggesting that it has to be an
exhaustive list of all attacks of this type and whether these tools will
prevent each, but at least making it clear the scenarios where these tools
aren’t enough by themselves to prevent this *specific* attack is pretty
important to this discussion. In other words, either a solution exists but
is not widely deployed for reasons discussed in policy-considerations, or
a solution exists but it can’t address foo and bar (or both).

> With their frequency and ease of occurrence we figured it was important
>for folks to be aware and consider the issues, ideally, operators smart
>folk outside of the SIDR circle, else they could be fooled into thinking
>these problems are solved by BGPSEC, when they are not.
I don’t think that anyone has claimed that BGPSec solves this, so I’m not
concerned about people being fooled.

You assert that IRR-based filtering and good BGP neighbor hygiene mostly
resolve the problem, and that even entry level BGP operators are familiar
with this issue, yet it occurs all of the time.
So why is it useful to single out BGPSec on this particular attack vector
as being no help? Please don’t misconstrue this as me defending BGPSec. I
am skeptical it will ever see deployment for much the same reasons you
detail, but that makes it all the more strange to have it be the primary
focus of a discussion of route leaks and the associated attack vector
since it never claimed to solve that problem. In other words, route leaks
are a problem whether BGPSec lives or dies, so let’s focus on that, rather
than re-hashing the discussion about whether BGPSec SHOULD have protected
against this attack or not.

>
>We could write a lot of text about why some operators believe where SIDR
>is and how they got there was not appropriate, and how tightly coupling
>resource certification to routing is a bad idea, particularly within the
>IETF and the current Internet governance climate, but I don’t think
>that’s going to do anyone any good here and we’d be forever getting this
>document published.
Again, I’m not asking for that text. I’m not sure how much clearer I can
be about that. The less said about SIDR’s design choices and process in
this context and WG, the better.

>I know some new work is happening with IRRs informed by resource
>certification and driving *persistent* policy configurations in routers
>and IMO, that solves 99% of what I care about, whereas, BGPSEC solves
>very little of what I’m concerned about.
Yet none of that work is referenced in this document, and when I point out
that the document is a bit thin, you keep harping on BGPSec and SIDR.

>Is this attack vector documented somewhere else?  So unless we can
>enumerate some broad array of stuff we shouldn’t document a trivial
>attack vector,
No it’s not documented elsewhere, and I’m not saying you shouldn’t
document it, nor do I think I’m asking for a broad array of stuff. I’m
saying that you haven’t documented it completely enough for it to be at
all useful as input to future work as the document claims it is supposed
to be.

>That document, coupled with the IRR document, do provide a lot of this
>context, hence their parallel progression.

But in their current form(s) that logical link between the two doesn’t
exist, since the documents don’t even reference one another. You need to
connect the dots a bit better under the assumption that not all readers
are necessarily aware of their parallel progression.

>This document discusses precisely why BGPSEC doesn’t solve this problem
>in section 2.  What do you believe is missing there?

No, it discusses HOW this set of announcements appears valid in BGPSec.
The WHY is what I’ve been trying to get you to add, which is that BGP has
no way to convey intent or the explicit limits of route propagation on a
per-ASN basis, and therefore there is no attribute being manipulated such
that it could be secured by a system that secures a subset of BGP
attributes like BGPSec.

>FWIW, I’m reluctant to use this document to point out all the other warts
>with BGPSEC for an array of reasons

And while it would be entertaining reading, I would be opposed to you
doing so. Such a document belongs in SIDR, not GROW.

From my perspective, you have several points to make in this draft to
provide a stable reference documenting this problem:

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]
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

Thanks
Wes

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 14 May 2014 16:11:35 -0400

> [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??'

> has no semantics to convey intent or this type of inter-AS propagation

(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.

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 16 May 2014 23:59:06 -0400

> I think this was part of the impetus for the document, or that's what I recall.

Sort of a late reply to this, but…

The draft's simple example of this behavior serves as a way to frame its discussion of some of the problems that can result.  But it does not produce a definition.  If that was the wg's purpose for this document, then this doesn't suit.

The draft itself says that it is not intended to provide a definition:

   While the formal definition of a 'route-leak' has proven elusive in
   literature, the rampant occurrence and persistent operational threats
   have proven to be anything but uncommon.  This document is intended
   to serve as a proof of existence for the referenced attack vector and
   any supplementary formal models are left for future work.

As a motivating example, this draft works.  As a definition of what is and is not a route leak, it does not.

I suspect if an explicit definition is not worked out now, it will get worked out in the middle of trying to work out a solution, which will be very messy.  It is always hard to work toward a solution when you aren't working from a common understanding of what you are solving.

--Sandy

---

From: Danny McPherson <[email-masked]>
Date: Mon, 19 May 2014 21:02:52 -0400

[top post only]

Good point Sandy, this was definitely meant to serve as more of a motivation, illustrating a real problem that smart people should focus on because it happens all the time and some real heavy solutions being consider wholly ignore it.  Quibbling about “definitions” that satisfy those in the know (some of which are heavily invested in solutions that don’t consider this an issue) at this stage is likely futile, and I’d at least be happy just publishing this as a “motivational” and if it only collects dust, so be it..

-danny

---

From: Jared Mauch <[email-masked]>
Date: Mon, 19 May 2014 21:11:25 -0400

> Good point Sandy, this was definitely meant to serve as more of a motivation, illustrating a real problem that smart people should focus on because it happens all the time and some real heavy solut…

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).

- Jared

---

From: Danny McPherson <[email-masked]>
Date: Mon, 19 May 2014 21:12:27 -0400

Where else would it be documented?  If the IETF is designing protocols that operators will have to deploy, should this not be here?  I thought that was the point of an “operations” working group?

-danny

---

From: Jared Mauch <[email-masked]>
Date: Mon, 19 May 2014 21:14:50 -0400

> Where else would it be documented?  If the IETF is designing protocols that operators will have to deploy, should this not be here?  I thought that was the point of an “operations” working group?

Not all operational practices are documented at the IETF.  Perhaps that is also an oversight.  I was merely asking this question outloud.

- Jared

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 20 May 2014 10:42:13 +0100

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.

Nick

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 20 May 2014 17:42:10 -0400

> 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

---

From: Tony Tauber <[email-masked]>
Date: Wed, 21 May 2014 10:01:45 -0400

> possible (and MiTM) where the network operators were previously

I would agree that focusing on MiTM attacks is hyperbolic and that the more
frequent consequence has been blackholing or (extreme) packet loss due to
congestion.

Also it's worthy to note that the leaks with naive causes (vs. malicious)
have been more common by far.

(And would second that Shane's contact info needs updating, esp. since I
think the Auth48 check before publication will go quicker with it.)

Thanks,
Tony