Category: IETF

Jul 23

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.

Mar 15

Deploy360@IETF86: Day 5 – MIF, LISP, IPv6 Maintenance… and we’re done!

IETF LogoAnd so we reach Friday… the final day of the 86th meeting of the Internet Engineering Task Force (IETF)  where it’s a short day that ends early and for us within the Deploy360 Programme only hits two of our topics:  IPv6 and Routing Resiliency/Security.

General information about participating remotely can be found on the Remote Participation page as well as the IETF86 agenda – specific info for the groups we are following is included below.

Here’s the preview of how we’re finishing this very busy week…

0900-1100 Friday, March 15

Multiple Interfaces (MIF) – Caribbean 1
Computers and devices today have the ability to connect to multiple networks simultaneously. Think about a laptop that can connect over WiFi or Ethernet – or a smartphone that can connect over WiFi or the cellular data network.  In those cases which network interface should the device use?  The MIF working group is working to document the existing practices and outline the issues involved in a world where multiple network availability is routine.

Location/ID Separation Protocol (LISP) – Caribbean 6
The LISP working group is defining a series of experimental RFCs around a new routing protocol designed to improve the scalability of the Internet’s routing infrastructure.

1120-1220 and 1230-1330  Friday, March 15

IPv6 Maintenance (6man) – Caribbean 4

The 6man working group “is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture.” (quoting the charter)  This is where most of the work is happening to refine the IPv6 protocol itself, and today’s session should be quite a busy one.

With those sessions, we’ll be closing out our work at IETF 86 this week.  Some of us will then be moving into a meeting of the Internet Society Advisory Council happening on Friday afternoon before we head to the Orlando airport for our flights home.

It’s been a great week and we’ve made some significant progress on a number of fronts!

On a final note, this is the first time we’ve posted these daily previews – were they helpful?  We’d love to hear your comments – either in response to this post, on social networks or via our email or feedback form. (Thanks!)

P.S. For a broader view of the Internet Society’s interest in IETF 86 beyond that of just the topics we cover here at Deploy360, please see our “Rough Guide to IETF 86′s Hot Topics“.

NEW!Listen to this post (and please follow Deploy360 on SoundCloud if you use that service):

Mar 13

Deploy360@IETF86: Day 3 – Lots of IPv6 with a bit of Routing

For us within the Deploy360 Programme, Day 3 of the 86th meeting of the Internet Engineering Task Force (IETF)  is all about IPv6, IPv6 and more IPv6, with a tiny bit of routing thrown in for something different.  Two of the “big” working groups related to IPv6 meet today.  The Sunset4 working group is looking at what happens when you really start shutting down IPv4, and the V6ops working group is back again with more discussion of operational guidance around IPv6.

General information about participating remotely can be found on the Remote Participation page as well as the IETF86 agenda – specific info for the groups we are following is included below.

0900-1130 Wednesday, March 13

Softwire – Caribbean 2
The Softwire discussion continues from Monday with more looking at ways to connect IPv4 networks across IPv6 networks and connecting IPv6 networks across IPv4 networks… both important aspects of encouraging IPv6 deployment.

Inter-Domain Routing (IDR) – Caribbean 5
The IDR working group supports the use of Border Gateway Protocol (BGP) version 4 within IPv4 and IPv6 networks. The group works on maintenance of the BGP protocol as well as new extensions.

1300-1500 Wednesday, March 13

Sunsetting IPv4 (SUNSET4) – Caribbean 2

The Sunset4 working group is looking at issues around the transition from IPv4 to IPv6 and specifically at issues related to the shutting down of IPv4 and working in an IPv6-only environment. One important piece of work right now is related to developing a “gap analysis” between IPv4 and IPv6.

1510-1710 Wednesday, March 13

IPv6 Operations (V6ops) – Caribbean 5
Today v6ops will address several interesting drafts around design choices for IPv6 networks, security, operational guidelines for data centers and suggestions for the use of Unique Local Addresses.

