URPF on small BGP-enabled customers?

Fri Jun 3 14:26:16 UTC 2005

christian.macnevin at uk.bnpparibas.com wrote:
> I guess it's been a while since I've played with it, but isn't this pretty
> well what happens with uRPF anyhow?

No, my proposal works as long as the customer advertizes their prefixes
via BGP, not matter how long the path or what community attributes are
set (for example NOEXPORT).  No matter how they send it, as long as they
send it, it works fine.  Unlike uRPF which depends on exactly this path
being the best path of all path available.  All this trouble of routing
decisions which affect uRPF is avoided.  That is also why it feeds the
received prefixes into an ACL which then is applied to the interface
versus doing two FIB lookups (one on source IP and one on destination
IP).

-- 
Andre

> The asymmetric routing problem is illustrated ascii stylee below.
> 
>           AS1
>          /
>      ASYOU  -    AS-OTHERGUY
>                \                 /
>            CUSTOMER
> 
> Say somebody in AS1 wants traffic from your customer. The request comes in
> through you, and to your customer. For whatever reason (internet exchange
> peering is more attractive to the customer, whatever - the point is, ignore
> the AS-path, because the customer has fiddled with their traffic - ie:
> always follow the money) their return traffic is going via AS-OTHERGUY.
> Their shortest path to AS1 is through you, so they throw the return traffic
> your way. Of course, your routing table resolves the best path for all
> customer routes to AS-CUSTOMER, so it drops all traffic coming in from
> AS-OTHERGUY.
> 
> I don't think your solution would fix that, as AS-OTHERGUY's announcements
> would have a longer AS-path than your direct peering with the customer.
> 
> (I reserve the right to be totally wrong and have completely misunderstood
> all mechanisms involved, btw ;) )
> 
> 
> 
> 
> 
> Internet
> nanog-list at nrg4u.com - 03/06/2005 14:58
> 
> 
> To:    Christian MACNEVIN
> 
> cc:    christopher.morrow, will, nanog
> 
> 
> Subject:    Re: URPF on small BGP-enabled customers?
> 
> 
> christian.macnevin at uk.bnpparibas.com wrote:
> 
>>At an old transit provider I was at, we had a pig of a time dealing with
>>uRPF. It doesn't like asymmetric routing at all, which is commonplace
> 
> when
> 
>>you've got customers homed at exchange points for one.
> 
> 
> This is why I say there should be a feature that will work like a dynamic
> ACL but is fed from BGP.  All the prefixes you learn from customer A via
> BGP are put into an automatic ACL, default is deny.  Then you apply this
> dynamic ACL to the interface the customer is connected to.  Of course it
> still doesn't work if you send traffic from prefixes you don't announce but
> for 70-80% of the cases it's a big step forward in automation.  This also
> gets rid of any differences between ACL on the forwarding plane and on the
> routing protocol plane.  All prefix filters are defined in BGP
> configuration.
> Forwarding layer follows and never gets out of sync again.
> 
> Random example syntax:
> 
>   router bgp 65500
>     neighbor 192.168.2.2 remote-as 65501
>     neighbor 192.168.2.2 dynamic ACL 10001 receive  #put received prefixes
>     here
>     neighbor 192.168.2.2 prefix-list CUST65501
>     ... #usual stuff
> 
>   #only this one is controlled
>   ip prefix-list extended CUST65501
>     permit ip 172.16.0.0/16 any
>     permit ip 10.0.0.0/8 any
> 
>   #ACL on interface follows BGP received prefixes
>   interface f0/0/0
>     ip access-group 10001 in  #same as in BGP neighbor config
> 
> 
> And Voila!  Problem automagically solved.
> 
> --
>  Andre
> 
> 
> 
> 
> 
> This message and any attachments (the "message") is 
> intended solely for the addressees and is confidential. 
> If you receive this message in error, please delete it and 
> immediately notify the sender. Any use not in accord with
> its purpose, any dissemination or disclosure, either whole 
> or partial, is prohibited except formal approval. The internet 
> can not guarantee the integrity of this message. 
> BNP PARIBAS (and its subsidiaries) shall (will) not 
> therefore be liable for the message if modified. 
> 
> **********************************************************************************************
> 
> BNP Paribas Private Bank London Branch is authorised 
> by CECEI & AMF and is regulated by the Financial Services
> Authority for the conduct of its investment business in the
> United Kingdom.
> 
> BNP Paribas Securities Services London Branch is authorised
> by CECEI & AMF and is regulated by the Financial Services
> Authority for the conduct of its investment business in the 
> United Kingdom.
>   
> BNP Paribas Fund Services UK Limited is authorised and 
> regulated by the Financial Services Authority.
> 
> 