- NANOG - lists.nanog.org

Boston UUNET Issue(s)
by Williams, Ken 24 Jun '04

24 Jun '04

Did anyone notice any network related issues on the Boston UUNET network earlier this morning (4:00AM PST -> 8:30 AM PST). What we observed was high latency for the following network 208.254.32.0/20? Regards, Ken Williams

1 0

RE: Unplugging spamming PCs
by Larry Pingree 24 Jun '04

24 Jun '04

Hi Joe, If only those who are approved email senders are allowed to be accepted, this allows police, FBI, or DHS to go after only those who are registered and abusing it. It's for the same purpose that we administer car registrations, so that at the end of the day, someone is responsible for the car. In this case, someone can be responsible for the domain and mail server. In its current state, we are left way in the open. I don't disagree that government control is un-desirable, but remember, at least in my mind, even though it may be undesirable, it may be a necessary action. Anyone know why we have to get a drivers license? How about a passport? What about a SSN? All of these things are ways in which we can have accountability. Without accountability we will remain in anarchy. All that government does is bridge a gap when corporations, which only do things for profit, will not collaborate on an appropriate solution to a problem, even though one exists. LP Best Regards, Larry Larry Pingree "Visionary people, are visionary, partly because of the great many things they never get to see." - Larry Pingree -----Original Message----- From: Joe Hamelin [mailto:nethead@gmail.com] Sent: Wednesday, June 23, 2004 5:26 PM To: Larry Pingree Cc: nanog(a)nanog.org Subject: Re: Unplugging spamming PCs On Wed, 23 Jun 2004 16:40:23 -0700, Larry Pingree <lpingree(a)juniper.net> wrote: > I agree with you it's a hard problem to solve. But unless there is > mandatory cooperation within mail server software (which can be > monitored) to interface with a registry of acceptable/registered sites, > then this model could work. I can telnet to a mailserver and send mail to that host without much thought. What good will a registry do? What will solve spam is getting some of these virus writers to actually write some code that will trash disks of poorly patched (if a at all) hosts. Let Darwin take over. -Joe

3 2

RE: Unplugging spamming PCs
by Larry Pingree 24 Jun '04

24 Jun '04

But if you telnet from an IP that is not registered, you would be denied. Thus at least eliminating many of the erroneous email servers out there on the DSL, dial-up and other broadband connections, this has been tried in the open with such things as MABS RBL, etc by blocking common spamming IP's and mail servers. But since it is not mandatory, it falls apart too easily. LP Best Regards, Larry Larry Pingree "Visionary people, are visionary, partly because of the great many things they never get to see." - Larry Pingree -----Original Message----- From: Joe Hamelin [mailto:nethead@gmail.com] Sent: Wednesday, June 23, 2004 5:26 PM To: Larry Pingree Cc: nanog(a)nanog.org Subject: Re: Unplugging spamming PCs On Wed, 23 Jun 2004 16:40:23 -0700, Larry Pingree <lpingree(a)juniper.net> wrote: > I agree with you it's a hard problem to solve. But unless there is > mandatory cooperation within mail server software (which can be > monitored) to interface with a registry of acceptable/registered sites, > then this model could work. I can telnet to a mailserver and send mail to that host without much thought. What good will a registry do? What will solve spam is getting some of these virus writers to actually write some code that will trash disks of poorly patched (if a at all) hosts. Let Darwin take over. -Joe

1 0

RE: Homeland Security now wants to restrict outage notifications
by Larry Pingree 24 Jun '04

24 Jun '04