1740-2010 Wednesday, March 13

IETF Operations and Administrative Plenary

While the operations and administrative plenary doesn’t usually directly relate to what we do here at Deploy360, it is a useful session to keep up with what changes are going on within the IETF as an organization and to learn about the current state of the organization.

And after that… we may try to have a team dinner, assuming we still have any energy left!  :-)

P.S. For a broader view of the Internet Society’s interest in IETF 86 beyond that of just the topics we cover here at Deploy360, please see our “Rough Guide to IETF 86′s Hot Topics“.

NEW!Listen to this post (and please follow Deploy360 on SoundCloud if you use that service):

Mar 12

Deploy360@IETF86: Day 2 – Routing (SIDR, KARP, GROW) and NAT (PCP, BEHAVE)

IETF LogoFor the Deploy360 team, Day 2 of the 86th meeting of the Internet Engineering Task Force (IETF) yields an IETF86 agenda that primarily focuses for us on routing issue and network address translation. We’ll start the day off looking at routing in embedded networks then return into secure routing between networks.  We’ll then look at authentication in routing followed by protocols and methods of working with NAT and finishing out the day attending a session on global routing operations.

General information about participating remotely can be found on the Remote Participation page – specific info for the groups we are following is included below.

0900-1030 Tuesday, March 12

Routing Over Low power and Lossy networks (ROLL) – Caribbean 3
This working group is looking at what needs to be done for routing packets in embedded networks such as industrial networks, connected home networks and other sensor networks (sometimes called the “Internet of Things”).

I’ll note that the Aggregated Service Discovery BOF happening at the same time also looks like an interesting session and something we’ll probably want to monitor. The proposed AGGSRV charter explains the problem of service discovery that it is trying to solve.

1030-1130 Tuesday, March 12

Secure Interdomain Routing (SIDR) – Caribbean 1
This is the second session at IETF 86 of the primary working group dealing with routing security issues that we are now looking to cover in the future in our Routing Resiliency/Security section of Deploy360. There will be some good discussions here related to BGPSEC and RPKI that should be quite interesting.

1145-1245 Tuesday, March 12

While not directly related to what we do here at Deploy360, we’ll be at the “ISOC@IETF” panel on the topic of:

Internet Society Briefing Panel at IETF 86: “Content is King; How Do we Avoid Playing the Pauper?”

The Internet has stimulated innovation through disruption in any number of areas, not the least of which is redefining what it means to be a “publisher” — of written, audio, video or other content. As everyone — people, for- and not-for-profit businesses alike — becomes a publisher, what are the next steps needed in order to ensure that content is treated as its creator desires. That may mean restricted use, or facilitating widespread use. This is not new — when the first anonFTP indexer was created (Archie), it surprised some authors who thought they were sharing private draft copies of their manuscript on an FTP site. On the flip side, every now and then a photo or a video “goes viral” on the Internet generating interest and awareness beyond the creator’s capacity to track it.

Are there ways that Internet application layer infrastructure standards could be extended to capture the content creator’s intentions of use of digital content, to be as open or as restricted as that creator desires?

Given that we are a publisher of content, this general topic is certainly of great interest to us. Unfortunately, all the seats have been reserved in the session so there is no room left to attend, but you can both listen and watch the session here:

1300-1500 Tuesday, March 12

There are two groups of interest to us in this time period.

Keying and Authentication for Routing Protocols (KARP) – Boca 2

The KARP working group examines how to add communication security to routing protocols in the form of message authentication, packet integrity, and denial of service (DoS) protection.

Port Control Protocol (PCP) – Caribbean 1

The PCP working group looks at how to enable communication from applications across middleboxes such as Network Address Translation (NAT) devices and firewalls. The group is looking at solutions for both IPv4 and IPv6.

1520-1650 Tuesday, March 12

Behavior Engineering for Hindrance Avoidance (BEHAVE) – Caribbean 1

