Re: BLS FastAccess internal tech needed
RFC2827/BCP38? - ferg -- Suresh Ramasubramanian <ops.lists@gmail.com> wrote: [snip] What they're *trying* to do is actually quite sensible, and beats spammers trying to do asymmetric routing / source address spoofing type stuff [snip] -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg@netzero.net or fergdawg@sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/
On Fri, 13 Jan 2006, Fergie wrote:
RFC2827/BCP38?
not exactly... though most likely 2827 would have helped. Our abuse folks called it 'fantasy mail' ... Spammer signs up for 'fast' link with someone, uses a farm of juno dial (or netzero or... you get the point) accounts to make a large number of machines dial out and start sending email as the dial-up IP out the 'fast' link. This was painful for a while, radius applied filters fix it now.
- ferg
-- Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
[snip]
What they're *trying* to do is actually quite sensible, and beats spammers trying to do asymmetric routing / source address spoofing type stuff
[snip]
-- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg@netzero.net or fergdawg@sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/
In message <20060112.195851.1587.15308@webmail05.lax.untd.com>, "Fergie" writes :
RFC2827/BCP38?
The problem is that an ISP can do all the source filtering it wants, but if it only blocks SYNs to port 25 all it takes is one unfiltered dial-up to spoof that ISP's addresses. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
On Thu, Jan 12, 2006 at 11:09:13PM -0500, Steven M. Bellovin wrote:
RFC2827/BCP38?
The problem is that an ISP can do all the source filtering it wants, but if it only blocks SYNs to port 25 all it takes is one unfiltered dial-up to spoof that ISP's addresses.
On the subject of filtering and IP spoofing... In the past year, our spoofer project has collected nearly 1200 unique reports from across the Internet and we have an interesting, if not wholly representative, dataset. The latest version of our spoofer tester includes a number of new features that may be interesting to the community. One particular new feature is the ability to determine where along a tested path filtering is employed with what we're calling a "reverse traceroute" mechanism [1]. Knowing the "filtering depth" is of particular interest to us since there is an operational tension between the specificity of router-level filters and the ability to properly maintain them. We also test fun stuff such as how far into the adjacent neighbor address space the client can spoof, filtering inconsistencies, etc. We'd appreciate any runs of the spoofer tester to help us gather additional data. The client, details of the reverse traceroute as well as our "State of IP spoofing" summary results are all the web page: http://spoofer.csail.mit.edu/ Thanks, rob [1] The idea for the reverse traceroute arose from a fruitful discussion with John Curran.
participants (4)
-
Christopher L. Morrow -
Fergie -
Robert Beverly -
Steven M. Bellovin