March 2005 - Test - lists.nanog.org

Re: Vonage Hits ISP Resistance
by Greg Boehnlein 30 Mar '05

30 Mar '05

On Thu, 31 Mar 2005, Brad Knowles wrote: > At 5:06 PM -0800 2005-03-30, Bill Nash wrote: > > > I find this to be entertaining, since as a VOIP consumer, I'm > > reimbursing my ISP for the cost of the traffic as part of my monthly > > tithe. > > No, that's not true. Not if your ISP has oversold their upstream > bandwidth, and a lot of people start using VOIP. > > In that case, your ISP is dependant on keeping you fat, dumb, > happy, barefoot, and pregnant in the kitchen, taking whatever > semidigested pabulum they choose to feed you, and if you start > getting uppity by actually thinking for yourself and using something > like VOIP, then they're going to have to bitch-slap you back into > your rightful place under their thumb. That is fairly entertaining. Perhaps you could provide the financial breakdown for ANY DSL business model that doesn't rely on over-subscription? Q. How many, full-on 6 Meg DSL subscribers can you put on a 45 meg ATM connection without oversubscription? ;) -- Vice President of N2Net, a New Age Consulting Service, Inc. Company http://www.n2net.net Where everything clicks into place! KP-216-121-ST

2 3

Sympatico / Nexxia (as577) smtp issues ?
by Mike Tancsa 30 Mar '05

30 Mar '05

Anyone know whats up with Sympatico / Bell's mail servers ? My customers are asking me why their mail is not getting there nor mail from sympatico is not getting to us. Most mail does not seem to be going through although network connectivity seems fine. I tried from 2 other networks and the issue seems to be the same. > host -tmx sympatico.ca sympatico.ca mail is handled by 5 toip6.bellnexxia.net. sympatico.ca mail is handled by 5 toip7.bellnexxia.net. sympatico.ca mail is handled by 5 toip8.bellnexxia.net. sympatico.ca mail is handled by 5 toip1.bellnexxia.net. sympatico.ca mail is handled by 5 toip2.bellnexxia.net. sympatico.ca mail is handled by 5 toip3.bellnexxia.net. sympatico.ca mail is handled by 5 toip4.bellnexxia.net. sympatico.ca mail is handled by 5 toip5.bellnexxia.net. > > telnet toip6.bellnexxia.net smtp Trying 209.226.175.174... telnet: Unable to connect to remote host: Connection refused > telnet toip1.bellnexxia.net smtp Trying 209.226.175.84... telnet: Unable to connect to remote host: Connection refused > telnet toip2.bellnexxia.net smtp Trying 209.226.175.85... telnet: Unable to connect to remote host: Connection refused > telnet toip3.bellnexxia.net smtp Trying 209.226.175.86... telnet: Unable to connect to remote host: Connection refused > telnet toip4.bellnexxia.net smtp Trying 209.226.175.87... Connected to toip4.bellnexxia.net. Escape character is '^]'. 421 #4.4.5 Too many connections to this host. Connection closed by foreign host. > telnet toip5.bellnexxia.net smtp Trying 209.226.175.88... telnet: Unable to connect to remote host: Connection timed out > telnet toip6.bellnexxia.net smtp Trying 209.226.175.174... telnet: Unable to connect to remote host: Connection refused > telnet toip7.bellnexxia.net smtp Trying 209.226.175.175... telnet: Unable to connect to remote host: Connection refused > -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike(a)sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike

4 3

IANA IPv4 allocations and bogon update: 73/8
by Rob Thomas 30 Mar '05

30 Mar '05

