- NANOG - lists.nanog.org

APRICOT-2012: Call for Papers
by Mark Tinka 24 Nov '11

24 Nov '11

Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) 21 February - 2 March 2012, New Delhi, India http://www.apricot2012.net CALL FOR PAPERS =============== The APRICOT 2012 Programme Committee is now seeking contributions for Presentations and Tutorials for APRICOT 2012. We are looking for people and proposals that would: - Offer a technical tutorial on an appropriate topic; and/or - Participate in the technical conference sessions as a speaker; and/or - Convene and chair a Birds of a Feather (BOF) session. Please submit proposals on-line at: http://submission.apnic.net/ CONFERENCE MILESTONES --------------------- Call for Papers Opens: 22 November 2011 First Draft Program Published: 19 December 2011 Final Deadline for Submissions: 10 February 2012 Final Program Published: 17 February 2012 Final Slides Received: 25 February 2012 PROGRAM MATERIAL ---------------- The APRICOT Programme is organised in three parts, including workshops, tutorials and the conference. The APNIC Policy SIG and Annual Members Meeting will be held during the APRICOT conference. Topics for tutorials and conference would include amongst others relevant to Internet Operations and Technologies: - IPv4 / IPv6 Routing and operations - IPv4 address runout / IPv6 deployment and transition technologies - Backbone operations - ISP and Carrier services - Network security issues (NSP-SEC, DDoS Anti-Spam, Anti-Malware) - Peering / IXPs - DNS / DNSSEC - Internet policy (Security, Regulation, Content Management, Addressing, etc) - Access and Transport Technologies, including broadband deployment, Cable/DSL, wireless, WiMax, metro ethernet, fiber network, MPLS - Content & Service Delivery (Multicast, Voice, Video, "telepresence", Gaming) CfP SUBMISSION -------------- All draft and complete slides must be submitted in PDF format only. Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions otherwise the Programme Committee will be unable to review the submission. For work in progress, the most current information available at time of submission is acceptable. Final slides are to be provided by the specified deadline for publication on the APRICOT website. While the majority of speaking slots will be filled by the first submission deadline, a limited number of slots may be available up to the final submission deadline for presentations that are exceptionally timely, important, or of critical operational importance. Please submit on-line at: http://submission.apnic.net/ Any questions or concerns should be addressed to the Programme Committee by e-mail at: pc-chairs at apricot.net We look forward to receiving your presentation proposals. Mark Tinka & Jonny Martin Co-Chairs, APRICOT Programme Committee program(a)apricot.net

1 0

automated config backups for SFTOS
by Jon Heise 24 Nov '11

24 Nov '11

Does anyone know of a method of automating config backups for force10 switches running SFTOS ? I've got an python expect script that works on our routers running FTOS, it uses a role account that can show the running configs without having to use the enable password. i could expand the script to use the enable password but i'm hesitant to have it lying around in a script Jon Heise

4 4

Posting for network engineers and operators...
by Brian Stengel 24 Nov '11

24 Nov '11

Apologies if this is not appropriate for this list... but I'm looking to hire network engineers for our project and would like to hear what job boards are best for network engineering types to view. I'm not a recruiter. We are looking for positions in Pennsylvania. Dice? Monster? Linked-in? thanks, brian -- Brian Stengel KINBER Director of Operations bstengel(a)kinber.org M: 412.398.2333 GV: 412.254.3481 Skype: brian_stengel KINBER - Keystone Initiative for Network Based Education and Research - www.kinber.org PennREN - Pennsylvania's Research and Education Network

8 7

Re: First real-world SCADA attack in US
by Hal Murray 24 Nov '11

24 Nov '11

> Like any of the decades largest breaches this could have been avoided by > following BCP's. In addition SCADA networks are easily protected via > behavioral and signature based security technologies. Is there a BCP that covers security for SCADA? Note that Google for "BCP SCADA" finds BS-25999 Business Continuity Plan Implementation Checklist ... ---------- Suppose a friend of yours was a low-level geek working for either a user/operator of a SCADA system or a vendor of software/hardware for that market. If he asked you for info about security, where would you send him? (Assume he knows all about SCADA but little about networks or security.) For that matter, is there any good security info for small to medium sized businesses? Say a local store, travel agency, or doctor/dentist. -- These are my opinions, not necessarily my employer's. I hate spam.

2 1

First real-world SCADA attack in US
by Jay Ashworth 23 Nov '11

23 Nov '11

On an Illinois water utility: http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

24 44

Odd router brokenness
by Mark Radabaugh 23 Nov '11

23 Nov '11

