Subject: [sidr] SIDR ReCharter - to capture/cover path validation work

From: Christopher Morrow <[email-masked]>
Date: Wed, 16 Feb 2011 12:53:45 -0500

Howdy, as mentioned a few weeks back we need to re-charter the WG in
order to move on from simply validating origination of routing
information to possibly validating path information as well, here's a
strawman charter re-work, how about we discuss some on the list and
have some more chat about it at the Prague meeting?

= = = = = = = = =

Description of Working Group:

The purpose of the SIDR working group is to reduce vulnerabilities in
the inter-domain routing system. The two vulnerabilities that will be
addressed are:

   * Is an Autonomous System (AS) authorized to originate an IP prefix
   * Is the AS-Path represented in the route the same as the path
        through which the route update traveled

The SIDR working group will take practical deployability into consideration.

Building upon the already completed and implemented framework:

   * Resource Public Key Infrastructure (RPKI)
   * Distribution of RPKI data to routing devices and its use in
        operational networks
   * Document the use of certification objects within the secure
        routing architecture

This working group will specify security enhancements for inter-domain
routing protocols.

The SIDR working group is charged with the following goals and
milestones:
ID Date      Pub Date
Mar 2011   Jan 2012  An overview of the RPKI and BGP Protocol changes
required for origin and path validation
Mar 2011   Jun 2012  A document describing threats to the routing system
Mar 2011   Jun 2012  A requirements document that  addresses these threats
Mar2011    Jan 2012  Document the BGP protocol enhancements that meet
the security requirements
Nov 2010    Jul 2011   draft-ietf-sidr-origin-ops
Mar 2011   Jul 2012   Operational deployment guidance for network operators
Jun 2011    Dec 2011 System and architecture design choices made in
the protocol and RPKI
Mar 2010    Mar 2012   draft-ietf-sidr-cps-irs
Mar 2010    Mar 2012   draft-ietf-sidr-cps-isp
Nov 2010    Jan 2012   draft-ietf-sidr-pfx-validate
Jan 2010    Jun 2011    draft-ietf-sidr-publication
Nov 2010    Jun 2011   draft-ietf-sidr-repos-struct
Nov 2010    Jun 2011   draft-ietf-sidr-roa-format
Feb 2011    Jun 2011    draft-ietf-sidr-rpki-rtr
Nov 2010    Nov 2011   draft-ietf-sidr-ltamgmt
Dec 2010    Oct 2011   draft-rgaglian-sidr-algorithm-agility
Jan 2011    Oct 2011   draft-ietf-sidr-ghostbusters
Jan 2010    Dec 2011   draft-ietf-sidr-keyroll
Jan 2010    May 2011  draft-ietf-sidr-arch
Jan 2010    May 2011  draft-ietf-sidr-cp
Jan 2010    May 2011  draft-ietf-sidr-res-certs
Jan 2010    Jun 2011  draft-ietf-sidr-roa-validation
Jan 2010    Jun 2011  draft-ietf-sidr-signed-object
Jan 2010    Jun 2011  draft-ietf-sidr-rpki-manifests
Jan 2010    Jul 2011  draft-ietf-sidr-rpki-algs
Jan 2010    Jul 2011  draft-ietf-sidr-rescerts-provisioning
Jan 2010    Aug 2011  draft-ietf-sidr-ta

==================

-Chris
<co-chair-mittens==off>

---

From: Russ White <[email-masked]>
Date: Fri, 18 Feb 2011 11:35:18 -0500

>         through which the route update traveled

As we've been discussing on the list --I don't think this is a good
goal. The first goal should be to determine what it is we want to show
about the AS Path in relation to other things, and then work on filling
that goal.

Starting with the assumption that proving an update travels a specific
path seems, to me, to be going about things the wrong way.

:-)

Russ

---

From: John Leslie <[email-masked]>
Date: Fri, 18 Feb 2011 12:11:54 -0500

Russ White <[email-masked]> wrote:
> To: Christopher Morrow <[email-masked]>
> 

   The question I think we ought to care about is:

Is the NLRI from this peer more or less likely than some other peer's NLRI
to represent what a legitimate originator would want me to see?

   All I really have control over is which peer I send to (and thus
which NLRI I forward to my peers). I have no control over what happens
to the packets after than first forwarding step.

--
John Leslie <[email-masked]>

---

From: Chris Morrow <[email-masked]>
Date: Fri, 18 Feb 2011 12:20:59 -0500

> to the packets after than first forwarding step.

we can't (and shouldn't conflate here) packet security with routing
(routing data, really) security.

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 18 Feb 2011 12:23:16 -0500

(my originaly wouldn't have made it to the list... so here it is again
from the right src-addr)

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 18 Feb 2011 12:30:57 -0500

> goal. The first goal should be to determine what it is we want to show

'this' refers to which of the two items above?

> about the AS Path in relation to other things, and then work on filling

I thought I covered this (a few times?) on the list discussion of the
reqs-00 draft, but I'd like to know if an update I see from a peer, if
selected, is one in which a party altered the as-path in order to draw
traffic to them. It's possible this happens for any number of reasons,
the simplest (and easiest to point to being 'bad') is:
  <http://www.wired.com/threatlevel/2008/08/how-to-intercep/>

In this case, with signing of the path at each path-hop you would be
able to determine if the route announcement should be used or not
(presuming a 'secure is better' policy, of course).

> path seems, to me, to be going about things the wrong way.

propose text then? dancing around the rosemary bush is tiring, given
the ideas expressed here and in the other thread you should have an
idea of what the goal is, propose some text that you think moves the
ball in the right direction, please.

-chris

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 18 Feb 2011 12:54:52 -0500 (Eastern Standard Time)

> path seems, to me, to be going about things the wrong way.

In my view of things, this is exactly the right way to do things. 
Anything else is baling wire holding some pieces together, not a solution.

OK so here goes with the philosophy.

Distributed protocols work because the sender and recipient are working 
with a common semantics of what the bits on the wire mean.

The sender is supposed to set certain bits to represent some particular 
semantics.

The recipient presumes that semantics when certain bits are set and makes 
decisions based on that semantics.

In BGP, the semantics of the protocol are that the AS_PATH represents the 
AS's through with the update has traveled.

This is the only reason why loop detection works.

This is the reason that people make decisions based on AS_PATH length. 
(Yes, I know this is not the highest priority decision in the procedure, 
but it is something everyone uses and one of the few ways to attempt to 
have impact on the decision of an AS not a direct neighbor.)

Munging around with the AS_PATH in ways not in the protocol makes things 
break.

We could try to list every single one of those, and find a separate way 
of dealing with each new way to break things, but we would miss some, 
someone would think of something new, whatever.

The point is to try to retain the semantics of the fields in the protocol.

Suppose someone munged around with the AS_PATH so that loops were not 
detected.  That would be a bad thing.  You could invent a way to prevent 
that and just that.

Suppose someone munged around with the AS_PATH so that it looked like 
there was a loop when there was not.  That could be a bad thing (cue 
Kapela and Pilosov)  You could invent a second way to prevent just that.

Suppose someone made a path look shorter than it was.  That could be a bad 
thing.  You could invent a third way to prevent just that.

Suppose someone inserted some unrelated AS into the AS_PATH to cause a 
link elsewhere to break.  That would be a bad thing. (reference Steve 
Bellovin discussion of link-cutting attacks, cue NANOG's rant against one 
certain person's experiment)  You could invent a fourth way to prevent 
just that.

Suppose....

But maybe you get the idea.

The fundamental problem (security geeks call this a "vulnerability") is 
that the AS_PATH is supposed to be constructed in a certain way, the 
recipients make decisions based on that assumption, and if it is possible 
to mess with that assumption, you've got problems.

End philosophy.

--Sandy

---

From: Jason Schiller <[email-masked]>
Date: Fri, 18 Feb 2011 13:00:56 -0500 (EST)

+1

|I thought I covered this (a few times?) on the list discussion of the
|reqs-00 draft, but I'd like to know if an update I see from a peer, if
|selected, is one in which a party altered the as-path in order to draw
|traffic to them. It's possible this happens for any number of reasons,
|the simplest (and easiest to point to being 'bad') is:
|  <http://www.wired.com/threatlevel/2008/08/how-to-intercep/>
|
|In this case, with signing of the path at each path-hop you would be
|able to determine if the route announcement should be used or not
|(presuming a 'secure is better' policy, of course).

In my opinion, origin validation only catches a small number of "bad" 
routing information.  Additionally this "bad" routing information is 
typically the type created by fat fingering, and I would argue is the 
easiest to detect and get fixed.

Anyone who is manipulating routing for nefarious purposes can avoid being 
caught by origin validation.  These cases are more frequent, harder to  
detect, and more difficult to get resolved.  

If there is any value in securing inter-domain routing it has to validate 
the AS path.

__Jason

==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       [email-masked]
UUNET / Verizon                         [email-masked]

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

On Fri, 18 Feb 2011, Christopher Morrow wrote:

|Date: Fri, 18 Feb 2011 12:30:57 -0500
|From: Christopher Morrow <[email-masked]>
|To: Russ White <[email-masked]>
|Cc: [email-masked], Adrian Farrel <[email-masked]>,
|    [email-masked]
|Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work
|
|On Fri, Feb 18, 2011 at 11:35 AM, Russ White <[email-masked]> wrote:
|>
|>>    * Is an Autonomous System (AS) authorized to originate an IP prefix
|>>    * Is the AS-Path represented in the route the same as the path
|>>         through which the route update traveled
|>
|> As we've been discussing on the list --I don't think this is a good
|> goal. The first goal should be to determine what it is we want to show
|
|'this' refers to which of the two items above?
|
|> about the AS Path in relation to other things, and then work on filling
|> that goal.
|
|I thought I covered this (a few times?) on the list discussion of the
|reqs-00 draft, but I'd like to know if an update I see from a peer, if
|selected, is one in which a party altered the as-path in order to draw
|traffic to them. It's possible this happens for any number of reasons,
|the simplest (and easiest to point to being 'bad') is:
|  <http://www.wired.com/threatlevel/2008/08/how-to-intercep/>
|
|In this case, with signing of the path at each path-hop you would be
|able to determine if the route announcement should be used or not
|(presuming a 'secure is better' policy, of course).
|
|> Starting with the assumption that proving an update travels a specific
|> path seems, to me, to be going about things the wrong way.
|
|propose text then? dancing around the rosemary bush is tiring, given
|the ideas expressed here and in the other thread you should have an
|idea of what the goal is, propose some text that you think moves the
|ball in the right direction, please.
|
|-chris
|_______________________________________________
|sidr mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/sidr
|

---

From: Russ White <[email-masked]>
Date: Fri, 18 Feb 2011 13:06:55 -0500

The problem lies right here:

> In BGP, the semantics of the protocol are that the AS_PATH represents
> the AS's through with the update has traveled.

No, it doesn't, really. Not in all cases.

> The point is to try to retain the semantics of the fields in the protocol.

The point should be to find out what it is you're trying to secure, and
then find a way to secure it. This _assumes_ the thing to secure is the
current semantics of the protocol.

But you're not addressing all the underlying assumptions that go with
those semantics.

> But maybe you get the idea.

Suppose someone invented a way to prevent all of that without trying to
verify what path an update followed?

Let me ask you something --does IPsec try to verify the path the packet
takes, or the contents of the packet? If the right solution for IPsec is
to validate the content of the packet, then why is the right solution
for BGP to verify the path of the packet?

:-)