-----BEGIN PGP SIGNED MESSAGE----- [ Apologies to those of you who receive this note in multiple forums. ] Hi, team. The numerous Team Cymru bogon projects have been updated as of 30 MAR 2005 to reflect the following IANA allocation made on 30 MAR 2005: 073/8 Mar 05 ARIN (whois.arin.net) IANA allocations change over time, so please check regularly to ensure you have the latest filters if you are not using the bogon BGP feed(s). We do announce updates to the bogon projects to sundry lists, such as the bogon-announce list. We can not stress this point strongly enough - these allocations change. If you do not adjust your filters, you will be unable to access perhaps large portions of the Internet. Worse yet, you may end up blocking access for people who transit through you. Please do not apply any filters or blocks to your network without carefully considering the ramifications of doing so. As a point of reference, the Team Cymru master Bogon Reference Page can be found here: <http://www.cymru.com/Bogons/> A quick summary of the documents and projects that have been updated include the following: HTTP The Bogon List - <http://www.cymru.com/Documents/bogon-list.html> The Text Bogon Lists - <http://www.cymru.com/Documents/bogon-bn-nonagg.txt> - <http://www.cymru.com/Documents/bogon-bn-agg.txt> Secure BIND Template - <http://www.cymru.com/Documents/secure-bind-template.html> Secure IOS Template (Cisco) - <http://www.cymru.com/Documents/secure-ios-template.html> Secure BGP Template (Cisco) - <http://www.cymru.com/Documents/secure-bgp-template.html> Secure JUNOS Template (Juniper) - <http://www.cymru.com/gillsr/documents/junos-template.htm> Secure JUNOS BGP Template (Juniper) - <http://www.cymru.com/gillsr/documents/junos-bgp-template.htm> Ingress Prefix Filter Templates, Loose and Strict (Cisco) - <ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter-Templates/> Ingress Prefix Filter Template, Loose (Juniper) - <http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter-loose.htm> Ingress Prefix Filter Template, Strict (Juniper) - <http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter-strict.htm> BGP Bogon route-server for AUTOMATED updates of bogon filters - All bogon route-server peers have already received the appropriate BGP prefix updates. - <http://www.cymru.com/BGP/bogon-rs.html> RADb fltr-unallocated fltr-martian fltr-bogons - <http://www.cymru.com/Bogons/index.html#radb> RIPE NCC fltr-unallocated fltr-martian fltr-bogons - <http://www.cymru.com/Bogons/index.html#ripe> DNS Bogon (bogons.cymru.com) zone - <http://www.cymru.com/Bogons/index.html#dns> Monitoring Bogon prefix monitoring - <http://www.cymru.com/BGP/robbgp-bogon.html> Bogus ASN monitoring - <http://www.cymru.com/BGP/asnbogusrep.html> Please feel free to contact Team Cymru <team-cymru(a)cymru.com> with any comments, questions, or concerns. Thank you for your continued support. Rob, for Team Cymru. - -- Rob Thomas http://www.cymru.com Shaving with Occam's razor since 1999. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQCVAwUBQks9clkX3QAo5sgJAQFCHgP/V6mR3gVMiNQ5bvkfSgsT5nkIw0bn2BJA nE4qKGQrB22WL6t83PMsMONjW7GvHJA7Ds4DVgVggTUBJ/SqupM1xQ3SBwEokHcW oydTMiUrsS1dmZMdoLoSHNdGC6hLciTgYayIO/EBI9IGoQYdR/swzgjzHXkLWghO 0C67MWkIT7M= =+ixP -----END PGP SIGNATURE-----

1 0

RE: outage/maintenance window opinion
by Howard, W. Lee 30 Mar '05

30 Mar '05

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of Luke Parrish > Sent: Wednesday, March 30, 2005 11:29 AM > To: Pete Templin > Cc: nanog(a)nanog.org > Subject: Re: outage/maintenance window opinion > > > > In this situation we were expecting to be done for the > majority of the > maintenance window, but yes I see your point. However I block > out a 3 hour > window for maintenance because the activities I am performing on the > network could easily cause a longer service outage than > planned as we all > know. So if I plan for a 4 hour window but only expect 20 minutes of > downtime that actually turns into 3 hours, as long as it is > inside the > maintenance window specified then it should not go against > outage minutes. > It was done in the window for a reason... > > ?? > Luke I'd agree that as long as it's back up before the end of the window, you're covered. However, if the outage extends beyond the end of the window, I would take the the position that made me look worst. That shows how seriously you take your maintenance window, and I think this kind of integrity gives you credibility later. Lee > > > At 02:05 PM 3/28/2005, Pete Templin wrote: > >Luke Parrish wrote: > >>Trying to get clarification on an issue. > >>Maintenance/outage window is 2:00AM to 5:00AM, during the window the > >>router we are working on fails and does not come back > online until 8:00AM. > >> From a outage reporting/documentation standpoint is the > outage start > >> time 2:00AM or 5:01AM since 5:01AM is when the maintenance > window and > >> planned outage was over... > > > >To a small degree, it depends on how long you anticipated > the outage to > >be. Were you expecting a three-hour tour^h^h^h^houtage, or > something > >shorter but opened a big window to give you flexibility on > when to do > >it? I would say that a fifteen-minute expected impact means > the outage > >started at 2:15AM (or fifteen minutes after your work > interrupted services). > > > >My $0.005, > > > >pt > > Luke Parrish > Centurytel Internet Operations > 318-330-6661 >

1 0

[bill.st.arnaud@canarie.ca: [CAnet - news] A new vision for the future of the Internet]
by k claffy 30 Mar '05

30 Mar '05

