October 2002 - Test - lists.nanog.org

sprint passes uu?
by Richard A Steenbergen 15 Oct '02

15 Oct '02

I don't know if anyone cares or is keeping track, but it seems that Sprint has now passed UU in number of customer routes (or at least, routes sent to peers). x.x.x.x 4 1239 2396636 438162 61442761 0 0 9w3d 47637 x.x.x.x 4 701 3768775 499186 61442761 0 0 1w5d 45410 Looks like UU routes have been steadily falling, dunno if they aggregated (hah!) or just lost customers due to, well, you know. But by the metrics people/reporters have been using to declare UU "half the internet", it looks like they're now #2. -- 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)

7 9

Input requested for second edition of "Firewalls and Internet Security"
by Steve Bellovin 15 Oct '02

15 Oct '02

We've just about finished the draft manuscript for the second edition of "Firewalls and Internet Security" (this time by Bill Cheswick, Steve Bellovin, and Avi Rubin). Given the tremendous change in the market (including both the prevalence of commercial firewalls and widespread easy access to open source software), we're dropping the appendix that lists useful free software; we're replacing it by a list of important sources to monitor for word on new holes, major patches, etc. (We'll put up a draft table of contents on the book's web site some time this weekend.) So -- what are your favorite mailing lists, web sites, etc., for keeping your systems and networks secure? (To answer the obvious question: we don't yet know precisely when the new book will appear on the shelves. A lot depends on how much rewriting we'll have to do in response to the technical reviews. But some time in the spring looks to be a pretty good bet.) --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book)

1 0

Draft agenda for Eugene
by Susan Harris 15 Oct '02

15 Oct '02

Draft Agenda: NANOG 26 Oct. 27-29, Eugene, Oregon ARIN X: Oct. 30-Nov. 1 http://ww1.arin.net/ARIN-X/ SUNDAY TUTORIALS 1:30 - 3:00 p.m. Managing IP Networks with Free Software Level: Intermediate Stephen Stuart, ISC 1:30 - 3:00 p.m BGP Troubleshooting Techniques Level: Introductory/Intermediate Philip Smith, Cisco 3:00 - 3:30 p.m. BREAK 3:30 - 5:00 p.m. ISP Security - Real World Techniques II Barry Raveendran Greene, Cisco Kevin Houle, CERT 3:30 - 5:00 p.m. BGP Troubleshooting (cont'd.) 5:00 - 7:30 p.m. DINNER BREAK 7:30 - 9:00 p.m. IPv6 Basics Level: Introductory Tony Hain, Cisco Monday, October 28 ================== 9:00 a.m. Welcome, Introductions Lucy L. Lynch, Univ. of Oregon Dave Meyer, Sprint/UO John Curran, ARIN Board Chair Susan Harris, Merit 9:20 a.m. Update on the National Strategy for Cyberspace Security Marc Sachs, Office of Cyberspace Security 10:15 a.m. BREAK 10:30 a.m. How to Own the Internet in Your Spare Time Stuart Staniford, Silicon Defense Vern Paxson, ICSI/ICIR Nicholas Weaver, UC Berkeley 11:15 p.m. Operational Feedback to IP Equipment Vendors Vijay Gill, AOL Time Warner 12:00 p.m. LUNCH 1:30 p.m. Route Flap Damping: Harmful? Randy Bush, IIJ Tim Griffin, AT&T Research 2:00 p.m. Carrier-Class Availability for IP Networks Sanjay Kalra, Juniper 2:30 p.m. Traffic Characteristics and Network Planning Thomas Telkamp, Global Crossing 2:50 p.m. Fast Reroute - A High Availability Addition to MPLS Shankar Rao & Sohel Ahmed, Qwest Richard Southern, Juniper 3:20 p.m. BREAK 3:35 p.m. Panel: Services, Complexity, and the Internet: What Direction? Dave Meyer, Sprint, moderator Randy Bush, IIJ Vijay Gill, AOL Time Warner Lixia Zhang, UCLA Dave Ward, Cisco Thomas Telkamp, Global Crossing 5:30 - 7:30 p.m. Beer 'n Gear Monday Evening BOFs =================== 7:30-9:00 p.m. Toolmaker BOF Stephen Stuart, ISC, moderator 9:00-10:30 p.m. ISP Security BOF I Barry Raveendran Greene, Cisco Merike Kaeo, merike.com, moderators Tuesday, October 29 =================== 9:00 a.m. IPv6 Impressions: ARIN Update and Routing Table Overview Cathy Wittbrodt, Packet Design 9:45 a.m. Experiences With Developing, Testing, Planning, and Operating IPv6-Enabled Nameservers Paul Vixie, ISC 10:05 a.m. Commercial IPv6 Deployment by ISPs in Japan J. Hagino, IIJ/KAME 10:25 a.m. BREAK 10:40 a.m. Panel: Trends in Measurement and Monitoring of Internet Backbones Dave Meyer, Sprint/University of Oregon, moderator Chris Martin, Verizon Christophe Diot, Sprintlabs Jennifer Rexford, AT&T Research Mujahid Khan, Sprint Tony Tauber, Genuity 12:00 p.m. LUNCH 1:30 p.m. OC48 (and Above) Flow Sampling: Mice, Elephants and Needles in Haystacks Craig Labovitz, Scott Ikel-Johnson, Rob Malan, Michael Bailey, Arbor Networks 2:00 p.m. Scriptroute: A Public Internet Measurement Facility Neil Spring, David Wetherall, & Tom Anderson, Dept. of CSE, University of Washington 2:20 p.m. Panel: Persistent Route Oscillation - Issues and Solutions Sue Hares, NextHop, moderator Enke Chen, Redback 3:15 p.m. BREAK 3:30 p.m. Observation and Analysis of BGP Behavior under Stress Lan Wang, UCLA; Dan Pei, UCLA; Randy Bush, AT&T; Xiaoliang Zhao, Daniel Massey & Allison Mankin, USC/ISI; Felix Wu, UC Davis; Lixia Zhang, UCLA 4:00 p.m. Toward Lowering the Load on DNS Root Nameservers Duane Wessels, The Measurement Factory/ CAIDA 4:30 p.m. New Services From the RIPE NCC Henk Uijterwaal, RIPE-NCC 4:50 p.m. Adjourn Meeting web site: http://www.nanog.org/mtg-0210/

