Subject: [sidr] Route Leaks and BGP Security

From: Danny McPherson <[email-masked]>
Date: Wed, 16 Nov 2011 23:23:28 -0500

Team, 
I've updated this draft based on some feedback received already.  Given 
the discussion at the WG session, and the list discussion as of late, I'd like 
to ask that it become a WG item and used to inform the BGP Threat Model 
document -- particularly with regards to what's an acceptable residual risk and 
what is not.  Once that's comprehensive it can be used to inform secure routing 
requirements documents in the working group, and then we can begin assessing 
the feasibility of reducing various risks.

<http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01>

Thanks!

-danny

Begin forwarded message:

> From: [email-masked]
> Date: November 16, 2011 11:01:24 PM EST
> To: [email-masked]
> Subject: I-D Action: draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01.txt
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Route Leak Attacks Against BGPSEC
> 	Author(s)       : Danny McPherson
>                          Shane Amante
> 	Filename        : draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01.txt
> 	Pages           : 5
> 	Date            : 2011-11-16
> 
>   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 Secure Inter-Domain
>   Routing working group during routing security requirements
>   discussions and subsequent specification.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01.txt
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 21 Nov 2011 00:35:53 -0500

> the feasibility of reducing various risks.

"The authors believe the capability to prevent leaks should be a	
  first-order engineering objective in any secure routing architecture."

So, in the simple scenario laid out, the customer is filtered by the
isp's, no? and the filter data is built with something like:  take irr
data, meld with rpki data, create filter-lists.

The rpki data gives the isps an ability to filter the customer
announcements, which would stop the leaks. Is the thing you really
want to outline in a draft the process to link the
resource-certification data with the existing IRR data and create
better prefix/as-path filters?

I think one item that was asked for on the list (or perhaps in the
meeting) was: How can you know a route you see is a leak?

Taken another way, in the case of your example:

victim - isp2 - attacker - isp1

how is the victim to know that this path isn't proper?
what in the update says that?
is there other data that could be used (outside of bgp) to tell the
victim that the path is improper?

-chris

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 21 Nov 2011 00:40:27 -0500

To make the route leak problem tractable, we need a definition.
Here is my attempt:

If a destination AS, D originates a route and announces it
to provider P1, and P1 agrees to provide connectivity to
D, then D trusts P1 to do the right thing with the route.
If P1 has further contracted provider P2 to provide it
with connectivity, then it trusts P2 to do the right thing
with the routes it originates. By extension, D also trusts
P2. This chain may continue. It may also branch. The result
is a set of ASs that D trusts to do the right thing with
the routes it originates.

A source AS, S similarly has a set of ASs it trusts to
do the right thing with its routes.

When S sends a packet to D, that packet should traverse
only ASs that S trusts OR that D trusts. If the packet
traverses an AS that NEITHER S NOR D trusts, then a route
leak has occurred.

When a route announcement leaves the set of ASs trusted
by its originator, Brian's "transit" bit turns off.

--
Jakob Heitz.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Danny McPherson
> Sent: Wednesday, November 16, 2011 8:23 PM
> To: sidr wg list
> Subject: [sidr] Route Leaks and BGP Security
> 
> 
> Team,
> I've updated this draft based on some feedback received already.
> Given the discussion at the WG session, and the list discussion as
> of late, I'd like to ask that it become a WG item and used to inform
> the BGP Threat Model document -- particularly with regards to what's
> an acceptable residual risk and what is not.  Once that's
> comprehensive it can be used to inform secure routing requirements
> documents in the working group, and then we can begin assessing the
> feasibility of reducing various risks.
> 
> > Subject: I-D Action:
> > draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01.txt
> > http://www.ietf.org/internet-drafts/draft-foo-sidr-simple-leak-
> attack-
> > bgpsec-no-help-01.txt
> >
> > ftp://ftp.ietf.org/internet-drafts/draft-foo-sidr-simple-leak-
> attack-b
> > gpsec-no-help-01.txt
> >
> > Internet-Draft directories: http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 21 Nov 2011 01:06:10 -0500

> To make the route leak problem tractable, we need a definition.

