Categories
Deploy360 Events IETF IPv6 Open Internet Standards Securing Border Gateway Protocol (BGP)

IETF 102, Day 5: Au revoir Montréal

There’s just the couple of sessions to highlight on the last day of IETF 102 before we wrap up for the week.

V6OPS continues at 09.30 EDT/UTC-4 where it left off on Thursday afternoon. On the agenda are drafts relating to Multi-Addressing Considerations for IPv6 Prefix Delegation which considers prefix delegation considerations for both classic routing and various multi-addressing use cases; whilst IP over Ethernet (IPoE) Session Health Checking describes a mechanism for IP over Ethernet clients to achieve connectivity validation using PPP-style keepalives such as BFD Echo, or ARP and Neighbor Discovery functions.

The remaining draft proposes a method for Discovering Provisioning Domain Names and Data, which describes a way for hosts accessing the Internet via multiple interfaces and with possible multiple IPv6 prefixes, to identify themselves using Fully Qualified Domains as Provisioning Domain identifiers.


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


The final session starting 11.50 EDT/UTC-4 includes IDR. This has been working on (amongst other things) the issue of route leaks, and is trying to pull together different conflicting approaches towards mitigation of these in favour of a more complementary approach. This work includes two drafts on Methods for Detection and Mitigation of BGP Route Leaks, and on Design Discussion of Route Leaks Solution Methods.

With that, IETF 102 draws to a close and we say au revoir to Montréal. Many thanks for reading along this week… please do read our other IETF 102-related posts … and we’ll see you at IETF 103 on 3-9 November 2018 which for the first time is being held in Bangkok, Thailand!

Relevant Working Groups

Categories
Deploy360 Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) Events IETF Internet of Things (IoT) IPv6 Open Internet Standards Transport Layer Security (TLS)

IETF 102, Day 4: DNS, IoT & TLS

This week is IETF 102 in Montreal, Canada, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. Today we’re focusing on DNS, IoT and TLS issues.

LPWAN is the first event of the day starting at 09.30 EDT/UTC-4. There will be a discussion relating to the Working Group Last Call on the Static Context Header Compression (SCHC) framework, which provides both header compression and fragmentation functionalities; and on how to advance the LPWAN Static Context Header Compression (SCHC) for CoAP specification. Two other drafts are being presented for adoption by the Working Group relating to SCHC specifications (see https://tools.ietf.org/html/draft-petrov-lpwan-ipv6-schc-over-lorawan-02 and https://tools.ietf.org/html/draft-zuniga-lpwan-schc-over-sigfox-03).


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


The first session of V6OPS commences at 13.30 EDT/UTC-4, and will continue on Friday morning. Today’s agenda items include a presentation on World IPv6 Trends from APNIC Labs, followed by discussion on a new draft NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks which describes considerations with respect to applications or devices using literal IPv4 addresses or non-IPv6 compliant APIs, as well as IPv4-only hosts on an IPv6-only network. Two existing drafts will also be discussed – Requirements for IPv6 Routers that defines a set of recommendations for routers, switches, and middleboxes deployed in IPv6 networks; and Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service which extends RFC 7084 in order to allow the provisioning of IPv6 transition services for the support of IPv4 as a Service (IPv4aaS).

During the second part of the afternoon starting at 15.50 EDT/UTC-4, there’s a choice of two meetings.

DNS Resolver Identification and Use (DRIU) is a BoF to discuss how to identify DNS stub resolvers that support privacy (i.e. DNS-over-TLS and DNS-over-HTTPS) using DHCP and DHCPv6. There’s a couple of drafts under discussion on DHCPv6 Options for private DNS Discovery, and DOH digests that provides a mechanism for selecting a DNS-over-HTTPS (DOH) server.

Alternatively, you can choose T2TRG that will consider the report from the Workshop on IoT Semantic/Hypermedia Interoperability (WISHI), along with an update on the iot.schema.org that enables webmasters to embed structured data on their web pages for use by search engines and other applications. Following this will be a discussion on the next steps for IoT security, including a draft that reviews the state-of-the-art and the challenges for IoT security. A further draft offers guidance for designing Internet of Things (IoT) systems that follow the REST architectural style.

Then for the evening session starting at 18.10 EDT/UTC-4, there’s again the choice of two meetings:

TLS continues on from Monday afternoon, and will consider three drafts during this session. Certificate-based Authentication with External PSK specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre-shared key (PSK); Ticket Requests describes a mechanism by which clients may request tickets as needed during a connection, in order to address a limitation on the number of parallel connection a client may initiate; whilst Encrypted Server Name Indication (ESNI) defines a simpler mechanism to conceal the domain name a client is trying to connect to.

DNSOP also continues from where it left off on Wednesday morning. A couple of interesting drafts that may come up in this session include a DNS proxy use case to tunnel DNS query and response using DNS over HTTPs (DOH) protocol; and a proposed protocol and DNS Resource Record to compute, sign, represent, and use a message digest to verify the contents of a DNS zone.

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

Relevant Working Groups

Categories
Deploy360 Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) Events IETF Internet of Things (IoT) IPv6 Open Internet Standards

IETF 102, Day 3: DNSSEC, DPRIVE & IoT

This week is IETF 102 in Montreal, Canada, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. And today’s topics include DNS Security & Privacy, along with more IPv6 and IoT.

The first DNSOP session will start at 09.30 EDT/UTC-4, and will continue on Thursday evening. Topics of interest include a draft on Algorithm Implementation Requirements and Usage Guidance for DNSSEC, which updates current algorithm implementation requirements and usage guidance for DNSSEC (obsoleting RFC 6944). Another draft on Multi Provider DNSSEC models describes how to deploy DNSSEC in environments where multiple DNS providers are in use, whilst Delegation_Only DNSKEY flag introduces a new flag for DNSSEC keys that can address a potential attack.


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


Alternatively, the relatively new working group SUIT will also be meeting at the same time. Vulnerabilities in Internet of Things (IoT) devices have raised the need for secure firmware updates that are also suitable for a constrained environments, and this group aims to develop an interoperable update mechanism. There are three drafts up for discussion, including the description of the firmware update architecture, a specification for the firmware update metadata model or manifest, as well a specification for the firmware manifest format. The next steps will also be discussed.

In the first afternoon session starting at 13.30 EDT/UTC-4, there’s a choice of DPRIVE or 6TiSCH.

DPRIVE will kick off with an analysis of RIPE Atlas probe data relating to DNS Privacy, before discussing some recommendations for DNS Privacy Service Operators. There’s also some new work on Oblivious DNS that introduces an additional layer of obfuscation between clients and their queries, and there will be some discussion about how to add privacy to the communication between recursive resolvers and authoritative DNS servers. The latter is beyond the scope of the current Working Group charter and so the group will consider whether to ask to expand their mandate.

