ISP port blocking practice

Sat Oct 24 02:54:28 UTC 2009

On Oct 23, 2009, at 3:43 PM, Justin Shore wrote:

> Dan White wrote:
>> On 23/10/09 17:58 -0400, James R. Cutler wrote:
>>> Blocking the well known port 25 does not block sending of mail. Or  
>>> the
>>> message content.
>> It does block incoming SMTP traffic on that well known port.
>
> Then the customer should have bought a class of service that permits  
> servers.
>
Then you shouldn't be marketing what the customer bought as "Internet  
Access".

>>> I think the relevant neutrality principle is that traffic is not  
>>> blocked
>>> by content.
>> My personal definition doesn't quite gel with that. You're deciding  
>> for the
>> customer how they can use their connection, before you have any  
>> evidence of
>> nefarious activity.
>
> They decided for themselves when they bought a residential  
> connection instead of a business circuit.  Just because someone  
> bought themselves a Camry doesn't mean that Toyota is deciding for  
> them that they can't haul 1000lbs of concrete with it.  The customer  
> did when they decided to buy a car and not a pickup.
>
Toyota does not market the Camry as a load hauling truck.

If you are marketing your service as "Residential access to the part  
of the internet
that we think is appropriate for a residence", then, I suppose that's  
fine.  If you're
calling it "Internet Access", then, you're claiming to sell a truck  
when you are
delivering a Camry.  It's a very different comparison.

>> Would you consider restricting a customer's outgoing port 25  
>> traffic to a
>> specific mail server a step over the net neutrality line?
>
> I do this all the time.  For example I don't let my customers send  
> or receive mail (or any traffic for that matter) from prefixes  
> originating from AS32311 (Colorado spammer Scott Richter).  Now if I  
> was blocking mail to dnc.org, gop.com, greenpeace.org, etc or  
> restricting Vonage to .05% of my bandwidth then yeah that would  
> violate net neutrality principles.  The difference is one stifles  
> speech and is anti-competitive.  The other mitigates a network  
> security and stability risk.
>
I actually admit that I don't have a problem with you blocking traffic  
entering your peering connections from a known SPAM-AS.  That is, as  
you state, a network security issue.

OTOH, filtering what I, as a customer, send/receive at my end without  
my consent is a different issue.

> I see this same argument on Slashdot all too often.  It's usually  
> bundled with an argument against providers doing any sort of traffic  
> aggregation ("if I buy 1.5Mbps then it should be a dedicated pipe  
> straight to the Internet!")  Unfortunately that's simply not  
> reality. You can either live with a small level of controls on your  
> traffic for the sake of stability and security or you can have wide- 
> open ISPs with no security prohibitions whatsoever.  The support  
> costs for the ISPs go through the roof and of course that gets  
> passed onto the customer.  Your 5 9s SLA gets replaced with "use it  
> while you can before it goes down again".  Everyone pays a penalty  
> for having a digital Wild West.  Not to start another thread on a  
> completely OT topic but the same concept can be applied to other  
> things like health care.  Either everyone can pay a little bit for  
> all to have good service or many average consumers can pay lots to  
> make up the losses for those that can't pay at all.
>
Yeah, I don't buy the aggregation issue.  That's absurd (Of course you  
can stat mux the traffic, that's
what makes packet switched networks cost effective and gives us that  
great residential pricing)

I don't buy the argument that you have to filter your customers to  
keep your support costs down.
I've worked for a number of ISPs that don't filter their customers'  
traffic and don't have astronomical
support costs or even heavy support call volume.

We're not dumb enough to push a 5 9s SLA at residential prices, but,  
I'd say we're probably closer
to 4 9s than 3.

Owen