February 2014 archive

TDYR #111 – New Report Out About Protecting Against DDoS Attacks On DNS

How can we best protect the Domain Name System (DNS) against distributed denial of service (DDoS) attacks? There's a new report from ICANN's SSAC on this issue: http://www.internetsociety.org/deploy360/blog/2014/02/ssac-issues-new-report-on-ddos-attacks-against-dns/

What Devices And Software Support The Opus Audio Codec? Here Is A List

Opus codec logoWhat devices support the Opus audio codec? What softphones? hardphones? call servers? Obviously given that Opus is the "mandatory to implement" audio codec for WebRTC, it will be in many web browsers... but what other I was asked this question by a colleague recently and when I couldn't easily find a list on the Opus codec web site, I turned to the VUC community inside of Google+ and posted there. The great folks there naturally were a huge help, and quickly came up with this list:

UPDATE: No sooner had I hit "Publish" then I discovered that Wikipedia has a list of devices and software supporting the Opus codec. As that list is much longer than this one below, I'd encourage you to look at that list.

What other devices or software supports the Opus codec? (Or what other lists are out there listing devices supporting the Opus codec?) Please do let me know either by comments here or on social media.


P.S. If you don't understand WHY the Opus codec matters so much, please read my earlier post on this topic.

If you found this post interesting or useful, please consider either:

SSAC Issues New Report On DDoS Attacks Against DNS

SSAC logoWhat can be done to prevent Distributed Denial of Service (DDoS) attacks against the DNS infrastructure? What can individuals or organizations who operate DNS servers do to their own systems to help reduce the threat of DDoS attacks?   ICANN’s Security and Stability Advisory Committee (SSAC) took on this issue recently and released a new report this week: “SAC065: SSAC Advisory on DDoS Attacks Leveraging DNS Infrastructure“.  It is available as a free PDF download in English.

While the report is not about DNSSEC, per se, it is about the overall issue of “DNS security” and outlines steps that can be taken to reduce the potential of DNS-based DDoS attacks.  This is critical if we are to get DNSSEC more widely deployed because there are some DNS server operators who have pushed back about DNSSEC citing concerns about the larger size of DNSSEC packets could help amplify DDoS attacks.

The recommendations for the industry include the following (with the report providing more detail on each):

Recommendation 2: All types of network operators should take immediate steps to prevent network address spoofing.

Recommendation 3: Recursive DNS server operators should take immediate steps to secure open recursive DNS servers.

Recommendation 4: Authoritative DNS server operators should investigate deploying authoritative response rate limiting.

Recommendation 5: DNS operators should put in place operational processes to ensure that their DNS software is regularly updated and communicate with their software vendors to keep abreast of latest developments.

Recommendation 6: Manufacturers and/or configurators of customer premise networking equipment, including home networking equipment, should take immediate steps to secure these devices and ensure that they are field upgradable when new software is available to fix security vulnerabilities, and aggressively replacing the installed base of non-upgradeable devices with upgradeable devices.

We agree with those recommendations and definitely encourage people to read the SSAC report and implement as many recommendations as possible.

Working together we can make the Internet more secure!

TypePad To Start Using Akismet To Fight Blog Comment Spam

Yes! The folks at TypePad announced today they going to start using Akismet to fight blog comment spam! As a user of TypePad since 2005-ish, I've long been frustrated with how poorly TypePad's anti-comment-spam mechanisms have worked and have written about that, although granted that particular incident was now 3.5 yrs ago and things have improved a bit in that I'm not seeing quite as much spam. However, I've also turned on full moderation on the couple of remaining blogs I still have on TypePad.

All my new blogs and other sites are over on WordPress where I've been very happy with the anti-spam services that I get from Akismet. (And some day I'd like to move this blog and Disruptive Telephony over to WordPress, too - if only I can carve out the considerable time that will be involved with the move.)

I'm pleased to see TypePad moving this way. It may not be enough to get me to stop using full moderation on my articles... but hopefully it should mean fewer spam comments to look at in the admin interface.

If you found this post interesting or useful, please consider either:

TDYR #110 – The Power Of Hacker News And Reddit To Drive Attention To Your Content

Today I reflect on the power of sites like Hacker News and Reddit to drive a large amount of attention to an article or other piece of content. I discovered today that a post I wrote last week: http://www.circleid.com/posts/20140219_anyone_who_still_thinks_ipv6_wont_happen_isnt_watching_measurems/ wound up on both HN and Reddit and subsequently has jumped to receive a high number of views: https://news.ycombinator.com/item?id=7291236 http://www.reddit.com/r/technology/comments/1yssvn/anyone_who_still_thinks_ipv6_wont_happen_clearly/

3 Sessions About Securing BGP At IETF89 Next Week

BGPNext week at IETF 89 in London there will be a good bit of discussion around the security and resilience of the Internet’s routing infrastructure.  Given our interest in securing BGP, members of our team will be attending the SIDR, GROW and IDR Working Groups next week and engaging in other routing discussions as well.

My colleague Andrei Robachevsky wrote about routing as part of the IETF 89 “Rough Guide” today and explained some of the activities that will be happening during the week.  I’d encourage you to read his post as he goes into some detail about the different drafts that are being considered by the three working groups.

Relevant Working Groups

