[c-nsp] URPF MAC check

[Tóth András]

I don't see the benefit because L2 address is only visible until your
next-hop, it does not validate the original sender which might be several
hops away. Also, MAC addresses are easily spoofable.

DoS attacks? Most often come from a spoofed source IP, so why wouldn't they
spoof the MAC as well (in case it's a DoS coming from a directly connected
network)? If coming from directly connected network, you can just consult
netflow/interface stats to see where is it coming from.

Additionally this would break HSRP which is certainly not common in IX
environments, but in theory having the virtual MAC in your ARP table would
cause legitimate traffic coming from the physical MAC being dropped.

Andras


On Fri, Nov 23, 2012 at 12:15 PM, Aled Morris <aledm at qix.co.uk> wrote:

> On 23 November 2012 11:06, Dobbins, Roland <rdobbins at arbor.net> wrote:
>
> >
> > On Nov 23, 2012, at 5:49 PM, Aled Morris wrote:
> >
> > > It would be handy if URPF could use both the L3 FIB (as it does now)
> and
> > the L2 ARP table to validate source addressess
> >
> > I guess I don't understand what you mean by this . . .
> >
> > Regarding some combination of layer-2 and layer-3, how would your box
> have
> > prior knowledge of what path(s) packets are going to take through the
> > Internet to reach the given interface on your box?
> >
>
> When URPF has a packet, it checks the L3 forwarding table to get the L3
> next hop for the given packet's source IP address.
>
> What I'm suggesting is that it would then use the ARP table for that L3
> next hop IP address to further validate the packet in hand.
>
> Does that explain what I am trying to ask for?
>
> Aled
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>