why the heck does the IAB think they should tell me how to run my network?
--bill
why the heck does the IAB think they should tell me how to run my
network?
i don't think expressing concerns id telling you what you MUST do.
but all in all i suspect the iab's motivations were because your
network (btw, which one is that?) is part of the INTERnet, and we
would like it all to interoperate end to end. you have been here
long enough to remember when the internet was a cooperation between
operators, yes?
randy
I think the IAB has a legitimate point.
Network operators rely today on the fact that different services use
different ports, so they can block particular types of access/behavior
by blocking ports.
However, this behavior has already started to change how applications
work. We've all seen the streaming media clients, or IM programs
that will use port 80 to get past a firewall, even though they are
not http traffic. Virus writers have done the same thing. New VPN
technologies use SSL, on the SSL web server port, but then send IP
packets over them, not web requests.
There is a real danger that long-term continued blocking will lead
to "everything on one port" (probably 80). This will have the end
result that ISP's will be unable to filter out the bad traffic
anymore by using a port based filter, nor will they be able to
collect statistics or other usage data. Additionally, this moves
the problem up the stack as if everything runs on port 80 some
"intelligent" demuxer will be needed at a higher layer for a box
that wants to run multiple services.
I'm not saying ISP's shouldn't filter, but the long term filtering
is a problem. It will cause application developers to do things
that will make long term filtering not work, in the end.
I think the IAB has a legitimate point.
Network operators rely today on the fact that different services use
different ports, so they can block particular types of access/behavior
by blocking ports.
I think the IAB has a legitimate point and I agree with it 100%.
Unfortunately, I also think it lacks a certain amount of practicality.
When/if I remove the microsoft port filters (for example) from the interface
between my campus and my eBGP peers or between segments of our campus network,
my network starts to melt down because of the sudden influx of virus probes
and traffic related to the spike in infections on our 10k - 20k hosts. If
the recommendation is to remove these low-cost protections, is there a
recommendation on how I can prevent the subsequent and severe instability
on my network?
There is a real danger that long-term continued blocking will lead
to "everything on one port" (probably 80).
Or port 443. If the traffic is on port 80, most signature systems can
determine that its not necessarily a standard HTTP interaction. If its
on port 443 and has a basic level of encryption, the signature-based systems
fail.
I'm not saying ISP's shouldn't filter, but the long term filtering
is a problem. It will cause application developers to do things
that will make long term filtering not work, in the end.
I absolutely agree. Its the same argument that we made to our administration
regarding why we shouldn't block outright peer-to-peer applications. First,
the applications themselves aren't a problem, aren't illegal and, given
that we are a University, we should try not to stifle their developement.
Just as important, if we blocked them outright, our community would likley
shift to applications that are more effective at hiding themselves from us.
Since the only drawback to allowing them is that they increase the average
bandwidth demand per user, something we plan for anyway, we chose not to
filter.
Unfortunately, I can't make the same argument about the edge port filters
we have in place for security reasons. Though there is a general benifit
gained by allowing application development, the overwhelming cost that we'd
incur dealing with the compromised hosts themselves, the substantial increase
in network traffic and network attacks that they generate, etc., makes
removing these protections cost prohibitive.
Again, I definitely agree with the IAB's recommendation. However, its
difficult to defend this point of view in practice since most of the
equipment does basic packet filtering in hardware or with minimal cost to
peformance. So, I just can't figure out how to sit in front of our
administration and justify the replacement of a zero-cost solution with
the cost of added staff and equipment to mitigate these security risks,
especially when the up side is just not "limiting the potential for
deployment of future applications".
Eric 
In a message written on Sat, Oct 18, 2003 at 12:26:21PM -0400, Eric Gauthier wrote:
Again, I definitely agree with the IAB's recommendation. However, its
difficult to defend this point of view in practice since most of the
equipment does basic packet filtering in hardware or with minimal cost to
peformance. So, I just can't figure out how to sit in front of our
administration and justify the replacement of a zero-cost solution with
the cost of added staff and equipment to mitigate these security risks,
especially when the up side is just not "limiting the potential for
deployment of future applications".
Well, but you've hit the nail on the head. The fitler solution is
_NOT_ zero cost, it is deferred cost. I suggest you phrase it that
way. It's a way of deferring the cost to later, with interest.
The longer you use it, the higher that interest payment will be,
in the form of new and different attacks you can't block.
Phrasing it to the bean counters that it is deferring the cost,
with interest, and suggesting that simultaneously some money be
spent on user education, better software, or whatever is appropriate
to insure you don't have a "huge baloon payment" later might help
put it in terms they can understand.
Similar parallels can be drawn to antibiotics -- the over use will
eventually render them ineffective. It's a very similar situation,
and sometimes you have to just invest in not getting sick in the
first place (wash your hands...patch your system).