- NANOG - lists.nanog.org

Operational: Wiltel Peering with MCI problems around D.C
by Rich Emmings 19 Aug '05

19 Aug '05

Anyone else (Wiltel customers especially) running into an operational issue around D.C. with partial connectivity It would seem MCI and Wiltel around D.C. have a 'informal' peering relationship and it's been errored right now for about 39 hours with a half-duplex route announcement. This has been effecting us with some loss of connectivity that's not there when we test same sites from other ISP clouds. Since it's informal, the help desk system at one or both ands may be having problem entering a ticket w/o an account number for the circuit. The usual channels are not producting results, and we're starting to get engineers on the lower end of the evoluationary food chain and finger pointing between wgc & mci that's not helping. Tried a pch, haven't heard yet. ... 5 nycmny2wcx2-pos0-0-oc192.wcg.net (64.200.68.157) 5.786 ms 6.510 ms 6.114 ms 6 hrndva1wcx2-pos1-0-oc192.wcg.net (64.200.210.178) 12.029 ms 11.883 ms 11.582 ms 7 washdc5lcx1-pos5-0.wcg.net (64.200.240.194) 12.840 ms 12.559 ms 12.887 ms ...traffic dies....

2 2

Re: Blocking certain terrorism/porn sites and DNS
by Hannigan, Martin 19 Aug '05

19 Aug '05

Since when is Internet email reliable? -----Original Message----- From: J. Oquendo [mailto:sil@politrix.org] Sent: Thu Aug 18 14:38:31 2005 To: nanog(a)nanog.org Cc: William Allen Simpson Subject: Re: Blocking certain terrorism/porn sites and DNS On Thu, 18 Aug 2005, William Allen Simpson wrote: > Apparently, you did.... Of course, repeated posting here will vastly > improve your opportunity to examine binaries handily delivered directly > to your own email box. ;-) "handily delivered directly to your own email box." I take note of "your own email box." So again I ask, how do you propose dealing with mail that was "handily delivered" to your clients' email boxes. Or would you just be assuming "if test -f LOOKS_LIKE_MY_EMAIL then filter_that". Either way you want to cut your comment it would take a bit of snooping to parse out traffic not destined to your own email box(es). So what do you tell your customer "Oh by the way we had to snoop in on your sessions to stop some new and improved MS uberworm." If so, when do you do it, when your network is crawling, after the fact... What if you're off by one and accidentally filter out say a contract worth a lot. Again, if I'm missing something by all means e-smack me. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo GPG Key ID 0x97B43D89 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x97B43D89 To conquer the enemy without resorting to war is the most desirable. The highest form of generalship is to conquer the enemy by strategy." - Sun Tzu

1 0

Re: Operational: Wiltel Peering with MCI problems around D.C
by Fergie (Paul Ferguson) 19 Aug '05

19 Aug '05

Would this be affecting MIT, too? I've been noticing some very odd connectivity issues between here (Austin) and the CSAIL at MIT.... - ferg -- Rich Emmings <rich(a)nic.umass.edu> wrote: Anyone else (Wiltel customers especially) running into an operational issue around D.C. with partial connectivity It would seem MCI and Wiltel around D.C. have a 'informal' peering relationship and it's been errored right now for about 39 hours with a half-duplex route announcement. This has been effecting us with some loss of connectivity that's not there when we test same sites from other ISP clouds. Since it's informal, the help desk system at one or both ands may be having problem entering a ticket w/o an account number for the circuit. The usual channels are not producting results, and we're starting to get engineers on the lower end of the evoluationary food chain and finger pointing between wgc & mci that's not helping. Tried a pch, haven't heard yet. ... 5 nycmny2wcx2-pos0-0-oc192.wcg.net (64.200.68.157) 5.786 ms 6.510 ms 6.114 ms 6 hrndva1wcx2-pos1-0-oc192.wcg.net (64.200.210.178) 12.029 ms 11.883 ms 11.582 ms 7 washdc5lcx1-pos5-0.wcg.net (64.200.240.194) 12.840 ms 12.559 ms 12.887 ms ...traffic dies.... -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

2 1

What application runs on port 8094?
by Joe Shen 19 Aug '05

19 Aug '05

Hi, Using netflow based monitor tool, I noticed there is a lot of traffic on 8094/UDP and 4662/TCP( both exceed 1Gbps, and exist all the time) What application use that port? Is there any P2P application use UDP as transportation protocol? thanks in advance. Joe __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 1GB free storage! http://sg.whatsnew.mail.yahoo.com