6TiSCH has a busy agenda with the 6top protocol that enables distributed scheduling being targeted for an IETF Last Call, whilst the IESG feedback on the security functionality will be discussed. Two other drafts are aiming for Working Group adoption including a description of a scheduling function that defines the behavior of a node when joining a network and a mechanism for carrying important information in infrequent network broadcasts. Another new draft defines a secure joining mechanism for enrolling devices into an 802.15.4 TSG network using 6TiSCH signalling methods.

In the second afternoon session starting at 15.20 EDT/UTC-4, Homenet will continue to discuss the Homenet profile of the Babel routing protocol. There are also two updated drafts on the agenda, relating to third party provisioning of naming services for home networks and defining DHCPv6 options so that naming services can be outsourced.

Rounding off the day is the IETF Plenary starting at 17.10 EDT/UTC-4.

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

Relevant Working Groups

Categories
Community Networks Deploy360 Encryption Events IETF Internet of Things (IoT) IPv6 Open Internet Standards

IETF 102, Day 2: Trust in the IETF

This week is IETF 102 in Montreal, Canada, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. And today’s topics include IPv6, IoT and Trust technologies.

6MAN commences at 09.30 EDT/UTC-4, and has six new drafts up for discussion covering IPv6 Neighbor Discovery Extensions for Prefix Delegation, IPv6 VPNs, ICMPv6, OAM in Segment Routing Networks with an IPv6 Data plane, allowing low or zero valid lifetimes to be accepted in Router Advertisement Prefix Information Options where it’s known that there can only be one router on the link; as well as introducing a new IPv6 ‘unrecognised’ option for ICMPv6 that conveys whether an underlying network can transmit IPv6 packets.

There are also three working group sponsored drafts, adopted from the last meeting. Privacy Extensions for Stateless Address Autoconfiguration in IPv6 describes an extension that causes nodes to generate global scope addresses from interface identifiers that change over time; IPv6 Segment Routing Header specifies how a node can steer a packet through a controlled set of instructions (segments) by prepending an SR header to the packet; whilst IPv6 Router Advertisement IPv6-Only Flag is an update to RFC 5175 that indicates to hosts that a link is IPv6-only.


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


There’s a choice of two meetings starting first thing at 09.30 EDT/UTC-4:

DMM is working on solutions for IP networks so that traffic between mobile devices and and correspondent nodes can take an optimal route. And there are several IPv6-related drafts including a couple related to Segment Routing (SRv6) for the Mobile User Plane (see https://www.ietf.org/id/draft-camarillo-dmm-srv6-mobile-pocs.txt and https://www.ietf.org/id/draft-ietf-dmm-srv6-mobile-uplane-02.txt), as well as on Proxy Mobile IPv6 extensions for Distributed Mobility Management. There’s also three drafts on 5G implementations which might be interesting.

Over in ROLL, they’ll be discussing an applicability statement for battery-powered remote metering devices and two others relating to routing headers and multicast parameters. There’s also a new draft on route discovery for symmetric and asymmetric Point-to-Point traffic flows.

Straight after lunch at 13.30-15.30 EDT/UTC-4 is 6LO , that’s preparing the IPv6 Backbone Router draft for a Working Group Last Call. There will also be an update regarding IESG review of the proposed revisions of RFCs 6550 and 6775 where 6LoWPAN Neighbor Discovery nodes in an RPL domain do not participate in the routing protocol, and a review of security considerations for Address Protected Neighbor Discovery that protects the owner of an address against address theft and impersonation inside a low-power and lossy network. Other drafts up for discussion include Design Considerations for Low-Power Networks to provide guidelines for improving interoperability, IPv6 over Power-Line Communication Networks, and on enabling IPv6 mesh networks over Bluetooth.

During the evening session commencing at 17.20 EDT/UCT-4, there’s another choice to be made between ACME and CFRG.

ACME is primarily focusing on agreeing the Automatic Certificate Management Environment protocol that is used to automate the process of verification, certificate issuance and revocation, and will be looking for consensus on a Working Group Last Call. Also up for discussion though, is the ACME TLS ALPN extension that allows for domain control validation using TLS, and Support for Short-Term, Automatically-Renewed (STAR) Certificates.

CFRG has five drafts on the agenda including randomness improvements for security protocols which is critical to the robustness of TLS and other security related cryptography; and Verifiable Random Functions (VRFs) which offer provide privacy against offline enumeration on data stored in a hash-based
data structure. Somewhat related is a draft that specifies a number of algorithms that may be used to hash arbitrary strings to Elliptic Curves, and another specifying a hash function with arbitrary output length.

Finally, although it’s not normally one of the Rough Guide topics, we’d like to highlight that the Global Access to the Internet for All (GAIA) Research Group will be holding a meeting at 15.50 EDT/UTC-4. This is chaired by our colleague Jane Coffin and aims to raise awareness and discuss the challenges and opportunities of enabling global Internet access. In particular to document and share deployment experiences and research results with the wider community, and to analyse how the costs of providing Internet access can be reduced for areas with low penetration.

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

Relevant Working Groups

Categories
Deploy360 Events IETF Improving Technical Security Internet of Things (IoT) IPv6 Open Internet Standards Securing Border Gateway Protocol (BGP) Transport Layer Security (TLS)

IETF 102, Day 1: IETF arrive à Montréal

Tomorrow sees kickoff of the Working Groups sessions at IETF 102 in Montreal, Canada, we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. Monday is an important day, with meetings of the TLS, 6MAN and SIDROPS Working Groups, along with two other IoT related groups.

6MAN commences at 09.30 EDT/UTC-4, and has six new drafts up for discussion covering IPv6 Neighbor Discovery Extensions for Prefix Delegation, IPv6 VPNs, ICMPv6, OAM in Segment Routing Networks with an IPv6 Data plane, allowing low or zero valid lifetimes to be accepted in Router Advertisement Prefix Information Options where it’s known that there can only be one router on the link; as well as introducing a new IPv6 ‘unrecognised’ option for ICMPv6 that conveys whether an underlying network can transmit IPv6 packets.

There are also three working group sponsored drafts, adopted from the last meeting. Privacy Extensions for Stateless Address Autoconfiguration in IPv6 describes an extension that causes nodes to generate global scope addresses from interface identifiers that change over time; IPv6 Segment Routing Header specifies how a node can steer a packet through a controlled set of instructions (segments) by prepending an SR header to the packet; whilst IPv6 Router Advertisement IPv6-Only Flag is an update to RFC 5175 that indicates to hosts that a link is IPv6-only.


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


ACE is running parallel with 6MAN, and will be discussing various drafts related to using DTLSOAuth, and Object Security in RESTful Environments and Proof of Possession for Web Tokens. There is also an important draft on Enrollment over Secure Transport for provisioning certificates over HTTPS.

Then in the afternoon starting at 13.30 EDT/UTC-4, you’ll need to choose between three working groups. The first TLS session of the week (the meeting continues on Thursday afternoon) has several important items related to the deployment of TLS 1.3 and there’s a proposal to formally deprecate TLS versions 1.0 and 1.1.

There’s two other drafts updating DTLS to version 1.3 (see https://tools.ietf.org/html/draft-ietf-tls-dtls13-28 and https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-01), and another describing a TLS extension to allow TLS clients to perform DANE authentication of a TLS server without needing to perform additional DNS record lookups. The remaining couple of drafts on the agenda relate to a mechanism that allows for exportable proof of ownership of a certificate that can be transmitted out of band and verified by another party, and on delegating credentials on TLS to allow server operators to
create their own credential delegations without breaking compatibility with clients that do not support this specification.

Over in SIDROPS, there’s three recommendations up for discussion that network operators avoid using the maxLength attribute when issuing Route Origin Authorizations under RPKI; how to improve Origin Validation within a trusted environment; and definition of a RPKI signed object that can be used by Trust Anchors to allow Relying Parties to migrate to new keys. There’s also a couple of profiles being defined for verifying that a Customer AS holder has authorised a Provider AS to be its upstream provider, and for AS Provider Authorization objects to verify the AS_PATH attribute of routes advertised by BGP. Finally, there will be a discussion on validation deployment planning.

There’s just the two drafts being discussed during the IPWAVE meeting, but important ones. The first is an update of the specification for transmitting IPv6 Packets over IEEE 802.11 Networks in Vehicular communications; the other defines the use cases for IP-based vehicular networks.

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

Relevant Working Groups

Categories
Deploy360 Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) IETF Improving Technical Security Internet of Things (IoT) IPv6 Open Internet Standards Securing Border Gateway Protocol (BGP) Transport Layer Security (TLS)

ISOC’s Hot Topics at IETF 102

The 102nd meeting of the IETF starts tomorrow in Montreal, Canada. This is will be the third time that an IETF has been held in the city, and tenth time in Canada – the first being way back in 1990.

The ISOC Internet Technology Team is as always highlighting the latest IPv6, DNSSEC, Securing BGP, TLS and IoT related developments, and we discuss these in detail in our Rough Guide to IETF 102. But we’ll also be bringing you daily previews of what’s happening each day as the week progresses.

Below are the sessions that we’ll be covering in the coming week. Note this post was written in advance so please check the official IETF 102 agenda for any updates, room changes, or final details.

Monday, 16 July 2018

Tuesday, 17 July 2018

Wednesday, 18 July 2018

Thursday, 19 July 2018

Friday, 20 July 2018

The IETF Hackathon will be held on both Saturday, 15 July 2018 (09.00-22.00 UTC-4) and Sunday, 16 July 2018 (08.30-16.00 UTC-4) in the Centre Ville Room. The Hackathon provides an opportunity for developers and implementers to discuss ideas, solutions and code to develop practical implementations of IETF standards.

The IETF Code Sprint will also be held on Saturday, 15 July 2018 (09.30-16.00 UTC-4) in the Sherbrooke/Mansfield Room. The Code Sprint brings together volunteers from the IETF Community to work on code for the IETF Datatracker, mailing lists, and other tools used by the IETF community.

You can also read the Internet Society’s latest Rough Guide to IETF 102. In particular, see:

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

Categories
Building Trust Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) Events IETF Improving Technical Security Open Internet Standards

