Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: NANOG: users

ISP port blocking practice

 

 

First page Previous page 1 2 3 4 5 6 Next page Last page  View All NANOG users RSS feed   Index | Next | Previous | View Threaded


michael at linuxmagic

Oct 23, 2009, 9:11 AM

Post #26 of 126 (1035 views)
Permalink
Re: ISP port blocking practice [In reply to]

On October 23, 2009, Steve Bertrand wrote:
> http://eagle.ca/update/mail/Outlook_Express/index.html
>
> ...yes, believe it or not, even with the pictures, they will sometimes
> still get it wrong ;)
>
> Years in planning and implementation, but a good, large-scale learning
> exercise and the achievement of no port 25 that I'm very proud of.
>
> Steve
>

Congratulations, it would be nice if everyone got there, and we push all our
clients to adopt such a strategy, but it is always surprising how many still
fear.. change.. and the phone calls they fear may come from it.

We should all work to educate that in the end run, call volumes, and other
problems will be reduced.


--
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors - President/CEO - LinuxMagic
Products, Services, Support and Development
Visit us at http://www.linuxmagic.com
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-589-0037 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


steve at ibctech

Oct 23, 2009, 10:14 AM

Post #27 of 126 (1035 views)
Permalink
Re: ISP port blocking practice [In reply to]

Michael Peddemors wrote:
> On October 23, 2009, Steve Bertrand wrote:
>> http://eagle.ca/update/mail/Outlook_Express/index.html
>>
>> ...yes, believe it or not, even with the pictures, they will sometimes
>> still get it wrong ;)
>>
>> Years in planning and implementation, but a good, large-scale learning
>> exercise and the achievement of no port 25 that I'm very proud of.
>>
>> Steve
>>
>
> Congratulations, it would be nice if everyone got there, and we push all our
> clients to adopt such a strategy, but it is always surprising how many still
> fear.. change.. and the phone calls they fear may come from it.

Thanks.

The phone calls is what we 'feared' the most. For most things, I'm able
to come up with hackery/workarounds to enable change with no client
impact, but not in this case.

What we did was go on a massive PR campaign via email and web for nearly
two years while I ran both 587 and 25 in parallel. Also, (for the most
part), we'd have the users make the changes pro-actively during
unrelated calls.

Getting closer to the 'due date', I set up a in-band, on-the-side
network of sensors that monitored for port 25 traffic across the network
segments. The sensors had access to RADIUS and other systems that
automated the task of retrieving the username (or client ident of some
sort) who was using the IP in question during that time period. The
results would then be emailed to me.

Sometimes the support staff would make a few cold-calls here or there to
further knock down the list when things were slow.

Most of the domain hosting and non-resi clients have their own 'techs',
so they were pretty good.

Slowly but surely, I started blocking 25 on segments of the network. At
this point, I'd say that we had about 80% coverage.

On and after doomsday, the call volume wasn't overly bad (I think we had
6 staff at that time). Because we were very prepared (with the
handy-dandy pictorials), calls incoming were exceptionally short: "yep,
you can't send. Read this email we're about to send and you'll be good
to go". We of course impounded into their minds that "oh, you didn't
follow the instructions we've been sending for the last two years" for
good measure.

Collateral damage was minimalistic, but was quickly spotted via the
sensors. Adjustments were made, and here we are. I'd have no fear in
doing it again, now that I know what to expect :)

Although we have only ~10k access users and on top of that ~400 hosted
domains, I do believe that the effort can scale up to any scope, so long
as the proper preparations are made in advance.

I believe renumbering my network twice prior to that helped with keeping
me sensible and realistic in how I needed to prepare though.

Cheers,

Steve


lyndon at orthanc

Oct 23, 2009, 10:15 AM

Post #28 of 126 (1035 views)
Permalink
Re: ISP port blocking practice [In reply to]

> Rogers
> says they don't do that, and lots of other people seem to be able to
> use port 587 on Rogers (and other ISPs) without problems.

I'm in Calgary right now so I can't check the current behaviour, but
as of June 1st it was still broken. Broken in the sense that any
connection to port 587 would go through, but the AUTH lines in the
EHLO response get deleted. They're obviously hijacking the connections
through a broken proxy. And port 587 without AUTH is useless.

As for outright blockage of port 587, I get this complaint from many of
my clients while they are on the road. It seems hotels love to block it.

--lyndon


cboyd at gizmopartners

Oct 23, 2009, 1:49 PM

Post #29 of 126 (1030 views)
Permalink
Re: ISP port blocking practice [In reply to]

On Oct 23, 2009, at 12:15 PM, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:

> As for outright blockage of port 587, I get this complaint from many
> of
> my clients while they are on the road. It seems hotels love to block
> it.

I travel a bit (used to a lot) and only found one place that proxied
it. Never saw an outright block. A call to the support group
actually got if fixed in about 45 minutes. Call and complain if it's
broken. You are the customer at that point.....

--Chris


lriemer at bestline

Oct 23, 2009, 2:19 PM

Post #30 of 126 (1030 views)
Permalink
Re: ISP port blocking practice [In reply to]

Isn't blocking any port against the idea of Net Neutrality?

