- NANOG - lists.nanog.org

RE: Exodus: this is bad
by Adam Rothschild 18 Nov '98

18 Nov '98

On Mon, 16 Nov 1998, Brian wrote: > > No, but I see stuff from this: > > Nov 16 15:14:34 venus in.telnetd[17889]: connect from 209.119.115.65 > Nov 16 15:14:35 venus in.telnetd[17890]: connect from 209.119.115.65 Hrrrm, so far I'm routing the following to Null0: 38.29.63.0/24 207.104.58.0/24 209.67.50.0/24 209.119.115.0/24 And blocking/logging all inbound telnet connections (besides, real men use SSH 8-)... Am I forgetting anything?

16 18

Re: Strange BGP announcement
by Tony Li 18 Nov '98

18 Nov '98

patrick(a)ianai.net (I Am Not An Isp) writes: > You said you wanted routers that followed the RFC. The RFC does not > mention list AS_PATH length as a route selection criteria. I have been > told that the draft for the next rev specifically prohibits using AS_PATH > length as a route selection criteria. Patently false. In particular, the spec allows an implementation to invoke local policy when computing the local preference of a route. An implementation can reasonably incorporate the AS path length in its local preference calculations as part of its policy. Tony

3 3

Re: Exodus Customer Security
by David Lesher 18 Nov '98

18 Nov '98

Unnamed Administration sources reported that Bret McDanel said: > If you make a policy where you dont give out customer information, when do > you break that policy? After 2 complaints? 5? Whatever the number, > there is always someone out there who can and will abuse that, for > whatever reason.. Don't need to. Offer to set up a three-way call. Then {Sprint} and alleged victim can both talk to alleged source. -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

2 1

Re: Journal of Internet Disasters
by Roeland M.J. Meyer 18 Nov '98

18 Nov '98

At 11:22 AM 11/18/98 -0500, Jay R. Ashworth wrote: >On Sun, Nov 15, 1998 at 10:20:30AM -0500, Deborah Ann Smith wrote: >> Even the FAA recognizes no matter how good a flight crew, if they get >> incorrect information from the Tower, any problems that occur are the >> Tower's fault! > >You know; would that this were true. > >If the tower gives you instructions that you _know_ will endanger your >flight, the final responsibility for avoid that danger lies with you as >pilot in command. You have to tell them you're ignoring them, but you >have to ignore them. > >Not that this will help you a damn when FAA decides to suspend your >ticket for ignoring ATC... Yes, but that's done, pending review and investigation. If you can document properly you will be exonerated. I happen to know of one instance where this actually happened and both the pilot and the ATC guy were suspended, pending review. Both were exonerated because the problem was equipment failure. Otherwise one of those suspensions might have become permanent. In the air-space, the FAA tends to err on the side of safety, rather than justice. If there is a doubt, everyone involved gets grounded until the doubt is removed. It sounds harsh, but that is a main reason that the air-space has the safety-record that it has. An aircraft's main function is to get you high enough off the ground such that the fall will kill you. - Pilot's credo. ___________________________________________________ Roeland M.J. Meyer, ISOC (InterNIC RM993) e-mail: <mailto:rmeyer@mhsc.com>rmeyer(a)mhsc.com Internet phone: hawk.mhsc.com Personal web pages: <http://www.mhsc.com/~rmeyer>www.mhsc.com/~rmeyer Company web-site: <http://www.mhsc.com/>www.mhsc.com/ ___________________________________________ Who is John Galt? "Atlas Shrugged" - Ayn Rand

1 0

National Infrastructure Protection Center
by Sean Donelan 18 Nov '98

18 Nov '98

After Scott Larson was so kind to come the the Dearborn NANOG and tells us all about the FBI's new cyber-security program, has anyone bothered to call the NIPC about any of these events? http://www.nipc.gov/ I leave it as an exrcise for the reader to try to figure out the correct phone number to call. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

6 6

Re: InternetWeek Article on UUnet: question
by Erik Muller 18 Nov '98

