- Test - lists.nanog.org

NSI Bulletin 097-009 | RS machine outage
by David H. Holtzman 22 Dec '97

22 Dec '97

The Internic is currently experiencing technical difficulties with some of the rs hosts. This problem is expected to be resolved within the next hour. Users may experience temporary problems with whois in the interim. We apologize for the inconvenience. _____________________________________ David H. Holtzman (dholtz(a)internic.net) Sr Vice President of Engineering Network Solutions, Inc.

2 1

Re: "Today is a good day to die"
by Prabhu Kavi 22 Dec '97

22 Dec '97

Nope. Try a bunch of 1+Meg emailed executables showing things like Rudolph going splat, men and women dancing, etc. Prabhu ______________________________ Reply Separator _________________________________ Subject: "Today is a good day to die" Author: "J.D. Falk" <jdfalk(a)priori.net> at smtplink Date: 12/19/97 11:08 AM There seem to be a lot of packets deciding that today is a good day to die and rushing towards exchange points in order to throw themselves off of the nearest gigaswitch. Has Worldcom upgraded the MAE's again, or is this the much- touted explosion of "e-commerce" for the Christmas season? We've gotten nothing useful out of Worldcom today; anybody else had any better luck? ********************************************************* J.D. Falk voice: +1-650-482-2840 Supervisor, Network Operations fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." *********************************************************

4 3

RE: Broadcast pings.
by Al Roethlisberger 22 Dec '97

22 Dec '97

At 04:04 PM 12/22/97 -0500, you wrote: >Yeah that was my initial thought, but we've been hit now from multiple >nameservers (and constantly machines that are named "ns" or appear in a >'nic record). I just found it odd that we're only getting hit from >machines matching this pattern. I guess it was random, but you never >know :-) > hmm, don't know. But it may be that a casual hacker that has recently jumped on the smurf bandwagon may be using ns addresses as they are so readily available. I have often been surprised at the lack of real knowledge some of the perpetrators have had in some of these cases. They just get the code, plug in some easy data(like their ISPs ns) and away they go. Fortunately for us, many of these folks don't know how to choose large enough networks to ping, so we often come out OK. Or maybe 'someone' just discovered nslookup =) and decided to use that data. Who knows though.... it is certainly hard to tell sometimes. al >Best regards, > >Jamie Scheinblum - FASTNET(tm) / You Tools Corporation >jamie(a)fast.net (610)954-5200 http://www.fast.net/ >FASTNET - Business and Personal Internet Solutions > >> -----Original Message----- >> From: Al Roethlisberger [SMTP:aroethli@cisco.com] >> Sent: Monday, December 22, 1997 3:23 PM >> To: Jamie Scheinblum >> Cc: nanog(a)merit.edu >> Subject: Re: Broadcast pings. >> >> At 12:50 PM 12/22/97 -0500, you wrote: >> >Has anyone seen an increase of broadcast pings, where the source >> route >> >appears to be from a nameserver? >> > >> >We took a look through our access-list logs, and it seems all of the >> >attempted attacks during the last few days have had an IP-source of a >> >nameserver. >> > >> >Just thought it was curious. >> > >> >Best regards, >> > >> >Jamie Scheinblum - FASTNET(tm) / You Tools Corporation >> >jamie(a)fast.net (610)954-5200 http://www.fast.net/ >> >FASTNET - Business and Personal Internet Solutions >> > >> >> >> Jamie, >> >> It is probably just someone 'smurfing', where they fudge the source ip >> of >> the broadcast ping request. The actual source of the ICMP request is >> probably entirely different than the nameserver you are seeing in your >> logs....hence the difficulty(although not impossible) tracking these >> attacks. >> >> I would imagine that this poor nameserver in question is also >> suffering from >> the attack as well when all the pinged devices attempt to respond. >> You >> probably have one or more folks using the same dummy address for the >> source. >> This is the nature of the 'smurf' problem. >> >> Check out: >> >> http://www.quadrunner.com/~chuegen/smurf.cgi >> >> This is a co-worker of mine that has put together some useful >> background and >> tips addressing this issue. >> >> Hope that helps. >> >> al >> > >

1 0

RE: Broadcast pings.
by Jamie Scheinblum 22 Dec '97

22 Dec '97

