- Test - lists.nanog.org

ISP Unbundling circuits
by itmailinglist 29 Jan '09

29 Jan '09

Hi everyone, Is it common for an ISP to install a lased line (circuit) and when the service ends, the service is not unbundled again but all the cabling is left where it is? I have even seen that a circuit is still active on there exchanges after years and no one at the ISP seems to care that they are wasting there own resources. Thanks and best regards, Alexander

8 7

-48VDC equipment recommendations
by Deepak Jain 29 Jan '09

29 Jan '09

Who does everyone like for -48VDC power systems nowadays (say in the 60A @48VDC and 600A@48VDC sizes). Something like you'd deploy in a POP or a 10-rack MMR with A&B. Management/no-management, not a big deal. Off-list is fine, and I'll be glad to summarize for the list. Thanks in advance, Deepak

3 2

NetFlow Research
by pmeaux MEAUX 29 Jan '09

29 Jan '09

I am doing some research at the University of Colorado on NetFlow and its potential to influence BGP routing policies. Are there any examples where review of NetFlow data has caused a change in a BGP routing policy? How often are these changes made and what would be the most common reasons for using NetFlow? Thanks Paul Meaux _________________________________________________________________ Windows Live™: E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_allup_explore_012009

1 0

Re: Tightened DNS security question re: DNS amplification attacks.
by aljuhani 28 Jan '09

28 Jan '09

Well the RBLs, in using dns queries, is another form of legal DDoS attacks, mainly when the suddenly cease to respond or re-configure to black-list the entire wold. One should just imagine the bandwidth consumption during a given time-frame, RBLs consume as oppose to volume of spam messages. ----- Original Message ----- From: "Frank Bulk" <frnkblk(a)iname.com> To: "'Paul Vixie'" <vixie(a)isc.org>; <nanog(a)merit.edu> Sent: Wednesday, January 28, 2009 18:02 Subject: RE: Tightened DNS security question re: DNS amplification attacks. | Pretty soon we need an RBL for DNS-oriented DDoS attacks. =) | | -----Original Message----- | From: Paul Vixie [mailto:vixie@isc.org] | Sent: Tuesday, January 27, 2009 9:21 PM | To: nanog(a)merit.edu | Subject: Re: Tightened DNS security question re: DNS amplification attacks. | | "Douglas C. Stephens" <stephens(a)ameslab.gov> writes: | | > ... | > I choose the latter, and that is why went to the effort of blocking this | > abusive traffic before it reaches my authoritative-only DNS servers. | | this is an odd implementation choice. the 1PPS query stream is still using | your line even with this defense in place. the 1PPS response stream and the | CPU cycles it takes to generate that stream isn't a burden on you (compared | to the 1PPS query stream that you can't stop anyway). so the only reason to | block these appears to be so that you don't participate in the attack, or in | other words to cut down the burden on the victim. with me so far? | | the burden on the victim isn't going to drop materially by what you did | since | hundreds of thousands of other servers are not going to block it. but if | the | victim is a recursive nameserver, then your blocking them will mean that | they | cannot access the zones you're authoritative for. so, no positive, but some | negative, for the only person in the whole equation who can be affected by | the blocking you're doing. | | i don't get it. with a cost:benefit matrix like that one, why is anybody | blocking this traffic? (i note with some alarm that ten years after i shot | it down, i still get queries to rbl.maps.vix.com, so the possibility that | the | blocks some folks might put in place to ...manage?... this attack will have | a | long term bad effect on our heirs and assigns. i know your perl script will | expire things 60 seconds after they stop spewing, but i fear that others are | blocking these in hardcode. | | (looking for ". IN NS" as the q-tuple pattern is not a solution, since the | bad guys can pretty trivially change the question they ask into one you're | willing to answer.) | | (REFUSED is nice because it's small, but the bad guys aren't lacking for | bots | to transmit spoofed packets from, they Do Not Need amplification, and all | forms of error rate limiting are also new attack vectors.) | | (is there a name-and-shame registry for networks that do/don't implement | BCP38? if not i guess i'll start one and hope that various auditors will use | google and notice me.) | -- | Paul Vixie | | | |

3 2

DNS DDoS
by Andrew Fried 28 Jan '09

28 Jan '09

