January 2010 - NANOG - lists.nanog.org

DIMACS/CCICADA secure routing workshop rescheduled
by Steven Bellovin 22 Jan '10

22 Jan '10

OK, folks -- we've corrected the scheduling conflict. The secure routing working is now March 10-12. Please come! ------------ ********************************************************************* DIMACS/CCICADA Workshop on Secure Routing March 10-12, 2010 DIMACS Center, CoRE Building, Rutgers University Organizers: Steve Bellovin, Columbia University, smb at cs.columbia.edu Nick Feamster, Georgia Institute of Technology, feamster at cc.gatech.edu Aaron D. Jaggard, Rutgers University, adj at dimacs.rutgers.edu Vijay Ramachandran, Colgate University, vramachandran at colgate.edu Presented under the auspices of the DIMACS Special Focus on Algorithmic Foundations of the Internet and the Command, Control, and Interoperability Center for Advanced Data Analysis (CCICADA). ************************************************ This workshop will bring together experts in networking, algorithms, mechanism design, and other areas to discuss recent progress and future directions in securing network routing, including robustness in the face of misconfiguration or rational behavior and defense against active attacks. ******************************************************************** Participation: We are soliciting short abstract submissions to be considered for a presentation at the workshop. Abstracts should be on recent progress and future directions in secure network routing; this includes (but is not limited to) theory, analysis, design, and experimental work related to robustness in the face of misconfiguration or rational behavior, defense against active attacks, and other problems relevant to secure routing. Because there will be no published proceedings we welcome submissions covering material that was previously presented elsewhere (and referenced as such). Instructions for authors: Submissions should include talk title, speaker name, affiliation, contact information, and a short abstract. Please mail abstracts to Aaron Jaggard (adj at dimacs.rutgers.edu) by Friday, January 22, 2010. ******************************************************************** Registration: (Pre-registration deadline: February 15, 2010) Please see website for complete registration details. ********************************************************************* Information on participation, registration, accomodations, and travel can be found at: http://dimacs.rutgers.edu/Workshops/SecureRouting/ **PLEASE BE SURE TO PRE-REGISTER EARLY** ********************************************************************

2 1

policies for 24.0.0.0/8 ?
by Jim Mercer 22 Jan '10

22 Jan '10

i'm doing some consulting work for a cable operator in Pakistan. while i'm guessing that realistically we will be approaching RIPE for address space, i'm just wandering what happened to 24.0.0.0/8 and what policies govern who and what can use the address space there. -- Jim Mercer jim(a)reptiles.org +92 336 520-4504 "I'm Prime Minister of Canada, I live here and I'm going to take a leak." - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, "Who are you and where are you going?"

2 2

AS3549
by Hans Goes 22 Jan '10

22 Jan '10

Just wondering if other people on this list experience similar problems with BGP sessions behind AS3549 ? It seems our trouble ticket is currently being taken care of and the GlobalCrossing NOC is investigating. If other people experience the same thing please let me know. PS: we are located in Amsterdam, Netherlands Hans Goes Senior Network Engineer IS Interned Services - PROUD AND CLEAR. www.is.nl +31 299 476 185 Gorslaan 18 1441 RG Purmerend The Netherlands cr1.ams2#sho ip bgp flap-stat inc 208.50.59.105 *> 4.23.88.0/24 208.50.59.105 1 00:17:43 3549 7018 46164 *> 4.23.89.0/24 208.50.59.105 1 00:17:43 3549 7018 46164 *> 4.23.92.0/23 208.50.59.105 1 00:17:43 3549 7018 46164 *> 4.23.94.0/23 208.50.59.105 1 00:17:43 3549 7018 46164 *> 4.38.0.0/21 208.50.59.105 1 00:17:43 3549 7018 46164 *> 4.38.8.0/21 208.50.59.105 1 00:17:43 3549 7018 46164 *> 4.43.50.0/24 208.50.59.105 1 00:17:43 3549 7018 46164 *> 4.43.51.0/24 208.50.59.105 1 00:17:43 3549 7018 46164 *> 4.67.96.0/21 208.50.59.105 1 00:17:43 3549 7018 46164 *> 4.67.104.0/21 208.50.59.105 1 00:17:43 3549 7018 46164 *> 8.14.0.0/20 208.50.59.105 1 00:17:43 3549 7018 46164 *> 8.14.16.0/20 208.50.59.105 1 00:17:43 3549 7018 46164 *> 24.49.84.0/23 208.50.59.105 1 00:01:22 3549 3356 7843 *> 24.49.89.0/24 208.50.59.105 1 00:01:22 3549 3356 7843 * 38.97.109.0/24 208.50.59.105 2 00:25:18 3549 701 20417 * 41.0.144.0/20 208.50.59.105 2 00:21:47 3549 5713 36994

