Subject: Re: [RPSEC] BGP Requirements Draft

From: Sandy Murphy <[email-masked]>
Date: Mon, 26 Sep 2005 06:16:54 -0400 (EDT)

>AS_PATH twiddling really is the only knob operators have, and there
>are various interesting things one can do, eg inserting AS numbers of
>/others/ into announcements to preclude an advertisement from
>reaching them and passing through them.

I'm hearing of this more and more frequently.  The fact that it is
seemingly widespread and accepted as honest practice is troubling.
It might be a fine and dandy tool in the hands of those on the side
of truth and goodness, but the bad guys could use it also, to craft
traffic to their own ends.  And we have yet to find a way to code
the "evil" flag in the packets.

Note: the path adjacency check would disallow this practice in most
cases.

>b) The desire to have AS_PATH reliably attest to the path the
>    announcement has traveled through

As I'm arguing, this is essential in order for the check-for-own-AS
to ensure loop-freedom.  If the AS_PATH does *NOT* attest to the list/set
of AS's that have all touched the announcement, then checking for your
own AS in the AS_PATH does not ensure loop-freedom.

--Sandy

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Paul Jakma <[email-masked]>
Date: Mon, 26 Sep 2005 11:31:06 +0100 (IST)

> seemingly widespread and accepted as honest practice is troubling.

Well, AS_PATH is the only useful inter-AS traffic engineering knob 
which BGP provides, so troublesome perhaps, unexpected, no.

> Note: the path adjacency check would disallow this practice in most

Right, and hence the fundamental discord between BGP traffic-eng 
practice and the desire for AS_PATH to have verifiable meaning as a 
path.

> to ensure loop-freedom.  If the AS_PATH does *NOT* attest to the 
> list/set of AS's that have all touched the announcement, then 
> checking for your own AS in the AS_PATH does not ensure 
> loop-freedom.

Agreed.

What would be the pros/cons of recording path in a verifiable way in 
a seperate attribute, say TRUSTED_AS_PATH or some such? One obvious 
advantage is that it would immediately address the concerns of those 
who wish to be able to continue to use AS_PATH for T-E.. (Apologies 
if this has already been covered here).

The other possibility is to do it other way around:

- Have AS_PATH be the trusted path, recording exactly the path
   traversed
- Solve the traffic-engineering-knob problems of BGP in some other
   way

Course, the latter isn't on-topic here :) (And could take a /long/ 
time, if ever, to achieve consensus on and implement).

And if one must accomplish it all with just AS_PATH, then I'd agree 
with Rusty that one should trade-away the wish to have path traversal 
recorded securely, cause the traffic-engineering side is too 
important to just banish.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Many pages make a thick book.

---

From: Sandy Murphy <[email-masked]>
Date: Mon, 26 Sep 2005 07:57:49 -0400 (EDT)

>important to just banish.

So both the currently recommended AS_PATH checks, the adjacency check and the
full path traversal check, would do away with the traffic enginnering
practice you describe.  Are you saying you would prefer to junk both
of those recommended  checks?   Ouch.

--Sandy

P.S.  I call the traffic engineering practice you describe "route poisoning"
- did I make that up or is that a recognized term for the practice?

---

From: Blaine Christian <[email-masked]>
Date: Mon, 26 Sep 2005 08:07:16 -0400

> of those recommended  checks?   Ouch.

I have said this before but it may bear repeating.  The work folks  
are doing in the "accepted practice" realm is adding AS's to the AS  
path.  The added AS's are ones that are already there (and only on  
immediately adjacent hops).  I do not know any providers who are  
changing the order, inserting in the middle or mucking about with  
subtracting AS's that are not their own.

I am sure there will be "someone" who claims they do the stranger  
implementations as common practice.  In those stranger  
implementations we should not feel too concerned as they are likely  
to be internal to a provider and thus the security of the path can be  
considered manageable by other means.

Regards,

Blaine

---

From: Paul Jakma <[email-masked]>
Date: Mon, 26 Sep 2005 13:12:06 +0100 (IST)