Rough Guide to IETF 102: DNSSEC, DNS Security and Privacy

DNS privacy will receive a large focus in the latter half of the IETF 102 week with attention in the DPRIVE, DNSSD, and OPSEC working groups. In an interesting bit of scheduling (which is always challenging), most of the DNS sessions are Wednesday through Friday. As part of our Rough Guide to IETF 102, here’s a quick view on what’s happening in the world of DNS.

Given that IETF 102 is in Montreal, Canada, all times below are Eastern Daylight Time (EDT), which is UTC-4.

IETF 102 Hackathon

The “DNS team” has become a regular feature of the IETF Hackathons and the Montreal meeting is no different. The IETF 102 Hackathon wiki outlines the work that will start tomorrow (scroll down to see it). Major security/privacy projects include:

Anyone is welcome to join the DNS team for part or all of that event.

DNS Operations (DNSOP)

The DNS sessions at IETF 102 start on Wednesday morning from 9:30am – 12noon with the DNS Operations (DNSOP) Working Group. Paul Wouters and Ondrej Sury will be speaking about “Algorithm Implementation Requirements and Usage Guidance for DNSSEC“, where they will be offering updated guidance around what cryptographic algorithms should be used for different aspects of DNSSEC.  Shumon Huque will be bringing the latest updates to draft-huque-dnsop-multi-provider-dnssec, exploring how to deploy DNSSEC in environments where multiple DNS providers are in use. Paul Wouters will also bring a new draft, draft-pwouters-powerbind, which introduces a new flag for DNSSEC keys that can address a potential attack. Given the critical role DNS plays, the DNSOP agenda has many other drafts up for discussion and action. The DNSOP working group also has a second meeting block on Thursday from 18:10-19:10.

DNS PRIVate Exchange (DPRIVE)

The DPRIVE working group meets Wednesday afternoon from 13:30-15:00 EDT.  As shown on the agenda, there will be three major blocks of discussion. After some initial discussion of current work on existing DNS privacy policies, there will be a larger discussion about some new work called “Oblivious DNS” that aims to make DNS privacy protection even stronger. This work originated in a paper at Princeton University – https://odns.cs.princeton.edu/ – and now is captured in draft-annee-dprive-oblivious-dns. It should be quite an interesting discussion!

The third major area will continue discussion about how to add privacy to the communication between a DNS recursive resolver and the authoritative DNS server for a given domain.  This is work outside the current  DPRIVE Working Group charter and so the group will be discussing whether to ask to expand their mandate to cover this new work.

Extensions for Scalable DNS Service Discovery (DNSSD)

Privacy will also get attention at the DNSSD Working Group on Thursday morning from 9:30-12:00 EDT.  DNSSD focuses on how to make device discovery easier across multiple networks. For instance, helping you find available printers on not just your own network, but also on other networks to which your network is connected. However in doing so the current mechanisms expose a great deal of information. The agenda allocates 65 minutes to Christian Huitema to guide a discussion around the way forward. Drafts under discussion include:

There are other drafts under discussion at DNSSD, but these are the ones probably most of interest to readers of this article.

DNS Resolver Identification and Use (DRIU)

IETF 102 will feature a number of Birds-of-a-Feather (BOF) sessions, and one in particular relates to DNS security. The quick description is:

The IETF has added additional methods for DNS stub resolvers to get to recursive resolvers (notably DNS-over-TLS, RFC 7858), and is about to add another (DNS-over-HTTPS, from the DOH Working Group). As these have been developed, questions have been raised about how to identify these resolvers from protocols such as DHCP and DHCPv6, what the security properties these transports have in various configurations (such as between strict security and opportunistic security), and what it means for a user who has multiple resolvers configured when the elements of the configured set have different transports and security properties.

