Subject: [RPSEC] another example of peering topology check not catching

From: Sandy Murphy <[email-masked]>
Date: Fri, 11 Mar 2005 18:37:30 -0500 (EST)

Another example which the peering topology check doesn't catch (I
think):

         B
        / \
       /   \
      A     C

B is multi-homed and has been allocated a /24 address block.

B advertises more specifics for part of that address block to A and
more specifics for the rest to C.  (Maybe it is load balancing, maybe
there are performance advantages to C's connection for the specific
application running on the addresses it sends to C, etc.)

A advertises the more specifics it got from B *and* the rest of the
more specifics as well, so it is advertising the entire /24 address
space.

This isn't really a case of needing to know B's policy in order to
decide what A should have done.  A is making an advertisement without
having received an advertisement that would justify it or any indication
that B is willing to accept the traffic that way.

Note that the traffic will get there.  And the traffic is following
the announced AS_PATH.  And the AS_PATH advertised will "correspond to
a verifiable list of autonomous systems based on the peering topology
of the network."

But B is bound to be displeased, no?

--Sandy

P.S. On the other hand, if there was a way to check:

>   o  Routing information carried through BGP SHOULD include information
>      that can be used to verify the readvertisement or modification by
>      each autonomous system through which the UPDATE has passed.

Then A's mis-advertisement would be caught.

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

---

From: Russ White <[email-masked]>
Date: Fri, 11 Mar 2005 22:36:28 -0500 (Eastern Standard Time)

> Another example which the peering topology check doesn't catch (I think):
>
>
>         B
>        / \
>       /   \
>      A     C
>

> B advertises more specifics for part of that address block to A and more 
> specifics for the rest to C.  (Maybe it is load balancing, maybe there 
> are performance advantages to C's connection for the specific application 
> running on the addresses it sends to C, etc.)

Let's make it more specific, say B advertises 10.1.1.0/25 to A, and 
10.1.1.128/25 to C.

> A advertises the more specifics it got from B *and* the rest of the more 
> specifics as well, so it is advertising the entire /24 address space.

Yes, but, from a routing perspective, this is perfectly valid. The path 
exists, and is loop free.

> This isn't really a case of needing to know B's policy in order to decide 
> what A should have done.  A is making an advertisement without having 
> received an advertisement that would justify it or any indication that B 
> is willing to accept the traffic that way.

Actually, it is policy. Routing finds loop free paths. Policy determines 
which of those loop free paths should, or should not, be used. If we delve 
into the policy arena in some places (like here), then we need a good 
reason not to delve into it in all the other places.

In fact, I'll turn your example around a bit, and show how this is 
specifically a policy issue. Suppose B also advertises the /24 to both A 
and C. This is common enough, and smart, if you actually want your traffic 
to continue flowing when one of your two SP's fails.

Now, for whatever reason, C decides not to readvertise the /25, but only 
the /24. What path is the traffic coming from beyond A and C going to take? 
Possibly A, correct? Isn't this also against B's policy? Yet, how would you 
address this?

Now, _if_ I were going to address this as a requirement, I would do so with 
wording something like this:

-- Any proposed security system SHOULD be able to express policies 
indicating a specific autonomous system should not be transited for any 
given destination. Note there is no way to gaurentee such a policy would be 
followed.

Or something like that. We then need to justify why, exactly, we don't want 
to cover other policies that may come up when discussing other possible 
cases.

> Note that the traffic will get there.  And the traffic is following the 
> announced AS_PATH.  And the AS_PATH advertised will "correspond to a 
> verifiable list of autonomous systems based on the peering topology of 
> the network."

Precisely. Routing finds loop free paths. BGP also happens to allow the 
local application of policy, and possibly allows an AS to influence the 
policy of adjacent AS'. Those influences are not gaurenteed to "work." 
Sometimes they will, sometimes they won't. Once you have the route, it's 
your policy that counts, though you might be nice, and allow your 
neighbor's policy to influence you.

:-)

Russ

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

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 14 Mar 2005 12:54:20 +0100

<snip>

> given destination. Note there is no way to gaurentee such a policy would be

I don't see this as anything to do with security.  If you said

-- Any proposed routing system SHOULD be able to express policies ...

