- NANOG - lists.nanog.org

Re: NSPs and filters (fwd)
by Barney Wolff 14 Jul '97

14 Jul '97

> Date: Mon, 14 Jul 1997 12:29:32 -0400 > From: Daniel Senie <dts(a)proteon.com> > > And it goes beyond that... Every PC running Windows (or any other OS, > for that matter) has complete ability to do anything with IP. So, any > user on a dialup line into any ISP is a possible source of attacks. > > This is why I think the RAS servers need to be able to filter right at > the point of the dialup. There, the comparison is a simple compare of a > 32 bit integer (IP address assigned to the dialup user, compared to the > IP address of packets received from the user). Any discrepancies should > set off alarm bells... Some ISPs, including the very large one for which I wrote the PPP code, already do this. Source address assurance is the mirror image of destination-based routing. That's not to say that routing is always symmetrical, but the problem is no harder, and can be made no slower. Barney Wolff <barney(a)databus.com>

1 0

Re: MAE West
by Curt Howland 14 Jul '97

14 Jul '97

I wouldn't call 8.5 hours "quickly corrected". > From: bmanning(a)ISI.EDU (Bill Manning) > > To true. Would you care to cover the cost of replicating the 400Mbp/s > to build in better reliability? It appears that the owners/operators of > MAE-West are selecting an optimization path based on the assumption that > outages are infrequent and can be quickly corrected. > > --bill >

1 0

Kaspia E-mail to the group
by Steve Carter 14 Jul '97

14 Jul '97

Am I too suspicious/cynical or did Jeff Erwin just manage to get another plug for his company and products onto the NANOG list? > -----Original Message----- > From: William B. Norton [SMTP:wbn@merit.edu] > Sent: Monday, July 14, 1997 9:39 AM > To: nanog(a)merit.edu > Subject: Kaspia E-mail to the group <snip>

1 0

The Cidr Report
by Tony Bates 14 Jul '97

14 Jul '97

1 0

Re: Unacceptable Delay
by Brett D. Watson 14 Jul '97

14 Jul '97

we've just received a bunch of nanog mail here at genuity that was delay *eight* hours between the time it reached merit.edu, and the time our mx host recieved it from merit, according to the headers. we've received external mail from all over the place all day with no apparent delay. has *no* one else seen any great delays in the messages from nanog? i don't think the packet loss has been that bad for 8 hours. :) -brett > I would say a lot of the delay is in packet loss.. with MW down, ME is > really loaded at this time.. I get as much as 60% packet loss just pinging > across the Ring. OUCH! > > Eric > > > _______________________________________________________ > Eric D. Madison - Senior Network Engineer - > ACSI - Advanced Data Services - ATM/IP Backbone Group > 24 Hour NMC/NOC (800)291-7889 Email: noc(a)acsi.net > > > On Fri, 11 Jul 1997, Rodney Joffe wrote: > > > It's interesting to note the delay in the NANOG mailer. I don't know if > > there's any manual operation involved, but according to the headers, Rob > > posted this at 7:43, it was received at 7:43 pdt by MERIT, and shipped > > out at 8:15 pdt. > > > > I guess we're lucky this isn't an operational list, where time might be > > important ;-) > > > > Can we improve this? > > > > > > Rodney Joffe > > Chief Technology Officer > > Genuity Inc., a Bechtel company > > http://www.genuity.net > > > > Received: from postal1.genuity.net by x-files.genuity.net with SMTP > > (Microsoft Exchange Internet Mail Service Version 5.0.1458.49) > > id 3T51M8BZ; Fri, 11 Jul 1997 08:15:13 -0700 > > Received: from merit.edu (merit.edu [198.108.1.42]) > > by postal1.genuity.net (Sendmail G2.3/8.8.5) with ESMTP id > > PAA19251; > > Fri, 11 Jul 1997 15:15:28 GMT > > Received: from localhost (daemon@localhost) > > by merit.edu (8.8.5/8.8.5) with SMTP id KAA15550; > > Fri, 11 Jul 1997 10:49:59 -0400 (EDT) > > Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 10:43:51 > > -0400 > > Received: (from majordom@localhost) > > by merit.edu (8.8.5/8.8.5) id KAA15338 > > for nanog-outgoing; Fri, 11 Jul 1997 10:43:49 -0400 (EDT) > > Received: from elite.exodus.net (rob(a)elite.exodus.net [209.1.115.69]) > > by merit.edu (8.8.5/8.8.5) with ESMTP id KAA15331 > > for <nanog(a)merit.edu>; Fri, 11 Jul 1997 10:43:41 -0400 (EDT) > > Received: (from rob@localhost) by elite.exodus.net (8.7.5/8.7.3) id > > HAA04422 for nanog(a)merit.edu; Fri, 11 Jul 1997 07:43:52 -0700 > > From: Robert Bowman <rob(a)elite.exodus.net> > > Message-Id: <199707111443.HAA04422(a)elite.exodus.net> > > Subject: It's always fun > > To: nanog(a)merit.edu > > Date: Fri, 11 Jul 1997 07:43:52 -0700 (PDT) > > X-Mailer: ELM [version 2.4 PL25] > > MIME-Version: 1.0 > > Content-Type: text/plain; charset=US-ASCII > > Content-Transfer-Encoding: 7bit > > Sender: owner-nanog(a)merit.edu > > > > >