The DRIU session will be on Thursday from 15:50-17:50, right before the second DNSOP session (although in a different room).

Operational Security Capabilities for IP Network Infrastructure

In the very last slot on Friday afternoon from 11:50-13:20, the OPSEC working group will feature Benno Overeinder speaking about “Recommendations for DNS Privacy Service Operators. This document outlines things DNS operators should thing about when considering offering “DNS privacy” services. It builds on the work coming out of the DPRIVE working group and the experience gained from the IETF Hackathon and the real-world deployment of these new protocols.

DNSSEC Coordination informal breakfast meeting

As a final note, on Friday morning before the sessions start we are planning an informal gathering of people involved with DNSSEC. We’ve done this at many of the IETF meetings over the past few years and it’s been a good way to connect and talk about various projects. True to the “informal” nature, we’re not sure of the location and time yet (and we are not sure if it will involve food or just be a meeting). If you would like to join us, please drop me an email or join the dnssec-coord mailing list.

Other Working Groups

DANE and DNSSEC will also appear in the TLS Working Group’s Monday meeting. The draft-ietf-tls-dnssec-chain-extension will be presented as a potential way to make DANE work faster by allowing both DANE and DNSSEC records to be transmitted in a single exchange, thus reducing the time involved with DANE transactions. Given the key role DNS plays in the Internet in general, you can also expect DNS to appear in other groups throughout the week.

P.S. For more information about DNSSEC and DANE and how you can get them deployed for your networks and domains, please see our Deploy360 site:

Relevant Working Groups at IETF 102:

DNSOP (DNS Operations) WG
Wednesday, 18 July 2018, 9:30-12:00 EDT, Laurier
Thursday, 19 July 2018, 18:10-19:10 EDT, Place du Canada

Agenda: https://datatracker.ietf.org/meeting/102/agenda/dnsop/
Documents: https://datatracker.ietf.org/wg/dnsop/
Charter: http://tools.ietf.org/wg/dnsop/charters/

DPRIVE (DNS PRIVate Exchange) WG
Wednesday, 18 July 2018, 13:30-15:00 EDT, Place du Canada
Agenda: https://datatracker.ietf.org/meeting/102/agenda/dprive/
Documents: https://datatracker.ietf.org/wg/dprive/
Charter: http://tools.ietf.org/wg/dprive/charters/

DNSSD (Extensions for Scalable DNS Service Discovery) WG
Thursday, 19 July 2018, 9:30-12:00 EDT, Duluth
Agenda: https://datatracker.ietf.org/meeting/102/agenda/dnssd/
Documents: https://datatracker.ietf.org/wg/dnssd/
Charter: http://tools.ietf.org/wg/dnssd/charters/

DRIU (DNS Resolver Identification and Use) BOF
Thursday, 19 July 2018, 15:50-17:50 EDT, Viger
Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-driu

OPSEC (Operational Security Capabilities for IP Network Infrastructure) WG
Friday, 20 July 2018, 11:50-13:20 EDT, Viger
Agenda: https://datatracker.ietf.org/meeting/102/agenda/opsec/
Documents: https://datatracker.ietf.org/wg/opsec/
Charter: http://tools.ietf.org/wg/doh/charters/

Follow Us

It will be a busy week in Montreal, and whether you plan to be there or join remotely, there’s much to monitor. Read the full series of Rough Guide to IETF 102 posts, and follow us on the Internet Society blog, Twitter, or Facebook using #IETF102 to keep up with the latest news.

Categories
Deploy360 Events IETF IPv6 Open Internet Standards

Rough Guide to IETF 102: IPv6

In this post for the Internet Society Rough Guide to IETF 102 I’ll review what’ll be happening at the IETF meeting in Montreal next week on the topic of all things IPv6.

IPv6 global adoption rates have shown slow growth since IETF 101 and are currently approaching 25% overall. With the almost total depletion of the remaining pools of new IPv4 addresses, more-and-more networks have been increasing their IPv6 deployments, with the top 15 network operators supporting nearly half-a-billion IPv6 users. In addition, 28 percent of the Alexa Top 1000 websites are IPv6-enabled, including many of the large content providers who are now delivering native IPv6 traffic to mobile devices in particular. The US recently reached 40% deployment with nearly 80% of smartphones using IPv6, whilst along with Belgium, India, Germany, Brazil and Japan who still lead the way, we’re starting to see significant growth in countries such as Switzerland, Portugal, Estonia, Uruguay, Ecuador, Peru and New Zealand.

IPv6 is always an important focus for the IETF, particularly with respect to the standardisation work related to the Internet-of-Things.

The IPv6 Maintenance (6man) Working Group is a key group and it will be meeting on Monday morning. It hasn’t published any RFCs since the last meeting, but has six new drafts up for discussion covering IPv6 Neighbor Discovery Extensions for Prefix Delegation, IPv6 VPNs, ICMPv6, OAM in Segment Routing Networks with an IPv6 Data plane, allowing low or zero valid lifetimes to be accepted in Router Advertisement Prefix Information Options where it’s known that there can only be one router on the link; as well as introducing a new IPv6 ‘unrecognised’ option for ICMPv6 that conveys whether an underlying network can transmit IPv6 packets.

There are also three working group sponsored drafts, adopted from the last meeting. Privacy Extensions for Stateless Address Autoconfiguration in IPv6 describes an extension that causes nodes to generate global scope addresses from interface identifiers that change over time; IPv6 Segment Routing Header specifies how a node can steer a packet through a controlled set of instructions (segments) by prepending an SR header to the packet; whilst IPv6 Router Advertisement IPv6-Only Flag is an update to RFC 5175 that indicates to hosts that a link is IPv6-only.

On Monday afternoon, the IP Wireless Access in Vehicular Environments (ipwave) Working Group will also be meeting. This group has yet to publish its agenda, but has recently updated the specification for transmitting IPv6 Packets over IEEE 802.11 Networks in Vehicular communications; and has been defining the use cases for IP-based vehicular networks. Two new drafts have also been published since the last meeting relating to DNS Name Autoconfiguration for Internet of Things Devices and IPv6 Neighbor Discovery for Prefix and Service Discovery in Vehicular Networks.

There are two IPv6-related working groups on Tuesday. The Routing Over Low Power and Lossy Networks (roll) Working Group focuses on IPv6 routing issues for these networks and has published three RFCs since its last meeting. This includes an applicability statement for battery-powered remote metering devices and two others relating to routing headers and multicast parameters. There’s also a new draft on route discovery for symmetric and asymmetric Point-to-Point traffic flows.

