|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: unicast RPF for peers viable?
As one of the key people pushing uRPF .... uRPF 'Strict Mode' was never ever designed to put on the ISP peering links. It was created to help ISPs scale BCP 38 filtering on the ISP-Customer edge. Knock out the easy 80% of the customers who are simple single homed customers - leaving the other 20% for special BCP38 uRPF/BGP or ACL configs. uRPF 'Loose Check' was designed for any part of the edge - ISP to ISP (could be customer or peer); the ISP to Customer edge; or the ISP to Multihomed edge. The objective was to provide a quick way to trigger a network wide source address based black hole. It also provides an effective way to filter source addresses with martian and bogons (i.e. addresses not in the FIB). So consider uRPF Loose Check as a source address based "noise reduction" filter and a network wide DDOS counter measure. So people need to get the two straight. The are completely different: uRPF Strict Mode for BCP 38 (not for ISP-ISP Peering links) Cisco: ip verify unicast source reachable-via rx Juniper (as of 5.3): unicast-reverse-path active-paths uRPF Loose Check Mode (suitable for ISP-ISP Peering Links) Cisco: ip verify unicast source reachable-via any Juniper (as of 5.3): unicast-reverse-path feasible-paths So you need to frame you response as to the appropriate uRPF mode. One key reminder - uRPF is just another security tool for an ISP's security tool kit. There is no such thing as a perfect security tool. A craftsman is known not for his/her tools, but how well they use the tools they got to perform their art. Barry > -----Original Message----- > From: [email protected] [mailto:[email protected]]On Behalf Of > Iljitsch van Beijnum > Sent: Sunday, May 05, 2002 3:11 AM > To: Christopher L. Morrow > Cc: [email protected] > Subject: unicast RPF for peers viable? > > > > On Sun, 5 May 2002, Christopher L. Morrow wrote: > > > I was hoping someone else might mention this, BUT what about the case of > > customers providing transit for outbound but not inbound > traffic for their > > customers? We have many, many cases of customers that are 'default > > routing' for their customers that get inbound traffic down alternate > > customers or peers or wherever... uRPF seems like a not so good solution > > for these instances :( especially since some of these are our worst > > abusers :( > > This dilemma has far reaching repercussions: > > If _you_ allow this and forego the unicast RPF check for these customers, > this means your peers can't do uRPF towards you without breaking > connectivity for these customers. > > In a perfect world, there would be no need to do uRPF on peering > interfaces, because peers make sure they don't send packets with spoofed > source addresses. Unfortunately, in the real world many networks STILL > don't bother and thereby allow hard to trace and filter DDoS attacks to be > launched from inside their networks. > > So what is the collective wisdom on the NANOG list? Is uRPF on peering > interfaces a viable option and if it breaks esoteric customer > configurations, too bad; or is it something that should be discouraged > because it breaks legitimate customer needs? > > If you feel strongly one way or the other, but don't want to join the > discussion, please reply with a "yes to peering uRPF" or "no to peering > uRPF" in private email, and I'll summerize to the list. > > Iljitsch van Beijnum > >
|