2 1

Cisco 12000 aka BFR aka GSR
by Peter Leppik 14 Jul '97

14 Jul '97

Apologies in advance for a non-operational question, but... Has anyone had the chance to get their hands on a real, live Cisco 12000 yet? I saw the plexiglass wonder at InterOp, and I'm wondering when there might be an actual box that real people can kick the tires on (even in beta). Thanks, -Peter

1 0

Re: NSPs and filters (fwd)
by smd＠clock.org 14 Jul '97

14 Jul '97

Jon Lewis <jlewis(a)inorganic5.fdt.net> writes: > Unless I'm mistaken, forged UDP requires root access and (at the volume we > received) was likely from a host with T1 or better > connection to the net. You just described nearly every PeeCee at nearly every higher educational institution in North America and northern Europe, and several parts of Asia, too. Sean.

3 3

Kaspia E-mail to the group
by William B. Norton 14 Jul '97

14 Jul '97

Hi all - Here is an apology from Kaspia for the e-mail sent to the individuals on the nanog mailing list. It appears to have been an unintentional error. Bill >To all NANOG members who attended the NANOG confererence in Florida last >month: > >It has been brought to my attention that Kaspia Systems has sent an >unsolicited email to many of you who did not attend our reception at the >show in Florida. I would like to take this opportunity to apologize for >this breach of internet protocol, and to assure you that it was a case not >knowing the rules vs. willfull violation of the rules. > >I was lead to believe that we were sending a personal email to the 40 or so >of you that attended our reception, an action I approved. What actually >happened was that our telemarketing group apparently decided that if 40 was >good, 400 must be great, and proceeded to email everyone on the NANOG list, >one at a time. This action I do not approve of, nor does Kaspia Systems >believe that unsolicited email is a proper use of the internet. > >Please accept my apologies on behalf of Kaspia Systems and be assured that >this will not happen again. > >Jeff Erwin >President & CEO >Kaspia Systems >(503) 644-1800 > =========================== Offending Message=============================== >From: psprague(a)kaspia.com (Pam Sprague) >To: <XXX(a)XXX.XXX.XXX> >Date: Wed, 2 Jul 1997 13:15:48 -0700 >X-MSMail-Priority: Normal >X-Priority: 3 >X-Mailer: Microsoft Internet Mail 4.70.1161 >MIME-Version: 1.0 >Content-Type: text/plain; charset=ISO-8859-1 >Content-Transfer-Encoding: 7bit >Message-ID: <19970702202132694.AAP219(a)Sales.kaspia> > >July 2, 1997 > >Dear XXXXXXXX, > >We very much appreciate the enthusiasm shown our product by all of you >at the cocktail reception we sponsored at the Hyatt last month. Many of >you commented about Kaspia's significance and relevance after seeing the >excellent presentation "Introduction to Network Performance >Measurement" given by Daniel McRobb of ANS. > >Dan's presentation stressed the importance of collecting, reducing and >trending various network statistics in order to perform capacity >planning and trouble-shooting. This is the best way to get the greatest >return from the two biggest costs of operating a network: Bandwidth and >Personnel. Most organizations do not have the resources to provide for >comprehensive network performance management; Kaspia was designed >specifically to meet that challenge. > >We already have meetings scheduled with several of you to determine your >specific requirements and to arrange for a comprehensive on-site >evaluation of our capability. For those of you that could not attend >our reception and would like to arrange for an individual presentation, >please contact us at http://www.kaspia.com/prod_info.htm ; we will >have an account team schedule a session with you, at your location, at a >time that is convenient for you. Also, if you would like one of our hats, >we're making more! > > >Thank you again for you enthusiasm and we look forward to being of >service. > >Sincerely, > > > >William H. Ross >Product Manager > >408-353-5764 >408-353-5765 FAX >bross(a)kaspia.com > > -------------------------------------------------------------- William B. Norton <wbn(a)merit.edu> (313) 764-9430

