January 2000 - NANOG - lists.nanog.org

CEF Load balancing...
by Alex Rubenstein 17 Jan '00

17 Jan '00

Question (kinda operational).. I've been looking/asking around, but have yet been able to get the same answer twice to the following question: How many links can you have in parallel when using CEF load-sharing per-packet? Another words, we currently have a site that has four DS1s load balanced, in parallel (terminating in the same router on each end). Can you add a [5th|6th|7th|8th] ? Before you answer "BUY A DS3!", this is located in a rural area that a) really doesn't (easily) even have DS3 capabilites, and b) isn't cost effective to have a DS3 as it is about 15 times the cost of a DS1. Thanks for any insight!

11 14

Re: ICMP rate limiting on EGRESS (Warning, operational content inside)
by Sean Donelan 17 Jan '00

17 Jan '00

On Mon, 17 January 2000, bmanning(a)vacation.karoshi.com wrote: > Source routing and connection based services are creaping into > the Internet, slowly but surely. Both are a far cry from the > destination forwarding and connectionless service that I grew > up with. Yes, but as far as I know, none of the new services rely on the ability to spoof the source address outside of local (perhaps VPN extended) network. Even old services such as roaming and redirector applications have switched to using tunnels instead of spoofed source addresses. Are there any real-world applications which have no alternative but to use spoofed source addresses on the Internet at large? Or is this a case, if we had thought about it, we would have prohibited it at the start; but now its in the wild we don't know how to get it back in the barn.

3 4

ICMP rate limiting on EGRESS (Warning, operational content inside)
by Alex Bligh 17 Jan '00

17 Jan '00

It is reasonably well acknowledge that ratelimiting ICMP on *ingress* to your network can be a good thing to do, if you have available resources to do it. How about players rate-limiting ICMP on *egress* of the network over public exchange points. I have been on the wrong end of several smurfs over 100Mb/s over MAE-East & West, as, I'm sure have others. Whenever anyone is smurfed like this, I presume their port blocks, and anyone sending them data has head of line blocking. Which means, in effect, anyone peering with anyone who is being (sufficiently smurfed) will experience packet loss to *other* peers. By rate-limiting ICMP on output (to perhaps 3 or 4 times its nowmal value which here is 4 times 1% of normal traffic levels), then if one of your peers is being smurfed, you help save HoL blocking occurring. If your peer blocks these on ingress, it won't help - the packets will still get switched. >From what I am (unscientifically) seeing, packet loss over the MAE is spikey and can go through periodicity of badness not dissimilar to the length of such DoS attacks. I am not, of course, suggesting that this will solve all the MAE's problems. If the Gigaswitches could give even an approximation of total traffic that was ICMP, and see if peaks in this correspond to peaks in packet loss between routers on the MAE (not just across the switch fabric), we could even attempt to measure this. Is this a good idea? -- Alex Bligh GX Networks (formerly Xara Networks)

6 5

RE: CEF Load balancing...
by Martin, Christian 17 Jan '00

17 Jan '00