----- Forwarded message from "Bill St.Arnaud" <bill.st.arnaud(a)canarie.ca> ----- Date: Wed, 30 Mar 2005 15:27:53 -0500 From: "Bill St.Arnaud" <bill.st.arnaud(a)canarie.ca> Subject: [CAnet - news] A new vision for the future of the Internet To: <news(a)canarie.ca> X-Mailer: Microsoft Outlook, Build 10.0.6626 Making the world (of communications) a different place Report of a working session of the End-to-End Research Group For more information on this item please visit the CANARIE CA*net 4 Optical Internet program web site at http://www.canarie.ca/canet4/library/list.html ------------------------------------------- http://www.ir.bbn.com/~craig/e2e-vision.pdf January, 2005 Version 4 3/24/05 This version for preliminary release David D. Clark, Craig Partridge, Robert T. Braden (chair), Bruce Davie Sally Floyd, Van Jacobson, Dina Katabi, Greg Minshall, K.K. Ramakrishnan, Timothy Roscoe, Ion Stoica, John Wroclawski and Lixia Zhang This report is the product of a discussion held at the January 2005 meeting of the End-to-End Research Group, which is part of the Internet Research Task Force. The challenge presented to the group for this discussion was the following: How might the computing and communications world be materially different in 10 to 15 years, and how might we define a research agenda that would get us to that world? There were a number of motivations for this discussion. The Internet itself arose because of a visionary answer to a question such as this one. Through an alignment of visionary leaders, the research community, and funding agencies, there was a coherent, long-term effort to build a running prototype of a major new communications system. That effort led to a number of new research results; results that substantially expanded and changed our understanding of the communications field. The networking field does not have a shared vision of the future today. Perhaps as a result, much of the research we see today lacks a motivation to deepen or broaden our understanding of communications. Much of today's research is felt to be incremental (in the sense of "least publishable increment") and lacking a long-term motivation. At the same time, the United States' National Science Foundation is interested in hearing about important focus areas that they might fund. While focus areas are some steps short of a shared vision, we thought that a discussion of visions of the future would help refine what the focus areas might be, and could even be a vehicle to bring the research community to a common objective. In this context, the participants at the meeting speculated about possible visions of the future, and whether the time was right for a focused research push to move us toward that future. The next several sections talk about some of the visions. The report concludes with some thoughts about directions we might take. [....] ------------------------------------- To SUBSCRIBE: send a blank e-mail message to news-join(a)canarie.ca To UNSUBSCRIBE: send a blank email message to news-leave(a)canarie.ca ------------------------------------- These news items and comments are mine alone and do not necessarily reflect those of the CANARIE board or management. ----------- Bill.St.Arnaud(a)canarie.ca _______________________________________________ news mailing list news(a)canarie.ca http://lists.canarie.ca/mailman/listinfo/news ----- End forwarded message -----

1 0

Re: Intradomain DNS Anycast revisited
by Joe Shen 30 Mar '05

30 Mar '05

thanks. > No, because both routers are reached through the > same L1/L2 medium, so > Quagga can't use link-state to determine > reachability of the next-hop. > You could fix that by getting rid of the switches, > and just having a bunch > of router interfaces facing two Ethernet interfaces > on each server, which > would remove some points of failure, and would be a > good idea if you can > spare the router interfaces... Do you mean Quagga's OSPF route has higher priority than static route? or even there is static default route configured, once Quagga detects link to default router is down it will replace 0.0.0.0/0.0.0.0 in host routing table? > > 2) If each server is configured two default > router ( > > router-1 & > > router-2), or each server learn route > 0.0.0.0/0.0.0.0 > > by OSPF ( our border router inject default > route into > > OSPF ); there should be > > two equal cost path to 0.0.0.0/0.0.0.0 on each > DNS > > server, the DNS server should disperse any > outgoing > > packets onto the two paths, will > > that do harm to DNS service ? > > Nope, no problem, particularly so long as the two > routers are iBGP peers, > so they'll both (for the most part) have the same > idea of what selected > paths are. > I don't understand why should both routers be iBGP peers. In fact, iBGP does not run on that two routers; the two routers are only members of OSPF backbone area who only run OSPF; only border router ( at the edge of our network) runs BGP and enject default route into OSPF backbone area. Although all DNS servers are cache server, we have to open 53/TCP to allow resolver using TCP protocol. For example, server-(1,3)--switch--router-1--\ | (OSPF only) router3--host server-(2,4)--switch--router-2--/ if that possible that router3 or router-1 dispers packets of the same TCP connection to different path? Is there possibility that a DNS requests are divided into multiple UDP packets? > > 3) Is there any requirement on BIND to fit to > such > > multipath routing situation? > > Nope. BIND doesn't know what's going on that far > below it. > Do I only need to configure BIND to origin request from administration IP address ( configured on NIC and different from DNS service address)? regards Joe __________________________________________________ Do You Yahoo!? Log on to Messenger with your mobile phone! http://sg.messenger.yahoo.com

