Apr 04
Following up on our recent post about the live demo of how 464XLAT can enable IPv4-only apps to work on IPv6-only networks, T-Mobile’s Cameron Byrne explains some of the challenges of enabling IPv6 for mobile networks and how 464XLAT came about. Cameron is one of the co-authors of RFC 6877 that documents this approach.
P.S. A hat tip to Cisco’s blog who also wrote about Cameron’s video yesterday.
Apr 04
In April 2013, Steve Crocker circulated this report with the following comment:
In June 2009, a year before the root was signed, the DNSSEC Industry Coalition, led by PIR, and the DNSSEC Deployment Initiative, held a symposium, Signed Root Deployment: Framing the Issues, to look at possible consequences of signing the root and the next steps after it was signed.
We had an excellent symposium and drafted a report. Sadly, we couldn’t quite complete the editing process, so the draft lay unpublished, incomplete, since then.
The concerns expressed during the symposium about the consequences of a much larger root zone are now well behind us. However, the sections on key distribution and use and on key rollover remain relevant, which is why we are pushing this draft out at this late date.
We are posting the report here at Steve’s request to make it available to the larger community.
Apr 03
The U.S. Department of Homeland Security recently issued a bulletin titled “TDoS Attacks on Public Safety Communications” and while it was “Law Enforcement Use Sensitive/For Official Use Only” a copy was obtained by Brian Krebs who wrote about it on his site and also published the DHS bulletin publicly.
This resulted in a small flurry of related articles that Mark Collier listed on his VoIP security blog. Most of the articles, unfortunately somewhat predictably, seem to be rehashes of Brian Krebs’ post and/or the DHS bulletin. However, the point is definitely solid – these are real attacks that are happening on call centers out there, including those operated by emergency services organizations. No one wants to be on the receiving end of hundreds (or thousands) of phone calls clogging up your call center and making it unusable for regular business.
The connection to VoIP is that made by Brian Krebs in his article:
According to a recent report from SecureLogix, a company that sells security services to call centers, free IP-PBX software such as Asterisk, as well as computer-based call generation tools and easy-to-access SIP services, are greatly lowering the barrier-to-entry for voice network attackers.
This is the key point. VoIP systems make these kind of attacks much easier to create. Anyone can take one of the various free VoIP servers and create a script that will generate a crazy number of phone calls. And of course the Caller-ID can be easily spoofed using the same servers. I’m sure there are already scripts out there that automate all of this for would-be attackers.
The challenge is then finding either a VoIP service provider (or “ITSP” or “SIP Service Provider”) who will let the attacker send out phone calls to the PSTN – or to find victims that allow incoming SIP connections (which means that attacks could come from any Internet connection). Or to find components of the SIP signaling infrastructure that have weak (or no) authentication and through which an attacker can send calls. For example, SIP gateways that allow incoming SIP calls with minimal (or easily spoofable) authentication.
It’s not necessarily easy to do, but VoIP systems do make it easier than it was in the past, largely because the attackers can obtain a degree of anonymity through masking their source, and also because of the automation of the calling possible through the systems.
Defending against a TDoS is not the easiest, particularly when the attackers can use spoofed Caller IDs to hide their origin. Here is a place where VoIP actually helps because if the calls are coming in over IP, firewalls and other network monitoring tools can be used to recognize patterns and potentially identify and block sources of the attacks. There are companies such as SecureLogix (whose CTO is Mark Collier, whom I linked to earlier) who do sell products and services to help address these threats. As we increasingly move to IP-based communications there will no doubt be many more companies and service providers offering such services.
We as an industry do need to do what we can to help people understand both the threat posed by these attacks, and also the mitigations and possible solutions.
In the meantime, expect more people to be talking about this issue due to this DHS bulletin and the surrounding attention in the media.
What do you think? What should be done within the VoIP vendor/organization community? What are good steps to promote to defend against TDoS attacks?
Apr 02
When should ICANN roll over the root Key Signing Key (KSK) that is at the core of the DNSSEC global chain of trust? How often should it do a rollover? What kind of notifications should be made in advance? What else should be considered?
These are some of the questions for which ICANN is seeking comment in their “Consultation on Root Zone KSK Rollover“. They want to hear from a range of people out there on several specific questions they list.
COMMENTS ARE DUE BY APRIL 12, 2013!
All comments are to be sent to comments-root-zone-consultation-08mar13@icann.org. Do note that submitted comments are posted publicly on ICANN’s website (which enables you to also see what others are saying) after being reviewed by their team.
To step back and explain this a bit, the “Root Zone Management Partners” of ICANN, Verisign and NTIA signed the root of DNS back in July 2010. For those who want the full details, the DNSSEC Practice Statement (DPS) for the root zone KSK spells out the process that occurred.
In keeping with common practice, there are two keys for the root zone: the Key Signing Key (KSK) and the Zone Signing Key (ZSK). The ZSK is used to sign all the records in the root zone – and the KSK is used to sign the ZSK. The ZSK is rolled over quarterly, as described in the DPS for the root zone ZSK.
The root zone KSK has NOT yet been rolled over since the key was put into production in July 2010.
Rolling over the keys in any kind of system such as DNSSEC is an important part of ensuring the system’s integrity. Generating and deploying new keys limits the exposure should an attacker somehow be able to compromise a key. ICANN has a contractual requirement to perform a KSK “within 5 years” of the deployment of the root zone KSK, i.e. by sometime in 2015.
ICANN is asking for comments on a specific set of questions (although the last one is rather open-ended):
They have also published a PDF file with more background and information.
From our perspective, this is an extremely important consultation and:
WE STRONGLY ENCOURAGE READERS TO SUBMIT COMMENTS BY APRIL 12th!
In our view within the Deploy360 team, we believe that the root KSK needs to be rolled sooner rather than later and should be rolled over on a regular basis. We believe there needs to be solid operational experience with rolling the root KSK so that in the unlikely event that the KSK ever should be compromised an emergency KSK rollover could be rapidly performed with minimal impact. We obviously hope that a compromise of the root KSK will never occur, but see value in having the operational experience so that an unscheduled rollover can be more of of a routine process. There may also be problems found in the initial KSK rollover and we need to find those issues out NOW while DNSSEC is still in the early stages of deployment. If we are going to break anything, lets do it now and fix things before DNSSEC gets massively deployed.
In speaking with others about this issue, I’ve generally found most people having a similar viewpoint. But I have seen some points of view in some mailing lists that we should not roll the KSK this early in the deployment as it could have a negative impact on DNSSEC deployment. As mentioned earlier, the counterpoint is that if a root KSK rollover breaks something, let’s find that out now.
ICANN wants to hear from you – and is again seeking comments up through April 12. Please take a moment to read the consultation document and provide comments if you can.
Note that there will be a session at the DNSSEC Workshop at ICANN 46 next week in Beijing specifically on this KSK rollover topic that will be available for remote viewing (albeit at 2:15pm Beijing time).
P.S. If you would like to understand more about key rollovers, section 4.1 of RFC 6781 goes into detail about different rollover processes.
UPDATE #1: When this post was first published, the comment due date in the block quote near the top incorrectly said the due date was April 20th. This was corrected.
Apr 02
Apr 01
Next week at the ICANN 46 meetings in Beijing, China, there will be a series of DNSSEC-related workshops. I (Dan York) will be there at ICANN 46 and will be participating in these sessions. If you are able to attend in person, the events will be an excellent way to learn more about DNSSEC.
NOTE: Remote participation IS possible. See the links below to listen to the live streams.
The major DNSSEC-related meetings are on Monday, April 8, 2013, and Wednesday, April 10, 2013. They are:
Monday, 8 April 2013 – 5pm-6:30pm, Auditorium – http://beijing46.icann.org/node/37065
This very basic introductory session is aimed to help attendees understand more about how DNSSEC can secure the Domain Name System and make the Internet more secure. As DNSSEC gets more widely deployed it is critical to understand how DNSSEC works. This session provides an interactive and fun way to learn how DNSSEC works, what tools are available to help and what best practices are currently being used.
Wednesday, 10 April 2013, 8:30am-2:45pm, Rainbow – http://beijing46.icann.org/node/37125
This 6+ hour workshop brings together industry leaders on DNSSEC for a series of panel discussions about the state of the art in implementing DNSSEC, current best practices, government regulations and operational practices. Sessions also include talks about the latest and innovative uses of DNSSEC. Panels at ICANN 46 include:
There will be case studies and reports on some of the latest tools. Of interest to many may be the talk from someone at CNNIC about China’s plans for deploying DNSSEC and signing .CN. I’ll be moderating the panel on “DNSSEC Innovation” as well as providing a brief tutorial about the DANE protocol and how it helps. Several of the other panelists will also be talking about DANE so it should be a good session.
I’ve attended several of these workshops now and have been very impressed by the quality of the sessions in terms of technical content. If you’re at all interested in DNSSEC, I really can’t recommend the event strongly enough. In full disclosure, I joined the Program Committee for this ICANN 46 workshop, so I’m a wee bit biased… but it also means I’ve seen many of the proposals as well as the completed slide decks – and I can say that there will be some excellent sessions there.
On Monday evening, there will also be an informal gathering of people involved with implementing DNSSEC to discuss and exchange information about DNSSEC implementations. As noted in the email announcement, you need to RSVP by Thursday, April 4, as it is being held at a local restaurant and a count of attendees is needed.
In looking over the ICANN 46 schedule, another meeting I will probably attend is the “Joint DNS Security and Stability Analysis Working Group (DSSA)” on Thursday, April 11, 2013. While it is not specifically about DNSSEC, it relates to “DNS security” in general and I would think it should be a rather interesting session given the recent DDoS attacks going on that are using DNS amplification.
If you are going to be at ICANN 46 and would like to meet with me to talk about DNSSEC, IPv6, routing resiliency or just Deploy360 in general, please feel free to drop me a note or find me in one of these sessions mentioned here.
Apr 01