1 0

BTN-network
by Darrell Carley 15 Oct '02

15 Oct '02

All, I hope that this is an acceptable discussion. I am curious if anyone has worked with or may have any comments about BTN's service. Is this the company formerly known as CAIS/Ardent? I am a network engineer for a web-hosting/small ISP, and considering them as one of our providers. Any opinions and comments appreciated. Feel free to contact me off list @ darrell(a)natnet.com. Thank you, Darrell C. National Net

2 1

Re: [Re: the cost of carrying routes]
by Joshua Smith 15 Oct '02

15 Oct '02

Ratul Mahajan <ratul(a)cs.washington.edu> wrote: > > > i have related question to ron's (a bit hypothetical but interesting > nonetheless). > > if isps charged for bgp announcements, would the number of announcements > that shouldn't be made (e.g., those due to configuration errors and poor > operational practices) go down? > > -- ratul they could probably make some good money if they also charged for 'leaky' networks - however, i think the sentiment amongst their customers would not be favorable (you charge for misconfigurations? some nerve you have) it is probably one of those long term goals that you will almost never be able to convince the powers-that-be of undertaking. i know i am having a very difficult time convincing management that our network needs some help - although after several recent, fairly successful attacks, they are starting to listen. joshua > > -------------- > > On Mon, 14 Oct 2002, Ron da Silva wrote: > > > > > > > Some ISPs charge for actual bits carried (peak usage, actual count, > > whatever) in addition to or instead of per port/circuit charges. > > > > Do any ISPs charge based on the number of announcements a customer > > advertises? > > > > If downstream advertisements became mainly smaller prefixes (say /24) > > that were not aggregatable by you as their upstream ISP, would you > > answer the above question differently? > > > > -ron > > > "Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence." - Stephen Hawking -

1 0

the cost of carrying routes
by Ron da Silva 14 Oct '02

14 Oct '02

Some ISPs charge for actual bits carried (peak usage, actual count, whatever) in addition to or instead of per port/circuit charges. Do any ISPs charge based on the number of announcements a customer advertises? If downstream advertisements became mainly smaller prefixes (say /24) that were not aggregatable by you as their upstream ISP, would you answer the above question differently? -ron

3 2

RE: the cost of carrying routes
by Charles Youse 14 Oct '02