Targeted victims, beginning 28-Jan-2009, as seen from my DNS server. GeoIP data for top two sites also below: +----------------+-------------+------------+ | host | count(host) | Percentage | +----------------+-------------+------------+ | 202.104.106.49 | 51 | 0.1109 | | 210.21.218.138 | 51 | 0.1109 | | 64.57.246.123 | 3561 | 7.7421 | | 64.57.246.146 | 29530 | 64.2026 | | 67.192.144.0 | 991 | 2.1546 | | 70.86.80.98 | 11276 | 24.5157 | | 76.9.16.171 | 535 | 1.1632 | +----------------+-------------+------------+ GeoIP Location Information for IP: 64.57.246.146 Located in: Suwanee, GA (US) Latitude: 34.0535 Longitude: -84.0659 Area Code: 770 Postal Code: 30024 ARIN information for: 64.57.246.146 DNS PTR Record: Registrar: arin ASN Number: AS20141 Country: US Ip Starting Block: 64.57.240.0 IP Ending Block: 64.57.255.255 IP Block Size: 4096 Date Registered: 20051012 Block Status: allocated BGP Peering Information for ASN20141: PEER_AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name 6983 | 64.57.246.146 | 64.57.240.0/20 | US | arin | 2005-10-12 | ITCDELTA - ITC^Deltacom 14745 | 64.57.246.146 | 64.57.240.0/20 | US | arin | 2005-10-12 | INTERNAP-BLOCK-4 - Internap Network Services Corporation GeoIP Location Information for IP: 70.86.80.98 Located in: Houston, TX (US) Latitude: 29.7523 Longitude: -95.3670 Area Code: 713 Postal Code: 77002 ARIN information for: 70.86.80.98 DNS PTR Record: 62.50.5646.static.theplanet.com. Registrar: arin ASN Number: AS21844 Country: US Ip Starting Block: 70.84.0.0 IP Ending Block: 70.87.255.255 IP Block Size: 262144 Date Registered: 20040729 Block Status: allocated BGP Peering Information for ASN21844: PEER_AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name 2914 | 70.86.80.98 | 70.84.0.0/14 | US | arin | 2004-07-29 | NTT-COMMUNICATIONS-2914 - NTT America, Inc. 3356 | 70.86.80.98 | 70.84.0.0/14 | US | arin | 2004-07-29 | LEVEL3 Level 3 Communications 3549 | 70.86.80.98 | 70.84.0.0/14 | US | arin | 2004-07-29 | GBLX Global Crossing Ltd. 4565 | 70.86.80.98 | 70.84.0.0/14 | US | arin | 2004-07-29 | MEGAPATH2-US - MegaPath Networks Inc. 6461 | 70.86.80.98 | 70.84.0.0/14 | US | arin | 2004-07-29 | MFNX MFN - Metromedia Fiber Network -- Andrew Fried andrew.fried(a)gmail.com

2 1

google logo
by Antonio Querubin 28 Jan '09

28 Jan '09

Anyone else noticing Google's logo has been scrambled? Antonio Querubin whois: AQ7-ARIN

14 14

RE: Tightened DNS security question re: DNS amplification attacks. [SEC=UNCLASSIFIED]
by David Zielezna 28 Jan '09

28 Jan '09

