- NANOG - lists.nanog.org

RE: DNS DOS increasing?
by Karyn Ulriksen 21 Jan '02

21 Jan '02

RE: DNS DOS increasing?I've seen this behavior before, also. I thought it was interesting that two servers side by side recieving the same attacks/ratios only serving DNS (BIND 8.2.x*) and acted in this manner: Redhat 6.2 w/dual proc 833 512/ram started "loosing" RR records Solaris 7 on a Sparc 10 (hehe) w/256 rebooted and served the correct records I'm curious to see how other OSes react to these attacks. My guess is that BSD systems (such as FreeBSD and BSDi) will react similarly to the Solaris based on my past experience with these systems. So I am curious too see if the RR record "loss" is an OS specific behaviour, especially since Redhat has priors in misplacing information in earlier versions of the OS. * I say BIND 8.2.x, because this continued to occur through the various BIND 8.2 releases. Best regards, Karyn Ulriksen Valkaryn Internet Group URL: http://www.valkaryn.net email: valkaryn(a)valkaryn.net =========================================== "Decisions should be made in the space of seven breaths." -----Original Message----- From: Karyn Ulriksen [mailto:valkaryn@valkaryn.net] Sent: Monday, January 21, 2002 8:39 AM To: James Smith Subject: RE: DNS DOS increasing? I've seen this behavior before, also. I thought it was interesting that two servers side by side recieving the same attacks/ratios only serving DNS (BIND 8.2.x*) and acted in this manner: Redhat 6.2 w/dual proc 833 512/ram started "loosing" RR records Solaris 7 on a Sparc 10 (hehe) w/256 rebooted and served the correct records I'm curious to see how other OSes react to these attacks. My guess is that BSD systems (such as FreeBSD and BSDi) will react similarly to the Solaris based on my past experience with these systems. So I am curious too see if the RR record "loss" is an OS specific behaviour, especially since Redhat has priors in misplacing information in earlier versions of the OS. * I say BIND 8.2.x, because this continued to occur through the various BIND 8.2 releases. Best regards, Karyn Ulriksen Valkaryn Internet Group URL: http://www.valkaryn.net email: valkaryn(a)valkaryn.net =========================================== "Decisions should be made in the space of seven breaths." -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of James Smith Sent: Monday, January 21, 2002 7:08 AM To: nanog(a)merit.edu Subject: RE: DNS DOS increasing? I've seen DOS-type behavior where a client will query a resolver for a name that doesn't exist, and the client does not accept the answer that the name does not exist and immediately sends another query, regardless of whether or not the resolver declared itself authoritative for the negative answer. -- /ak Get ready for more DOS-like behavior as systems get deployed that have 10 second TTLs in the DNS. These systems are used to provide multi-isp redundancy by pinging each upstreams router, and when a ping fails, start giving out a dns response using the other ISP IP range. Same FQDN, new IP. This of course is driven by the desire for redundancy in small businesses who make the Internet an integral part of their business plan. Either they can't get PI space and don't have (or don't want to spend) the $$$ to do BGP, or are unable to convince their upstream to cut a hole in their CIDR block and allow a 2nd party to announce that chunk (which for some is as small as /28). James H. Smith II NNCDS NNCSE Systems Engineer The Presidio Corporation

2 1

RE: Network Security Policies
by Steve Smith 21 Jan '02

21 Jan '02

This may or may not help. http://net-services.ufl.edu/~security/security-links.html Steve -----Original Message----- From: Hauser, Dewitt C, IV (Clint), SOBUS [mailto:dchauser@att.com] Sent: Monday, January 21, 2002 11:13 AM To: 'nanog(a)nanog.org' Subject: Network Security Policies At the moment, we're firming up our policy on access to Networking Devices and the like. In support of this, I'm looking for any links to white papers or other such sources that discuss/support the following things: - Limiting the number of people with access - Scheduled password change/rotation - Password change when someone with access leaves I'm going to be doing research on this to drag things up myself, but I figured I would put this out here to ask to provide some narrowing down of the search and speeding it up. Thanks in advance. -- Clint Hauser AT&T Solutions

1 0

NANOG 24 (Miami) Meeting Updates
by Carol Wadsworth 21 Jan '02

21 Jan '02

NANOG 24 Meeting Updates A partial list of presentation topics for NANOG 24, February 10-12, in Miami is now posted on the web: http://www.nanog.org/mtg-0202/topics.html For additional meeting information, please see: http://www.nanog.org/mtg-0202/index.html For those of you who have registered to attend the meeting, we look forward to seeing you in Miami and would like to remind you about two upcoming deadlines: January 24 -- the NANOG room block at the hotel expires. For reservation information, please see: http://www.nanog.org/mtg-0202/hotel.html January 25 -- if your registration fee is unpaid by this date, the fee increases $50. To check on your payment status, please reference the attendee list at: http://www.nanog.org/mtg-0202/attendee.list.html See you there!