4 3

Blocking certain terrorism/porn sites and DNS
by Abhishek Verma 19 Aug '05

19 Aug '05

Hi, I have a doubt which i am sure a lot of people in this list would be able to help me with. There was news that terror groups like Al Qaida, etc. are using internet to promote their terror links and these web sites provide online training on how one could assemble bombs, etc. The community as a whole wants to close all such web sites. I dont think there is any ambiguity there. My question is why cant we ban websites like, say, alqaida.com (hypothetical name), etc. from the whois database. As far as i understand if there is a website with the name of www.abc.com then it needs to register itself with the whois database (from network solutions) so that all the queries to this website can be forwarded to the corresponding nameserver. Now, if we want to block abc.com permanently then cant we simply remove this URL entry from the whois database? Will this work? Thanks, Abhishek -- Class of 2004 Institute of Technology, BHU Varanasi, India

19 26

Whois Query Changes in the .ORG Registry, 20 August 2005 (2-day Notice)]
by Rick Wesson 18 Aug '05

18 Aug '05

FYI -rick -------- Original Message -------- Subject: [Org-Registrars] Whois Query Changes in the .ORG Registry, 20 August 2005 (2-day Notice) Date: Thu, 18 Aug 2005 13:47:36 -0400 From: PIR Technical Support <techsupport(a)pir.org> To: org-registrars(a)publicinterestregistry.net Dear Registrars, Please be advised that on 20 August 2005 between 15:00 and 17:00 UTC, the .ORG Whois (including port 43 and www.pir.org) is scheduled for downtime and will be unavailable. Please note that the .ORG Registry System will continue to operate normally and the Shared Registration System (SRS) and the Web-based Admin Interface will remain available. Registering and manipulating domain names and other registry objects will be possible. Domains will continue to resolve normally. During this downtime, PIR will implement the following changes to the Whois function for the .ORG Registry System. 1. Whois access for public Port 43 will be restricted to 4 queries per minute per unique IP address. 2. Registrars will be provided with additional access to Whois via a dedicated Whois server, whois2.publicinterestregistry.net. These changes are being made in response to the requests we have received from registrars and registrants to minimize the potential for data mining the .ORG Registry's Whois records. Whois Access for Public Port 43 ******************************* To reduce abusive use of the public Whois and ensure access for legitimate users, PIR is executing changes necessary to restrict Whois access to the public Port 43 to a maximum of 4 queries per minute per IP address. When a user exceeds the lookup quota allocated, the system will respond with an appropriate message. Registrar Specific Whois Access ******************************** All .ORG registrars will be provided with a dedicated Whois access server, whois2.publicinterestregistry.net. Registrars will still be able to access the public Port 43 Whois server, though the 4 queries per minute limitation will exist if this access mechanism is used. It is recommended that registrars utilize the separate dedicated Whois server that will be explicitly for registrar use. This access will allow registrars to have a less restrictive access of 50 queries per minute per source IP to Whois information. This dedicated Whois server will be available from a different hostname/IP address than the public Whois service. Additional information regarding registrar access to the dedicated Whois server and IP/Subnet requirements are located at https://www.pir.org/registrars/registrar_relations/faqs/whois_limitation. Registrars may choose to utilize both the public Whois on Port 43 and the separate dedicated server concurrently. Should you have any questions, please contact PIR Technical Support. Sincerely, PIR Technical Support <techsupport(a)pir.org> +1.416.646.3308

1 0

Re: New N.Y. Law Targets Hidden Net LD Tolls
by Richard A Steenbergen 18 Aug '05

18 Aug '05

On Thu, Aug 18, 2005 at 12:19:25AM -0700, William C. Devine II wrote: > Just about all of the ISP's in my area, even those I've worked for, had > a 'disclaimer' on their user agreement that said that some of the local > phone numbers might be long distance and that the user should call the > operator to verify it is a local call before placing the call. > Is that warning enough, or are they saying the ISP must keep a database > of users' addresses and specifically warn that user that out of the 10 > local call-in numbers, based on their zip code, these three (A, B, C) > could be long distance? To quote the original pasted article: > Consumers, however, must act on the warning that Internet providers must > soon post by contacting their phone companies to find out whether a > number is truly local. > > Many service providers already post such warnings. America Online Inc. > agreed to do so in 1989, while the New York Attorney General's Office in > 2001 secured similar agreements with 25 New York-based Internet > providers including AT&T Worldnet. Sounds like the standard notice that all reputable ISPs are probably already giving. Given the very real potential for grandma and grandpa to pick a number off a list which looks like it is in their area code and end up with a multi-thousand dollar phone bill the next month, I'm surprised consumer protection folks haven't asked for such a requirement sooner. On Thu, Aug 18, 2005 at 03:07:57AM -0400, Eric A. Hall wrote: > > Seems to me the appropriate response is for the AG office to pursue the > people who are running the toll scams, not to push enforcement out to > uninvolved third parties. Having dealt with AGs in the past, I know that's > just whistling dixie, but still the notion of introducing liability is > kind of spooky. I'm not sure which part of "this seems to have nothing to do with toll scams" wasn't clear the first time around, but this response still seems to have no basis given the facts... -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