Justin Shore wrote:
> Owen DeLong wrote:
>> Blocking ports that the end user has not asked for is bad.
>
> I was going to ask for a clarification to make sure I read your
> statement correctly but then again it's short enough I really don't
> see any room to misinterpret it. Do you seriously think that a
> typical residential user has the required level of knowledge to call
> their SP and ask for them to block tcp/25, tcp & udp/1433 and 1434,
> and a whole list of common open proxy ports? While they're at it they
> might ask the SP to block the C&C ports for Bobax and Kraken. I'm
> sure all residential users know that they use ports 447 and 13789. If
> so then send me some of your users. You must be serving users around
> the MIT campus.
>
>> Doing it and refusing to unblock is worse.
>
> How you you propose we pull a customer's dynamically-assigned IP out
> of a DHCP pool so we can treat it differently? Not all SPs use
> customer-facing AUTH. I can think of none that do for CATV though I'm
> sure someone will now point an oddball SP that I've never heard of
> before.
>
>> Some ISPs have the even worse practice of blocking 587 and a few even
>> go to the horrible length to block 465.
>
> I would call that a very bad practice. I haven't personally seen a
> mis-configured MTA listening on the MSP port so I don't think they can
> make he claim that the MSP port is a common security risk. I would
> call tcp/587 a very safe port to have traverse my network. I think
> those ISPs are either demonstrating willful ignorance or marketing
> malice.
>
>> A few hotel gateways I have encountered are dumb enough to think they
>> can block TCP/53
>> which is always fun.
>
> The hotel I stayed in 2 weeks ago that housed a GK class I took had
> just such a proxy. It screwed up DNS but even worse it completely
> hosed anything trying to tunnel over HTTP. OCS was dead in the
> water. My RPC-over-HTTP Outlook client couldn't work either.
> Fortunately they didn't mess with IPSec VPN or SSH. Either way it
> didn't matter much since the network was unusable (12 visible APs from
> room, all on overlapping 802.11b/g channels). The average throughput
> was .02Mbps.
>
>> Lovely for you, but, not particularly helpful to your customers who
>> may actually want to use some of those services.
>
> I take a hard line on this. I will not let the technical ignorance of
> the average residential user harm my other customers. There is
> absolutely no excuse for using Netbios or MS-SQL over the Internet
> outside of an encrypted tunnel. Any user smart enough to use a proxy
> is smart enough to pick a non-default port. Any residential user
> running a proxy server locally is in violation of our AUP anyway and
> will get warned and then terminated. My filtering helps 99.99% of my
> userbase. The .001% that find this basic security filter intolerable
> can speak with their wallets. They can find themselves another
> provider if they want to use those ports or pay for a business circuit
> where we filter very little on the assumption they as a business have
> the technical competence to handle basic security on their own. (The
> actual percentage of users that have raised concerns in the past 3
> years is .0008%. I spoke with each of them and none decided to leave
> our service.)
>
> We've been down the road of no customer-facing ingress ACLs. We've
> fought the battles of getting large swaths of IPs blacklisted because
> of a few users' technical incompetence. We've had large portions of
> our network null-routed in large SPs. Then we got our act together
> and stopped acting like those ISPs who we all love to bitch about,
> that do not manage their customer traffic, and are poor netizens of
> this shared resource we call the Internet. Our problems have all but
> gone away. Our residential and business users no longer call in on a
> daily basis to report blacklisting problems. We no longer have
> reachability issues with networks that got fed up with the abuse
> coming from our compromised users and null-routed us. I stand by our
> results as proof that what we're doing is right. Our customers seem
> to agree and that's what matters.
>
> Justin
>
>
>


james.cutler at consultant

Oct 23, 2009, 2:58 PM

Post #31 of 126 (1029 views)
Permalink
Re: ISP port blocking practice [In reply to]

Blocking the well known port 25 does not block sending of mail. Or the
message content.

Blocking various well know M$ protocol ports does not block remote
file access. Or control the type of files that can be accessed.

I think the relevant neutrality principle is that traffic is not
blocked by content.

So, no, blocking any port is NOT against the idea of Net Neutrality.

On Oct 23, 2009, at 5:19 PM, Lee Riemer wrote:

> Isn't blocking any port against the idea of Net Neutrality?
>


James R. Cutler
james.cutler [at] consultant


dwhite at olp

Oct 23, 2009, 3:15 PM

Post #32 of 126 (1028 views)
Permalink
Re: ISP port blocking practice [In reply to]

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.

> 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.

Would you consider restricting a customer's outgoing port 25 traffic to a
specific mail server a step over the net neutrality line?

--
Dan White


justin at justinshore

Oct 23, 2009, 3:43 PM

Post #33 of 126 (1028 views)
Permalink
Re: ISP port blocking practice [In reply to]

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.

>> 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.

> 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 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.

Justin


james.cutler at consultant

Oct 23, 2009, 4:33 PM

Post #34 of 126 (1028 views)
Permalink
Re: ISP port blocking practice [In reply to]

No, blocking a port does not restrict a customers use of the network
any more than one way streets restrict access to downtown stores. It
just forces certain traffic directions in a bicycle/motorcycle/car/van/
truck neutral manner. Carry anything you want. Others laws restrict
incendiary content.


On Oct 23, 2009, at 6:15 PM, 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.
>
>> 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.
>
> Would you consider restricting a customer's outgoing port 25 traffic
> to a
> specific mail server a step over the net neutrality line?
>
> --
> Dan White

James R. Cutler
james.cutler [at] consultant


patrick at ianai

Oct 23, 2009, 5:12 PM

Post #35 of 126 (1028 views)
Permalink
Re: ISP port blocking practice [In reply to]

The original intent of Net Neutrality laws had nothing to do with
blocking or not on random ports. It had to do with giving an unfair
advantage to the provider in question to sell competing services.
Much like anti-trust legislation doesn't stop a company from cornering
a market, just stops them from using that Market Power to create
artificial advantages in other market segments to the detriment of the
public.


Putting this into a hypothetical example: If your access to iTunes,
NetFlix, Amazon, etc. is filtered / rate limited / whatever, but you
can order On-Demand from the company who owns the same piece of <fiber|
broadband connection you can buy because of monopoly / duopoly
protection, then this is deemed "unfair". Anti-net-neutrality people
spin this into "but suppose I want to charge extra for premium access
to YouTube?" A != B, their argument does not address the underlying
point of the rule. Do not be fooled by such spin.


Back to the original question, no provider is blocking port 25 to
force you to buy their mail services - they usually give it out for
free with a connection! Add in the "reasonable network management /
preventing abuse / best common practices" argument, which are backed
up with 3rd party documents, and I don't think anyone rational would
call this a violation of Network Neutrality.

