[168851] in North American Network Operators' Group
Re: BCP38 is hard; let's go shopping!
daemon@ATHENA.MIT.EDU (Christopher Morrow)
Wed Feb 5 17:22:04 2014
In-Reply-To: <7852910.7306.1391636764901.JavaMail.root@benjamin.baylink.com>
Date: Wed, 5 Feb 2014 17:21:42 -0500
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Jay Ashworth <jra@baylink.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Wed, Feb 5, 2014 at 4:46 PM, Jay Ashworth <jra@baylink.com> wrote:
> ----- Original Message -----
>> From: "joel jaeggli" <joelja@bogus.com>
>
>> > As I've noted, I'm not sure I believe that's true of current generation
>> > gear, and if it *is*, then it should cost manufacturers business.
>>
>> There are boxes that haven't aged out of the network yet where that's an
>> issue, some are more datacenter-centric than others. force10 e1200 was
>> one platform that had this limitation for example.
>
> So making sure manufacturers are producing gear that's BCP38-compliant,
> and buyers have it on their tick-list, is still a productive goal, too.
but, if it's a datacenter deployment there are mitigations you can
perform aside from uRPF... right?
you COULD just use a simple acl on the interface: "my local network
is..." which you could even automate.
you COULD do dhcp-snooping/mac-locking/etc and ensure that the
end-host is only using the one address(es) it's permitted to use.
(potentially harder to do on some gear)
you COULD clamp the outbound path from edge-L3 box -> code with the
right acl, since you konw what traffic should come out of the local L3
edge piece.
the answer doesn't' have to be uRPF.