danny's draft actually does a decent job of saying what a leak is (one
instance of a leak at least, which is fine), it just doesn't say how
you'd know that from 2 as-hops away... (today, with out bgp changes
and/or external knowledge about the ASes in the AS-Path)

<snip>

> traverses an AS that NEITHER S NOR D trusts, then a route

how is this 'trust' known? how does it translate down the chain? I
don't trust AS9001 anymore than 4134 than 4366 than 3 ... I do happen
to fling packets through them though :(

> by its originator, Brian's "transit" bit turns off.

I doubt the originator trusts anyone except itself... and MAYBE it's transits.

why mix two topics? :( (also, how does the route know it crossed this
boundary and a bit needs flipping?)

-chris

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 21 Nov 2011 01:17:32 -0500

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Christopher
> Morrow
> Sent: Sunday, November 20, 2011 10:06 PM
> To: Jakob Heitz
> Cc: Danny McPherson; sidr wg list
> Subject: Re: [sidr] Route Leaks and BGP Security
> 
> danny's draft actually does a decent job of saying what a leak is
> (one instance of a leak at least, which is fine), it just doesn't
> say how you'd know that from 2 as-hops away... (today, with out bgp
> changes and/or external knowledge about the ASes in the AS-Path)
> 
> <snip>
> 
> > When S sends a packet to D, that packet should traverse only ASs
> that
> > S trusts OR that D trusts. If the packet traverses an AS that
> NEITHER
> > S NOR D trusts, then a route leak has occurred.
> 
> don't trust AS9001 anymore than 4134 than 4366 than 3 ... I do
> happen to fling packets through them though :(

You contracted it to provide you connectivity.
If it doesn't, it breaks the contract.

> 
> > When a route announcement leaves the set of ASs trusted by its
> > originator, Brian's "transit" bit turns off.
> 
> why mix two topics? :( (also, how does the route know it crossed
> this boundary and a bit needs flipping?)

When the provider sends it to another customer or
another AS that is not contracted to provide connectivity
for that route.

> -chris

The trust I'm talking about is the trust to provide
connectivity, not the trust not to snoop your packets
or anything else.

---

From: Russ White <[email-masked]>
Date: Mon, 21 Nov 2011 07:32:34 -0500

> and/or external knowledge about the ASes in the AS-Path)

I came to the conclusion long ago that BGP doesn't carry the information
needed to "secure" the AS Path... Maybe this is why BGPsec can't provide
the information needed to make intelligent decisions in so many places
--because BGP itself doesn't provide that information, and BGPsec only
attempts to "secure the semantics of BGP" (and that only in a rather
incomplete way).

The solution isn't to rule out such problems because they're
"unsolvable." There are, in fact, at least two systems that can solve
this problem.

>> traverses an AS that NEITHER S NOR D trusts, then a route

I would generally avoid using packet flow models as a way to describe
BGP security issues... BGP, like all routing protocols, is a distributed
real time database combined with a set of rules about using the data
within the database.

By signing the updates, you're attempting to show that the each node
participating in the database has followed the rules correctly. The
problem is that many of the rules are implicit, rather than explicit,
and implicit rules don't lend themselves to being signed. Danny's route
leak problem, or needing "beacons," to take routes out of the system,
etc., are instances of implicit rules.

You have to start with a good model and good requirements, and then work
from there. The model the WG has chosen --"we're going to secure BGP
semantics," doesn't lead to a good result, simply because not all the
semantics are on the table to be secured.

:-)

Russ

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 21 Nov 2011 10:15:27 -0500

BGP security issues...

The ultimate goal is to protect the packet flow, so I went back to that to come up with a definition. How to translate that into BGP is just the next step.

---

From: Randy Bush <[email-masked]>
Date: Mon, 21 Nov 2011 18:09:49 +0200

> "unsolvable." There are, in fact, at least two systems that can solve

in the harsh realities such as

  o a significant portion of the internet's isps will not publish
    peering and customer business relationships,

  o ASs are not homogenous, A gives B local peering and international
    transit in frankfurt, but B may have no relationship with A in
    new york, or B may be A's customer in new york, and you will never
    know (and you do not want to see how this is done if you are
    anywhere near a meal)

  o etc.

could you point to where two such systems are documented?

otherwise, i have to conclude that

  o this is just a repeat of the non-sense which wasted years of time
    of the last ietf attempt in this area,

  o and we should do what we know how to do, which, though not a total
    panacea, will be a non-trivial improvement on the current situation,
    and

  o and we should leave the research to an irtf wg.

randy

---

From: Russ White <[email-masked]>
Date: Mon, 21 Nov 2011 11:57:42 -0500

>     peering and customer business relationships,

You can't secure what you don't tell anyone about. Security is about
allowing others to compare the current state against what the state
should be. What you're asking for is to ask someone else to take some
specific action for you without telling them what that action should be.
An impossibility.

>     know (and you do not want to see how this is done if you are

These can be accounted for in some of the systems that have been
proposed in the past, or are now available.

>     of the last ietf attempt in this area,

Which is a worse waste of time --designing a solution first, then
fitting the requirements around it, or figuring out what the problem is,
then thinking through possible solutions?

:-)

Russ

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 21 Nov 2011 20:53:24 +0100

>>      peering and customer business relationships,

Randy,

This is very true statement how every last week we have had a number of 
conversations where the same significant portions of ISPs expressed very 
great interest in increase their revenues in the context of CDNs.

So to get some money from the large content providers like Akamai or 
Google they are willing to expose their peering relations just to let 
those big guys may an intelligent content query redirection.

I do know this is a bit outside of the scope of this WG, but the 
requirement is common and with addressing one we could perhaps address 
the other one in one shot.

So if we would propose a solution which only asks to advertise given 
AS's neighboring ASes by peering to them of course without disclosing 
any policy one may have .. do you think this would not be a doable 
proposal ?

Regards,
R.

 > On 2011-11-21 17:57, Russ White wrote:
>

---

From: Shane Amante <[email-masked]>
Date: Mon, 21 Nov 2011 16:08:53 -0700

Hi Chris,

> better prefix/as-path filters?

As the -01 draft states:
---snip---
  Discussion of out of band methods to mitigate this attack are beyond
  the scope of this document, as it's objective is to inform routing
  protocol design choices currently being considered within the IETF's
  SIDR Working Group.
---snip---

> what in the update says that?

That's the point.  :-)  At present, nothing being "secured" in the UPDATE, (specifically AS_PATH wrt BGPSec), will tell you that the UPDATE was sent through a legitimate control-plane path vs. an illegitimate control-plane path.

In today's networks, the means to control the propagation of a particular BGP route are through configuration of 'policy' locally on routers, (ASBR's/PE's), that look for a combination of /one or more/ _BGP_attributes_ in the BGP route itself to limit its propagation.  As one specific example, an operator of an AS typically configures their ingress ASBR's to assign a specific standard BGP community that says something like:
- this is a customer route;
- this is a peer route
(I would note that these BGP standard communities are 'local' to and only have meaning within the operator of their particular AS.  An operator should NOT or would NOT "trust" third-parties, e.g.: their customers or peers, to set and send these communities to them for lots of obvious reasons).

When a BGP route travels to that operator's egress ASBR's, the egress ASBR then has a locally configured policy that looks for the locally significant BGP community string that says: "this is a customer route", in which case the route is sent out of both peer & customer eBGP sessions.  OTOH, if the eBGP policy at the egress ASBR determines, based on the locally significant BGP community string assigned to a BGP route, "this is a peer route", the action in that locally configured policy at peer eBGP sessions is to drop (not announce outbound) that particular UPDATE; whereas, the action at customer eBGP sessions is to announce that UPDATE outbound.

Locally significant BGP communities + locally configured policy are just one method that could be used, but likely the most widely used.  Depending on the size of one's network other BGP Attributes + locally configured policy may be used.

> victim that the path is improper?

IMHO, and as I think Russ has pointed out, BGP was only (?) designed to express reachability, not to carry or forward _policy_.  At present, nothing in the BGP protocol disseminates _policy_[1].  Instead, policy to control propagation of BGP routing information is only known to routers via out-of-band configuration (through CLI or NETCONF), either manually or through automated methods.

-shane

[1] The only minor exception I can think of to this is the well-known NO_EXPORT or NO_ADVERTISE BGP communities.  However, those have an extremely limited scope -- specifically, both communities are only exchanged between _directly_ connected adjacent ASN's.  I would add that since BGPSec does not make any attempt to sign the BGP community Attribute, it follows that even in this most limited case BGPSec is not able to certify (authenticate?) that a given BGP route *should* or *should not* be propagated to AS'es 2+ hops away.  What if one stripped the NO_EXPORT or NO_ADVERTISE community off and re-announced that BGP route -- is that not considered a MiTM attack, just as bad (or, worse?) as fraudulently inserting one's self into the AS_PATH?

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 21 Nov 2011 21:47:28 -0500

> Hi Chris,

howdy!

>  protocol design choices currently being considered within the IETF's

yea, that's cheating :)

> That's the point.  :-)  At present, nothing being "secured" in the UPDATE, (specifically AS_PATH wrt BGPSec), will tell you that the UPDATE was sent through a legitimate control-plane path vs. an i…

agreed.

> (I would note that these BGP standard communities are 'local' to and only have meaning within the operator of their particular AS.  An operator should NOT or would NOT "trust" third-parties, e.g.:…

ok, so if we step forward and ask for 'give me an attribute to
indicate customer/peer/other', would we then trust that? it'd be
(presumably) set per as-hop, is that anymore trustworthy than the
communities supposed above?

(I'd also ask what the rules are for setting this sort of thing, but I
don't think that matters since we can't really trust the value in it)

> IMHO, and as I think Russ has pointed out, BGP was only (?) designed to express reachability, not to carry or forward _policy_.  At present, nothing in the BGP protocol disseminates _policy_[1].  I…

yup, I don't think we're going to get to the fully publicly exposed
policy world though... are we? (we can't, I think, expect everyone to
expose that sort of thing, never mind keep it updated)

> -shane
>
> [1] The only minor exception I can think of to this is the well-known NO_EXPORT or NO_ADVERTISE BGP communities.  However, those have an extremely limited scope -- specifically, both communities are only exchanged between _directly_ connected adjacent ASN's.  I would add that since BGPSec does not make any attempt to sign the BGP community Attribute, it follows that even in this most limited case BGPSec is not able to certify

During the design team discussions of what parts of bgp to sign, the
decision was made not to cover communities and other attributes
since.. which community means what? which are important? which aren't?
can one AS set 701:666 and send that along to 701? what about 70:112?
(as rob austein said: "What are the security semantics of a
community?") Also, what about (as danny pointed out a few meetings
ago) the networks that strip all communities on ingress so routes with
all relevant attributes equal but different community sets don't cause
extra headache/etc.

> (authenticate?) that a given BGP route *should* or *should not* be propagated to AS'es 2+ hops away.  What if one stripped the NO_EXPORT or NO_ADVERTISE community off and re-announced that BGP route -- is that not considered a MiTM attack, just as bad (or, worse?) as fraudulently inserting one's self into the AS_PATH?

yup... no-export/advertise were taken as 'advisory' communities that
networks MAY heed, but certainly weren't bound to do so.

So, back to the question:
"Given BGP as it is today, how do you know if a route is a leak or not?"

I suppose documenting: "One leak scenario is <see id name>" is a fine
thing, does it help to actually fix the problem though? I think what I
heard in the meeting and on the thread(s) here was: "Sure leaks are
important, there's not a way devised so far that distinguishes a
'leak' route from a 'normal' route, more than 1 as-hop from the
'source' of the leak.

In the id/draft:

   isp1   isp2 - me
       \     /
        AS1

I can't tell at 'me' that the route I see is a 'leak', just that I see
an as-path that is isp1-as1-isp2.

-chris

---

From: Terry Manderson <[email-masked]>
Date: Tue, 22 Nov 2011 14:15:09 +1000

Speaking for myself on this one.

> don't think that matters since we can't really trust the value in it)

So lets say (hypothetically) we adopt a requirement of this system to allow a relying party to parse a route and know if it is intended or not by some construction of verifiable information.

I can't, for the life of me, see a transitive attribute _in_ BGP (signed or otherwise) making a positive step in trying to secure intent of the local AS as effected by a routing domain 2+ hops away.

> expose that sort of thing, never mind keep it updated)

