- Test - lists.nanog.org

Re: Vonage Hits ISP Resistance
by Fergie (Paul Ferguson) 31 Mar '05

31 Mar '05

Who said it was QoS? - ferg -- Bill Nash <billn(a)billn.net> wrote: Why exactly are networks taking this stance to QoS VOIP traffic, generated by their customers, into uselessness? -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

2 1

Vonage may route 911 call to Congress, FCC
by Fergie (Paul Ferguson) 31 Mar '05

31 Mar '05

C|Net: "Net phone provider Vonage may ask Congress and the Federal Communications Commission to help it solve problems with SBC over subscriber access to the 911 emergency call network." http://news.com.com/Vonage+may+route+911+call+to+Congress%2C+FCC/2100-7352_… - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

1 0

cincinnati-oh.gov / rcc.org contact please?
by Suresh Ramasubramanian 31 Mar '05

31 Mar '05

As above. Can an operator from the Regional Computing Center / Cincinnati Ohio contact me offlist, please? -- Suresh Ramasubramanian (ops.lists(a)gmail.com)

1 0

Contact from ACM?
by Mark Newton 31 Mar '05

31 Mar '05

I need to talk to someone who can update the bogon filters on www.acm.org. Attempts to reach technical contacts via the website have failed, which is a bit surprising given the nature of the org. If anyone reading this is an ACM member who can pass this message along to someone who cares I'd appreciate it. Thanks, - mark -- Mark Newton Email: newton(a)internode.com.au (W) Network Engineer Email: newton(a)atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223

2 1

AOL's brains on the floor?
by Michael Loftis 31 Mar '05

31 Mar '05

Anyone else confirm? Looks like AIM, www.aol.com...maybe more, are all down form various POPs here.

1 1

DNS cache poisoning attacks -- are they real?
by Florian Weimer 31 Mar '05

31 Mar '05

ISC SANS has recently disclosed yet another suspected DNS cache poisoning attack. I reach a different conclusion. based on publicly available data. Maybe there is unpublished information which suggests a different view. Unofficial name servers which pose as authoritative for well-known zones have been around for ages. An astonishingly large number is officially authoritative for (at least somewhat) frequented zones, and from time to time, your resolvers receive authority sections containing leaked unofficial data. I noticed this unfortunate fact back in July 2004, when I looked more closely at DNS packet captures for debugging purposes. Even in my limited sample, the number leaking name servers was so high that systematically contacting their operators and convincing them to change their configurations seemed unfeasible (and many of them were located in regions which are not exactly known for their cooperative spirit when it comes to such matters). Today, I looked again at a few unofficial servers. Quite a few of them are operated by apparently respectable organizations with an AS number etc. (definitely not the backyard servers behind a cable modem I would expect in an attack). It is hard to tell if the more shady ones legitimately redirect customer traffic, and unintentionally leak these records to the general Internet, or attempt an actual attack. (I'm not sure how to tell them apart at the protocol level. Maybe I'm missing something.) Many of the unofficial records have been unchanged for quite some (i.e. predating the current "pharming" craze). Even the DNS cache poisoning case described in the ISC diary could be the unwanted consequence of an oversimplified DNS configuration (wildcard RRs for *.com instead of a proper DNS zone). Are any ISPs actually willing to disconnect customer name servers which serve unofficial zones? I don't believe that many ISPs would try to exercise this much control over the packets their customers send. Furthermore, there are apparently some reasons for running such servers which generally are considered legitimate. Should we monitor for evidence of hijacks (unofficial NS and SOA records are good indicators)? Should we actively scan for authoritative name servers which return unofficial data? I don't think this makes sense, even if we could strongly discourage the practice. Right now, I suspect that many people rediscovered the relative weakness of the domain name system and started looking for anomalies, and that's why we see an increasing number of reports -- not because of an increasing number of actual attacks.

18 37

APRICOT 2006 withdrawn from Bangalore, India - moves to Perth
by Suresh Ramasubramanian 31 Mar '05

31 Mar '05

-------- Original Message -------- Subject: [APRICOT-INFO] APRICOT 2006 News! Date: Thu, 31 Mar 2005 13:59:07 +1000 From: Philip Smith <pfs(a)cisco.com> (apologies for duplicates) Dear Colleagues, Due to unforeseen circumstances the APIA Board has reluctantly agreed to set aside the award of APRICOT to Bangalore, India for 2006. APRICOT 2006 now will be held in Perth, Australia from Wednesday 22nd February to Friday 3rd March 2006. The host organisation for APRICOT 2006 will be the Western Australian Internet Association (WAIA), the runner up bid for APRICOT 2006. The venue will be the Perth Convention and Exhibition Centre. More information will be on the website for APRICOT 2006, www.2006.apricot.net, which will be available shortly. best wishes! Philip Smith Secretary, APIA Board _______________________________________________ Apricot-info mailing list Apricot-info(a)apricot.net http://mailman.apnic.net/mailman/listinfo/apricot-info

1 0

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

31 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 31 Mar '05

31 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 31 Mar '05

31 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