ISP port blocking practice
dts at senie.com
Fri Sep 3 03:04:54 UTC 2010
Ingress filtering is the correct tool for the job. The whole point here is that packets are coming from somewhere they should not, and they are thus spoofed. The tools have been in place to deal with this for a very long time now. The drafts that became RFC 2267 (precursor of RFC 2827 / BCP38) date from mid-1996. Paul and I wrote the original drafts to solve something else, but the issue is the same. Solving the vector you're concerned about doesn't need another layer of implementation in the mail servers. The packet routing fabric needs to handle it, and doing so addresses far more than just the email situation. I agree it'd be nice to get the asymmetric attack stopped, but disagree we need yet another mechanism to do it.
On Sep 2, 2010, at 10:55 PM, Zhiyun Qian wrote:
> I skimmed through these specs. They are useful but seems only related specific to IP spoofing prevention. I see that IP spoofing is part of the asymmetric routing story. But I was more thinking that given that IP spoofing is not widely adopted, the other defenses that they can more perhaps more easily implement is to block incoming traffic with source port 25 (if they already decided to block outgoing traffic with destination port 25). But according to our study, most of the ISPs didn't do that at the time of study (probably still true today).
> On Sep 2, 2010, at 9:20 PM, Suresh Ramasubramanian wrote:
>> BCP38 / RFC2827 were created specifically to address some quite
>> similar problems. And googling either of those two strings on nanog
>> will get you a lot of griping and/or reasons as to why these aren't
>> being more widely adopted :)
>> On Fri, Sep 3, 2010 at 7:47 AM, Zhiyun Qian <zhiyunq at umich.edu> wrote:
>>> Suresh, thanks for your interest. I see you've had a lot of experience in fighting spam, so you must have known this. Yes, I know this spamming technique has been around for a while. But it's surprising to see that the majority of the ISPs that we studied are still vulnerable to this attack. That probably indicates that it is not as widely known as we would expect. So I thought it would be beneficial to raise the awareness of the problem.
>>> In terms of more results, the paper is the most detailed document we have. Otherwise, if you interested in the data that we collected (which ISPs or IP ranges are vulnerable to this attack). We can chat offline.
More information about the NANOG