Jack, et al.
As a larger than average end user and what could
be called a small ISP, I really can not image
legitimate traffic on 135..
who in there right mind would pass NB traffic in the wild?
I dunno, may it is just that Old military security mindset
creeping into my brain housing group.
Can someone enlighten me? What is legitimate 136 traffic?
J
That's the problem; not all customers are in their right mind. All
they know is that it was working yesterday, and not today, because you
blocked a port.
The question of port blocking for most sizable ISPs comes down to
principle vs principle. One the one hand, you have the principle of
network invisibility. You agreed to pass customer traffic, not pass
judgement on it. If it's a valid IP packet, you'll deliver it. And
you don't slow down or stop traffic because you're spending cycles
examining packets.* That's what customers expect.
On the other hand, you have the principle of being a good network
citizen. You try to keep your tables clean and your peers from
flapping. You accept valid routes and inform your peers when you get
invalid ones, so they have a chance to fix them. You are properly
embarrassed when you find a spammer on your network or your name on
the CIDR report. And you don't spew other people's networks with worm
traffic. That is what other providers expect.
Port blocking is therefore a quandry: do you stick with your customer
principle, or your provider principle? I think most of us weigh the
damage of the attack vs the damage of losing the port, and make
individual judgement calls. It would be nice if there were some
central consensus on when to block ports; then individual providers
wouldn't need to take abuse from customers or other networks when their
judgement wasn't exactly the same as somebody else's.
-Dave
* Before the holy war starts, yeah, some hardware doesn't slow down
when blocking ports, and this is only an issue if your hardware isn't
that breed. My point is that this might be an issue for some hardware,
and that "Buy vendor X" isn't really a solution for everyone.
Yes, some providers however react improperly to certain situations and
do not listen to their paying customers.
RCN in Chicago is one example. One day, they just started blocking
outbound port 25 on their network. Now, I use other SMTP servers
other than the RCN one. In my case, they're my servers and all I have to
do is set up my SMTP to listen on an additional port. For others, they
aren't so lucky and may have a legitimate gripe with them for censoring
traffic.
In the case of 135-139, no one who uses these ports legitimatly should
have a need to use them "in the wild" unless in a tunnel. If a user came to
me complaining about them being blocked, I would ask the user why they
were using them incorrectly and would suggest safer ways to do the same
task.
So, being a good ISP is trying to accomodate the needs of as many
customers as you can, while being a good net neighbor. This is not
always easy.
As a larger than average end user and what could
be called a small ISP, I really can not image
legitimate traffic on 135..
who in there right mind would pass NB traffic in the wild?
the days of giving intelligence tests to customers is long gone.
the job of an isp is to deliver packets. maybe your customer
is foolish. but break their ceo's access and you're their ex-
isp.
randy
My experience seems to be that as the ISP we're blamed when the subscribers gets a virus, because after all it's our network that sent the customer the virus.
-- Mike
My experience seems to be that as the ISP we're blamed when the
subscribers gets a virus, because after all it's our network that
sent the customer the virus.
Catch 22 ... Block the virus, get accused of being a censor. Allow the
virus, get accused of being a carrier...
*sigh*
From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On
Behalf Of McBurnett, Jim
... I really can not image
legitimate traffic on 135..
My problem with this approach is that, in 1985, you could have said "I
really cannot imagine legitimate traffic on port 80".
(On the other hand, you could probably say that today and be mostly right)
Matthew Kaufman
matthew@eeph.com