I agree, there are much more important things to protect than this information. It would be almost impossible to manage, and even more unlikely to ever have a positive effect. Besides, if someone with ill intentions has the abilities to act so quickly on such short notice, then we have much greater failures of our intelligence system that would need to be addressed. LP Best Regards, Larry Larry Pingree "Visionary people, are visionary, partly because of the great many things they never get to see." - Larry Pingree -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Scott McGrath Sent: Thursday, June 24, 2004 11:06 AM To: nanog(a)merit.edu Subject: RE: Homeland Security now wants to restrict outage notifications I did read the article and having worked for gov't agencies twice in my career a proposal like the one floated by DHS is just the camel's nose. I should hope the carriers oppose this. Now a call comes into our ops center "I cant reach my experiment at Stanford". Ops looks up the outages Oh yeah there's a fiber cut affecting service we will let you know when it's fixed. They check it's fixed they call the customer telling them to try it now. Under the proposed regime "We know its dead do not know why or when it will be fixed because it' classified information" This makes for absolutely wonderful customer service and it protects public safety how?. Scott C. McGrath On Thu, 24 Jun 2004, Tad Grosvenor wrote: > Did you read the article? The DHS is urging that the FCC drop the proposal > to require outage reporting for "significant outages." This isn't the DHS > saying that outage notifications should be muted. The article also > mentions: "Telecom companies are generally against the proposed new > reporting requirements, arguing that the industry's voluntary efforts are > sufficient." > > -Tad > > > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > Scott McGrath > Sent: Thursday, June 24, 2004 12:58 PM > To: nanog(a)merit.edu > Subject: Homeland Security now wants to restrict outage notifications > > > > See > > http://www.theregister.co.uk/2004/06/24/network_outages/ > > for the gory details. The Sean Gorman debacle was just the beginning > this country is becoming more like the Soviet Union under Stalin every > passing day in its xenophobic paranoia all we need now is a new version of > the NKVD to enforce the homeland security directives. > > Scott C. McGrath > >

1 0

MTU discovery
by Edward B. Dreger 24 Jun '04

24 Jun '04

Is it just me, or are more sites breaking pmtud these days? It's getting tempting to hack up ietf-pmtud-method support even before it becomes standard... Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses: davidc(a)brics.com -*- jfconmaapaq(a)intc.net -*- sam(a)everquick.net Sending mail to spambait addresses is a great way to get blocked.

3 2

RE: .ORG DNS Problem?
by Mike Damm 24 Jun '04

24 Jun '04

<rant> A reminder to folks giving status reports on anycasted DNS deployments, don't forget to mention which node you are querying. For the F root (and other BIND implementations): dig +norec @f.root-servers.net hostname.bind chaos txt For UltraDNS: dig +norec @tld1.ultradns.net whoareyou.ultradns.net in a </rant> I'm seeing no problems with tld1.ultradns.net (udns2pxpa.ultradns.net) or tld2.ultradns.net (udns2eqsj.ultradns.net) -Mike -----Original Message----- From: Alexander Bochmann [mailto:ab@lists.gxis.de] Sent: Thursday, June 24, 2004 7:49 AM To: nanog(a)nanog.org Subject: Re: .ORG DNS Problem? Hi, ...on Thu, Jun 24, 2004 at 11:18:26AM -0400, Adam Kujawski wrote: > Anybody else having problems resolving .ORG domains via TLD1.ULTRADNS.NET > (204.74.112.1) and TLD2.ULTRADNS.NET. (204.74.113.1). I'm seeing slow > respones, or no responses. Same here, until a few minutes ago. Didn't work (connection timed out) from various places in Europe, while I had no problems when coming from a host in the US. Alex. -- AB54-RIPE

2 1

.ORG DNS Problem?
by Adam Kujawski 24 Jun '04

24 Jun '04