Continuing an afternoon of NAT, the BEHAVE working group looks at NAT issues as they relate to the interconnection of IPv6 and IPv4 networks.

1700-1830 Tuesday, March 12

Global Routing Operations (GROW) – Caribbean 1

The GROW working group looks at the operational aspects of the IPv4 and IPv6 global routing systems

And after all that, we’ll be a bit tired but will be heading out to the one night of IETF that is a social event. Given that it will be at the Harry Potter section of Universal Studios, one can only imagine the photos, eh? :-)

P.S. For a broader view of the Internet Society’s interest in IETF 86 beyond that of just the topics we cover here at Deploy360, please see our “Rough Guide to IETF 86′s Hot Topics“.

NEW!Listen to this post (and please follow Deploy360 on SoundCloud if you use that service):

Mar 11

Watch/Listen Live – FCC CTO Henning Schulzrinne on "The End of Plain Old Telephone System (POTS)" at 5:30pm EDT Tonight at IETF86

Ietf square 1In about 15 minutes, at 5:30pm US Eastern At around 6:00pm US EDT, Henning Schulzrinne, CTO of the US Federal Communications Commission (FCC) will be speaking on "The End of Plain Old Telephone System (POTS): Transitioning the PSTN to IP" at the technical plenary of the 86th IETF meeting happening this week in Orlando, Florida.  You can listen or watch here:

Henning's slides are also available for download.

It should be quite an interesting session!

If you found this post interesting or useful, please consider either:

Mar 11

Deploy360@IETF86: Day 1 – SIDR, Softwires and V6Ops

IETF LogoAs today’s 86th meeting of the Internet Engineering Task Force (IETF) begins, here are the sessions from the IETF86 agenda that we on the Deploy360 team will be attending (all times US Eastern).  General information about participating remotely can be found on the Remote Participation page – specific info for the groups we are following is included below.

0900-1130 Monday, March 11

There are two groups we want to follow so Jan will be probably be in one (Softwires) while I (Dan) am in the other (SIDR):

Softwires – Caribbean 2
This working group is looking at ways to connect IPv4 networks across IPv6 networks and connecting IPv6 networks across IPv4 networks… both important aspects of encouraging IPv6 deployment.

Secure Interdomain Routing (SIDR) – Caribbean 4
This is the primary working group at IETF dealing with routing security issues that we are now looking to cover in the future in our Routing Resiliency/Security section of Deploy360. There will be some good discussions here related to BGPSEC and RPKI that should be quite interesting.

1300-1500 Monday, March 11

This time block is easy as we all will be in the “v6ops” working group dealing with IPv6 operational issues. This is probably the most important working group for the IPv6 work we do here within Deploy360.

IPv6 Operations (V6ops) – Caribbean 3

1540-1710 Monday, March 11

This time block doesn’t have any sessions that are specific to the Deploy360 program, but several are of general interest:

  • History BOF – looking at ways to archive/record history of the Internet.
  • Netconf – a protocol to ease configuration of network devices
  • Oauth – an important protocol for web security
  • Transport Area – discussions of transport-related drafts and items that don’t fit in existing working groups

Links to the audio feeds and jabber rooms for those sessions can be easily found on the tools-style agenda page.

1740-1940 Monday, March 11 – Technical Plenary

The technical plenary doesn’t directly relate to the topics we cover here at Deploy360, but the lead session will be “The End of Plain Old Telephone Service (POTS)” by Henning Schulzrinne, the CTO of the US Federal Communications Committee (FCC) and should be quite interesting.

And that will be the end of a long day!

P.S. For a broader view of the Internet Society’s interest in IETF 86 beyond that of just the topics we cover here at Deploy360, please see our “Rough Guide to IETF 86′s Hot Topics“.

NEW! Listen to this post (and please follow Deploy360 on SoundCloud if you use that service):

Mar 08

