- Test - lists.nanog.org

mci-rr
by jamie＠intuition.iagnet.net 08 Jan '98

08 Jan '98

Anyone getting similar problems? Message 83/84 Mail Delivery Subsystem Jan 7, 98 04:06:04 pm -0500 Postmaster notify: Cannot send message within 5 days Return-Path: <> Date: Wed, 7 Jan 1998 16:06:04 -0500 (EST) Auto-Submitted: auto-generated (postmaster-notification) [Attach #1: ""] [Type: text/plain, Encoding: 7bit, Size: 370] The original message was received at Fri, 2 Jan 1998 15:45:24 -0500 (EST) from localhost ----- The following addresses had permanent fatal errors ----- <mci-rr(a)RR.mci.net> ----- Transcript of session follows ----- <mci-rr(a)RR.mci.net>... Deferred: Connection timed out with rr.mci.net. Message could not be delivered for 5 days Message will be deleted from queue -- james g.k. rishaw dal/efnet:gavroche __ IAGnet/CIC/netILLINOIS Backoffice DID:216.902.5455 FAX:216.623.3566 \/ 800.637.4IAGx5455 "The man who doesn't read good books has no advantage over the man who can't read them." - Mark Twain

2 2

Netscape sites very slow today
by Tony Torzillo 08 Jan '98

08 Jan '98

This may be of interest to anyone who received complaints of slowness to the Netscape home page yesterday. You can't use anything in this message to configure your router. ---------- Forwarded message ---------- Date: Wed, 07 Jan 1998 14:48:44 -0700 From: Duane Wessels <wessels(a)nlanr.net> To: ircache(a)nlanr.net Cc: Jeff Halper <squid(a)ihot.com> Subject: Re: Netscape sites very slow today Resent-Date: Wed, 7 Jan 1998 13:52:20 -0800 (PST) Resent-From: ircache(a)nlanr.net Yesterday, Jeff Halper asked this on our squid-users list: >I use parent cache sv - noticed it was uusually slow in fetching sites at >netscape.com today - any suggestions? The problem turned out to be sort of interesting, so I thought I'd share it with you... First I thought I'd see if Jeff was imagining things or if there really was a difference. So I looked at the "service time" value for *.netscape.com requests from four days of access logs. The results were: Median Service Date Time (seconds) ----- -------------- Jan 3 2.47 Jan 4 3.47 Jan 5 5.81 Jan 6 76.17 So obviously, something was seriously wrong. The next thing to try was a simple ping: sv-wessels> ping www.netscape.com PING www-uk2.netscape.com (195.44.254.3): 56 data bytes 64 bytes from 195.44.254.3: icmp_seq=5 ttl=248 time=603 ms 64 bytes from 195.44.254.3: icmp_seq=6 ttl=248 time=550 ms Say what? WWW-UK2? sv.cache, located at FIX-West, uses ns.arc.nasa.gov for DNS service. Every time I checked the rest of that day, ns.arc.nasa.gov always returned www-uk2.netscape.com, even though the DNS TTL was quite low (less 15 minutes). dig @ns.arc.nasa.gov www.netscape.com ; <<>> DiG 2.0 <<>> @ns.arc.nasa.gov www.netscape.com ;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 10 ;; flags: qr rd ra ; Ques: 1, Ans: 2, Auth: 3, Addit: 3 ;; QUESTIONS: ;; www.netscape.com, type = A, class = IN ;; ANSWERS: www.netscape.com. 94 CNAME www-uk2.netscape.com. www-uk2.netscape.com. 2344 A 195.44.254.3 Looks to me like some DNS smart-resolution feature gone haywire. I sent mail to dns-admin(a)netscape.com, but have yet to get a reply. Since it seemed that ns.arc.nasa.gov was not going to "fix itself" any time soon, I changed sv's resolv.conf to use a different DNS server temporarily. Today, ns.arc.nasa.gov is giving us good answers (www24.netscape.com) Shrug. Duane W.

2 1

RE: A NetSat prospect?
by Jeremy Morrison 07 Jan '98

07 Jan '98

Hank: I hear you are looking for hybrid connectivity into the Middle East. NetSat Express (www.netsatx.net) is looking into the region to begin offering services. I invite you to look through our homepages and send me a line if you would like more information. Best Regards, Jeremy Morrison >Date: Wed, 31 Dec 1997 15:58:51 +0200 >From: Hank Nussbacher <hank(a)ibm.net.il> >To: nanog(a)merit.edu >Subject: Looking for unidirectional simplex satlink > >Can anyone point me at satellite providers who provide Internet >unidirectional (simplex) satellite transmissions at E1 speed (unshared, >non-broadcast), other than Interpacket, that cover the Middle East area? > >Thanks, >Hank

1 0

Governments want to change Net architecture
by Declan McCullagh 07 Jan '98

07 Jan '98

======== Date: Wed, 7 Jan 1998 07:44:57 -0800 (PST) From: Declan McCullagh <declan(a)well.com> To: politech(a)vorlon.mit.edu Subject: FC: Governments want to change Net architecture, from Comm Daily X-URL: Politech is at http://www.well.com/~declan/politech/ [Apologies to Art for not forwarding this earlier. --Declan] ---------- Forwarded message ---------- Date: Thu, 18 Dec 1997 10:28:49 -0500 From: Art Brodsky <arb(a)well.com> To: declan(a)smtp.well.com Subject: comm daily story Declan, Here's the story from Comm Daily, Dec. 17 'Optimistic and Damned Silly' INTERNET CHANGE FOCUS OF INTERNATIONAL LAW ENFORCEMENT Law enforcement officials of U.S. and 7 other industrialized countries want to make fundamental changes in Internet technology in order to aid in their ability to track and catch criminals, Justice Dept. sources said. Program to consider changes in Internet architectures comes as part of agreement announced last week by Attorney Gen. Janet Reno and Justice ministers from around world after meeting in Washington (CD Dec 11 p10). However, one leading Internet authority, MCI Senior Vp Vinton Cerf, said international group's plan wouldn't work. Justice ministers are considering approach similar to that of Communications Assistance to Law Enforcement Act (CALEA) program in U.S., which would make traffic from advanced telecom networks more accessible to law enforcement entities. Representatives of Canada, France, Germany, Italy, Japan, Russia and U.K., as well as U.S., agreed as part of "statement of principles" issued in communique following 2-day session that: "To the extent practicable, information and telecommunications systems should be designed to help prevent and detect network abuse, and should also facilitate the tracing of criminals and the collection of evidence." Several items on "action plan" issued in support of those principles refer to working with new technologies to collect critical evidence, developing standards for authenticating electronic data for use in investigations and encouraging standards-making bodies to provide public and private sectors "with standards for reliable and secure telecommunications and data processing technologies." DoJ officials said Dept. may want to talk later with telephone industry on trap and trace issues, but it's premature to involve them now in follow-up to international summit. Instead, they said, they are looking at broader picture of telecom networks that haven't worked as closely with law enforcement as they could, and have begun thinking about Internet protocols. Internet operates globally with common protocols, currently Internet Protocol version 4. Internet engineers are working on next iteration, version IPv6 (Internet Protocol version 6 -- 5 was experimental attempt that was dropped). Justice official said that one problem now is that it's easy to send and receive e-mail with false address, called "spoofing." It would be helpful to law enforcement if information sent over Internet were tagged, and packets would transmit information reliably as to where they came from, including user and service provider, officials said. Loose analogy would be to compare e-mail messages to tagging of explosives, so law enforcement can track explosive material to its source. DoJ said new protocols could be designed to make it easier to authenticate messages and to make system more reliable. Law enforcement wants to work with industry to accomplish goal, saying it would help "keep people who are abusing information technologies from continuing to do it." There will be substantial obstacles to law enforcement concept, however. Not least of them is that IPv6 will include sophisticated encryption capabilities as part of protocols. Such security isn't built in to Internet now, one of reasons why electronic commerce has yet to take off, said Mark McFadden, communications dir. for Commercial Internet eXchange Assn. (CIX). That feature will make it harder for law enforcement to gain access to information, he said. Cerf, co-inventor of Internet protocols, said in interview that law enforcement's concept of tagging e-mail messages wouldn't work: "To imagine that we would instantly create the infrastructure for that throughout the entire Internet strikes me as optimistic and damned silly, at least in the short term. Anyone who anticipates using tools to guarantee that everything will be traceable is not going to have a successful outcome." Technically, such project could be accomplished, Cerf said, but having administrative infrastructure to administer it is quite different issue. It's possible to have digital signature for every packet of data, but it would take "an enormous amount of processing, and it's not clear we have any network computers and routers that could do that and maintain the traffic flow that's required," Cerf said. It also would require that each sender affix digital signature to each piece of mail, idea that Cerf said couldn't be enforced: "Frankly, the idea of trying to guarantee traceability of that kind is far from implementable." He said he didn't want to be misunderstood that his objections were "an argument in favor of criminality." But Cerf said he worries that "someone relies on what they think is a technical solution without recognizing all of the administrative mechanics that need to be put in place." Law enforcement has some time to work with Internet community. McFadden said IPv6 isn't scheduled to be implemented at consumer level for at least 5 years, possibly as much as 10. There was some urgency when it appeared that reservoir of Internet addresses would dry up, but with progress being made to protect addresses as scarce resource there's less pressure for new set of protocols, he said. posted with permission Warren Publishing -------------------------------------------------------------------------- POLITECH -- the moderated mailing list of politics and technology To subscribe: send a message to majordomo(a)vorlon.mit.edu with this text: subscribe politech More information is at http://www.well.com/~declan/politech/ --------------------------------------------------------------------------

1 0

peering policies and spam
by Jeremy Porter 07 Jan '98

07 Jan '98

Have any providers gone on record as stating that they are going to require anti-spam policies in their future peering agreements? We have the case of a spam attack coming from Cable and Wireless CWIX.NET customer: Here is CWIX saying its ok to send in bulk unsolicited email. We are going to require that our service providers and peers argee to not pass us spam traffic, by whatever means that they want to impelement. As a stop gap, I imaging a route map to map all prefixes arriving out of AS 5683 to Null0 for the time being will a stop gap, until we can get our providers to drop peering with these idiots. I imagine we will also be pursing legal action as these people are located in state. >Here is the official response from CWIX.NET (cable wireless ex) >Patrick >>>>> >><excerpt>Sender: lawrence(a)tipa2.cwix.net >>Date: Mon, 05 Jan 1998 19:20:34 -0500 >>From: Lawrence Guidry >>Organization: Cable & Wireless Internet Exchange (CWIX) >>To: "Patrick Michael O'Leary" >>Subject: [Fwd: Ticket #92258 (craig) Spammed email to our site! >> >> >>Upon investigation, your complaint appears to be without merit. >> >> >>The simple act of sending commercial bulk e-mail to your clientelle is >>not in and of itself a violation of our AUP. >> >> >>Any issues of complaint regarding plagerism towards Roy Bronson are >>between you and he. >> >> >>Of course, please feel free to re-clarify your complaint for further >>consideration by us. --- Jeremy Porter, Freeside Communications, Inc. jerry(a)fc.net PO BOX 80315 Austin, Tx 78708 | 1-800-968-8750 | 512-458-9810 http://www.fc.net

2 1

AOL Web caching?
by Brian Horvitz 07 Jan '98

07 Jan '98

Has anyone else exerienced problems with AOL's web proxy servers? We switched the IP address of a web site about 5 months ago, and we are still getting about 10,000 hits a day from AOL on the old address. We dropped a note to them a ways back but didn't get much of a response. Brian Horvitz Shore.Net

11 11

Wired article: Smurfing Cripples ISP's
by Paul Ferguson 07 Jan '98

07 Jan '98

See: http://www.wired.com/news/news/technology/story/9506.html - paul

1 0

UDP port 137 Question
by C. Jon Larsen 07 Jan '98

07 Jan '98

Is there any *valid* reason to see UDP traffic directed at a unix box's port 137 coming from IP sources across the internet ? The unix servers in question are most definitely *not* running samba, and there is absolutely no NT anywhere on this customer's network (that is seeing the incoming UDP traffic directed at an IP destination address on port 137). (A couple of 95 boxes scattered across an Ethernet comprise the Micro$oft part of the network). None of the 95 boxen are running any file or print serving (sharing) resources. I can't think of any valid reason to see this traffic, personally. Anybody out there that can present a scenario where I would expect to see these UDP packets coming back in ? netbios-ns 137/tcp nbns netbios-ns 137/udp nbns netbios-dgm 138/tcp nbdgm netbios-dgm 138/udp nbdgm netbios-ssn 139/tcp nbssn =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- C. Jon Larsen Email: jlarsen(a)ford.ajtech.com Systems Engineer Voice: +1.804.353.2800 x118 A&J Technologies http://www.ajtech.com PGP Key fingerprint: 8A 62 4C 6E 1E 3C CD 63 B3 16 1A 1B D2 61 EE 97 PGP Public key available at: http://ford.ajtech.com/CJL.txt =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

12 15

Re: UDP port 137 Question
by Paul Thornton 07 Jan '98

07 Jan '98

I noticed similar port 137 hits a while back, and after a bit of investigating discovered that every time a colleague visited a web site (using Netscape, incidentally) the server sent a port 137 request back to the client PC. Initially I thought this was a "helpful" MS extension in their server, but have since seen port 137 hits from their nameservers as well. This probably points to some interesting name lookups going on at there end, which results in a NetBIOS name lookup being sent back. Somewhere I have the address of the server in question - I'll dig it out if there is interest. If nothing else, their hit count will go up ;-) Paul -- Paul Thornton, Network Engineer, London Internet Exchange Ltd. Tel: 07000 783797 Mobile: +44 467 372205

2 1

Re: route ingress
by Vadim Antonov 07 Jan '98

07 Jan '98

The issue here is people deliberately injecting bogus routing information. Any "chain of trust" systems break down if there's somebody abusing the trust. This means that tier-1 ISPs shouldn't trust routing information coming from tier-2 ISPs, etc. That leaves the only workable option - cryptographical authentication of routes, by the presense of signature by a trusted address space registry. --vadim Date: Wed, 7 Jan 1998 12:39:26 +0300 (MSK) From: "Alex P. Rudnev" <alex(a)Relcom.EU.net> To: Vadim Antonov <avg(a)pluris.com> I am sorry, but what for do you want it? Why is not efficient to use AS identification in conjuction to IP prefix filtering at the 1't level ISPs (and may be 2'nd level too), based on the NIC data base. On Tue, 6 Jan 1998, Vadim Antonov wrote: > Date: Tue, 06 Jan 1998 13:23:47 -0800 > From: Vadim Antonov <avg(a)pluris.com> > To: "Sean M. Doran" <smd(a)clock.org>, nanog(a)merit.edu > Subject: Re: route ingress > > Sean M. Doran wrote: > > > Vadim Antonov ?avg(a)pluris.com? writes: > > > > ? The only real solution is strong cryptographical authentication of > > ? the ownership of routing prefixes. For some reason i do not see > > ? any serious work in that direction being done. > > > > This would be much easier if we had a bottom-up > > hierarchical addressing structure rather than the > > current top-down one. > > I quite agree with that (though i'm not convinced that "bottom->top" > allocation combined with recursive NATting is the best architecture). > > However, this does not preclude doing authentication with the current > routing system. > > --vadim

1 0