The IPv6 over Networks of Resource Constrained Nodes (6lo) Working Group has a busy agenda with the IPv6 Backbone Router draft being prepared for a Working Group Last Call. There will also be an update regarding IESG review of the proposed revisions of RFCs 6550 and 6775 where 6LoWPAN Neighbor Discovery nodes in an RPL domain do not participate in the routing protocol, and a review of security considerations for Address Protected Neighbor Discovery that protects the owner of an address against address theft and impersonation inside a low-power and lossy network. Other drafts up for discussion include Design Considerations for Low-Power Networks to provide guidelines for improving interoperability, IPv6 over Power-Line Communication Networks, and on enabling IPv6 mesh networks over Bluetooth.

Moving ahead to Wednesday afternoon, the IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) Working Group has an extremely busy agenda. The 6top protocol that enables distributed scheduling is now aiming for IETF Last Call, whilst the IESG feedback on the security functionality will be discussed. Two other drafts are also aiming for Working Group adoption including a description of a scheduling function that defines the behavior of a node when joining a network and a mechanism for carrying important information in infrequent network broadcasts. Another new draft defines a secure joining mechanism for enrolling devices into an 802.15.4 TSG network using 6TiSCH signalling methods.

The Homenet (homenet) Working Group is being held during late Wednesday afternoon. It recently published RFC 8375 which relates to the special use domain ‘home.arpa’, and the group will continue to discuss the Homenet profile of the Babel routing protocol. There are two updated drafts on the agenda, relating to third party provisioning of naming services for home networks and defining DHCPv6 options so that naming services can be outsourced.

Thursday morning sees the meeting of the Low Power Wide-Area Networks (lpwan) Working Group. This group recently published RFC 8376 which provides an informational overview of LPWAN technologies in order to perform a gap analysis.

There will be a discussion relating to the Working Group Last Call on the Static Context Header Compression (SCHC) framework, which provides both header compression and fragmentation functionalities; and on how to advance the LPWAN Static Context Header Compression (SCHC) for CoAP specification. Two other drafts are being presented for adoption by the Working Group relating to SCHC specifications (see https://tools.ietf.org/html/draft-petrov-lpwan-ipv6-schc-over-lorawan-02 and https://tools.ietf.org/html/draft-zuniga-lpwan-schc-over-sigfox-03).

Last, but very much not least, the IPv6 Operations (v6ops) Working Group will be meeting on both the Thursday afternoon and Friday morning. It’ll kick-off with a presentation on World IPv6 Trends from APNIC Labs who are one of the organisations tracking IPv6 deployment. There’s then one new draft up for discussion on NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks which describes considerations with respect to applications or devices using literal IPv4 addresses or non-IPv6 compliant APIs, as well as IPv4-only hosts on an IPv6-only network.

There are also four existing drafts to be discussed. Requirements for IPv6 Routers defines a set of recommendations for routers, switches, and middleboxes deployed in IPv6 networks; Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service extends RFC 7084 in order to allow the provisioning of IPv6 transition services for the support of IPv4 as a Service (IPv4aaS) by means of new mechanisms that were not available when RFC 7084 was published; Multi-Addressing Considerations for IPv6 Prefix Delegation considers prefix delegation considerations for both classic routing and various multi-addressing use cases; whilst IP over Ethernet (IPoE) Session Health Checking describes a mechanism for IP over Ethernet clients to achieve connectivity validation using PPP-style keepalives such as BFD Echo, or ARP and Neighbor Discovery functions.

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. 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 programmes of the Internet Society in the rest of our Rough Guide to IETF 102 posts.

IPv6-related Working Groups at IETF 102:

6MAN (IPv6 Maintenance) WG
Monday, 16 July 2018 @ 09.30-12.00 UTC-4, Laurier
Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-6man/
Documents: https://datatracker.ietf.org/wg/6man/documents/
Charter: https://datatracker.ietf.org/wg/6man/charter/

IPWAVE (IP Wireless Access in Vehicular Environments) WG
Monday, 16 July 2018 13.30-15.30 UTC-4, Laurier
Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-ipwave/
Documents: https://datatracker.ietf.org/wg/ipwave/documents/
Charter: https://datatracker.ietf.org/wg/ipwave/documents/

ROLL (Routing Over Low power and Lossy networks) WG
Tuesday, 17 July 2018  09.30-12.00 UTC-4, Duluth
Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-roll/
Documents: https://datatracker.ietf.org/wg/roll/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-roll/

6LO (IPv6 over Networks of Resource Constrained Nodes) WG
Tuesday, 17 July 2018  13.30-15.30 UTC-4, Duluth
Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-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) WG
Wednesday, 18 July 2018 13.30-15.00 UTC-4, Duluth
Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-6tisch/
Documents: https://datatracker.ietf.org/wg/6tisch/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-6tisch/

Homenet (Home Networking) WG
Wednesday, 18 July 2018 15.20-16.50 UTC-4, Centre Ville
Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-homenet/
Documents: https://datatracker.ietf.org/wg/homenet/documents/
Charter: https://datatracker.ietf.org/wg/homenet/charter/

LPWAN (IPv6 over Low Power Wide-Area Networks) WG
Thursday, 19 July 2018 09.30-12.00 UTC-4, Centre Ville
Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-lpwan/
Documents: https://datatracker.ietf.org/wg/lpwan/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-lpwan/

V6OPS (IPv6 Operations) Working Group
Thursday 19 July 2018 13.30-15.30 UTC-4, Laurier & Friday, 20 July 2018 09.30-11.30 UTC-4, Place du Canada
Agenda: https://datatracker.ietf.org/meeting/102/materials/agenda-102-v6ops/
Documents: https://datatracker.ietf.org/wg/v6ops/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-v6ops/

Follow Us

It will be a busy week in Montreal, and whether you plan to be there or join remotely, there’s much to monitor. Read the full series of Rough Guide to IETF 102 posts, and follow us on the Internet Society blogTwitter, or Facebook using #IETF102 to keep up with the latest news.

Categories
Events IETF Internet of Things (IoT) Open Internet Standards

Rough Guide to IETF 102: Internet of Things

The buzz around the Internet of Things (IoT) is only increasing, to the surprise of, well, no one. We are often asked what is happening in the IETF in relation to IoT and in this short post I’d like to highlight some of the relevant activities and sessions scheduled during the upcoming IETF 102 meeting in Montreal. Also check out the IETF Journal IoT Category, the IETF IoT page, the IETF IoT Directorate, the Internet Society’s IoT page, or the Online Trust Alliance (OTA, which became an Internet Society Initiative in April 2017) IoT page for more details about many of these topics.

The IETF Hackathon, held on the weekend preceding the main IETF meeting (July 14-15), includes projects directly related to IoT, with the possibility of more being added. More information is on the Hackathon wiki. Projects of interest include those relating to:

  • Software Updates for Internet of Things (suit)
  • Authentication and Authorization for Constrained Environments (ace)
  • IPv6 over Low Power Wide-Area Networks (lpwan)
  • Work on IoT Semantic / Hypermedia Interoperability (WISHI)