Yeah that was my initial thought, but we've been hit now from multiple nameservers (and constantly machines that are named "ns" or appear in a 'nic record). I just found it odd that we're only getting hit from machines matching this pattern. I guess it was random, but you never know :-) Best regards, Jamie Scheinblum - FASTNET(tm) / You Tools Corporation jamie(a)fast.net (610)954-5200 http://www.fast.net/ FASTNET - Business and Personal Internet Solutions > -----Original Message----- > From: Al Roethlisberger [SMTP:aroethli@cisco.com] > Sent: Monday, December 22, 1997 3:23 PM > To: Jamie Scheinblum > Cc: nanog(a)merit.edu > Subject: Re: Broadcast pings. > > At 12:50 PM 12/22/97 -0500, you wrote: > >Has anyone seen an increase of broadcast pings, where the source > route > >appears to be from a nameserver? > > > >We took a look through our access-list logs, and it seems all of the > >attempted attacks during the last few days have had an IP-source of a > >nameserver. > > > >Just thought it was curious. > > > >Best regards, > > > >Jamie Scheinblum - FASTNET(tm) / You Tools Corporation > >jamie(a)fast.net (610)954-5200 http://www.fast.net/ > >FASTNET - Business and Personal Internet Solutions > > > > > Jamie, > > It is probably just someone 'smurfing', where they fudge the source ip > of > the broadcast ping request. The actual source of the ICMP request is > probably entirely different than the nameserver you are seeing in your > logs....hence the difficulty(although not impossible) tracking these > attacks. > > I would imagine that this poor nameserver in question is also > suffering from > the attack as well when all the pinged devices attempt to respond. > You > probably have one or more folks using the same dummy address for the > source. > This is the nature of the 'smurf' problem. > > Check out: > > http://www.quadrunner.com/~chuegen/smurf.cgi > > This is a co-worker of mine that has put together some useful > background and > tips addressing this issue. > > Hope that helps. > > al >

1 0

Re: Broadcast pings.
by Al Roethlisberger 22 Dec '97

22 Dec '97

At 12:50 PM 12/22/97 -0500, you wrote: >Has anyone seen an increase of broadcast pings, where the source route >appears to be from a nameserver? > >We took a look through our access-list logs, and it seems all of the >attempted attacks during the last few days have had an IP-source of a >nameserver. > >Just thought it was curious. > >Best regards, > >Jamie Scheinblum - FASTNET(tm) / You Tools Corporation >jamie(a)fast.net (610)954-5200 http://www.fast.net/ >FASTNET - Business and Personal Internet Solutions > Jamie, It is probably just someone 'smurfing', where they fudge the source ip of the broadcast ping request. The actual source of the ICMP request is probably entirely different than the nameserver you are seeing in your logs....hence the difficulty(although not impossible) tracking these attacks. I would imagine that this poor nameserver in question is also suffering from the attack as well when all the pinged devices attempt to respond. You probably have one or more folks using the same dummy address for the source. This is the nature of the 'smurf' problem. Check out: http://www.quadrunner.com/~chuegen/smurf.cgi This is a co-worker of mine that has put together some useful background and tips addressing this issue. Hope that helps. al

1 0

NSI Bulletin 097-008 | Internic holiday hours
by David H. Holtzman 22 Dec '97

22 Dec '97

On Wednesday, December 24, 1997, the InterNIC Call Center will close two (2) hours early at 7 p.m. Eastern Time (instead of 9 p.m.). This is a one-time occurrence. Call Center support will return to normally scheduled hours on Friday, December 26th: 7 a.m. to 9 p.m. _____________________________________ David H. Holtzman (dholtz(a)internic.net) Sr Vice President of Engineering Network Solutions, Inc.

1 0

Agenda topics so far
by Susan R. Harris 22 Dec '97

22 Dec '97

