Deploy360 IETF IPv6 Transport Layer Security (TLS)

Deploy360@IETF98, Day 2: IoT, IPv6, TLS & SIDR

Chicago Skyline aerial view with road by the beach

Tuesday is another busy day at IETF 98 in Chicago with sessions related to pretty much the whole Deploy360 portfolio. Each day we’re bringing you blog posts pointing out what Deploy360 will be focusing on.

The morning session sees TLS busy with a significant update to the TLS protocol which is now in Last Call. There’s a companion update to DTLS, and also on the agenda are drafts on a DANE Record and DNSSEC Authentication Change Extension for TLS, certificate compression, and delegated credentials. So it looks to be a very significant meeting.

Running at the same time is 6TiSCH. There will be further discussions on the draft that describes the architecture for running IPv6 over TSCH networks, two drafts related to the 6top protocol that enables distributed scheduling, as well as four drafts related to security functionality. There will also be an update on IEEE 802.15.4e developments, and introduction of a draft describing a joint scheduling architecture for deterministic industrial field and backhaul networks.

NOTE: If you are unable to attend IETF 98 in person, there are multiple ways to participate remotely.

It’s perhaps worth calling into the Internet Area Working Group after lunch. This acts as a forum for cross-area issues, and there’s one IPv6 related draft on the agenda concerning DHCPv6 Options for Discovery NAT64 Prefixes.

The second afternoon session sees the first meeting of the recently chartered SIDROPS. This has taken over the technology developed by SIDR and is developing guidelines for the operation of SIDR-aware networks, as well as providing operational guidance on how to deploy and operate SIDR technologies in existing and new networks.

On the agenda are two drafts outlining mitigating mechanisms for route leaks. One suggests an enhancement to BGP that would extend the route-leak detection and mitigation capability of BGPSEC, whilst the other proposes to enhance the BGP Open message to establish a relationship agreement between two BGP neighbouring speakers in order to enforce appropriate configuration on both sides.

Also running at the same time is UTA which has finished a number of pieces of work and will therefore focus on several drafts related to Strict Transport Security (STS) for mail transfer and user agents.

If all this isn’t enough, OPSEC is being held during the evening session where a draft on operational security considerations for IPv6 networks will be discussed. IPv6 presents some new security challenges, but this draft analyses the operational security issues for enterprises, service providers and residential users and proposes practical mitigation techniques.

For more background, please read the Rough Guide to IETF 98 from Olaf, Dan, Andrei, Mat, Karen and myself.

Relevant Working Groups

Deploy360 Domain Name System Security Extensions (DNSSEC) IETF IPv6 Transport Layer Security (TLS)

Deploy360@IETF95, Day 1: IPv6, TLS, SIDR, DNSSD, ACME & REGEXT

IETF95 Hackathon participants

It’s a very busy first day for the Deploy360 team at IETF 95 in Buenos Aires with our focus areas of IPv6, DNSSEC, securing BGP and TLS all having sessions during the day. Throughout this week at IETF 95 we’ll be bringing you these daily blog posts that point out what we are focused on during that day.

Our day begins with IPv6 Operations (v6ops), Secure Inter-Domain Routing (sidr) and Using TLS in Applications (uta) Working Groups all kicking-off at the same time on Monday afternoon at 14:00 ART (UTC-3). We’re then planning to take in the Extensions for Scalable DNS Service Discovery (dnssd) and Public Notary Transparency (trans) Working Groups, before finishing up the day with the Automated Certificate Management Environment (acme) and Registration Protocols Extensions (regext) Working Groups.

NOTE: If you are unable to attend IETF 95 in person, there are multiple ways to participate remotely.

V6OPS only has a couple of drafts on the agenda this time, although the discussion of draft-gont-v6ops-ipv6-ehs-packet-drops-03 could be interesting as it concerns the observed issue of IPv6 packets with certain extension headers being dropped by Internet. The other draft under discussion draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-02 is concerned with mitigating potential denial-of-service attacks via multicasting. However, also on the agenda is the LACNIC report on IPv6 deployment in Latin America and the Caribbean which is a comprehensive survey of the current state of IPv4 exhaustion, case studies of IPv6 deployments, as well as the problems, challenges and regulatory barriers that were experienced.

SIDR has quite a few new proposals on the agenda. The draft-rir-rpki-allres-ta-app-statement-00 attempts to address the problem where subordinate certificates over claim number resources leading to invalidation of the branch underneath and the potential loss of routing of those resources. This draft is expected to generate a lot of comment as it proposes that each RIR will move from a Trust Anchor reflecting their current holdings, to one reflecting all holdings so that over-claiming can not occur when resources are transferred from one RIR to another.

The draft-ietf-sidr-rpki-tree-validation-00 describes how a Relying Party can discover RPKI objects to download and validate independently from any repository access protocol is used, whilst draft-kklf-sidr-route-server-rpki-light-00 provides suggestions as to how RPKI can be effectively used in an IXP environment.

UTA has two new drafts up for discussion related to securing SMTP connections via TLS, whilst there’s a new version of the DEEP proposal which aims to improve email confidentiality between mail user agents and mail servers. As Dan York mentioned in a Rough Guide post, this UTA session has a strong DNSSEC connection as all of the proposals for securing email have some DNSSEC or DANE aspect.

Moving onto DNSSD which we haven’t covered too much in the past, but which is concerned with discovering services on a network that may extend beyond your own local network, with the security implications that entails. There are two interesting drafts here – one related to the overall threat model and the other about privacy extensions.

At the same time is TRANS which is focused on certificate transparency – a mechanism for tracking changes in TLS certificates. This has a draft out about the attack model and threats on certificate transparency that relates to our interest in TLS and DANE.

We round off the day with ACME which has been developing a standards-based REST API allowing agent software to authenticate that a server controls a domain, request a certificate, and then install it on a server without human intervention. This has been used in the Let’s Encrypt initiative, and this session will likely discuss whether the work of the group is now completed.

At the same time the REGEXT working group will be meeting for the first time with the goal of documenting extensions to the Extensible Provisioning Protocol (EPP) used for communication with top-level domain (TLD) registries.   This group is taking over from the now-closed EPPEXT working group which approved documents such as the process for a secure transfer of a DNSSEC-signed domain that is currently in the RFC editor queue for publication.   Our interest in this session at IETF 95 is draft-latour-dnsoperator-to-rrr-protocol, part of the ongoing work driven primarily by Olafur Gudmundsson (CloudFlare) and Jacques Latour (CIRA), with help from Paul Wouters and many others, to automate the process of passing the DNSSEC DS records from a DNS operator (or “DNS hosting provider”) up to a registry without involving a registrar.  Dan wrote about this issue last year and it has been a frequent topic at ICANN DNSSEC Workshops.

For more background, please read the Rough Guide to IETF 95 from Olaf, Dan, Andrei, Mat, Karen and myself.

Relevant Working Groups:

Image credit: a photo Dan York took of part of the “DNS team” at the IETF 95 Hackathon that were working on DNS over TLS.