The problem is, not everyone is rational, and no law is written
perfectly. Some spammer _will_ file a lawsuit claiming their spam is
CAN-SPAM compliant, therefore legal, and the provider cannot block
them. This will use legal resource, and may even result in un-
blocking while a judge who knows what the box on his secretary's desk
where his "e-mail" (huh?) gets printed is found. And that could take
a while.

Would that life were perfect. But it is not, so we muddle through as
best we can. And I think we can do better than allowing a gov't
sponsored monopoly use that monopoly to decide what things we can and
cannot do based on what will raise their profit margin.


One other personal comment: I believe if you paid for a resource, you
should be allowed to dictate its use, even to your customers (as long
as it is clear when they paid what the rules are). That said, there
are no cable or DSL providers in the US who "paid" 100% for their
resources, no matter what the executives at these companies think.
This is not opinion, this is fact.

OTOH: Companies who set up WiMAX or satellite or other technologies
which do not depend on gov't grants, tax relief, right-of-way,
monopoly protection, etc. should be allowed to do as they please.
Yes, this includes filtering iTunes so you buy their movie streaming
service. Of course, I have no idea if such a company exists, but it
certainly is not impossible to set one up. I just don't know if it
can make any money against companies that are funded by, granted
exclusive rights by, or are helped in other ways by the gov't. I fear
the answer is "no way in hell".


All of this is IMHO, of course.

--
TTFN,
patrick


On Oct 23, 2009, at 7:33 PM, James R. Cutler wrote:

> No, blocking a port does not restrict a customers use of the network
> any more than one way streets restrict access to downtown stores. It
> just forces certain traffic directions in a bicycle/motorcycle/car/
> van/truck neutral manner. Carry anything you want. Others laws
> restrict incendiary content.
>
>
> On Oct 23, 2009, at 6:15 PM, 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.
>>
>>> 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.
>>
>> Would you consider restricting a customer's outgoing port 25
>> traffic to a
>> specific mail server a step over the net neutrality line?
>>
>> --
>> Dan White
>
> James R. Cutler
> james.cutler [at] consultant
>
>
>
>
>


dwhite at olp

Oct 23, 2009, 7:35 PM

Post #36 of 126 (1025 views)
Permalink
Re: ISP port blocking practice [In reply to]

On 23/10/09 17:43 -0500, Justin Shore wrote:
>> It does block incoming SMTP traffic on that well known port.
>
> Then the customer should have bought a class of service that permits
> servers.

That justification is a slippery slope. At what point do you draw the line
on what constitutes business use? Is running a web server business use? A
mail server? What about a server which participates in a peer to peer
network? VPN?

I certainly think you're within your right as a network operator to
determine what is business use. I don't happen to feel that running a
protocol server in and of itself meets that definition.

>> 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 think I worded my question a bit wrong. I meant to hypothetically propose
a common scenario: You only allow your customers to connect to your SMTP
server, and if they attempt to connect to *any* other SMTP server, they are
blocked or redirected to your SMTP server.

--
Dan White


owen at delong

Oct 23, 2009, 7:46 PM

Post #37 of 126 (1026 views)
Permalink
Re: ISP port blocking practice [In reply to]

Yes.

Owen

On Oct 23, 2009, at 2:19 PM, Lee Riemer wrote:

> Isn't blocking any port against the idea of Net Neutrality?
>
> Justin Shore wrote:
>> Owen DeLong wrote:
>>> Blocking ports that the end user has not asked for is bad.
>>
>> I was going to ask for a clarification to make sure I read your
>> statement correctly but then again it's short enough I really don't
>> see any room to misinterpret it. Do you seriously think that a
>> typical residential user has the required level of knowledge to
>> call their SP and ask for them to block tcp/25, tcp & udp/1433 and
>> 1434, and a whole list of common open proxy ports? While they're
>> at it they might ask the SP to block the C&C ports for Bobax and
>> Kraken. I'm sure all residential users know that they use ports
>> 447 and 13789. If so then send me some of your users. You must be
>> serving users around the MIT campus.
>>
>>> Doing it and refusing to unblock is worse.
>>
>> How you you propose we pull a customer's dynamically-assigned IP
>> out of a DHCP pool so we can treat it differently? Not all SPs use
>> customer-facing AUTH. I can think of none that do for CATV though
>> I'm sure someone will now point an oddball SP that I've never heard
>> of before.
>>
>>> Some ISPs have the even worse practice of blocking 587 and a few
>>> even
>>> go to the horrible length to block 465.
>>
>> I would call that a very bad practice. I haven't personally seen a
>> mis-configured MTA listening on the MSP port so I don't think they
>> can make he claim that the MSP port is a common security risk. I
>> would call tcp/587 a very safe port to have traverse my network. I
>> think those ISPs are either demonstrating willful ignorance or
>> marketing malice.
>>
>>> A few hotel gateways I have encountered are dumb enough to think
>>> they can block TCP/53
>>> which is always fun.
>>
>> The hotel I stayed in 2 weeks ago that housed a GK class I took had
>> just such a proxy. It screwed up DNS but even worse it completely
>> hosed anything trying to tunnel over HTTP. OCS was dead in the
>> water. My RPC-over-HTTP Outlook client couldn't work either.
>> Fortunately they didn't mess with IPSec VPN or SSH. Either way it
>> didn't matter much since the network was unusable (12 visible APs
>> from room, all on overlapping 802.11b/g channels). The average
>> throughput was .02Mbps.
>>
>>> Lovely for you, but, not particularly helpful to your customers
>>> who may actually want to use some of those services.
>>
>> I take a hard line on this. I will not let the technical ignorance
>> of the average residential user harm my other customers. There is
>> absolutely no excuse for using Netbios or MS-SQL over the Internet
>> outside of an encrypted tunnel. Any user smart enough to use a
>> proxy is smart enough to pick a non-default port. Any residential
>> user running a proxy server locally is in violation of our AUP
>> anyway and will get warned and then terminated. My filtering helps
>> 99.99% of my userbase. The .001% that find this basic security
>> filter intolerable can speak with their wallets. They can find
>> themselves another provider if they want to use those ports or pay
>> for a business circuit where we filter very little on the
>> assumption they as a business have the technical competence to
>> handle basic security on their own. (The actual percentage of
>> users that have raised concerns in the past 3 years is .0008%. I
>> spoke with each of them and none decided to leave our service.)
>>
>> We've been down the road of no customer-facing ingress ACLs. We've
>> fought the battles of getting large swaths of IPs blacklisted
>> because of a few users' technical incompetence. We've had large
>> portions of our network null-routed in large SPs. Then we got our
>> act together and stopped acting like those ISPs who we all love to
>> bitch about, that do not manage their customer traffic, and are
>> poor netizens of this shared resource we call the Internet. Our
>> problems have all but gone away. Our residential and business users
>> no longer call in on a daily basis to report blacklisting
>> problems. We no longer have reachability issues with networks that
>> got fed up with the abuse coming from our compromised users and
>> null-routed us. I stand by our results as proof that what we're
>> doing is right. Our customers seem to agree and that's what matters.
>>
>> Justin
>>
>>
>>


