[j-nsp] out-bound anti-spoofing rules when using community-based routing

[Pekka Savola]

On Fri, 25 Jan 2008, David Ball wrote:
>   Pekka, I'm not sure I caught why your example of a BGP customer
> advertising an aggregate to us but the specifics to another upstream
> wouldn't work.  If 'feasible-paths' is in use, doesn't that alleviate
> the problem?  Even if the 'preferred' path is not their local port, we
> should still have the aggregate which should pass the uRPF check, no?

No, feasible paths won't help in that case.

If:
  - your customer advertises a prefix P with mask n (P/n)
  - you get the same prefix P/n from some other source (e.g., your peer 
network or customer's another interface), and that route is preferred.
  - your customer-facing router receives the preferred advertisement

In this scenario:
  - without feasible paths, your router would reject all traffic 
(because your peer-learned route is active and your customer-learned 
route is not)
  - with feasible paths, your router would accept traffic from P/n from 
the customer because even though the customer-learned path is 
inactive, it's still considered "feasible" and uRPF accepts it.

Now, if you get more specifics of P/n from your peer, that's a 
different route compared to the aggregate.  If you don't learn the 
same more specific route from the customer, all customer's traffic 
from that more specific prefix gets dropped.  This is because your 
router will think that the correct direction to the more specific is 
to your peer network, not the direct connection to customer.

You can think of this as "longest prefix matching wins every time, if 
you have the same prefixes with the same length, you select one and 
the rest are considered feasible".

RFC 3704 section 2.3 tries to explain this but probably doesn't make 
it much better than above.

HTH,

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings