On 2010-04-04, Eugene Yunak <e.yunak@gmail.com> wrote:
quoted text
> On 4 April 2010 18:56, Pete Vickers <pete@systemnet.no> wrote:
>> On 31. mars 2010, at 20.01, Claudio Jeker wrote:
>>
>>> On Wed, Mar 31, 2010 at 08:08:01PM +0300, Eugene Yunak wrote:
>>>> On 31 March 2010 19:27, N. Arley Dealey <arley.dealey@gmail.com> wrote:
>>>>> It would appear to me that antispoof and URPF achieve similar results. Is
>>>>> there a reason to prefer one over the other?
>>>>
>>>> Not at all. antispoof blocks ip packets that came in from the wrong
>>>> interface, while URPF blocks packets from "aliens" (no entry in
>>>> routing table for the source address). Just look at the output of
>>>> pfctl -sr
>>>>
>>>
>>> Not at all. URPF does not only check if a route exists it also checks that
>>> the route is pointing to the interface the packet came in.
>>>
>>> Antispoof is only for the LAN while URPF is actually capable of tracking
>>> stuff further down. This is at the same time the problem of URPF if you
>>> have asymetric routing URPF fails. Antispoof works in this case since it
>>> is hard to get asymetric routing on the LAN.
>>>
>>> --
>>> :wq Claudio
>>>
>>
>>
>> uRPF (at least recent incarnations of it) can be /configured/ to drop packets
>> based of presence of /either/ :
>>
>> - a matching FIB prefix outbound on the same interface the packet arrived on
>> (strict mode)
>> - a matching FIB prefix outbound on any interface (loose mode)
>>
>> you can also mask uRPF effect to only a subset of packets/prefixes with an
>> ACL.
>>
>>
>> pretty extensive explanation here:
>>
>> http://www.cisco.com/web/about/security/intelligence/urpf.pdf
>>
>
> Do you realise that this is an OpenBSD mailing list, and we are
> discussing OpenBSD's pf implementation of uRPF?

It's still relevant.

PF has the things Pete specifically mentioned:

- loose mode: use 'no-route' for this
- ACLs, well you just restrict the rule operation:

block in urpf-failed
pass in from 1/8

But we don't have a few things discussed in the document which
might be useful:

- option to use an alternative table in the urpf/no-route lookup

- drop incoming packets where the route lookup yields a blackhole/reject
route (the 'If the adjacency of a route equals Null0...' enhancement).
this is really nice, it lets you inject a route tagged with some community,
have an associated 'match...set nexthop blackhole' in bgpd.conf, then you
would be able to drop traffic *sourced* from that address at all your
borders, without some special way to sync PF tables around.