owen at delong

Oct 23, 2009, 7:54 PM

Post #38 of 126 (1025 views)
Permalink
Re: ISP port blocking practice [In reply to]

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


mysidia at gmail

Oct 23, 2009, 8:36 PM

Post #39 of 126 (1024 views)
Permalink
Re: ISP port blocking practice [In reply to]

On Fri, Oct 23, 2009 at 5:43 PM, Justin Shore <justin [at] justinshore> wrote:
>[...]  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. [...]

Server does not necessarily equal business. A server that handles
a few personal mailboxes for a residential user is not 1000lbs of
concrete.
Offhand, I can think of a lot of uses for various types of servers at
a residence that don't require special business features, and are
generallly low-traffic.

Some people might be a little upset if they brought their brand new
leased Camry home, to find their particular dealer had made an
ad-hoc decision to weld the trunk shut, and didn't tell them about
it directly and immediately, when advertising the vehicle.

You want to haul a few groceries home? Shoulda asked for a "business" camry.

Nevermind that the manufacturer has no separate product for that, it
was a dealer's arbitrary decision to block that particular "port",
anticipating customers would otherwise try to do evil things with it
(like try to haul concrete).

Anyways... like it or not.. blocking of outbound/inbound 25 may
be common.
But how common was the original question.. not 'is it a good idea?' or not.

I would suggest that blocking the destination port 25, outgoing
traffic from the end-user's point of view is the more preferred
choice, it is more efficient, in that the block is closer to the
source, and there are fewer wasted bits of traffic.

--
-J


a.harrowell at gmail

Oct 24, 2009, 2:27 AM

Post #40 of 126 (1017 views)
Permalink
Re: ISP port blocking practice [In reply to]

-original message-
Subject: Re: ISP port blocking practice
From: Owen DeLong <owen [at] delong>
Date: 24/10/2009 4:00 am

Yes.

Owen

On Oct 23, 2009, at 2:19 PM, Lee Riemer wrote:

> Isn't blocking any port against the idea of Net Neutrality?
>

Only if you take a legalistic view of it. Too much of the NN debate is about the futile search for an infallible legal argument with no corner cases. This is silly.

Take an empirical, practical view instead. Obviously there is no objection to blocking spam going out; after all, the spam comes from machines that are no longer under the control of their owners, so the only free speech that is affected is that of the spammer, and hasn't that already been litigated?

Free speech doesn't include the freedom to shout fire in a crowded theatre. Neither does it include the freedom to carry out a DDOS on the fire brigade control room. You aren't allowed to levy a toll on the roads and except your mates - roads are neutral. But that doesn't invalidate the speed limit or the obligation to drive on the left.

> Justin Shore wrote:
>> Owen DeLong wrote:
>>> Blocking ports that the end user has not asked for is bad.
>>
>> I was going to ask for a clarification to make sure I read your
>> statement correctly but then again it's short enough I really don't
>> see any room to misinterpret it. Do you seriously think that a
>> typical residential user has the required level of knowledge to
>> call their SP and ask for them to block tcp/25, tcp & udp/1433 and
>> 1434, and a whole list of common open proxy ports? While they're
>> at it they might ask the SP to block the C&C ports for Bobax and
>> Kraken. I'm sure all residential users know that they use ports
>> 447 and 13789. If so then send me some of your users. You must be
>> serving users around the MIT campus.
>>
>>> Doing it and refusing to unblock is worse.
>>
>> How you you propose we pull a customer's dynamically-assigned IP
>> out of a DHCP pool so we can treat it differently? Not all SPs use
>> customer-facing AUTH. I can think of none that do for CATV though
>> I'm sure someone will now point an oddball SP that I've never heard
>> of before.
>>
>>> Some ISPs have the even worse practice of blocking 587 and a few
>>> even
>>> go to the horrible length to block 465.
>>
>> I would call that a very bad practice. I haven't personally seen a
>> mis-configured MTA listening on the MSP port so I don't think they
>> can make he claim that the MSP port is a common security risk. I
>> would call tcp/587 a very safe port to have traverse my network. I
>> think those ISPs are either demonstrating willful ignorance or
>> marketing malice.
>>
>>> A few hotel gateways I have encountered are dumb enough to think
>>> they can block TCP/53
>>> which is always fun.
>>
>> The hotel I stayed in 2 weeks ago that housed a GK class I took had
>> just such a proxy. It screwed up DNS but even worse it completely
>> hosed anything trying to tunnel over HTTP. OCS was dead in the
>> water. My RPC-over-HTTP Outlook client couldn't work either.
>> Fortunately they didn't mess with IPSec VPN or SSH. Either way it
>> didn't matter much since the network was unusable (12 visible APs
>> from room, all on overlapping 802.11b/g channels). The average
>> throughput was .02Mbps.
>>
>>> Lovely for you, but, not particularly helpful to your customers
>>> who may actually want to use some of those services.
>>
>> I take a hard line on this. I will not let the technical ignorance
>> of the average residential user harm my other customers. There is
>> absolutely no excuse for using Netbios or MS-SQL over the Internet
>> outside of an encrypted tunnel. Any user smart enough to use a
>> proxy is smart enough to pick a non-default port. Any residential
>> user running a proxy server locally is in violation of our AUP
>> anyway and will get warned and then terminated. My filtering helps
>> 99.99% of my userbase. The .001% that find this basic security
>> filter intolerable can speak with their wallets. They can find
>> themselves another provider if they want to use those ports or pay
>> for a business circuit where we filter very little on the
>> assumption they as a business have the technical competence to
>> handle basic security on their own. (The actual percentage of
>> users that have raised concerns in the past 3 years is .0008%. I
>> spoke with each of them and none decided to leave our service.)
>>
>> We've been down the road of no customer-facing ingress ACLs. We've
>> fought the battles of getting large swaths of IPs blacklisted
>> because of a few users' technical incompetence. We've had large
>> portions of our network null-routed in large SPs. Then we got our
>> act together and stopped acting like those ISPs who we all love to
>> bitch about, that do not manage their customer traffic, and are
>> poor netizens of this shared resource we call the Internet. Our
>> problems have all but gone away. Our residential and business users
>> no longer call in on a daily basis to report blacklisting
>> problems. We no longer have reachability issues with networks that
>> got fed up with the abuse coming from our compromised users and
>> null-routed us. I stand by our results as proof that what we're
>> doing is right. Our customers seem to agree and that's what matters.
>>
>> Justin
>>
>>
>>


