March 2002 - Test - lists.nanog.org

Re: Telco's write best practices for packet switching networks
by Eric Brandwine 06 Mar '02

06 Mar '02

>>>>> "rp" == Rob Pickering <rob(a)pickering.org> writes: rp> --On 06 March 2002 15:04 +0000 "Christopher L. Morrow" <chris(a)UU.NET> rp> wrote: >> Eric's point was you deploy your fancy-dan mail server with ONLY 22 >> and 25 listening, rp> Um, that would be "ONLY port 25 listening" on it's public network rp> facing interface wouldn't it. rp> Why would you want to expose a management protocol like ssh to the rp> Internet? You wouldn't. Neither would I. I'll go poke fun at Chris. rp> OK so leaving ssh open is convenient, but if we are talking best rp> practice surely having your remote management protocols running on a rp> separate network, or at the very least filtering on a host basis so rp> that it's only listening to connects from your NOC has to be the way rp> to do this. Absolutely. It bothers me that as an ISP, we kinda have to run mail and dns servers. If there were two protocols I'd choose NOT to expose to the public network, they'd be it. I'd much rather expose ssh than bind or sendmail. ericb -- Eric Brandwine | Apart from hydrogen, the most common thing in the UUNetwork Security | universe is stupidity. ericb(a)uu.net | +1 703 886 6038 | - Harlan Ellison Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E

3 2

Re: Telco's write best practices for packet switching networks
by Eric Brandwine 06 Mar '02

06 Mar '02

>>>>> "rq" == Rob Quinn <rquinn(a)sec.sprint.net> writes: >> When you've got a deployed server, run by clueful people, dedicated to a >> single task, firewalls are not the way to go. rq> Probably. And I would certainly rate "clueful people" _far_ rq> above a firewall when it comes times to prioritize your security rq> needs and resources. Mind having a talk with my management? >> chose a resilient and flame tested daemon, and watch the patchlist for it. rq> You've never seen a security vendor come out with a patch or rq> workaround before an application vendor? Sure. Sometimes they come out with patches that wouldn't be needed if you didn't have the firewall ;) Stateful firewalls also suffer from state propagation problems. High bandwidth redundant links and firewalls don't get along well together. Some firewall packages will allow you to statelessly pass high bandwidth traffic (tcp,udp/53) in the DNS example, which helps with load management and failover. But then you're back to where you were without the firewall. Decent IDSes run on spanning ports against your uplinks, decent logging on packet filtering routers, etc will all give you the benefits of the firewall. In general, and IDS is a better IDS than a firewall, and so forth. The primay benefit of firewalls is simplicity of configuration, and the ability to allow outbound services without opening huge inbound holes (tcp,udp/53, tcp/20, udp > 1023, etc). This is generally not the case with deployed ISP servers. Finally, the "crunchy ouside" thing takes over way too often. Management is lulled into a happy place by the word "firewall", and even good security engineers get lazy. I realize that this is 100% a meat problem, but it's a problem either way. ericb -- Eric Brandwine | If people are good only because they fear punishment, UUNetwork Security | and hope for reward, then we are a sorry lot indeed. ericb(a)uu.net | +1 703 886 6038 | - Albert Einstein Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E

1 0

Re: Telco's write best practices for packet switching networks
by Eric Brandwine 06 Mar '02

06 Mar '02

>>>>> "rds" == Ron da Silva <ron(a)aol.net> writes: >> Cool, who has an OC-192 firewall on their control elements? What is >> a control element, is that the same as a router or is that a signaling >> gateway? rds> Hmm...gotta say it (again). Of course oc192/10ge firewalls are not rds> currently widely deployed (aka not a best practice), but they should be! rds> Of course, folks will argue that you have to pay a lot of extra $$ rds> to make that a reality...kind of like how auto makers argue that you rds> should pay a lot of extra $$ for the GPS receiver in your car (which rds> does not COST a lot of extra $$). Firewalls are good things for general purpose networks. When you've got a bunch of clueless employees, all using Windows shares, NFS, and all sorts of nasty protocols, a firewall is best practice. Rather than educate every single one of them as to the security implications of their actions, just insulate them, and do what you can behind the firewall. When you've got a deployed server, run by clueful people, dedicated to a single task, firewalls are not the way to go. You've got a DNS server. What are you going to do with a firewall? Permit tcp/53 and udp/53 from the appropriate net blocks. Where's the protection? Turn off unneeded services, chose a resilient and flame tested daemon, and watch the patchlist for it. ericb -- Eric Brandwine | It is hard to believe that a man is telling the truth UUNetwork Security | when you know that you would lie if you were in his ericb(a)uu.net | place. +1 703 886 6038 | - H. L. Mencken Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E

2 1

Telco's write best practices for packet switching networks
by Sean Donelan 06 Mar '02

06 Mar '02