Russ

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 18 Feb 2011 13:17:46 -0500 (Eastern Standard Time)

> No, it doesn't, really. Not in all cases.

In the *protocol* this is true.  Certainly people mess with configurations 
and implementations to get their own twisty features in, but in the 
protocol, that's what is supposed to happen.  It is what the recipients 
rely on.

> verify what path an update followed?

As I said, one could try to list all the ways of making bad things happen 
by exploiting the vulnerability (munging the semantics), but it would be 
hopeless.

> for BGP to verify the path of the packet?

The semantics of IP is that the source address is the host that sent the 
packet and the contents of the packet are as sent.

Not much more.

So that's what IPsec protects.  That semantics.

(Try to list all the bad things you can do by messing with IP packets and 
address each one.)

The BGP protocol has a different semantics and so it has a different 
protection.

--Sandy

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 18 Feb 2011 13:19:12 -0500

> for BGP to verify the path of the packet?

because with ipsec the content inside the encrypted payload (or even
the content after the AH header) is not intended to be played with by
anyone along the path. Detection of bit flippage in the packet is the
point of ipsec.

BGP requires that folk along the path adjust metrics, communities,
localpref (inside their ASNs) etc. It's not appropriate to 'secure the
whole of the update' since that can not be done.

-chris

---

From: Russ White <[email-masked]>
Date: Fri, 18 Feb 2011 13:28:17 -0500

> As I said, one could try to list all the ways of making bad things
> happen by exploiting the vulnerability (munging the semantics), but it
> would be hopeless.

Suppose you listed all the problems, and we found one way to resolve all
of them without the underlying assumption that the only way to solve the
problem is to prove the path the update took.

> packet and the contents of the packet are as sent.

Huh? Then why is there anything such as ESP? Shouldn't we only care
about the packet header, and just leave the rest of the packet unencrypted?

No, IPsec encrypts, and protects, _much_ more than the "protocol semantics."

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Fri, 18 Feb 2011 13:31:52 -0500

> whole of the update' since that can not be done.

But you're missing the point. Sandy said, "all we're trying to do is
secure the existing protocol semantics." As Sandy herself said, the only
"semantics" in IP are things that are contained within the header. So
why not just secure the header.

So the "securing the semantics" argument won't fly. Tell me what you
want to secure, not how you intend to secure it. If the charter says,
"we want to prove an update followed the AS Path listed in the update,"
then I will ask why we shouldn't prove the rest of the semantics, as
well --who added what communities, who removed communities, and were
they authorized to do so; who changed the next hop, and is the next hop
really the correct and authorized one; etc. --these are all part of the
"semantics" of BGP, as well.

If you're going to say, "secure the semantics," then secure all of them.
If you're going to say, "secure the data," then figure out what matters
in terms of how the data looks, and secure that.

:-)

Russ

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 18 Feb 2011 13:34:59 -0500

> in terms of how the data looks, and secure that.

what matters: AS-PATH
how it looks: every AS which sees this route, and propogates it to
external peers, attests to that fact.

---

From: Russ White <[email-masked]>
Date: Fri, 18 Feb 2011 14:21:40 -0500

> external peers, attests to that fact.

Wrong. As someone who has been long involved in the writing of BGP
specs, and someone who has worked, for a long time, on BGP, I can tell
you that the "semantic of BGP" has never been that the AS Path is used
for anything other than determining if the path is loop free. Anyone who
tells you that the "BGP semantic" is that the update has traversed the
path shown in the AS Path attribute simply doesn't understand BGP.

A few examples showing this simply isn't the case.

1. Private AS Stripping. At certain edges, a provider may peer with an
organization that does not have an AS number. In these cases, the
peering organization may use a private AS Number, which is then stripped
by the upstream. In all such cases, the AS Path does not --by
intention-- represent the "path of the update."

2. Local AS No Prepend. In some situations, it's useful (and good) to
send an update that has another AS in the path than the AS number you're
peering on. This occurs, for instance, in L3VPNs, and when providers are
merging two different AS numbers. If this were a real "threat" to BGP
and it's operation, then this feature wouldn't have been built by any
vendors --but it was created, at the request of service providers (some
of whom are now arguing that the AS Path is somehow untouchable).

3. Confederations. In the case where an organization decides to break
their network up into multiple administrative domains, or to combine
multiple administrative domains, several autonomous systems --with
public, routable AS numbers-- may be configured into a confederation. In
this case, the AS Path continues to have the AS numbers through which
the update passes added to the attribute. The "additional" AS numbers
are stripped off at the opposite edge of the confederation. Once again,
the AS Path is not anything special here, it's just another attribute,
and it certainly does not represent the path the update takes through
the network.

4. Wide AS'. According to RFC4893, the way in which BGP will migrate
from narrow AS numbers to wide AS numbers is: For any speaker that peers
with a speaker in an AS that doesn't support wide numbers, place the AS
path in a community, and place a "holder" AS number in the AS Path. When
receiving an update with a community containing portions of the AS Path,
move these portions back into the AS Path proper. Again, the AS Path is
not seen as something that "cannot be touched or changed," but rather a
simple attribute designed to show one specific thing --loop freeness.
There is no concept here of the AS Path showing the route the update
itself, took.

5. AS Sets. If a speaker aggregates a group of NLRIs into a single
advertisement, the speaker can/should build an AS Set to indicate the
group of AS' from which the NLRIs represented in the aggregate were
collected. Again, the AS Path doesn't have anything to do with "the path
the update took through the network."

I could go on giving examples, but to state, "BGP's semantic is that the
AS Path represents the path through which the update has traveled," is
simply untrue.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Fri, 18 Feb 2011 14:23:10 -0500

> I think the short name of the 2nd bullet is simply "authenticity of the AS path
> attribute".  Having authentic AS path information seems to provide everybody
> with a sound base to do whatever they want to do as their policies - and 
> certainly also general use rules.

1. That's not what the second bullet actually says.

2. Define what you mean when you say, "an authentic AS Path."

:-)

Russ

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 18 Feb 2011 14:49:06 -0500

> for anything other than determining if the path is loop free. Anyone who

i wasn't claiming anything about bgp semantics, that was sandy. I
didn't disagree with her, but it wasn't central to my message. You
clipped out the part of the message I replied to, which was only
related to your response:

" If you're going to say, "secure the semantics," then secure all of them.
  If you're going to say, "secure the data," then figure out what matters
  in terms of how the data looks, and secure that."

> intention-- represent the "path of the update."

for origin validation (not this conversation, but...) the ISP here
would have a ROA issued by the address-owner... so this isn't a
problem. The as-path is still a clear indicator here, since the
customer is a leaf... the fact that their ASN doesnt show up isn't a
problem, especially since the roa/origin-validation would nicely tell
us that the ASN we do so as the first (right-most) element is "ok".

> of whom are now arguing that the AS Path is somehow untouchable).

again, not a problem, presumably the AS stamped in the path is signed
by the ASN Owner, whether they say: "X" but are really "Y" isn't a
concern, they still have (in a possible endtime) cert issued down a
tree we can validate. They are still attesting to the fact that they
saw and passed along the route announcement in question. (see the
second half of the sentence you are responding to here)

(for all intents and purposes this looks like your next point, confeds)

> public, routable AS numbers-- may be configured into a confederation. In

(it's not required that the asn's in a confed be "public routable",
routable doesn't mean anything either here, ASNs... this is a
redherring though)

> and it certainly does not represent the path the update takes through

sure, and again, on exit the autonomous system (with the distinct
routing policy and administrative domain) stamps it saying: "Yup, was
here." they attest to this (again in my endtime of choice) in a manner
I can validate. (see the second half of the sentence you are
responding to here)

> There is no concept here of the AS Path showing the route the update

yup, this issue we have talked about some, I don't recall the details,
someone should think about this more... but again: "I saw this route,
I am passing it along" is really what matters. (see the second half of
the sentence you are responding to here)

> the update took through the network."

and because AS-Sets are opaque when it comes to security semantics
(which asn in the set is responsible for what part of the aggregate?)
they are excluded from the discussion, and on the road to deprecation.

> AS Path represents the path through which the update has traveled," is

eh... but it is. one more time around the mulberry bush?

-chris

---

From: Russ White <[email-masked]>
Date: Fri, 18 Feb 2011 15:14:30 -0500

> they are excluded from the discussion, and on the road to deprecation.

The point wasn't to say, "can each of these be solved," it was to say,
"the AS Path wasn't designed to bear the weight you're putting on it."

> eh... but it is. one more time around the mulberry bush?

It's not. The AS Path is to prove the path is loop free. It was never
intended to prove where the update went in the network.

:-)

Russ

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 18 Feb 2011 15:19:29 -0500

> intended to prove where the update went in the network.

ok, so what other tool do we have today that does this? (can tell us
that an path is not fictitious)

---

From: Russ White <[email-masked]>
Date: Fri, 18 Feb 2011 15:23:01 -0500

> that an path is not fictitious)

There never was a tool intended to solve that problem --from a routing
perspective, it doesn't matter where I get the information from, only
that the path is actually loop free. BGP cares about policy as well, but
only the policy between me and my peer, never a peer several hops away.

Let me ask this --do you care if you get the certificate showing AS x is
able to originate prefix y from a server in AS x, or off a web site
someplace? Or are you more concerned about the certificates/etc being
right --that the information is true?

:-)

Russ

---

From: John Leslie <[email-masked]>
Date: Fri, 18 Feb 2011 15:28:50 -0500

Russ White <[email-masked]> wrote:
> [Christopher Morrow <[email-masked]> wrote:]
>> [Russ White wrote:]
> 

   Please try to excuse me for interrupting a perfectly good flame-war...

   IMHO, Russ is being careful in what he says, but Chris isn't.

   The plain fact is, Chris made a perfectly reasonable post:
" 
" On Fri, Feb 18, 2011 at 1:31 PM, Russ White <[email-masked]> wrote:
"
"> If you're going to say, "secure the semantics," then secure all of them.
"> If you're going to say, "secure the data," then figure out what matters
"> in terms of how the data looks, and secure that.
" 
" what matters: AS-PATH
" how it looks: every AS which sees this route, and propogates it to
" external peers, attests to that fact.

   ... alas, not being as careful as I would wish about what he wrote...

   I interpreted to be in response to the last two lines of Russ, and say:
" 
" What matters is the AS_PATH; it gives us every AS which sees this NLRI;
" propagating it to external peers attests to this fact already.

   He did not say anything about how to validate that so as to place
confidence in the AS_PATH for loop detection, least of all some of the
other things we're looking for.

   Thus, I decided against responding to it right away, hoping somebody
would lead the discussion in that direction...

---

From: "Ruediger Volk, Deutsche Telekom T-Com - TE141-P1" <[email-masked]>
Date: Fri, 18 Feb 2011 19:48:36 +0100

Russ wrote
  > path seems, to me, to be going about things the wrong way.
oh! the second bullet seems like a perfect starting point!
(and questioning the first would seem to consider rolling back the ROA work8-O)

I think the short name of the 2nd bullet is simply "authenticity of the AS path
attribute".  Having authentic AS path information seems to provide everybody
with a sound base to do whatever they want to do as their policies - and 
certainly also general use rules.
I have trouble to believe that less than "authentic AS path info" will
serve us well enough, and doing less would mean that we dilute and messup
the security mechanism by some implied policies.
You are welcome to suggest relations and context that help defining useful
policies to evaluate with authentic AS path info (whether as general rules
or for private policy definitions).

Starting to look into "context" assuming and targeting that less than authentic
AS path should be sufficient would seem to me like heading for rat holes...

  > Russ

Ruediger

---

From: Stephen Kent <[email-masked]>
Date: Sun, 20 Feb 2011 11:22:57 -0500

At 11:35 AM -0500 2/18/11, Russ White wrote:
>Content-Type: multipart/signed; micalg=pgp-sha1;
>  protocol="application/pgp-signature";
>  boundary="------------enigEEE752FC731D9F82CF768B1F"
>
>

Some folks have observed that ASes may make decisions about accepting updates
based on AS path info. That, by itself, motivates securing the AS 
path info in an update, irrespective of any other motivations.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Sun, 20 Feb 2011 12:23:13 -0500

At 1:06 PM -0500 2/18/11, Russ White wrote:
>...

Russ,

IPsec provides end-to-end secruity services (confidentiality, integrity,
data origin authentication, and optional anti-replay) between peers. 
It need not worry about the path taken by the traffic that is 
protected by IPsec. The security semantics for IPsec-protected 
traffic are purely end-to-end. IPsec attempts to provide security 
consistent with an agreed-upon notion of what IP traffic should 
expect in a benign environment (e.g., no passive or active 
wiretapping), plus a recognition of real world limitations (e.g., 
variable delays happen, packets are dropped or reordered, etc.).

IPsec is not an appropriate analogy for the BGP security context.  In 
BGP the recipient of an update is allowed to transform it in certain 
ways, and to pass it on to other routers (at its discretion). It is 
not an end-to-end security model of the sort that IPsec embodies.

It seems that we have a major disagreement over what constitutes the 
semantics of routing security relative to a benign environment.  You 
stated that

"... the "semantic of BGP" has never been that the AS Path is used
for anything other than determining if the path is loop free."

That assertion seems to ignore the fact that routing decisions often 
take into account path length. Are you saying that such decisions are 
not part of the semantics of BGP, as interpreted by most ASes?

Steve

---

From: Russ White <[email-masked]>
Date: Sun, 20 Feb 2011 14:12:37 -0500

> not part of the semantics of BGP, as interpreted by most ASes?

The primary purpose of the AS list in the AS Path is to determine the
loop-freeness of the path, much like a metric in an IGP is used for the
same reason. The AS Path length was added to the decision process,
AFAIK, in order to inject the idea of the "least cost," or shortest
path, once you've arrived at a set of loop free paths.

Now, if you look at the actual attributes placed in BGP in order to
express policy, there are only three available (that I know of):

1. Local preference, which is only within an AS.

2. MED, which is one AS to a directly connected peer, and has always
been accepted as something which can be (and most often is) overriden.

3. Communities, which are either transitive or nontransitive. The only
ones I know of that actually express routing policy are nontransitive
--they only impact the AS I'm peering with.

In other words, the idea that in this network:

A--B--C

A should somehow be able to base any sort of policy on C's policy just
wasn't ever there. And yet --this appears to be precisely what we are
trying to inject into the protocol. Trying to set a policy that you will
not prefer a route from B because it passes through C is basing the
policy on potentially partial information.

I know there's been a strong attempt to disconnect policy towards
routing updates from forwarding policy. To this end --let me ask an open
question to the list. Can anyone on list point me to a policy carried in
BGP, or actually implemented by a BGP speaker, that's not designed to
impact forwarding?

:-)

Russ

---

From: "Ruediger Volk, Deutsche Telekom T-Com - TE141-P1" <[email-masked]>
Date: Mon, 21 Feb 2011 01:45:09 +0100

> The primary purpose of the AS list in the AS Path is to determine the
        ^^^^^^^^^^^^^^^  that's already pretty a different statement from
"never been .. used for anything other than determining if the path is
loop free."

  > --they only impact the AS I'm peering with.
This is an (incomplete:-) list of attributes that have immediately defined
semantics for BGP route selection and propagation.  This provides the
primitives that a operator has to use when implementing policies.
The more sophisticated operators define and implement policies (usually)
using vendor specific policy languages (e.g. route-map, RPL, ...)
or more abstract ones (like IETF standards track RPSL);
often the operator's policy implementation provides a new signalling
repertoire for their customers (to allow them additional control of
usage and propagation of the customer routes etc.); usually the signalling
uses community attributes (usually transitive!).
The implementation of policies means evaluating attributes of routes to decide
how to manipulate the attributes used for further processing and propagation
(in particular by setting the input/triggers for above mentioned primitives).

Simple early examples can be found in RFC1998.

Please note all known serious BGP implementations as well as RPSL
support AS path regular expressions in their repertoire of criteria for
evaluating routes;  there probably is a reason - I also hear that in some
parts of the Internet AS path filters are used as the primary security
measure (no, I don't!).
Also note that even the examples in RFC1998 use AS path expressions
that do NOT depend on just the immediate neighbor's AS...

  > wasn't ever there.
Does not seem like a relevant question.
Policies are essentially internal to an AS (=black box); they relate
to external input and may create specific output - and of course specifics
can be communicated to other AS operators;  so there is no principal
problem for C signalling something to A, and A using that (assuming that
B's policy did not block or distort the signal).

  > And yet --this appears to be precisely what we are
??????
Can the AS path attribute fullfill it's "primary function" of loop
prevention if we CAN NOT rely on it including all AS that have propagated
the route?  (with "abstraction" caveat for not publicly visible confederation members!)
I don't see HOW (other than by miracle or additional attributes that are more
reliable in this respect!)
So "C" must be available in the annoucement that B propagates to A (unless
B and C are members of confederation - and confederation members are
only visible inside the confederation) and there is nothing "partial"
in the "knowledge" that A's policy would use...

  > BGP, or actually implemented by a BGP speaker, that's not designed to
Considering the wide range of applications that have occured in proposals
to use BGP for distributing information in networks I would not be surprised
at all if there are cases that are only very indirectly related to forwarding!

:-)  :-)

  > Russ

Ruediger Volk

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Feb 2011 07:51:51 -0500

>path, once you've arrived at a set of loop free paths.

Whatever the primary purpose may have been initially, the fact is 
that path length is an important input to path selection as 
implemented. That justifies
an effort to ensure that the path seen by a recipient is authentic.

Steve

---

From: Russ White <[email-masked]>
Date: Mon, 21 Feb 2011 08:12:53 -0500

> Whatever the primary purpose may have been initially, the fact is that
> path length is an important input to path selection as implemented. That
> justifies

So the only security problem anyone faces, currently, is people cheating
on the AS Path length?

:-)

Russ

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 21 Feb 2011 09:13:00 -0500 (Eastern Standard Time)

No, messing with an AS_PATH is the fundamental problem.

Cheating on AS_PATH length is just one way to exploit that fundamental 
vulnerability.

See other messages for other examples of ways to exploit.

--Sandy

---

From: Russ White <[email-masked]>
Date: Mon, 21 Feb 2011 09:57:39 -0500

> See other messages for other examples of ways to exploit.

Countering these should be the requirements and the statement in the
charter, not "signing the update."

:-)

Russ

---

From: Jason Schiller <[email-masked]>
Date: Mon, 21 Feb 2011 11:02:37 -0500 (EST)

|So the only security problem anyone faces, currently, is people cheating
|on the AS Path length?

I thougth my previous post (as well as other) have been pretty clear on 
this topic.  The Kapella style attacks are sucessful because an 
organization can add ASes that they are not autorized to use to the 
AS-path.

__Jason

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 21 Feb 2011 11:30:07 -0500

> organization can add ASes that they are not autorized to use to the

and aside from 'you are originating a route you should not be
originating' this seems to be the other large class of attack, no?

Russ, what other classes of attack were you thinking of? (or seen in
the wild, or seen tested in labs, etc)

-chris

---

From: Shane Amante <[email-masked]>
Date: Mon, 21 Feb 2011 11:39:57 -0700

Jason, All,

> organization can add ASes that they are not autorized to use to the 

But, who is certifying what are legitimate vs. illegitimate AS_PATH's when the AS_PATH is greater than 2?

IOW, let's take a simple case of a stub AS, (AS_A), who is purchasing transit from two upstream providers: AS_B and AS_C.  In that case, the originating AS, AS_A, certainly has 'authority' on who (or, what set of AS'es) should be providing it with transit.  And, I can see the origin AS, AS_A, having something analogous to an IRR 'aut-num' object to tell the world what AS'es it is exporting/importing routes/AS'es to/from.  Operationally, this is already done today (for those that use IRR aut-num objects, at least).  I get it.  If this is where we draw a line in the sand that we want SIDR work to go, but no farther (at least for now), then OK.  (However, I'm still not sure if REQ #4.1 in draft-ymbk-bgpsec-reqs-00 is intended to address an origin ASN -> transit provider's AS_PATH relationship reqm't or is restating what the concept of ROA's do today.  Can someone clarify?)

However, the impression I'm getting is that folks want SIDR to go a step beyond that.  For example, AS_B and AS_C announce AS_A on to their upstreams/peers -- and, this is where I don't get it.  Let's use just the case of transit provider AS_B.  Let's say he announces AS_A onto AS_X, AS_Y and AS_Z, so you have an AS_PATH that looks like the following:
AS_X AS_B AS_A
AS_Y AS_B AS_A
AS_Z AS_B AS_A

At this point:
a) There is no *direct* contractual linkage from AS_A to AS_X, Y or Z ... and, just as importantly, /further beyond AS_X, Y and Z/.
b) Just as importantly, there is no IANA or RIR -- currently! -- that certifies the contractual linkage between AS_B and AS_X, Y and Z.