I'm checking just with a mix of tcpdump/pcap, bind logs and p0f. A bit overboard, but logging is fun. I haven't checked any dark hosts to see whether the attack repeatedly sends queries to IPs which have never given an answer or indication of any kind of life. Your monitoring will probably determine this so let us know what behavior you find. DZ -----Original Message----- From: Steve Bertrand [mailto:steve@ibctech.ca] Sent: Wednesday, 28 January 2009 2:47 PM To: David Zielezna Cc: John Martinez; nanog(a)nanog.org Subject: Re: Tightened DNS security question re: DNS amplification attacks. [SEC=UNCLASSIFIED] Good work! How are you checking for this by hand? Would it be safe to assume that running tcpdump on a box in the following manner on a monitor port for a sizable portion of the network be ok (as opposed to the DNS servers themselves, as I don't have control over them all)? sniffer# tcpdump -n -i em5 dst port 53 | grep "NS? . (17)" 22:38:31.150114 IP 64.57.246.146.43581 > 208.70.106.58.53: 23685+ NS? . (17) We have a mix of DNS servers, some BIND and some DJBDNS, a BIND ACL won't work here. We also have single-homed clients that run accessible DNS servers that appear to be Windows based. ACL's outside of the BIND scope would be fantastic. For now, I'm following the above list, and blocking everything ingress that is not source port 53 from the IP to my network 53. Steve If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents. Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA.

1 0

Contact at Eschelon/Integra to remove old swip
by Seth Mattinen 28 Jan '09

28 Jan '09

I've been trying unsuccessfully for years to get Eschelon/Integra to remove the swip for an old IP block. Last time I called some months ago I finally talked to someone who said they'd take care of it, but I looked today and it still says it's mine. The range in question is 66.224.163.0/24 and the T1 it was used with was disconnected years ago. If anyone can remove the swip or put me in touch with someone who can I'd appreciate it. ~Seth

2 2

APNIC offline
by manolo 27 Jan '09

27 Jan '09

All, Is anyone else seeing www.apnic.net offline? I have tried from two locations and the website does not respond. whois is working as expected though. Manolo

7 6

AfNOG 2009 - Call for Presentations
by Randy Bush 27 Jan '09

27 Jan '09

---------------------- Call for Presentations ---------------------- The African Network Operators' Group (AfNOG) invites applications from people who wish to teach a tutorial, make a presentation, or chair a panel discussion at the 10th AfNOG meeting in Cairo, Egypt, in May 2009. We also invite programme suggestions from other people. Background ---------- AfNOG and AfriNIC are jointly organising a two-week event that includes the AfNOG Workshop on Network Technology (offering advanced training in a week-long hands-on workshop), several full-day Tutorials, a one-day AfNOG meeting, and a two-day AfriNIC meeting. Further information about the event may be found at <http://www.afnog.org/afnog2009/> and <http://www.afrinic.net/meeting/>. Venue ----- Venue for the event will be announced shortly About AfNOG ----------- AfNOG (see <http://www.afnog.org/>) is a forum for cooperation and the exchange of technical information between operators of Internet-connected networks in Africa. AfNOG has organised an event like this one every year since 2000. About the Tutorials & Conference ------------------- The AfNOG Conference takes the form of a series of short presentations followed by open discussions, during which network operators from around the continent share experiences, discuss problems and their solutions as well as interact on various issues affecting African networking. The conference has in the past attracted over 200 participants, mainly consisting of engineering staff from national service providers, managers from IT Enterprises and members of the research and education community. Several tutorials will be offered before the AfNOG conference from 17 - 18 May 2009. Tutorials are technical workshops which focus on a particular subject in-depth and should be non-commercial in nature. Tutorials take place in a classroom-style environment, and may include a hands-on practical component. They are intended to offer advanced training relating to technology already deployed or soon to be deployed on networking and related services provisioning for ISP operations. Potential Areas of Interest --------------------------- Conference: * Routing Operations: Rural Connectivity Solution, IPv4 and IPv6 Routing, MPLS, Backbone operations, Traffic Engineering * Services Operations: DNS, Email, VOIP, Content Development, Open Source Tools and Analysis * Security Operations: NSP-Sec, DDoS, Security Operations, Anti-SPAM, Anti-Malware. * Internet Provider Relationships: IXP Operations, Peering * Technologies: Wireless, WiMax, DSL, Broadband access aggregation * Internet Governance Tutorials: * Network Monitoring and Management * Wireless Networking * Advanced Routing * DNSSEC * IPV6 * VOIP How to Submit ------------- People interested in making a presentation, or chairing a panel discussion at the AfNOG meeting are invited to submit a proposal not later than 28 February 2008 We ask that the following information be sent in an email message to <afnog-presentations09(a)afnog.org>. * speaker/presenter name and affiliation * email address and phone number * nature of the proposal (conference presentation, panel discussion, or tutorial) * proposed title * requested time allocation (for conference presentations or panel discussions: 30 minutes to 2 hours). * an abstract of no more than 200 words * permission to reproduce your presentation after the event, including permission to post it on the AfNOG website. The Programme Committee also welcomes suggestions and expressions of interest, even if you don't have all the above information. Funding and Support AfNOG is a not-for-profit event and because limited funds are available, conference presenters and tutorial instructors are expected to cover their travel expenses. However, tutorial instructor or conference presenters are exempted from paying registration fees. Deadlines ---------- Submission deadline: 28 Feb 2009 Notification by: 15 March 2009 Final Program Published: 31 March 2009 Send Requests to: afnog-presentations09(a)afnog.org

1 0