After the SNMP excitement I asked if anyone had suggestions on how to architect or design a backbone network to be less suspectible to problems. It turns out the telephone industry has written a set of best practices for the Internet. Focus Group 2.A.2: Best Practices on Packet Switching. Karl Rauscher, Lucent Technologies http://www.nric.org/pubs/index.html Mr. Rauscher gave an example of the kind of information to be found there. The best practice used in the example states that critical packet network elements such as control elements, access in signaling gateways and DNS servers, should have firewall protection such as screening and filtering. One hundred percent of the respondents indicated they were implementing this best practice. Cool, who has an OC-192 firewall on their control elements? What is a control element, is that the same as a router or is that a signaling gateway?

2 1

Re: Satellite latency
by Tony Rall 06 Mar '02

06 Mar '02

On Tuesday, 2002/03/05 at 08:42 ZE2, Hank Nussbacher <hank(a)att.net.il> wrote: > New 12.2(8)T feature in Cisco IOS called TCP Windows Scaling: > http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/12… > 2t8/tcpwslfn.htm > > Specifically made for satellite networks: > ip tcp window-size 750000 I don't understand the benefit of this on a router. Except for connections where the router itself is an endpoint (telnet to the router, for example), the router has no need to even be aware of window size. Perhaps the router's window size comes into play if the router is performing advanced functions such as NAT or IPSEC? Tony Rall

3 2

80 AMP power controllers?
by Chris J. Robb 05 Mar '02

05 Mar '02

Greetings. I may have the need to drive a piece of networking equipment with a DC input requirement of 80 AMPS, possibly 90. For remote management, we need the capability to power cycle the box remotely through dial-up. There will be redundant power, so two 80 AMP feeds will be required. Sentry has a box that can split two 100 AMP feeds into two 70 AMP feeds toward our equipment. That's about as high as I can find. What do the larger carriers use? (Or to they just use remote hands at the POPs when necessary. Thanks! -Chris -- Chris Robb Indiana University

3 2

Re: Satellite latency
by Hank Nussbacher 05 Mar '02

05 Mar '02

New 12.2(8)T feature in Cisco IOS called TCP Windows Scaling: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/12… Specifically made for satellite networks: ip tcp window-size 750000 -Hank >On Wed, Feb 27, 2002 at 11:01:04PM -0500, Mark Allman wrote: > > > The receiver is the one that informs the sender how large of a > > > window it can accept, so it can be practical for a subscriber > > > installation. It wouldn't be a good idea to park a bunch of > > > servers behind one of these links, but any receiving node that set > > > its TCP receive window to 2x the byte/sec capacity of the link > > > should see decent throughput. > > > > No, you need to set things on both sides. The sender has to buffer > > data until it is ACKed in case it needs to retransmit. So, its > > buffer needs to be as big as the advertised window or the sender > > buffer will effectivly limit the advertised window. > >What do you need to set on the send side? If the receiver tells the >sender "my acceptable window is 512k", the sender knows how much it >has to buffer. > >-c

3 3

Tools used accounting/billing
by H. Michael Smith, Jr. 05 Mar '02

05 Mar '02

Hello All. Can anyone suggest tools to use for gathering statistics for billing purposes? I would like to know what tools are most common among ISPs. Thanks, Michael

3 2

111 8th - NY Level III
by Gyorfy, Shawn 05 Mar '02

05 Mar '02

Is there anyone there at the Level III facility at 111 8th in NY. Please respond. shawn

1 0

detecting and blocking DoS/DDoS attacks
by Constantinos A. Kotsokalis 05 Mar '02

05 Mar '02

Hello everyone, I recently finished the latest beta release of a tool to detect (and possibly block) DoS/DDoS attacks. There are a few problems that I am trying to resolve, but all in all it seems to work. The tool is released under the GPL (i.e. it is free to use and modify the source code) and is available at: http://prdownloads.sourceforge.net/panoptis/panoptis-0.1b4.tar.gz Any contribution to the code, or functionality tests, will be of great value. Please note that the input is provided by Cisco routers exporting NetFlow data. At the moment, versions 1 and 5 have been tested. Support for version 8 is included, but not tested at all. The tool also allows for the creation of a detector mesh, in order to achieve trace-back in the case of spoofed IP addresses. Another thing to keep in mind is that it is written in C++ (so you will need a C++ compiler), it has been tested on Linux and it needs the GNU CommonC++ library (available at http://sourceforge.net/projects/cplusplus ). Please understand that this is a beta release, so not everything might work as it should; However, enough testing will lead to a stable release which will help all of us get rid of script kiddies bringing our networks to their knees. Thanks, Costas -- Constantinos A. Kotsokalis || ckotso(a)grnet.gr Greek Research and Technology Network Tel: +30 10 7474243 || Fax: +30 10 7474490

1 0