History tells us we are (for the most part) inept at doing so, even with tools available.

But what we do know is that when policy is implemented, the results are transparent and can be seen
(ris, routeviews, et al) by anyone who cares to look.

> an as-path that is isp1-as1-isp2.

The bit I think that is missing is some knowledge that isp1 asserts it has valid routing through isp2, and any other potential 'true' paths. (noting AS1 is considered the 'Serleena' here)

From what I recall draft-huston-sidr-aao-profile takes a step in that direction. (insert my reluctance about tightly binding routing operations to allocation practice) in such that it only publicises the valid paths, through subsequent AAO's by by other ASNs. Thus if an AAO (in my reading) is created by isp1 with only an adjacency to isp2. It provides "me" with an ability to say that the received route with AS1 on path is invalid.

The AAO doesn't dive into local policy, and if isp1 has a private peering with AS3, then it need not put that in an AAO and thus the business dealings remain private - everything else ends up being seen in routeviews over time. So this is one way... but not the only way.

The killer problem here is that partial deployments will create path islands, where only a number of the ASN hops have created AAO objects and thus a path validity exercise will still fall into a potential leak trap until all ASNs get there. The question then could then be, "is it o.k. for the answer to route leaks to be near unusable until we have a significant deployment"

Cheers,
T.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 22 Nov 2011 00:13:52 -0500