Anybody else having problems resolving .ORG domains via TLD1.ULTRADNS.NET (204.74.112.1) and TLD2.ULTRADNS.NET. (204.74.113.1). I'm seeing slow respones, or no responses. Traceroutes look fine: % tcptraceroute 204.74.112.1 53 Selected device fxp0, address 64.246.100.1, port 55786 for outgoing packets Tracing the path to 204.74.112.1 on TCP port 53, 30 hops max 1 fastethernet-0-0.angola-gw.amplex.net (64.246.100.126) 9.403 ms 7.361 ms 9.148 ms 2 dtrtmi1wce1-ser2-5-5.wcg.net (65.77.89.53) 9.801 ms 8.061 ms 9.917 ms 3 brvwil1wcx2-pos14-1.wcg.net (64.200.240.33) 9.748 ms 8.341 ms 9.612 ms 4 chcgil9lcx1-pos6-0-oc48.wcg.net (64.200.103.118) 10.001 ms 9.172 ms 8.762 ms 5 ge-4-3-0.r00.chcgil06.us.bb.verio.net (206.223.119.12) 9.646 ms 8.960 ms 9.502 ms 6 ge-0-3-0.r02.chcgil06.us.bb.verio.net (129.250.2.121) 9.323 ms 9.071 ms 9.039 ms 7 ge-1-1.a00.chcgil07.us.ra.verio.net (129.250.25.136) 9.848 ms 9.306 ms 9.003 ms 8 fa-2-1.a00.chcgil07.us.ce.verio.net (128.242.186.134) 9.679 ms 9.697 ms 9.684 ms 9 tld1.ultradns.net (204.74.112.1) [open] 10.296 ms 10.625 ms 9.537 ms -AND - % tcptraceroute 204.74.113.1 53 Selected device fxp0, address 64.246.100.1, port 55792 for outgoing packets Tracing the path to 204.74.113.1 on TCP port 53, 30 hops max 1 fastethernet-0-0.angola-gw.amplex.net (64.246.100.126) 5.402 ms 7.282 ms 9.738 ms 2 dtrtmi1wce1-ser2-5-5.wcg.net (65.77.89.53) 9.973 ms 7.958 ms 9.909 ms 3 brvwil1wcx2-pos14-1.wcg.net (64.200.240.33) 9.800 ms 10.295 ms 8.835 ms 4 chcgil9lcx1-pos6-0-oc48.wcg.net (64.200.103.118) 8.878 ms 8.786 ms 9.187 ms 5 fe9-2.IR1.Chicago2-IL.us.xo.net (206.111.2.149) 9.512 ms 8.964 ms 8.869 ms 6 p5-0-0.RAR2.Chicago-IL.us.xo.net (65.106.6.137) 9.580 ms 9.214 ms 9.120 ms 7 p4-1-0.MAR2.Chicago-IL.us.xo.net (65.106.6.154) 9.512 ms 10.285 ms 9.594 ms 8 p15-0.CHR1.Chicago-IL.us.xo.net (207.88.84.14) 10.126 ms 9.517 ms 9.472 ms 9 10.11.102.1 (10.11.102.1) 10.990 ms 9.808 ms 10.182 ms 10 tld2.ultradns.net (204.74.113.1) [open] 9.933 ms 10.124 ms 9.778 ms Source IP for the traceroutes is 64.246.100.1. Dig's don't get very far: % dig nanog.org +trace ; <<>> DiG 9.2.2-P3 <<>> nanog.org +trace ;; global options: printcmd . 300086 IN NS C.ROOT-SERVERS.NET. . 300086 IN NS D.ROOT-SERVERS.NET. . 300086 IN NS E.ROOT-SERVERS.NET. . 300086 IN NS F.ROOT-SERVERS.NET. . 300086 IN NS G.ROOT-SERVERS.NET. . 300086 IN NS H.ROOT-SERVERS.NET. . 300086 IN NS I.ROOT-SERVERS.NET. . 300086 IN NS J.ROOT-SERVERS.NET. . 300086 IN NS K.ROOT-SERVERS.NET. . 300086 IN NS L.ROOT-SERVERS.NET. . 300086 IN NS M.ROOT-SERVERS.NET. . 300086 IN NS A.ROOT-SERVERS.NET. . 300086 IN NS B.ROOT-SERVERS.NET. ;; Received 388 bytes from 64.246.100.1#53(64.246.100.1) in 10 ms org. 172800 IN NS TLD1.ULTRADNS.NET. org. 172800 IN NS TLD2.ULTRADNS.NET. ;; Received 109 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 9 ms ;; connection timed out; no servers could be reached -Adam

