BCP38 making it work, solving problems

Sean Donelan sean at donelan.com
Mon Oct 11 01:35:33 UTC 2004


On Sun, 10 Oct 2004, James Baldwin wrote:
> I agree that BCP 38 should be implemented. I agree that BCP 38 will
> have a greater affect on network abuse than port 25 filtering. They
> both have their place and address to partially overlapping groups of
> abuse imho.

Be conservative in what you send is an excellent philosophy.  And within a
product generation or two, vendor equipment will almost capable of
supporting it. Even Cisco has realized uRPF isn't a complete solution.
Cisco's marketing department came up with multiple differently named IP
sourceguard, Cable source verify, unicast reverse path filtering; which
confuses both technical and non-technical people.  But too many boxes
still crumble if you turn them on, if you are even able to turn them on.

But BCP38 doesn't immediately help the ISP.  Several ISPs have implemented
BCP38, and it has very little return on investment.  It actually has a
negative return because people are dumb.  People think BCP38 means the
packets could only originate from you.  In reality, BCP38 only helps you
with where the spoofed packets did NOT originate.  But people don't
complain to the source of spoofed packet.  People complain to IANA about
attacks coming from Net-10.  I know the Net-10 packets didn't originate
from me, but it doesn't mean the Net-64 packets did.

On the other hand, NAT, banning servers, blocking port 25, file sharing
bandwidth limits all have much faster return on investment from the ISP
point of view.  They may be more harmful in the longer term.  But even
your friends don't like it when you try to do the right thing.  Microsoft
removed "raw" sockets from XP SP2. Doesn't that make you feel safer?

I have received complaints from people about NOT being able to spoof
packets.




More information about the NANOG mailing list