IETF Open Internet Standards Technology

El IETF habla en español

Rumbo al encuentro IETF 95, que se concretará del 3 al 8 de abril en Buenos Aires y será el primero en la historia en realizarse en Latinoamérica, apareció el IETF Journal en español.

El boletín resume las alternativas del IETF 93, realizado en Praga y profundiza sobre los principales temas en los que está trabajando el IETF actualmente.

El Journal publicado en español incluye un informe especial sobre la sesión de preguntas y respuestas en vivo con Edward Snowden que tuvo lugar a través de video antes de la reunión Nº 93.

Otros artículos de la publicación tratan sobre: el trabajo para simplificar tecnologías de seguridad en Internet, el mundo de NETCONF y YANG, el IETF Hackathon, el modelado de redes basado en Internet y las ideas de la comunidad para mejorar los programas educativos y de mentores, entre otros.

Para completar el documento, se pueden leer interesantes columnas de los presidentes del IETF, el IAB y el IRTF.

Para aquellas personas que asistirán al IETF 95 en Buenos Aires en el mes de abril, este documento es de lectura obligada. Otras fuentes en español que los interesados podrán consultar son:

Link de descarga IETF Journal en español:

IETF Open Internet Standards

Archiving IETF 93 – Watch/Listen/Learn It All Again!

Perhaps you read our Rough Guide to IETF 93 and the individual blog posts on topics that are important to us here at the Internet Society. Specifically:

But there’s nothing quite like seeing the IETF in action for yourself. You can go re-live the entire IETF experience, as all the slides and video archives are now available.

All the IETF Presentations

Just want to see the slides from the Working Groups and BoFs? Check out all the Chair Reports, slides, and other meeting materials at:

All the IETF Video Archives

Want to watch full sessions in all their glory? Meetecho was on hand to stream and record every single session in Prague. See the chairs, presenters, slides, and audience Q&A lines all in one view at:

The ISOC@IETF Briefing Panel

Not part of the official IETF agenda, our traditional Tuesday lunchtime briefing panel this time was on “Tackling Connectivity Diversity: Protocol Challenges for Constrained Radio Networks and Devices.” You can see the slides and watch the video archive of this session at:

(Note that we had some problems with the live stream in the beginning, and will be uploading a better quality video later this week.)

Remote Participation at IETF 94 in Yokohama

Remote participation options get better and better with every IETF. While most of the work still gets done on mailing lists, there are many valuable discussions that take place during the three in-person meetings each year. Even if you can’t make it to Yokohama for IETF 94, please watch this blog for our Rough Guide posts and the Remote Participation section of the IETF 94 website so you can be there virtually.

Plus, you can always follow us on social media as we lead up to Yokohama and once we’re onsite. Follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, or via RSS for information as we get closer.

What Else?

Finally, a question for you: What else can we at the Internet Society do to help? Are the Rough Guides useful? Is there some other topic you wish we would cover? What other comments, questions, or concerns do you have? We’d love your feedback!

Building Trust IETF Privacy

Edward Snowden Highlights Identity and Privacy at IETF 93

Sunday night, a group of IETF 93 attendees organized an unofficial, but unique event[1]. Edward Snowden was a surprise (remote participant) guest in a question and answer session after a screening of the documentary Citizenfour. It was movie night at the IETF – a first in all my many years in this community.

The obvious highlight of the evening was the live discussion with Mr. Snowden. It was both interesting and inspirational, especially through the lens of our ISOC work. It included topics ranging from ownership of the Internet to the vital role of specific technologies in improving privacy. All of the discussion was framed in terms closely aligned with our ISOC mission that “the Internet is for everyone” and a safe Internet promotes human rights.

Mr. Snowden discussed who the Internet is for and who controls it. He stated that “governments or countries don’t own the Internet, the public does.” He called on the community to make the Internet safe for everyone all the time, and not to allow others to determine who is safe and who is not. He reminded the IETF that users of the Internet are the ultimate customers of our products. “We should ensure our protocols follow users’ intent.”

Moving on from general topics, the discussion dove into specific technical questions. Middleboxes in particular were a frequent target of criticism with statements like “every middlebox is an increased attack surface.” He talked about the need to secure metadata along with content reminding us of the vital information included in metadata. It is well past time for emerging protocols to properly address the collection and sharing of unnecessary information.

Of particular interest to our work here at ISOC, Mr. Snowden talked about the importance of identity in this space. He talked about the need for anonymous and pseudonymous communications and the ability to separate identity from personas.

Moving further down into the technical details, there was a discussion about IEEE 802 MAC addresses and their role in tracking. Juan Carlos Zuniga mentioned the Wi-Fi privacy experiment that has been conducted at the last few IETFs which has resulted in an IEEE 802 project to define MAC address privacy. Mr. Snowden supported the work by stating, “Burned in long lasting hardware addresses are extremely dangerous.”

