December 2012 - Test - lists.nanog.org

Re: IP Address Management IPAM software for small ISP
by Chris Conn 23 Jan '13

23 Jan '13

> looking for IPAM solutions for a small regional wireless ISP. > There are 4 Tier 2 personnel and 2 NOC technicians who would be using > the tool, and a small staff of engineers. > Nobody uses HaCI?

2 2

looking glass for Level 3
by Tassos Chatzithomaoglou 16 Jan '13

16 Jan '13

Anyone have any looking glass for Level 3? The following seem not to be working http://www.level3.com/LookingGlass/ http://lg.level3.net/bgp/bgp.cgi http://lookingglass.level3.net/ -- Tassos

7 7

State of the RING 2012
by Job Snijders 15 Jan '13

15 Jan '13

Hi, Here is the yearly update regarding the NLNOG RING project, this year's update includes some links to tools that might be of interest to the broader community. More information about the RING can be found here: https://ring.nlnog.net/ Kind regards, Job ============================================================ State of the NLNOG RING 2012 A yearly newsletter about the best debugging project ever Edition 2, 28 Dec 2012 ============================================================ Contents ============================================================ 1. Introduction: growth 2. New services 4. Into the future! 5. Testimonials & conference exposure 6. Closing notes ============================================================ 1. Introduction: growth ============================================================ Today, 28th of december 2012, the RING turns 2 years old! The project's origins can be traced back to the following line on IRC (translated): [28 Dec 2010/10:26 CET - #NLNOG] "hey, maybe we should create a #nlnog test platform" And now here we are, 2 years later: 188 machines provided by 165 organisations in 39 countries. Compared to 2011 we have more than doubled in size! From our usage statistics we gather that 65% of organisations actively makes use of the RING through SSH. Other statistics gathered from our code repositories: - 1111 commits were made (doubled since last year!) - Most code commits happened, again, on Tuesdays - Lines of code: 20267 insertions(+), 5774 deletions(-) We could not have sustained this level of growth without the continuing support of our infrastructure sponsors and the 2012 fundraiser contributors: XS4ALL, Amazon Web Services, Leaseweb, Atrato IP Networks, Gossamer Threads, BIT, PCextreme, SoftLayer, Snijders IT, Solido Hosting, Duocast, A2B Internet, Nedzone, Tetaneutral, LCHost, Previder, Triple IT and eBay Classifieds Group. A full overview of all supporters can be found here: https://ring.nlnog.net/patrons/ ============================================================ 2. New services ============================================================ AMP (Active Measurement Project): --------------------------------- One of the biggest changes this year was moving from a distributed master/slave smokeping setup to something much better: AMP. The AMP software performs measurements from every RING node to every other RING node, and reports the results to central collectors which in turn feed a web interface. AMP as a tool offers us insight in end-to-end MTU, jitter, latency, packetloss and historic traceroutes both for IPv4 and IPv6 between all RING nodes. URL: http://amp.ring.nlnog.net/ BGP Looking glass: ------------------ Due to popular request we set up a BGP looking glass, which currently receives full IPv4 and IPv6 tables from 35+ participants. The LG uses the BIRD BGP daemon with a web interface written by one of the RING participants! We currently are exploring if we can use the collected data for a monitoring and alerting system to help participants gain insight in prefix visibility and, for instance hijack events. Stay tuned! URL: http://lg.ring.nlnog.net/ IRR/RPLS services: ------------------ Although the IRR system and RPSL have been around for a long time, there still is a lot of room for improvement in terms of performance, ease of use and standardised methods and tools. We believe that the RING community can make a difference in the popularity of proper filtering. One of the first things we offer (in beta) is a web service to expand RPSL object such as AS-SET, AUTNUM and RS-SETs and expose the data in JSON. URL: http://irr.ring.nlnog.net/ ============================================================ 3. Into the future! ============================================================ In 2013 we will continue to automate as many aspects of the RING as possible. But more importantly, the RING has to become the best swiss army knife a network engineer can imagine so we will focus on usability, more advanced tools and security. We are making a lot of progress towards publication of all kinds of RING related information in an easy accessible database, we imagine this will accelerate the development of a new generation of tools! We also started talks with other debugging projects such as RIPE Atlas to explore if cooperation and exchange of information can further such projects. As the RING is a community effort, we can only become more valuable to our members by help from the community. We need you for new creative ideas, high quality code, and of course more RING nodes. If you can help out in our efforts, don't hesitate to contact us! ============================================================ 4. Testimonials & Exposure ============================================================ Two debugging cases have been documented, where the RING proved to be of vital importance when debugging an issue at hand. Route leak: ----------- A root-cause analysis based on historic data collected by the RING. URL: https://ring.nlnog.net/news/root-cause-analysis-using-amp/ The IPv4 address that ended with .255: -------------------------------------- How the variety in RING nodes helped locate an ancient, dysfunctional ACL. URL: https://ring.nlnog.net/news/ring-success-the-ipv4-255-problem/ Conference exposure: -------------------- Various RING participants have spoken at Internet oriented conferences around the world. The following meetings made a presentation slot available to the RING: eduPERT, LINX79, MENOG11, NANOG56 and RIPE65. All of these presentations have helped the RING grow, as in the days after such a presentation we saw a spike in RING participant applications. If you want to present about the RING at a meeting in your region or local operator community, please contact us. We have great slides available for this purpose! ============================================================ 5. Closing notes ============================================================ We conclude this newsletter by saying to you, the participants, THANK YOU! Without the continued support from lots of participants the RING would not be where it is today. We are proud to be playing a small role in making the Internet an easier thing to debug and research. Again, thank you! Kind regards, Job Snijders Martin Pels Peter van Dijk Edwin Hermans ringthing

2 1

RE: [j-nsp] Krt queue issues
by Jensen Tyler 08 Jan '13

08 Jan '13

Look into Static route retain. Should keep the route in the forwarding table. >From Jniper site <<< Route Retention By default, static routes are not retained in the forwarding table when the routing process shuts down. When the routing process starts up again, any routes configured as static routes must be added to the forwarding table again. To avoid this latency, routes can be flagged as retain, so that they are kept in the forwarding table even after the routing process shuts down. Retention ensures that the routes are always in the forwarding table, even immediately after a system reboot. >>> Thanks, Jensen Tyler Sr Engineering Manager Fiberutilities Group, LLC -----Original Message----- From: juniper-nsp-bounces(a)puck.nether.net [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of Benny Amorsen Sent: Wednesday, October 03, 2012 8:32 AM To: Jared Mauch Cc: Saku Ytti; juniper-nsp(a)puck.nether.net Subject: Re: [j-nsp] Krt queue issues Jared Mauch <jared(a)puck.nether.net> writes: > As far as the fallback 'default' route, if you are purchasing transit > from someone, you could consider a last-resort default pointed at > them. You can exclude routes like 10/8 etc by routing these to discard > + install on your devices. That only helps if the default gets installed first, though. If the default has to wait at boot in the krt-queue behind the 300k+ Internet-routes, I have not really gained anything... I suppose it is likely that a static default would be installed before the BGP sessions even come up. /Benny _______________________________________________ juniper-nsp mailing list juniper-nsp(a)puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp

5 5

Re: Gmail and SSL
by Keith Medcalf 04 Jan '13

04 Jan '13

Your assertion that using "bought" certificates provides any security benefit whatsoever assumes facts not in evidence. Given recent failures in this space I would posit that the requirement to use certificates purchased from entities "under the thumb" of government control, clearly motivated only by profit, and with highly questionable moral and ethical standards represents a huge increase in risk of passive attack and confidentiality failure where such rosk did not previously exist. Sent from Samsung Mobile -------- Original message -------- From: Jimmy Hess <mysidia(a)gmail.com> Date: To: Randy <nanog(a)afxr.net> Cc: NANOG list <nanog(a)nanog.org> Subject: Re: Gmail and SSL

25 48

Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.
by Keith Medcalf 03 Jan '13

03 Jan '13

Concomittant wirh reduced risk assessment capability? Sent from Samsung Mobile -------- Original message -------- From: Randy Bush <randy(a)psg.com> Date: To: Lynda <shrdlu(a)deaddrop.org> Cc: North American Network Operators' Group <nanog(a)nanog.org> Subject: Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.

5 5

GeekTools Whois Proxy and RIPE/RIPE-NCC
by Rodney Joffe 01 Jan '13

01 Jan '13

NANOG and ARIN Friends, 14 Years ago, at the suggestion of Jon Postel and some of the early participants in NANOG, we developed the GeekTools Whois proxy to make it easier for *us* - network security and abuse techs - to deal with the expanding number of gtlds and registrars and the varied whois servers that were appearing. The service had both a CLI and web interface. The service also led directly to the creation of whois-servers.net, which now seems to be part of a number of *nix distributions. The service has been up for 14 years, and over that time we have fulfilled the requirements of all of the whois server operators in regards to minimizing and stopping abuse of the GT whois proxy by domain scrapers, spammers, etc, while enabling the security folks to do their jobs. In some cases we have even written code to pass the ip address of the requestor to the whois server registry operator when they wanted to manage quota's directly. We think we have a really good relationship with all of the whois server operators, and I think we provide a useful service to the community, and is widely used. And in 14 years we have never been tarred as an enabler of abuse of "the whois" system. There has obviously never been any kind of charge or fee for using the proxy, or any of the other tools on GeekTools. In about 2002 we started placing a banner ad on the web interface page to offset some of the costs for the bandwidth that the proxy consumes. An average of about $70 a month for over the last 10 years. Actual bandwidth costs are higher than that of course, but it was a thought in 2002 that we had frankly forgotten about until recently. Two weeks ago RIPE-NCC, who provide the whois data for IP addresses in the RIPE region, informed us that based on decisions by their members, as of January 1st 2013, tomorrow, they would no longer provide whois proxy query response services to GeekTools unless we ponied up $1,800 a year for RIPE membership. I don't work very well above layer 7. It is what it is. So I wanted to let you know that as of midnight tonight, apparently, you won't be able to use GeekTools for RIPE related queries. If you have automated scripts, and you are one of the users who has expanded access to GeekTools, you'll need to find an alternative for RIPE queries *today*. My guess is that you will be able to query RIPE directly, once you have worked out that the address space is within RIPE's assignments. I think its wrong to have to pay for whois data that is part of a community resource . So I won't do it.

5 8

Happy new year (and contact at 7018/20057)
by Drew Weaver 31 Dec '12

31 Dec '12

Howdy and Happy New Year. We're having some IP/routing issues with AS 20057/7018 and so far attempts at hitting noc(a)att.net<mailto:noc@att.net> and noc(a)attglobal.net<mailto:noc@attglobal.net> haven't been successful. Does anyone have a contact at 20057 or 7018 or if anyone from those orgs are reading this can you please contact me off list? Thanks, -Drew

1 0

Re: Gmail and SSL
by Keith Medcalf 30 Dec '12

30 Dec '12

While i will agree that the client being able to validate the certificate directly is the best place to be, I do not see any advantage of requiring purchased certificates over self-signed certificates. IMO it provides no realistic security benefit at all. Then again I don't award points for certificate verification having anything to do with identity verification of the remote party. In other words, if I didn't sign it then the certificate posseses no more validity than an ephemeral self-signed certificate. Of course, others are free to delude themselves with additional "theatrics" and false assumtions if they want to do so. Sent from Samsung Mobile -------- Original message -------- From: Christopher Morrow <morrowc.lists(a)gmail.com> Date: To: kmedcalf <kmedcalf(a)dessus.com> Cc: mysidia@gmail.com,nanog@nanog.org Subject: Re: Gmail and SSL

1 0

Gmail and SSL
by Randy 30 Dec '12

30 Dec '12

I'm hoping to reach out to google's gmail engineers with this message, Today I noticed that for the past 3 days, email messages from my personal website's pop3 were not being received into my gmail inbox. Naturally, I figured that my pop3 service was down, but after some checking, every thing was working OK. I then checked gmail settings, and noticed some error. It explained that google is no longer accepting self signed ssl certificates. It claims that this change will "offer[s] a higher level of security to better protect your information". I don't believe that this change offers better security. In fact it is now unsecured - I am unable to use ssl with gmail, I have had to select the plain-text pop3 option. I don't have hundreds of dollars to get my ssl certificates signed, and to top it off, gmail never notified me of an error with fetching my mail. How many of email accounts trying to grab mail are failing now? I bet thousands, as a self signed certificate is a valid way of encrypting the traffic. Please google, remove this requirement. Source: http://support.google.com/mail/bin/answer.py?hl=en&answer=21291&ctx=gmail#s…

10 12