The Thing-to-Thing Research Group (T2TRG) investigates open research issues towards turning the IoT into reality. The research group will be meeting on Thursday afternoon in Montreal to report out on their recent activities. Their summary meeting agenda can be found here. As in the past, full details and latest info on their activities can be found in GitHub. Of particular note is the recent update of a key draft document: State-of-the-Art and Challenges for the Internet of Things Security.

Two recently chartered IoT-related working groups met for the first time as working groups at the last IETF meeting in March, and are tackling very serious problems. I am very pleased to see these moving forward:

I would like to draw your attention to two recently initiated activities:

In this edition of the Rough Guide I would like to highlight some recent work in SUIT, addressing hash-based signatures. (Description courtesy Russ Housley)

Today, RSA is often used to digitally sign software updates. In preparation for a day when RSA, DSA, and ECDSA cannot be depended upon, a digital signature algorithm is needed that will remain secure even if there are significant cryptoanalytic advances or a large-scale quantum computer is invented. The hash-based digital signature algorithm specified in [HASHSIG] is one such algorithm. The use of hash-based signatures to protect software update distribution will allow the deployment of software that implements new cryptosystems even if such advances break current digital signature mechanisms.

[HASHSIG] specifies the conventions for using the Leighton-Micali Signature (LMS) algorithm, and it is in the final stages of approval in the IRTF CFRG. [HASHSIG-COSE] specifies the conventions for these digital signatures with the CBOR Object Signing and Encryption (COSE) [RFC8152] syntax. The LMS algorithm is one form of hash-based digital signature; it can only be used for a fixed number of signatures. The LMS algorithm uses small private and public keys, and it has low computational cost; however, the signatures are quite large. The mechanism has broader applicability than SUIT, so a home that supports the broader perspective is desirable.

Ongoing work includes:

MUD

I also want to (again) point you to “Manufacturer Usage Description Specification” (MUD) which was developed in the Operations and Management Area Working Group (opsawg). MUD holds significant promise, and I am pleased to see that it is gaining some serious traction: The Internet Engineering Steering Group (IESG) recently approved it as a proposed standard.

From the abstract: This memo specifies a component-based architecture for manufacturer usage descriptions (MUD). The goal of MUD is to provide a means for Things to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects.

Eliot Lear, one of the MUD authors, has written a great article about it for the IETF Journal: Managing the Internet of Things – It’s All About Scaling.

As I have noted in previous IoT Rough Guides, MUD also plays a significant role in the project – Mitigating IoT-Based Automated Distributed Threats – being developed by the US National Institute of Standards and Technology (NIST) National Cybersecurity Center of Excellence (NCCoE).

If you have an interest in how the IoT is developing and being standardized in the IETF, I hope to see you in person or online at some of these meetings during IETF 102. (Note that If you know you will be unable to travel to the meeting and would like to participate remotely, you must register as a remote participant. There is currently no fee to be a remote participant at an IETF meeting but registration is required. If you do not want to register, you may opt to listen to the live audio stream of the sessions instead.)

Schedule and locations subject to change. Please refer to the online agenda to confirm. All times Montreal Time: EDT (UTC-4)

6LO (IPv6 over Networks of Resource-constrained Nodes) WG
Tuesday, 17-July 2018, 13:30-15:30, Duluth Meeting Room
Agenda/Materials
Documents
Charter

6TISCH (IPv6 over the TSCH mode of IEEE 802.15.4e) WG
Wednesday, 18-July 2018, 13:30-15:00, Duluth Meeting Room
Agenda/Materials
Documents
Charter

ACE (Authentication and Authorization for Constrained Environments) WG
Monday, 16 July 2018, 09:30-12:00, Viger Meeting Room
Agenda/Materials
Documents
Charter

CORE (Constrained RESTful Environments) WG
Monday, 16 July 2018, 15:50-17:50, Duluth Meeting Room
Thursday, 19 July 2018, 18:10-19:10, Van Horne meeting room
Agenda/Materials
Documents
Charter

HOMENET (Home Networking) WG
Wednesday, 18-July 2018, 15:20-16:50, Centre Ville Meeting Room
Agenda/Materials
Documents
Charter

IPWAVE (IP Wireless Access in Vehicular Environments) WG
Monday, 16 July 2018, 13:30-15:30, Laurier Meeting Room
Agenda/Materials
Documents
Charter

LPWAN (IPv6 over Low Power Wide-Area Networks) WG
Thursday, 19 July 2018, 09:30-12:00, Centre Ville Meeting Room
Agenda/Materials
Documents
Charter

LWIG (Light-Weight Implementation Guidance) WG
Friday, 20 July 2018, 11:50-13:20, Duluth Meeting Room
Agenda/Materials
Documents
Charter

OPSAWG (Operations and Management Area) WG
Tuesday, 17 July 2018, 15:50-18:20, Blenheim meeting room
Agenda/Materials
Documents
Charter

ROLL (Routing Over Low power and Lossy networks) WG
Tuesday, 17 July 2018, 09:30-12:00, Duluth Meeting Room
Agenda/Materials
Documents
Charter

SUIT (Software Updates for Internet of Things) WG
Wednesday, 18 July 2018, 09:30-12:00, Duluth Meeting Room
Agenda/Materials
Documents
Charter

T2TRG (Thing-to-Thing) RG
Thursday, 19 July 2018, 15:50-17:50, Laurier meeting room
Agenda/Materials
Documents
Charter

TEEP (Trusted Execution Environment Provisioning) WG
Monday, 16 July 2018, 13:30-15:30, Viger Meeting Room
Agenda/Materials
Documents
Charter

Follow Us

It will be a busy week in Montreal, and whether you plan to be there or join remotely, there’s much to monitor. Read the full series of Rough Guide to IETF 102 posts, and follow us on the Internet Society blogTwitter, or Facebook using #IETF102 to keep up with the latest news.

Categories
Building Trust Events IETF Improving Technical Security Open Internet Standards

Rough Guide to IETF 102: Internet Infrastructure Resilience

As usual, in this post I’ll focus on important work the IETF is doing that helps improve the security and resilience of the Internet infrastructure.

At IETF 102 there are a lot of new ideas being brought to the community in the form of Internet Drafts aimed at improving the security and resilience of the Internet infrastructure, and I’d like to introduce some of them to you. But keep in mind – an Internet Draft does not indicate IETF endorsement, is not a standard, and may not result in any further work at the IETF.

So, let us look at what is happening in the domain of BGP, the routing protocol that connects the Internet.

Route leaks

There has been slow progress in the work on mitigating route leaks in the IDR Working Group (WG). One of the reasons for the slowness was that the group was considering two proposals addressing the route leak problem and both are IDR WG documents:  “Methods for Detection and Mitigation of BGP Route Leaks”, and “Route Leak Prevention using Roles in Update and Open Messages”. Plus, there is a third submission “Route Leak Detection and Filtering using Roles in Update and Open Messages” that also provides a solution in this area.

