ISP port blocking practice

Steve Bertrand steve at
Fri Oct 23 04:40:12 UTC 2009

Jon Kibler wrote:
> Zhiyun Qian wrote:
>> Hi all,
>> What is the common practice for enforcing port blocking policy (or what
>> is the common practice for you and your ISP)? More specifically, when
>> ISPs try to block certain outgoing port (port 25 for instance), they
>> could do two rules:
>> 1). For any outgoing traffic, if the destination port is 25, then drop
>> the packets.
>> 2). For any incoming traffic, if the source port is 25, then drop the
>> packets.
>> Note that either of the rule would be able to block outgoing port 25
>> traffic since each rule essentially represent one direction in a TCP
>> flow. Of course, they could apply both rules. However, based on our
>> measurement study, it looks like most of the ISPs are only using rule
>> 1). Is there any particular reason why rule 1) instead of rule 2)? Or
>> maybe both?
>> Also, is it common that the rules are based on tcp flags (e.g. SYN,
>> SYN-ACK)? One would think block SYN packet is good enough.
>> Regards.
>> -Zhiyun
> I understand your question, and I believe that you have been given a lot of good
> answers. However, I believe that, as an ISP, you are asking the wrong question;
> more precisely, you are only asking part of the real question you should be
> asking. The more appropriate question should be: "What should be our network
> filtering policies?"
> To answer that question, I would start with ingress and egress filtering by IP
> address, protocol, etc.:
>    1) Never allow traffic to egress any subnet unless its source IP address is
> within that subnet range.

Sorry to nit, but shouldn't your uRPF setup take care of this (and many
other of your list items), long before ACL?

It's absolutely great if you have your list implemented, but imho, all
ISP's, no matter how small should investigate and implement urpf. It's
especially fun to play with RTBH.

To be honest, the smaller you are, the easier it is to implement (ie.
urpf strict everywhere!  :)


More information about the NANOG mailing list