On Mon, 26 Sep 2005, Sandy Murphy wrote:

> So both the currently recommended AS_PATH checks, the adjacency 
> check and the full path traversal check, would do away with the 
> traffic enginnering practice you describe.  Are you saying you 
> would prefer to junk both of those recommended checks?  Ouch.

Well, I think it's a tough call. Removing useful capabilities tends 
not to go down well with users, you'd have to poll BGP users to see 
what they'd want more I guess.

That said, if we reframe this debate in terms of some kind of 
additional TRUSTED_AS_PATH, then we can leave all the existing 
practices around AS_PATH untouched and maybe keep everyone happy. And 
a debate about this notional TRUSTED_AS_PATH could focus purely on 
the security merits/tradeoffs (rather than having to delve into what 
TE uses of AS_PATH are and are not appropriate/useful).

An idea at least ;). (maybe it's been brought up already and 
dismissed - if so apologies).

> - did I make that up or is that a recognized term for the practice?

It's recognised yes, in terms of RIP and there's a similar concept in 
OSPF. I've not heard it used wrt these BGP path tricks, so "BGP route 
poisoning" is yours possibly :).

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
And on the eighth day, we bulldozed it.

---

From: Sandy Murphy <[email-masked]>
Date: Mon, 26 Sep 2005 09:22:38 -0400 (EDT)

>And A advertises X to B, B can readvertise it to C or D, and E can't
>tell the difference, since there's no way to not allow B to readvertise
>the route to D, from A's perspective. Isn't this what you just said is
>outside the spec, so we can't do anything about it?

No, this is *NOT* what I'm saying.  

Let me try with your diagram.
If I understand your diagram:
A---B---C
     +---D---E

Suppose A is announcing the route to B and B is propagating that route
to C.  But B is also a peer of D and B is *NOT* announcing the route
to D.  But D could announce the route (D,B,A) to E because the peerings
exist - even though it did not receive an UPDATE carrying (B,A) from B.

--Sandy

---

From: Russ White <[email-masked]>
Date: Mon, 26 Sep 2005 09:33:47 -0400

> exist - even though it did not receive an UPDATE carrying (B,A) from B.

Certainly, but you've moved into the realm of policy. It's B's policy 
not to allow D to transit traffic from E. First, I'd point out that it's 
A's route, not B's, so speaking of B's policy towards A's route is a 
little ambiguous to begin with. Did A sign a contract with B stating 
this to be A's policy? Or did B design this policy without A's consent 
and knowledge? In either case, this is outside the scope of the BGP 
specification.

Second, I'd point out that B can enforce this policy much more cleanly 
with packet filtering on it's edge with D, than trying to count on 
routing control flow to enforce data flows.

Third, there are actually ways to solve this problem using a graph of 
internetwork connectivity, if you really must solve it with routing.

So, again:

- -- Is this in scope?
- -- Is it correct to say it's "more secure" without considering all the 
options and tradeoffs?

:-)

Russ

- -- 
[email-masked] CCIE <>< Grace Alone

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 26 Sep 2005 10:01:33 -0400

[Poisoning AS_PATHs]

> the "evil" flag in the packets.

I'm not certain I'd call this "evil".

It is far more evil to remove ASes from the path.
It is far more evil to propagate routing information and do packet
filtering.

One could look at this and simply call it a case of "announce only that
which you are willing to forward".  By injecting someone else's AS into
the path, you're declaring that you aren't willing to forward traffic.
Unfortunately, the granularity of this mechanism is poor.

> Note: the path adjacency check would disallow this practice in most

This depends on whether you're using the AS_PATH for the adjacency
checks or not.  In many cases, it's the logical candidate.  I think
we're adding more and more cases where we outright want to have
one attribute that is clearly tied to route propagation through a
set of ASes and another that is used for loop prevention.

-- 
Jeff Haas 
NextHop Technologies

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 26 Sep 2005 10:59:58 -0400

In message <[email-masked]>, Paul Jakma write
>what they'd want more I guess.