Fortunately, it seems that the relationship between all three is clearer now. Preventing route leaks locally by the potential culprit is described in draft-ietf-idr-bgp-open-policy. It also defines roles that can be useful in other solutions. draft-ietf-idr-route-leak-detection-mitigation now incorporates some ideas from draft-ymbk-idr-bgp-eotr-policy and is focused on detection and mitigation of the leaks upstream, more than one hop away from the culprit. In other words, the group is now working on two complementary and not conflicting solutions. Hopefully that will help with finalizing them soon.

Leveraging RPKI for proven operational practices

A common best practice to ensure that one’s customers only announce their own networks and the networks of their customers, is to build prefix filters. In fact, this should become a norm for every network, as defined in Action 1 of MANRS.

In the case where there are only direct customer relationships (i.e. the network’s customers are all “stub networks”), the task is relatively easy – one needs to collect the list of prefixes legitimately originated by these customer networks. This is most commonly done by using an IRR and collecting corresponding “route” objects, but with the proliferation of RPKI this can become a more robust process using cryptographically verifiable ROA objects that serve a similar purpose.

If you are a bigger network and some of your customers also provide transit services for smaller networks, the task is more difficult. How does one determine who are the customers of one’s customers and so on?

To help with this task, there is a special IRR object – “as-set”. This object is a list of ASNs or other “as-sets” that defines a customer cone of a particular AS. However, when it comes to RPKI, there is no way for an operator to assert the routes for its customer networks, making it difficult to use the information carried by RPKI to create meaningful prefix filters without relying on RPSL “as-sets”.

The Internet Draft “RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous Systems Numbers To Facilitate BGP Filtering” tries to fix that problem by introducing a new attestation object, called an AS-Cone.  An AS-Cone is a digitally signed object with the goal of enabling operators to define a set of customers that can be considered transit customer networks, thereby facilitating the construction of prefix filters for a given ASN and making routing more secure.

By leveraging RPKI, AS-Cone also addresses two fundamental problems with the RPSL “as-set”:

  • the same AS-SET name can exist in multiple IRRs,
  • a relying party does not know which “as-set” belongs to which ASN, and which as-set to use.

Validating AS-PATH without BGPsec

The Border Gateway Protocol (BGP) was designed with no mechanisms to validate BGP attributes. The ability to manipulate one of them – AS_PATH – creates one of the more serious vulnerabilities of the Internet routing system. BGPsec was designed to solve the problem of AS_PATH correctness.

But according to the authors of a new Internet Draft, “Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization“, even leaving aside its complexity, its backward compatibility with ‘insecure’ BGP allows an attacker to mount a downgrade attack to nullify all the work of AS_PATH signing. The authors suggest a more pragmatic approach that can help leveraging the benefits of RPKI without the need for the ubiquitous deployment of BGPsec. The idea is that any AS can declare its upstream providers and peers – the networks that can propagate its prefix announcements. The more networks do that – the more chances to detect misconfigurations (malicious or not).

The draft defines the semantics of Autonomous System Provider Authorization (ASPA) objects that should become part of RPKI. ASPAs are digitally signed objects that bind a in a selected AFI Provider AS number to a Customer AS number (in terms of BGP announcements, not business), and are signed by the holder of the Customer AS.  An ASPA attests that a Customer AS holder (CAS) has authorized a particular Provider AS (PAS) to propagate the Customer’s IPv4/IPv6 announcements, e.g. to the Provider’s upstream providers or peers.

Using blockchain to secure IP addresses allocation, delegation and bindings

While RPKI technology offers the significant benefits of cryptographically secured authentication and authorisation of ownership of Internet number resources (IP address blocks and AS numbers), aligned with the distribution hierarchy of Internet number resources, it has also raised some concerns. The concerns are mostly related to centralization of routing authority and creating single points of failure, or even kill switches, represented by the  RIRs and IANA.

A technology that can facilitate building cryptographically strong and credible ledgers, without relying on a hierarchical system, is blockchain. Can it be applied in this case?

The Internet Draft, “An analysis of the applicability of blockchain to secure IP addresses allocation, delegation and bindings“, looks at how blockchain technology can be used to secure the allocation, delegation, and binding to topological information of the IP address space.  The main outcomes of the analysis are that blockchain is suitable in environments with multiple distrusting parties and that Proof of Stake is a potential candidate for a consensus algorithm.

However, several questions remain open, such as the balance of power between providers and customers, enforcement of RIR policies, incentives for adoption or deployment cost.

As you can see, the meeting in Montreal is certainly going to be full of interesting discussions in the area of Internet infrastructure resilience, and will hopefully lead to some important work, specifications and improvements to the fabric of the network that we all depend on for so much.

Related Working Groups at IETF 102

SIDROPS (SIDR Operations) WG
Agenda: https://datatracker.ietf.org/meeting/102/agenda/sidrops/
Charter: https://datatracker.ietf.org/wg/sidrops/charter/

GROW (Global Routing Operations) WG
Agenda: https://datatracker.ietf.org/meeting/102/agenda/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/

IDR (Inter-Domain Routing) WG
Agenda: https://datatracker.ietf.org/meeting/102/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/

DOTS (DDoS Open Threat Signaling) WG
Agenda: https://datatracker.ietf.org/meeting/102/agenda/dots/
Charter: https://datatracker.ietf.org/wg/dots/charter/

Follow Us

It will be a busy week in Montreal, and whether you plan to be there or join remotely, there’s much to monitor. Read the full series of Rough Guide to IETF 102 posts, and follow us on the Internet Society blog, Twitter, or Facebook using #IETF102 to keep up with the latest news.

Categories
Building Trust Events IETF Open Internet Standards Technology

Rough Guide to IETF 102

Starting next weekend, the Internet Engineering Task Force will be in Montreal for IETF 102, where over 1,000 engineers will discuss open Internet standards and protocols. The week begins on Saturday, 14 July, with a Hackathon and Code Sprint. The IETF meeting itself begins on Sunday and goes through Friday. We’ll be providing our rough guides on topics of mutual interest to both the IETF and the Internet Society as follows:

For more general information about IETF 102 see:

Immediately prior to the IETF meeting, ICANN are hosting a DNS Symposium on the theme “Attention, Domain Name System: Your 30-year scheduled maintenance is overdue.” The ICANN DNS Symposium will take place in the same venue as the IETF 102 meeting on Friday 13th July.

Here are some of the activities that the Internet Society is involved in during the week.

Applied Networking Research Workshop (ANRW 2018)