I would agree with you but the problem here seems to me that BGP (as in I-D
bgp4-26) cannot express the policies that operators want, so operators break
that specification and stretch it beyond what seems reasonable.  And now, you
want a security system to sanction that:-)

Sandy's Operator post listed some dubious practices with the question should
security not stop them.  The discussion has exposed more dubious practices but
the question remains for me, should we not stop them, not should we enforce
them.  They remain dubious practices.

Tom Petch

---

From: Russ White <[email-masked]>
Date: Mon, 14 Mar 2005 08:51:03 -0500 (Eastern Standard Time)

> I would agree with you but the problem here seems to me that BGP (as in 
> I-D bgp4-26) cannot express the policies that operators want, so 
> operators break that specification and stretch it beyond what seems 
> reasonable.  And now, you want a security system to sanction that:-)
>
> Sandy's Operator post listed some dubious practices with the question 
> should security not stop them.  The discussion has exposed more dubious 
> practices but the question remains for me, should we not stop them, not 
> should we enforce them.  They remain dubious practices.

Well, we could argue about/discuss every possible policy all day, but I 
tend to think this specific one, the ability to indicate if an AS should or 
should not be used as transit, tends to be common, and one that people 
expect BGP to be able to do (though it can't gaurentee it in the way many 
people seem to think it can).

I can't think of many others that I would try to get into securing--it's a 
huge black hole....

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Mar 2005 09:59:31 -0500

At 10:36 PM -0500 3/11/05, Russ White wrote:
>>more specifics for the rest to C.  (Maybe it is load balancing, 
>>maybe there are performance advantages to C's connection for the 
>>specific application running on the addresses it sends to C, etc.)
>
>Yes, but, from a routing perspective, this is perfectly valid. The 
>path exists, and is loop free.

Russ,

Being a physically extant path and loop free does not necessarily 
make the path "valid." If we agree that BGP is used by ASes to 
communicate what traffic they want to flow to/through them, then for 
a path to be called "valid" it should accurately reflect what as AS 
has advertised.

>>decide what A should have done.  A is making an advertisement 
>>without having received an advertisement that would justify it or 
>>any indication that B is willing to accept the traffic that way.
>
>Actually, it is policy. Routing finds loop free paths. Policy 
>determines which of those loop free paths should, or should not, be 
>used. If we delve into the policy arena in some places (like here), 
>then we need a good reason not to delve into it in all the other 
>places.

BGP, as characterized in the RFC, is about more than just the 
propagation of loop free paths, so this seems to be an unduly narrow 
characterization. BGP specifically communicates policy, through route 
advertisements.

The issue you seem to be raising in you message is whether we should 
adopt new protocols and infrastructure to communicate additional 
policy data in an out of band fashion. that's a fair question to ask, 
but it essentially says that BGP does not do an adequate job relative 
to its own, stated goals, and needs to be augmented.

Steve

---

From: Russ White <[email-masked]>
Date: Mon, 14 Mar 2005 10:13:15 -0500 (Eastern Standard Time)

> Being a physically extant path and loop free does not necessarily make 
> the path "valid." If we agree that BGP is used by ASes to communicate 
> what traffic they want to flow to/through them, then for a path to be 
> called "valid" it should accurately reflect what as AS has advertised.
>
>> 
>>> having received an advertisement that would justify it or any 
>>> indication that B is willing to accept the traffic that way.
>> 
>> which of those loop free paths should, or should not, be used. If we 
>> delve into the policy arena in some places (like here), then we need a 
>> good reason not to delve into it in all the other places.
>
> BGP, as characterized in the RFC, is about more than just the propagation 
> of loop free paths, so this seems to be an unduly narrow 
> adopt new protocols and infrastructure to communicate additional policy 
> data in an out of band fashion. that's a fair question to ask, but it 
> essentially says that BGP does not do an adequate job relative to its 
> own, stated goals, and needs to be augmented.

Most of the policy you are discussing isn't implemented in the AS Path, 
however, it's in communities, local pref, and med--which are all the things 
we _aren't_ looking at. Policy based on as path is normally either a 
"hack," or perhaps something done with your immediate peer.

I actually think the wording I've suggested doesn't imply any sort of 
external system, and also covers the AS Path based concepts nicely....

:-)

Russ