Dan York

You might think the final day of IETF 90 might be a bit quieter for us… but in fact the morning session from 9:00-11:30 EDT has three sessions happening simultaneously that are related to the work we do (HOMENET, SIDR and TRANS) – and in my personal case I want to be in two separate places at the same time!  (Which I will be attempting to do via monitoring Jabber chat rooms.)   The day will actually start at 8:00am with an informal breakfast meeting of some of the folks subscribe to the DNSSEC coordination mailing list.  After that we’ll be heading into the morning session block where we’ll be choosing between the three conflicting sessions.

One of those three sessions is HOMENET, which Chris described in his Rough Guide post about IPv6:

(HOMENET) is chartered to address the challenges in the evolving networking technology within and among relatively small “residential home” networks. This work is not necessarily dependent on a specific version of IP but the thrust of all discussions within the WG is how the IPv6 protocol suite can better serve these often overlooked networks out at the consumer edge of the Internet. 

The HOMENET agenda is filled with IPv6-related drafts and discussion points… BUT… there is also a DNSSEC angle that I described in my own Rough Guide post:

the HOMENET Working Group has on its agenda two documents from Daniel Migault that that look at two different aspects of DNSSEC interaction with customer-premise equipment (CPE).  The first draft outlines an architecture in which a CPE device could manage some of its naming services and then outsource other naming services, such as DNSSEC management, to external services.  The second draft proposes new DHCP optionsthat would provide a means to update the trust anchors used in DNSSEC and also provide a way to update the time of a CPE device. These are both definitely important work as we need CPE devices to provide solid DNSSEC support if we are to get DNSSEC validation happening everywhere.

The challenge for me is that one floor down in the hotel the TRANS working group will also be talking about DNSSEC.  As I said in the Rough Guide post:

 the TRANS Working Group focused on “Certificate Transparency” (CT) will be having a discussion about whether there is a role for CT to play in logging DNSSEC information. There is not a draft associated with this idea but there was a lengthy discussion in the trans mailing list that began with a message from Nico Williams and continued on into great detail. My understanding is that the discussion will be mainly about what, if any, role CT might play with DNSSEC and DANE. Given some of the passions involved with this whole topic I expect there to be a great amount of discussion.

Meanwhile, in a room nearby to TRANS, the Secure Inter-Domain Routing (SIDR) working group that focuses on securing BGP will be meeting.  As our colleague Andrei Robachevsky wrote in his Rough Guide post about routing resiliency, there is a great amount of work happening in this group this week.  Of particular interest may be a discussion around “RPKI Revisited” led by Geoff Huston about the Resource Public Key Infrastructure (RPKI). As Andrei writes:

Perhaps a bigger change that is being discussed is related to the problem of potential operational fragility in the management of certificates in the RPKI in response to the movement of resources across registries described by the draft “RPKI Validation Reconsidered”. The problem in a nutshell is that in the current model, specified by RFC 6487, a certificate is considered invalid if a proper validation path cannot be built for all resources specified by that certificate. But in operational reality such a situation can occur, for instance, with the resource transfer, when “shrinkage” of the parent certificate will immediately invalidate the whole branch beneath, unless all subordinate certificates are also re-issued. If such a situation happens high in the hierarchy, say at the RIR level, the impact can be pretty severe. The draft also describes alternative approaches, although the focus of the discussion now is on the problem.

After those three sessions in the first meeting block, the second meeting block really has for us only the Global Routing Operations (GROW) Working Group.  The GROW agenda covers a number of routing security topics, one of which, as Andrei writes, deals with the issue of route leaks:

One of the items, which originally emerged in the SIDR WG and has now also been discussed in the GROW WG, is so-called “route-leaks”. Simply speaking, 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, if no precautions are taken this results in traffic from one provider to another bypassing the customer. This introduces the potential for a staged MITM attack. But this is an explanation in layman terms, and the group was working on nailing down the definition and the problem statement, see https://datatracker.ietf.org/doc/draft-ietf-grow-simple-leak-attack-bgpsec-no-help/.

After that, our team will be attending the regular meeting of the Internet Society Advisory Council and then will be starting the process of heading home!   As you can tell from our posts, it’s been a VERY busy – but successful – week!

If you’d like to join the HOMENET, SIDR or GROW sessions (or any of the others) remotely to hear the discussion you can follow the instructions on the IETF 90 Remote Participation page or use the “tools-style” agenda page that provides easy links to the audio stream, jabber chat room documents and more for each of the sessions.

The information about the relevant working groups today is:

HOMENET (Home Networking) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/homenet/
Documents: https://datatracker.ietf.org/wg/homenet/
Charter: https://datatracker.ietf.org/wg/homenet/charter/
(Friday, July 25, 2014, 0900-1130 EDT, Canadian)

TRANS (Public Notary Transparency) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/trans/
Documents: https://datatracker.ietf.org/wg/trans/
Charter: https://datatracker.ietf.org/wg/trans/charter/
(Friday, July 25, 2014, 0900-1130 EDT, Manitoba)

SIDR (Secure Inter-Domain Routing) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/sidr/
Charter: https://datatracker.ietf.org/wg/sidr/charter/
(Friday, 25 July, 0900-1130 EDT, Territories Room)

GROW (Global Routing Operations) WG
Agenda: https://datatracker.ietf.org/meeting/90/agenda/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/
(Friday, 25 July, 1150-1320 EDT, Ontario Room)

For more background on what is happening at IETF 90, please see our “Rough Guide to IETF 90″ posts on the ITM blog:

• Rough Guide to IETF 90: DNSSEC, DANE and DNS Security (see also our Deploy360 post on the topic)
• Rough Guide To IETF 90: IPv6 Is Everywhere, eh?
• ISOC Rough Guide to IETF 90: Routing Resilience
• Overview: ISOC Rough Guide to IETF 90: Toronto, Eh?

If you are here at IETF 90 in Toronto, please do feel free to say hello to a member of the Deploy360 team.  And if you want to get started with IPv6, DNSSEC or one of our other topics, please visit our “Start Here” page to find resources appropriate to your type of organization.