- Test - lists.nanog.org

Re: engineering --> ddos and flooding
by Steven M. Bellovin 31 May '01

31 May '01

In message <4.3.2.7.2.20010531175313.024ed980(a)mail.netpath.net>, Andrew Dorsett writes: > >Hey, this is a technical question for all of the Network >Engineers/Architects on the list. Has a method been found to stop an >incoming attack? Granted you can filter the packets to null on the router, >but that doesn't stop them from coming across the wire and into the >router. Has a way been devised to stop them from coming into the router; >via something like a BGP update to null the packets or what? I'm concerned >about a flood that is so massive coming from the core and flooding a small >T1 or less. > See my talk (and the associated draft papers) from the D.C. NANOG; there were also several DDoS talks in Scottsdale. --Steve Bellovin, http://www.research.att.com/~smb

1 0

RE: jumbo frames
by RJ Atkinson 31 May '01

31 May '01

At 16:47 31/05/01, Lane Patterson wrote: >I have been tracking jumbo frame support trends for a while, and >am reasonably disappointed by lack of standards and vendor willingness >to support jumbos (yes there are very REAL h/w design considerations, >so until operators demand jumbo support and folks test it in realistic >environments, it's not going to happen). I believe most GigE switch vendors currently support ~9180 IP MTU over GigE interfaces. IEEE 802 committee has repeatedly and deliberately declined to make that an official standard however. A number of the host vendors (e.g. Sun) appear to be listening to customer requests for support of that IP MTU size also. >Unfortunately, many of the folks most adamant about maintaining 4470 >in their core are therefore sticking with POS everywhere, so their >requirement is not making it to the ether vendors. POS could be configured at various MTUs, right ? 4470 is just a historical choice equal to FDDI, right ? Folks could engineer their POS links to use ~9180, I think, if they wanted to do so. >There are different reasons to use several different sizing parameters: > > "Mini-jumbo": say 1518, 1540, etc. the idea here is that you > can handle stacked tunnels and LAN encapsulations, such > as stacked headers of 802.1Q, MPLS, IP/GRE tunnels, etc. > while still preserving "1500 for the edge" > > Applicability: 802.1Q, VPN, MPLS, and other encap-based > or tunnel-based applications I believe at least 802.1q support is quite commonplace these days. > "Mid-jumbo": say 4470: the idea is to make sure a backbone can > preserve its MTU across both ethernet, ATM, and POS links > within its diameter, and conceivably between networks via > IX's that support jumbos. This in fact may be critical > for folks running large ISIS implementations that need > to ration # of LSPs: This number derives from FDDI MTU, which was formerly commonly used as the basis for many an exchange point. >http://www.ietf.org/internet-drafts/draft-kaplan-isis-ext-eth-02.txt I believe IEEE 802 committee officially opposes the above draft, though I could be misinformed. > "Real jumbo": not standardized, Kindly see RFC-1626, which is where this number and rationale came from. The correct number, btw, is 9180 bytes as an IP MTU. > but somewhere between 8100-9100B,...

1 0

Re: Cisco ACL Manager(s)
by Ron Buchalski 31 May '01

31 May '01

How about this? http://www.mentortech.com/learn/tools/acclist.shtml It's been around for awhile, although I've never tried it. Unfortunately, there doesn't seem to be a link available to actually download the program, so you'll probably need to contact Mentor Technologies to get it. -rb >From: "Robert A. Hayden" <rhayden(a)geek.net> >To: NANOG <nanog(a)merit.edu> >Subject: Cisco ACL Manager(s) >Date: Thu, 31 May 2001 13:10:19 -0500 (CDT) > > >Any recommendations out there on software to make management of Cisco ACLs >a little easier than traditional manual ways? Doesn't even need to do the >insertion into the router, just be able to produce something that can be >cut-n-pasted into place. > >- Robert > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

1 0

Cisco ACL Manager(s)
by Robert A. Hayden 31 May '01

31 May '01

Any recommendations out there on software to make management of Cisco ACLs a little easier than traditional manual ways? Doesn't even need to do the insertion into the router, just be able to produce something that can be cut-n-pasted into place. - Robert

2 1

RE: QOS or more bandwidth
by Irwin Lazar 31 May '01

31 May '01

FWIW, I recently heard someone ask the question - "how do you go to your investors and tell them you need more money for more bandwidth because you don't want to efficiently manage your existing capacity?" This is the business case for QoS, IMHO. Irwin -----Original Message----- From: Sean Donelan [mailto:sean@donelan.com] Sent: Tuesday, May 29, 2001 2:18 AM To: nanog(a)merit.edu Subject: QOS or more bandwidth While its generally more effective to add more bandwidth than rationing it with QOS, with the recent downturn in capital markets will QOS become more popular? If your budget for bandwidth has been cut, I'm not sure people will have any budget for QOS either. But what QOS features are included in the standard product offerings?

7 6

Re: Mitch tries to defend his open relay again (was Re: ORBS (Re: Scanning))
by dlr＠bungi.com 31 May '01

31 May '01

[In the message entitled "Re: Mitch tries to defend his open relay again (was Re: ORBS (Re: Scanning))" on May 30, 22:16, Mitch Halmu writes:] > > On Mon, 28 May 2001, John Fraizer wrote: > > > If you want a huge laugh, (and want to give ole Mitch the /. or NANOG > > ... then laugh about this one: > > http://www.dmnews.com/cgi-bin/artprevbot.cgi?article_id=15323 > Without further comment, here's the MAPS press release on the topic. http://www.mail-abuse.org/pressreleases/2001-05-25.html --

1 0

RE: ORBS (Re: Scanning)
by Roeland Meyer 31 May '01

31 May '01

> From: E.B. Dreger [mailto:eddy+public+spam@noc.everquick.net] > Sent: Sunday, May 27, 2001 8:05 AM > ORBS catches far more than MAPS. As Randy stated "so does a hydrogen bomb". The problem is target acquisition and [the lack of] discrimination. The REASON tactical nukes aren't used regularly is the collateral damage issue. > My take is that anybody who has a > problem with the infrequent ORBS probes should have a huge > problem with the daily bombardment of relay attempts. A system that tests positive for ORBS , yet is using MAPS, will not be used as a spam relay. Yet, ORBS will list such a system. > Bottom line: Blocking mail from rogue servers is the best way to stop > spam and to not be a party to somebody else getting > relay-raped. Anyone with clue closed relays how many years ago? It is more accurate to state that most folks have placed guards on their mail systems. > I don't buy the "we need open relay for nationwide users" argument, > either. Build a cheap MX that does nothing but take mail from a given > POP, and send it to the world. Anti-spoofing at the border, > don't accept mail from the outside world, and you're done. You must not have a roaming staff or are willing to keep telcos wealthy.

14 27

experience with BGP on Extreme's Alpine
by Arnold Nipper 31 May '01

31 May '01

I know ExtremeNetwork's high position in L2, but don't have any idea how they perform on L3. Now an Alpine3804 might the right solution for a customer as he needs a loadbalancer, switch and router which also should do BGP. Any experience and hints welcome! Arnold

4 3

Re: jumbo frames
by Richard A. Steenbergen 30 May '01

30 May '01

On Tue, 29 May 2001, Dave Siegel wrote: > I've seen a lot of discussion about why one would want to do Jumbo > frames on your backbone...let's assume for the sake of argument that a > customer requirement is to support 9000 bytes packets across your > backbone, without fragmentation. > > Why not bump MTU up to 9000 on your backbone interfaces (assuming they > support it)? > > What negative affects might this have on your network? > > a) performance delivering average packet sizes > b) QoS > c) buffer/pkt memory utilization > d) other areas Theoretically increasing the MTU anywhere you are not actually generating packets should have no impact except to prevent unnecessary fragmentation. But then again, theoretically IOS shouldn't get buggier with each release. There will obviously be different packet handling techniques for the larger packets, and I'm not aware of any performance or stability testing that has been done for jumbo frames. I'm guessing the people who are actively using them havn't been putting it in line rate mixed small and large packets conditions. Obviously anything extra and uncommon you try to do runs the risk of setting off new bugs (even common stuff sets off new bugs). I can tell you some of the drivers I have seen for PC gige cards (especially linux) badly mangle jumbo frames and may not perform well. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