Sometimes, the proper answer is "just say 'no'".  There are features 
and behaviors that *cannot* be secured.  The question to ask is the 
desirability of the feature (and how widespread the usage is is one 
metric) versus the utility to the attacker.  If we're going to bless 
arbitrary types of of AS_PATH rewriting to support various unclean 
forms of traffic engineering, we may as well go home -- we've just 
negated any possible way to know securely what such nodes actually 
received.  

Clearly, we need to understand how operators actually use BGP.  In the 
case of unsecureable behavior, we may be better off designing a new BGP 
feature that will do what they want more directly, rather than trying 
to weld extra-large rocket engines to such porcine features [see
RFC 1925, Section 2(3).)

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Paul Jakma <[email-masked]>
Date: Mon, 26 Sep 2005 17:21:51 +0100 (IST)

> negated any possible way to know securely what such nodes actually 

I don't see why.

In such a case (if you can /not/ tighten the useage of AS_PATH) there 
still would be the option to leave AS_PATH as 'unclean' and introduce 
some kind of TRUSTED_AS_PATH.

One for people to play their TE tricks on, the other to securely 
record the path.

> to weld extra-large rocket engines to such porcine features [see

Exactly. :)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
The University of California Statistics Department; where mean is normal,
and deviation standard.

---

From: Blaine Christian <[email-masked]>
Date: Mon, 26 Sep 2005 12:27:13 -0400

> to weld extra-large rocket engines to such porcine features [see

Steve's point should be well taken.  While folks are using the  
ability insert AS's to block certain prefix announcements to certain  
systems it is not clear that this is something the AS path was  
intended to accomplish.  As such, the support of that ability, by  
router vendors, is probably tenuous at best.

Also, the few examples I have heard thus far seem to be of dubious  
purpose.  We actually did a "poll" of sorts for this specific issue  
on the nanog thread.  It was pretty clear the ability to block prefix  
announcements to certain AS's  was not driving a need.

It may be helpful to distinguish between Internet BGP and private BGP  
as well.  I have only been focused on the Internet BGP folks so if  
there are networks that require the ability to perform this sort of  
modification a large router vendor would probably have a better idea.

Regards,

Blaine

---

From: Stefan Mink <[email-masked]>
Date: Mon, 26 Sep 2005 20:50:25 +0200

Hi Jeffrey,

> set of ASes and another that is used for loop prevention.

actually we would need 3 attributes:

* one for the metric: this one is purely numerical and can only be
   incremented. Instead of taking the length of the AS_PATH into
   account during the routing decision, one takes this one.
* one for loop checks: here on Traffic Engineering is being done
   anymore, but the attribute contains exactly the ASes in the
   exact historic order, which have passed on this route.
* one for policy: here you can list ASes that should not receive
   or use this route. This is of course not enought to implement
   a mechanism to protect against the redistribution attack I
   described, it's just a mini-mechanism to implement simple policies.

    tschuess
              Stefan
-- 
Stefan Mink, Schlund+Partner AG (AS 8560)
Primary key fingerprint: 389E 5DC9 751F A6EB B974  DC3F 7A1B CF62 F0D4 D2BA

---

From: Stefan Mink <[email-masked]>
Date: Mon, 26 Sep 2005 21:11:40 +0200

Russ White wrote:
> Certainly, but you've moved into the realm of policy. 

I'd rather say she moved into the realm of "liveliness of origination":
It's not enough the ensure that the first AS in the path is authorized
to origin that route. It must also be ensured that that AS actually
origined this route (and not - as Sandy's example showed - some AS doing
correct prependings). Even harder (impossible in absence of any soft
state mechanism) is: is the route still valid? (i.e. has not been
withdrawn)

> - -- Is this in scope?

yes, it's definitely important to ensure (by means of a signature e.g.)
that a route was actually originated by the first AS in the path.

> - -- Is it correct to say it's "more secure" without considering all the 

I don't understand this question :-}

    tschuess
              Stefan