Greetings - here's what we've lined up so far for the February NANOG. Are there other topics you'd like to hear about? ------------------------------------------- PRESENTATIONS - "Technical Considerations in Preventing Mail Abuse (Spam)" Presentation and open discussion, Paul Vixie, Vixie Enterprises See http://maps.vix.com/ - "Squid Caching Update," K Claffy, NLANR - "IPv6 Solutions/IPv4 Issues," Christian Huitema, Bellcore, & Yakov Rekhter, Cisco - "Monitoring your Network with Freely Available Statistics Reporting Tools: An Overview," Stan Barber, Academ Consulting Services - "ARIN Update," Kim Hubbard, ARIN - "Recent Events in Inter-Provider Multicasting," Dave Meyer, Univ. of Oregon - "Multihoming: Problems and Solutions from the Customer Point of View," Howard Berkowitz TUTORIALS - "BGP 101: An Introduction to the Border Gateway Protocol" Paul Ferguson, Cisco - "Routing Gotcha's to Watch For," Avi Freedman, Net Access - "Using BGP Communities and MEDs With GateD," Sue Hares, Merit PS - the NANOG registration staff is on vacation until January 5, so please hold your cards, calls, and letters until then. (Web registration will stay open during the holidays ... :) --Susan Harris

1 0

Cisco-IP bridging
by Adam Rothschild 22 Dec '97

22 Dec '97

NANOG folks: Sorry if this is at all off topic.... Could someone PLEASE point me towards some documentation concerning IP bridging (IOS 11.2, dual 25xx routers)? Thanks a mil, Adam

2 1

Y2K in RADB?
by Pete Ashdown 19 Dec '97

19 Dec '97

I tried this today whilst updating my AS: changed: pashdown(a)xmission.com 19971218 *ERROR*: date part of "changed"not in YYMMDD format I know it isn't going to break any critical transactions, but I'd suggest moving to YYYYMMDD.

2 1

Re: Traffic Engineering (fwd)
by Sean M. Doran 19 Dec '97

19 Dec '97

Eric Germann <ekgermann(a)cctec.com> writes: > At 04:31 PM 9/18/97 -0400, Sean M. Doran wrote: > > > >Perhaps you could explain to me how you can find the > >shortest path between A and B using ping times, traceroute > >hop counts, and AS_PATHS observed at C, assuming that > >traffic between A and B is not exchanged through C? > > > > You're not trying to find it between A and B. A connects to B, but B has > every intention of redirecting to C1, C2, or C3, etc. The originally proposed idea was that search engines would present a list of hits sorted by the proximity to the client that made the query. What you are doing is rehashing the IBM scheme. Unfortunately the IBM scheme requires * an initial connection to a server * each server must know the location of its replicated data * each server must be able to determine the proximity of its replicated data to the client in reasonable time and without placing too much additional load on the server, the client, or the replicating sites Point (1) means that for short transactions, preserving locality is a net loss. If it is more work to redirect than to serve directly, there is no point in not serving directly. Point (2) means that copies of the data that may be nearer the client may not be known about. This is also a scaling problem. Point (3) is a difficult engineering challenge, not least because determining proximity (assuming proximity is a function of bandwidth, delay, and infrastructure) without inducing traffic load is hard. What is really needed is a scheme such that * the client learns the identity of the datum desired, and the ultimate, authoritative source of the datum, through user interaction (typing in a URL) or through a search database * the client or its proxy asks increasingly distant infrastructure if replicas are available; Van Jacobson suggests this is a good application for multicast and I'm inclined to agree somewhat * the client or its proxy retreives the found replicated datum if a replica exists and is found within a reasonable time or scope of multicast search or the client or its proxy turns to the ultimate source for a copy * should the client or its proxy hear a query for this same datum, it will offer it up for retrieval to other clients that is, everything in your client or proxy's local cache may be served up to nearby clients Note that the squid caching system emulates this scheme to a large degree. The difficulty is now reduced to constructing a spanning tree for all multicast queries and determining whether something found by the client or its proxy to be topologically nearby is a good choice for serving up the data. These problems seem much more tractable than the ones the IBM scheme needs to solve, and a great deal of theoretical work has gone into this sort of model already. > Anyone know of some reasonably available methods for > measuring end to end "performance" which are almost > universally implemented? No. See the CAIDA or IPPM efforts for why not. Sean. P.S.: Curtis Villamizar had another interesting approach which involved pushing content far afield to machines with the same transport-layer (IP) addresses, relying upon closest-exit routing to connect one to the topologically-closest replication machine. Unfortunately, while this could be really cool for NSPs to offload stuff towards peering points (public or private), it also has some poor scaling properties and is uncomfortably reliant upon the stability of routing. If he's done any more thinking about the idea, I'd love to hear about it though.

4 4