Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: SYN spoofing

  • From: Daniel Senie
  • Date: Wed Jul 28 14:06:33 1999

Joe Shaw wrote:
> 
> Any provider who allows the passing of address space that isn't his own
> (beyond whatever transit they may provide to their peers) is shameful.
> 
> How hard is it really to put a filter on your outbound links that says
> drop all ip traffic heading out these links that isn't from my IP space?
> It's just like martian filters for your inbound links, and we'd see a
> significant decrease in spoofing based attacks if it was more widely
> adopted.  Not to mention it'll keep peers from dumping traffic on you.

When RFC 2267 was a draft, and since its publication, there have been a
variety of comments that the routers in place couldn't do ingress
filtering at an acceptable rate without impacting traffic flows. The
hope was that vendors would consider this in future designs, and some
appear to have done so.

I suspect most deployed routers do at least some filtering of packets on
most or all interefaces. In the past, some routers couldn't do these
lookups efficiently on source addresses, but that's really an
implementation issue. It's *possible* to design hardware that can handle
it, if there's a business case for doing so. ISPs should be interested
in doing such filtering.

Dialup server vendors have implemented the ability to push filters into
dialup ports. This facility should be used by those offering dialup
pools to ensure packets arriving on a dialup port have a source IP
address that matches the address the server gave to the user in the PPP
IPCP exchange. There are exceptions (LAN dialup) where this won't work,
which is why control of these filters must be available from a Radius
(or equivalent) server, and applied or not on a per-user basis.

Cisco implemened a feature called "Unicast RPF" That disallows
forwarding of packets on an interface where a reverse path is not
present. The command to activate it is:

	ip verify unicast reverse-path

and according to Paul Ferguson (co-author of RFC 2267) it's in use by
many ISPs. Apparently this is very-low overhead. Paul has also indicated
the use of extended access lists on Cisco routers is very low overhead,
especially on routers using distributed express forwarding.

Perhaps RFC 2267 should at some point be promoted to a BCP. There was
some discussion about this a few months ago. Whether promotion to BCP
status would entice more network providers to use the facilities or not
is unclear.

-- 
-----------------------------------------------------------------
Daniel Senie                                        dts@senie.com
Amaranth Networks Inc.            http://www.amaranthnetworks.com





Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.