2 2

RE: .ORG DNS Problem?
by Cody Lerum 24 Jun '04

24 Jun '04

Seeing it also.. Resolving intermittently, but timeouts abound. -C -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Adam Kujawski Sent: Thursday, June 24, 2004 9:18 AM To: nanog(a)nanog.org Subject: .ORG DNS Problem? Anybody else having problems resolving .ORG domains via TLD1.ULTRADNS.NET (204.74.112.1) and TLD2.ULTRADNS.NET. (204.74.113.1). I'm seeing slow respones, or no responses. Traceroutes look fine: % tcptraceroute 204.74.112.1 53 Selected device fxp0, address 64.246.100.1, port 55786 for outgoing packets Tracing the path to 204.74.112.1 on TCP port 53, 30 hops max 1 fastethernet-0-0.angola-gw.amplex.net (64.246.100.126) 9.403 ms 7.361 ms 9.148 ms 2 dtrtmi1wce1-ser2-5-5.wcg.net (65.77.89.53) 9.801 ms 8.061 ms 9.917 ms 3 brvwil1wcx2-pos14-1.wcg.net (64.200.240.33) 9.748 ms 8.341 ms 9.612 ms 4 chcgil9lcx1-pos6-0-oc48.wcg.net (64.200.103.118) 10.001 ms 9.172 ms 8.762 ms 5 ge-4-3-0.r00.chcgil06.us.bb.verio.net (206.223.119.12) 9.646 ms 8.960 ms 9.502 ms 6 ge-0-3-0.r02.chcgil06.us.bb.verio.net (129.250.2.121) 9.323 ms 9.071 ms 9.039 ms 7 ge-1-1.a00.chcgil07.us.ra.verio.net (129.250.25.136) 9.848 ms 9.306 ms 9.003 ms 8 fa-2-1.a00.chcgil07.us.ce.verio.net (128.242.186.134) 9.679 ms 9.697 ms 9.684 ms 9 tld1.ultradns.net (204.74.112.1) [open] 10.296 ms 10.625 ms 9.537 ms -AND - % tcptraceroute 204.74.113.1 53 Selected device fxp0, address 64.246.100.1, port 55792 for outgoing packets Tracing the path to 204.74.113.1 on TCP port 53, 30 hops max 1 fastethernet-0-0.angola-gw.amplex.net (64.246.100.126) 5.402 ms 7.282 ms 9.738 ms 2 dtrtmi1wce1-ser2-5-5.wcg.net (65.77.89.53) 9.973 ms 7.958 ms 9.909 ms 3 brvwil1wcx2-pos14-1.wcg.net (64.200.240.33) 9.800 ms 10.295 ms 8.835 ms 4 chcgil9lcx1-pos6-0-oc48.wcg.net (64.200.103.118) 8.878 ms 8.786 ms 9.187 ms 5 fe9-2.IR1.Chicago2-IL.us.xo.net (206.111.2.149) 9.512 ms 8.964 ms 8.869 ms 6 p5-0-0.RAR2.Chicago-IL.us.xo.net (65.106.6.137) 9.580 ms 9.214 ms 9.120 ms 7 p4-1-0.MAR2.Chicago-IL.us.xo.net (65.106.6.154) 9.512 ms 10.285 ms 9.594 ms 8 p15-0.CHR1.Chicago-IL.us.xo.net (207.88.84.14) 10.126 ms 9.517 ms 9.472 ms 9 10.11.102.1 (10.11.102.1) 10.990 ms 9.808 ms 10.182 ms 10 tld2.ultradns.net (204.74.113.1) [open] 9.933 ms 10.124 ms 9.778 ms Source IP for the traceroutes is 64.246.100.1. Dig's don't get very far: % dig nanog.org +trace ; <<>> DiG 9.2.2-P3 <<>> nanog.org +trace ;; global options: printcmd . 300086 IN NS C.ROOT-SERVERS.NET. . 300086 IN NS D.ROOT-SERVERS.NET. . 300086 IN NS E.ROOT-SERVERS.NET. . 300086 IN NS F.ROOT-SERVERS.NET. . 300086 IN NS G.ROOT-SERVERS.NET. . 300086 IN NS H.ROOT-SERVERS.NET. . 300086 IN NS I.ROOT-SERVERS.NET. . 300086 IN NS J.ROOT-SERVERS.NET. . 300086 IN NS K.ROOT-SERVERS.NET. . 300086 IN NS L.ROOT-SERVERS.NET. . 300086 IN NS M.ROOT-SERVERS.NET. . 300086 IN NS A.ROOT-SERVERS.NET. . 300086 IN NS B.ROOT-SERVERS.NET. ;; Received 388 bytes from 64.246.100.1#53(64.246.100.1) in 10 ms org. 172800 IN NS TLD1.ULTRADNS.NET. org. 172800 IN NS TLD2.ULTRADNS.NET. ;; Received 109 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 9 ms ;; connection timed out; no servers could be reached -Adam

