‹ Back
Deploy360 6 April 2016

[email protected], Day 3: DNS, SIDR & IPv6

Kevin Meynell
By Kevin MeynellSenior Manager, Technical and Operational Engagement

 Sara Dickinson at DPRIVE

Day 3 is another busy day for the Deploy360 team at IETF 95, albeit with a more orderly schedule. We kick-off with the DNS PRIVate Exchange and IPv6 Maintenance Working Groups, followed by the second session of the Secure Inter-Domain Routing Working Group, and first session of the Domain Name System Operations Working Group.

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

DPRIVE has a short session in Atlantico C to continue discussions on DNS over TLS and DNS over DTLS which aims to secure the connections between DNS clients and the recursive resolvers that people use. This follows on from the Specification for DNS over TLS that was recently submitted for publication as an RFC to the IESG, and forms an important part of the overall encryption work being done by the IETF to protect against pervasive monitoring.

Over in Buen Ayre C, 6MAN will discuss proposed updates to the IPv6 specification, addressing architecture and path MTU discovery as currently defined in RFC 2460RFC 4291, and RFC 1981. There are also two working group drafts relating to extension headers for routing and hop-by-hop options which allow for differential handling of packets by forwarding and control planes in routers. A further draft has the aim of allowing larger packet sizes (MTUs) to be negotiated on Ethernet provisioned links that are able to support so-called jumbo frames.

In the afternoon, SIDR continues from where it left off on Monday, but today’s session will focus on the requirements for RPKI Relying Parties. There will also be a discussion on detecting and mitigating route leaks – namely valid announcements that nevertheless propagate beyond their intended scope. There are a couple of proposals to extend the capabilities of BGPSEC to detect route leaks, but also to enhance BGP Open messages to enable BGP neighbours to specify their relationship (i.e. peer, customer, provider, internal) and thereby enforce appropriate configuration on both sides.

We finish the day with the first session of DNSOP (the second being on Friday morning). This includes two DNSSEC related drafts on speeding up negative answers from NSEC records for the root zone, as well as one on requirements and usage guidance for DNSSEC cryptographic algorithms with the intent of phasing out potentially less secure implementations.

Relevant Working Groups:

Image: Sara Dickinson presenting at the DPRIVE Working Group

‹ Back

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...

Join the conversation with Internet Society members around the world