SIDR (Secure Inter-Domain Routing)
Tuesday, March 4, 0900-1130 UTC, Balmoral Room
WG Agenda: https://datatracker.ietf.org/meeting/89/agenda/sidr/
Documents: https://datatracker.ietf.org/wg/sidr/
Charter: https://datatracker.ietf.org/wg/sidr/charter/

GROW (Global Routing Operations)
Tuesday, March 4, 1300-1400 UTC, Blenheim Room
WG Agenda: https://datatracker.ietf.org/meeting/89/agenda/grow/ (not yet available)
Documents: https://datatracker.ietf.org/wg/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/

IDR (Inter-Domain Routing Working Group)
Thursday, March 6, 1300-1500 UTC, Blenheim Room
WG Agenda: https://datatracker.ietf.org/meeting/89/agenda/idr
Documents: https://datatracker.ietf.org/wg/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/

Remote Participation

You don’t have to be in London to participate in the meetings of IETF 89. You can also:

  • Listen to live audio streams.
  • Participate in Jabber chat rooms to ask questions.
  • Download the slides planned for each session.
  • Listen and watch “Meetecho” conferencing sessions that provide an integrated view of slides, audio, chat and video.

Information about how to participate can be found on the IETF 89 Remote Participation page.  Keep in mind that times for London are in UTC.

FIR #744 – 2/24/14 – For Immediate Release

Back to Skype; Quick news: Chevron gives free pizza after fracking explosion, Virgin Galactic looking for a PR agency, Groupon says its President's Day gaffe was a hoax, Sprinklr acquires Dachis; Ragan promo; News That Fits: CIPR survey says PR is at a crossroads, Michael Netzley's Asia Report, internal social media leads to more internal influencer mapping, Media Monitoring Minute from CustomScoop, listener comments, five tips from BuzzFeed on making content shareable, Dan York's Tech Report, last week on the FIR Podcast Network, the role of the idea carrier; music from Les Gordons; and more.

RFC 7123 – Security Implications of IPv6 on IPv4 Networks

What are the security issues around IPv6 support and IPv6 transition mechanisms on an IPv4-only network?  Could the unplanned and perhaps even unknown support of IPv6 by operating systems introduce additional security concerns into an enterprise network?

In an Informational RFC 7123 published in February 2014, Fernando Gont and Will Liu explore the security implications of native IPv6 support and also of IPv6 tunneling mechanisms.  They walk through the different transition mechanisms, explain potential security issues and outline ways to potentially mitigate the security concerns.  The document is available at:


The introduction of the document gives a taste of what the rest of the document covers:

Most general-purpose operating systems implement and enable native IPv6 [RFC2460] support and a number of transition/coexistence technologies by default. Support of IPv6 by all nodes is intended to become best current practice [RFC6540]. Some enterprise networks might, however, choose to delay active use of IPv6.

This document describes operational practices to prevent security exposure in enterprise networks resulting from unplanned use of IPv6 on such networks. This document is only applicable to enterprise networks: networks where the network operator is not providing a general-purpose internet, but rather a business-specific network. The solutions proposed here are not practical for home networks, nor are they appropriate for provider networks such as ISPs, mobile providers, WiFi hotspot providers, or any other public internet service.

In scenarios in which IPv6-enabled devices are deployed on enterprise networks that are intended to be IPv4-only, native IPv6 support and/or IPv6 transition/coexistence technologies could be leveraged by local or remote attackers for a number of (illegitimate) purposes. For example,

  • A Network Intrusion Detection System (NIDS) might be prepared to detect attack patterns for IPv4 traffic, but might be unable to detect the same attack patterns when a transition/coexistence technology is leveraged for that purpose.
  • An IPv4 firewall might enforce a specific security policy in IPv4, but might be unable to enforce the same policy in IPv6.
  • A NIDS or firewall might support both IPv4 and IPv6, but might not be configured to enforce on IPv6 traffic the same controls/policies it enforces on IPv4 traffic.
  • Some transition/coexistence mechanisms could cause an internal host with otherwise limited IPv4 connectivity to become globally reachable over IPv6, therefore resulting in increased (and possibly unexpected) host exposure.
  • IPv6 support could, either inadvertently or as a result of a deliberate attack, result in Virtual Private Network (VPN) traffic leaks if IPv6-unaware VPN software is employed by dual-stacked hosts.

In general, most of the aforementioned security implications can be mitigated by enforcing security controls on native IPv6 traffic and on IPv4-tunneled IPv6 traffic. Among such controls, is the enforcement of filtering policies to block undesirable traffic. While IPv6 widespread/global IPv6 deployment has been slower than expected, it is nevertheless happening; and thus, filtering IPv6 traffic (whether native or transition/coexistence) to mitigate IPv6 security implications on IPv4 networks should (generally) only be considered as a temporary measure until IPv6 is deployed.

TDYR #109 – Wishing The Best For All In Ukraine Right Now

Tonight my thoughts are with all the folks in Kiev and throughout the Ukraine as they make their way through some very turbulent times... (More info: https://en.wikipedia.org/wiki/Euromaidan )

TDYR #108 – The Amazing Power Of The Olympics To Get People Excited About Curling!

TDYR #108 - The Amazing Power Of The Olympics To Get People Excited About Curling! by Dan York