2 1

Is everyone ready for April 12?
by Hank Nussbacher 30 Mar '05

30 Mar '05

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2aumng.mspx Should be a very interesting period of April 12-15 :-) -Hank

1 0

drone armies C&C report - March/2005
by Gadi Evron 30 Mar '05

30 Mar '05

Below is a periodic public report from the drone armies / botnets research and mitigation mailing list. For this report it should be noted that we base our analysis on the data we have accumulated from various sources. According to our incomplete analysis of information we have thus far, we now publish two reports. The ISP's that are most often plagued with botnet C&C's (command & control) are, by the order listed: ---------------------------------- Top 13 with open non-resolved suspect C&Cs ASN Responsible Party Unique IPs Open-unresolved 21840 SAGONET-TPA - Sago Networks 31-40 11-15 25761 STAMINUS-COMM - Staminus Commu 16-20 11-15 27595 ATRIVO-AS - Atrivo 6-10 6-10 27654 ASN-NA-MSG-01 - Managed Soluti 6-10 3-5 17676 JPNIC-JP-ASN-BLOCK Japan Netwo 6-10 3-5 16625 LEASEWEB LEASEWEB AS 3-5 3-5 4713 OCN NTT Communications Corpora 6-10 3-5 8551 BEZEQ-INTERNATIONAL-AS Bezeqin 3-5 3-5 13749 EVERYONES-INTERNET - Everyones 3-5 3-5 4766 KIXS-AS-KR Korea Telecom 6-10 3-5 21788 NOC - Network Operations Cente 6-10 3-5 13301 UNITEDCOLO-AS Autonomous Syste 3-5 3-5 6517 YIPESCOM - Yipes Communication 6-10 3-5 Top 10 frequently listed without regard to state ASN Responsible Party Unique IPs 21840 SAGONET-TPA - Sago Networks 31-40 25761 STAMINUS-COMM - Staminus Commu 16-20 {10913,13790,19024,14744} INTERNAP Internap 11-15 {13884,21844} THEPLANET-AS - THE PLANET 11-15 27654 ASN-NA-MSG-01 - Managed Soluti 6-10 4766 KIXS-AS-KR Korea Telecom 6-10 4713 OCN NTT Communications Corpora 6-10 17676 JPNIC-JP-ASN-BLOCK Japan Netwo 6-10 3356 LEVEL3 Level 3 Communications 6-10 Unresolved open IPs for top 10. ASN Responsible Party Open-unresolved. 21840 SAGONET-TPA - Sago Networks 11-15 25761 STAMINUS-COMM - Staminus Commu 6-10 {10913,13790,19024,14744} INTERNAP Internap 1-3 {13884,21844} THEPLANET-AS - THE PLANET 1-3 27654 ASN-NA-MSG-01 - Managed Soluti 3-5 4766 KIXS-AS-KR Korea Telecom 3-5 4713 OCN NTT Communications Corpora 3-5 17676 JPNIC-JP-ASN-BLOCK Japan Netwo 3-5 3356 LEVEL3 Level 3 Communications 1-3 * We would gladly like to establish a trusted relationship with these and any organizations to help them in the future. * We would especially like to note the serious and prompt response by PNAP, as well as the serious efforts made by The Planet. * By previous requests here is an explanation of what "ASN" is, by Joe St Sauver: http://darkwing.uoregon.edu/~joe/one-pager-asn.pdf * Clarification: the definition of "count" is how many C&C servers are located at said AS. We replaced it to be called "Unique IPs" and "Open-unresolved" accordingly. The Trojan horses most used in botnets: --------------------------------------- 1. Korgobot. 2. SpyBot. 3. Optix Pro. 4. rBot. 5. Other SpyBot variants and strains (AgoBot, PhatBot, actual SDbots, etc.). * There seems to be an increase in Energymechs used for botnets running on *nix machines. -- Gadi Evron, Information Security Manager, Project Tehila - Israeli Government Internet Security. Ministry of Finance, Israel. gadi(a)tehila.gov.il gadi(a)CERT.gov.il Office: +972-2-5317890 Fax: +972-2-5317801 http://www.tehila.gov.il The opinions, views, facts or anything else expressed in this email message are not necessarily those of the Israeli Government.

1 0

outage/maintenance window opinion
by Luke Parrish 30 Mar '05

30 Mar '05