14 Oct '02

I think you're confusing commercial peering agreements with providing customers the ability to advertise their routes via BGP. Two different issues. C. -----Original Message----- From: Jeff S Wheeler [mailto:jsw@five-elements.com] Sent: Monday, October 14, 2002 5:11 PM To: nanog(a)merit.edu Cc: ron(a)aol.net Subject: Re: the cost of carrying routes Ron, Many carriers require that you advertise a certain minimum number of routes to them over your peering sessions, or they will not peer with you. This suggests that those carriers see routes carried as a point of value, rather than or in addition to one of cost. I have seen 5,000 routes as a minimum used by more than one transit-less carrier. Is this really an operational value perception at these carriers, or is it simply a means of creating a barrier-to-peering? Are fewer, shorter prefixes seen as more valuable than longer ones, e.g. swamp /24s? Is a University or other entity with a legacy /16 more or less valuable as a peer than a growing ISP with a few /20s, and presumably more eyeballs and/or content behind them? -- Jeff S Wheeler <jsw(a)five-elements.com> On Mon, 2002-10-14 at 16:47, Ron da Silva wrote: *snip* > Do any ISPs charge based on the number of announcements a customer > advertises? > > If downstream advertisements became mainly smaller prefixes (say /24) > that were not aggregatable by you as their upstream ISP, would you > answer the above question differently?

1 0

what's that smell?
by Paul Vixie 14 Oct '02

14 Oct '02

since the last time we cleared the firewall statistics on c.root-servers.net, 1895GB of udp/53 input has led to 6687GB of udp/53 output, but, and this is the important part now so pay attention, 185GB of input was dropped due to an RFC1918 source address. who needs DDOS when most network operators aren't filtering RFC1918 on output? (there's only been 4.2GB of udp/2002 and other wormy traffic, by comparison.) current winners of the "sustained input traffic over 100KBits/sec" award are 164.58.150.146, 200.52.12.131, and 195.146.194.12. c-root keeps on ignoring you, but you just never give up. congradulations, or something. (note that c-root's network operator has offered to filter RFC1918 on input from other AS's, but it's actually useful to keep on measuring it.)

25 52

Lumeta network mapping
by Sean Donelan 12 Oct '02

12 Oct '02

A couple of interesting research products have hit the commercial marketplace. Lumeta (www.lumeta.com) is selling a firewall rule analyzer, a pseudo-expert system which lets you ask questions about a firewall ruleset; and a network mapping system which helps find unexpected network connectivity. Have folks tried the commercial versions of Lumeta's products? Since both products are both essentially discovery tools, did people discover anything they didn't already know? While I would like both the network discovery and firewall analyzer as part of a toolkit, as stand-alone tools they seem limited. If you spend the money, Lumeta's products will tell you either what you already know, or they'll tell you about stuff you didn't know. But how do you know ahead of time whether or not you already know how the movie ends, and its worth the price of the movie ticket? I did like Bill Cheswick's comments on password aging. http://www.lumeta.com/asktheexperts/question17.html Once upon a time I decided to research the source of the change your password every N days rule. I tracked it back to the days of 300 baud modems. When was the last time your changed your 4-digit PIN on your ATM/bank card?

1 0

Re: Who does source address validation? (was Re: what's that smell?)
by Stephen J. Wilcox 12 Oct '02

12 Oct '02

On Tue, 8 Oct 2002, Greg A. Woods wrote: > [ On Tuesday, October 8, 2002 at 22:34:51 (+0100), Stephen J. Wilcox wrote: ] > > Subject: Re: Who does source address validation? (was Re: what's that smell?) > > > > > > So I guess you may argue block RFC1918 tcp inbound but icmp and udp .. you start > > to break things, perhaps that is why large providers dont do this on backbone > > links. > > Such things REALLY _NEEED_ to be broken, and the sooner the better as > then perhaps the offenders will fix such things sooner too, because they > are by definition already broken and in violation of RFC 1918 and good > common sense. Ok but real world calling. I have tried this and when customers find something doesnt work on your network but it does on your competitor you make it work even if that means breaking rules. You've snipped the other comments from my email which goes on to say take any RFC for a protocol eg POP, SMTP etc and look at whats actually being done with it, most commonly look at how Microsoft have implemented it or what the big ISPs are doing on their servers etc and you either tow the line or your service suffers. Steve

11 16