From a contractual PoV, AS_A has very little to do with _who_, beyond his directly connected transit providers/peers (AS_B and AS_C in this example), his routes are announced to.  Instead, AS_B is contractually obligated to announce, or not announce, AS_A's routes based on whether AS_B's connected AS'es are peers or transit providers.[1]  (Yes, there are exceptions like AS_A tagging routes with "NO_EXPORT", but operationally those are most likely an exception, IMO, intended to withhold more-specifics ... not 'general' reachability/connectedness).

I believe this, potentially, ties back to REQ's #3.14 and #4.2 in draft-ymbk-bgpsec-reqs-00, which (depending on your PoV) either conflict with each other or REQ #3.14 makes the 'assurances' people desire in REQ #4.2 not any better than we have in BGP today at AS_PATH lengths greater than 2.  Specifically, let's assume that AS_Z is contractually a 'peer' of AS_B and that AS_Z has suddenly gone "rogue".  AS_Z is now starting to announce AS_B, (and AS_A), on to AS_Z's __peers__ (AS_J, not depicted)[2].  AS_Z can sign AS_B's (and, AS_A's) routes all day long and they'll look "legitimate" from the PoV that a "recipient of an UPDATE [will know] that that UPDATE has traversed that AS_PATH in the update".  But, and here's the key point: a recipient of routes from AS_Z shouldn't *really* accept them, correct, because that AS_Z is breaching their contract with AS_B?  Or, to look at it in a completely different light, what 'value' does a signature provide in this case compared to today's non-signature based AS_PATH?

In summary, an AS_PATH is more than just a series of "breadcrumbs" on where an UPDATE has been.  In reality, there's a lot of very, very complicated 'policy' (really, dollars) on where it's _allowed_ to go, as well, that ultimately matters if you're going to provide assurances that it's "legitimate" or not.  I highly, highly recommend the reqmt's draft is much, much more clear on what assurances folks are attempting to make at, for example, various AS_PATH lengths, otherwise the signatures are likely to be, at best, meaningless.

-shane

[1] REQ 3.14 of draft-ymbk-bgpsec-reqs-00 states that a "BGPsec design MUST NOT require operators to reveal proprietary data ... [that] includes peering, customer and provider relationships".  This seems to ignore the reality that a recipient would need to know this if you're going to understand that, for example, a peer should only be sending you their transit customer's routes ... not their other peer's routes ...
[2] For the more security-oriented folks in the room, at a very high-level, peer's only announce their transit customer's routes to each other.  As a peer, you do not announce your other peer's routes on to other peer's ...

---

From: Jason Schiller <[email-masked]>
Date: Mon, 21 Feb 2011 14:01:46 -0500 (EST)

On Mon, 21 Feb 2011, Shane Amante wrote:

|
|But, who is certifying what are legitimate vs. illegitimate AS_PATH's 
|when the AS_PATH is greater than 2?
|
|IOW, let's take a simple case of a stub AS, (AS_A), who is purchasing 
|transit from two upstream providers: AS_B and AS_C.  In that case, the 
|originating AS, AS_A, certainly has 'authority' on who (or, what set of 
|AS'es) should be providing it with transit.  And, I can see the origin 
|AS, AS_A, having something analogous to an IRR 'aut-num' object to tell 
|the world what AS'es it is exporting/importing routes/AS'es to/from.  
|Operationally, this is already done today (for those that use IRR aut-num 
|objects, at least).  I get it.  If this is where we draw a line in the 
|sand that we want SIDR work to go, but no farther (at least for now), 
|then OK.  (However, I'm still not sure if REQ #4.1 in 
|draft-ymbk-bgpsec-reqs-00 is intended to address an origin ASN -> transit 
|provider's AS_PATH relationship reqm't or is restating what the concept 
|of ROA's do today.  Can someone clarify?)
|
|
|However, the impression I'm getting is that folks want SIDR to go a step 
|beyond that.  For example, AS_B and AS_C announce AS_A on to their 
|upstreams/peers -- and, this is where I don't get it.  Let's use just the 
|case of transit provider AS_B.  Let's say he announces AS_A onto AS_X, 
|AS_Y and AS_Z, so you have an AS_PATH that looks like the following:
|AS_X AS_B AS_A
|AS_Y AS_B AS_A
|AS_Z AS_B AS_A
|
|At this point:
|a) There is no *direct* contractual linkage from AS_A to AS_X, Y or Z 
|... and, just as importantly, /further beyond AS_X, Y and Z/.
|b) Just as importantly, there is no IANA or RIR -- currently! -- that 
|certifies the contractual linkage between AS_B and AS_X, Y and Z.
|
|From a contractual PoV, AS_A has very little to do with _who_, beyond 
|his directly connected transit providers/peers (AS_B and AS_C in this 
|example), his routes are announced to.  Instead, AS_B is contractually 
|obligated to announce, or not announce, AS_A's routes based on whether 
|AS_B's connected AS'es are peers or transit providers.[1]  (Yes, there 
|are exceptions like AS_A tagging routes with "NO_EXPORT", but 
|operationally those are most likely an exception, IMO, intended to 
withhold more-specifics ... not 'general' reachability/connectedness).
|

In your example where AS_A buys transit from AS_B and AS_B buy transit /
Peers with AS_X, AS)Y, and AS_Z...

When AS_B announces AS_A's prefix to its upstreams, it is asserting two 
things:

1. AS_B learned the prefix from AS_A, choose it as best, and does not have 
policy to limit the distribution of the route.

2. That network represented as AS_B has the right to use the ASN value 
AS_B.

-- The RIRs validate this

Likewise when AS_Z propagates the prefix it makes the same claim, that it 
has learned the route  from AS_B and that it as a network has the right to 
us AS_Z.

__Jason

---

From: "Smith, Donald" <[email-masked]>
Date: Mon, 21 Feb 2011 12:17:33 -0700

I think your last statement missed the concept of paid peering.
That is TIER 1 ISPs frequently announce TIER2 routes but consider the TIER2 "customer" as a "peer".
Or am I missing something?

> [2] For the more security-oriented folks in the room, at a very high-
> level, peer's only announce their transit customer's routes to each
> other.  As a peer, you do not announce your other peer's routes on to
> other peer's ...

Sharing: Author's permission required.
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Shane Amante
> Sent: Monday, February 21, 2011 11:40 AM
> To: Jason Schiller
> Cc: [email-masked]; Russ White
> Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation
> work
>
> Jason, All,
>
> IOW, let's take a simple case of a stub AS, (AS_A), who is purchasing
> transit from two upstream providers: AS_B and AS_C.  In that case, the
> originating AS, AS_A, certainly has 'authority' on who (or, what set of
> AS'es) should be providing it with transit.  And, I can see the origin
> AS, AS_A, having something analogous to an IRR 'aut-num' object to tell
> the world what AS'es it is exporting/importing routes/AS'es to/from.
> Operationally, this is already done today (for those that use IRR aut-
> num objects, at least).  I get it.  If this is where we draw a line in
> the sand that we want SIDR work to go, but no farther (at least for
> now), then OK.  (However, I'm still not sure if REQ #4.1 in draft-ymbk-
> bgpsec-reqs-00 is intended to address an origin ASN -> transit
> provider's AS_PATH relationship reqm't or is restating what the concept
> of ROA's do today.  Can someone clarify?)
>
>
> However, the impression I'm getting is that folks want SIDR to go a
> step beyond that.  For example, AS_B and AS_C announce AS_A on to their
> upstreams/peers -- and, this is where I don't get it.  Let's use just
> the case of transit provider AS_B.  Let's say he announces AS_A onto
> AS_X, AS_Y and AS_Z, so you have an AS_PATH that looks like the
> following:
> AS_X AS_B AS_A
> AS_Y AS_B AS_A
> AS_Z AS_B AS_A
>
> At this point:
> a) There is no *direct* contractual linkage from AS_A to AS_X, Y or Z
> ... and, just as importantly, /further beyond AS_X, Y and Z/.
> b) Just as importantly, there is no IANA or RIR -- currently! -- that
> certifies the contractual linkage between AS_B and AS_X, Y and Z.
>
> From a contractual PoV, AS_A has very little to do with _who_, beyond
> his directly connected transit providers/peers (AS_B and AS_C in this
> example), his routes are announced to.  Instead, AS_B is contractually
> obligated to announce, or not announce, AS_A's routes based on whether
> AS_B's connected AS'es are peers or transit providers.[1]  (Yes, there
> are exceptions like AS_A tagging routes with "NO_EXPORT", but
> operationally those are most likely an exception, IMO, intended to
> I believe this, potentially, ties back to REQ's #3.14 and #4.2 in
> draft-ymbk-bgpsec-reqs-00, which (depending on your PoV) either
> conflict with each other or REQ #3.14 makes the 'assurances' people
> desire in REQ #4.2 not any better than we have in BGP today at AS_PATH
> lengths greater than 2.  Specifically, let's assume that AS_Z is
> contractually a 'peer' of AS_B and that AS_Z has suddenly gone "rogue".
> AS_Z is now starting to announce AS_B, (and AS_A), on to AS_Z's
> __peers__ (AS_J, not depicted)[2].  AS_Z can sign AS_B's (and, AS_A's)
> routes all day long and they'll look "legitimate" from the PoV that a
> "recipient of an UPDATE [will know] that that UPDATE has traversed that
> AS_PATH in the update".  But, and here's the key point: a recipient of
> routes from AS_Z shouldn't *really* accept them, correct, because that
> AS_Z is breaching their contract with AS_B?  Or, to look at it in a
> completely different light, what 'value' does a signature provide in
> this case compared to today
>  's non-signature based AS_PATH?
>
> In summary, an AS_PATH is more than just a series of "breadcrumbs" on
> where an UPDATE has been.  In reality, there's a lot of very, very
> complicated 'policy' (really, dollars) on where it's _allowed_ to go,
> as well, that ultimately matters if you're going to provide assurances
> that it's "legitimate" or not.  I highly, highly recommend the reqmt's
> draft is much, much more clear on what assurances folks are attempting
> to make at, for example, various AS_PATH lengths, otherwise the
> signatures are likely to be, at best, meaningless.
>
> -shane
>
> [1] REQ 3.14 of draft-ymbk-bgpsec-reqs-00 states that a "BGPsec design
> MUST NOT require operators to reveal proprietary data ... [that]
> includes peering, customer and provider relationships".  This seems to
> ignore the reality that a recipient would need to know this if you're
> going to understand that, for example, a peer should only be sending
> you their transit customer's routes ... not their other peer's routes
> ...
> [2] For the more security-oriented folks in the room, at a very high-
> level, peer's only announce their transit customer's routes to each
> other.  As a peer, you do not announce your other peer's routes on to
> other peer's ...
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

---

From: Shane Amante <[email-masked]>
Date: Mon, 21 Feb 2011 12:24:21 -0700

Jason,

> policy to limit the distribution of the route.

Ah ha, you said: "policy".  What policy?  NO_EXPORT community?  Contractual policy?  Other?