The ACM, IRTF and ISOC Applied Networking Research Workshop will take place on the Monday of IETF week, as part of the Internet Research Task Force (IRTF) mission to foster greater collaboration between researchers and the IETF community. Registration is free for IETF attendees.  The ANRW program is full of great presentations including invited talks and features sessions on TLS, routing, Internet infrastructure, congestion control, traffic engineering, and anonymous communications. The workshop will also feature an extensive poster session.

The workshop will be livestreamed for those not able to attend in person:

9:30-12:00 Monday July 16 Morning session I
http://www.meetecho.com/ietf102/anrw/

13:30-17:50 Monday July 16 Afternoon sessions I and II
http://www.meetecho.com/ietf102/anrw_II/

Applied Networking Research Prize (ANRP)

Through the Applied Networking Research Prize (ANRP), supported by the Internet Society, the Internet Research Task Force (IRTF) recognizes the best new ideas in networking and brings them to the IETF, especially in cases where the ideas are relevant for transitioning into shipping Internet products and related standardization efforts. Out of 55 submissions in 2018, six submissions will be awarded prizes. Two winners will present their work at the IRTF Open Meeting on Tuesday, 17 July at 9:30AM.

GCSC Panel

On Tuesday, 17 July, during IETF 102 in Montreal, the Global Commission on the Stability of Cyberspace (GCSC) will host a lunch panel on “Cyber Diplomacy Meets InfoSec and Technology.” During this session, the Commission wants to inform and engage with the IETF community on its work so far and the work that is in the pipeline.

The Global Commission on the Stability of Cyberspace sets out to develop proposals for norms and policies to enhance international security and stability and guide responsible state and non-state behavior in cyberspace. During this lunch panel GCSC want to engage with the IETF community to discuss the norms they have proposed so far:

In addition, the Commission want to talk about the work that they are currently undertaking on vulnerabilities, their exploitation and disclosure.

The panelists are:

  • Irina Rizmal, Research Fellow at the DiploFoundation specialized in policy analysis in matters pertaining to national security and defense.
  • Bill Woodcock, Commissioner and Executive Director at Packet Clearing House, the non-profit agency that supports critical Internet infrastructure.
  • Jeff Moss, Commissioner, founder of Black Hat and Defcon, member of the DHS security council, and former ICANN CSO.

The panel will be moderated by Olaf Kolkman, GCSC Commissioner and Chief Internet Technology Officer of the Internet Society.

IETF Journal

The IETF Journal provides an easily understandable overview of what’s happening in the world of Internet standards, with a particular focus on the activities of the IETF Working Groups. Articles highlight some of the hot issues being discussed in IETF meetings and on the IETF mailing lists. You can follow IETF Journal via our Twitter and Facebook channels. If you would like to write for the Journal about your work at IETF 102, please email us at ietfjournal@isoc.org.

Other highlights of the IETF 102 meeting include:

Hackathon

Right before IETF 102, the IETF is holding another Hackathon to encourage developers to discuss, collaborate, and develop utilities, ideas, sample code, and solutions that show practical implementations of IETF standards. The Hackathon is free to attend but has limited seats available. Technologies from past Hackathons include DNS, HTTP 2.0, NETVC, OpenDaylight, ONOS, VPP/FD.io, RiOT, SFC, TLS 1.3, WebRTC, YANG/NETCONF/RESTCONF. Details on all planned technologies will be listed on the IETF 102 Meeting Wiki.

Technical Plenary

One of the week’s highlights is the plenary meeting. It will take place on Wednesday, 18 July, from 17:10-19:40. The event is live streamed.

Birds of a Feather (BoF) Sessions

Another major highlight of every IETF is the new work that gets started in birds-of-a-feather (BoF) sessions. Getting new work started in the IETF usually requires a BoF to discuss goals for the work, the suitability of the IETF as a venue for pursuing the work, and the level of interest in and support for the work. There are three BoFs happening in Montreal:

  • DNS Resolver Identification and Use (driu)Thursday, 19 July, 15:50-17:50 The IETF has added additional methods for DNS stub resolvers to get to recursive resolvers (notably DNS-over-TLS, RFC 7858), and is about to add another (DNS-over-HTTPS, from the DOH Working Group). As these have been developed, questions have been raised about how to identify these resolvers from protocols such as DHCP and DHCPv6, what the security properties these transports have in various configurations (such as between strict security and opportunistic security), and what it means for a user who has multiple resolvers configured when the elements of the configured set have different transports and security properties.This BoF is not intended to form a Working Group. Instead, it is meant to bring together authors of various WG and individual drafts to prevent overlap and to garner interest in particular topics.
  • Internationalization Review Procedures (i18nrp) Monday, 16 July, 13:30 – 15:30 This BOF is to examine procedural and structural options for moving forward with work on internationalization topics in the IETF, or deciding not to work on that topic.
  • The Label “RFC” (rfcplusplus) Wednesday, 18 July, 18:10 – 19:40 This BoF is intended to discuss a proposed experiment to tackle the “regrettably well-spread misconception” that all RFCs are standards.

Follow Us

It will be a busy week in Montreal, and whether you plan to be there or join remotely, there’s much to monitor. Follow us on the Internet Society blog, Twitter, or Facebook using #IETF102 to keep up with the latest news.

Categories
Building Trust Events IETF Improving Technical Security Public Policy Technology

Registration Open for “Cyber Diplomacy Meets InfoSec and Technology” Alongside IETF 102

As we recently announced, the Global Commission on the Stability of Cyberspace (GCSC) will host a lunch panel on “Cyber Diplomacy Meets InfoSec and Technology” alongside IETF 102 on Tuesday, 17 July. Registration opens today in two time slots for global time zone fairness, at 08:00 UTC and 20:00 UTC. Register here.

The Global Commission on the Stability of Cyberspace is developing norms and policy initiatives that intend to counter the risk to the overall security and stability of cyberspace due to rise of offensive cyber-activities, and especially those by states. During this session, the Commission wants to inform and engage with the IETF community on its work so far and the work that is in the pipeline.

The Internet Society is assisting with logistics. Internet Society Chief Internet Technology Officer and GCSC Commissioner Olaf Kolkman will moderate the panel. The panelists are:

  • Irina Rizmal, researcher at the DiploFoundation specialized in policy analysis in matters pertaining to national security and defense.
  • Bill Woodcock, Commissioner and Executive Director at Packet Clearing House, the non-profit agency that supports critical Internet infrastructure.
  • Jeff Moss, Commissioner, founder of Black Hat and Defcon, member of the DHS security council, and former ICANN CSO.

Venue

The panel takes place during lunch on Tuesday, 17 July, at the Fairmont The Queen Elizabeth in Montreal alongside IETF 102. Lunch will be provided to those who pre-register.

Registration

Pre-registration is required to attend this briefing panel in person. Registration is now open, so register here.

This event will also be webcast and audiocast. Pre-registration (or IETF attendance) is not required to attend online. Watch this space or the session page for more information and links on remote participation.

We hope you can join us in Montreal, or online!