3 4

Wrap-up of the Yipes! query..
by Los, Ralph 30 May '01

30 May '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NANOG readers.... OK...this is a wrap-up of the Yipes! query I sent out a little while ago. In listening to all the responses I got back (most of which were, 'me too' queries), I've got the following picture of Yipes!..... 1. Their sales person is quick to introduce himself, but since this post, I've mad a query into company status, funding, and more serious engineering-type queries, with NO ANSWER. 2. They're not funded yet, and selling WAY below cost. Does this mean that a year from now they're going to triple their prices? worse? 3. I've heard 2:1 in horror stories about Yipes! not being able to deliver. Not even T-1's in these cases when a drop-dead delivery date was given. 4. I've heard a few short replies about "we're been using them for x months (2-6) and never had a problem, they deliver what they promise". But what about their support?....no one's seemed to have dealt that way yet. My verdict? I'm going to hold off, going to pursue Cogent (www.cogentco.com) and see if they have a better offering/stability platform. They appear to...give that a look if you have an interest in getting fiber. Good luck, thanks for the replies! Ralph M. Los Asst. Vice-President, Internet Systems and Security EnvestNet Advisory Corp. rlos(a)envestnet.com (312) 827-3945 (direct) (312) 296-9003 (wireless w/voicemail) -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQA/AwUBOxVgMHM6eMaR3AeZEQLVywCePuJj21rYvejIqYDdk9CXLRD85oEAnjnN ZVbFoS0uS4K+39CwciOaBbnK =rLr/ -----END PGP SIGNATURE-----

1 0