Telco's write best practices for packet switching networks

I was agreeing with Eric's point. I've been saying this for years. My
comment about the packet filter was to deal with services that are
needed for some internal purposes, but for some reason can't protect
themselves. Right now, that's snmp -- you may have snmpd running on
your mail server, but given the recent CERT advisory you need to keep
the bad guys away from it. (Yes, you should install fixed code -- but
given how many components were affected by that advisory, it's quite
obvious that no one has had time to test the fixes properly.)

    --Steve Bellovin, http://www.research.att.com/~smb
    Full text of "Firewalls" book now at http://www.wilyhacker.com

Okey-dokey :slight_smile: I missed that part (the agreement part)

My comment was originally prompted by the meeting minutes which
reported on the survey data showing that 100% of carriers are implementing
firewalls in their gateways. The 100% is what caught my eye. As the
topic comes up in various places, large ISPs repeatedly say they are
unable to implement filters or packet screening on their high-speed
links such as at peering points. So the self-reported 100% implementation
of screening and filtering firewalls at gateways didn't seem to jive
with my understanding of the limitations faced by large ISPs.

Firewalls can be a useful tool in the security engineer's toolbox. But
they get misused a lot. I don't believe security engineers are better
programmers. If there was a class of programmers in the world that didn't
make mistakes, I would hire them to write the applications. When the
firewall is more complex than the application server it is "protecting"
which is likely to have more mistakes?

How recently are ISPs repeatedly saying this? Packet filtering on high-speed optical interfaces has been possible for some time, depending on your router vendor, for some value of "packet filtering".

I could understand it if the issue of how to manage packet filter definitions on routers as the network changes was a problem. But if I would be slightly surprised if there was still a universal voice saying "we absolutely cannot filter packets at the edge, because the vendors won't let us".

To meet the requirements of what I understood the original quoted fragment to be saying, it's perhaps not necessary to packet filter at the edge, anyway. You can apply a firewall to just the loopback interface of a junos box and arguably consider your control element firewalled.

Joe

My comment was originally prompted by the meeting minutes which
reported on the survey data showing that 100% of carriers are implementing
firewalls in their gateways. The 100% is what caught my eye. As the
topic comes up in various places, large ISPs repeatedly say they are
unable to implement filters or packet screening on their high-speed
links such as at peering points. So the self-reported 100% implementation
of screening and filtering firewalls at gateways didn't seem to jive
with my understanding of the limitations faced by large ISPs.

Yes... hmm, I didn't read the report/minutes BUT I'd think this might mean
2 things:
1) the filtering is on the gateways (routers) 'for the router' (vty acls,
loopback filters, snmp filters, ntp filters...)
2) the filtering is on the ISP's corporate connection to the 'internet'

I'd think 1 more likely the correct interpretation than 2. I'd doubt this
was meant to be applied to 'all interfaces on the gateways' in the sense
that all interfaces have a traffic filter on them. That really isn't a
scalable/managable/workable (without melting a router) solution. (yes, I
know a juniper can probably filter on all interfaces at 'line rate' but
not everyone has junipers at their edge so the 100% would not apply here)

Hurray, my favorite arguement!

> My comment was originally prompted by the meeting minutes which
> reported on the survey data showing that 100% of carriers are
> implementing
> firewalls in their gateways. The 100% is what caught my eye. As the
> topic comes up in various places, large ISPs repeatedly say they are
> unable to implement filters or packet screening on their high-speed
> links such as at peering points.

How recently are ISPs repeatedly saying this? Packet filtering on
high-speed optical interfaces has been possible for some time, depending
on your router vendor, for some value of "packet filtering".

'now' would be a good starting time, but atleast 2 years we've been saying
it (if not longer)

I could understand it if the issue of how to manage packet filter
definitions on routers as the network changes was a problem. But if I
would be slightly surprised if there was still a universal voice saying
"we absolutely cannot filter packets at the edge, because the vendors
won't let us".

"we absolutely cannot filter packets at the edge, because the vendors
won't let us"

The equipment fries, the equipment does not support acls, the acls simply
don't work... I don't think I can put it any more clearly. There has got
to be a push from the USERS of this equipment (not just one user, all
users) to get line rate, full packet filtering capability on ALL
interfaces on EVERY router, everything from the smallest foundry or 1700
to the largest 12416 or M160 or Avici. If users don't start asking for
this 2 years ago it'll be another 4-5 years before its a reality. The
vendors will NOT push forward on this without a significant cash incentive
(like everyone saying: I need this so do it for me).

To meet the requirements of what I understood the original quoted
fragment to be saying, it's perhaps not necessary to packet filter at
the edge, anyway. You can apply a firewall to just the loopback
interface of a junos box and arguably consider your control element
firewalled.

Yes, if this is about the original discussion point,
firewalling/protecting the control elements, then a loopback filter (or
similar technology on a non-juniper platform) would suffice.

So it appears that we are in agreemnet after all! :slight_smile: (And we've been
saying the above for at least 4 years now...)

-ron

Since at least one vendor has got the message and ships hardware that *will* do line-rate filtering on high-speed interfaces, perhaps the answer is to modulate vendor selection accordingly. There's a significant cash incentive, for you, or at least a significant non-cash disincentive.

Joe

I'll step WAY OUT on this limb now :slight_smile:

>
>>
>> ...I don't think I can put it any more clearly. There has got
>> to be a push from the USERS of this equipment (not just one user, all
>> users) to get line rate, full packet filtering capability on ALL
>> interfaces on EVERY router, everything from the smallest foundry or
>> 1700
>> to the largest 12416 or M160 or Avici. If users don't start asking for
>> this 2 years ago it'll be another 4-5 years before its a reality. The
>> vendors will NOT push forward on this without a significant cash
>> incentive
>> (like everyone saying: I need this so do it for me).
>
> So it appears that we are in agreemnet after all! :slight_smile: (And we've been
> saying the above for at least 4 years now...)

Since at least one vendor has got the message and ships hardware that
*will* do line-rate filtering on high-speed interfaces, perhaps the
answer is to modulate vendor selection accordingly. There's a
significant cash incentive, for you, or at least a significant non-cash
disincentive.

Locking yourself into one vendor could be considered a bad move :frowning: You are
then locked into all their little quirky ways of doing things and you have
no recourse when their 'next great technology' isn't quite so great.

Additionally, perhaps the 'one good vendor' (and in my original note I
listed those vendors I could think of, not nceessarily those with
problems...) doesn't quite do everything you want either?

Its a sticky problem, basically having everyone who uses the equipment in
a big way shout the loudest possible that we need these basic filtering
requirements on all platforms is a good start. :slight_smile:

So, anyone experienced the 3xGigE linecard filtering?? :slight_smile: Talk about
enjoyable... the commands aren't even in the IOS filter with!!! SUPER
COOL!