Categories
Deploy360 Encryption Internet of Things (IoT) IPv6

Deploy360@IETF95, Day 4: TLS & IPv6

Buenos Aires

Day 4 is a quieter one for Deploy360 at IETF 95, with just the TLS and IPv6 over Networks of Resource-constrained Nodes Working Groups of specific interest. The Routing Area and Dynamic Host Control Working Groups also have some IPv6 business though.


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


tls holds its second session in Atlantico C this morning. It will continue to discuss the proposed TLS version 1.3 standard that aims remove support for weaker encryption algorithms, introduce new encryption algorithms, along with requiring stronger handshaking techniques.

In parallel in Buen Ayre C, rtgwg will be discussing multi-homing for provider assigned IPv6 addresses as well as homenets. A related draft covers the issue of IPv6 networks using packet source addresses for making routing decisions, especially on small multi-homed networks with dynamic addressing.

In the afternoon session, dhc has a busy agenda with no less than five drafts relating to DHCPv6. Of particular interest is Secure DHCPv6 which builds on the need for more secure communication against pervasive monitoring by adding authentication and encryption of messages between DHCPv6 clients and servers.

That leaves 6lo in the evening which is looking into the issues of implementing IPv6 on nodes with limited power, memory and processing resource with a view towards the future Internet-of-Things. Despite the lateness of the hour, there are whopping ten drafts under discussion in this session

Relevant Working Groups:

Categories
Deploy360 Domain Name System Security Extensions (DNSSEC)

Deploy360@IETF95, Day 3: DNS, SIDR & IPv6

 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

Categories
Deploy360 Domain Name System Security Extensions (DNSSEC) Encryption Events IETF

Deploy360@IETF95, Day 2: TLS, Curdle, Homenet, Security & Sunset4

John Levine at microphone

Our schedule for Day 2 at IETF 95 is a bit less hectic than yesterday, but promises to be the most interesting of the week. As well as the established Home Networking and TLS Working Groups, today also sees the debut of the new CURves, Deprecating and a Little more Encryption Working Group. There will also be a meeting of the Sunsetting of the IPv4 Working Group to discuss moving the IPv4 protocol to historic status.


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


TLS holds the first of its two sessions this morning (the other being on Thursday morning). There’s really just the one item on the agenda, which is the proposed TLS version 1.3 standard that aims remove support for weaker encryption algorithms, introduce new encryption algorithms, along with requiring stronger handshaking techniques.

HOMENET has another busy agenda as it continues to develop protocols for residential networks based on IPv6. The primary focus is on autoconfiguration, naming architecture and service discovery, as well as multiple interfacing support in home-type scenarios, but two important new drafts will also be discussed. The Homenet profile of the Babel routing protocol used in conjunction with the HNCP protocol defines how Babel should be used in a Homenet scenario, whilst the Homenet Naming and Service Discovery Architecture covers how services advertise and register themselves both on the homenet and public Internet. The security aspects of this will also be covered in a presentation during the session.

OPSEC also has three IPv6-specific drafts on its agenda, including an approach for risk assessment of IPv6 transitional technologies using the STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of service and Elevation of Privilege) classification, and an analysis of the different security considerations between IPv4 and IPv6 in particular parts of the network. The third draft under discussion addresses requirements for IPv6 firewalls that have not been specified or recommended in RFCs to-date.

The CURDLE Working Group may be a bit of a mouthful when its acronym is fully expanded, but improving the cryptographic security of a number of protocols is an important objective and one very relevant to Deploy360. In particular, there are two drafts up for discussion that specify new algorithms for DNSSEC, something Dan York wrote about the importance of recently.

And to round off the day there’s SUNSET4 which has just the one draft on the agenda, but a potentially very significant one as it proposes to move IPv4 (as defined by RFC 791) to historic status and thereby no longer recommended for use on the Internet. This may not reach RFC status, but it has certainly generated some interesting discussion as to the implications of the IETF no longer actively working on IPv4 technologies. Possibly a meeting to attend just in case history does indeed get made?

Relevant Working Groups:


Image credit: a photo Dan York took of ISOC Board Member John Levine making a point at the microphone in the UTA Working Group on Monday.

Categories
Open Internet Standards

Fellows to IETF 95: Building Diverse Technical Communities

Independent, volunteer-based, technical communities are vital to the success of the IETF, and to the bottom-up, collaborative fabric of the Internet ecosystem. These communities of practice serve as important forums for knowledge exchange, resource sharing, skill development, relationship building and networking.

While quite prevalent in developed countries, there is still quite a lot of work to be done to create extended local and regional technical communities in emerging economies. The manner in which these communities emerge and evolve; how they are managed; and how they support local and regional (as well as international) collaboration, is critical to the strengthening and sustainability of the IETF, and to increasing awareness and participation in its work from individuals in developing countries.

The Internet Society serves diverse technical communities by continuously enhancing its activities related to open Internet standards (OIS). To date, the organization has supported over 200 technologists, engineers, and researchers from Europe, Africa, Asia-Pacific and Latin America & the Caribbean to attend IETF meetings. The regional bureaus have fostered a vibrant network of remote hubs that engage with the IETF community in a number of ways.