jgreco at ns

Oct 24, 2009, 3:17 AM

Post #41 of 126 (1015 views)
Permalink
Re: ISP port blocking practice [In reply to]

> > Isn't blocking any port against the idea of Net Neutrality?
>
> Yes.
>
> Owen

No.

The idea of net neutrality, in this context, is for service providers
to avoid making arbitrary decisions about the services that a customer
will be allowed.

Blocking 25, or 137-139, etc., are common steps taken to promote the
security of the network. This is not an arbitrary decision (and I am
defining it this way; I will not play semantics about "arbitrary".
Read along and figure out what I mean.) For 25, SMTP has proven to be
a protocol that has adapted poorly to modern life, and a variety of
issues have conspired that make it undesirable to allow random home
PC's to use 25. Reasonable alternatives exist, such as using 587, or
the ISP's mail server. A customer isn't being disallowed the use of
SMTP to send mail (which WOULD be a problem). A customer may use any
number of other mail servers to send mail. Not a serious issue, and
not arbitrary... it's generally considered a good, or even best
current, practice.

Blocking VoIP from your network to Vonage, because you want your
customers to buy your own VoIP service? That's a very clear problem.
There's no justifiable reason that any viable broadband service
provider would have for blocking VoIP. Yet there could be a reason
to forbid VoIP; I can, for example, imagine some of the rural WISP
setups where the loads caused on the infrastructure interfere with
providing service.

Similarly, it'd be ridiculous to expect an 802.11b based rural WISP
to be able to support HD Netflix streaming, or dialup ISP's to be
able to support fast downloading of movies. These are not arbitrary
restrictions, but rather technological ones. When you buy a 56k
dialup, you should expect you won't get infinite speed. When you
buy WISP access on a shared 802.11b setup, you should expect that
you're sharing that theoretical max 11Mbps with other subs.

It gets murkier when you get into situations such as where your
cableco has sold you a 15Mbps Internet connection, but proceeds to
"traffic engineer" your activities down to a slower speed. There
are real questions that should be addressed; for example, if you
are paying extra for a "premium" service (as in when the default
speed is 7Mbps and you've upgraded), should a customer expect that
they will actually get substantially more capacity? How does the
reliance on overcommit affect things? The ideal is to sell a
high speed connection to someone who uses none of it, of course...
but if you're selling lots of capacity, and betting that only a
little will be used at a time, and you've guessed wrong, the big
question is, is that tolerable, or is net neutrality going to
force you to provide what you've sold?

So, now, back to blocking... many service providers block 80, on
the basis that they don't want customers running servers. This
could very well be a net neutrality issue. It's probably not a
security issue. It's a decision being made at a business level, in
order to promote the purchase of "business class" services. It's
an arbitrary decision about what a customer will be allowed to do.

There's lots of interesting stuff to think about. Net neutrality
isn't going to mean that we kill BCP38 and port 25 filtering. It
is about service providers arbitrarily interfering with the service
that they're providing. Customers should be given, to the maximum
extent reasonably possible, Internet connectivity suitable for
general purpose use. Where service providers start infringing on
that, that's what should be addressed by network neutrality.

... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


patrick at ianai

Oct 24, 2009, 8:21 AM

Post #42 of 126 (1012 views)
Permalink
Re: ISP port blocking practice [In reply to]

On Oct 23, 2009, at 10:54 PM, Owen DeLong wrote:
> 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".

We disagree. But is this really the place to discuss what MARKETING
people should be doing? :)

Blocking port 25 is not, IMHO, a violation of Network Neutrality. I
explained why in a very long, probably boring, post. Your definition
of Network neutrality may differ. Which is fine, but doesn't make
mine wrong.

As for how it is marketed, well, I'm not even going to try to argue
that.

--
TTFN,
patrick


jcdill.lists at gmail

Oct 24, 2009, 8:41 AM

Post #43 of 126 (1011 views)
Permalink
Re: ISP port blocking practice [In reply to]

Chris Boyd wrote:
>
>
> Once it's set up correctly we've found customers really like it since
> their email "just works" in most places.

