Re: URPF on small BGP-enabled customers?
I guess it's been a while since I've played with it, but isn't this pretty well what happens with uRPF anyhow? 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@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@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.
christian.macnevin@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@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@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.
On 2005-06-03, at 10:26, Andre Oppermann wrote:
christian.macnevin@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.
So, your proposal is loose-mode uRPF?
Joe Abley wrote:
On 2005-06-03, at 10:26, Andre Oppermann wrote:
christian.macnevin@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.
So, your proposal is loose-mode uRPF?
I thought that loose-mode uRPF is what was recommended for any connected entity that is multi-homed. And that makes sense. What happened to that? Whats next? uRPF in core? At which point do we stop breaking things? There must be a safe way to solve the problem of spoofing routed space without breaking multi-homing.
Andre Oppermann wrote:
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).
And my proposal works as long as the customer advertises their prefixes via BGP, with the added caveat that ACLs don't have to be updated (i.e. uRPF works and is used). I'd have to re-check my customer-side route maps, but I think they'll open the uRPF for all possible permutations of <community>. pt
participants (5)
-
Andre Oppermann -
christian.macnevin＠uk.bnpparibas.com -
Joe Abley -
Joe Maimon -
Pete Templin