sean@donelan.com (Sean Donelan) writes:
If there is a magic solution, I would love to hear about it.
Unfortunately, the only solutions I've seen involve considerable work and resources to implement and maintain all the "exceptions" needed to do 100% source address validation.
I had no idea this was so hard. I guess the people who maintain AS3557 (or AS6461 for that matter) do such a job of making this _look_ easy that I just naturally thought it _was_ easy. Forgive my simple minded approach, if it really is simple minded, but... any given interface or peering session or whatever is either customer facing, peer/transit facing, or a trunk which leads ultimately to more customer AND more peer/transit facing interfaces elsewhere in the network. On customer-facing connections, there's a short list of things they should be allowed to say as IP source addresses. (They might be multihomed but chances are low that you want them giving transit to other parts of the network through you, no matter whether you do usage sensitive billing or not.) On transit/peer facing connections, there's a short list of things they should NOT be allowed to send from (your own customers, chiefly) and a short list of things you should NOT be allowed to send them from (RFC1918 being the big example.) Because F-root's network operator was filtering out inbound RFC1918-sourced packets, I could only see them at C-root. Now, F-root can also see them, so I can once again collect stats from (and complain about stats from) both. RFC1918 routes are allowed to float around inside AS3557, by the way, since "customers" use them for VPN purposes. So we don't filter out ingress 1918 from customer-facing interfaces; instead we filter out egress 1918 toward our peers/transits. Like I said, I had no idea this was generally thought to be so complicated. -- Paul Vixie