The IETF in LAC initiative has served as a key impetus to bringing the first IETF to Latin America. The African Bureau is also building off the IETF in LAC model with the objective of bringing the IETF to the continent. The Kolkata Chapter has partnered with the Government of India on the India IETF Capacity Building (IICB) Program, which is geared towards increasing the participation of Indians and the engagement of corporations in the work of the IETF. As a result, communities of practice are popping up all across the world. But to accomplish this, there have been some critical success factors. Let’s discuss what they are.

Finding Common Ground

The first one is finding a way to connect different groups of people regardless of their background to a common ground. The biggest thing we see in the IETF are people forming groups and communities around passions that many of them identify with. Their need for and love of the open Internet has been at the core of our burgeoning communities. For them, the Internet is an indispensable platform, and one around which their interests are galvanized.

Let’s Come Together in the Same Place

Secondly, no one can discount that remote participation is important. But nothing can aptly replace face-to-face interactions. When it comes to engaging a community, you cannot rely solely on online platforms. Getting people to come and shake hands with the person next to them has been more beneficial than any advice or guidance they receive online. For example, there are currently around 20 Remote Hubs in Latin America and 26 in India, and with many of them being led by past Fellows to the IETF. This demonstrates why Remote Hubs and the Fellowship to the IETF have been so essential to the growth of our communities.

It’s the Content

Content is another significant component in the overall mix. Our communities look to us to provide timely and relevant content on the issues that matter to them. Whether it takes the form of web site updates, online courses and tutorials, Deploy360 resources, or policy briefs, our constituents view us as a trusted source for Internet-related content. This is how they become informed and empowered to act (and to increase their participation in OIS activities).

Leveraging Social Media

Effective community leadership requires constant creation/sharing of quality content and connecting with people online. Online engagement is of paramount importance — Frequent updates on ISOC activities, generation of new content, timely responses to questions from our community, and features on our influencers and programme alumni are just a few components of the overall social media strategy. This is how we build connections and ignite change. And we want to keep these conversations going!

So to recap, key success factors for sustainable, successful tech communities:

  • Find a shared passion
  • Create consistent face-to-face opportunities
  • Delivery consistent, useful online content
  • Use social media to engage with your community around a shared passion
  • Did I mention consistency?

Finally, we would like to congratulate the Fellows to IETF 95. You can view their bio profiles here.

Once again, we have another dynamic group of young professionals who will be attending the Buenos Aires meeting. We are looking forward to an exciting and productive week with them. They are our next wave of advocates and ambassadors who will strengthen and build new communities going forward.

Categories
Building Trust Identity IETF Open Internet Standards Privacy Technology

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

This installment of the Internet Society’s Rough Guide to IETF 95 focuses attention on the IETF 95 activities related to improving trust in the Internet. Key to this trust is the ability to establish and maintain accurate identity including privacy. As one might expect, there is a great deal of activity in this space in the IETF.

First, there is one BoF related to the trust topic at IETF 95. The Limited Use of Keys (lurk) BoF is looking at the problem caused by the increasing separation of the content provider from the network delivery. In this case, the content provider does not necessarily want to give their private key to the network service provider hosting their content. Generally speaking sharing of private keys is a bad idea. Thus far the mailing list has identified this “offload TLS without giving the CDN my private key” use case as being of particular interest. This BoF will explore if there are other related use cases that also need to be addressed and if there is sufficient interest to pursue work in this area.

As for the IETF working groups, there are several ongoing working groups addressing relevant topics in this space. Some of the ones that will meet at IETF 95 are highlighted below.