As the session was wrapping up, Snowden specifically called out the Cryptech effort as “awesome.” This is an activity that was initiated by conversations within the IETF community to develop an open source hardware crypto module developed in a transparent manner. In fact, just prior to the IETF there was an open workshop on cryptech where participants could install the prototype and use it to sign a DNS zone.

There were standing ovations at the beginning and end and several bouts of spontaneous applause from the appreciative audience. In my decades of IETF participation, I must say it was a first.

Special kudos to Mark Nottingham who arranged the screening, and Daniel Kahn Gillmor who arranged for Edward Snowden’s appearance. You can read more about Mark’s thoughts on the event in his own words by reading his “Snowden Meets the IETF” blog post.

Thank you for a fascinating and inspirational beginning to this week’s IETF.

[1] Editorial note: To explain a bit more, a group of individuals attending IETF 93 got together, requested meeting room space,paid for the screening of the movie and invited people to attend. This was not an official IETF activity although it was at the IETF 93 venue.

Building Trust Identity IETF Privacy

Rough Guide to IETF 93: Trust, Identity, and Privacy

Wrapping up the series of Rough Guide posts for IETF 93 is our focus on Trust, Identity, and Privacy. ISOC has been working over the past six years in these areas, and each subsequent IETF has seen advancing work and progress being made on multiple fronts. IETF 93 is no exception. During IETF 92, I mentioned a new mailing list that was created to discuss vectors of trust, a potential replacement for NIST SP 800-63. For this meeting, there has been a preliminary draft published (, and an informal meeting is being organized to discuss it. The meeting will be held on Wednesday, 22 July 2015 at 7:45 pm in the Florenc Room. The impetus for this mailing list came out of an ISOC-sponsored workshop this past September. It is hoped that these discussions will lead to further consensus on concepts around trust and levels of assurance. Monitor the mailing list for details. This is a great opportunity to get involved in a potential IETF activity at a very early stage.

Next, the W3C Privacy Interest Group (PING) ( will again be meeting face-to-face alongside IETF on Thursday, 23 July 2015 in the Rokoska room between 11:30 and 13:00. The main topic will be the draft TAG privacy and security questionnaire: Please join the meeting if you have an interest in privacy on the Web and would like to help develop better privacy features in Web standards.

As for the IETF working groups, there are several ongoing working groups addressing relevant topics in this space. We are particularly interested in a number of activities around the Web PKI at this meeting. First, there is a new draft outlining both the technical and non technical issues associated with the current web pki system. ( This draft will be considered within the context of the IAB Security and Privacy Program. There has also been interest expressed in the draft outside the IAB, so I look forward to some quality hallway conversations on this document.

The newly formed Automated Certificate Management Environment (acme) working group is working to lower the barrier to deployment of certificates for the Web PKI. In particular, the acme working group is looking for ways to automate certificate issuance, validation, revocation and renewal. The agenda for this meeting includes the protocol, use cases, and suggested changes to JWS Signing Input Options.

Certificate Transparency continues to show promise as one mechanism to improve trust in the infrastructure. The web PKI certificate infrastructure continues to be a source of trust related operational issues in the Internet. The primary effort of the trans (Public Notary Transparency) working group is the generation of a standards track version of the experimental RFC 6962 on Certificate Transparency. The primary focus of this week’s discussion will be resolution of issues on the update to RFC 6962. Additional topics for this week’s agenda include a threat analysis, client behavior, and the gossip protocol.

Finally, a rough guide entry doesn’t seem complete without mention of the oauth WG. The oauth (Web Authorization Protocol) working group has a full agenda for its Wednesday evening meeting based around its continuing work on proof-of-possession security assertions, token introspection, and token exchange among others.

As you can see, the IETF is devoting a significant amount of time and energy on efforts related to trust, identity, and privacy. There is plenty to follow and contribute to in this space.

Related Meetings, Working Groups, and BOFs at IETF 93:

ace (Authentication and Authorization for Constrained Environments) BOF
Wednesday, 22 July 2015; 0900-1130, Karlin I/II

acme (Automated Certificate Management Environment) WG
Thursday, 23 July 2015; 1520-1720, Congress Hall III

oauth (Web Authorization Protocol) WG
Wednesday, 22 July 2015, Athens/Barcelona

trans (Public Notary Transparency) WG
Thursday, 23 March 2015, 1740 – 1910, Karlin III

Follow Us

There’s a lot going on in Prague, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see

Building Trust IETF Improving Technical Security Open Internet Standards Privacy Technology

Rough Guide to IETF 93: Strengthening the Internet

Strengthening the Internet and encryption continue to be active areas for the IETF community. The news stories related to encryption just seem to keep coming. Now some governments are even considering requiring key escrow or banning encryption outright. The stakes continue to rise in this discussion. In this section of the Rough Guide, we will focus on CrypTech, the IAB Privacy and Security program, the Crypto Forum Research Group, and a few relevant IETF work groups happening at IETF 93 in Prague next week.

First, CrypTech (website:; wiki:; mailing list: is a project to create an open hardware cryptographic engine developed in a transparent manner. While this project is technically outside the scope of the IETF, it was originally started with the support of IETF and IAB leadership. CrypTech is making excellent technical progress, but it needs to establish more robust and stable funding.

At IETF 93, there will be several opportunities to learn more about the CrypTech project and to get involved. First, there will be a hands-on workshop on Saturday, 18 July, to learn more about the current state of the project. A detailed agenda is available here: ( CrypTech will also be an agenda item in the saag and cfrg meetings mentioned below. This is an interesting project with great potential and many opportunities to participate and contribute.

Moving on, the Internet Architecture Board (IAB,, through its Privacy and Security Program ( is continuing to work on the topic of confidentiality. A document on “Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement” ( has been approved and is in the final steps of publication. The program is now working on a mitigations draft entitled “Confidentiality in the Face of Pervasive Surveillance” ( Now is an excellent time to find some of the program participants and discuss this document with the authors.

While this is not an IETF 93 activity, the IAB is also working with the GSMA to plan a workshop on Managing Radio Networks in an Encrypted World (MaRNEW). There is still time to put together position papers if you feel you have something to contribute in this space. ( The workshop is planned for 24-25 September in Atlanta, GA, and there should be interesting results to review in time for IETF 94.

Next, the Internet Research Task Force (IRTF) Crypto Forum Research Group (cfrg, continues to focus on use of cryptography for IETF protocols. It has been focusing extensively on the selection of new elliptic curves for use in IETF protocols, and rough consensus on this topic is documented in “Elliptic Curves for Security” ( Hot topics at the meeting this week will include pake schemes, extended hash-based signatures, and elliptic curve signatures. Anyone interested in the future direction of cryptographic curves and algorithms would be well served to follow these discussions.

There are also a number of IETF working groups progressing efforts related to strengthening the Internet that will be meeting this week. In this post I will focus on tls and uta. Other working groups also working on strengthening the Internet are discussed in the “ DNSSEC, DANE, DPRIVE, and DNS Security” and the soon-to-come “Trust, Identity, and Privacy” Rough Guide posts.

The Transport Layer Security (tls) working group is actively working on an update to the TLS protocol ( This is a very active working group with a mailing list that is not for the faint of heart. There will be two sessions and a total of 4.5 hours of meeting time devoted to progressing the agenda. Topics for IETF 93 include known configuration mechanisms, 0-RTT, PSK and resumption, client authentication, and cipher suites among others.

Since the last IETF meeting, the Using TLS in Applications (uta) working group has published two RFCs; RFC 7525 ”Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)” ( and RFC 7590 “Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)“ ( This meeting will focus on enhanced email privacy and TLS/DTLS security modules.

Finally, I’d like to give a quick plug for the Security Area Advisory Group (saag) session. This is an excellent way to get a quick view of some of the security-related conversations ongoing in the IETF. This week’s session will include CrypTech along with the state of transport security in email and http. All in all, there is much to see and do in the world of Strengthening the Internet for IETF 93.

Related Meetings, Working Groups, and BoFs at IETF 93:

cfrg (Crypto Forum Research Group)
Wednesday, 22 July 2015, 1300-1530, Athens/Barcelona

tls (Transport Layer Security) WG
Tuesday, 21 July, 2015, 1520-1720, Congress Hall III,
Wednesday, 22 July 2015, 0900-1130, Grand Ballroom

uta (Using TLS in Applications) WG
Tuesday, 21 July 2015, 1740-1840, Congress Hall III

saag (Security Area Advisory Group)
Thursday, 23 July 2015, 1300-1500, Congress Hall II

Follow Us

There’s a lot going on in Prague, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see

IETF Internet Governance Open Internet Standards

Rough Guide to IETF 93: The IANA Transition

The 93rd meeting of the Internet Engineering Task Force (IETF) kicks off next week (July 19-24) in Prague to discuss a variety of issues, ranging from security to privacy to DNSSEC and IPv6. The IANA stewardship transition process, which has been underway since March 2014, is also part of the IETF’s agenda.

The IETF has a vested interest in a successful IANA transition process. Being one of the ‘directly’ affected customers of IANA, the IETF is responsible for developing Internet protocols and policy for those protocols. As such and at the request of the IANA Coordination Group (ICG), the IETF was the first community to submit its proposal back in January 2015. Since then, the IETF community has been closely following the process and has consistently talking with both the numbering and the names’ community.

Last month, during ICANN’s 53rd meeting in Buenos Aires more progress was made. The names’ community successfully concluded its proposal and submitted it to the ICG. Jari Arkko’s blog update from ICANN provides a very good overview of what took place and what are the next steps for the ICG and the stewardship transition process in general.

After the ICANN meeting, a new timeline was also posted. Responding to a request by Assistant Secretary Larry Strickling, the ICG outlined the three phases they anticipate will be required for the full transition to take place. Taking into consideration all the various components and dependencies – i.e. issues of accountability for the names’ part – the ICG anticipates that the earliest the transition could be completed in the July 2016 timeframe.

Finally, and as the accountability discussions continue with urgency, the ICG has announced that the proposal to transition the stewardship of the IANA functions will be out for public comment July 31 to September 8 (approximately).

The IANA transition discussion is scheduled to be discussed in the Thursday, 23 July, afternoon session.

Related Working Groups and BoFs at IETF 93

ianaplan (Planning for the IANA/NTIA Transition)
Thursday, 23 July 2015, 15:20-17:20, Congress Hall II

Follow Us

There’s a lot going on in Prague, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see

IETF Open Internet Standards Technology

Rough Guide to IETF 93: Internet Scalability & Performance

In this post I’ll shine a light on some of the Internet Engineering Task Force (IETF) and Internet Research Task Force (IRTF) efforts underway to explore and address more sophisticated ways to use available bandwidth, improve Internet performance, and otherwise efficiently get Internet content to where it needs to be. These groups will all be meeting as part of the IETF 93 meeting in Prague next week.

On the Sunday of IETF meetings, the Education team organises various tutorial sessions, and IETF 93 will include an ‘Introduction to Performance Measurements and Monitoring’ that will provide an overview of IETF work on the topic.

Internet performance is to a large extent governed by the way transport protocols operate, and the tcpm WG will be meeting to discuss proposed new functionality to improve and enhance the working of TCP, the main transport protocol used on the Internet today. One of the advances developed in the tcpm WG, TCP Fast Open, was included in recent announcements by Apple that should provide a big boost to networking performance in their products.

Multipath TCP is another IETF protocol now seeing more widespread deployment in operational networks, and the meeting in Prague will include updates on implementation experiences and new work to use and extend Multipath TCP.

Getting new code deployed in networking stacks is often hard because of uncertainties about how existing hardware and software on the network will react. After a successful Bar BoF meeting in Dallas, the proposed How Ossified is the Protocol Stack? (hops) research group will meet in Prague to discuss measurement techniques and data sources that could help make better engineering decisions to work around some of the ossification in the protocol stack. The hope is that techniques similar to ‘happy eyeballs’ for IPv6 can be used to support deployment of new transport features and protocols.

Packet networks give rise to transient congestion by design and several groups are meeting to discuss different aspects of congestion control and avoidance (aqm and rmcat). For regulators, being able to monitor the performance of networks, and the extent to which congestion or other factors are impacting consumers’ experience of the network is very important. The lmap working group is meeting in Prague to advance their important work on standardizing a large-scale broadband performance measurement infrastructure.

Related Working Groups and BoFs at IETF 93

iccrg (Internet Congestion Control Research Group)
Wednesday, 22 July 2015, 1550-1720, Congress Hall I

mptcp (Multipath TCP) WG
Tuesday, 21 July 2015, 1300-1500, Berlin/Brussels

tcpm (TCP Maintenance and Minor Extensions) WG
Wednesday, 22 July 2015, 1300-1530, Karlin I/II

hopsrg (Proposed How Ossified is the Protocol Stack?) RG
Friday, 24 July 2015, 0900-1130, Congress Hall III

aqm (Active Queue Management and Packet Scheduling) WG
Monday, 20 July 2015, 1850–1950, Congress Hall I

lmap (Large-Scale Measurement of Broadband Performance) WG
Monday, 20 July 2015, 0900-1130, Athens/Barcelona

rmcat (RTP Media Congestion Avoidance Techniques) WG
Monday, 20 July 2015, 0900-1130, Congress Hall II

Follow Us

There’s a lot going on in Prague, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see

Domain Name System Security Extensions (DNSSEC) IETF Improving Technical Security Privacy

Rough Guide to IETF 93: DNSSEC, DANE, DPRIVE and DNS Security

Wow! There is a crazy amount of DNS activity happening at IETF 93 next week in Prague! Beyond the usual working groups we follow such as DNSOP and DANE, there are a wide range of other groups where DNS security and privacy are under discussion. It’s going to be a VERY busy week for all of us involved with DNS!  (And, there’s also the IETF 93 Hackathon starting on Saturday and Sunday where several of us will be working on code related to DNSSEC, DANE and more.)

Let’s walk through the week…

NOTE: If you are unable to attend IETF 93 in person, there are multiple ways to participate remotely and listen to these sessions. Also, all times below are Central European Summer Time (CEST) which is UTC+2.

DNS Operations (DNSOP)

Monday turns out to be a big DNS day with DNSOP starting off the back-to-back marathon in the 15:20 to 17:20 block. The major piece of DNSSEC-related work will be two different drafts from Joe Abley and Warren Kumari around publication of DNSSEC trust anchors. Both of these are work items out of the ongoing work around how we successfully perform a key rollover with critical DNSSEC keys such as the Key Signing Key at the root of DNS. After that, DNSOP will continue the ongoing discussion related to “special-use” names which, while not directly connecting to DNS security, should still be quite interesting.

Domain Boundaries (DBOUND)

Next up on Monday in the 17:40 to 18:40 session will be the DBOUND group. This group is look at the boundaries used to determine when an address being requested in DNS is “private” versus “public”. This impacts security policies.

DNS-based Authentication of Named Entities (DANE)

Finally in the 18:50 – 19:50 slot on Monday, the working group looking after the DANE protocol will be meeting to focus on three drafts:

  • TLS extension for DNSSEC
  • Client Certificates in DANE TLSA Records
  • DANE and SMIME

Given the amount of activity with using DANE in email communication these days, I expect there to be some good discussion.

Tuesday is TLS Day

Tuesday turns out to be “TLS Day” with both the core Transport Layer Security (TLS) and the Using TLS in Applications (UTA) groups meeting. Because of the connection to DANE, the TLS meeting is important to understand in terms of the evolution of the protocol with TLS 1.3 and beyond. There is packed agenda for the TLS WG and it spans two days – both Tuesday and Wednesday. If time permits, there is also a specific presentation for the group about DNSSEC and DANE validation chains. The UTA working group has a lighter agenda this time, but again is something we’ll follow because of the connection to TLS and DANE.

DNS Service Discovery (DNSSD)

Wednesday morning will begin with the 9:00-11:30 session having both the second session of the TLS Working Group and also the only session of DNSSD. The key reason to mention the group this time is that the DNSSD agenda includes a discussion of the threat model and security considerations for multicast DNS (mDNS).

Crypto Forum Research Group (CFRG)

Wednesday afternoon from 13:00-15:30 brings the meeting of the CFRG which has nothing specific to DNS security on its agenda, but there looks to be a lengthy discussion planned about the use of elliptic curve cryptography (ECC). This is something we’ve certainly been looking at within the DNSSEC space with regard to using ECDSA and other algorithms for DNSSEC signatures. It will be interesting to see what emerges out of this discussion in terms of future directions for IETF crypto algorithms.

Extensible Provisioning Protocol Extensions (EPPEXT)

In the last session slot on Wednesday from 17:40-19:40 the EPPEXT group will be meeting to discuss extensions to the EPP protocol used between DNS registrars, registries and similar entities.  An agenda has not yet been published but several of the past documents have related to exchanging DNSSEC-related information.

Thursday is for TRANS

The only working group we’re tracking on Thursday related to DNS or TLS is the Public Notary Transparency (TRANS) group meeting in the 17:40-19:10 block at the end of the day. No agenda yet, so it’s not clear what will be discussed.  Certificate Transparency is one of the number of technologies that are working to make TLS more secure and so this remains of interest.

DNS PRIVate Exchange (DPRIVE)

In the unenviable slot of Friday morning from 9:00-11:30 will be the third meeting of the DPRIVE Working Group that is chartered to develop: “mechanisms to provide confidentiality to DNS transactions, to address concerns surrounding pervasive monitoring.” A great bit of work has been going on and the DPRIVE agenda shows discussion being planned for several possible solutions to provide this level of privacy and confidentiality.

It will be a busy week – but the outcomes of all these sessions should go far to make the DNS – and the overall Internet – more secure!

P.S. For more information about DNSSEC and DANE and how you can get them deployed for your networks and domains, please see our Deploy360 site:

Relevant Working Groups at IETF 93:

DNSOP (DNS Operations) WG
Monday, 20 July 2015, 1520-1720 CEST, Congress Hall II

DBOUND (Domain Boundaries) WG
Monday, 20 July 2015, 1740-1840 CEST, Athens/Barcelona

DANE (DNS-based Authentication of Named Entities) WG 
Monday, 20 July 2015, 1850-1950 CDT, Venetian

EPPEXT (Extensible Provisioning Protocol Extensions) WG 
Wednesday, 22 July 2015, 1740-1940 CEST, Karlin III

DPRIVE (DNS PRIVate Exchange) WG
Friday, 24 July 2015, 0900-1130 CEST, Karlin I/II

Follow Us

There’s a lot going on in Prague, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see

Deploy360 Domain Name System Security Extensions (DNSSEC) Events

IETF 93 Hackathon July 18-19: DNSSEC, DANE, DPRIVE and DNS Security

IETF HackathonHow can we improve the tools and services that use DNSSEC or DANE?  How can we make DNS more secure and private? (And, why spend a beautiful weekend exploring Prague when we could be inside a hotel conference room working on code???) For a number of us, we’re going to be spending this coming weekend, July 18-19, looking to answer those questions through writing code and changing/updating software as part of the IETF 93 Hackathon.  More info is at:

As IETF Chair Jari Arkko wrote about on the IETF blog, these hackathons are a way to bring “running code” back into the IETF meetings – and also just a great way to advance the deployment and usage of IETF protocols.  They are also just a fantastic way to strengthen the relationships between members of the IETF community.

I’ll be there as one of the “champions” of DNSSEC / DANE / DPRIVE (DNS confidentiality/privacy) along with Allison Mankin, Benno Overeinder, Sara Dickinson and Daniel Kahn Gillmor.  A number of others from within the DNS community have also signed up to join in to the effort – and we’re hoping to attract some of the other participants as well.

On the wiki page listing the technologies, we wrote this for some of the ideas:

  • Contribute to access of end-systems to new developments in DNS
  • Protocols: DANE support for webmail, DNS-over-TLS (application uses), DNS-over-DTLS (stack and uses), TLSA client certs, client privacy election for EDNS client-subnet, getdns language bindings, etc.
  • Tools: portable tool for creating and adding DANE RR’s to zones, changes to existing tools to support new crypto algorithms, etc.
  • Measurement: New tools or sites for measuring DNSSEC or DANE deployment

We’ve had some other ideas, too… we’ll see what we come up with!  (And you’re welcome to send me your ideas for tools you’d like to see!)  I’m personally interested in expanding some of the metrics… and I’m also interested in anything that expands the usage or support of the ECDSA algorithm (I’m thinking more about … what interfaces could be extended to add ECDSA support?)

I’ll post a report back here on the site once the hackathon is over.  If you are going to be at the Hackathon at IETF 93, please do consider joining with us!

P.S. And if you want to get started with DNSSEC and DANE, please see our Start Here page!

IETF Improving Technical Security Open Internet Standards Technology

ISOC Rough Guide to IETF 93: Routing Resilience

There is considerable work underway across several IETF working groups to ensure the Internet’s routing infrastructure is more secure and resilient in both the short and long runs. Many of these groups will meet in Prague at IETF 93 next week.

Let me begin, as always, by listing the WGs where security and resilience issues of the global routing system are discussed and solutions are developed. The groups meeting at IETF 93 are: Secure Inter-Domain Routing (SIDR, WG, Global Routing Operations (GROW, WG, Inter-Domain Routing Working Group (IDR, WG.

Secure Inter-Domain Routing

The SIDR WG focuses on securing inter-domain routing. The overall architecture is based on a Resource PKI (RPKI), which adds an authentication framework to BGP and is an important component of BGP security extensions – BGPSEC, also developed in SIDR WG. This is a key technology for improving trust in the routing infrastructure.

A lot of work has been done, and there are quite a few operational deployments. This results in refinements of the protocols and fixing some of the issues. This is a normal cycle of protocol maturity, when operational experience is fed back into the protocol development, leading to improvements.

For more than a year, participants have been discussing an issue of potential operational fragility in the management of certificates in the RPKI in response to the movement of resources across registries. There is a draft, “RPKI Validation Reconsidered” (, that proposes changes to the certificate validation procedure. While the issue is real, one of the problems is that the implementation of resource transfers in RPKI is not documented and the implications are not clear. To address this, a new draft “Resource Transfer in the Resource Public Key Infrastructure” ( has been published and is under discussion.

There are also other types of mistakes a Certificate Authority (CA) or repository operator may make. For example, they may be subject to legal measures that compel actions resulting in generating “bogus” signed objects or removing legitimate repository data. Draft “Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)” ( attempts to catalogue such actions and analyze the implications. It will be discussed in Prague.


There are some movements in the BGPSEC area, too. The BGPSEC protocol specification is in the Working Group Last Call (draft-ietf-sidr-bgpsec-protocol-11). People found a few omissions that are easy to fix, like insecure Address Family Identifiers (AFI) that allow the attacker to confuse IPv4 and IPv6 prefixes that look the same on the wire.

Extra care needs to be taken when making a significant reconfiguration, like Autonomous System (AS) migration when networks are merged, for example. A draft “BGPSec Considerations for AS Migration” ( discusses this for a common method of AS migration within the BGPSEC protocol.

As a matter of fact, this common method is not trivial, requires some BGP features that are not formally part of the BGP4 protocol specification, and may be vendor-specific in exact implementation. Absent these features, an ISP would be required to coordinate an ASN change with, in some cases, tens of thousands of customers. In particular, as each router is migrated to the new ASN, to avoid an outage due to ASN mismatch the ISP would have to force all customers on that router to change their router configurations to use the new ASN immediately after the ASN change. This is addressed in the draft “Autonomous System Migration Features and Their Effects on the BGP AS_PATH Attribute” ( This draft is being discussed in the IDR WG and is largely parallel to one of the SIDR WG I just mentioned, although addressing different aspects.

Speaking of network reconfigurations and maintenance, one very important requirement is operational continuity, which applies to the two drafts I just mentioned. Even if an ISP has redundant connections, simply taking down or even bringing up a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence. This is not satisfactory for applications like Voice Over IP, online gaming, or virtual private networks (VPNs). Therefore, a solution is needed for the graceful shutdown of a (set of) BGP session(s) in order to limit the amount of traffic loss during a planned shutdown. Such a solution is described in a draft “Graceful BGP session shutdown” (draft-ietf-grow-bgp-gshut). This draft is now expired because of dependencies on other drafts, not because of the loss of interest, but it is being discussed in the GROW WG.

Routing System Operational Issues

In general, the GROW WG focuses on operational problems associated with the global routing system, such as routing table growth, the effects of interactions between interior and exterior routing protocols, and the effect of operational policies and practices on the global routing system, its security and resilience.

One of the items that originally emerged in the SIDR WG is the so-called “route-leaks”. Simply put, this describes a violation of a “valley-free” routing when, for example, a multi-homed customer “leaks” an announcement from one upstream provider to another one. Since usually customer announcements have the highest priority, unless precautions are taken this results in traffic being passed from one provider to another, bypassing the customer. This sets the stage for a potential Man in the Middle (MITM) attack. Unfortunately none of the solutions developed in the SIDR WG protect against this type of attack, simply because BGP does not have the ability to signal relationships like customer-provider.

In “Methods for Detection and Mitigation of BGP Route Leaks” ( the authors suggest an enhancement to BGP that would extend the route-leak detection and mitigation capability of BGPSEC. The draft proposes a new Route Leak Protection (RLP) field that operators should set when announcing routes to their customers and peers. Receiving a BGP update that has the RLP field set to ’01’ (‘Do not Propagate Up’) for one or more hops in the AS path from a customer or a peer will indicate that such announcement represents a “route leak” and should be treated accordingly (e.g. by preferring a valid signed update from a peer or an upstream provider over the customer’s update).

Massive DDoS attacks targeting Internet Exchange Point (IXP) members may cause congestion of their peering port(s). In order to limit the impact of such a scenario on legitimate traffic, IXPs adopted a feature called blackholing. A member may trigger blackholing via BGP through the route server. The concept of blackholing at IXPs is similar to blackholing in iBGP scenarios [RFC3882] and expands the concept of Remote Triggered Black Hole (RTBH) filtering [RFC5635]. A draft “BLACKHOLEIXP BGP Community for Blackholing at IXPs” ( proposes to define a well-known transitive BGP community, to allow an operator to indicate to the IXP route server which routes should be discarded on the switching fabric of the IXP. The draft and its implications will be discussed in the GROW WG.

Related Working Groups at IETF 93

SIDR (Secure Inter-Domain Routing) WG
Friday, 24 July, 09:00-11:30, Berlin/Brussels

GROW (Global Routing Operations) WG
Monday, 20 July, 18:50-19:50, Karlin I/II

IDR (Inter-Domain Routing Working Group) WG
Monday, 20 July, 17:40-18:40, Grand Hilton Ballroom
Friday, 24 July, 11:50-13:20, Grand Hilton Ballroom

Follow Us

There’s a lot going on in Prague, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see

IETF Open Internet Standards Technology

Rough Guide to IETF 93 – Czech It Out!

It’s almost here! Starting on Sunday, 19 July, the Internet Engineering Task Force will be in Prague for IETF 93, where more than 1000 engineers will spend a week discussing the latest issues in open standards and protocols. As usual, the Internet Society is providing a ‘Rough Guide’ to the IETF via a series of blog posts on topics of mutual interest:

  • Routing Resilience and Security
  • Scalability & Performance
  • DNSSEC, DANE, and DNS Security
  • Trust, Identity, and Privacy
  • Strengthening the Internet
  • The IANA Transition

All these posts can be found, and will be archived, through our Rough Guide to IETF 93 overview page at

Here are some of the activities that the Internet Society is involved in and some of my personal highlights.

IETF Journal

Before we get to IETF 93, catch up on some of the highlights from IETF 92 in Dallas by reading Volume 11, Issue 1 of the IETF Journal. You can read all the articles online at, or pick up a hard copy in Prague. The cover article, “ 10 Years of the IETF Journal: How It Began,” continues our year-long celebration of the milestone and offers a retrospective from one of the Journal’s creators and its first editor, Mirjam Kuhne. We also have articles about the first IETF Hackathon, IAB Guidelines for Internet-of-Things Developers, a technical overview of SDN, NFV and more, and reports on ISOC Fellows, Applied Network Research Prize winners, along with the usual Chair Reports from the IETF, IAB, and IRTF Chairs.

Speaking of the IETF Journal, did you know it is now being translated into Russian? The March 2015 issue of the Журнал IETF (Инженерного совета Интернета) is available through our site and the Russian ISOC Chapter. This issue will be translated in a few weeks and linked from the main IETF Journal page.

Jonathan B. Postel Service Award

The Postel Service Award was established by the Internet Society to honor individuals or organizations that, like Jon Postel, have made outstanding contributions in service to the data communications community. During the IETF Operations and Administration Plenary from 09:00-11:30 on Thursday, 23 July, the Internet Society’s President and CEO, Kathy Brown, will present the Jon Postel award to this year’s recipient.

ISOC@IETF Briefing Panel

Internet connectivity speeds and mobile device capabilities vary across the world, but not all application or protocol developers keep that in mind. How do we address this discrepancy? Does the infrastructure need to change? Is this a temporary condition due to uneven global development? These are some of the questions we’ll discuss during the Internet Society Briefing Panel at IETF 93, entitled: Tackling Connectivity Diversity: Protocol Challenges for Constrained Radio Networks and Devices.” The panel takes place during lunch on Tuesday, 21 July. Pre-registration is required to attend this briefing panel in person, but it will also be webcast and audiocast for remote or later viewing. Register online now at



Through the Applied Networking Research Prize (ANRP, supported by the Internet Society) the Internet Research Task Force (IRTF) recognizes the best new ideas in networking, and brings them to the IETF, especially in cases where the ideas are relevant for transitioning into shipping Internet products and related standardization efforts. In Prague, two talented researchers will present during the IRTF Open Meeting on Monday, 20 July:


Right before IETF 93, the IETF is holding a Hackathon to encourage developers to discuss, collaborate and develop utilities, ideas, sample code and solutions that show practical implementations of IETF standards. The Hackathon is free to attend but limited to 100 attendees. This is the second time the IETF has held a Hackathon before a meeting, and I hope it is a tradition that continues. Read our article about the last Hackathon in the IETF Journal.


One of the week’s highlights will be the technical plenary on Tuesday, 21 July, which will feature a message from ITU Secretary General Houlin Zhao, a report on the Coordinating Attack Response at Internet Scale (CARIS) Workshop, and the technical talk on Vehicular Communications.

Another major highlight of every IETF is the new work that gets started in birds-of-a-feather (BoF) sessions. Getting new work started in the IETF usually requires a BoF to discuss goals for the work, the suitability of the IETF as a venue for pursuing the work, and the level of interest in and support for the work. There are five BoFs happening in Prague:

Follow Us

There’s a lot going on in Prague, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see

Human Rights Technology

The Science and Art of Identifying Next Generation Leaders: Some Reflections before IETF 93

For IETF 80 in 2011, the Internet Society had nearly 90 applicants for 12 available Fellows awardee slots. For IETF 93, applications increased by more than 60% to 170 applicants for 14 slots.

As awareness and corresponding demand has ballooned for future leaders in the Internet ecosystem, so clearly has the number of applicants to the Internet Society’s Fellows and other competitive leadership programmes. While demand has increased, so has the overall quality of the applicants and ultimately the selected individuals.

Three factors contribute to this increased caliber:

1. Qualified self-selection
In 2013, we initiated a self-assessment guide. Coupled with the actual selection criteria, these two documents lay out capacity and capability expectations. Before potential participants apply, they need to qualify themselves according to the criteria for these programmes. These expectations clarify required commitments before, during, and after the event. Since applying is in itself a process, we wanted to mitigate unnecessary frustration and these checklists help ensure that those who do apply have a fair shot for serious consideration.

2. A robust, diverse selection committee
The current Fellows selection committee has nine (9) standing members, many who contribute to each round and are active in IETF. The committee includes: a Chapter representative, a current ISOC Board member, active IETF participants, regional staff representatives, and former awardees. Each selection committee member brings invaluable perspective and passion. Niel Harper, the lead for ISOC’s Next Generation leaders programme, guides the process, including reviewing each application fully. A former ISOC NGLer himself, Niel is uniquely qualified in understanding what is required of Fellows to IETF and our other programmes.

3. An appreciation for the more intangible skills of leadership
While there are some straightforward criteria, such as following and contributing to IETF Working Groups and a demonstrated commitment to advancing IETF and open standards in region, we also consider some other leadership traits. Integrity, passion, and a pay-it-forward mentality all factor into the vetting process. In programmes where we have returning opportunities such as Fellowships to IETF and Ambassadors to IGF, it is particularly rewarding to see individuals awarded over time who have even more fully demonstrated the potential we initially saw. Some qualities on those who get the most out of the Fellows experience can be found here.

All that said, please join me in congratulating the latest cohort of Internet Society Fellows to IETF.

They are truly an exceptional group of technologists and we look forward to seeing their contributions to IETF and open standards this upcoming week and in the future.