18 Nov '98

On Wed, 18 Nov 1998, Sean Donelan wrote: > http://www.internetwk.com/news1198/news111398-2.htm > > Was NETCOM identified as the source? Why was the NETCOM NOC difficult > for UUNET to reach on Sunday? Was it a 'customer configuration error' > or a router vendor(s) software bug? If UUNET had identified the correct > customer router to block, why did the route return? I'm more than a little curious about those comments as well. Noone from UUNet, to my knowledge, has informed us of any involvement from Netcom in this situation. If we were involved, I would greatly appreciate any information as to how... as we all know, we can't fix the problems that nobody tells us about. If there were problems contacting us, again, I'd like to know. Our contact information is readily available, and as far as I know, accurate - http://puck.nether.net/netops/nocs.html is up to date for us, anyway. Of course, I'm taking those comments with a pretty large grain of salt as well, considering that the same sentence implies that we're a UUNet customer. Uh, no, I think not. ---------------------------------------------------------------------------- Erik Muller, Network Engineer emuller(a)noc.netcom.net NETCOM Network Services Support NETCOM On-Line Communication Services

1 0

Cache-as-cache-can
by Michael Haba 18 Nov '98

18 Nov '98

To cut a long story short, I was just wondering if people could extrapolate their feelings regarding commerical Web Cache solutions. In terms of the good, the bad and the ugly. At the moment I'm left with 'two goods' Network Appliance's NetCache and Inktomi's Traffic Server and would appreciate some input to sort them out. -Michael -- Michael Haba <m.haba(a)magnet.at> Telenor Magnet - Internet at Work

9 11

RE: AS_PATH length and route selection (WAS: Strange BGP announcement)
by Martin, Christian 18 Nov '98

18 Nov '98

> So, would anyone care to discuss (from an operational POV) what removing > AS_PATH length from the BGP route selection algorithm will do to the > Internet? You determine your local policy based on the tools that you have. If AS_PATH length were not in the algorithm by default, you could force it in there (in Cisco IOS) using route maps and regexps. For example: ! route-map MATCH_LONGER_THAN_5_ASPATH_HOPS permit 10 match as path 5 set local-preference 50 ! route-map DISCARD_LONGER_THAN_5ASPATH_HOPS permit set local-preference 100 ! ip as-path access-list 5 permit ^[0-9]+\ [0-9]+\ [0-9]+\ [0-9]+\ [0-9]+_ ! This goes for any routing protocol, not just BGP. -Chris

1 0

RE: Strange BGP announcement
by Martin, Christian 18 Nov '98

18 Nov '98

> > Patently false. In particular, the spec allows an > implementation to invoke > local policy when computing the local preference of a route. An > implementation can reasonably incorporate the AS path length > in its local > preference calculations as part of its policy. > > Tony > In Cisco IOS, this falls under the BGP decision process in selecting a route. So in an indirect way, this is already implemented. To be more exact in terms of the RFC, I suppose a match clause could be implemented based on path length, but this can be done already with a regular expression. Either way, the capability is there. -Chris

1 0

Re: Cache-as-cache-can
by Tony Li 18 Nov '98

18 Nov '98

paul(a)vix.com (Paul Vixie) writes: > There's a fourth. I used to manufacture something called the Web Gateway > Interceptor which was topologically a router. It wasn't competitive as > a router, either in price, performance, or number/kind of interfaces. But > you could put it in parallel with another router and integrate it into > your OSPF mesh and use OSPF link costs to make it be the primary path only > while it was up. HSRP would have worked the same way, and I'll admit that > it's a lot simpler to do (though I'm not sure it's an open standard yet?) HSRP is published as an Informational RFC. However, there is a patent on the protocol, assigned to Cisco. To the best of my knowledge, Cisco has not granted any licenses to that patent (yet). The VRRP working group selected the VRRP protocol instead of HSRP to place on the standards track, so at this point, it is unlikely that HSRP will become a standard (open or otherwise) anytime soon. Tony

1 0