Subject: Re: [RPSEC] Re: Potential Requirements New Thread

From: [email-masked]
Date: Wed, 13 Nov 2002 09:00:50 -0500 (EST)

>And the path is used in the
>decision process only as a way to prevent loops (being a first
>level tie breaker is only incidental, really).

I'm not sure what you mean by "incidental".

>-- Knowing the origin 
>-- Knowing that the origin actually originated this prefix

So if AS 7007 had truncated the AS_PATH to the originating AS and then
added itself to the path and advertised that path of length 2,
would that have not influenced lots of traffic to head to AS7007
that would otherwise not have gone that way?

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

---

From: Russ White <[email-masked]>
Date: Wed, 13 Nov 2002 09:20:49 -0500 (EST)

> So if AS 7007 had truncated the AS_PATH to the originating AS
> and then added itself to the path and advertised that path of
> length 2, would that have not influenced lots of traffic to
> head to AS7007 that would otherwise not have gone that way?

It may, or it may not. There are a lot of overriding influences.
For instance, AS7007 could simply originate two prefixes covering
the same space, but one bit longer, and it won't matter what the
AS path is. Or, if the next hop out AS happens to set the local
pref for some internal policy, it won't make any different what
AS7007 does with the AS path. With the new "Custom Decision"
draft, life becomes more interesting in this respect.

This is one of those knots we get tangled in on a regular basis
in bgp--what difference does AS path prepend _really_ make? It
seems to sometimes, and others it doesn't, depending on the
situation out in parts of the network you can't control.
Bascially, the next hop chosen is regulated by the AS which
receives the route, not the one which originates it, which makes
solving any problems related to path verification a very
interesting knot to untangle.

You _do_ want to prevent someone from spoofing an AS--saying they
are connected to someone they aren't, or saying they are someone
they're not, but verifying the path doesn't (seem to) necessarily
prove these things. So, I suppose my question is, what would we
accomplish by protecting the AS Path, per se? We should protect
against spoofing (and protecting the as path may be an answer to
that), but the AS path itself, as an item of interest, doesn't
appear to be all that interesting (to me).

I'm just thinking in terms of the same thing with OSPF and IS-IS,
where, as you say, the path isn't all that interesting of an
aspect to try and protect in those protocols (and I agree with
that), and how that fits into the current threat drafts (and the
bgp attack tree).

:-)

Russ

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

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 13 Nov 2002 09:57:39 -0500

On Wed, Nov 13, 2002 at 09:20:49AM -0500, Russ White wrote:
> in bgp--what difference does AS path prepend _really_ make?

To be a little more general, in BGP an announcement has the potential
to have a "capture effect".  In the absence of a more specific 
announcement, advertising reachability has the chance to capture
traffic towards the advertiser of that reachability even if the
resulting path is not the one that is advertised.

However, having that route only means it has the *potential* to
capture traffic at a given router.  Whether it does or not depends
on policy.

At least from the perspective of a regional ISP who doesn't
provide a lot of transit services, prepending can make HUGE
differences to your traffic flows.  However, its a very coarse knob
due to the locality of the effect.

> accomplish by protecting the AS Path, per se?

While we can't protect the entire path due to the absence of
perfect information due to implicit and explicit aggregation,
validating the path of what we *do* potentially limits the risk.

The question is, are we getting a good bang for the buck out of
this imperfect check?

To restate a previous post - the best you might be able to come up
with is "foo originated this route.  bar, who is adjacent to
me propagated this route to me.  Is he allowed to?"  If you use
that route, you *know* that they're going to get the traffic.
You don't know what they're going to do with it once they have it.

> aspect to try and protect in those protocols 

I'm somewhat ignorant of the nitty-gritty of various IGPs, however
a similar threat (I think?) is that you can advertise signed
and authenticated LSA's to your heart's content.  This just implies
that if the routers *used* those LSA's as advertised all routers
should theoretically route packets according to the algorithm.

If a box maliciously forwarded packets a different direction from
what the IGP said, how could you tell from the routing protocol
perspective?  I don't think you can.

-- 
Jeff Haas 
NextHop Technologies