Earlier this week I had an experience at a San Jose[1] Public Library,
where they blocked ports 995, 587, 465, and 119. None of my mail
services (or usenet service) worked, except for the news server I use
that runs on port 443 (heh) and my webmail backup. Using gmail/webmail
I sent an email to the tech admin, and they opened up those ports the
next day.

This is the first time I've had problems with using these ports - in
other cases it does "just work" as expected. I was rather stunned to
run into this at a public library. Usually librarians are major
defenders of free speech and fight vigorously against censoring,
blocking, and filtering of any type on library computers and networks.
My guess is that none of the librarians *knew* that the IT department
had setup these blocks. I'll have a chat with them the next time I drop in.

jc

[1] San Jose is the 3rd largest city in California, 10th largest city in
the US and the center of Silicon Valley - I had expected a higher level
of IT clue than I found.


owen at delong

Oct 24, 2009, 9:13 AM

Post #44 of 126 (1011 views)
Permalink
Re: ISP port blocking practice [In reply to]

On Oct 24, 2009, at 3:17 AM, Joe Greco wrote:

>>> Isn't blocking any port against the idea of Net Neutrality?
>>
>> Yes.
>>
>> Owen
>
> No.
>
> The idea of net neutrality, in this context, is for service providers
> to avoid making arbitrary decisions about the services that a customer
> will be allowed.
>
Right.

> Blocking 25, or 137-139, etc., are common steps taken to promote the
> security of the network. This is not an arbitrary decision (and I am
> defining it this way; I will not play semantics about "arbitrary".
> Read along and figure out what I mean.) For 25, SMTP has proven to be
> a protocol that has adapted poorly to modern life, and a variety of
> issues have conspired that make it undesirable to allow random home
> PC's to use 25. Reasonable alternatives exist, such as using 587, or
> the ISP's mail server. A customer isn't being disallowed the use of
> SMTP to send mail (which WOULD be a problem). A customer may use any
> number of other mail servers to send mail. Not a serious issue, and
> not arbitrary... it's generally considered a good, or even best
> current, practice.
>
A common practice of breaking the network for your customers does not
make the network any less broken and does not make the action network
neutral

The SMTP protocol has adapted just fine. Certain operators of SMTP
servers, on the other hand, are a different issue. I don't take
exception
if you want to block those SMTP servers. I do take exception if you
block the protocol entirely.

587 is the exact same protocol as 25, just with different host
configuration
policies. As such, I would hold up 587 as an example to prove my point.


> Blocking VoIP from your network to Vonage, because you want your
> customers to buy your own VoIP service? That's a very clear problem.
> There's no justifiable reason that any viable broadband service
> provider would have for blocking VoIP. Yet there could be a reason
> to forbid VoIP; I can, for example, imagine some of the rural WISP
> setups where the loads caused on the infrastructure interfere with
> providing service.
>
Some providers block outbound 25 to other email service providers
because they want your outgoing email to go only through their
own unauthenticated, unsecure mail servers. (I have had at least
one former ISP refuse to unblock port 25 or 587 for me to a host
that was running TLS and SMTPAUTH while they insisted that
I use their port 25 server which did not listen on port 587 and
would not accept TLS or SMTPAUTH).

> Similarly, it'd be ridiculous to expect an 802.11b based rural WISP
> to be able to support HD Netflix streaming, or dialup ISP's to be
> able to support fast downloading of movies. These are not arbitrary
> restrictions, but rather technological ones. When you buy a 56k
> dialup, you should expect you won't get infinite speed. When you
> buy WISP access on a shared 802.11b setup, you should expect that
> you're sharing that theoretical max 11Mbps with other subs.
>
Right... Those are not arbitrary, they are valid. Blocking all access
to port 25 is, on the other hand, arbitrary.
>
>
> There's lots of interesting stuff to think about. Net neutrality
> isn't going to mean that we kill BCP38 and port 25 filtering. It
> is about service providers arbitrarily interfering with the service
> that they're providing. Customers should be given, to the maximum
> extent reasonably possible, Internet connectivity suitable for
> general purpose use. Where service providers start infringing on
> that, that's what should be addressed by network neutrality.
>
BCP-38 is good. SMTP blocking is not in BCP-38.

Not allowing a user to send forged packets is a perfectly legitimate
action. Not allowing a user to send or receive valid packets
properly formatted, carrying legitimate traffic for purposes which
are not a violation of the providers AUP, on the other hand, is
not good.

Owen


jgreco at ns

Oct 24, 2009, 12:07 PM

Post #45 of 126 (1009 views)
Permalink
Re: ISP port blocking practice [In reply to]

> On Oct 24, 2009, at 3:17 AM, Joe Greco wrote:
> >>> Isn't blocking any port against the idea of Net Neutrality?
> >>
> >> Yes.
> >>
> >> Owen
> >
> > No.
> >
> > The idea of net neutrality, in this context, is for service providers
> > to avoid making arbitrary decisions about the services that a customer
> > will be allowed.
>
> Right.
>
> > Blocking 25, or 137-139, etc., are common steps taken to promote the
> > security of the network. This is not an arbitrary decision (and I am
> > defining it this way; I will not play semantics about "arbitrary".
> > Read along and figure out what I mean.) For 25, SMTP has proven to be
> > a protocol that has adapted poorly to modern life, and a variety of
> > issues have conspired that make it undesirable to allow random home
> > PC's to use 25. Reasonable alternatives exist, such as using 587, or
> > the ISP's mail server. A customer isn't being disallowed the use of
> > SMTP to send mail (which WOULD be a problem). A customer may use any
> > number of other mail servers to send mail. Not a serious issue, and
> > not arbitrary... it's generally considered a good, or even best
> > current, practice.
>
> A common practice of breaking the network for your customers does not
> make the network any less broken and does not make the action network
> neutral
>
> The SMTP protocol has adapted just fine. Certain operators of SMTP
> servers, on the other hand, are a different issue. I don't take
> exception
> if you want to block those SMTP servers. I do take exception if you
> block the protocol entirely.
>
> 587 is the exact same protocol as 25, just with different host
> configuration
> policies. As such, I would hold up 587 as an example to prove my point.