1 0

state of the art in router configuration
by Ratul Mahajan 21 Jan '02

21 Jan '02

after a study on bgp misconfiguration (http://www.cs.washington.edu/homes/ratul/bgp/index.html) i am beginning to wonder what the state of the art in router configuration is. a quick search on the web did not yield anything interesting. thoughts on the matter from guys who configure routers would be appreciated. 1. how do most operators configure their bgp (text editor or some high-level configuration tool)? 2. are there "configuration checkers" out there that would check whether an operator has not made a common error while modifying configuration? 3. when misconfigurations do happen, how are they detected? thanks, -- ratul

2 1

[OT] Routeing `listeners' for BGP and ISIS
by Richard Mortier 21 Jan '02

21 Jan '02

Hi, I believe this is appropriate for the NANOG list according to the AUP; my apologies if it isn't or if you receive multiple copies. I'd like to announce the release of `PyRT' the `Python Routeing Toolkit' available at http://www.sprintlabs.com/Department/IP-Interworking/Routing/PyRT/index.html >From the web-page: "The Python Routeing Toolkit (`PyRT') enables routeing information in a network to be collected. The purpose of this software is to enable routeing information in a network to be collected. This package currently supports BGPv4 and ISIS and will dump MRTD format files. It also supports parsing of MRTD TABLE_DUMP files (as available from, eg., RouteViews and RIPE/RIS). A number of utilities for manipulating these dumps are also provided." Information is collected by forming adjacencies with a router, and then acting as a `passive' router (ie. no routes are injected). It is released under the GPLv2 and was developed as part of work done at Sprint ATL, Burlingame CA. -- Richard Mortier ---------------------- ----------------- ---- Intern, 1 Aug--28 Feb, mort(a)sprintlabs.com ----- Sprint ATL, Burlingame, CA mort(a)ieee.org ----- http://www.cl.cam.ac.uk/~rmm1002/

2 1

Re: Persistent BGP peer flapping - do you care?
by Dave Israel 20 Jan '02

20 Jan '02

On 1/17/2002 at 14:21:59 -0800, Jake Khuon said: > As for propogation of the bad prefix... well that soapbox has worn paint on > top. If people aren't going to bother following specs in the first place > I'm not sure a new spec will solve anything. It's a question of robustness; if the new spec includes a way to be tolerant of how the spec is (or can be) commonly abused, then the followers of the spec will not be at the mercy of those who deviate. In this case, I think that having the option to keep a session that gives bad routes up, and just dropping the route, is a good answer. That would allow the user to determine which is preferable for a given peer: possible corruption or certain disconnection. -Dave

4 3

Re: Persistent BGP peer flapping - do you care?
by Susan Hares 19 Jan '02

19 Jan '02

vijay: What else causes repeative peer bounces other than the broken prefix? sue PS - I'm away from work from now until Monday morning.. At 05:42 PM 1/17/2002 -0500, Vijay Gill wrote: >On Thu, 17 Jan 2002, Dave Israel wrote: > > > It's a question of robustness; if the new spec includes a way to be > > tolerant of how the spec is (or can be) commonly abused, then the > > followers of the spec will not be at the mercy of those who deviate. > > > > In this case, I think that having the option to keep a session that > > gives bad routes up, and just dropping the route, is a good answer. > > That would allow the user to determine which is preferable for a given > > peer: possible corruption or certain disconnection. > >If you have a "bad route" how do you know the rest of the update is good? >The nlri may have gotten corrupted on the wire or between the interface >and the processor (parity error, or some sort of corruption on the bus). >Given that case, in an update, I am not sure you can make a determination >of what is good nlri and selectively propogate and process those. See also >meltdowns circa nov 1998. > >/vijay

3 2

Perhaps OT: Thoughts on venture technology
by Christopher J. Wolff 19 Jan '02

19 Jan '02

Dear List, Allow me a moment to state, mainly, that the NANOG group reprents a far greater aggregate of technological intellectual property than could ever be assembled in any tight-knit telecom or dot-com operation. And, That many of us, according to human nature, have dreams and desires that may be fettered by the boundaries of our corporations, or fettered by the lack of corporation (my condolences to those who have experienced the impact of downsizing). Therefore, I would like to share my recent epiphany. My partners and I founded Broadband Laboratories to act as the foundation to incubate our bleeding-edge technological dreams into a production quality reality. My thought was to open up the "Laboratory" function to teams of NANOG members coordinated to develop, from soup to nuts, selected technology projects proposed by other NANOG members. At this juncture I would like to offer coordination of project management, datacenter, and connectivity resources for selected technology projects. A great example would involve distilling interdisciplinary teams of NANOG members to pursue several development projects. The compensation plan is a straightforward joint venture. You commit X resources with an agreed-upon cash value. I commit X resources with an agreed-upon cash value. If this is a "for profit" project, any proceeds generated by the project are returned to cover our pre-negotiated costs. Any profits generated by the project are split evenly as our reward. If this opportunity interests you, please drop me a note. If you are not interested, thank you for letting me take a moment out of your day. Regards, Christopher J. Wolff, VP, CIO Broadband Laboratories http://www.bblabs.com

1 0

Persistent BGP peer flapping - do you care?
by Susan Hares 19 Jan '02

19 Jan '02

NANOG -- We are finalizing a revision of the BGP specification. It is in last call for your new BGP specification. This BGP revision is to match the bgp in deployment. One part of the specification remains, a fix for a problem called "persistent bgp flapping". We urgently need input from nanog folks on what is deployed. Here's the description "presistent bgp flapping" from the BGP specification: >If a BGP speaker detects an error, it shuts down the connection >and changes its state to Idle. Getting out of the Idle state >requires generation of the Start event. If such an event is >generated automatically, then persistent BGP errors may result >in persistent flapping of the speaker. 1) Do any of the ISPs see the persistent bgp peer flapping now? Does anyone from the ISP community ever experience anything like this BGP persistent peer flapping? The solution is to have an exponential backoff in the rate of sending the Opens. If you have seen this, how many routers did this persistent bgp peer flapping impact? (Can you give a % of your routers or a total number)? How often does this impact your routers? 2) Is this feature on in your machine by default? If not, do you configure the exponential rates? 3)Do you track if your routers are in this state? How do you track if your routers are in this state? Sue Hares

7 8

The Cidr Report
by CIDR Report 19 Jan '02

19 Jan '02

This is an auto-generated mail on Fri Jan 18 23:00:00 PST 2002 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 18Jan02 0) General Status Table History ------------- Date Prefixes 040102 104733 050102 104575 060102 105090 070102 105136 150102 104579 160102 104712 170102 104584 180102 104688 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 12251 Number of ASes announcing only one prefix: 7411 (4204 cidr, 3207 classful) Largest number of cidr routes: 732 announced by AS701 Largest number of classful routes: 1380 announced by AS701 1) Gains by aggregating at the origin AS level --- 18Jan02 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1172 901 271 23.1% Telstra Pty Ltd AS701 1380 1147 233 16.9% UUNET Technologies, Inc. AS4151 287 155 132 46.0% USDA AS577 321 197 124 38.6% Bell Advanced Communications Inc. AS16473 198 77 121 61.1% Bell South AS7018 810 695 115 14.2% AT&T AS6595 169 61 108 63.9% DoD Education Activity Network As AS705 288 185 103 35.8% UUNET Technologies, Inc. AS852 401 302 99 24.7% Telus Advanced Communications AS17557 179 83 96 53.6% Pakistan Telecom AS19632 95 13 82 86.3% Metropolis Intercom S.A. AS2048 185 105 80 43.2% State of Louisiana AS1239 469 389 80 17.1% Sprint AS12302 110 31 79 71.8% MobiFon S.A. AS7046 305 227 78 25.6% UUNET Technologies, Inc. AS4755 224 152 72 32.1% Videsh Sanchar Nigam Ltd. Autonom AS703 284 222 62 21.8% UUNET Technologies, Inc. AS3464 160 98 62 38.8% Alabama SuperComputer Network AS724 217 158 59 27.2% DLA Systems Automation Center AS4200 110 53 57 51.8% Apex Global Information Services, AS16758 63 6 57 90.5% IKON Office Solutions AS4323 381 325 56 14.7% Time Warner Communications, Inc. AS226 145 89 56 38.6% Los Nettos AS6471 121 66 55 45.5% ENTEL CHILE S.A. AS3908 316 261 55 17.4% Supernet, Inc. AS19834 63 8 55 87.3% NetForce, Inc. AS7303 104 51 53 51.0% Telecom Argentina Stet-France Tel AS2149 315 262 53 16.8% Performance Systems, Inc. AS13999 66 14 52 78.8% Mega Cable S.A. de C.V. AS1 496 445 51 10.3% BBN Planet Total 53624 41950 11674 21.8% For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0