DNSSEC Discussion In DNSOP Working Group At IETF86 Next Week

IETF LogoAt the 86th meeting of the Internet Engineering Task Force (IETF) next week in Orlando there is one primary working group where DNSSEC will be discussed, the DNSOP (DNS Operations) working group.  As noted in our recently-published “Rough Guide To IETF 86′s Hot Topics“, DNSOP develops guidelines for the operation of DNS software servers and the administration of DNS zone files. It also documents DNSSEC operational procedures and looks at DNS-related IPv6 transition and coexistence issues.

The meeting is on Thursday, March 14, from 17:30 – 18:30 US Eastern time. The agenda and working group charter are:

Agenda: https://datatracker.ietf.org/meeting/86/agenda/dnsop/
Charter: https://datatracker.ietf.org/doc/charter-ietf-dnsop/

There are two major DNSSEC-related documents being discussed. First is draft-livingood-negative-trust-anchors, an interesting idea about how to use a “Negative Trust Anchor” to indicate within the DNSSEC-validating resolver that you want to accept DNS records for a given domain even if the DNSSEC-validation cames back as bad.  The primary use case for this is when there is a breakage of the DNSSEC chain of trust caused by, for instance, accidentally letting a key expire for a domain.  This idea came about from the team at Comcast when they dealt with issues like the nasa.gov key expiration.  It’s intended as a temporary measure that administrators can use while we are getting more DNSSEC deployed and the tools and processes are still evolving.

The second document is draft-kumari-ogud-dnsop-cds, a new draft that proposes a method of solving the dilemma of how to communicate a new Key Signing Key (KSK) to the parent domain using DNS itself.  This issue has been an ongoing challenge that has been in need of simplification – and this approach is one such proposal.  The mechanism, though, has proven to be quite contentious with a large volume of email to the dnsop mailing list.  It should generate quite an interesting discussion in the DNSOP meeting!

There may be a few other DNSSEC-related documents floating around in other working groups, but the DNSOP group on Thursday will be the major location of DNS-related discussion at this IETF 86 meeting.  Other DNS-related working groups such as DANE and DNSEXT chose not to meet as their work has been going on through the mailing lists and did not require a face-to-face meeting this time.

Note that if you can’t participate in person, there are several ways to participate remotely via audio, Jabber chat, WebEx and MeetEcho.

P.S. 3 of the 4 DO Team members will be at IETF 86 next week – please do say hello if you are there!

Mar 07

IPv6 Sessions at IETF 86 Next Week

IETF Logo

The 86th meeting of the Internet Engineering Task Force (IETF) is happening next week in Orlando and if you are interested in IPv6, there are quite a number of working groups where IPv6 will be discussed.  Our recently-published “Rough Guide To IETF 86′s Hot Topics” highlights three of the IPv6 groups:

v6ops (IPv6 Operations) WG

Joel Jaeggli is now an AD and John Brzozowski is taking over his job as WG chair along with Fred Baker. One draft to be discussed is draft-mlevy-v6ops-auto-v6-allocation-per-asn that led to some interesting discussions on the mailing list about the assertion that this draft enables networks to bypass the Regional Internet Registries (RIRs) in getting IPv6 space. It will be interesting to see whether this progresses or is discussed at the WG meeting during IETF 86.

There was a call for adoption of draft-binet-v6ops-cellular-host-requirements as a working group document. Most comments were in favor but there were a couple of articulate opponents. Many of the supporters are people working for adoption of v6 in mobile networks – mostly mobile operators.

Agenda: https://datatracker.ietf.org/meeting/86/agenda/v6ops/
Charter: https://datatracker.ietf.org/wg/v6ops/charter/
(11 March 2013, 1300-1530; 13 March 2013 1510-1710)

————–

6man (IPv6 Maintenance) WG