1 0

Re: Internet Backbone Index
by smd＠clock.org 14 Jul '97

14 Jul '97

Stephen Balbach <stephen(a)clark.net> writes: > Routes the first packets and switches the rest based on > "flows". How is this conceptually different from cisco fastswitching wherein the slow path is used for the first packet towards a destination and all subsequent packets use a cache-based fast path? In both cases you have a slow cache-set-up path and a finite cache. There are significant disadvantages to using a cache in core routers (look up Dennis Ferguson's comments in your local NANOG archive, nobody I can think of can improve on them). The only principal advantage to cache-based routing is when you haven't got the power to process all packets through the same path without drops or mishandling of things like options and filters, but you do have the power to do some sort of hashed cache lookup. With luck, this will not be the case in future routers. Sean.

1 0

Re: NSPs and filters
by smd＠clock.org 14 Jul '97

14 Jul '97

Jon Lewis <jlewis(a)inorganic5.fdt.net> writes: > A certain minimal level of network security should be a part of any > responsible network. Out of curiosity, do you yourselves do source-based IP filtering at all your edges? (Dialups, dedicated customers, gateways to your own PeeCee/Workstation gear, and so on and so forth) I don't disagree with you: everyone *ought* to filter out bogus source addresses, and this *ought* to happen as close to the edge as possible, so that a reasonable "tree of trust" would assist in tracking down where any given source-spoofing attack could *not* be coming from. Without this "tree of trust", the farther away you get from the valid origin of any given prefix, the less reliable your decision to filter or not filter a packet that claims to be originated there will be. This gets awkward for large providers, since they probably don't want to cause outages to customers or customers' customers, or customers' customers' customers... On the other hand, in a purely PA-addressed Internet, this is very simple, so much so that filtering could even be done on very large amounts of traffic, even without routers which are specifically designed with source-based filtering in mind. However, once again the addressing shortcomings of IPv4 (and these are duplicated in IPv6) get in the way of building a scalable, reliable, secure Internet without involving NAT devices. > Somewhere in the internet food chain, it is > very much practical to install filters, and someone needs to make sure > they are in place. Yes: if from your perspective you are certain that a particular interface should only generate source addresses within a certain prefix, or conversely you can guarantee that the only valid source for packets originated with that prefix is across a particular interface or small set of interfaces, then building safety-providing filters that do not cause unwanted disconnectivity is easy. The problem is in the certainty... Sean.

1 0