7 13

Re: Blocking certain terrorism/porn sites and DNS
by J. Oquendo 18 Aug '05

18 Aug '05

On Thu, 18 Aug 2005, William Allen Simpson wrote: > Apparently, you did.... Of course, repeated posting here will vastly > improve your opportunity to examine binaries handily delivered directly > to your own email box. ;-) "handily delivered directly to your own email box." I take note of "your own email box." So again I ask, how do you propose dealing with mail that was "handily delivered" to your clients' email boxes. Or would you just be assuming "if test -f LOOKS_LIKE_MY_EMAIL then filter_that". Either way you want to cut your comment it would take a bit of snooping to parse out traffic not destined to your own email box(es). So what do you tell your customer "Oh by the way we had to snoop in on your sessions to stop some new and improved MS uberworm." If so, when do you do it, when your network is crawling, after the fact... What if you're off by one and accidentally filter out say a contract worth a lot. Again, if I'm missing something by all means e-smack me. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo GPG Key ID 0x97B43D89 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x97B43D89 To conquer the enemy without resorting to war is the most desirable. The highest form of generalship is to conquer the enemy by strategy." - Sun Tzu

1 0

Re: Blocking certain terrorism/porn sites and DNS
by J. Oquendo 18 Aug '05

18 Aug '05

On Thu, 18 Aug 2005, William Allen Simpson wrote: > Bad assumption. After all, terrorist is poorly defined, and from the > perspective of a particular government. Interesting you say this, same comes to mind concerning terrorists using so called cryptography simply because an agent of some government found "crypt.dll" on a machine and decided "By the love of INSERT_YOUR_DEITY_HERE they're using crypto now!" > Funny thing though, they don't seem to call their sites "spam-king", > but instead "opt-in-real-big", or the equivalent. So, we have to > examine their binaries to find the sites. Isn't this sort of ironic. To "not" want to "police" yet want to examine "binaries to find sites." And how may I ask are you going to examine these binaries via traffic. Isn't that to the tune of an illegal tap being you would unlawfully check email in and out of your network. Or did I miss something. As for filtering sites from Spam/Porn/etc., on the ISP level, someone would have to be a complete reject to do so. I know I wouldn't want anything filtered. On a corporate level, I right now have to filter a lot of unwanted junk and recently had to tone down my filtering. HR woman searched for sexual harrassment and could not get information because my rules were stringent. Filtering on an ISP/NSP level I think is a horrible idea because I believe everyone has the right to free speech and thought. Filtering is also likely to introduce unwanted latency. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo GPG Key ID 0x97B43D89 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x97B43D89 To conquer the enemy without resorting to war is the most desirable. The highest form of generalship is to conquer the enemy by strategy." - Sun Tzu

2 1

Re: zotob - blocking tcp/445
by Roger Marquis 18 Aug '05

18 Aug '05

Andy Johnson wrote: > I think the point of many on this list is, they are a transit > provider, not a security provider. They should not need to filter > your traffic, that should be up to the end user/edge network to > decide for themselves. How is this different from a transit provider allowing their network to be used for spam? Seems the same hands-off argument was made wrt spam a decade ago but has since proved unsustainable. Our particular problem is with an ISP in Wisconsin, NETNET-WAN. We get tens of thousands of scans to netbios ports every day from their /19. This is several orders of magnitude more netbios than we see from the rest of the net combined. It's eating nontrivial bandwidth and cpu that we pay real money for. They've had our logs for months but seem incapable of doing anything about their infected customers. The suits recommend documenting time and bandwidth costs and sending a bill with a cease and desist request. My question is not what can we do about bots, we already filter these worst case networks, but what can we do to make it worthwhile for bot-providers like NETNET to police their own networks without involving lawyers? -- Roger Marquis Roble Systems Consulting http://www.roble.com/

5 4