The 6man Working Group is charged with the maintenance, upkeep  and advancement of the IPv6 protocol specifications and addressing architecture, which is especially relevant as IPv6 begins to be deployed around the world at scale this year. A lot of the mailing list discussion since the last IETF meeting has been around the use of the U-bit and G-bit in the IPv6 iid as outlined in draft-carpenter-6man-ug. This draft hopes to clarify the use of these bits.

Agenda: https://datatracker.ietf.org/meeting/86/agenda/6man/
Charter: https://datatracker.ietf.org/doc/charter-ietf-6man/
(15 March 2013, 1120-1220, 1230-1330)

————–

sunset4 (Sunsetting IPv4) WG

sunset4 is a new working group in the Internet Area. The working group is an addresses the fact that the Internet is still largely IPv4, but in the presence of address exhaustion it cannot continue to be the Internet that we know today. The Internet will transition to IPv6 but there will be an interval where the Internet’s performance degrades as more coping mechanisms are adopted and before a complete transition to IPv6. This working group hopes to develop techniques to mitigate some of that pain. Sunset4 has a new charter proposed since the last IETF meeting, but it has not been approved. There has been little activity on the mailing list since IETF 85.

Agenda: https://datatracker.ietf.org/meeting/86/agenda/sunset4/
Charter: https://datatracker.ietf.org/doc/charter-ietf-sunset4/
(13 March 2013, 1300-1500)

Beyond those working groups, given that IPv6 is “the new normal” it can be found throughout many other groups, including:

IPv6-related drafts will also appear in a range of other working groups. Should be some excellent discussions and we’re looking forward to seeing progress made on a number of different drafts.

Note that if you can’t participate in person, there are several ways to participate remotely via audio, Jabber chat, WebEx and MeetEcho.

Jan 24

RFC 6841 Outlines How To Write DNSSEC Policies and Practice Statements

Back in July 2012, we wrote about “How To Write a DNSSEC Practice Statement (DPS)” and referenced an Internet-Draft that explained the process.  We’re very pleased to see that that I-D was just published this month as a formal RFC:

RFC 6841 – A Framework for DNSSEC Policies and DNSSEC Practice Statements

As the abstract says:

This document presents a framework to assist writers of DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone with Security Extensions implemented.

In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement.

It’s well worth a read not only if you are an operator of a Top-Level-Domain (TLD) or one of the newgTLDs (all of whom are mandated to support DNSSEC), but also if you are with an enterprise/company that is considering hosting all the DNSSEC-signing for your domains yourself.

If you want examples of what these DPS documents look like, we maintain a list of DNSSEC Practice Statements that includes documents from many of the major TLDs.  (And we’re always open to adding more if you have a published DPS online.  Just let us know.)

Jan 21

10 Updated Internet-Drafts Related to IPv6 Security

Fernando Gont of SI6 Networks has been a VERY busy man lately!  He and his colleagues and co-authors have recently updated a whole host of Internet-Drafts related to IPv6 security.  In a post to the full-disclosure mailing list, Fernando provided his list that includes:

Network Reconnaissance in IPv6 Networks

Security Implications of IPv6 on IPv4 Networks

Virtual Private Network (VPN) traffic leakages in dual-stack
hosts/ networks

Security Assessment of Neighbor Discovery (ND) for IPv6

DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers

Security Implications of IPv6 Fragmentation with IPv6
Neighbor Discovery

Security Implications of IPv6 options of Type 10xxxxxx

Security Implications of Predictable Fragment

Processing of IPv6 “atomic” fragments

Recommendations on filtering of IPv4 packets containing IPv4 options

Some of these are broader documents while some dive deep into specific issues or solutions.  Altogether they do represent a great amount of work on IPv6 security issues, which is excellent and definitely needed as we continue to move to using more and more IPv6 in our networks.

Thanks to Fernando and the others involved in the work for getting these updated drafts out.  If you have any comments on these drafts, I know that Fernando is always looking for feedback – his email address and contact info in Argentina can be found at the end of any of the drafts.