|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical 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
|