Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-threats-04.txt

From: [email-masked]
Date: Thu, 17 Jan 2013 13:23:35 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF.

	Title           : Threat Model for BGP Path Security
	Author(s)       : Stephen Kent
                          Andrew Chi
	Filename        : draft-ietf-sidr-bgpsec-threats-04.txt
	Pages           : 26
	Date            : 2013-01-17

Abstract:
   This document describes a threat model for the context in which BGP
   path security mechanisms will be developed.  It assumes the context
   established by the SIDR WG charter, as of April 19, 2011.  The
   charter established two goals for the SIDR work:

   o  Enabling an AS to verify the authorization of an origin AS to

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-threats

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-threats-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-threats-04

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Andrew Chi <[email-masked]>
Date: Thu, 17 Jan 2013 16:41:08 -0500

> http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-threats-04

This revision clarifies the wording on route leaks as a residual 
vulnerability, addressing a comment by Chris Morrow.

---

From: Eric Osterweil <[email-masked]>
Date: Tue, 22 Jan 2013 10:07:49 -0500

On Jan 17, 2013, at 4:41 PM, Andrew Chi wrote:

> This revision clarifies the wording on route leaks as a residual vulnerability, addressing a comment by Chris Morrow.

I have a few problems with this draft, and in particular, with the new text:
- The anecdote at the top of the modified paragraph on page 19 says, ``It has been stated that...'' without a citation, however, the paragraph then goes on to say that without an _RFC_ citation we cannot address route leaks.  I would submit that moving from anecdotal hearsay to omission without a normative reference is an awkward transition.
- While there is no definition of a route leak in an RFC, there is an entire GROW draft dedicated to it.
- I also don't understand how the text in this (a threats document) can claim that route leaks are beyond the scope of PATHSEC in a fait accompli manner...  This is a threats document, right?  This is a threat to BGP, right?  The RPKI provides semantics that ``BGP, itself does not include semantics...'' for... I don't think applying this exclusion to route leaks survives a sniff test.

Overall, I think the threats document is still missing a badly needed treatise on route leaks.  I would suggest a good starting point for informational reading might be the draft:
	http://tools.ietf.org/html/draft-grow-simple-leak-attack-bgpsec-no-help-00

Eric

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 22 Jan 2013 11:08:56 -0500

On Tue, Jan 22, 2013 at 10:07 AM, Eric Osterweil
<[email-masked]> wrote:
<snip>
> - I also don't understand how the text in this (a threats document) can claim that route
> leaks are beyond the scope of PATHSEC in a fait accompli manner...  This is a
> threats document, right?  This is a threat to BGP, right?  The RPKI provides
> semantics that

is the 'leak' a threat to 'BGP' or to the users of the network?

>``BGP, itself does not include semantics...'' for... I don't think applying this exclusion to
> route leaks survives a sniff test.

the RPKI is simply a database, it's not part of the BGP protocol. The
RPKI system doesn't include bgp peering data, so while you could
detect and potentially mitigate a 'hijack', it's not clear to me that
you'd know 'leak' vs 'new peering arrangement' just based on the RPKI
data.

> Overall, I think the threats document is still missing a badly needed treatise on route
> leaks.

is it fair to say that you would like the threats document to say, in
perhaps more words than this:
  "BGP Path Security has no capability to influence or inform the bgp
system of 'route leaks'."

this, I think, does run afoul of stephen's want for a definition of
'route leak' though... but I think it's what you're aiming at?

---

From: Eric Osterweil <[email-masked]>
Date: Tue, 22 Jan 2013 11:16:01 -0500

> is the 'leak' a threat to 'BGP' or to the users of the network?

I think this might be a case of picket fences?  I see your distinction, but I had thought the wg's broader goal was to protect those that rely on BGP?  I didn't think we were designing a protocol that could fall in a forrest with no one to hear it. :)

> you'd know 'leak' vs 'new peering arrangement' just based on the RPKI

Indeed.  My point was not to draw RPKI into the solution space, or claim something about its goals.  I was just trying to illustrate that the wg has already invested (heavily) in systems and designs that are not semantically part of BGP.  It just seemed silly (imho) to start claiming that if something isn't part of BGP's semantics, we should treat it as taboo...

> 'route leak' though... but I think it's what you're aiming at?

I am not sure.  I would suggest that identifying a threat should _not_ be held up by the search for a closed form expression of that threat.  Does that make more sense?

Eric

---

From: Randy Bush <[email-masked]>
Date: Wed, 23 Jan 2013 07:18:38 +0900

> I had thought the wg's broader goal was to protect those that rely on
> BGP?

good luck with that.  start an insurance business.

it is to protect the protocol from being gamed.

randy

---

From: Eric Osterweil <[email-masked]>
Date: Tue, 22 Jan 2013 18:17:54 -0500

> good luck with that.  start an insurance business.

Good one, Randy...

Eric

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 22 Jan 2013 21:16:15 -0500

>>> I had thought the wg's broader goal was to protect those that rely on

I think the goal has been to protect the routing system through better
protections of the protocol. I hope we can later get to a point where
this means the users of the system have tools to make their routing
system (and ours) better.

-chris

---

From: Russ White <[email-masked]>
Date: Wed, 23 Jan 2013 09:41:04 -0500

> Indeed.  My point was not to draw RPKI into the solution space, or claim something about its goals.  I was just trying to illustrate that the wg has already invested (heavily) in systems and design…

The problem is, of course, that a "route leak," is explicitly a part of
BGP's semantics --on the filtering side of things. Communities, for
instance, are very much a part of the semantics of BGP. They are used to
filter routes and control the places where routes are advertised;
therefore filtering is a part of BGP's semantics. Proving a route should
not be advertised is as much a part of this problem as proving a route
should be advertised --in fact, you can't really separate the two
problems, though we've been trying to for years.

"Securing the semantics of BGP," is just a convenient way to restrict
the scope to BGP-SEC (SBGP), while being flexible enough to leave out
the things BGP-SEC (SBGP) can't fix as well. We need to begin from the
beginning, starting with a real requirements document with real
requirements framed in a way actually designed to protect the operation
of BGP from the perspective of intent, rather than operation. I'll say
it again (to be ignored again): all security is about intent.

Russ

-- 
<><
[email-masked]
[email-masked]

---

From: Shane Amante <[email-masked]>
Date: Wed, 23 Jan 2013 08:49:21 -0700

On Jan 23, 2013, at 7:41 AM, Russ White <[email-masked]> wrote:
> of BGP from the perspective of intent, rather than operation.

> I'll say

I'm not ignoring it.  :-)  In fact, I'll +1 it.  

-shane

> 
> Russ
> 
> -- 
> <><
> [email-masked]
> [email-masked]
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>