Except it doesn't. 587 is "submission done right"; whereas 25 is
"transit." 587 and 25 are conceptually completely different, even if
they use a common underlying protocol. That's why 587 not only does
not prove your point, but it actually allows me to show that it isn't
SMTP being interfered with, but rather just the uncontrolled submission
of e-mail to remote machines.

Does network neutrality mean that dialup operators will have to allow
PPP users to connect without a login and password?

> > Blocking VoIP from your network to Vonage, because you want your
> > customers to buy your own VoIP service? That's a very clear problem.
> > There's no justifiable reason that any viable broadband service
> > provider would have for blocking VoIP. Yet there could be a reason
> > to forbid VoIP; I can, for example, imagine some of the rural WISP
> > setups where the loads caused on the infrastructure interfere with
> > providing service.
>
> Some providers block outbound 25 to other email service providers
> because they want your outgoing email to go only through their
> own unauthenticated, unsecure mail servers. (I have had at least
> one former ISP refuse to unblock port 25 or 587 for me to a host
> that was running TLS and SMTPAUTH while they insisted that
> I use their port 25 server which did not listen on port 587 and
> would not accept TLS or SMTPAUTH).

Blocking 25 isn't a problem. Blocking 587 is. Requiring all e-mail
to go through their servers is also a problem. That's because there
is a good reason for the 25 blocking, one that you can trivially
work around on 587. Blocking 587 is overreaching, and is dictating
that you must use their servers. That is not neutral.

> > Similarly, it'd be ridiculous to expect an 802.11b based rural WISP
> > to be able to support HD Netflix streaming, or dialup ISP's to be
> > able to support fast downloading of movies. These are not arbitrary
> > restrictions, but rather technological ones. When you buy a 56k
> > dialup, you should expect you won't get infinite speed. When you
> > buy WISP access on a shared 802.11b setup, you should expect that
> > you're sharing that theoretical max 11Mbps with other subs.
>
> Right... Those are not arbitrary, they are valid. Blocking all access
> to port 25 is, on the other hand, arbitrary.

It's not, because there is an obvious ongoing problem with infected
end-user machines sending spam, and no particular reason that an end-
user machine needs to be able to send e-mail to random remote sites.
A huge amount of good is accomplished for the 'net as a whole when a
service provider blocks 25. They're not preventing you from sending
e-mail, they're just requiring that it be sent in a manner that
complies with current community standards. And there are standards,
and you can submit via 587 to alternative e-mail services of your
choice.

It is not entirely ideal, but it is laughable to construe 25 blocking
as making it impossible (or even hard) to send e-mail, given that it
most certainly isn't.

> > There's lots of interesting stuff to think about. Net neutrality
> > isn't going to mean that we kill BCP38 and port 25 filtering. It
> > is about service providers arbitrarily interfering with the service
> > that they're providing. Customers should be given, to the maximum
> > extent reasonably possible, Internet connectivity suitable for
> > general purpose use. Where service providers start infringing on
> > that, that's what should be addressed by network neutrality.
>
> BCP-38 is good. SMTP blocking is not in BCP-38.
>
> Not allowing a user to send forged packets is a perfectly legitimate
> action. Not allowing a user to send or receive valid packets
> properly formatted, carrying legitimate traffic for purposes which
> are not a violation of the providers AUP, on the other hand, is
> not good.

Oh. Really. But the problem is, you can't play both "BCP38 is good"
and "25 blocking is bad." They're of the same cloth.

If I'm assigned 24.1.2.3 by Comcast, and Comcast filters my ingress to
prevent me from emitting other addresses, you claim that's fine because
it's BCP38.

There's a problem: I can validly emit a variety of other addresses, in
particular any address in 206.55.64.0/20 and some other networks. I am
not "forging" packets if I emit 206.55.64.0/20-sourced addresses down a
Comcast pipe.

How many people realistically have this problem? Well, potentially,
lots. Anyone who uses a VPN could have a legitimate IP address on their
machine; because of BCP38 (and other security policy) it is common
for a VPN setup to forward Internet-bound traffic back to the VPN
server rather than directly out the Internet. In some cases, one could
reasonably argue that this is undesirable.

But overall, security is greatly increased by eliminating the ability
to inject forged traffic. We do this through BCP38. BCP38 carries with
it some amount of inconvenience to users whose legitimate traffic can
not be sent due to the simplistic filtering typically employed.

This does not mean BCP38 violates net neutrality, any more than it means
25 blocking violates it. On the other hand, if your ISP is intercepting
your DNS, forcing /all/ SMTP through their servers, mandating the use of
web proxy servers that add banner ads, blocking VoIP, and RST'ing
BitTorrent traffic, then you have a serious net neutrality problem.

As operators, the readers in this group should be uniquely qualified to
understand: common technical steps taken to ensure the security and
continued smooth operation of your network are probably not violating
net neutrality, but once you move into the realm of steps taken that
damage a competitor, degrade or forbid particular services, or other
decisions made for "business" reasons, where such things affect the set
of potential things a user could reasonably expect to want to be able
to do, then you have to look a bit more carefully at it.

... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


kmedcalf at dessus

Oct 24, 2009, 1:05 PM

Post #46 of 126 (1003 views)
Permalink
RE: ISP port blocking practice [In reply to]

> Free speech doesn't include the freedom to shout fire in a crowded theatre.

It most certainly does! There is absolutely nothing to prevent one from shouting "FIRE" in a crowded theatre. In fact, any attempt to legislate a prohibition against such behaviour would, in all civilized countries and legal systems, constitute unlawful prior restraint.

You are confusing (as are all the myriad idiots who keep repeating this fictitious statement) prior restraint with positive law.