>We have a situation where CEF in a particilar 12.0.x version >broke the BVI >interface in an IRB configuration w/ATM. Then the next version broke >forwarding between an ATM interface and a Ethernet interface in an >interesting way (I haven't tracked down the specifics on the >second case >yet.) I've seen issues where CEF drives the CPU through the roof if it is doing per-packet balancing on interfaces that reside on different VIPs. I've also seen links drop out of a CEF load-balancing group and the Adj Table hashes not purge the down interface, or keep the hash indices the same, with only two interfaces instead of three, thereby doing 67/33 balancing instead of 50/50. The workaround is to diable and reenable CEF. On the positive side, you can easily aggregate 200+Mbps across 6 DS3s with minimal CPU and smooth, per-packet balancing. Process switching on steroids it is... Besides, to uses reverse-path filtering, dCAR, dWRED, etc, you need dCEF. It is stable in 11.1.26CC1 - we use it all over for load-balancing on DS3s... Chris > >All in all, CEF works wonders, if it doesn't break something with its >extra-fancy forwarding. > >- Forrest W. Christian (forrestc(a)imach.com) KD7EHZ >---------------------------------------------------------------------- >iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com >Solutions for your high-tech problems. (406)-442-6648 >---------------------------------------------------------------------- > >

1 0

Mae-West Stats and Nanog Archives
by Derrick Bennett 17 Jan '00

17 Jan '00

I was actually looking for current Mae-West Stats as the page I have ended last year. I thought someone had asked this recently but found that the nanog mailing list search site stopped in october of 99. Does anyone know where newer mae-west stats may be and if the archives for nanog will be updated soon ? Thanks, Derrick Bennett

2 1

Re: Mae-West Stats and Nanog Archives
by Sean Donelan 17 Jan '00

17 Jan '00

On Sun, 16 January 2000, Derrick Bennett wrote: > I was actually looking for current Mae-West Stats as the page I have ended > last year. I thought someone had asked this recently but found that the > nanog mailing list search site stopped in october of 99. Does anyone know > where newer mae-west stats may be and if the archives for nanog will be > updated soon ? I was told (going from memory, so I hope Steve will correct me) there was a SNMP problem collecting stats on mae-west last fall. Since MCI/Worldcom is changing to a new statistics package, instead of fixing the old ones, the new statistics should show up real soon. But I guess like many software projects its been delayed. Because the stats from Ameritech and the MAE's are essentially the only publically available measures of multi-provider Internet traffic, I hope they come back. Sprint & Pacbell/Bellcore used to have some stats, but all the links I had have stopped working. It would be nice to get some aggregate numbers for private interconnects, but I guess it isn't a realistic dream.

2 1

Re: Fw: Administrivia: ORBS
by Paul Vixie 17 Jan '00

17 Jan '00

> Paul Vixie's Mail Abuse Prevention System ... Ouch! Mail Abuse Prevention System LLC, has a pile of people associated with it, and I can't sit idly by and see it referred to as my possession. MAPS LLC is: Sean Fagan Technologist Nick Nicholas Evangelist Peter Popovich Principal Investigator, RBL Kelly Thompson Associate Director Al Iverson Principal Investigator, RSS Gordon Fecyk Principal Investigator, DUL JD Falk Product Manager While I may have founded it, the *only* work I still do for MAPS LLC is: funding nomination processing arguing on NANOG It's not "mine" and hasn't been "mine" since before it was six weeks old. -- Paul Vixie <vixie(a)mibh.net> >> But what *IS* the internet? > It's the largest equivalence class in the reflexive transitive > symmetric closure of the relationship "can be reached by an IP > packet from". --Seth Breidbart

2 1

Re: Fw: Administrivia: ORBS
by George Herbert 16 Jan '00

16 Jan '00

Danielle writes: >In effect, Above.net is (by filtering the ORBS probes) licensing every >single IP in their /16 to spam via the sordid and detailed means that >ORBS works to prevent. >This is an incorrect assumption? Please educate me as to how this is the >wrong way to view this. There seems to be some sort of implicit assumption in this, and many other postings to NANOG, that if you disagree with ORBS you must be pro-spam, or at least tolerant or neglegent with respect to it. Dave Rand is the CTO of Abovenet. Dave helped found the RBL with Paul Vixie, and has been involved at least on and off with MAPS LLC [I hope this is an accurate one sentence historical summary... someone can correct this if it isn't...]. As far as I can tell, there is no backbone provider which actually responds better to spam problems in its network than Abovenet does. They have one of the best AUPs out there and enforce it very, very well. Various folks who are and/or have been involved with ORBS have had antagonistic relationships with quite a number of other spam fighters over the years. This has led to admitted incidents where non-open-relays were ORBS listed because they were run by people who were disagreeing with ORBS in public. Although any sort of generalization has its flaws, the RBL-centric anti-spam crowd on the spam@zorch list generally believes that ORBS and its approach of netblock scanning and test messages are net abuse, beyond appropriate responses to spam, and that ORBS is run by people who put personal conflicts at the same level as actual spam problems. Part of this obviously is just personality and politics. At the technical and operational level, though, this has significant impacts: a wide number of people who are undoubtedly actively anti-spam believe ORBS scanning constitutes net abuse, and believe that ORBS listing of persons who merely have personal conflicts with ORBS operators is inappropriate for a resource being used by such a large portion of the net. This is more or less the whole reason why RBL/MAPS started the RSS; the RSS is, arguably, what ORBS should have been all along: it doesn't scan for open relays unless a valid report is in hand that the relay is being abused. It uses RBL's professionalism and documented policies so that it has publically known and trusted behaviour rather than arbitrary and personal. For all of those reasons, it is quite possible to be actively and responsibly anti-spam but very much opposed to the methods of ORBS. I personally believe that ORBS has consistently taken actions which are in the long run going to have negative consequences on the efforts to combat spam, such as the personal attack listings and such, and its antagonizing any number of networks by refusing to stop scanning them. I urge anyone who is using ORBS to consider these issues, research the RBL/MAPS approach (http://maps.vix.com/) and reconsider whether ORBS is, in the long run, the approach to spam blocking which is best for you and for your networks. The ORBS approach is not the only viable one, and not the only valid one, and while it does work the negative consequences of its approach should not be ignored. Please note that I am not speaking for MAPS, the RBL, or anyone else in this matter other than myself (I have done some minor stuff for the RBL before but am not actively involved now), though I believe that the consensus opinions from the spam@zorch crowd that I have paraphrased above accurately represent that mailing list / group of people's opinions on the subject. I also would like to note yet again that I am not at this time and have not been for some years a CRL employee, just a shell account end user, and my opinions on this matter should not be associated with CRL in any way. -george william herbert gherbert(a)crl.com

1 0

Re: Fw: Administrivia: ORBS
by Brian Dickson 16 Jan '00

16 Jan '00

Greg Woods wrote: > [ On Friday, January 14, 2000 at 12:24:32 (-0800), J.D. Falk wrote: ] > > Subject: Re: Fw: Administrivia: ORBS > > > > Unfortunately, ORBS does not allow for people who DO know > > about relays, and DO close them, and don't want to be scanned > > anymore. In the ORBS world, that simply isn't an option. > > > > That's where most of the sane anti-ORBS sentiment comes from. > > If your mailers were abused, reported to ORBS and listed, fixed, and > finally cleared from ORBS then please don't prevent ORBS from testing > them again in the future -- that is your guarantee that we won't > individually block your mailers again with our own private lists. I think the issue most people aren't certain of, is when is it reasonable to test a machine, in the manner ORBS does? Let's consider various possibilities, in an order somewhat resembling decreasing reasonable-ness. [My comments on these are bracketed.] 1) If your mailer receives an incoming connection request on port 25, it's pretty reasonable to test the machine from which the request comes. The logic here is pretty solid - before accepting a connection from another mailer, it is reasonable to want to verify that it isn't an open relay being used for spam. For efficiency, perhaps such testing could be limited to incoming requests from machines listed on ORBS or similar sites. If an ORBS-like list, maintained based not on pre-emptive testing, but on at-receive-time non-open-relay verification, this would be pretty benign. The question for this list would be, how can you ensure that any submission from participants is authentic? - have this ORBS-like list *not* trust submissions, per se; - rather, have the machine(s) hosting the list, added as MX entries *for* participants (ie, participants add the MX) - participant machines, upon detecting mail connection requests from a machine, does the following: - check to see if it is listed - if yes, refuse connection - if no, check directly if it is an open relay -if so, refuse the connection Refused connections (listed, or detected open relay) result in the open relay trying MX hosts with larger MX values, until the ORBS-like machine is tried - the ORBS-like machine, would then do its identical check, only because the sending machine was trying to forward mail through it; thus it is no longer pre-emptive. - if already on list, either refuse connection, or test again - if sending machine is determined to be an open relay, add to list [IMHO, this would be both non-pre-emptive, scalable (although with a small ramp-up problem), yet centralized enough to be useful to large and small sites alike. The central machine(s) would clearly need to re-do their testing periodically (not necessarily every time someone from a listed site tries to send mail!), and would need to be capable of handling a huge number of connection requests. I defer to the MTA-gurus as to whether this is do-able in practical terms.] [If anyone is considering implementing this - *please* be sure to put in place checks to avoid mutual- checking run-away recursion!.] 2) Hosts listed in any domain as an MX host. Unfortunately, in neither DNS nor in the IANA assigned ports, is there any distinction between an MDA and an MTA. An MX is a proxy-MDA, which by necessity is an MTA. There is no corresponding "Relay" record for DNS, which *would* be something always valid to test. In the absense of the distinction, the MX meaning could be overloaded (to use the c++ term) to include relay; the question would then become one of whether it is reasonable to test hosts that actively advertise the fact that they are relays. (What would have been really sweet, is if there were separate ports for local deliver (MDA) and transport (MTA). Then, machines with MDA, but no MTA, would never forward mail; they could locally initiate mail, and receive mail for delivery, without being any kind of relay (open or closed). This would reduce the set of hosts needing to be tested, to those with MTA ports accepting connections. It would also mean the default config for any such machine would normally be MDA and no MTA; only MX and Relay machines would have MTA turned on.) [IMHO, there's no clear line on pre-emptive testing; clearly, major mail hubs (closed relays, MX machines, large mailservers with lots of users) have to worry about (a) spam, and (b) scaling issues, and any kind of pre-emptive spam-avoidance is (1) welcome, and (2) maybe necessary.] [If the pre-emptive testing resulted in lists of known-good (machines *known* to be *not-open* for relay), then this would be, in effect, an opt-in/opt-out mechanism; then sites who don't wish to allow testing by a testing-agent, would still need to be verified when mail is received from them; this verification could be cached by mailhubs (and kept for some well-defined interval, such as the refresh period from the SOA for the zone for the sending machine.) Testing of such opt-out sites would then be done only by parties receiving mail from them, not by anyone else. I think that would keep most folks happy.] 3) Hosts listed with A records for any "main" zone, eg "foo.com". If there is no MX record, but there is an A record, which would be used for mail to that zone, it is reasonable to presume that spammers will attempt to use the machine. (Or is it? I'm playing devils advocate, here.) [IMHO, this is reasonable iff (2) is reasonable.] 4) Hosts whose names can be found by zone-tranfer from a "main" zone. If administators for a zone operate a nameserver which does not do ACL-based restrictions on zone-transfers, is it reasonable to presume that any server listening to port 25 is more likely to be an open relay? [IMHO, regardless of SMTP testing, anyone doing this check should notify admins where this is permitted, that they might want to not permit this.] 5) Hosts listening to port 25. [IMHO, Occams razor would have drawn blood already.] -- Brian Dickson, Email: briand(a)teleglobe.net Director, Backbone Engineering Tel : +1 703 755 2056 Teleglobe Communications Corp., Fax : +1 703 755 2648 Rm 3214, 11480 Commerce Park Drive, Cell : +1 703 851 9053 Reston, Virginia, USA, 20191 http://www.teleglobe.com

5 7

Trust in cyberspace
by Sean Donelan 16 Jan '00

16 Jan '00

I visited the bookstore (you know, those places you bought books before Amazon.com) and picked up a copy of "Trust in cyberspace." Although much of the book is concerned with "security," I was pleased to see some coverage of other problems which reduce people's confidence in network systems. The chapter on the "Public Telephone Network" (PTN) and the Internet trustworthiness has a very good overview of the design decisions, types of failures and attacks. Unlike many cyber-assurance studies which only focus on the "hacker" attack; congestion, link failure (aka Backhoe attack), and operator error are included in this book. Most of us are aware of the security weakness with the current Internet, but this book is one of the first I've seen to list several weaknesses in the Public Telephone Network in on place. One oversight is the book doesn't really explain the definition of "failure" or "outage" varies between the PTN and the Internet. So you can't easily compare reliability measurements between them. The famous 99.999% reliability of the PTN doesn't translate to the Internet because the Internet measurements include things normally excluded by the PTN measurements, e.g. congestion. One important buzzword I would call your attention to is "Minimum Essential Information Infrastructure." This is a creation of a RAND researcher in 1995, and is percolating around the cyber-assurance groups.

1 0