-shane

---

From: Shane Amante <[email-masked]>
Date: Mon, 21 Feb 2011 12:35:07 -0700

Don,

> Or am I missing something?

I purposefully glanced over paid peering, in an attempt to keep things relatively simple (for now), in a meager attempt to figure out what are the requirements with respect to assertions on the "data" contained in an AS_PATH.  The concept of paid-peering, etc. may have to be revisited depending on where present conversations lead us.

-shane

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 21 Feb 2011 15:13:05 -0500 (Eastern Standard Time)

> intended to prove where the update went in the network.

The AS_PATH has always been intended to represent the ASs that propagated 
the update.

The AS_PATH can be used to detect loops ONLY because it does represent the 
ASs that propagated the update.

--Sandy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Feb 2011 15:23:53 -0500

I think we do need to be a little careful about what the AS path 
"always" meant, and what we are going to end up with it meaning if we 
follow the path and discussion.
For example, there is long practice of adding not just ones own AS, but 
sometimes other AS numbers to a path for policy reasons.  In that usage, 
it does not represent "the AS that propagated the update."
It may well be that it is acceptable to eliminate that usage.
An AS Set does not mean that the advertisement went through all of those 
AS.  (Admittedly, we are probably just going to ban sets.)
Folks tell all sorts of lies if they implement various kinds of 
multi-pathing.

It is reasonable to say that we are going to give up some of the 
flexibility the tool has had in order to get better verifiability of 
certain specific properties.

But we should understand that we are indeed changing the semantics when 
we do so.

Yours,
Joel

On 2/21/2011 3:13 PM, Sandra Murphy wrote:
...
>
> The AS_PATH has always been intended to represent the ASs that
> propagated the update.
>
> The AS_PATH can be used to detect loops ONLY because it does represent
> the ASs that propagated the update.
>
>
> --Sandy
>
>
>
>>
>> :-)
>>
>> Russ
>>
>>
>>

---

From: Russ White <[email-masked]>
Date: Mon, 21 Feb 2011 16:18:28 -0500

> the ASs that propagated the update.

Sorry --but I just gave 5 examples of where the AS Path is intentionally
modified without causing loops. The point is the loopfreeness, not the
path the update took.

Let me ask this in a different way. Suppose you have the following:

A---B
+-C-+

Now, for whatever reason, and with C's full knowledge and consent, B
decides to advertise C's routes to A without putting itself in the AS
Path. Is this possible? Yes, it is --using current commercial
implementations of BGP. Is it wrong?

Well, it doesn't cause a loop, does it? As for policy --isn't that up to
the contract between B and C? Why should BGP enforce the contract terms
B and C are able to write between themselves? And yes, this situation
does exist in the real world --I just happen to be helping a customer
set this up in a private environment.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Mon, 21 Feb 2011 16:26:56 -0500

> policy to limit the distribution of the route.

Who's policy? I think this is where the problem really lies, isn't it?
Are you trying to prove that AS_B has not restricted AS_A from sending
these routes along to its peers? If so, why should AS_A's peers pay any
attention to what AS_B's policy is? IE, the only person who should
enforce AS_B's policy with AS_A is AS_B itself --or am I missing something?

Further, is the _only_ policy anyone really cares about whether or not
AS_B "authorizes" AS_A to send routes on to its peers? Are there no
other policies in play here? In other words, we're going to build an
entire security system around one policy that's not really contained
within the protocol today?

This is why I really, really, want the requirements clarified.

> 2. That network represented as AS_B has the right to use the ASN value 

This has nothing to do with signing updates, to be honest --in fact,
this is something that I've been bothered about for a long long time. Do
the RIR's really want to get into the "you're really who you say you
are," business? If someone can fool the RIR into thinking they're Banco
Rio, and get a corresponding AS claiming such through a validated
certification, and I put my account information into a web site based on
this information, and I lose my identity, can I sue the RIR for not
doing a good job of being certain who people really are?

If not, then what have I gained here? This is the larger problem we've
kind-of just left under the covers, but it's bound to come popping out
at some point or another. I would prefer it not come out in a court
case, honestly. :-)

At any rate, this second piece is well outside the scope of path
validation, I think.

:-)

Russ

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 21 Feb 2011 16:28:25 -0500

Not to be pedantic, but the BGP spec *does* say that the AS_PATH documents the path of an UPDATE, and that each AS must add itself:
"
This attribute identifies the autonomous systems through which routing information carried in this UPDATE message has passed. 
...
   When a BGP speaker propagates a route it learned from another BGP
   speaker's UPDATE message, it modifies the route's AS_PATH attribute
   based on the location of the BGP speaker to which the route will be
   sent:
...
         1) if the first path segment of the AS_PATH is of type
            AS_SEQUENCE, the local system prepends its own AS number as
            the last element of the sequence (put it in the leftmost
            position with respect to the position of octets in the
            protocol message).  
"
<http://tools.ietf.org/html/rfc4271#section-5.1.2>

As I read this, in your example, B would not be conformant with the BGP spec if it forwarded UPDATEs from C without appending it's own AS.  It would probably be OK to *re-originate* the routes, but that creates a separate set of problems.

--Richard

---

From: Russ White <[email-masked]>
Date: Mon, 21 Feb 2011 16:36:47 -0500

> Not to be pedantic, but the BGP spec *does* say that the AS_PATH documents the path of an UPDATE, and that each AS must add itself:

No, it says that's the normal mode of operation... There's no MUST in

>             position with respect to the position of octets in the

Further, how do we then explain all the examples of the IDR WG, itself,
changing the AS Path (such as narrow to wide)?

> As I read this, in your example, B would not be conformant with the BGP spec if it forwarded UPDATEs from C without appending it's own AS.  It would probably be OK to *re-originate* the routes, but…

So, one point of order might be --approach IDR with this specific
question. Is the AS Path in BGP intended to exactly represent --with no
changes allowed-- the path through which an update has passed? Or is the
primary purpose to prevent loops? Getting the answer to that question
might be helpful.

As a contributor to BGP, I would say it's only related to loopfreeness,
not to the path the update takes --it's not a route explorer, it's a
routing update.

:-)

Russ

---

From: Randy Bush <[email-masked]>
Date: Tue, 22 Feb 2011 08:30:01 +0800

> this topic.

they were.  you are dealing with a one man dos.  do not feed the troll.

randy

---

From: Jason Schiller <[email-masked]>
Date: Mon, 21 Feb 2011 21:20:53 -0500 (EST)

ack.

understood.

Was concerned that other observers on SIDR might be buying his crap.

__Jason

On Tue, 22 Feb 2011, Randy Bush wrote:

|Date: Tue, 22 Feb 2011 08:30:01 +0800
|From: Randy Bush <[email-masked]>
|To: Jason Schiller <[email-masked]>
|Cc: Russ White <[email-masked]>, [email-masked]
|Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work
|
|> |So the only security problem anyone faces, currently, is people cheating
|> |on the AS Path length?
|> 
|> I thougth my previous post (as well as other) have been pretty clear on 
|> this topic.
|
|they were.  you are dealing with a one man dos.  do not feed the troll.
|
|randy
|

---

From: Russ White <[email-masked]>
Date: Mon, 21 Feb 2011 22:03:21 -0500

> they were.  you are dealing with a one man dos.  do not feed the troll.

One thing I've learned through the years is the first person to start
calling names has lost the argument.

Russ

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 21 Feb 2011 22:20:14 -0500

Actually, I suspect that there is a useful, but badly articulated, 
question underlying Russ' emails.
Yours,
Joel