2 1

fix the edge (was Re: 1/8 and 27/8 allocated to APNIC)
by Anton Kapela 22 Jan '10

22 Jan '10

On Thu, Jan 21, 2010 at 8:22 PM, Jon Lewis <jlewis(a)lewis.org> wrote: > I thought there was some other group that had been squatting in 1/8, > something about radio and peer to peer...but not AnoNet (at least that name > was totally unfamiliar)...but this was all I could find with a quick google. http://en.wikipedia.org/wiki/AnoNet#Scaling oh, the irony. good thing privacy costs too much for the majority of internet users. on a serious note, who cares? Resolution to the 1/8 allocation "mess" seems on par with freeing up IP stacks from excluding 240/4, but by the time any of this is resolved, perhaps residential users on att dsl/etc might just have working IP6CP, or will have switched to comcast by then. -Tk

2 1

Katrina response, private and public
by Eric Brunner-Williams 22 Jan '10

22 Jan '10

Folks, After the Katrina landfall a diverse group of wireless people started organizing a relief effort, culminating in work around Waveland. There was also a group from the NPGS in Monterey, who worked on the Boxing Day Tsunami aftermath. Does anyone have a similar contact set? Eric

13 23

2009 Worldwide Infrastructure Security Report available for download.
by Dobbins, Roland 22 Jan '10

22 Jan '10