Since this list likes to speculate with little facts on a regular basis (and I'll admit to being as guilty as anyone) I throw this one out for opinions : We were seeing very odd behavior on a Cogent circuit following a software upgrade to tol01.atlas. Two traceroutes: mark@angola-gw> traceroute 74.125.226.6 traceroute to 74.125.226.6 (74.125.226.6), 30 hops max, 40 byte packets 1 * * gi1-1.ccr01.tol01.atlas.cogentco.com (38.104.148.5) 110.315 ms 2 te4-2.ccr01.sbn01.atlas.cogentco.com (154.54.7.154) 139.520 ms 196.910 ms 5.728 ms 3 * * * 4 * te0-5-0-5.ccr21.ord03.atlas.cogentco.com (154.54.44.174) 8.310 ms te0-0-0-7.ccr21.ord03.atlas.cogentco.com (154.54.25.70) 8.752 ms 5 te0-0-0-0.ccr22.ord03.atlas.cogentco.com (154.54.24.214) 8.983 ms te0-1-0-0.ccr22.ord03.atlas.cogentco.com (66.28.4.66) 7.948 ms * 6 * * te-9-1.car4.Chicago1.Level3.net (4.68.127.129) 26.127 ms 7 GOOGLE-INC.car4.Chicago1.Level3.net (4.71.100.22) 38.132 ms 25.120 ms * 8 * * 209.85.254.122 (209.85.254.122) 24.539 ms 9 * 72.14.237.130 (72.14.237.130) 26.134 ms 72.14.237.108 (72.14.237.108) 25.021 ms MPLS Label=666803 CoS=4 TTL=1 S=1 10 216.239.46.161 (216.239.46.161) 31.816 ms 35.702 ms 32.249 ms 11 72.14.233.142 (72.14.233.142) 32.897 ms * * 12 * yyz06s05-in-f6.1e100.net (74.125.226.6) 33.319 ms * and a ping over the same path: --- www.l.google.com ping statistics --- 675 packets transmitted, 323 packets received, 52.1% packet loss round-trip min/avg/max/stddev = 12.834/28.831/129.743/28.987 ms and at the same time: mark@angola-gw> traceroute 38.100.128.10 traceroute to 38.100.128.10 (38.100.128.10), 30 hops max, 40 byte packets 1 gi1-1.ccr01.tol01.atlas.cogentco.com (38.104.148.5) 4.445 ms 1.841 ms 1.713 ms 2 te7-7.ccr02.cle04.atlas.cogentco.com (154.54.5.230) 5.318 ms te3-2.ccr02.cle04.atlas.cogentco.com (154.54.28.86) 4.755 ms te7-7.ccr02.cle04.atlas.cogentco.com (154.54.5.230) 4.982 ms 3 te4-2.ccr01.pit02.atlas.cogentco.com (154.54.30.10) 7.997 ms te3-2.ccr01.pit02.atlas.cogentco.com (154.54.30.6) 7.736 ms te4-2.ccr01.pit02.atlas.cogentco.com (154.54.30.10) 8.177 ms 4 te0-0-0-5.mpd21.dca01.atlas.cogentco.com (154.54.40.81) 17.197 ms te0-0-0-5.ccr22.dca01.atlas.cogentco.com (154.54.30.230) 16.907 ms te0-0-0-5.mpd21.dca01.atlas.cogentco.com (154.54.40.81) 17.008 ms 5 te0-1-0-0.mpd22.dca01.atlas.cogentco.com (154.54.2.193) 17.358 ms te0-0-0-0.mpd22.dca01.atlas.cogentco.com (154.54.31.38) 17.196 ms te0-1-0-0.mpd22.dca01.atlas.cogentco.com (154.54.2.193) 18.690 ms 6 te4-2.mpd01.iad03.atlas.cogentco.com (154.54.29.122) 17.885 ms * 18.537 ms 7 cogentco.com (38.100.128.10) 17.836 ms !<10> 17.918 ms !<10> 17.833 ms !<10> --- 38.100.128.10 ping statistics --- 236 packets transmitted, 236 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 22.717/27.942/128.011/12.236 ms sh-3.2# Works perfectly. There is no asymmetric routing in this scenario (only 1 BGP peer running during this test), and it is not due to traffic congestion. Initial speculation over the dropped packets in the trace to 74.125.226.6 was ICMP depriortization. The results are too consistent for that to make sense (I have dozens of traceroutes to the same destination - they all appear similar). I realize there is a long history of Cogent/L3 ugliness but I'm pretty sure that this issue has nothing to do with that subject. Traceroutes and pings from the control plane of tol01.atlas sourced from 38.104.148.5 do not show any odd behavior. Inbound traffic (to us) is not affected by this. Our workaround while resolving this issue was to change local-pref on the affected prefixes to send traffic out our other providers. The issue started after a software upgrade to tol01.atlas and resolved after a (reported) reboot of tol01.atlas. The question is: How does a router break in this manner? It appears to unintentionally be doing something different with traffic based on the source address, not the destination address. I realize this can be done intentionally - but that is not the case here (unless somebody isn't telling me something). -- Mark Radabaugh Amplex mark(a)amplex.net 419.837.5015

4 6

Postini or Google contact
by Andy Ringsmuth 23 Nov '11

23 Nov '11

Any chance there's someone on this list from Google, or more specifically, the Postini portion? We're having some unusual mail blockages coming from one specific domain that Postini has been giving us headaches over for the past few weeks. I've got the logs to verify/help track down the problem, but I've confirmed it is within Postini. Much appreciated. ---- Andy Ringsmuth andy(a)newslink.com News Link – Manager Technology 1845 S. 11th St., Lincoln, NE 68502 (402) 475-6397 (402) 304-0083 cellular

1 0

Contact for Telefonica (AS12956)
by Brandon Ewing 23 Nov '11

23 Nov '11

Greetings, Can someone put me in contact with someone with clue in the Telefonica backbone? One of their downstreams is hijacking a prefix of mine as a /24. I've also started advertising the /24 to my upstreams, but many Telefonica customers are still seeing the bad route. I tried to check the NOC list at puck.nether.net, but it appears to be down. -- Brandon Ewing (nicotine(a)warningg.com)

2 1

RIPE 64 Call for Presentations
by Todd Underwood 23 Nov '11

23 Nov '11

Fellow builders, operators, analyzers and ponderers of networks, I suspect that the following Call for Presentations may be a useful reminder for some of you to begin working on presentations for RIPE 64 next Spring. ------------------------------- RIPE 64: Call for Presentations RIPE 64 takes place on 16-20 April 2012 in Ljubljana, Slovenia. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the Plenary, BoF and tutorial sessions at RIPE 64. The PC seeks presentations covering topics of network engineering and operations, including but not limited to: • IPv6 deployment • Managing IPv4 scarcity in operations • Commercial transactions of IPv4 addresses • Data centre technologies • Network and DNS operations • Internet governance and regulatory practices • Network and routing security * Content delivery * Internet peering and mobile data exchange Submissions ------------ Attendees of the RIPE meetings are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters who are proposing a panel or BOF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. Presenters should indicate how much time they will require (30 minutes is a common maximum duration, although some talks can be longer). Proposals for presentations must be submitted for full consideration no later than *3 February* using the online topic submission system at: http://meetings.ripe.net/pc/ Presentations submitted after this date will be considered on a space-available basis. In addition to presentations selected in advance for the plenary, the RIPE PC also offers several timeslots for “lightning talks” which are selected immediately before or during the conference. Lightning talks are short (10 mins maximum) and often involve more timely topics. Lightning talks will be announced shortly before the conference. If you are aware of a talk that might be interesting to the community, please provide us with the details and we will approach the potential speaker. If you have any questions or requests concerning content submissions, please email pc(a)ripe.net. For more information about RIPE 64, including how to register, visit: http://ripe64.ripe.net/ Kind regards, todd underwood, for the RIPE Programme Committee toddunder(a)gmail.com pc(a)ripe.net

1 0

Re: First real-world SCADA attack in US
by Dennis 23 Nov '11

23 Nov '11

Like any of the decades largest breaches this could have been avoided by following BCP's. In addition SCADA networks are easily protected via behavioral and signature based security technologies. Steven Bellovin <smb(a)cs.columbia.edu> wrote: > >On Nov 22, 2011, at 8:08 58PM, Steven Bellovin wrote: > >> >> On Nov 22, 2011, at 7:51 59PM, Valdis.Kletnieks(a)vt.edu wrote: >> >>> On Tue, 22 Nov 2011 13:32:23 -1000, Michael Painter said: >>> >>>>> http://jeffreycarr.blogspot.com/2011/11/latest-fbi-statement-on-alleged.html >>> >>>> And "In addition, DHS and FBI have concluded that there was no malicious traffic from Russia or any foreign entities, as >>>> previously reported." >>> >>> It's interesting to read the rest of the text while doing some deconstruction: >>> >>> "There is no evidence to support claims made in the initial Fusion Center >>> report ... that any credentials were stolen, or that the vendor was involved >>> in any malicious activity that led to a pump failure at the water plant." >>> >>> Notice that they're carefully framing it as "no evidence that credentials were >>> stolen" - while carefully tap-dancing around the fact that you don't need to >>> steal credentials in order to totally pwn a box via an SQL injection or a PHP >>> security issue, or to log into a box that's still got the vendor-default >>> userid/passwords on them. You don't need to steal the admin password >>> if Google tells you the default login is "admin/admin" ;) >>> >>> "No evidence that the vendor was involved" - *HAH*. When is the vendor *EVER* >>> involved? The RSA-related hacks of RSA's customers are conspicuous by their >>> uniqueness. >>> >>> And I've probably missed a few weasel words in there... >> >> They do state categorically that "After detailed analysis, DHS and the >> FBI have found no evidence of a cyber intrusion into the SCADA system of >> the Curran-Gardner Public Water District in Springfield, Illinois." >> >> I'm waiting to see Joe Weiss's response. > > >See http://www.wired.com/threatlevel/2011/11/scada-hack-report-wrong/ > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > >

1 0