On 2/21/2011 9:20 PM, Jason Schiller wrote:
> |From: Randy Bush<[email-masked]>
> |To: Jason Schiller<[email-masked]>
> |Cc: Russ White<[email-masked]>, [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Tue, 22 Feb 2011 11:31:01 +0800

> question underlying Russ' emails.

might be.  hard to tell.  having lived through the slanging match of
rpsec, i am not willing to spend a whole lot more time on one slanger
than the other.

randy

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 22 Feb 2011 11:40:32 -0500 (Eastern Standard Time)

Randy, please do not indulge in ad-hominem attacks.  It does nothing to 
help in finding the right answer.

--Sandy

---

From: Andrew Lange <[email-masked]>
Date: Tue, 22 Feb 2011 18:50:41 -0800

To divert the discussion a bit back into the realm of requirements.

What is the current "diameter" of the Internet?  From my recollections it was converging toward about 4 ASes in diameter.  This would mean that for most paths we have:

AS_A <--> AS_B <--> AS_C <--> AS_D

If we have already authenticated the route origin, with either offline or online enforcement depending on your preference, we have cryptographically bound a route object to an aut num.  Okay, this is good.  This is the current scope of the work. Now it's tougher for people to fake announcements, intentionally or otherwise.  This solves a lot of the problem.

Now, next step, we're looking at cryptographically signing the AS PATH, but as Russ points out that isn't really what we want, at least I don't think it is.  What we seem to be trying to get at is what is to vet the relationship between the ASes in the list.  For example, is AS_B really an upstream of AS_A? And it is therefore plausible that they would legitimately want to announce AS_A's routes. 

Of course, as Shane points out, there is absolutely no way in BGP (nor should their be, IMHO), of expressing the actual relationship between AS_A and AS_B.  They could be peers, confeds, paid peers, customers, etc. 

The requirement seems to be the ability to cryptographically sign an object expressing the relationship between AS_A and AS_B.  Is AS_B allowed, by AS_A, to announce AS_A's routes?

BGP seems impractical as a mechanism, however, we could use RPSL to do this.  We simply offer the origin AS, in this case AS_A, an option to express it's commercial relationship with its upstreams (or vice versa).  It can say "AS_B" can announce these routes, AS_Q can announce these, etc.  Yes, this does require that we announce "confidential" information, but, being realistic, anyone can figure most of this out by looking at a routing table.

Given the small diameter, then we've solved 90% of the problem, as we only have to then trust the big carriers in the core. If AS_B and AS_C are Level 3 and Verizon, we can be reasonably assured that they will get things right more often than not.   They've been doing this a while, and tend to know what they are doing.  There is strong commercial pressure not to blow it, and become subject to an attack or a highly visible misconfiguration. 

Andrew

---

From: Randy Bush <[email-masked]>
Date: Wed, 23 Feb 2011 11:08:20 +0800

> What is the current "diameter" of the Internet?  From my recollections
> it was converging toward about 4 ASes in diameter.

that was the mean, not the diameter.  not counting prepends and other
kink, the effective diameter is considerably larger.

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 23 Feb 2011 11:11:08 +0800

> If we have already authenticated the route origin, with either offline
> or online enforcement depending on your preference, we have
> cryptographically bound a route object to an aut num.

btw, the sidr work to date has not formally bound the route origin.  it
is informal, and easily spoofed.  the sidr work to date only deals with
the simple fat finger problem.

randy

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 23 Feb 2011 05:52:33 -0500 (Eastern Standard Time)

> Now, next step, we're looking at cryptographically signing the AS PATH, but as Russ points out that isn't really what we want, at least I don't think it is.  What we seem to be trying to get at is…

"Plausible" is a rather weak security property.  Is that your 
recommendation of what you want out of a secure solution from this working 
group?

--Sandy

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 23 Feb 2011 17:31:09 +0200

On Feb 16, 2011, at 7:53 PM, Christopher Morrow wrote:
[...]
>        through which the route update traveled
[...]

I think this is a fine charter expansion.  We could discuss other variants until the cows come home (oh wait, done that) but at some point we have to stop debating metaphysics, pick a goal and execute.  This one seems reasonable.

--John

---

From: Shane Amante <[email-masked]>
Date: Wed, 23 Feb 2011 12:57:27 -0700

Randy,

> the simple fat finger problem.

Can you clarify what you mean by "the sidr work to date has not formally bound the route origin ... and [is] easily spoofed"?

I thought the entire goal of the RPKI and, more importantly, the objects that it holds attest to the 'authorization' to originate a route?  In particular, I refer to the following in Section 3.1 of http://tools.ietf.org/html/draft-ietf-sidr-arch-12:
---snip---
   A ROA is an attestation that the holder of a set of prefixes has
   authorized an autonomous system to originate routes for those
   prefixes.  A ROA is structured according to the format described in
   [ROA-FORM].  The validity of this authorization depends on the signer
   of the ROA being the holder of the prefix(es) in the ROA; this fact
   is asserted by an end-entity certificate from the PKI, whose
   corresponding private key is used to sign the ROA.
---snip---

Perhaps there's a subtle _security_ nuance that I'm missing in your statement?

Thanks,

-shane

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 23 Feb 2011 15:26:04 -0500 (Eastern Standard Time)

> Can you clarify what you mean by "the sidr work to date has not formally bound the route origin ... and [is] easily spoofed"?

This is something that has been mentioned in the wg many times, so I'll 
answer.

It is quite easy for an AS to construct an AS_PATH with the legitimate 
authorized origin on the origin end, without every having received such an 
announcement from the origin.  Without the legitimate origin ever having 
actually made the announcement to anyone, even.

That's why path validation is important.  You really would like some 
assurance that the origin actually announced the prefix *and* announced it 
to the party that appears tp have propagated it onward.

> I thought the entire goal of the RPKI and, more importantly, the objects that it holds attest to the 'authorization' to originate a route?  In particular, I refer to the following in Section 3.1 of…

Authorization yes but not authentication.

You know the origin AS is authorized to announce the prefix but you don't 
know that the announcement is authentic.  Any other AS could produce a 
route that looks like the legitimate origin made the announcement when 
they did not.

When this is pointed out, I always remind people:

Even though origin authorization is not the end game, it is a vital 
necesary crucial important first step without which nothing else could 
succeed.

I.e., we are not wasteing our time here.

--Sandy

---

From: Andrew Lange <[email-masked]>
Date: Wed, 23 Feb 2011 15:17:14 -0800

Hi Sandy,

Reply is inline.

> recommendation of what you want out of a secure solution from this working 

Given the thread, I can understand your frustration.  And, I could have made myself more clear.  I'll try:  given the policies that AS_B might be implementing, we cannot know for certain, without AS_B publishing their policies, if AS_B should in fact be announcing which of AS_A's routes or in what form, hence the use of the term "Plausible." 

I agree "Plausible" is not security property, but a business/routing policy.

From a work item perspective, it would be useful to have a relationship object signed that says "I'm AS_A, and I have AS_B and AS_Q as legitimate connections."  This information, combined with AS_A's signed route-objects means that downstream ASes would be able to verify that a route 1.2.0.0/16 coming in with an AS PATH of [AS_A, AS_B] or [AS_A, AS_Q] would be AS PATHs that could be authorized.  Effectively solving the Origin + Upstream issue would solve most of the problems.  Yes, someone could then spoof an announcement of origin+upstream+self, but then we're looking at a minimum of a 3-AS path and the likelihood of that being best drops.  We can also do this with a simple route-filter and does not require on-system crypto calculations.

Andrew

---

From: Robert Loomans <[email-masked]>
Date: Thu, 24 Feb 2011 10:09:23 +1000

On 24/02/2011, at 09:17, Andrew Lange wrote:

> From a work item perspective, it would be useful to have a relationship object signed that says "I'm AS_A, and I have AS_B and AS_Q as legitimate connections." 

Geoff published a (now expired) draft for just such an object: http://tools.ietf.org/html/draft-huston-sidr-aao-profile-03

Rob

-- 
Robert Loomans                         email:       [email-masked]
Senior Software Engineer, APNIC        sip:    [email-masked]
http://www.apnic.net/                  phone:         +61 7 3858 3100

---

From: Randy Bush <[email-masked]>
Date: Thu, 24 Feb 2011 08:16:15 +0800

> Can you clarify what you mean by "the sidr work to date has not
> formally bound the route origin ... and [is] easily spoofed"?

rpki has roa binding prefix P to asn A0.  i run A1.  i inject a route
for P with as-path A1 A0.  the origin, A0, is what the roa allows, but
has no crypto sig.  

that is sidr work to date.  stops fat fingers but not the simplest of
path attacks.

randy

---

From: Geoff Huston <[email-masked]>
Date: Thu, 24 Feb 2011 08:16:58 +0800

> Geoff published a (now expired) draft for just such an object: http://tools.ietf.org/html/draft-huston-sidr-aao-profile-03

and I can push it out again.

Andrew, I assume you are serious in claiming that this would be useful to have in this context.

Geoff

---

From: Andrew Lange <[email-masked]>
Date: Wed, 23 Feb 2011 17:12:53 -0800

Geoff,

Do you disagree as to its utility? 

Andrew

---

From: Geoff Huston <[email-masked]>
Date: Thu, 24 Feb 2011 10:01:33 +0800

Andrew,

I hope I was neutral in neither agreeing or disagreeing as to its utility in my comment.

I was simply checking your assertion that "it would be useful to have a relationship object" and gently trying to understand your reasoning behind holding that view.

  Geoff

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
[email-masked]

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 23 Feb 2011 22:05:26 -0500

> I was simply checking your assertion that "it would be useful to have a relationship object" and gently trying to understand your reasoning behind holding that view.

for my money, I see this as data that will quickly rot, with very
little ability to really know if it's valid or not from an external
perspective.

Providing ROA data for netblocks, and attaching that to the notion of
a tree of certificate data down from RIR -> NIR -> LIR -> EndUser
should be 'simple', at least the mechanisms exist to keep this updated
and validated are I think. I don't think we want to introduce more
data that will root (IRR style).

Back to path validation though, what should we target as important
items to 'secure' (validate I think is the term I'd use), currently
the reqs talk about:
  o AS_PATH
  o prefix/length

Should, and why?, the relationship between ASN's be validated/used as
well? I think the thought had been that the RPKI data + irr data would
lead to better/easier prefix-list-style protections, so the
relationship didn't need to be validated beyond the immediate 2 ASN's.

-Chris

---

From: Shane Amante <[email-masked]>
Date: Wed, 23 Feb 2011 22:24:18 -0700

Sandy,

Thank you for responding!  Please see below.

On Feb 23, 2011, at 13:26 MST, Sandra Murphy wrote:
> This is something that has been mentioned in the wg many times, so I'll answer.
> 
> It is quite easy for an AS to construct an AS_PATH with the legitimate authorized origin on the origin end, without every having received such an announcement from the origin.  Without the legitimate origin ever having actually made the announcement to anyone, even.
> 
> That's why path validation is important.  You really would like some assurance that the origin actually announced the prefix *and* announced it to the party that appears tp have propagated it onward.

Let's deconstruct this a little further to see if we can be more clear on the reqmt's, (which feeds into the re-charter, etc. discussions).

Fundamentally I think it comes down to this: What is the routing scope for which SIDR intends to provide AS_PATH 'authorization'?  The reason I'm asking is, operationally, the more certain I can be of that 'authority' the more inclined/obligated I will be to impose, say, AS_PATH filtering based on that 'authority' to accept or drop those prefixes in my routers.  Alternatively, if we're just signing AS_PATH's, but don't know how to operationally use (or, it's too difficult/burdensome to use) those AS_PATH signatures at, for example, a certain routing scope/distance ... then, why bother imposing those signatures beyond a certain routing scope in the first place (increasing cost/complexity of the routers and Ops in the process)?

Specifically, what you've described above (I believe) only refers to just the _origin_ of a particular announcement -- not a 'signature' over the complete AS_PATH or a signature for each ASN in an entire AS_PATH.  I described my understanding of "origin" in my previous e-mail in this thread, namely: a given [customer] ASN (AS_A) expresses its intent to announce prefixes from that ASN to a set of _immediately_ adjacent (directly-connected) transit providers and/or peers.  Again, just for the purposes of drawing an analogy to something I'm already familiar with, this would be similar to what ASN's do today with IRR 'aut-num' objects by expressing their import & export policies to immediately adjacent ASN's.  Given this has already been done in the IRR, for dozens of years, with aut-num objects means it should be straightforward to have a similar concept in the RPKI.  I'd also add that the benefit of this approach is that the origin ASN, AS_A, knows first-hand (based on contractual policy) to which [upstream] transit-providers or peers it *potentially*[1] should or should not be announcing sets of routes to.  More importantly, capturing/recording this "adjacency" information is already part of the 'work-flow' that we do today, in the IRR world, when turning up (or, turning down) a particular [customer] neighbor ASN.  (Adding the RPKI bits to the workflow will add more time and steps to that process, but the "process" is already there).

If this is _all_ the current charter text and reqmt's draft is intended to capture, I can start to look at refining those from this PoV.  (And, you can ignore the rest of this e-mail :-).  That said, I'm still very worried about _whether_ or how we are going to handle the case of, for example, spoofing and/or hiding ASN'es in the case of 'local-as' and 'private-as' that are used extensively on these directly adjacent connections (to facilitate faster integrations of networks during M&A).

OTOH, once we go beyond AS_A's immediately adjacent ASN's (routing scope with AS_PATH of length > 2 -- IOW, the upstream peer/transit-provider's neighbors), this is where I really question if any 'value' can be derived from a complete, end-to-end AS_PATH signature (or, seeing a signature on each ASN in the AS_PATH).  More specifically, I mean that I (and, other operators) not only could, but _will_ construct off-line AS_PATH filters and push them to my routers (or, my future routers with 'majik' crypto-assist can directly do the same thing themselves) where I would be able to _reliably_ make a decision on whether to accept or deny prefixes coming from peers with a _completely_ signed AS_PATH.  As one extreme example, is it *really* operationally feasible to impose a filter of all possible AS_PATH's that UUnet *could* send to me, for all their customers (plus, customers of customers, etc., etc. -- including all of the prepending variations that may exist) on all of the eBGP sessions that I have with AS701 and not have it be out-of-date half-way through uploading it on my routers?

> You know the origin AS is authorized to announce the prefix but you don't know that the announcement is authentic.  Any other AS could produce a route that looks like the legitimate origin made the announcement when they did not.
> 
> Even though origin authorization is not the end game, it is a vital necesary crucial important first step without which nothing else could succeed.

Right.  I get that based on past discussions surrounding the "liability", (and/or amount of work), to verify the authenticity of an organization and their associated objects.  That said, I applaud Randy putting forward the "ghostbusters" draft to reveal the identify of the "authorized" party associated with the RPKI objects they hold in order to make it possible for operators to find out who the heck is behind a set of RPKI objects.

> I.e., we are not wasteing our time here.

I'm just trying to make sure I'm on the same page wrt getting the reqmt's straight in order that when solutions start appearing I can clearly explain to my internal developers and end-users/customers what they are, and are not, intended to solve for.

Thanks again,

-shane

[1] I say "potentially", because there are, for example, both standard and proprietary BGP TE communities, (such as NO_EXPORT), that allow customers to selectively suppress, prepend or de-preference routes that limit a prefixes routing scope ... but, those have nothing to do with the AS_PATH attribute.

---

From: Dongting Yu <[email-masked]>
Date: Thu, 24 Feb 2011 06:07:11 +0000

Hello,

> to the party that appears tp have propagated it onward.

Since my impression so far is that recording the actual route taken by
the announcement is not feasible in all cases, is it possible to
require only that a party involved can vouch/validate that part of the
AS path as correct? So an AS can modify their own part of a path as
long as they can say "yes it is correct" when asked, or they can, for
example, add another ASN as long as the other AS can say "yes" when
asked.

The difference is in one case we aim for accuracy and in the other we
just need someone (who has the rights) to verify it. My impression is
that so far the former is leaned towards. But correct me if I have
misunderstood.

Dongting

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 24 Feb 2011 15:27:03 +0200

Andrew,

> Given the thread, I can understand your frustration.  And, I could have made myself more clear.  I'll try:  given the policies that AS_B might be implementing, we cannot know for certain, without A…

Assume a model where the AS path is signed such that the recipient is able to verify that for each arc in the path, the further AS did sign it to the closer AS.  To take your example and extend it, suppose we have

	AS_A --> AS_B --> AS_C --> AS_D

(A announces a route to B announces it to C announces it to D.)  If D is able to verify the signature on the (B, C) arc, then it knows (for some value of "knows" of course :-) that B did actually send the route to C.  Whether that fulfills "AS_B should in fact be announcing which of AS_A's routes or in what form" I leave it to you to interpret -- it doesn't protect against a policy misconfiguration on the announcing router of AS_B.  An abstract representation of AS_B's policy could do that, but functionality like that is beyond the scope of the proposed charter item.  The fact that systems to provide exactly this kind of abstract policy publication have fallen into disrepute doesn't fill me with optimism about this approach, despite my own personal history with it.

I interpret the proposed charter item to be asking not "if AS_B *should* in fact be announcing which of AS_A's routes or in what form" but rather roughly "if AS_B *did* in fact announce which of AS_A's routes and in what form".

--John

---

From: Russ White <[email-masked]>
Date: Thu, 24 Feb 2011 15:00:55 -0500

> I interpret the proposed charter item to be asking not "if AS_B *should* in fact be announcing which of AS_A's routes or in what form" but rather roughly "if AS_B *did* in fact announce which of AS…

Isn't this a difference without a distinction? Let me put it another way.

If you claim "A did, in fact, send an update it received from B, which B
received from C, to me," what did you intend to _do_ with this
information? If you intend to block receipt of the route in the case
where the signatures are not "valid," then you automatically moved to,
"A should have sent me this update that it received from B, and B
received from C."

If you sign the update with no filtering, then you've proven what _did_
happen. Once you filter, you're trying to prove what _should_ happen.

Can you explain the difference in some other way that doesn't mix the
two ideas?

:-)

Russ

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 24 Feb 2011 18:51:39 -0500

Andrew,

Comment below.

Sriram

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Lange
> Sent: Wednesday, February 23, 2011 6:17 PM
> To: Sandra Murphy
> Cc: [email-masked]
> Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work
> 
--- snip ---
> 
> From a work item perspective, it would be useful to have a relationship object signed that
> says "I'm AS_A, and I have AS_B and AS_Q as legitimate connections."  This information,
> combined with AS_A's signed route-objects means that downstream ASes would be able to
> verify that a route 1.2.0.0/16 coming in with an AS PATH of [AS_A, AS_B] or [AS_A,
> AS_Q] would be AS PATHs that could be authorized.  Effectively solving the Origin +
> Upstream issue would solve most of the problems.  Yes, someone could then spoof an
> announcement of origin+upstream+self, but then we're looking at a minimum of a 3-AS
> path and the likelihood of that being best drops.  We can also do this with a simple route-
> filter and does not require on-system crypto calculations.
> 
> Andrew
> 
Yes, the path length goes up by 2.
But normally an adversary would spoof an announcement with a subprefix (more specific) 
of the prefix that the legitimate prefix owner has announced 
(while still trying to keep within the maxlength as specified in the ROA).
I that case the increased path length would not matter. 
The spoofed announcement would be accepted and propagated widely.

Sriram

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 25 Feb 2011 16:05:31 +0200

> Can you explain the difference in some other way that doesn't mix the

Since after reading your message carefully three times I don't understand your question, I'm unable to answer it.  Sorry.

--John

---

From: Russ White <[email-masked]>
Date: Fri, 25 Feb 2011 09:10:30 -0500

> Since after reading your message carefully three times I don't understand your question, I'm unable to answer it.  Sorry.

You're apparently trying to separate the idea of proving an update
traveled a specific path from the idea of using this information to
actually filter or determine any other policy. I don't see how you can
separate the two --can you explain how you can?

:-)

Russ

---

From: John Scudder <[email-masked]>
Date: Fri, 25 Feb 2011 06:14:54 -0800

> separate the two --can you explain how you can?

If you can establish the former (that the route did travel across the path it said it did), that outcome can be used as input to policy.  This is exactly analogous to draft-ietf-sidr-pfx-validate-01, BTW.

Divide, conquer.  A commonly used trick in computing. :-)

--John

---

From: Russ White <[email-masked]>
Date: Fri, 25 Feb 2011 09:26:42 -0500

> Divide, conquer.  A commonly used trick in computing. :-)