[Apologies for any duplication if you've seen this notification on other lists.] We've just posted the 2009 Worldwide Infrastructure Security Report for download at this URL: <http://www.arbornetworks.com/report> This year's WWISR is based upon the broadest set of survey data collected by Arbor to date, with the number of respondents doubling from 66 to 132, and much greater input from non-USA/non-EMEA, regional providers. The WWISR is based upon input from the global operational community, and as such, is unique in its focus on the operational security aspects of public-facing networks. Many of you contributed to the survey which forms the foundation of the report; as always, we're grateful for your insight and participation, and welcome your feedback and comments. Thanks much! ----------------------------------------------------------------------- Roland Dobbins <rdobbins(a)arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken

5 6

Patents, IETF and Network Operators
by Abhishek Verma 22 Jan '10

22 Jan '10

Hi, Network Ops folks use the IETF standards for their operations. I see lot of nifty things coming out from the IETF stable and i was wondering why those dont get patented? Why bother releasing some really good idea to IETF (i.e. open standards bodies) when the vendor could have patented it. The network operators can still use it as long as they are using that vendor's equipment. I understand that interop can be an issue, since it will be a patented technology, but it will always work between the boxes from the same vendor. If so, then whats the issue? Is interop the only issue because of which most ideas get released into IETF? I guess interop is *an* issue since nobody wants a single vendor network. Thanks, Abhishek

8 10

RE: RE: Enhancing automation with network growth
by Kevin St John 22 Jan '10

22 Jan '10

I think Cacti (www.cacti.net) can do this pretty simply if that’s any help… ________________________________________ From: Tom Wright [TWright(a)internode.com.au] Sent: Thursday, January 21, 2010 4:54 PM To: Steve Bertrand Cc: nanog list Subject: Re: Enhancing automation with network growth Hi Steve, Our MRTG is fully automated. We ditched cfgmaker (too slow) in favour of our own developed Perl using the Net::SNMP module from CPAN. If you use 'non-blocking' SNMP calls, Net::SNMP can be blisteringly fast. In the case of our routers/switches, we query our NMS (assume this is just a table of hostnames and IP addresses) for a list the devices we want to graph, and then re-generate MRTG configurations a few times a day - meaning that we pick up new devices/port changes automatically. Capital expenditure = $0 :) -- Tom On 21/01/2010, at 1:24 PM, Steve Bertrand wrote: Hi all, I'm reaching the point where adding in a new piece of infrastructure hardware, connecting up a new cable, and/or assigning address space to a client is nearly 50% documentation and 50% technical. One thing that would take a major load off would be if my MRTG system could simply update its config/index files for itself, instead of me having to do it on each and every port change. Can anyone offer up ideas on how you manage any automation in this regard for their infrastructure gear traffic graphs? (Commercial options welcome, off-list, but we're as small as our budget is). Unless something else is out there that I've missed, I'm seriously considering writing up a module in Perl to put up on the CPAN that can scan my RANCID logs (and perhaps the devices directly for someone who doesn't use RANCID), send an aggregate 'are these changes authorized' email to an engineer, and then proceed to execute the proper commands within the proper MRTG directories if the engineer approves. I use a mix of Cisco/FreeBSD&Quagga for routers, and Cisco/HP for switches, so it is not as simple as throwing a single command at all configs. All feedback welcome, especially if you are in the same boat. My IP address documentation/DNS is far more important than my traffic stats, but it really hurts when you've forgotten about a port three months ago that you need to know about now. Steve -- Kind Regards, Tom Wright Internode Network Operations P: +61 8 8228 2999 W: http://www.internode.on.net<http://www.internode.on.net/>

1 0

Housing situations sought for the family of Reynold Guerrier
by Eric Brunner-Williams 21 Jan '10

21 Jan '10

Naturally, I didn't make all the local connections I could have before I needed them when I went to NANOG-45, graciously hosted by Terremark. I think it is unlikely that any of the three paths -- parole from Homeland Security, visa from State, and Congressional action, are likely to occur within finite time. Not only is the situation on the ground profoundly difficult, but we constantly encounter questions about the necessity of network continuity at all, or the value of any one person maintaining the operational integrity of the NAP/IXP/uW relay serving the Haitian government, on-site NGOs, and cellular traffic. So I'm turning again to the Operator Community for help. If you have contacts in the DR that could help Reynold's wife Dominique and their children, Nikki, age 3, and Aurelia, age 1, please send them to me. Housing for four. When Dominique and the kids are secure, Reynold is going back to the data center in Boutillers, which consists of the microwave relay to the Dominican Republic, the Internet Exchange point (IX) he normally operates, and Network Access Point (NAP), since the event. There is no other skilled person present. Basically, Reynold has inherited the entire facility, as the operator of the IXP hosted in the larger data center, and some technicians, who he now provides for and manages. The distance from Port au Prince to Santo Domingo is 5 hours, road condition and boarder control time included. Eric

2 1

Emergency power generators
by Mike 21 Jan '10

21 Jan '10

Hi Folks, Northern California is getting pounded hard by storms, as we do most every year, and have quite a few electric outages as a result. Of particular note however is that we have experienced a number of remote and inaccessible microwave backhaul sites where the on-site generator has failed to engage, leaving us with 9 hours of battery. Sometimes, fortunately, that's enough to carry us through. Other times, like now, it's not. I don't want to lecture the site owners about routine testing procedures and so forth, but it seems that we need to become experts on the topic and we would like to offer these site owners a solution to test and verify generator operation. Does anyone have any pointers to possible solutions or vendor white papers I could look at? We probably want to verify start, read voltage to verify output, and maybe even gauge fuel in the tanks if thats possible. No sales droids please, just helpful information based on experience at this time. Thank you.

8 7