> So lets say (hypothetically) we adopt a requirement of this system to allow a relying party to parse a route and know if it is intended or not by some construction of verifiable information.

'if it is intended' ... means:
  a) "is intended to be seen at the vantage point it was observed at"
(3 as-hops away)
  b) "with the as-path it shows up with" (isp1 - as1 - isp2 - me)
  c) something else?

it's not clear what you meant, I'll assume b though...

> I can't, for the life of me, see a transitive attribute _in_ BGP (signed or otherwise) making a positive step in trying to secure intent of the local AS as effected by a routing domain 2+ hops away.

err, this didn't parse for me :(
You mean you don't see the possibility of adding a transitive
attribute to BGP, which some AS adds to a path (and signs into the
announcement, so it has to be kept along the path) and is replicated
with each as-hop?

Something like:
  isp1      -      as1      -      isp2     -   me
   out:is-cust  in:is-transit out:is-transit in:is-cust  out:is-cust
in:is-transit

So, isp1 signs toward as1 "is-customer"
      as1 signs from isp1 "is-transit"

      as1 signs to isp2 "is-transit"
      isp2 signs from as1 "is-customer"

      isp2 signs to me "is-customer"
      me signs from isp2 "is-transit"

Given that you'd have to configure (I suspect) each peering as
'peering' or 'transit' or 'customer' ...I don't see this flying
either. :( I also don't see how to compute this on the local-router
level either, given the information in the session, without an
operator having to designate "this is a X" :(

> History tells us we are (for the most part) inept at doing so, even with tools available.

I had thought that RIPE had this licked in their region, no? they have
policy-foo encoded in RPSL-stuff in the DB no? Is that NOT working for
the cases in region?

> (ris, routeviews, et al) by anyone who cares to look.

sure... but the data isn't exactly always 'accurate' there, and it's
not accessible to the 'user' (router in the field) really, and I think
the data includes lots of helter-skelter cruft that's not very helpful
for this case :(

> The bit I think that is missing is some knowledge that isp1 asserts it has valid routing through isp2, and any other potential 'true' paths. (noting AS1 is considered the 'Serleena' here)

oh, I think danny's draft has a link between isp1/isp2 :(
you probably meant here: "ISP1 and ISP2 directly connect, the path via
AS1 is invalid/improper/a-leak" right?

> The killer problem here is that partial deployments will create path islands, where only a number of the ASN hops have created AAO objects and thus a path validity exercise will still fall into a p…

note sure, is that time also when we'd have full
resource-certification and the tools mostly available to just filter
people reliably/properly/everywhere? ('everywhere' for some value of
all-customers-of-all-isps, and maybe including
settlement-free-interconnects as well?)

-chris

---

From: Terry Manderson <[email-masked]>
Date: Tue, 22 Nov 2011 15:52:16 +1000

> it's not clear what you meant, I'll assume b though...

to be specific, "it was intended to be seen at the vantage point it was observed at, and in the form presented".

So something showing up 3 hops away might be fine provided the 3 hops are intended to be isp1 - as1 - isp2.

> announcement, so it has to be kept along the path) and is replicated

yes. (and sorry for being terse)

>      isp2 signs from as1 "is-customer"

the problem is that as1 can validly say "i don't do BGPSEC, but i'm still a valid on path actor" and you have to trust that at face value even though as1 is maleficent. You need isp1 to say that isp1 & as1 have a valid transit arrangement.

> operator having to designate "this is a X" :(

right.

> policy-foo encoded in RPSL-stuff in the DB no? Is that NOT working for

Probably they are the closest it gets, but a line from the ENISA paper sticks with me:

"Unfortunately, the quality of the IRRs varies, which makes it difficult to rely on them"

> the data includes lots of helter-skelter cruft that's not very helpful

I was simply using it to demonstrate that since transit routing relationships end up in the RIS and routeviews as observable artefacts (cruft included), advertising who you have a transit relationship in something like the AAO isn't making any huge declarations of "I peer with company X" that can't be found by other investigations.

Although in hindsight the AAO might not be fine grained enough. In some cases an autonomous system may want to optionally list a set of prefixes that are subject to a transit/peer relationship with an adjacent AS.. (and of course, in some cases not)

> AS1 is invalid/improper/a-leak" right?

That was my understanding.

> settlement-free-interconnects as well?)

That I don't know - crystal ball cracked when I tried to beat this year's NHL results out of it.

T.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 22 Nov 2011 01:09:17 -0500

> So something showing up 3 hops away might be fine provided the 3 hops are intended to be isp1 - as1 - isp2.

ok

> the problem is that as1 can validly say "i don't do BGPSEC, but i'm still a valid on path actor" and you have to trust that at face value even though as1 is maleficent. You need isp1 to say that is…

right, if the attribute isn't signed (or maybe it flat doesn't exist
without signage?) then ... we are where we are today.
Once you cross out of signage, you are lost (under the bgpsec rules as
written at least).

> "Unfortunately, the quality of the IRRs varies, which makes it difficult to rely on them"

yup... well is that for RPSL/Policy-foo? or just for registration in general?
For instance, ALT-DB blows as a source for as701 data... RADB has some
for AS701...
Neither has RPSL-Policy-Foo for AS701 :( ('accepts all routes from
<list-o-customer-asns> && sends-all-routes to
<everyone-except-SFP-peers>')

I got the impression that the culture in ripe-region essentially was
that: "Everyone autogens filters from RIPE-IRR, so ... get that right
or your internet is very small."

> I was simply using it to demonstrate that since transit routing relationships end up in the RIS and routeviews as observable artefacts (cruft included), advertising who you have a transit relations…

Could be, I do know that Randy's had some study time to show that even
though people say: "Transit free" they aren't always as free as they'd
like everyone to think. This wasn't (as I recall) observable from
routeviews/ris data though :(

Also, just using ris/routeviews as a starting point I was thinking:
"Could you watch history and build a list of common adjacencies, or
adjacencies you never expect to see?" I couldn't get to a reliable
enough answer though :( (I didn't do any math though... or in-depth
research, I fell back on 'well cyclops/et-al can't seem to be reliable
100% of the time, so...')

It's fair to say that SOME transit routing relationships show up in
RV/RIS, but not all do, and the vantage points are not 'all tier-1 and
down', they are often 'tier-77 networks view of the world!' (with
paths selected such that their Level3 transit is hidden for 'most' of
the intertubes, is that because they only bought 3356-customer routes?
or??

it's messy :(

> Although in hindsight the AAO might not be fine grained enough. In some cases an autonomous system may want to optionally list a set of prefixes that are subject to a transit/peer relationship with…

sure, the really weird relationships are ... weird. Also, very hard to
quantify :(
just dealing with the 'normal' cases seems to be weird though :(

> That was my understanding.

err, then a corrected ascii-art is:

  isp1 --- isp2 - me
      \     /
       as1

apologies for the mistake previously :(

-chris

---

From: Danny McPherson <[email-masked]>
Date: Tue, 22 Nov 2011 06:00:02 -0500

>> "Unfortunately, the quality of the IRRs varies, which makes it difficult to rely on them"

Terry: I think this is in large part attributed to lack of formally verifiable IRR objects (i.e,. 
objects bootstrapped by some resource certification mechanism).  There are many other
reasons as well, I'm working with a few folks to try and capture some of these..

> or your internet is very small."

I like that culture, it provides accountability and puts the onus on each operator 
to maintain their information.

-danny

---

From: Russ White <[email-masked]>
Date: Tue, 22 Nov 2011 07:35:41 -0500

>From what's been said on the list in the last several days, however,
isn't it true that even the signatures are "advisory?" There is an
insistence that local policy overrules the signatures --so all the
entire SIDR effort is doing is providing more information on which to act.

Why wouldn't signing communities be providing more information on which
to act, as well? How can we say that providing more information on which
to at is legitimate in the one case (that the receiver isn't bound by
the information provided, but it is good information to have), and yet
in the second case argue that because no-one is bound to act on the
information, we shouldn't provide it?

> an as-path that is isp1-as1-isp2.

There is a way to tell --you simply have to have ISP1 and ISP2 advertise
through some mechanism that AS1 is not a transit peer. You can either
add this information into BGP itself, through a community or some other
attribute --but note that BGP wasn't designed to do this, and you're
trusting AS1 to pass along the information that's it's not a transit
peer when trying to act as a transit peer (a bit pathological, IMHO), or
you must do so out of band.

There are out of band solutions available, but the insistence that
no-one ever advertise their intent has blocked all such out of band options.

Not everyone might object to advertising their intent --and building a
system that doesn't allow the advertisement of policy to appease the few
that do object appears to be backwards from the way business should be
done. Operators should be given the ability to trade off between
additional security and "privacy."

:-)

Russ

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 22 Nov 2011 16:12:57 -0500

> isn't it true that even the signatures are "advisory?" There is an

in the end state I think we'd like them to be mandatory. If they
aren't there then the operator of the network in question can decide
to accept/depref/deny the route in question.

> entire SIDR effort is doing is providing more information on which to act.

sure.

> to act, as well? How can we say that providing more information on which

If communities were guaranteed to exist along the entire path, maybe?
If people didn't add communities and drop them 'at will' maybe? If we
understood what a community meant, maybe?

I don't see any of the three things there being the case though :(
Communities are really only useful inside a single AS or to the direct
peers (where they signal ala RFC1998 action to be taken on the peer
network).

> you must do so out of band.

right, this was the focus of at least 2 messages I sent over the last
few days, it's also a focus of Brian Dickson's notes... 'add a bit to
bgp, flip it up/down if customer/peer'. I don't see a practical (and
trustworthy) method to do that though.

-chris

---

From: Brian Dickson <[email-masked]>
Date: Tue, 22 Nov 2011 18:18:12 -0500

> peers (where they signal ala RFC1998 action to be taken on the peer

I've been thinking about ways to handle additional attributes to the
set of things signed,
while also allowing some of those to be added/changed/deleted along the way.

I'll be working on a more formal message (or possibly draft), but
wanted to at least
get the idea in folks' heads, that it isn't impossible, and might even
be workable.

The simplest case is, the extra values get added to the signature
block of the originator,
and nobody modifies those values along the way. (Obviously there are
some attributes
where this is not possible because BGP requires them to change.)

[In this simple case, nothing new is really needed.]

The problem happens the first time you change something, and gets
worse with every change.

The idea I'm working on, is to create a "stack" of attributes that change.
This is very much like the stack in a language like 'C'.

The current values are kept in the normal place in BGP.

The immediately previous value(s) that were replaced (or deleted) are
pushed onto
the top of the stack, as well as some kind of indicator of what
attributes were added,
changed, and deleted, and which entry in the AS_path these correspond to.
(Maybe a NULL indicator as a placeholder if nothing changed...)

Signature validation required a reverse-diff be applied while working
backwards through
the signatures. The set of additional signed attributes gets
reconstituted, and combined
into some canonical form for validating the signature.

It's clunky, for sure, and for attributes that are high-volume and
subject to lots of change
along an AS-path, might bloat things a bit.

On the other hand, it provides data not previously available for path
selection, along with
crypto validation of that data.

Comments on this idea are welcome. It's a work in progress....

Brian