Hmmm...

This is what I thought.

1. Shane and I are arguing that you can't --or shouldn't-- imply policy
based on which AS a particular piece of routing information went through
multiple hops from you (I hope that's right, Shane).

> I interpret the proposed charter item to be asking not "if AS_B *should* in fact be announcing which of AS_A's routes or in what form" but rather roughly "if AS_B *did* in fact announce which of AS…

3. My question was --it seems you're trying to say, "no, I don't want to
infer policy from this, I just want to prove what happened." At which
point I asked --what's the difference if, in fact, you intend to act
based on what you perceive as "what happened?"

In trying to "divide and conquer," you're actually assuming step 2 from
step 1 --and the assumption is what I think we need to drive out into
the open air and discuss by building a set of requirements other than,
"I want to prove what happened."

:-)

Russ

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 25 Feb 2011 09:29:13 -0500

Let me try phrasing the issue differently.  I may still be missing the 
point, from all sides.

I believe that what is actually wanted is primarily:
o To prevent any advertiser from sending an advertisement that would 
cause other properly behaving parties to send traffic iin a way that 
they are not "entitled" to cause

As secondary matter
o We want such attempted subversion to be visible at more than one hop 
because experience tells us that not everyone deploys the tools 
properly, and thus we can not count on every honest player doing their 
job well.

(Colluding subverting players is addressed only to the degree that it is 
covered by what we are after, not explicitly.  We are staying away from 
Byzantine Generals.)

The above probably needs more wordsmithing, but is a problem statement 
that does not assume that packets follow their advertisements, nor that 
any party can control what any other party actually does.  It also 
avoids getting into the question of the accuracy of the reflection of 
the path of the advertisement, the AS path in the advertisement, and the 
actual packet flow.  Instead, it focuses on an attack we are trying to 
prevent.
I believe that the primary solutions on the table are all solutions that 
can be reasonably considered to address the problem as stated.  (I.e. I 
am not trying to change the solutions pace, only to clarify the problem 
space.)

Apologies if I am still completely confused.
Yours,
Joel

---

From: John Scudder <[email-masked]>
Date: Fri, 25 Feb 2011 06:41:43 -0800

I think that is more or less right.

--John

On Feb 25, 2011, at 4:29 PM, Joel M. Halpern wrote:

> Let me try phrasing the issue differently.  I may still be missing the point, from all sides.
> 
> o To prevent any advertiser from sending an advertisement that would cause other properly behaving parties to send traffic iin a way that they are not "entitled" to cause
> 
> As secondary matter
> o We want such attempted subversion to be visible at more than one hop because experience tells us that not everyone deploys the tools properly, and thus we can not count on every honest player doing their job well.
> 
> (Colluding subverting players is addressed only to the degree that it is covered by what we are after, not explicitly.  We are staying away from Byzantine Generals.)
> 
> The above probably needs more wordsmithing, but is a problem statement that does not assume that packets follow their advertisements, nor that any party can control what any other party actually does.  It also avoids getting into the question of the accuracy of the reflection of the path of the advertisement, the AS path in the advertisement, and the actual packet flow.  Instead, it focuses on an attack we are trying to prevent.
> I believe that the primary solutions on the table are all solutions that can be reasonably considered to address the problem as stated.  (I.e. I am not trying to change the solutions pace, only to clarify the problem space.)
>

---

From: John Scudder <[email-masked]>
Date: Fri, 25 Feb 2011 06:40:35 -0800

> multiple hops from you (I hope that's right, Shane).

"Can't"?  Hm.  I'll address "shouldn't", by saying if you think that shouldn't be done, then don't configure your policy to do it.  Others disagree.  In any case, the question of which AS a particular piece of routing information went through is only tangentially related to the topic, which I will remind you is

This doesn't speak to any particular AS in the path.  It just asks whether there is a custodial chain that extends back to the route's origin.

I'll also note in passing that as others -- Ruediger maybe? -- have noted, AS path regexes wouldn't exist if policies weren't already being written based on exactly "which AS a particular piece of routing information went through multiple hops from you".

> "I want to prove what happened."

You lost me again.

My best guess based on the above is that you think we should actively prevent people from writing policies to prefer routes that have a known custodial chain that extends back to the origin to ones that do not have such.  I do not think we should prevent them from doing so.  The proposed charter addition suggests adding a tool to enable that choice.  It seems like a worthy thing to me.

By and large I think the discussion of general policy in this context muddies the waters so I am going to try to resist the temptation to discuss it any further.

--John

---

From: Russ White <[email-masked]>
Date: Fri, 25 Feb 2011 09:54:05 -0500

> This doesn't speak to any particular AS in the path.  It just asks whether there is a custodial chain that extends back to the route's origin.

Why does the custodial chain matter?

:-)