1 0

Re: Unplugging spamming PCs
by Michael.Dillon＠radianz.com 24 Jun '04

24 Jun '04

> That sentence is A joke 15000 subscribers affected A joke? Doing hard time is no joke. > http://www.reuters.com/newsArticle.jhtml; > jsessionid=IPQ4NZVA4P24ACRBAELCFEY?type=technologyNews&storyID=5504916 Maybe I read the Russian wrong here http://www.echel.ru/news/?page=2&id=3421#3421 but it seemed to me like he was sentenced to two years with the possibility of early release after one year. Nevertheless, when you read the details of what he actually did, this is a real wakeup call for anyone in Russia who sends spam. The police take it as seriously as releasing viruses or worms. Wouldn't we all like to see our courts treat spammers this way? Write a few lines of PERL to pump out SPAM and go to jail. --Michael Dillon

1 0

Re: Can a customer take IP's with them?
by Howard C. Berkowitz 24 Jun '04

24 Jun '04

>does your contract with your customers state that the space >is non-portable, that they can't take it with them and that >they WILL have to renumber ?? If so then they are asking >the court to change the contract you and they entered, which >i doubt would happen. > >the legal risk here is if the court gets it in their head >that IP's are like phone numbers and that they (numbers) >should be portable...... > >Judge: "So what exactly is an IP address" > >Plantif: "Judge, an IP address is a unique number that is >assigned to each computer on my clients network. It unique >like a phone number, and like each person in the company has >a unique phone number, they must have a unique IP address" > >Judge: "So basicly its like a phone number for computers." > >Plantif: "Yes" This would absolutely have to be challenged on cross-examination. Were I the attorney, especially if the plaintiff had mentioned telephone number portability, I would ask the plaintiff to explain what additional work had to be done to the POTS network to implement portability. Should the plaintiff start mumbling, I'd impugn his credibility, and then ask a bunch of hard questions about SS7 (including the TCAP mechanism for portable number translation), how IP routing works, how IP routing has no authoritative mechanism for global translation, etc. I'd interrogate the customer about DNS and why they weren't able to solve their portability requirement with it. I'd look for detailed familiarity with RFC 2071 and 2072. I wouldn't expect the customer to be able to answer many of these. As the defendant, I would expect to bring in my own expert witness who is very good at explaining these differences, and how the telephone and IP routing environments are different. > >also how much space are we talking about here ?? a /19 >or a /27 ? or ??? If its smaller than a /20, Hell >let them announce it, most places won't take the route >and their connectivity will be dorked. > >You might also advise ARIN that this customer has IP space >that is not being used and that it should be reclaimed >as they didn't renumber from your space. > > >john brown > >On Wed, Jun 23, 2004 at 01:16:48AM -0400, Alex Rubenstein wrote: >> >> >> >> (also sent to nanog) >> >> >> >> Should a customer be allowed to force a carrier to allow them to announce >> non-portable IP space as they see fit to any other carriers of their >> choosing when they are no longer buying service from the original carrier >> [that the space is assigned to]? >> >> According to ARIN regulations, the space does not "belong" to us but we >> have the right to assign or revoke the space to our customers as we see >> fit. In addition ARIN regulations specifically prohibit us from transferring >> or selling the IP space to another customer (even if we want to). >> >> NAC has a customer who is leaving NAC. As part of normal procedure (and >> also because the space provided to us by ARIN is non portable), the >> customer has been informed that the IP space used by the customer will not >> be available to be used by the customer subsequent to them leaving us. >> >> It should be mentioned that the following facts exist, and cannot be >> disputed: >> >> a) customer has obtained space directly from ARIN over a year ago, but has >> chosen not to renumber from space allocated from us. This was solely their >> choice, and we did not restrict this in any way. >> >> b) customer is exercising the right not to renew the business agreement, >> and is leaving NAC voluntarily. >> >> Thus, they are attempting to file for and obtain a temporary restraining >> order (TRO), and ask for the following: >> >> >> -- start -- >> >> "NAC shall permit CUSTOMER to continue utilization through any >> carrier or carriers of CUSTOMER's choice of any IP addresses that were >> utilized by, through or on behalf of CUSTOMER under the current agreement >> during the term thereof (the "Prior CUSTOMER Addresses") and shall not >> interfere in any way with the use of the Prior CUSTOMER Addresses, > > including, but not limited to: >> >> (i) by reassignment of IP address space to any customer; >> aggregation and/or BGP announcement modifications >> >> (ii) by directly or indirectly causing the occurrence of >> superseding or conflicting BGP Global Routing Table entries; filters >> and/or access lists, and/or >> >> (iii) by directly or indirectly causing reduced prioritization of >> access to and/or from the Prior CUSTOMER Addresses. >> >> NAC shall provide CUSTOMER with a LOA within 7 days of CUSTOMERS's written >> request for sale, >> >> NAC shall permit announcement of the Prior CUSTOMER Address to ANY >> carrier, IP transit, or IP peering network." >> >> -- end -- >> >> >> In other words, customer is asking a court to rule whether or not IP space >> should be portable, when an industry-supported organization (ARIN) has >> made policy that the space is in fact not portable. It can be further >> argued that the court could impose a TRO that would potentially negatively >> affect the operation of my network. >> >> NAC does not want to be forced to rely on a customer's ability to properly >> make complex routing updates that if done improperly could disrupt >>the entire >> NAC network. We believe there is a great danger to NAC that their routing >> mistakes could take down some or all of our network infrastructure. >> >> Another VERY important issue to bring up: If customer is granted the legal >> right to continue to use IP space that is registered to NAC by ARIN, NAC >> runs into the very serious problem of being liable for all of the Spam >> that could be generated by the customer and all of the RBLs that the >> carrier may be added to [that of course will effect all of NAC's >> customers] with no ability to revoke the IP space to protect itself. This >> has to potential to effect the NAC network in a catastrophic manner. >> >> I'd love any comments from anyone. >> _______________________________________________ >> "Eat sushi frequently". - Avi >> inet(a)inet-access.net is the human contact address. >> list(a)inet-access.net is the list posting address. >> See below URL for subscribe/unsubscribe and list options: >> http://inet-access.net/mailman/listinfo/list >_______________________________________________ >"Eat sushi frequently". - Avi >inet(a)inet-access.net is the human contact address. >list(a)inet-access.net is the list posting address. >See below URL for subscribe/unsubscribe and list options: >http://inet-access.net/mailman/listinfo/list _______________________________________________ "Eat sushi frequently". - Avi inet(a)inet-access.net is the human contact address. list(a)inet-access.net is the list posting address. See below URL for subscribe/unsubscribe and list options: http://inet-access.net/mailman/listinfo/list

2 2