Category: IETF87

“Rough Guide To IETF 87″ Now Available – IPv6, DNSSEC, Routing and much, much more…

IETF LogoNext week is the 87th meeting of the Internet Engineering Task Force (IETF), taking place this time in Berlin, Germany, and it will be an incredibly busy week as something like 1,200-1,500 engineers gather in a hotel meeting space to debate and discuss various topics and create the open standards that power the Internet.  There are many different working groups meeting during the week and the IETF 87 agenda can seem a bit overwhelming.  To help with that, as we’ve done in the past, the Internet Society has published our “Rough Guide to IETF 87″ available at:

http://www.internetsociety.org/rough-guide-ietf87

This document reflects our (Internet Society) interests and what we see as the important topics related to the technology priorities we have an an organization.  The working groups and events listed are ones where we have Internet Society staff participating or where the topic being covered is one of our priorities.

For instance, within our team here at Deploy360, we’ll be there in Berlin at the working groups related to:

  • IPv6
  • DNSSEC
  • Routing resiliency and security

Most of which, but not all, are captured in the Rough Guide.  As we noted in an earlier post about DNSSEC activities, there are two groups focused on DNSSEC and DANE that are of great interest to us.  There are a wide number of IPv6-related groups in which we’ll be participating and several groups related to routing resiliency and security.

If you are reading this page here on our Deploy360 site, hopefully the Rough Guide will help you understand where we will be spending our time.

There are, of course, a great many other working groups meeting next week at IETF 87 that are doing outstanding work in Internet infrastructure, applications, routing, security, real-time communications, network operations and so much more.  The full agenda for IETF 87 is an amazing list of all the great open standards work happening across the IETF!

NOTE: If you unable to attend IETF 87 in Berlin in person, there are numerous methods of remote participation that you will allow you to listen to what is going on and to provide comments.

2 DNSSEC / DANE Sessions Next Week At IETF 87 In Berlin

IETF LogoNext week is the 87th meeting of the Internet Engineering Task Force (IETF)  in Berlin, Germany, and there will be two working groups meeting that are related to DNSSEC on the agenda:

DNSOP

The DNSOP (DNS Operations) Working Group will meet on Thursday, August 1, from 1520-1650 (Berlin time) in the Bellevue room.  There are 3 major items on the DNSOP agenda, but the one of strong importance related to DNSSEC is the discussion about how to communicate that there has been a change in the Key Signing Key (KSK) from a child zone up to a parent zone.  In other words, when you create a new KSK for your child zone, can we get an automated way to communicate the existence of this new KSK to the parent zone so that a DS record can be created and the global chain of trust can be updated?

Somewhat ironically, I experienced this precise issue myself last week when, during the DNSSEC Workshop at ICANN 47, a KSK on one of my personal zones expired.  The company providing DNS hosting for that domain automatically generated a new KSK, but they have no way of alerting the parent zone (.ORG in this case) that a new DS record is ready for upload.  I had to login to the web interface for my registrar and copy/paste the DS record from the web interface of my DNS hosting provider.  Meanwhile, my domain was failing validation.

There are two different proposals for mechanisms to automate this process.  Warren Kumari, Olafur Gudmundsson and George Barwood submitted draft-kumari-ogud-dnsop-cds that proposed the creation of a new “CDS” record type in DNS.  Essentially, the parent zone will periodically poll the child zones and if a new CDS record is found the parent zone will update the DS record for the zone.  Separately, Wes Hardaker developed draft-hardaker-dnsop-csync providing a similar but broader mechanism for synchronizing child and parent zones. This draft involves the creation of a “CSYNC” record type in DNS which tells the parent zone which records in the child zone need to be updated in the parent zone.  Wes originally wrote the draft to look at how to synchronize NS records and their associated A and AAAA records (what we often call “glue” records) between child and parent zones but then added support for DS and DNSKEY records to stimulate further discussion.

At DNSOP there will be a joint presentation about the two drafts with an interest in looking at “where do we go from here”.  It should be an interesting discussion and if you are unable to attend in person you can listen to the remote audio stream at the specified time.

DANE

Right after DNSOP, the DANE Working Group will meet on Thursday, August 1, from 1700-1830 (Berlin time) in the Potsdam 1 room.  With RFC 6698 now specifying the DANE protocol the WG is focused more on how DANE will be used by various services.  The agenda has not yet been posted, but there has been active discussion on the DANE mailing list about drafts relating to using DANE with email (both SMTP and S/MIME) and with voice-over-IP (SIP) as well as with OpenPGP and OTR.  As someone who sees DANE as a powerful reason to deploy DNSSEC, I’m very much looking foward to the discussion in this group and to seeing where DANE is going.

If you are unable to attend IETF 87 in person, you will be able to listen remotely to the DANE working group at its specified time.