Nothing prevents you from shouting "FIRE" in a crowded theatre (or anywhere else for that matter). However the proof of the FACT that you shouted "FIRE", and the proof of the FACT that this caused panic and injury, and proof of the FACT that the act of shouting "FIRE" caused pandemonium and injury will lead to a conviction for the offense of RECKLESS ENDANGERMENT or other offences against positive law.

It is not the shouting of "FIRE" in a crowded theatre that is unlawful, it is the reckless act and the reckless disregard for the consequences of that act which is criminal. In fact, if one were to shout "FIRE" in a crowded theatre and everyone simply ignored it, no offense would have been committed at all!

Please keep your facts straight and do not abridge and summarize to the point of absolute absurdity!

> Neither does it include the freedom to carry out a DDOS on the fire brigade control room.

This, of course, falls in the same category. You are totally free to DDoS the fire brigade control room. It is not illegal nor can such action be prohibited by positive law. It is however entirely possible that the consequence of such behaviour is perilous to property, life and limb; and that as a consequence the act itself becomes reckless endangerment ONLY AFTER IT HAS BEEN COMMITTED. There is not, and cannot be, any lawful prior restraint in this case either.

> You aren't allowed to levy a toll on the roads and except your mates - roads are neutral.

Of course you can, and governments do it all the time.

> But that doesn't invalidate the speed limit or the obligation to drive on the left.

Once again, you are confusing prior restraint with the consequence of doing an action. The Act itself cannot be prohibited. Their may be consequences assigned to having proven that an act was done, but the doing of the act is not and cannot be prohibited.

Of course, both the United States and the UK have become Fascist states, and as such it is reasonable to expect that they will behave like Fascists.

--
() ascii ribbon campaign against html e-mail
/\ www.asciiribbon.org


cluestore at gmail

Oct 24, 2009, 4:55 PM

Post #47 of 126 (996 views)
Permalink
Re: ISP port blocking practice [In reply to]

>
>
>
> Blocking port 25 is not, IMHO, a violation of Network Neutrality. I
> explained why in a very long, probably boring, post. Your definition of
> Network neutrality may differ. Which is fine, but doesn't make mine wrong.
>
>
>
> --
> TTFN,
> patrick
>
>
> I agree with this. I would think that from an administrator/engineers
perspective, it's more of being proactive to help protect the network, the
end-user and help keep SLA's (keep from getting listed on RBL because of a
non-patched or virused pc, not wasting network resources due to SPAM, trying
to keep your own house clean, etc) more than it is an attack on Net
Neutrality.

But on the other hand, the end-user, customer, or whoever is having a port
blocked, might wonder about the services they are buying and if it's time to
jump ship to another provider if they aren't willing to work with the
customer.

I think that most providers are willing to work with the customer if ports
such as SMTP need to be unblocked for whatever reason. If they aren't, then
i would suggest finding another provider.

Clue


jmaimon at ttec

Oct 25, 2009, 4:05 PM

Post #48 of 126 (965 views)
Permalink
Re: ingress filtering and multiple Internet conenctions [In reply to]

Joe Greco wrote:

>
> There's a problem: I can validly emit a variety of other addresses, in
> particular any address in 206.55.64.0/20 and some other networks. I am
> not "forging" packets if I emit 206.55.64.0/20-sourced addresses down a
> Comcast pipe.
>
> How many people realistically have this problem? Well, potentially,
> lots. Anyone who uses a VPN could have a legitimate IP address on their
> machine; because of BCP38 (and other security policy) it is common
> for a VPN setup to forward Internet-bound traffic back to the VPN
> server rather than directly out the Internet. In some cases, one could
> reasonably argue that this is undesirable.


I would like to take the opportunity to urge vendors of routers and
firewalls to take extra special care and attention to make sure that The
Right Thing can always happen whenever multiple egress services are
employed.

This means that policy routing for network AND ALL locally generated
traffic should be available and work as the operator intends it to.

Right now things still suck pretty hard, depending on what you are using.


Joe


nanog-post at rsuc

Oct 25, 2009, 4:25 PM

Post #49 of 126 (965 views)
Permalink
Re: ISP port blocking practice [In reply to]

On Fri, Oct 23, 2009 at 04:19:23PM -0500, Lee Riemer wrote:
> Isn't blocking any port against the idea of Net Neutrality?

Which demonstrates just how relevant to reality such things are.

--
RSUC / GweepNet / Spunk / FnB / Usenix / SAGE


jgreco at ns

Oct 25, 2009, 4:58 PM

Post #50 of 126 (963 views)
Permalink
Re: ingress filtering and multiple Internet conenctions [In reply to]

> Joe Greco wrote:
> > There's a problem: I can validly emit a variety of other addresses, in
> > particular any address in 206.55.64.0/20 and some other networks. I am
> > not "forging" packets if I emit 206.55.64.0/20-sourced addresses down a
> > Comcast pipe.
> >
> > How many people realistically have this problem? Well, potentially,
> > lots. Anyone who uses a VPN could have a legitimate IP address on their
> > machine; because of BCP38 (and other security policy) it is common
> > for a VPN setup to forward Internet-bound traffic back to the VPN
> > server rather than directly out the Internet. In some cases, one could
> > reasonably argue that this is undesirable.
>
> I would like to take the opportunity to urge vendors of routers and
> firewalls to take extra special care and attention to make sure that The
> Right Thing can always happen whenever multiple egress services are
> employed.
>
> This means that policy routing for network AND ALL locally generated
> traffic should be available and work as the operator intends it to.
>
> Right now things still suck pretty hard, depending on what you are using.

Who defines what "The Right Thing" is?

Allowing (what are to the service provider) random IP's inbound, even
if there's some mechanism to limit it, means that the ISP now has some
additional responsibilities to be able to transport packets for space
that isn't theirs; a transit upstream or peer might filter, especially
for smaller service providers.

Basically, allowing this dooms BCP38.

... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

First page Previous page 1 2 3 4 5 6 Next page Last page  View All NANOG users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.