Russ

---

From: John Scudder <[email-masked]>
Date: Fri, 25 Feb 2011 06:56:40 -0800

> Why does the custodial chain matter?

I think Joel summed it up pretty well.  Rather than continue to pick at this nit, why not switch gears and see what you think of his alternate formulation?

--John

---

From: Russ White <[email-masked]>
Date: Fri, 25 Feb 2011 10:00:05 -0500

> I think Joel summed it up pretty well.  Rather than continue to pick at this nit, why not switch gears and see what you think of his alternate formulation?

I thought I already responded to that?

:-)

Russ

---

From: John Scudder <[email-masked]>
Date: Fri, 25 Feb 2011 07:03:38 -0800

[extra cc's dropped]

...
> I thought I already responded to that?

Not that I saw but perhaps our messages have crossed.  I was referring to 

Message-Id: 	<[email-masked]>
Date: 	February 25, 2011 4:29:13 PM GMT+02:00

in this same thread.  I will patiently wait to see your reply.

--John

---

From: John Leslie <[email-masked]>
Date: Fri, 25 Feb 2011 12:45:52 -0500

Russ White <[email-masked]> wrote:
> To: John Scudder <[email-masked]>
> 
>> This doesn't speak to any particular AS in the path. It just asks
>> whether there is a custodial chain that extends back to the route's
>> origin.
> 

   I can't speak for John Scudder, but I would guess he means that it
doesn't _matter_ whether it matters: that is what folks want to know.

   We have quite a history of "assuming" that the chain shows which
ASs the routing information has traveled. In SIDR we are realizing how
easily that can be untrue.

   It's natural for folks to want to ratify the assumption.

   Speaking for myself, I'm uneasy about making this a goal _before_
I'm convinced it's reasonable to achieve it.

   (This doesn't mean I insist on nailing down a solution before setting
the goal -- it means I suspect that the goal is not reasonably achievable
with current hardware.)

---

From: Randy Bush <[email-masked]>
Date: Sat, 26 Feb 2011 20:39:10 +0900

> If you can establish the former (that the route did travel across the
> path it said it did), that outcome can be used as input to policy.
> This is exactly analogous to draft-ietf-sidr-pfx-validate-01, BTW.
> 

more like what is taught in opsys 101, separation of mechanism from
policy

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 26 Feb 2011 20:47:44 +0900

> they are not "entitled" to cause

close, but i am not entirely comfortable with this
  o we can not hope to prevent the advertisement, only detect it is
    bogus.
  o it is the bgp receiver's policy decision on where to send traffic.
    a security researcher may specifically want to send traffic toward
    a bogus announcement.
  o i.e. 'cause' is too strong a word, perhaps 'lure'

but you have the essential point

randy

---

From: Andrew Lange <[email-masked]>
Date: Mon, 28 Feb 2011 20:16:21 -0800

John,

But wouldn't a record of an existing announcement also show that AS_B did in fact announce which of AS_A's routes and in what form?  Why does it need to be signed if all we want to do is record what happened?  Perhaps I'm missing something....

Andrew

---

From: Andrew Lange <[email-masked]>
Date: Mon, 28 Feb 2011 20:18:45 -0800

Sriram,

Why would you accept a route de-aggregated by an upstream?  If signed route-object says AS_A owns and announces only the route 1.2.3.0/20 and I'm seeing 1.2.3.0/21 from AS_B, the route filter should be configured not to accept more specifics.   If AS_A wants to de-aggregate, it can split it's route-objects into the more specifics and register them.

Andrew

---

From: Andrew Lange <[email-masked]>
Date: Mon, 28 Feb 2011 20:13:01 -0800

Geoff,

My reasoning is that   without a specific policy statement, such as "B should be announcing this route, signed A", then we can demonstrate that B did announce it, but not if B should have announced it.   With that policy object then we can construct the route filter to check that not only did B announce it but if they should be doing so.  From an operational perspective that has value.

Andrew

---

From: Andrew Lange <[email-masked]>
Date: Mon, 28 Feb 2011 20:28:40 -0800

John,

To reply to my own message, after reading through the rest of this chain. 

Is all we're trying to do here is to establish a "custodial chain" of a route to prevent some ill-behaving AS in the middle attempting to hijack a route, effectively by pretending that the source AS is behind it, since we're origin-validating, and hoping that its neighbors end up preferring it's longer-AS announcement over other, likely preferred routes, from legitimate sources?

If that is the case, having a set of policy objects expressing AS relationship should do the same thing  and more with less overhead? (yes, I know that data integrity becomes an issue, but data integrity is always an issue.)

Andrew

On Feb 28, 2011, at 8:16 PM, Andrew Lange wrote:

> <smime.p7s>_______________________________________________
> sidr mailing list
> [email-masked]

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 1 Mar 2011 00:14:59 -0500

On Mon, Feb 28, 2011 at 11:28 PM, Andrew Lange
<[email-masked]> wrote:
>
> If that is the case, having a set of policy objects expressing AS relationship should do the same
> thing  and more with less overhead? (yes, I know that data integrity becomes an issue, but data
> integrity is always an issue.)

if you go this route, how do you validate the data you've received
from the datastore? how do you do this in the face of all of the
myriad of datastores we have today of this same data which are rotten
and unmaintained?

-Chris

---

From: Randy Bush <[email-masked]>
Date: Tue, 01 Mar 2011 14:41:31 +0900

> If that is the case, having a set of policy objects expressing AS
> relationship should do the same thing and more with less overhead?

real policy is per prefix, customer, peer, and things disgustingly more
complex, with complications of backdoor relationships, ibgp policies to
implement regionalization, and a jillion things you would not want to
tell your children.

aside from not wanting to publish much of that, even if it was
publishable, how would you differentiate 'the announcement really took
this path' from 'it is possible that the announcemnt took this path?'
the latter being a half-assed probabilistic assurance.

randy

---

From: Geoff Huston <[email-masked]>
Date: Tue, 1 Mar 2011 17:09:28 +1100

>> integrity is always an issue.)

I was deliberately keeping away from participating in this conversation, but I have researched this topic in some depth in recent times (http://www.potaroo.net/papers/BGP_Security_Literature_Review.pdf), and I think that I have some familiarity with this topic that may be helpful to others who are also watching this and trying to understand what is being debated here.

What I see here is a dichotomy between two distinct architectural approaches, and the conversation appears to flip from one to the other when we discuss path validation. 

One view is that we are securing the operation of a particular protocol, namely BGP. This protocol operates in a standard distance vector mode of AShop-by-AShop, where information is propagated outward from the causal point. If you want to secure this protocol, then there are two fundamental attributes of the protocol's transitive data objects that are securable, namely the address prefix and the AS path. The AS path is constructed incrementally in this protocol, and the most direct mechanism that would allow it to be secured is for each AS to be able to demonstrate the validity of what it received and what it added. I.e. incremental signing of elements of the AS path as the basic unit of routing information propagates across the inter-AS network. To the extent that this is an accurate reflection of the underlying inter AS connection topology, EBGP multi-hop notwithstanding, this is an accurate reflection of a subset of the interAS topology, and it allows a BGP speaker the ability to validate, in the context of the operation of BGP the protocol, information that is being propagated by BGP.

The other view I see is a reflection of the observation that BGP, like any other inter-domain routing protocol, is a mechanism that "discovers" the inter-AS topology of the network. If you already "know" the "real" topology via some other mechanism, then you can use this information as a filter for information being passed to you in the routing protocol. i.e. In this instance if you had complete information of all "valid" AS adjacencies then you could use this as an information filter for AS paths that you are being presented with via BGP. If an AS path contains an assertion of an AS adjacency that is not in your local "map then you have grounds to doubt that the information you are be presented with in this particular update is in fact "valid"

Superficially, this second approach is seductively attractive: its simple to conceptualise, relatively lightweight and probably fast in terms of processing overheads, and makes the minimum of assumptions as to the way the protocol itself operates. This decoupling of the propagation of the security credentials from the protocol operations also appears to be consistent with the approach being taken to securing origination - the security credentials are flooded via some other mechanism and they are used locally to maintain a local route filter which is then used to pass / reject incoming route updates in BGP based on the implicit AS adjacencies that are being asserted in the AS Path.

But this is a superficial attraction as I see it. This decoupled approach still admits lies in routing. It limits the extent to which one can lie, but it still admits lies. 

However, I don't think this aspect of the issue of AS Plausibility vs AS Path Provability is the core of the issue _for me_ (others see it differently and want a stricter condition). More importantly for me at any rate, is that this decoupling of topology information from the operation of the protocol potentially stops the operation of the routing protocol to be a topology discovery tool. If AS 1 and AS2 bring up a peering session, then no one else will believe that adjacency (or the routes that use that adjacency) until the security credentials of the pairwise adjacency of AS1 and AS2 has already flooded the network. And how does this association get flooded? Equally, how do you inform everyone else that a peering session has been torn down? Or that this AS adjacency has some policy constraints that are intended to limit the scope of its visibility? As long as you are prepared to limit your concept of the scope of a routing protocol to be one of best path computation over a relatively fixed topology that all players know of in advance then this idea of a decoupled approach to propagation of AS adjacencies and the operation of the protocol itself could well be a viable approach to securing the outcomes of the operation of the protocol, or at least limiting the range of potential ways to lie in the protocol. But if you also want some level of dynamic discovery of the underlying topology as well as path computation in the scope of the operation of the protocol, then you are asking a lot of this form of decoupling of securing the underlying inter-AS topology from the operation of the routing protocol, because at some point you need to distribute the information of a new AS adjacency at the same time as you want to pass the routing protocol packet. I.e. If you want to secure what BGP is telling you in the AS Path then it makes sense to use a mechanism that is directly associated with the manner of the construction of the AS Path itself, within BGP itself. And if you couple the security credentials to the protocol not only do you get dynamic behaviour of topology discovery, you also get AS Provability in so far as you are now back to being able to validate that the path of propagation of the update matches the path describes in the update.

(I note that the same argument of using in-band security credentials to enable dynamic discovery of routing information could be applied to origination security credentials and their manner of distribution, and I also note that the WG decided not to go down that path for securing origination. But having made that decision, I don't think that this decision for the manner of securing origination necessarily precludes the WG from using the BGP protocol mechanisms to bind the AS Path and the AS Path security credentials together. I do however think that sBGP, which as I recall bundles both origination and path security credentials into the BGP protocol payload together with the routing data that the credentials relate to, still strikes me as an approach that has an attractive level of architectural consistency. :-) )

The above is all my own opinion, naturally! Now to clamber off this soap box and head back to hide in my corner!

regards,

  Geoff