The Automated Certificate Management Environment (acme) working group is working to lower the barrier to deployment and management of certificates for the Web PKI. Currently, the verification of domain names in a certificate is done using a set of manual mechanisms. The acme working group is working to automate the process of issuance, validation, revocation and renewal of certificates. This is meeting will focus almost exclusively on maturing the current document (https://datatracker.ietf.org/doc/draft-ietf-acme-acme/) and resolving the issues documented in the issue tracker (https://github.com/ietf-wg-acme/acme/issues). This working group is also tied to the Let’s Encrypt certificate authority that is striving to lower the barriers to certificate usage both from a cost and a complexity perspective.

The Authentication and Authorization for Constrained Environments (ace) working group is focused on the increasingly complex Internet of Things (IoT) space. The bulk of the discussion this week will focus on resolving open issues with the draft on using OAuth 2.0 for Internet of Things (IoT) authorization. There are more details on all the IETF work related to IoT in the most recent edition of the IETF Journal.

In response to evolving concerns about pervasive surveillance, the IETF has looked to improve the observable data in many of its protocols. The DNS PRIVate Exchange (DPRIVE) Working Group was chartered to develop mechanisms to provide confidentiality between DNS Clients and Iterative Resolvers. Given that virtually all communication on the Internet involves name resolution, providing additional privacy to the underlying mechanisms is key to improving trust in the Internet.

The Web Authorization Protocol (oauth) working group has been working for quite some time on a suite of documents that enables a user to grant a third-party access to protected resources without sharing the user’s long term credentials. The working group has completed a long list of RFCs. This week’s meeting will focus on mix-up mitigation, discovery, token exchange, and the use of OAuth for native apps. OAuth is a key component of online identity systems and is being leveraged in the ongoing OpenID Connect work. The Open Specification for Pretty Good Privacy (OpenPGP) working group originally completed its work in 2008 providing a solution for object encryption, object signing, and identity certification ( RFC4880). Recently it has become clear that it was time to produce an update to RFC4880, and the OpenPGP working group was reinstated to do that work. This revision will include potential inclusion of elliptic curves recommended by the Crypto Forum Research Group (CFRG), a symmetric encryption mechanism that offers modern message integrity protection, an update to the mandatory-to-implement algorithm selection, deprecation of weak algorithms, and an updated public-key fingerprint mechanism.

The web PKI certificate infrastructure continues to be a source of trust related operational issues in the Internet. The primary effort of the Public Notary Transparency (trans) working group is the generation of a standards track version of the experimental RFC 6962 on Certificate Transparency. Certificate Transparency creates a log of certificates issued by certificate authorities (CAs). This provides the opportunity to monitor for problems in the certificate infrastructure globally. The primary focus of this week’s discussion will continue to be the update to RFC 6962, a threat analysis, and the gossip protocol. Rumor has it that the 6962bis effort in approaching completion!

As the Internet has evolved, some of the key pieces of infrastructure that we often take for granted need to be reconsidered in the light of the current operational environment. Time is a key component of establishing and maintaining trust, and it is often overlooked. The Network Time Protocol (ntp) working group has recently started a working group last call (WGLC) on NTS. Network Time Security (NTS) will define an updated framework and mechanisms for time server authentication. The WGLC on NTS has generated a great deal of mailing list discussion, and the meeting here at IETF 95 promises to have many interesting questions to resolve.

Finally, the Internet Architecture Board (IAB), through its Privacy and Security Program has taken a look at some of the problems of the existing Web PKI infrastructure. Since IETF 94, the program has adopted and updated a draft that identifies some of the issues and emerging solutions in this space. This draft, “ Problems with the Public Key Infrastructure (PKI) for the World Wide Web” will be on the program agenda this week. Find one of the co-authors and discuss any suggestions you might have for improving the document. Have a great week here at IETF 95 while you explore all of these trust, identity, and privacy related activities!

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

lurk (Limited Use of Remote Keys) BOF
Tuesday, 5 April 2016; 14:00 – 16:00 ART, Atlantico C
Agenda: https://datatracker.ietf.org/meeting/95/agenda/lurk/

ace (Authentication and Authorization for Constrained Environments) WG
Monday, 4 April 2016; 10:00 – 12:30 ART, Atlantico C
Agenda: https://tools.ietf.org/wg/ace/agenda
Documents: https://tools.ietf.org/wg/ace
Charter: https://tools.ietf.org/wg/ace/charter

acme (Automated Certificate Management Environment) WG
Monday, 4 April 2016; 17:40 – 19:40 ART, Buen Ayre A
Agenda: https://tools.ietf.org/wg/acme/agenda
Documents: https://tools.ietf.org/wg/acme/
Charter: https://tools.ietf.org/wg/acme/charters

dprive (DNS PRIVate Exchange) wg
Wednesday, 6 April 2016; 10:00 – 11:00 ART, Atlantico C
Agenda: https://tools.ietf.org/wg/dprive/agenda
Documents: https://tools.ietf.org/wg/dprive/
Charter: https://tools.ietf.org/wg/dprive/charters

oauth (Web Authorization Protocol) WG
Wednesday, 6 April 2016; 10:00 – 12:30 ART, Buen Ayre B
Agenda: https://tools.ietf.org/wg/oauth/agenda
Documents: https://tools.ietf.org/wg/oauth
Charter: https://tools.ietf.org/wg/oauth/charter

openpgp (Open Specification for Pretty Good Privacy)
Wednesday, 6 April 2016; 11:00 – 12:30 ART, Atlantico C
Agenda: https://tools.ietf.org/wg/openpgp/agenda
Documents: https://tools.ietf.org/wg/openpgp/
Charter: https://tools.ietf.org/wg/openpgp/charters

trans (Public Notary Transparency) WG
Wednesday, 6 April 2016; 14:00 – 16:00 ART, Atlantico C
Agenda: https://tools.ietf.org/wg/trans/agenda
Documents: https://tools.ietf.org/wg/stir/
Charter: https://tools.ietf.org/wg/trans/charter

ntp (Network Time Protocol) WG
Tuesday, 5 April 2016, 14:00 – 16:00 ART, Quebracho B
Agenda: https://tools.ietf.org/wg/ntp/agenda
Documents: https://tools.ietf.org/wg/ntp
Charter: https://tools.ietf.org/wg/ntp/charter

Follow Us

There’s a lot going on in Buenos Aires, 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 http://dev.internetsociety.org/rough-guide-ietf95.

Categories
Building Trust Encryption IETF Improving Technical Security Open Internet Standards Technology

Rough Guide to IETF 95: All Things Encryption

We have come a long was in both time and distance from Yokohama to Buenos Aires, and the efforts of the Internet community to strengthen the Internet by improving deployment of encryption continue with IETF 95 this week. This time around we will highlight the curdle, tls, and uta working groups, the cfrg research group, and the IAB Privacy and Security program.

The first thing I’d like to mention is a working group that will be meeting for the first time here in Buenos Aires. The CURves, Deprecating and a Little more Encryption (CURDLE) working group will focus on updating cryptographic mechanisms for existing IETF protocols. The working group will add mature mechanisms that enjoy broad support from implementers. It will also look at removing the support for old algorithms where there is IETF consensus to do so. The initial protocols that the CURDLE group will address include SSH, DNSSEC, PKIX, CMS, XML Digital Signatures and potentially XML Encryption, Kerberos and JSON.

Along the same lines, the Using TLS in Applications (UTA) working group continues to look at adding TLS support to existing applications. This week the focus will be on support for TLS in SMTP. Of note from the uta working group since the last IETF is the recent publication of RFC 7817 “Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols”.

The Transport Layer Security (TLS) working group continues to work on an update to the TLS protocol. This is a very active working group with a plan to publish an update to TLS in 2016. This meeting will be devoted to resolving the open issues with the current specification as documented in the issue tracker: https://github.com/tlswg/tls13-spec/issues.

Next, the Internet Research Task Force (IRTF) Crypto Forum Research Group (cfrg) continues to focus on use of cryptography for IETF protocols. Since IETF 94, RFC 7748 on “Elliptic Curves for Security” has been published. This is a major milestone for this activity. Topics for this week’s meeting include extended hash-based signatures, secure state management for hash-based signatures, PAKE requirements, and quantum resistant cryptography. Anyone interested in the future direction of cryptographic curves and algorithms would be well served to follow these discussions.

The Internet Architecture Board (IAB), through its Privacy and Security Program, has been focusing on strengthening the Internet by looking at threats, mitigations, and trust models. Since the publication of RFC 7624 “Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement”, the focus has been on a draft discussing mitigations “Confidentiality in the Face of Pervasive Surveillance”. This document is approaching maturation so now is an excellent time to find a member of that program to discuss the draft.

Also related to the IAB Privacy and Security program work is the Managing Radio Networks in an Encrypted World (MaRNEW) workshop held jointly by the IAB and the GSMA in September 2015 and discussed at IETF 94. A draft of the report for this workshop is now available in addition to all the raw workshop materials. One concern going into the workshop was that radio networks would face challenges meeting their operational requirements in an encrypted world. Discussion at the workshop focused on alternatives to traditional content classification that could be deployed in conjunction with encryption. Here at IETF 95 there will be BoF on Alternatives to Content Classification for Operator Resource Deployment (accord). This should be an excellent discussion of the challenges being faced and possible next steps to address some of these challenges.

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 the challenges and possibilities represented by the Internet of Things along with security and privacy issues in numeric identifiers among other topics.

All in all, the work continues here at IETF 95 to make encryption more widespread and easier to deploy for a stronger Internet.

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

curdle (CURves, Deprecating and a Little more Encryption) WG
(Tuesday, April 5, 2016, 16:20 – 17:20 ART, Buen Ayre B)
Agenda: https://www.ietf.org/proceedings/95/agenda/agenda-95-curdle
Documents: https://datatracker.ietf.org/group/curdle/documents/
Charter: https://datatracker.ietf.org/group/curdle/charter/

uta (Using TLS in Applications) WG
(Monday, April 4, 2016, 14:00 – 15:30 ART, Atlantico C)
Agenda: https://datatracker.ietf.org/meeting/95/agenda/uta/
Documents: https://datatracker.ietf.org/wg/uta/charter/
Charter: https://datatracker.ietf.org/group/uta/charter/

tls (Transport Layer Security) WG
(Tuesday, April 5, 2016, 10:00-12:30 ART, Atlantico B
Thursday, April 7, 2016, 10:00-12:30 ART, Atlantico C)
Agenda: https://tools.ietf.org/wg/tls/agenda-95-tls.html
Documents: https://tools.ietf.org/wg/tls
Charter: https://tools.ietf.org/wg/tls/charters

cfrg (Crypto Forum Research Group)
(Friday, 8 April 2016, 10:00 – 12:00 ART, Buen Ayre A)
Agenda: https://tools.ietf.org/agenda/95/agenda-95-cfrg.html
Documents: https://datatracker.ietf.org/rg/cfrg/documents/
Charter: https://irtf.org/cfrg

accord (Alternatives to Content Classification for Operator Resource Deployment ) BoF
(Thursday April 7, 2016, 10:00-12:30 ART, Pacifico A)
Agenda: https://datatracker.ietf.org/meeting/95/agenda/accord/

saag (Security Area Advisory Group)
(Thursday, 7 April 2016, 1400-1600 ART, Pacifico A)
Agenda: https://tools.ietf.org/agenda/95/agenda-95-saag.html

Follow Us

There’s a lot going on in Buenos Aires, 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 http://dev.internetsociety.org/rough-guide-ietf95.

Categories
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.

Categories
Deploy360 Domain Name System Security Extensions (DNSSEC) IETF IPv6

Our Hot Topics @ IETF 95

IETF 95 - Buenos AiresNext week is IETF 95 in Buenos Aires which is not only the first to be held in Argentina, but also the first to be held in Latin America. Although it’ll just be Megan Kruse and Dan York on-site this time from Deploy360 due to an overlap with ION Bangladesh/bdNOG 5, if you have any questions about Deploy360 or ideas to help deployment of our key Internet technologies IPv6DNSSECSecuring BGPTLS and anti-spoofing, then please get in contact with them!

Our Deploy360 colleagues are planning to cover the following sessions, although there are some unfortunate clashes which may require some hopping between rooms:

Monday, 4 April 2016

Tuesday, 5 April 2016

Wednesday, 6 April 2016

Thursday, 7 April 2016

Friday, 8 April 2016

The Internet Society has also put together its latest Rough Guide to the IETF 95, and will again be covering wider developments over on the Tech Matters Blog.  In particular, see:

If you can’t get to Buenos Aires next week, you can attend remotely!  Just visit the IETF 94 remote participation page or check out http://www.ietf.org/live/ for more options.

Categories
Building Trust IETF Improving Technical Security Open Internet Standards Technology

Rough Guide to IETF 95: Internet Infrastructure Resilience

This issue of the ISOC Rough Guide to IETF 95 includes not only issues related to the control plane (routing), but also to the data forwarding plane – specifically DDoS attacks. There is interesting and important work underway at IETF 95 in Buenos Aires next week that can help addressing problems in both areas.

The Secure Inter-Domain Routing (SIDR, http://datatracker.ietf.org/wg/sidr/) WG is focusing 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 global routing infrastructure.

If you look at the agenda, quite a few new proposals are brought to the table and will be discussed in Buenos Aires. Remarkably, most of them are related to the RPKI and Origin Validation, its operational and deployment aspects, which is a good indicator of the maturing process of this technology.

For quite some time the RIR engineers operating apexes of the RPKI hierarchy have been raising concerns about fragility of the system to potential mistakes of “over-claiming.” This is a case when a subordinate certificate “over-claims” resources compared to its parent, which leads to invalidation of the whole branch beneath. The closer to the top of the RPKI hierarchy such mistakes happen, the bigger the impact – some ISPs can lose their routing completely (assuming other folks validate, of course). And the probability of such mistakes is unfortunately non-zero, especially taking into account the inter-RIR address transfers.

A proposal “RPKI Validation Reconsidered” ( http://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered) tried to address this issue, but proposed quite fundamental changes to the PKI validation process that raised strong opposition in SIDR.

A new draft “RPKI Multiple ‘All Resources’ Trust Anchors Applicability Statement” ( https://tools.ietf.org/html/draft-rir-rpki-allres-ta-app-statement-00) attempts to address this problem, but from a different angle. It suggests that each RIR will move from a Trust Anchor that reflects their current holdings to one that reflects all holdings (e.g. 0/0) so that over-claiming can not occur at an RIR level when dealing with transfers from one RIR to another. Interesting solution – I am sure it will generate some discussion at the microphone!

In order to use information published in RPKI repositories, Relying Parties (RP) need to retrieve and validate the content of certificates, CRLs, and other RPKI signed objects. To validate a particular object, one must ensure that all certificates in the certificate chain up to the Trust Anchor (TA) are valid. Therefore, the validation of a certificate tree is usually performed top-down, starting from the TA certificate and descending down the certificate
chain, validating every encountered certificate and its products.

A draft “RPKI Certificate Tree Validation by a Relying Party Tool ( https://tools.ietf.org/html/draft-ietf-sidr-rpki-tree-validation-00) describes how a Relying Party tool could discover RPKI objects to download, build certificate path, and validate RPKI objects, independently from what repository access protocol is used. The draft documents the process used by the RIPE NCC RPKI Validator implementation, but if there is interest it may be a good starting point of a generic validation document. I think that work can lead to more coherent and robust implementations of the validators.

A draft “Signaling RPKI Validation Results from a Route-Server to Peers”
( https://tools.ietf.org/html/draft-kklf-sidr-route-server-rpki-light-00) proposes how RPKI can be effectively used in an IXP environment, enhancing the functionality of a route server.

This all indicates to me that practical RPKI is getting more momentum.

We talked before about a so-called “route-leak.” Simply speaking, this term describes an otherwise valid announcement that nevertheless violated the intended propagation scope. For example, a multi-homed customer “leaks” an announcement from one upstream provider to another one. Because it is a policy violation, neither OV nor BGPSEC can detect or mitigate such “attack.” Seems like a significant “hole” that needs to be fixed.

Next to the “Methods for Detection and Mitigation of BGP Route Leaks” ( http://datatracker.ietf.org/doc/draft-ietf-idr-route-leak-detection-mitigation), where the authors suggest an enhancement to BGP that would extend the route-leak detection and mitigation capability of BGPSEC, there is a yet another proposal – “Route Leak Detection and Filtering using Roles in Update and Open messages” ( https://tools.ietf.org/html/draft-ymbk-idr-bgp-open-policy-00). This new proposal enhances the BGP Open message to establish an agreement of the (peer, customer, provider, internal) relationship of two BGP neighboring speakers in order to enforce appropriate configuration on both sides. Propagated routes are then marked with a flag according to agreed relationship allowing detection and mitigation of route leaks. There are similarities among the two proposals and I think they can complement each other. I hope this will be discussed soon and an agreed common approach will be adopted.

Related to the forwarding plane, a recently created WG – a DDoS Open Threat Signaling (DOTS, http://datatracker.ietf.org/wg/dots/) WG is making good progress. The goal of the group is to develop a communications protocol intended to facilitate the programmatic, coordinated mitigation of such attacks via a standards-based mechanism. This protocol should support requests for DDoS mitigation services and status updates across inter-organizational administrative boundaries.

There are a few drafts focusing on inter-domain operation that will be discussed during the WG meeting. By blocking DDoS attacks with inter-domain cooperation, average utility of DDoS mitigation equipment will increase. This will leverage total capacity of DDoS protection systems all over the internet. With this mechanism, we can manage DDoS attacks that exceed the capacity of its own platform.

Let us hope this work will lead to effective solution of this huge problem of the Internet and facilitate necessary cooperation on the global level.

Related Working Groups at IETF 95

SIDR (Secure Inter-Domain Routing) WG
Monday, 4 April 2016, 14:00-15:30, Atlantico B
Wednesday, 6 April 2016, 14:00-16:00, Buen Ayre A
Agenda: https://datatracker.ietf.org/meeting/95/agenda/sidr/
Charter: https://datatracker.ietf.org/wg/sidr/charter/

GROW (Global Routing Operations) WG
Thursday, 7 April 2016, 16:20-17:20, Buen Ayre B
Agenda: https://datatracker.ietf.org/meeting/95/agenda/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/

IDR (Inter-Domain Routing Working Group) WG
Tuesday, 5 April 2016, 10:00-12:30, Buen Ayre B
Agenda: https://datatracker.ietf.org/meeting/95/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/

DOTS (DDoS Open Threat Signaling) WG
Friday 8 April 2016, 10:00-12:00, Atlantico B
Agenda: https://datatracker.ietf.org/meeting/95/agenda/dots/
Charter: https://datatracker.ietf.org/wg/dots/charter/

Follow Us

There’s a lot going on in Buenos Aires, 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 https://dev.internetsociety.org/tag/ietf95/.

Categories
IETF IPv6 Open Internet Standards

Rough Guide to IETF 95: All About IPv6

IPv6 remains an important aspect of the standardization work within the IETF, with much activity next week at IETF 95 in Buenos Aires. IPv6 deployment hit 10% earlier this year according to Google IPv6 statistics, and whilst other sources such as APNIC Labs and Akamai show slightly lower adoption rates, IPv6 usage continues to grow a steady rate as Regional Internet Registries assign their last remaining IPv4 addresses. There’s also evidence from both the RIRs and commercial transfer market that IPv4 address transfers as well as use of legacy addresses (i.e. those allocated before 1997) increased substantially in 2015, reflecting the limited availability of new IPv4 address blocks.

Both the IPv6 Operations (v6ops) and the IPv6 Maintenance (6man) Working Groups are meeting at IETF 95 in Buenos Aires next week. It’s perhaps worth highlighting first though, that a new draft https://tools.ietf.org/html/draft-howard-sunset4-v4historic-00 is up for discussion at the Sunsetting IPv4 Working Group on Tuesday evening. This proposes to move IPv4 (as defined by RFC 791) to historic status and thereby no longer recommended for use on the Internet. Whilst this may not reach RFC status, it has generated some interesting discussion as well as media comment as to the implications of the IETF no longer actively working on IPv4 technologies.

Returning to more practical matters, the IPv6 Operations (v6ops) Working Group has just two drafts up for discussion. The draft draft-gont-v6ops-ipv6-ehs-packet-drops-03 has been generating significant discussion on the v6ops mailing list as it concerns the observed dropping of packets with certain extension headers. 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.

The final item on the agenda of v6ops is the LACNIC report on IPv6 deployment in Latin America and the Caribbean. This is a comprehensive survey of the current state of IPv4 exhaustion, case studies of IPv6 deployments, but perhaps more interestingly the problems, challenges and regulatory barriers that were experienced. The report also provides insight into the rationale of those ISPs not currently considering the deployment of IPv6.

The IPv6 Maintenance (6man) Working Group will be meeting on Wednesday morning and will continue to discuss the proposed updates to the IPv6 specification, addressing architecture and path MTU discovery as currently defined in RFC 2460, RFC 4291, and RFC 1981. There are also two working group drafts relating to extension headers for routing ( draft-previdi-6man-segment-routing-header-08) and hop-by-hop options ( draft-ietf-6man-hbh-header-handling-03) which allow for differential handling of packets by forwarding and control planes in routers. A further draft draft-van-beijnum-multi-mtu-05 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.

The Homenet Working Group has a busy agenda on Tuesday afternoon as it continues to develop protocols for residential networks based on IPv6. The primary focus is on autoconfiguration, naming architecture and service discovery, as well as multiple interfacing support in home-type scenarios, but two important new drafts will also be discussed. The Homenet profile of the Babel routing protocol used in conjunction with the HNCP protocol defines how Babel should be used in a Homenet scenario ( draft-chroboczek-homenet-babel-profile-00), whilst the Homenet Naming and Service Discovery Architecture covers how services advertise and register themselves both on the homenet and public Internet ( draft-lemon-homenet-naming-architecture-00). The security aspects of this will also be covered in a presentation during the session.

The IETF is also looking into the issues of implementing IPv6 on nodes with limited power, memory and processing resource with a view towards the future Internet-of-Things. The IPv6 over Networks of Resource-Constrained Nodes (6lo) Working Group is scheduled to meet on Thursday afternoon, whilst the IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) Working Group meets on Monday afternoon with a new charter and plug testing on the agenda. The Routing Over Low Power and Lossy Networks (roll) Working Group on Tuesday afternoon will also consider the usage of IPv6 in very low power devices that have differing requirements in terms of their maximum MTUs.

Whilst these are the IPv6 specific sessions, other working groups need to take IPv6 into consideration as it evolves into a core Internet protocol. The Operational Security Capabilities for IP Network Infrastructure (opsec) Working Group on Tuesday afternoon has three IPv6-specific drafts on the agenda. The draft draft-georgescu-opsec-ipv6-trans-tech-threat-model-00 outlines an approach for risk assessment of IPv6 transitional technologies using the STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of service and Elevation of Privilege) classification, whilst draft-ietf-opsec-v6-08 analyses the different security considerations between IPv4 and IPv6 in particular parts of the network. The last of the drafts under discussion draft-gont-opsec-ipv6-firewall-reqs-03 addresses the requirements for IPv6 firewalls that have not been specified or recommended in RFCs to-date.

Finally, the Routing Area Working Group (rtgwg) on Thursday morning will have a discussion around multi-homing for provider assigned IPv6 addresses as well as homenets. A related draft is draft-ietf-rtgwg-dst-src-routing-01 which covers the issue of IPv6 networks using packet source addresses for making routing decisions, especially on small multi-homed networks with dynamic addressing.

At the Internet Society, we continue to promote IPv6 deployment. You can check out the World IPv6 Launch measurements for our latest measurements of IPv6 around the globe: http://www.worldipv6launch.org/measurements

You can also check out the Deploy360 online resources for getting started with IPv6 deployment:

And you can read more about other topics of interest to the technology programs of the Internet Society in the rest of our Rough Guide to IETF 95 posts.

Some IPv6 Working Groups at IETF 95:

v6ops (IPv6 Operations) WG
Monday, 4 April 1400-1500 UTC-3, Buen Ayre C
Agenda: https://datatracker.ietf.org/meeting/95/agenda/v6ops/
Documents: https://datatracker.ietf.org/wg/v6ops/documents/
Charter: https://datatracker.ietf.org/wg/v6ops/charter/

6man (IPv6 Maintenance ) WG
Wednesday, 6 April 1000-1230 UTC-3, Buen Ayre C
Agenda: https://datatracker.ietf.org/meeting/95/agenda/6man/
Documents: https://datatracker.ietf.org/wg/6man/documents/
Charter: https://datatracker.ietf.org/wg/6man/charter/

sunset4 (Sunsetting IPv4) WG
Tuesday, 5 April 1740-1910 UTC-3, Buen Ayre C
https://datatracker.ietf.org/meeting/95/agenda/sunset4/
Documents: https://datatracker.ietf.org/wg/sunset4/documents/
Charter: https://datatracker.ietf.org/group/sunset4/charter/

Homenet (Home Networking) WG
Tuesday, 5 April 1400-1600 UTC-3, Pacifico A
Agenda: https://datatracker.ietf.org/meeting/95/agenda/homenet/
Documents: https://datatracker.ietf.org/wg/homenet/documents/
Charter: https://datatracker.ietf.org/wg/homenet/charter/

6lo (IPv6 over Networks of Resource Constrained Nodes) WG
Thursday, 7 May 1730-1930 UTC-3, Pacifico A
Agenda: https://datatracker.ietf.org/meeting/95/agenda/6lo/
Documents: https://datatracker.ietf.org/wg/6lo/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-6lo/

6tisch (IPv6 over the TSCH mode of IEEE 802.15.4e)
Monday, 4 April 1400-1530 UTC-3, Buen Arye B
Agenda: https://datatracker.ietf.org/meeting/95/agenda/6tisch/
Documents: https://datatracker.ietf.org/wg/6tisch/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-6tisch/

roll (Routing Over Low power and Lossy networks)
Tuesday, 5 April 1620-1720 UTC-3, Quebracho B
Agenda: https://datatracker.ietf.org/meeting/95/agenda/roll/
Documents: https://datatracker.ietf.org/wg/roll/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-roll/

opsec (Operational Security Capabilities for IP Network Infrastructure)
Tuesday 5 April 1620-1720 UTC-3, Buen Ayre A
Agenda: https://datatracker.ietf.org/meeting/95/agenda/opsec/
Documents: https://datatracker.ietf.org/wg/opsec/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-opsec/

rtgwg (Routing Area Working Group)
Thursday, 7 May 1000-1230 UTC-3, Buen Ayre C
Friday, 8 May 1000-1200, Atlantico C
Agenda: https://datatracker.ietf.org/meeting/95/agenda/rtgwg/
Documents: https://datatracker.ietf.org/wg/rtgwg/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-rtgwg/

Follow Us

There’s a lot going on in Buenos Aires, 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 https://dev.internetsociety.org/tag/ietf95/.

Categories
Building Trust Events IETF Open Internet Standards Technology

Rough Guide to IETF 95: Scalability and Performance

In this post I’ll highlight some of the Internet Engineering Task Force (IETF) and Internet Research Task Force (IRTF) groups meeting as part of the IETF 95 meeting in Buenos Aires next week. These groups are working to explore and address more sophisticated ways to use and share available bandwidth, improve Internet performance, and otherwise efficiently get Internet content to where it needs to be.

Measurement techniques and data sources that could help us to make better engineering decisions to work around some of the rigidity in the protocol stack will be the subject of the proposed Measurement and Analysis for Protocols (maprg) research group meeting on Monday morning. The agenda for the session includes a presentation on the results Apple have obtained from their use of beta software for wide-area measurements.

The Alternatives to Content Classification for Operator Resource Deployment (accord) BoF will take place on Thursday morning. Encryption poses a challenge for cellular networks that use communication metadata to categorise sessions by their service requirements. This BoF session will seek to educate attendees about the realities of cellular networks today, and explore whether there are ways to provide the signals these networks need in the presence of ubiquitous encryption. This meeting is a follow-up activity from the IAB MaRNEW workshop that took place last year.

On Tuesday, Applied Networking Research Prize winners Zakir Durumeric and Roya Ensafi will present their research results. Zakir will talk about a detailed study of email security and Roya will present her analysis of the Great Firewall of China.

Packet networks give rise to transient congestion by design and several groups are meeting to discuss different aspects of congestion control and avoidance. The RTP Media Congestion Avoidance Techniques working group is developing and evaluating congestion control algorithms to handle the emerging use of the Internet for real-time audio and video communication. The Internet Congestion Control research group (iccrg) will meet to discuss some of the latest innovations and thinking in relation to congestion control and managing congestion on the Internet.

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 Buenos Aires to advance their important work on standardizing a large-scale broadband performance measurement infrastructure.

Related Working Groups and BoFs at IETF 95

accord BoF (Alternatives to Content Classification for Operator Resource Deployment) BoF
Thursday, 7 April 2016, 1000-1230, Pacifico A
Agenda: https://datatracker.ietf.org/meeting/95/agenda/accord/

irtfopen (IRTF Open Meeting)
Tuesday, 5 April 2016, 1000-1230, Pacifico A
Agenda: https://datatracker.ietf.org/meeting/95/agenda/irtfopen/

maprg (Proposed Measurement and Analysis for Protocols Research Group) RG
Monday, 4 April 2016, 1550-1720, Pacifico A
Agenda: https://datatracker.ietf.org/meeting/95/agenda/maprg/
Charter: https://datatracker.ietf.org/doc/charter-irtf-maprg/

iccrg (Internet Congestion Control) RG
Monday, 4 April 2016, 1400-1530, Buen Ayre A
Agenda: https://datatracker.ietf.org/meeting/95/agenda/iccrg/
Charter: https://datatracker.ietf.org/doc/charter-irtf-iccrg/

lmap (Large-Scale Measurement of Broadband Performance) WG
Tuesday, 5 April 2016, 1400-1600, Buen Ayre A
Agenda: https://datatracker.ietf.org/meeting/95/agenda/lmap/
Documents: https://datatracker.ietf.org/wg/lmap/
Charter: http://datatracker.ietf.org/wg/lmap/charter/

rmcat (RTP Media Congestion Avoidance Techniques) WG
Wednesday, 6 April 2016, 1000-1230, Atlantico B
Agenda: https://datatracker.ietf.org/meeting/95/agenda/rmcat/
Documents: https://datatracker.ietf.org/wg/rmcat/
Charter: http://datatracker.ietf.org/wg/rmcat/charter/

Follow Us

There’s a lot going on in Buenos Aires, 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 http://dev.internetsociety.org/rough-guide-ietf95.

Categories
IETF Internet Governance Open Internet Standards

Registration Open for the IETF 95 Briefing Panel – Public Policy and Internet Technology Development

We are happy to announce that registration is now open for the Internet Society Briefing Panel at IETF 95, entitled: “Public Policy and Internet Technology Development.” The panel takes place during lunch on Tuesday, 5 April, at the Hilton Buenos Aires.

Due to high demand for limited seating, pre-registration is required to attend the Briefing Panel in person. Registration opens today (29 March) in two blocks at 09:00 and 21:00 UTC for global time zone fairness.

This event will be recorded and webcast live on the ISOCtech YouTube Channel. Watch the Internet Technology Matters blog or the session information page for information about remote participation and archive details. Registration is NOT required for remote participation.

Session Abstract

The Internet Society has been bringing policy makers to IETF meetings for several years to experience the IETF meeting week first-hand and to learn from IETF experts about the technologies and standardisation processes that drive the IETF. Simultaneously, public policy makers have been directly involved in IETF projects like ECRIT and PAWS. The worlds of Internet technology standardisation and public policy development are drawing closer together.

When Internet technology is developed and standardised, the protagonists often move on to new projects while deployment proceeds in environments more diverse and heterogenous than any under consideration during the development phase. Because Internet technology has a real impact on people, their public representatives are increasingly taking an interest in the IETF as one source of this technology.

In this panel session we will identify the important issues for Internet public policy makers generally and the Latin American region in particular. We will discuss the relevance of the IETF to their work. In particular we will address the following questions:

  • What are the high priority issues for Internet policy makers today?
  • Why are policy makers interested in the work of the IETF?
  • Where does the work of the IETF and Public Policy intersect?
  • What could/should be done to improve two-way dialogue between technologists and public policy officials?

Join Us!

We hope you will join us, either in person or remotely, during IETF as we discuss the intersection of public policy and Internet technology development.

Register today!