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

From: Sandy Murphy <[email-masked]>
Date: Mon, 14 Mar 2005 12:01:54 -0500 (EST)

>> Another example which the peering topology check doesn't catch (I think):
>>
>>
>>      A     C
>>
>
>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.

That is where we don't agree.  I do not consider this to be a path
that exists.  Certainly the peering adjacencies exist, but as we
all know, the existence of a peering does not ensure that the traffic
will pass.  The BGP advertisements, according to the spec, are supposed
to indicate that the speaker has a route to the prefix advertised.
Not just a peering relationship with the other AS.  If that were
all that BGP promised, then the messages could carry a whole lot less
information.

To better indicate the point, expand the graph a bit:

           B
          / \
         /   \
        A1    C
       /
      A2

Suppose that A1 advertises 10.1.1.0/25 to A2, but A2 is the one
that messes up and announces both 10.1.1.0/25 and 10.1.1.128/25.
A2 may have forwarding set up to forward 10.1.1.128/25 to A1, but
A1 surely doesn't have a forwarding set up for 10.1.1.128/25.
A2's advertisement passes the origination test and the peering
topology test and the "advertising the route it uses" test.

But the prefix isn't "reachable" because the advertised route doesn't
can't and won't forward traffic.

--Sandy

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

---

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

> will pass.

You can't gaurantee this, under any circumstances. You have to separate 
routing from forwarding in your mind.... One builds a graph, the other 
actually sends the traffic.

If packet networks always sent information only across the path listed in 
the routing database, packet networks would never have been invented in the 
first place. That's the _point_ of a hop-by-hop packet network. To route 
around problems on the fly (and notice I've not once discussed failure 
modes in anything we've discussed so far, just normal operation).

The point is to get the packet one hop closer to the destination, and let 
the next hop, with presumably more knowledge than I have, choose the next 
best hop, and so on, until the packet reaches its destination. No matter 
what happens to the network, and no matter what I think about the path the 
packet should take, the packet gets there. That's the point.

Many years ago, we had pure circuit switched networks with the property of 
always sending traffic along a predetermined path. We've abandoned those 
for packet switched networks, and for a lot of good reasons. Now, we either 
have to try and convert packet switched networks into circuit switched 
networks, in order to "secure" them in some abstract sense, or we have to 
live within what's possible in a packet switched network--including that we 
can't know, for certain, when we forward a packet, which way it's going to 
take to get to the destination. We can try to _influence_ this path, but we 
can't gaurantee it, hence it's policy, not circuit setup.

> The BGP advertisements, according to the spec, are supposed to indicate 
> that the speaker has a route to the prefix advertised.

Yes, exactly. Not what the path is, only that a path exists. That's it, 
nothing more. I think we're hanging way too much on the AS Path here.

Don't hang too much on the path, it's just not that strong of a peg, IMHO.

:-)

Russ

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