Re: stats on spam?
On Sun, 7 Jul 2002, deeann mikula wrote: can anyone point me to any current statistics on the amount of email traffic carried on the internet that is actually spam? The Wall Street Journal has an on-going series about UCE/Spam. Today's article is about Hotmail. According to the article Hotmail gets approximately two billion e-mail messages a day, 80% of them are spam. Hotmail Has Quite a Job to Save Its E-Mail Empire From Spam by Lee Gomes http://online.wsj.com/article/0,,SB1026085791622086280,00.html?mod=technology%5Ffeatured%5Fstories%5Fhs
Re: Internet vulnerabilities
On Sun, 7 Jul 2002, Richard A Steenbergen wrote: I think the problem they are refering to is what happens if your routing topology changes (or worse, flaps). A stateful connection (like TCP) which would have stayed up during a routing change could potentially be shifted to a different server which obviously wouldn't know the other one's state. Yes. As I said in a previous message in this thread, that's a common objection brought up by people who've never run an anycast network and are trying to think of reasons why it might be problematic. But since in the real world that appears to happen two orders of magnitude less frequently than connection failures due to loss of connectivity, _when you take no steps to prevent it_, and the prevention is both trivial and necessary with HTTP, which is the protocol most commonly anycasted, it's not an issue at all. -Bill
Assistance with a Customer Network Staffing Support Levels
Good Evening: I'm looking for any kind of industry benchmark data to help me justify IT head count. We're also looking for the same kind of data that you may uses in order to justify IT head count. Things like, How many engineers per device? At what point should the set up internal help desks? Number of trouble tickets per technician, Number of changes per engineer, etc.etc. Can you point me in the right direction to get this information? Thank you in advance for any help you can offer. Regards, Ryan _ Send and receive Hotmail on your mobile device: http://mobile.msn.com
rewars/benefit bogon filters
Looking for some statisitcs from some dataminers out there Bogon lists? How effective are they? DDoS scripts are abundant to those who seek them. Am I going to reep any rewards by taxing my edge routers an extra 25 lines of ACL? Who out there has some stats I can look at? And by posting this, am I diminishing its value? provide..comment...Best practice? jnullPGP: 0x54B1A25C"!" It's the little things
Re: AS number inconsistencies
On Mon, 8 Jul 2002, Marwan Fayed wrote: I am a CS PhD student trying to track ASes (for reasons I'm happy to discuss offline). There is a grave inconsistency I have come across and can't explain. Simply, there seems to be many AS numbers in the non-private range that come into use at some point in time and advertise a range of IPs, but these AS numbers are not allocated until much later. More specifically, archived BGP tables show many AS numbers which ARIN shows not to have allocated (in their allocation history tables) until many months, sometimes a year/two, later. The number of such ASes has shrunk over time (from about 100 in 1999/2000 to 20-30 in 2002) but still exists. I don't want to name ASes grin. Does any one have any explanations? Are network operators notified of their new AS number well in advance of the actual receipt of that number on paper, for example? Any help is appreciated (and hopefully this occurence is of interest to nanog). The most plausible explanations I can think of for people not using their ASNs in their production networks for a long time after receiving them from their RIR are: 1) There are technical challenges to be overcome before the AS can start to originate routes. For example, the AS migrations, or some other large network cutover or architecture change. 2) After the ASN is allocated, business/technical drivers shift as they often do in this industry, and the project that required the new ASN is now pushed back/scaled down/eliminated entorely. I've seen examples of both in the wild. jms
Re: AS number inconsistencies
More data would be useful to answer this question. I have not done any research to answer these questions myself, but here are some additional points which may further clarify your own search: - Do these Premature ASes announce the same routes before and after they are registered? - Do these PASes announce new routes, or do they announce routes that already exist in the global tables via some other legitimate AS? - Do these PASes appear from behind the same transit ASes before and after they are registered? - Is there oscillation in appearances of these PASes before official registration? In other words, do they only appear for a few hours at a time in the period before they're officially registered? There have been instances of rogue network operators announcing networks in order to cause disruption (think DNS cache attack) in whack-a-mole style where the AS will appear and disappear very quickly in order to give some minimal additional difficulty in tracking down the culprit. The questions I ask above, if answers are available, would be able to classify some of these attacks and allow for further examination versus some other, yet unidentified cause. Or, is it the case that _all_ off the PASes are then legitimately registered at some point in the future? It may be the case that a savvy network attacker would pick soon-to-be-legitimate or once-were-legitimate-but-are-now-unused ASes for their attack, but I would bet that at least some would pick ASes that don't come from an easily overlooked range. JT Hi All, This is my first post to this list so please forgive me if it's in any way inappropriate, and as I know everyone has work to do, I'll try to be brief. I am a CS PhD student trying to track ASes (for reasons I'm happy to discuss offline). There is a grave inconsistency I have come across and can't explain. Simply, there seems to be many AS numbers in the non-private range that come into use at some point in time and advertise a range of IPs, but these AS numbers are not allocated until much later. More specifically, archived BGP tables show many AS numbers which ARIN shows not to have allocated (in their allocation history tables) until many months, sometimes a year/two, later. The number of such ASes has shrunk over time (from about 100 in 1999/2000 to 20-30 in 2002) but still exists. I don't want to name ASes grin. Does any one have any explanations? Are network operators notified of their new AS number well in advance of the actual receipt of that number on paper, for example? Any help is appreciated (and hopefully this occurence is of interest to nanog). Thanks, --marwan ps. If one wishes to refer to a cluster of members of nanog, are they referred to as NANOs? (Not to be confused with the salutation made famous by tv's Mork Mindy, of course) :-) Theatre is not supposed to change the world, but it can show the world can change. --unnamed director
Bogus bogon?
Something looks wrong here: ; host ns.eu.sun.com ns.eu.sun.com A 192.18.1.3 ; wget -q -O- http://www.cymru.com/Documents/bogon-dd.html | grep '192.18' B192.18.0.0 255.254.0.0/BBR B192.18.0.0 255.254.0.0/BBR B192.18.0.0 0.1.255.255/BBR B192.18.0.0 0.1.255.255/BBR The bogon list references rfc2455 as mentioning 192.18.0.0/15, however the subnet is never referenced in it. In fact, no IP addresses appear to be in rfc2455, and the network seems to be a perfectly legitimate block containing two /16's (Sun, Agere) and one /24 more-specific in Sun's /16 block (mrc-apu.cam.ac.uk). Rob? An experiment in social engineering? :-) David.
Re: Bogus bogon?
Hi, David. ] Something looks wrong here: EEEK! Looks? IS! A thousand apologies to the folks at Sun. This should be RFC 2544 and 198.18.0.0/15. Both have been fixed now. David, thanks for pointing this out. You've won a spot in the coveted CREDITS section. :) ] Rob? An experiment in social engineering? :-) No, an experiment in not-enough-coffee-and-making-mods-late-at-night. :) Thanks and apologies! Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: WorldComm Fiber Cut????
MFNs status page is: http://www.mfn.com/network/ip_networkstatus.shtm#sjc Jane Sean Donelan wrote: On Sun, 7 Jul 2002, Gerardo A. Gregory wrote: Can someone from WorldComm please verify a fiber cut that happened today at around 11:30 am (Central). I have bveen informed that a fiber cut in Illinois (or Indiana) has been in effect (until just a few minutes) for all of the afternoon and most of the evening. Worldcom is reporting a problems near Chicago. Earthlink is reporting problems affecting its customers in Indiana, Illinois, Iowa, Michigan, Wisconsin and Ohio. http://help.mindspring.com/netstatus/ http://www.noc.uu.net/ Cable Wireless is showing delays out of Cleveland, Ohio http://sla.cw.net/ ATT and Sprint aren't reporting any problems. http://ipnetwork.bgtmo.ip.att.net/index.html http://www.sprint.net/ MFN's and PSI's network status pages have stopped working for me, so I don't know if they are having problems. http://www.above.net/html/techlog.txt http://www.psi.net/cgi-bin/netstatus.pl5
RE: Internet vulnerabilities
RFC1546. Really, anycast is a bad name for it. nearcast or closecast might be better. Anycast just has a nice ring... - Daniel Golding -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Marshall Eubanks Sent: Friday, July 05, 2002 7:44 AM To: Bill Woodcock; Marshall Eubanks Cc: [EMAIL PROTECTED] Subject: Re: Internet vulnerabilities On Thu, 4 Jul 2002 18:43:44 -0700 (PDT) Bill Woodcock [EMAIL PROTECTED] wrote: On Thu, 4 Jul 2002, Marshall Eubanks wrote: Is this the anycast based on MSDP ? Anycast, not multicast. -Bill But the only IPv4 anycast that I know of does use MSDP : http://www.ietf.org/internet-drafts/draft-ietf-mboned-anycast-rp-08.txt Is there a different proposal ? What's the RFC / I-D name ? Regards Marshall
Re: rewars/benefit bogon filters
On Mon, Jul 08, 2002 at 07:13:51AM -0500, jnelson wrote: Looking for some statisitcs from some dataminers out there Bogon lists? How effective are they? DDoS scripts are abundant to those who seek them. Am I going to reep any rewards by taxing my edge routers an extra 25 lines of ACL? Who out there has some stats I can look at? For better performance, turn on RPF loose at your borders. As for effectiveness, expect around a 40% drop in random source DoS. This may or may not be useful to you at all. When most people refer to bogon filtering, they're talking routes not packets. I suppose if someone was determined they could write a DoS which uses only valid source addresses, but there are two reasons why they don't: 1) Kiddies don't know and/or care, as long as they type ./ and you go down. 2) A fair amount of the overhead in a traditional raw socket high pps DoS is in the random number generation with every packet. In order to get a perfectly sourced DoS they would probably cross the point of diminishing returns where the overall packet rate falls below what they were generating before even minus RPF filters. Personally I'd almost rather keep the extra 40% of the attack and have the immediate cues and traceability provided by spotting obvious bogons coming in. Or use a Juniper, and do both. :) -- Richard A Steenbergen [EMAIL PROTECTED] 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)
RE: WorldComm Fiber Cut????
Title: RE: WorldComm Fiber Cut Ah, but she didn't say she believed it. Just said where the data was... Do we really need to verify what it shows? At best, it shows that they have spotty reporting. At worst, it shows rather severe reliability problems. Take your pick... James H. Smith II NNCDS NNCSE First Call Response Center Professional Services - Network Engineer The Presidio Corporation -Original Message- From: Internet Guy [mailto:[EMAIL PROTECTED]] Sent: Monday, July 08, 2002 12:22 PM To: [EMAIL PROTECTED] Subject: Re: WorldComm Fiber Cut HHHMMM... Very interesting. Someone who believes what a carrier really tells them. If you go to the MFN homepage click on the graphs listed below, then you might see that possibly the data being displayed is both inaccurate, as well as misleading. Go to SJC OC3 Los Angeles, to OC192 SJC3 to SJC4, to OC12 MaeW ATM, OC48 # 2 for IAD to NYR, IAD # 2 to PAIX VA OC48, DCA2 to DFW2 OC48, PAIX OC12 to Core1.sjc, NPA - DS3 to San Jose, LGA1 OC192#2 to IAD, LGA1 OC48 to Chicago, NYC Backbone OC192 to LGA2, NYC Backbone OC48 # 2 to core3.lga1, ETC... Each one of these graphs shows abnormalities in the flow of internet data, such as pits, spikes, square wave function graphs, clipping on some waveforms, etc. This is not limited to MFN. I have observed this on other similiar types of Sundry network data collection systems. It is not easy to see HOW BAD the problem is with these Sundry data collection systems, UNTIL you expand the MRTG graph. Once this is done, then you can really see how bad the integrity of the collected data really is. A small MRTG graph really masks the problems associated with the data which is being displayed. With a larger graph, you definately see the problems associated with todays Sundry systems. As there is no way to really verify the QUALITY or INTEGRITY of the data being displayed, then I submit as fact, that what is being shown here is really in a grey area, at best. So who really knows how correct, the data which is being displayed on the MFN home page is really is ? Cause with the clipping, spiking, pits, squarewave graphs, small graphing scale being shown, definately, I have my doubts ... One would also wonder, that if this data collection system is used by MFN to generate bills for customers of MFN who are charged by the Megabyte, what these customers bills look like HOW accurate these bills really are... Regards, Mike Martin. From: Pawlukiewicz Jane [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: WorldComm Fiber Cut Date: Mon, 08 Jul 2002 10:52:18 -0400 MFNs status page is: http://www.mfn.com/network/ip_networkstatus.shtm#sjc Jane Sean Donelan wrote: On Sun, 7 Jul 2002, Gerardo A. Gregory wrote: Can someone from WorldComm please verify a fiber cut that happened today at around 11:30 am (Central). I have bveen informed that a fiber cut in Illinois (or Indiana) has been in effect (until just a few minutes) for all of the afternoon and most of the evening. Worldcom is reporting a problems near Chicago. Earthlink is reporting problems affecting its customers in Indiana, Illinois, Iowa, Michigan, Wisconsin and Ohio. http://help.mindspring.com/netstatus/ http://www.noc.uu.net/ Cable Wireless is showing delays out of Cleveland, Ohio http://sla.cw.net/ ATT and Sprint aren't reporting any problems. http://ipnetwork.bgtmo.ip.att.net/index.html http://www.sprint.net/ MFN's and PSI's network status pages have stopped working for me, so I don't know if they are having problems. http://www.above.net/html/techlog.txt http://www.psi.net/cgi-bin/netstatus.pl5 _ Chat with friends online, try MSN Messenger: http://messenger.msn.com
Re: Bogus bogon?
Hi, John. ] 192.88.99.0/24 which is the 6to4 anycast network. Do we really want to be ] filtering that prefix? Good question. I'm re-reading RFC 3068 now, and the RFC appears to allow for the advertisement of this prefix into the global table. I'm wondering if this is wise, however. It seems this prefix would best be used internally. What do others think? Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
RE: Bogus bogon?
Tony Tauber wrote: On Mon, 8 Jul 2002, Rob Thomas wrote: Hi, John. 192.88.99.0/24 which is the 6to4 anycast network. Do we really want to be filtering that prefix? Good question. I'm re-reading RFC 3068 now, and the RFC appears to allow for the advertisement of this prefix into the global table. I'm wondering if this is wise, however. It seems this prefix would best be used internally. What do others think? Thanks, Rob. I believe the idea is that it typically comes from outside one's domain because it's supposed to allow edge islands of IPv6 to find the mainland. If you had a connection to the mainland under your control, you wouldn't need this trick to get there. At least that's my understanding. Tony Close. The prefix should be advertised to the customers of the network which has the interconnect. If those customers are other SPs, the downstream will receive it from outside, and should advertise it to their customers. If a SP chooses to provide the interconnect service, it may still want to receive that prefix from outside as a backup. The point is that it is a well-known prefix that allows end customers to deploy IPv6 even if their direct SP chooses not to support it on their timeframe. It is designed on the assumption that the first hop SP is doing nothing about IPv6 deployment, and that includes not filtering the prefix. It would be wise to continue announcing it even after the SP starts announcing native IPv6 to customers because there will be some islands out there still, and it will be more efficient for the endpoints to directly tunnel over IPv4 than to run it through a central gateway service in each SP. Clearly each origin AS announcing the prefix will want to limit their exposure to their customers, but SPs without an interconnect should not have a problem accepting it. Tony
Readiness for IPV6
As far as I can tell, neither Foundry Bigiron, nor Cisco 65xx support IPV6 (I could be wrong). While they probably aren't the most popular routers, they are very popular, and im sure plenty of cisco's smaller routers don't support it either. How ready is the 'net to transit to IPV6 in the future? Should everyone be factoring in replacing big routers with IPV6 being the only reason? Just curious on others' opinions on this. --Phil
Re: Readiness for IPV6
On Mon, 8 Jul 2002, Phil Rosenthal wrote: As far as I can tell, neither Foundry Bigiron, nor Cisco 65xx support IPV6 (I could be wrong). While they probably aren't the most popular routers, they are very popular, and im sure plenty of cisco's smaller routers don't support it either. I am on the 6bone using a combination of 2600 and Zebras. The 2600 doesn't do BGP6 yet, although it does RIP6 just fine. It's getting there... How ready is the 'net to transit to IPV6 in the future? Define future. It's coming, although slowly. But then, why hurry? The emergency was just another skyfall... -- Yours, J.A. Terranson [EMAIL PROTECTED] If Governments really want us to behave like civilized human beings, they should give serious consideration towards setting a better example: Ruling by force, rather than consensus; the unrestrained application of unjust laws (which the victim-populations were never allowed input on in the first place); the State policy of justice only for the rich and elected; the intentional abuse and occassionally destruction of entire populations merely to distract an already apathetic and numb electorate... This type of demogoguery must surely wipe out the fascist United States as surely as it wiped out the fascist Union of Soviet Socialist Republics. The views expressed here are mine, and NOT those of my employers, associates, or others. Besides, if it *were* the opinion of all of those people, I doubt there would be a problem to bitch about in the first place...
Re: Readiness for IPV6
Phil Rosenthal wrote: As far as I can tell, neither Foundry Bigiron, nor Cisco 65xx support IPV6 As far as I can tell, despite many feature requests to the contrary, Foundry barely supports IPV4. Your local Foundry sales ofice can offer you a more percise time-line on Foundry's planned support for Internet Protocol versions 4 and 6. Alif The Terrible wrote: I am on the 6bone using a combination of 2600 and Zebras. Forge any checks to pay for those, Jerry? Frank Rizzo
Re: Readiness for IPV6
On Mon, 8 Jul 2002, Rizzo Frank wrote: Good to hear, Jerry. Have you forged any checks in the past, or are the guys on usenet full of it? If you're so new as to listen to everything you hear on Usenet, then you deserve what you get - GIGO. Got serious questions? Google is your friend. Start at the link that is supposedly the smoking gun, http://www.apbnews.com/media/gfiles/youngman/index.html, and then read down a few paragraphs to the interview with Henny's personal assistant of 8 years: I know all the details of the thing, said Camerman, but there are people who are still alive who would be hurt if the incident resurfaced. snip They had already arrested someone, and they didn't want to get in trouble for false arrest. The FBI doesn't put people in jail and then say, 'Oh, I'm sorry.' Now, if you have something even _approaching_ content, great. If you really want to go play in this Burnore-esque playground, you can do it alone - this is *years* old you know... Frank Rizzo -- Yours, J.A. Terranson [EMAIL PROTECTED] If Governments really want us to behave like civilized human beings, they should give serious consideration towards setting a better example: Ruling by force, rather than consensus; the unrestrained application of unjust laws (which the victim-populations were never allowed input on in the first place); the State policy of justice only for the rich and elected; the intentional abuse and occassionally destruction of entire populations merely to distract an already apathetic and numb electorate... This type of demogoguery must surely wipe out the fascist United States as surely as it wiped out the fascist Union of Soviet Socialist Republics. The views expressed here are mine, and NOT those of my employers, associates, or others. Besides, if it *were* the opinion of all of those people, I doubt there would be a problem to bitch about in the first place...
Re: AS number inconsistencies
At 02:10 PM 09-07-02 +1000, Philip Smith wrote: And there are only two ASes which appear, and are not registered anywhere - one is intermittent, the other, AS5757, has been there since I started this over 3 years ago. So what does UUnet have to say? * 207.19.224.0 152.158.76.66 0 2686 7018 701 5757 i Who gave the permission for them to accept AS5757 from their single-homed customer? -Hank
Re: AS number inconsistencies
hmm, I'm not responsible for this kind of thing but I can certainly ASK someone... this has been from the same path for this whole time? --Chris ([EMAIL PROTECTED]) ### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## ### On Tue, 9 Jul 2002, Hank Nussbacher wrote: At 02:10 PM 09-07-02 +1000, Philip Smith wrote: And there are only two ASes which appear, and are not registered anywhere - one is intermittent, the other, AS5757, has been there since I started this over 3 years ago. So what does UUnet have to say? * 207.19.224.0 152.158.76.66 0 2686 7018 701 5757 i Who gave the permission for them to accept AS5757 from their single-homed customer? -Hank
Re: AS number inconsistencies
hey... looks like this might actually get fixed! --Chris ([EMAIL PROTECTED]) ### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## ### On Tue, 9 Jul 2002, Hank Nussbacher wrote: At 02:10 PM 09-07-02 +1000, Philip Smith wrote: And there are only two ASes which appear, and are not registered anywhere - one is intermittent, the other, AS5757, has been there since I started this over 3 years ago. So what does UUnet have to say? * 207.19.224.0 152.158.76.66 0 2686 7018 701 5757 i Who gave the permission for them to accept AS5757 from their single-homed customer? -Hank
Re: AS number inconsistencies
Hank Nussbacher is rumoured to have written: * And there are only two ASes which appear, and are not registered anywhere * - one is intermittent, the other, AS5757, has been there since I started * this over 3 years ago. * * So what does UUnet have to say? * Who gave the permission for them to accept AS5757 from their single-homed * customer? sigh I registered AS5757 sometime in 1995. In fact, I sent in the registration request for AS5758 for UMD within 10 minutes of AS5757. For whatever reason, the record for 5757 disappeared. You'll note that 5758 is still there, no problems. I occasionally would call up the NIC and ask them where the record went, and at the time they would tell me they could see it fine in their system, and they couldn't tell me why it wasn't appearing in the public dump. Unfortunately, I didn't push the issue. Their response eventually changed to we don't know what you are talking about. Someone who would know told me that all older AS's were also recorded by hand in some sort of physical medium. I can't get ahold of anyone at ARIN who knows what I'm talking about, for that, either. The orginal email confirming the allocation is sitting on an 8mm tape, right in front of me. I don't have the means to retrieve the data. [Anyone have a mid-90's sun 8mm tape deck I can borrow?] 5757 wasn't intended to be singly-homed. Times have changed, and I'm between, um, providers. If it will make things easier for everyone, I'll be happy to have UUnet turn 207.19.224.67 into a static route. But that doesn't fix my disappearing record problem. I'd welcome any useful suggestions. _jenn