Trying to get clarification on an issue. Maintenance/outage window is 2:00AM to 5:00AM, during the window the router we are working on fails and does not come back online until 8:00AM. From a outage reporting/documentation standpoint is the outage start time 2:00AM or 5:01AM since 5:01AM is when the maintenance window and planned outage was over... My take is that the outage starts when the planned maintenance/outage window is over at 5:01AM. Luke Luke Parrish Centurytel Internet Operations 318-330-6661

7 8

Re: DNS cache poisoning attacks -- are they real?
by Joe Maimon 30 Mar '05

30 Mar '05

Brad, I suspect and google confirms, that you know a whole lot more about this than I do, so please have a little patience explaining this to me. Brad Knowles wrote: > At 8:49 AM -0500 2005-03-29, Joe Maimon wrote: > >> 1) Registrars being required to verify Authority in delegated to >> nameservers (will this break any appreciated valid models?) before >> activating/changing delegation for zone.<REAL FIX> > > > Okay, so the spammers make the data appear valid just long enough to > pass the test, then they go back to their wily ways. Not a real fix. > Why would this not work against the procedure as originaly described? Step 1) Spammers register Domain and delegate it to nameserver that respond with AA set for domain. Step 2) Registrar activated delegation due to Authority response from nameservers Step 3) Spammers seed recursive resolvers Step 4) Spammers change delegation by registrar to seeded resolvers Step 5) Change fails because Registrar check Authority from seeded resolvers and does not get it. How do spammers make step 5 succeed? >> 2) Stricter settings as regards to all lame delegations -- SERVFAIL by >> default without recursion/caching attempts? > > > You'd have the caching server check the name of the zone to see if > it is claimed as an NS record, even when it's just caching/recursive? > Now, tell me how they'd do this at all the sites on the Internet, since > we assume that the data advertised may change at any moment? What I meant is that when a server attempts to seed its cache and it encounters lameness it should not attempt to obtain it from any other servers. Perhaps it should return the answer but not cache it (or cache with forced small TTL). Now lameness is something that the server SHOULD see when it attempts to recursively resolve the name without extra effort. > > In terms of running a caching/recursive server, I don't think > there's any way to reliably detect that someone has aimed an NS record > at you. That would be like asking how you know, a prior, whether or not > www.youareadamnedbloodyfool.com is a now CNAME record for your webserver. I am suggesting that the server can semi-reliably detect that the parent soa hasnt aimed the ns record for the subzone at it. It would verify its cache contents every X before sending on the answers it has. It should purge from cache anytime the check reveals that the parent zone has an NS aimed at it for the cache contents -- which should be a clear indication of cache hijacking. Or perhaps servers should check periodicaly for all kinds of lameness of the cached contents. This would prevent practical usage of a technique where spammers spray-seed all resolvers they can with large TTL's so that the resolvers users see them for quite some time irregardless of registrars/parent zone's actions. > >> 3) Paranoid checking for situations such as these by having recursing >> nameservers attempt to periodically check for suspicous NS and glue from >> the parent zone's POV and compare it to cache, trashing cached records >> if they do not like result. > > > How do they know who their claimed "parent" is, when someone aims a > totally bogus NS record at them? Do you ask them to walk the entire DNS > tree throughout the entire Internet? > And thats so hard? Servers do this all the time fairly often. > > An open recursive/caching nameserver is like an open mail relay. > There may be some people who stubbornly insist that they are a necessary > evil -- feel free to become the next toad.com if you like. There may be > a lot of people who have one but don't know it. > > But they are evil, and I believe that they should be eliminated. > So far nobody here has said that they are either neccessary or evil -- 'cept for you and chris on the evil part. As to that, I cant credit the resulting evilness you paint as evil as open mail servers became, not because open mail-relay servers were intrinsically so but because they become so very attractive to all the evil users out there. For a real life example of an open-relay mail server, walk to your nearest corner and see the maildrop that takes mail from anybody and delivers it to anyone else. A commandeered open-relay server is spewing garbage to its victims. A commandeered open-recursion server, while not a good thing, is hardly doing the same - in most cases described here its simply perpetuating a domain name far longer than POLICY reasons would like. This was probably a designed for feature, for example keeping panix.com going strong for the lucky one due to cached large NS TTLS would have been viewed as a good thing at the time. Furthermore, as others have pointed out, eliminating the openness of these resolvers would simply force a push to have spammers trojan armies seek 'n' seed the resolvers they can recurse from. Due to the nature of this game, the larger client base the resolver serves, the better the chances of it getting seeded. These would be the same resolvers targetted were they open. And as others have pointed out, once an answer is in cache, its not considered recursion and different access control needs to be applied.

2 2