Categories
IETF

IETF 101, Day 5: All Sorted, Innit?

This week is IETF 101 in London, and we’ve been bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. Friday is only a half-day, but there’s still a couple of interesting sessions to wrap-up the week.


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


Homenet starts at 09.30 GMT/UTC, and has the Homenet profile of the Babel routing protocol currently in IETF Last Call. Other drafts being discussed include the Simple Homenet Naming and Service Discovery ArchitectureOutsourcing Home Network Authoritative Naming Service, and DHCPv6 Options for Homenet Naming Architecture.

The remainder of the agenda will be a discussion about Homenet security in relation to the home perimeter, HNCP and Babel, as well as appropriate trust models and how to establish trust.

ROLL continues from where it left off on Thursday morning, also starting at 09.30 GMT/UTC. There are several drafts being discussed dealing with the issues of routing over resource constrained networks where limited updates are possible.

So that brings the IETF in London to a close, and hopefully we’ve also given you a bit of an insight into rhyming slang throughout the week. Now it’s time to follow the van, as an old music hall song goes, but don’t dilly dally on the way…

Please do read our other IETF 101-related posts … and we’ll see you at IETF 102 on 14-20 July 2018 in Montreal, Canada!

Relevant Working Groups

Categories
Community Networks Growing the Internet IETF

How Do We Connect Everyone to the Internet? An IETF 101 Technical Plenary

How do we connect everyone, everywhere, to the Internet? What role do “community networks” play in helping connect more people? How can we best use wireless spectrum and what are the issues with that? How can satellites fit into the picture? And what is the state of satellite technology? And what about the role of “space lasers”?

All that and more was the subject of yesterday’s featured panel at the Technical Plenary at IETF 101 in London.

Interested to learn more? Watch/listen to the Global Access to the Internet for All (GAIA) session TODAY (22 March) at 1:30pm UTC:
Agenda
Video/slides/chat
Audio-only

Organized by the Internet Architecture Board (IAB) and the Internet Research Task Force (IRTF), the panel was moderated by our Jane Coffin and included these speakers:

  • Leandro Navarro Moldes, Associate Professor, Universitat Politècnica de Catalunya (SLIDES)
  • Steve Song, Wireless Spectrum Research Associate, Network Startup Resource Center (SLIDES)
  • Jonathan Brewer, Consulting Engineer, Telco2 Limited (SLIDES)

You can watch the recording of the session at:

The session began with Leandro Navarro outlining how half the world is still not connected to the Internet and is not able to benefit from all the opportunities. He explored the reasons why, the challenges with business models, and the opportunities to improve the situation. He spoke about the different types of community networks and the need for small providers to cooperate and collaborate to be most effective.

Next Steve Song opened with the provocative question – do we care more about connecting refrigerators than poor people? He went on to talk about the impact of fiber optic connections in Africa – and then explained both the opportunities and challenges of using radio spectrum for communication. Steve discussed the economics and politics of spectrum allocation and finished looking at some of the upcoming next generation technologies. A key message: access diversity is critical!

Finally, Jonathan Brewer provided a view on satellite options for Internet access. He outlined typical orbits and latencies; spoke about different architectures and common deployment scenarios; and explained different satellite spectrum bands and then pros and cons. We learned about “rain fade” and other terms. He also offered three newer commercial ventures as examples of the exciting activities in the space sector.

After the panelists spoke, Jane opened the floor to questions. Attendees asked about the diversity of options, the need to include more people and regions, and more. And yes, there was a discussion about “space lasers” and how some of these new networks are building mesh networks based on using lasers between satellites.

It was an educational session that offered many ideas for how to connect the rest of the world.

If you would like to learn more and find out how to help:


Image credit: Stonehouse Photographic

Categories
IETF

IETF 101, Day 4: The Brass Tacks about DNS and Routing

This week is IETF 101 in London, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. And Thursday is probably the busiest day for us, covering the whole range of our interests.

ROLL has its first of two sessions starting at 09.30 GMT/UTC; continuing on Friday morning. There are several drafts being discussed dealing with the issues of routing over resource constrained networks where limited updates are possible.


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


There’s a choice between a couple of working groups after lunch, starting at 13.30 GMT/UTC.

DOH was chartered to create a single RFC, so clearly the draft DNS queries over HTTPS is going to be the primary focus of discussion. However, there will also be updates on the practical implementation work, and a discussion about possible future work if there is a decision to re-charter the group.

6LO runs in parallel and has a fairly busy agenda with Registration Extensions for 6LoWPAN Neighbor Discovery, and Address Protected Neighbor Discovery for Low-power and Lossy Networks having received feedback from the IESG. The drafts related to IPv6 Backbone Router and Packet Delivery Deadline time in 6LoWPAN Routing Header are being prepared for Working Group Last Calls, and there will also be updates on the 6LO applicability and use cases and from the fragmentation design team (draft-watteyne-6lo-minimal-fragment-00 and draft-thubert-6lo-forwarding-fragments-04). Finally, there’s a proposed update to RFCs 6550 and 6775 where 6LoWPAN ND nodes in a RPL domain do not participate in the routing protocol.

Following the afternoon break there’s the choice of SIDROPS, T2TRG or a joint NTP/TICTOC meeting, commencing at 15.50 GMT/UTC.

SIDROPS will be discussing several drafts related to the operational management of certificates in the RPKI, and in particular how to perform RPKI checks via a route server. There are also two drafts related to Trust Anchor Locators – one defining a TAL for RPKI with support for HTTPS URIs, whilst RPKI signed object for TAL defines how a RPKI signed object can be used to communicate a new Trust Anchor Locator to already deployed Relying Parties. There’s a working group sponsored draft on Requirements for RPKI Relying Parties, and finally a new proposed draft on Origin Validation Policy Considerations for Dropping Invalid Routes (not yet published).

T2TRG researches the issues of turning the IoT into reality, and will be discussing a key draft State-of-the-Art and Challenges for the Internet of Things Security. There will also be presentations on Deep learning on microcontrollers, Secure Computations in Decentralized Environments, and Semantic Interoperability Testing.

The NTP/TICTOC joint session is focusing on Network Time Security (NTS). This represents a significant update for NTP server authentication as secure and accurate time synchronization is vitally important for the proper operation of security protocols.

If you still have any remaining energy, there’s a couple of evening sessions starting at 18.10 GMT/UTC.

DNSOP holds its second session of the week, and the main draft of interest is the Multi-Provider DNSSEC Model that relates to deploying DNSSEC in environments where multiple DNS providers are in use.

Last but not least, UTA will be discussing drafts on Strict Transport Security (STS) for mail (SMTP) transfer agents and mail user agents as well as SMTP Require TLS Option.

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

Relevant Working Groups

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

IETF 101, Day 3: TLS & DPRIVE is no Diet Coke

This week is IETF 101 in London, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. There’s plenty of variety on Wednesday, following the themes of Trust and Identity, IPv6 and the Internet-of-Things.

TLS has its second session of the week starting at 09.30 GMT/UTC, and will be focused on the big development of the TLS 1.3 specification being approved by the IESG. Some further work is required, but there are a number of TLS 1.3 related drafts up for discussion.

These include Datagram Transport Layer SecurityDTLS Connection Identifer,  Exported authenticators in TLSDANE Record and DNSSEC Authentication Chain Extension for TLS, TLS Certificate compression, SNI Encryption in Tunnelling via TLS, and Semi-static DH Key Establishment in TLS 1.3.


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


Running in parallel is LPWAN which is working on enabling IPv6 connectivity with very low wireless transmission rates between battery-powered devices spread across multiple kilometres. There’s a draft providing an overview of the set of LPWAN technologies under consideration by the IETF, two other working group sponsored drafts on LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP, as well as five individual drafts related to SCHC.

After lunch there’s a choice of DPRIVE or 6TiSCH starting at 13.30 GMT/UTC.

DPRIVE will have two major topics of discussion, starting with recommendations for best current practices for those operating DNS privacy servers, building on the work of the DNS Privacy Project. There will also be a discussion on how to add privacy to the communication between a DNS recursive resolver and the authoritative DNS server for a given domain.

Finally, given that original focus of the Working Group was on stub-to-recursive-resolver connections which is now basically done from a standards perspective, there is interest in moving to next phase of privacy. A discussion on how to re-charter the group has therefore been scheduled.

6TiSCH has a full agenda, with the 6top protocol that enables distributed scheduling now being targeted for an IESG Last Call, and the security functionality (https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-05 and https://tools.ietf.org/html/draft-ietf-6tisch-6top-sfx-01) being prepared for Working Group Last Calls.

ACME rounds off the day from 15.30 GMT/UTC, where the main order of business is the core specification of the Automatic Certificate Management Environments that has been submitted to the IESG for publication. The meeting will also discuss the TLS ALPN challenge that allows for domain control validation using TLS, as well as using STIR with ACME to provide cryptographic authentication for telephone calls.

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

Relevant Working Groups

Categories
Deploy360 Domain Name System Security Extensions (DNSSEC) IETF Improving Technical Security IPv6 Open Internet Standards

IETF 101, Day 2: A Bit of Rosie Lee (Mobility)

This week is IETF 101 in London, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. After a hectic Monday there’s less dashing around needed today, although there’s a few things to highlight, even if you’ll have to choose between them as they’re unfortunately all scheduled at the same time.


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


DNSOP starts its first of two sessions at 15.50 GMT/UTC (it continues on Thursday. Several of the drafts under discussion relate to the Root KSK Rollover and how to better automate and monitor key rollovers.

At the same time, DOTS is also meeting and has a bit of a mixed agenda with four drafts up for discussion, implementation reports, and feedback on the Hackathon.

There are two drafts covering the Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel and Data Channel specifications, one that establishes an architecture for establishing and maintaining signalling within and between domains, with the last one presenting use cases describing the interactions expected between DOTS components and messaging exchanges.

Alternatively, DMM has a very busy agenda with no less than thirteen drafts under discussion. A selection of these includes DMM deployment Models and Architectural Considerations, Proxy Mobile IPv6 extensions for Distributed Mobility ManagementSegment Routing IPv6 for Mobile User Plane, and Segment Routing IPv6 as Data Plane for 3GPP N9 Interface (still awaiting draft to be published). Worth highlighting too, is the draft on Optimized Mobile User Plane Solutions for 5G.

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

Relevant Working Groups

Categories
Deploy360 Domain Name System Security Extensions (DNSSEC) IETF Improving Technical Security IPv6 Open Internet Standards

IETF 101, Jour 2: Un peu de Rosie Lee (Mobilité)

IETF 101 se déroule cette semaine à Londres. L’équipe de technologie Internet de l’ISOC vous apporte tous les jours des articles de blog mettant en évidence les sujets que nous jugeons intéressants.  Après un lundi mouvementé, il y a moins de choses à faire aujourd’hui, bien qu’il y ait quelques points à souligner, même si vous devez choisir entre eux car ils sont malheureusement tous programmés en même temps.


À savoir : Si vous ne pouvez pas être présent à l’IETF 101 en personne, il y a plusieurs façons de participer à distance.

Pour plus de détails cliquez ici

 

 

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

IETF 101, Day 1: Would You IPv6 It?

It’s another packed week at IETF 101 in London, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. Monday is a very full day with two important IPv6 working groups, one on IoT, a couple on routing, and another couple related to crypto.

The week begins bright and early at 09.00 GMT/UTC with V6OPS, although it has a relatively light agenda with a discussion on implementing IPv6-preferred data centres to start the meeting, and 7 drafts on which comments are being requested.
The couple of new drafts are Requirements for IPv6 Routers that defines a set of recommendations for routers, switches, and middleboxes deployed in IPv6 networks; and Using Conditional Router Advertisements for Enterprise Multihoming that proposes a solution to the problem of enterprise multihoming without address translation by using Router Advertisements to influence the host source address.
The five existing drafts up for discussion are NAT64 Deployment Guidelines in Operator and Enterprise NetworksIPv6 Point-to-Point Links; Transition Requirements for IPv6 Customer Edge Routers to support IPv4IPv6 Performance Measurement with Alternate Marking Method; and IP Fragmentation Considered Fragile.

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


IPWAVE is running in parallel with V6OPS. It’s focusing on a couple of working group-sponsored drafts including a specification for transmitting IPv6 Packets over IEEE 802.11 Networks in Vehicle-to-Internet and Vehicle-to-Infrastructure communications; and defining the use cases for IP-based vehicular networks, but will also be discussing re-chartering.

6MAN meets straight after lunch at 13.30 GMT/UTC. This has 7 drafts up for discussion, as well as an update on multi-vendor interoperability testing results.
The new drafts are Privacy Extensions for Stateless Address Autoconfiguration in IPv6 that describes an extension that causes nodes to generate global scope addresses from interface identifiers that change over time; Recommendation on Temporary IPv6 Interface Identifiers specifies a set of requirements for generating temporary addresses and clarifies the stability requirements for IPv6 addresses; whilst Unified Identifier in IPv6 Segment Routing Networks extends the use of IPv6 Segment Routing Headers to segment identifiers encoded as MPLS labels and IPv4 addresses.
The other drafts include IPv6 Node Requirements; IPv6 Segment Routing Header; ICMPv6 errors for discarding packets due to processing limits; and IPv6 Router Advertisement IPv4 Unavailable Flag aims to update RFC 5175.
Following the afternoon break, there’s a choice between IDR or the Crypto Forum starting at 15.50 GMT/UTC.
IDR will be discussing a working group sponsored draft addressing the problem of route leaks – Methods for Detection and Mitigation of BGP Route Leaks – along with drafts on BGP Link State Extensions for IPv6 Segment Routing; and BGP Signaling of IPv6-Segment-Routing-based VPN Networks. There are also drafts on BGP-LS Extension for Inter-AS Topology Retrieval Under Different ScenarioBGP Extended Community for Identifying the Target Node; and BGP Link-State Extensions for BGP-only Fabric.
The Crypto Forum has yet to publish an agenda, but have recently been discussing drafts on the Transition from Classical to Post-Quantum CryptographyRe-keying Mechanisms for Symmetric KeysSPAKE2 (a secure, efficient password based key exchange protocol); Augmented Password-Authenticated Key Exchange (AugPAKE); Verifiable Random Functions (VRFs)The memory-hard Argon2 password hash and proof-of-work function; Hash-based SignaturesXMSS: Extended Hash-Based Signatures; and AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption.

In the evening session starting at 17.40 GMT/UTC, there’s a choice of TLS, DHC or GROW.

This is the first TLS session of the week, and the important TLS 1.3 agenda items will be covered during the Wednesday session.  This session will discuss drafts on TLS Options for Negotiation of Visibility in Datacenters and Record Header Extensions for (D)TLS; and there will also be a discussion on TLS-SRP that a set of cryptographic protocols that provide secure communication based on passwords.

DHC has three IPv6-related drafts on its agenda, including DHCPv4 over DHCPv6 Source Address OptionYANG Data Model for DHCPv6 Configuration; and Link Layer Addresses Assignment Mechanism for DHCPv6.

Finally, GROW has an interesting agenda item relating to IRR vs RPKI parity regarding AS-SETs.

For more background, please read the Rough Guide to IETF 101 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 Open Internet Standards Technology

Rough Guide to IETF 101: DNSSEC, DANE, DNS Security and Privacy

It’s going to be a crazy busy week in London next week in the world of DNS security and privacy! As part of our Rough Guide to IETF 101, here’s a quick view on what’s happening in the world of DNS.  (See the full agenda online for everything else.)

IETF 101 Hackathon

As usual, there will be a good-sized “DNS team” at the IETF 101 Hackathon starting tomorrow. The IETF 101 Hackathon wiki outlines the work (scroll down to see it). Major security/privacy projects include:

  • Implementing some of the initial ideas for DNS privacy communication between DNS resolvers and authoritative servers.
  • Implementation and testing of the drafts related to DNS-over-HTTPS (from the new DOH working group).
  • Work on DANE authentication within systems using the DNS Privacy (DPRIVE) mechanisms.

Anyone is welcome to join us for part or all of that event.

Thursday Sponsor Lunch about DNSSEC Root Key Rollover

On Thursday, March 22, at 12:30 UTC, ICANN CTO David Conrad will speak on “Rolling the DNS Root Key Based on Input from Many ICANN Communities“. As the abstract notes, he’ll be talking about how ICANN got to where it is today with the Root KSK Rollover – and about the open comment period on the plan to roll the KSK in October 2018.

David’s session will be streamed live for anyone wishing to view remotely.

DNS Operations (DNSOP)

The DNS sessions at IETF 101 really begin on Tuesday, March 20, with the DNS Operations (DNSOP) Working Group from 15:50 – 18:20 UTC. Several of the drafts under discussion will relate to the Root KSK Rollover and how to better automate and monitor key rollovers. DNSOP also meets on Thursday, March 22, from 18:10-19:10, where one draft of great interest will be draft-huque-dnsop-multi-provider-dnssec. This document explores how to deploy DNSSEC in environments where multiple DNS providers are in use. As per usual, given the critical role DNS plays, the DNSOP agenda has many other drafts up for discussion and action.

DNS PRIVate Exchange (DPRIVE)

The DPRIVE working group meets Wednesday afternoon from 13:30-15:00 UTC.  As shown on the agenda, there will be two major blocks of discussion. First, Sara Dickinson will offer recommendations for best current practices for people operating DNS privacy servers. This builds off of the excellent work she and others have been doing within the DNS Privacy Project.

The second major discussion area will involve Stephane Bortzmeyer discussing how to add privacy to the communication between a DNS recursive resolver and the authoritative DNS server for a given domain.  When the DPRIVE working group was first chartered, the discussion was whether to focus on the privacy/confidentiality between a stub resolver and the local recursive resolver; or between the recursive resolver and authoritative server; or both. The discussion was to focus on the stub-to-recursive-resolver connection – and that is now basically done from a standards perspective. So Stephane is looking to move the group on into the next phase of privacy. As a result, the session will also include a discussion around re-chartering the DPRIVE Working Group to work on this next stage of work.

Extensions for Scalable DNS Service Discovery (DNSSD)

On a similar privacy theme, the DNSSD Working Group will meet Thursday morning from 9:30-12:00 UTC and include a significant block of time discussing privacy and confidentiality.  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. draft-ietf-dnssd-privacy-03 and several related drafts explore how to add privacy protection to this mechanism. The DNSSD agenda shows more information.

DNS-Over-HTTPS (DOH)

IETF 101 will also feature the second meeting of one of the working groups with the most fun names – DNS Over HTTPS or… “DOH!” This group is working on standardizing how to use DNS within the context of HTTPS. It meets on Thursday from 13:30-15:30. As the agenda indicates, the focus is on some of the practical implementation experience and the work on the group’s single Internet-draft: draft-ietf-doh-dns-over-https.

DOH is an interesting working group in that it was formed for the express purpose of creating a single RFC. With that draft moving to completion, this might be the final meeting of DOH – unless it is rechartered to do some additional work.

DNSSEC Coordination informal breakfast meeting

Finally, 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 Wednesday 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 101:

DNSOP (DNS Operations) WG
Tuesday, 20 March 2018, 15:50-18:30 UTC, Sandringham
Thursday, 22 March 2018, 18:10-19:10 UTC, Sandringham

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

DPRIVE (DNS PRIVate Exchange) WG
Wednesday, 21 March 2018, 13:30-15:00 UTC, Balmoral
Agenda: https://datatracker.ietf.org/meeting/101/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, 22 March 2018, 9:30-12:00 UTC, Buckingham
Agenda: https://datatracker.ietf.org/meeting/101/agenda/dnssd/
Documents: https://datatracker.ietf.org/wg/dnssd/
Charter: http://tools.ietf.org/wg/dnssd/charters/

DOH (DNS over HTTPS) WG
Thursday, 22 March 2018, 13:30-15:30 UTC, Blenheim
Agenda: https://datatracker.ietf.org/meeting/101/agenda/doh/
Documents: https://datatracker.ietf.org/wg/doh/
Charter: http://tools.ietf.org/wg/doh/charters/

Follow Us

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

Categories
Building Trust Encryption Events Identity IETF Improving Technical Security Open Internet Standards Privacy Technology Transport Layer Security (TLS)

Rough Guide to IETF 101: Privacy, Identity, and Encryption

It’s that time again! In this post of the Rough Guide to IETF 101, I’ll take a quick look at some of the identity, privacy, and encryption related activities at IETF this coming week. Below a few of the many relevant activities are highlighted, but there is much more going on so be sure to check out the full agenda online.

Encryption

Encryption continues to be a priority of the IETF as well as the security community at large. Related to encryption, there is the TLS working group developing the core specifications, several working groups addressing how to apply the work of the TLS working group to various applications, and the Crypto-Forum Research Group focusing on the details of the underlying cryptographic algorithms.

The Transport Layer Security (TLS) Working Group is a key IETF effort developing core security protocols for the Internet. The big news out of this working group is the IESG approval of the TLS 1.3 specification. There is still some way to go before final publication, but the end is in sight.

There will be two TLS sessions this week. The Monday session will focus primarily on the ongoing discussion of data center operator concerns for the use of DTLS in their environments. There is an updated proposal on a “TLS 1.3 Option for Negotiation of Visibility In the Datacenter”. This is sure to continue to be a contentious topic in the TLS working group as it struggles with whether or not to adopt this work.

The Wednesday session will address a number of ongoing drafts including:

The TLS working group is very active and, as with all things that are really important, there are many diverse opinions to fill the room.

The Using TLS in Applications (UTA) Working Group was chartered to look at updating the definitions for using TLS with various application protocols. It has finished a number of documents already including recommendations for the secure use of TLS and DTLS, use of TLS for XMPP, and the use of TLS server identity check procedures for email. The main portion of the meeting will discuss issues raised on a draft related to Strict Transport Security (STS) for mail (SMTP) transfer agents and mail user agents. Also on the agenda is a draft on an option to require TLS for SMTP. There is a new draft on TLS/DTLS 1.3 profiles for IoT that may get some discussion time, but isn’t currently listed on the agenda.

The next activity of potential interest to the encryption community is the Crypto Forum Research Group (cfrg). A key work item of this research group that is nearing completion is hash based signatures. I also see updated drafts on Verifiable Random Functions, Hashing to Elliptic Curves, and Verifiable Oblivious Pseudorandom Functions. The agenda isn’t posted yet so I’m not sure what else might appear, but I am sure it will be an interesting and engaging discussion.

There are two other sessions that will be of interest to folks generally interested in encryption in protocols.

The first is a BoF on Message Layer Security (mls). Many internet applications need group key-establishment and a message protection protocol with features like asynchronicity, forward secrecy, membership authentication and message authentication. The goal of this proposed working group is to develop a standard security protocol so that applications can share code and so that there can be shared validation of the protocol (as there has been with TLS 1.3), not the interoperability of messaging protocols. The Messaging Layer Security BoF is a working group-forming session exploring whether there is sufficient interest and scope to form a working group on the topic. The agenda includes a problem statement, architecture, draft protocol, a report on formal analysis, and a discussion of charter. Some key drafts include https://datatracker.ietf.org/doc/draft-omara-mls-architecture and https://datatracker.ietf.org/doc/draft-barnes-mls-protocol.

Finally, the QUIC Working Group is striving to provide a standards-track specification for a UDP-based, stream-multiplexing, encrypted transport protocol. This has been a very active working group in the IETF. While this is a Transport Area effort, the fact that encryption is a key aspect and being designed in from the beginning is of interest to encryption enthusiasts.

Certificates

Moving on from cryptography and encryption, the next set of IETF working groups are related to the certificate infrastructure for the Internet, acme and lamps.

The Automated Certificate Management Environment (acme) Working Group is specifying ways to automate certificate issuance, validation, revocation and renewal. The main order of business at this week’s meeting is to discuss the core specification Automatic Certificate Management Environment. This document has been submitted to the IESG for publication, and this meeting will focus on addressing the feedback received to date. The meeting will also discuss the TLS ALPN challenge, and some STIR topics.

The Limited Additional Mechanisms for PKIX and SMIME (lamps) Working Group is engaged in some maintenance activities around PKIX and SMIME. A number of working group documents have been submitted to the IESG, and this week’s agenda will discuss DNS Certification Authority Authorization (CAA) Resource Record, additional SHAKE algorithms and identifiers, and use of the SHAKE one-way has function in CMS.

Authentication and Authorization

From the certificate infrastructure, we move next to authentication and authorization and the set of related working groups tackling those issues for the IETF.

Anyone with an interest in the Internet of Things (IoT), will be interested in the Authentication and Authorization for Constrained Environments (ace) Working Group. This group is working to develop standardized solutions for authentication and authorization in constrained environments. They published a use cases document last year, and this week’s agenda includes discussion of existing working group documents on authentication and authorization for constrained environments.

The Web Authorization Protocol (oauth) Working Group has been working for years on mechanisms that allow users to grant access to web resources without necessarily compromising long term credentials or even identity. It has been a very prolific working group with around 15 RFCs published to date. IETF 101 will be another busy week for those interested in this area including sessions on both Tuesday and Wednesday. Agenda items for these two sessions include:

Additionally, the working group will discuss a potential new OAuth client assertion flow and distributed OAuth.

For those new to OAuth, there is an OAuth 2.0 tutorial planned for Sunday afternoon in the first tutorial slot. This is an excellent opportunity to get a detailed introduction to OAuth 2.0 from a key contributor to the work.

There are two additional working groups meeting this coming week that are related to the OAUTH work. The first is the Token Binding (TOKBIND) Working Group that is tasked with specifying a token binding protocol and specifying the use of that protocol with HTTPS. The second is Security Events (SECEVENT) Working Group working on an Event Token specification that includes a JWT extension for expressing security events and a syntax for communicating the event-specific data. Both of these have a strong relationship to the OAuth work.

General Security

The Network Time Protocol (NTP) Working Group addresses protocols for the accurate synchronization of clocks on a network. This may seem like a bit of a stretch for a blog post on identity, privacy, and encryption. However, accurate and secure time synchronization turns out to be vitally important for the proper operation of security protocols. The NTP WG has been working on Network Time Security (NTS) which is a significant update for NTP server authentication. This week the NTP NTS effort will focus on getting some implementation work done in the Hackathon in advance of the NTP meeting on Thursday.

For the security crowd, no IETF week is complete without the Security Area Advisory Group (SAAG) meeting. This meeting features a quick run through all the working groups doing security-related work in the IETF across all areas, a set of short talks, and an open session to bring issues and topics forward from the community. The agenda isn’t available yet, but it generally is an excellent session on security in general.

The experiment from IETF 100 on a session to quickly review and decide what to do with specific new work proposals that are being brought forward has resulted in a new working group specifically for this purpose, Security Dispatch (secdispatch). The new working group will meet for the first time this week, and it will address a method for web security policies, considerations For Using Short Term Certificates, use of the Hash-based Merkle Tree Signature (MTS) Algorithm in the Cryptographic Message Syntax (CMS), and pretty Easy privacy.

Also, don’t forget the IETF Hackathon is held this weekend, before the IETF. This IETF Hackathon has several projects of interest including work on Messaging Layer Security, TLS 1.3 testing and interoperability, EAP TLS with large certificates and long certificate chains, distributed denial of service threat signaling, and Network time security. All the potential projects of this rendition of the IETF Hackathon as listed on the IETF 101 Hackathon wiki site.

Finally, just a quick note to point out that DNS Privacy (DNSPRIV) and the Decentralized IoT Security and Standards (DISS) workshops were successfully held in conjunction with NDSS 2018. The agendas and some materials are online now, and the proceedings will be published in the coming months.

Join us for another full week for identity, and privacy, and encryption related topics here at IETF 101!

Relevant Working Groups at IETF 100:

ace (Authentication and Authorization for Constrained Environments) WG
Monday, 19 March, 09:30-12:00, Balmoral
Agenda: https://datatracker.ietf.org/doc/agenda-101-ace/
Charter: https://datatracker.ietf.org/wg/ace/about/

acme (Automated Certificate Management Environment) WG
Wednesday, 21 March, 15:20-16:50, Buckingham
Agenda: https://datatracker.ietf.org/doc/agenda-101-acme/
Charter: https://datatracker.ietf.org/wg/acme/about/

cfrg – Crypto Forum Research Group
Monday, 19 March, 15:50-17:20, Balmoral
Agenda: https://datatracker.ietf.org/meeting/101/agenda/cfrg/
Charter: https://irtf.org/cfrg

ntp (Network Time Protocol )WG
Thursday, 22 March, 15:50-17:50, Palace C
Agenda: https://datatracker.ietf.org/doc/agenda-101-ntp/
Charter: https://datatracker.ietf.org/wg/ntp/about/

oauth (Web Authorization Protocol) WG
Monday, 19 March, 15:50-17:20, Viscount
Agenda: https://datatracker.ietf.org/doc/agenda-101-oauth/
Charter: https://datatracker.ietf.org/wg/oauth/about/

quic (QUIC)
Thursday, 22 March, 09:30-12:00, Sandringham
Agenda: https://datatracker.ietf.org/meeting/101/materials/agenda-101-quic.html
Charter: https://datatracker.ietf.org/group/quic/about/

saag (Security Area open meeting)
Thursday, 22 March, 13:30-15:30, Sandringham
Agenda: https://datatracker.ietf.org/meeting/101/materials/agenda-101-saag/ (coming soon)

secdispatch (Security Dispatch)
Tuesday, 20 March, 09:30-12:00, Blenheim
Agenda: https://datatracker.ietf.org/doc/agenda-101-secdispatch/
Charter: https://datatracker.ietf.org/wg/secdispatch/about/

secevent (Security Events) WG
Friday, 23 March, 09:30-11:30, Park Suite
Agenda: https://datatracker.ietf.org/meeting/101/materials/agenda-101-secevent/
Charter: https://datatracker.ietf.org/wg/secevent/about/

tls – Transport Layer Security
Monday, 19 March, 17:40-18:40, Balmoral
Agenda: https://datatracker.ietf.org/doc/agenda-101-tls-sessa/, https://datatracker.ietf.org/doc/agenda-101-tls-sessb/
Charter: https://datatracker.ietf.org/wg/tls/about/

tokbind (Token Binding) WG
Wednesday, 21 March, 15:20-16:50, Viscount
Agenda: https://datatracker.ietf.org/meeting/101/materials/agenda-101-tokbind/
Charter: https://datatracker.ietf.org/wg/tokbind/about/

uta – Using TLS in Applications
Thursday, 22 March, 18:10-19:10, Blenheim
Agenda: https://datatracker.ietf.org/meeting/101/materials/agenda-101-uta/
Charter: https://datatracker.ietf.org/wg/uta/about/

Follow Us

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

Categories
Building Trust Deploy360 Events IETF IPv6 Open Internet Standards Technology

Rough Guide to IETF 101: IPv6

In this post for the Internet Society Rough Guide to IETF 101, I’m reviewing what’ll be happening at the IETF in London next week.

IPv6 global adoption rates continue to rise (to approximately 22% according to Google), although at a slightly slower overall rate since the last IETF. Nevertheless, there’s still substantial growth in IPv6 capability in large markets such as the United States, India and Germany, with Belgium still leading the world. There has also been significant progress in Greece, Brazil, Malaysia, Finland, Switzerland and Uruguay recently, whilst Japan, the UK and France continue to show consistent growth. The amounts of native IPv6 traffic seen on the Internet still does not entirely reflect global IPv6 capabilities, but with most major content and cloud providers now supporting IPv6, and mobile networks increasingly preferring IPv6, this gap will continue to close.

IPv6 is an important focus for the IETF, particularly with respect to the standardisation work related to the Internet-of-Things. And it’s straight into the IPv6 work on Monday, with both the IPv6 Operations (v6ops) and IPv6 Maintenance (6man) Working Groups being held that day, along with three other IoT-related Working Groups.

The IPv6 Operations (v6ops) Working Group is one of the key groups, but has a relatively light agenda this time as since the last meeting it’s published two RFCs. RFC 8273 (https://tools.ietf.org/html/rfc8273) outlines the assignment of unique IPv6 prefixes to hosts instead of from a shared IPv6, which allows unique service provider addresses to be used to improve host isolation and enhance subscriber management on shared networks. RFC 8305 (https://tools.ietf.org/html/rfc8305) provides an update to the Happy Eyeballs algorithm to reduce delays to users whilst preferring IPv6 on dual-stack networks.

The meeting kicks off first thing Monday morning with a discussion on implementing IPv6-preferred data centres. There’s then a couple of new drafts that include Requirements for IPv6 Routers (https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs-02) that defines a set of recommendations for routers, switches, and middleboxes deployed in IPv6 networks; plus Using Conditional Router Advertisements for Enterprise Multihoming (https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-01) that proposes a solution to the problem of enterprise multihoming without address translation by using Router Advertisements to influence the host source address.

There’s also five other existing drafts for which comment is still being requested. NAT64 Deployment Guidelines in Operator and Enterprise Networks (https://tools.ietf.org/html/draft-palet-v6ops-nat64-deployment-00) describes how NAT64 can be deployed in an IPv6 operator or enterprise network when there is only an IPv6 access link; IPv6 Point-to-Point Links (https://tools.ietf.org/html/draft-palet-v6ops-p2p-links-00) describes different alternatives for configuring IPv6 point-to-point links, considering the prefix size, numbering choices and prefix pool to be used; whilst Transition Requirements for IPv6 Customer Edge Routers to support IPv4 (https://tools.ietf.org/html/draft-palet-v6ops-transition-ipv4aas-00) 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. IPv6 Performance Measurement with Alternate Marking Method (https://tools.ietf.org/html/draft-fioccola-v6ops-ipv6-alt-mark-00) describes a passive performance measurement method in an IPv6 domain, with IP Fragmentation Considered Fragile (https://tools.ietf.org/html/draft-bonica-intarea-frag-fragile-01) discusses how IP fragmentation reduces the reliability of Internet communication and provides recommendations for application developers and network operators.

The IP Wireless Access in Vehicular Environments (ipwave) Working Group is running in parallel with v6ops. It is currently focused on a couple of working group-sponsored drafts including a specification for transmitting IPv6 Packets over IEEE 802.11 Networks in Vehicle-to-Internet and Vehicle-to-Infrastructure communications (https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-21); and defining the use cases for IP-based vehicular networks (https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-02). The group will also be discussing re-chartering, with a problem statement and associated security and privacy considerations due to the IESG in May 2018.

The IPv6 Maintenance (6man) Working Group is another key group, and since the last meeting has published RFC 8319 (https://tools.ietf.org/html/rfc8319) that updates the IPv6 Neighbor Discovery Protocol (RFC 4861) to increase the maximum time allowed between sending unsolicited multicast RAs from a router interface as well as to increase the maximum router lifetime. The meeting is being held on Monday afternoon and has a busy agenda with 2 working group-sponsored drafts, 2 existing drafts, and 3 new drafts, as well as an update on multi-vendor interoperability testing results.

IPv6 Node Requirements (https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis) specifies the minimum requirements for enabling effective IPv6 functionality and interoperability on nodes; whilst IPv6 Segment Routing Header (https://tools.ietf.org/html/draft-ietf-6man-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. ICMPv6 errors for discarding packets due to processing limits (https://tools.ietf.org/html/draft-herbert-6man-icmp-limits-03) defines how nodes can signal the discard of packets if they are unable to process the protocol headers; and IPv6 Router Advertisement IPv4 Unavailable Flag (https://tools.ietf.org/html/draft-hinden-ipv4flag-03) specifies a flag to indicate to hosts there’s no IPv4 service on the advertising default IPv6 router, updating RFC 5175 (https://tools.ietf.org/html/rfc5175).

The new drafts up for discussion include Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (https://tools.ietf.org/html/draft-gont-6man-rfc4941bis) that describes an extension that causes nodes to generate global scope addresses from interface identifiers that change over time; Recommendation on Temporary IPv6 Interface Identifiers (https://tools.ietf.org/html/draft-gont-6man-non-stable-iids-02) specifies a set of requirements for generating temporary addresses and clarifies the stability requirements for IPv6 addresses; with Unified Identifier in IPv6 Segment Routing Networks (https://tools.ietf.org/html/draft-mirsky-6man-unified-id-sr) extending the use of IPv6 Segment Routing Headers to segment identifiers encoded as MPLS labels and IPv4 addresses.

If you fancy staying later, the Dynamic Host Configuration (dhc) Working Group is meeting on Monday evening and has three IPv6-related drafts on the agenda. DHCPv4 over DHCPv6 Source Address Option (https://tools.ietf.org/html/draft-ietf-dhc-dhcp4o6-saddr-opt-01) defines a DHCPv6 option to convey parameters for communicating a source tunnel IPv6 address between an DHCP 4o6 client and server, in conjunction with the IPv4 address allocation process. YANG Data Model for DHCPv6 Configuration (https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-yang-06) aims to support the configuration and management of DHCPv6 servers, relays, and clients; whereas Link Layer Addresses Assignment Mechanism for DHCPv6 (https://tools.ietf.org/html/draft-bvtm-dhc-mac-assign-00) proposes an extension to DHCPv6 that allows a scalable approach to link-layer address assignments.

There doesn’t seem to be lot happening IPv6-wise on Tuesday, but if you’re feeling IPv6 withdrawal symptoms, then the Measurement and Analysis for Protocols Research Group (maprg) on Tuesday morning has three IPv6-specific agenda items. These are a discussion on measuring IPv6 performance, visualising IPv6 space, and an update on IPv6 client adoption.

The Low Power Wide-Area Networks (lpwan) Working Group meets on Wednesday morning. This is working on enabling IPv6 connectivity with very low wireless transmission rates between battery-powered devices spread across multiple kilometres, and whilst the agenda has yet to be published, there are three current working group-sponsored drafts. The overview of the set of LPWAN technologies under consideration by the IETF has now been sent to the IESG for publication (https://tools.ietf.org/html/draft-ietf-lpwan-overview), whilst the other relevant draft deals with LPWAN header compression and fragmentation for IPv6 (https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc/).

The IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) Working Group then meets on Wednesday afternoon. TSCH is the emerging standard for automation and control over low-power and lossy wireless networks, and this group is working on how to utilise IPv6 in industrial standards. There’s a very full agenda, with the 6top protocol that enables distributed scheduling (https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-10) now being targeted for an IESG Last Call, and the security functionality (https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-05 and https://tools.ietf.org/html/draft-ietf-6tisch-6top-sfx-01) being prepared for Working Group Last Calls.

Thursday is another quiet day with just the IPv6 over Networks of Resource Constrained Nodes (6lo) Working Group meeting on Thursday afternoon. It nonetheless has a fairly busy agenda with Registration Extensions for 6LoWPAN Neighbor Discovery (https://tools.ietf.org/html/draft-ietf-6lo-rfc6775-update-14) and Address Protected Neighbor Discovery for Low-power and Lossy Networks (https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-06) having received feedback from the IESG. The drafts related to IPv6 Backbone Router (https://tools.ietf.org/html/draft-ietf-6lo-backbone-router-06) that proposes proxy operations for IPv6 Neighbor Discovery on behalf of devices located on broadcast-inefficient wireless networks; and Packet Delivery Deadline time in 6LoWPAN Routing Header (https://tools.ietf.org/html/draft-ietf-6lo-deadline-time-01) are being prepared for Working Group Last Calls. There will also be updates on the 6LO applicability and use cases (https://tools.ietf.org/html/draft-ietf-6lo-use-cases-04), and from the fragmentation design team (https://tools.ietf.org/html/draft-watteyne-6lo-minimal-fragment-00 and https://tools.ietf.org/html/draft-thubert-6lo-forwarding-fragments-04). Finally, there’s a proposed update to RFCs 6550 and 6775 where 6LoWPAN ND nodes in a RPL domain do not participate in the routing protocol.

The week concludes with the Homenet Working Group (homenet) on Friday morning. This develops protocols for residential networks based on IPv6 and currently has Special Use Domain ‘home.arpa.’ awaiting publication as an RFC, with the Homenet profile of the Babel routing protocol (https://tools.ietf.org/html/draft-ietf-homenet-babel-profile-05) currently in IETF Last Call. The Simple Homenet Naming and Service Discovery Architecture (https://tools.ietf.org/html/draft-ietf-homenet-simple-naming-01) describes how names are published and resolved homenets, and how hosts are configured to use these names to discover services on homenets. The remainder of the agenda will be a discussion about Homenet security in relation to the home perimeter, HNCP and Babel, as well as appropriate trust models and how to establish trust.

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

IPv6-related Working Groups at IETF 101:

V6OPS (IPv6 Operations) Working Group
Monday, 18 March 2018 09.30-12.00 UTC, Viscount
Agenda: https://datatracker.ietf.org/meeting/101/materials/agenda-101-v6ops/
Documents: https://datatracker.ietf.org/wg/v6ops/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-v6ops/

IPWAVE (IP Wireless Access in Vehicular Environments)
Monday, 18 March 2018 09.30-12.00 UTC, Sandingham
Agenda: https://datatracker.ietf.org/meeting/101/materials/agenda-101-ipwave/
Documents: https://datatracker.ietf.org/wg/ipwave/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-ipwave/

6MAN (IPv6 Maintenance) WG
Monday, 18 March 2018 13.30-15.30 UTC, Viscount
Agenda: https://datatracker.ietf.org/meeting/101/materials/agenda-101-6man/
Documents: https://datatracker.ietf.org/wg/6man/documents/
Charter: https://datatracker.ietf.org/wg/6man/charter/

DHC (Dynamic Host Configuation) WG
Monday, 18 March 2018 17.30-18.40 UTC, Viscount
Agenda: https://datatracker.ietf.org/meeting/101/materials/agenda-101-dhc/
Documents: https://datatracker.ietf.org/wg/dhc/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-dhc/

LPWAN (IPv6 over Low Power Wide-Area Networks)
Wednesday, 20 March 2018 09.30-12.00 UTC, Viscount
Agenda: https://datatracker.ietf.org/meeting/101/materials/agenda-101-lpwan/
Documents: https://datatracker.ietf.org/wg/lpwan/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-lpwan/<

6TISCH (IPv6 over the TSCH mode of IEEE 802.15.4e)
Wednesday, 20 March 2018 13.30-15.00 UTC, Viscount
Agenda: https://datatracker.ietf.org/meeting/101/materials/agenda-101-6tisch/
Documents: https://datatracker.ietf.org/wg/6tisch/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-6tisch/

6LO (IPv6 over Networks of Resource Constrained Nodes) WG
Thursday, 21 March 2018 13.30-15.30 UTC, Buckingham
Agenda: https://datatracker.ietf.org/meeting/101/materials/agenda-101-6lo/
Documents: https://datatracker.ietf.org/wg/6lo/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-6lo/

Homenet (Home Networking) WG
Friday, 22 March 2018 09.30-11.00 UTC, Sandringham<
Agenda: https://datatracker.ietf.org/meeting/101/materials/agenda-101-homenet/
Documents: https://datatracker.ietf.org/wg/homenet/documents/
Charter: https://datatracker.ietf.org/wg/homenet/charter/

Follow Us

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

Categories
Building Trust Events IETF Improving Technical Security Internet of Things (IoT) Open Internet Standards Technology

Rough Guide to IETF 101: Internet of Things

The Internet of Things (IoT) is an increasingly hot buzzword around the Internet industry and the broader technology and innovation business arenas. We are often asked what the IETF is doing in relation to IoT and in this short Rough Guide to IETF 101 post I’d like to highlight some of the relevant sessions scheduled during the upcoming IETF 101 meeting in London. 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 IoT page for more details about many of these topics. See also this recent article in the IETF Journal: Internet of Things: Standards and Guidance from the IETF.

The IETF Hackathon, held the weekend preceding the main IETF meeting (17-18 March), will include at least four projects directly related to IoT, with the possibility of more being added. More information is on the Hackathon wiki.

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 London to report out on their recent activities. Their summary meeting agenda is here. As in the past, full details and latest info can be found in GitHub. Of particular note is a recent update of a key ID: State-of-the-Art and Challenges for the Internet of Things Security. Following IETF 101, there will be a joint meeting with the T2TRG, the Open Connectivity Foundation (OCF), and W3C Web of Things (WoT) Working Group on March 23 in Prague.

New Work

There are two newly chartered IoT-related working groups meeting for the first time in London, which are tackling very serious problems. I am pleased to see these moving forward:

Ongoing Work

The Constrained RESTful Environments (core) WG aims to extend the Web architecture to most constrained networks and embedded devices. This is one of the most active IoT working groups and they will be meeting twice in London, on Monday afternoon and Tuesday morning. They will be considering several Internet Drafts (IDs) including: CoAP Simple Congestion Control/Advanced, CoAP Management Interface, Uniform Resource Names for Device Identifiers, and Publish-Subscribe Broker for the Constrained Application Protocol (CoAP).

The IPv6 over Networks of Resource-constrained Nodes (6lo) WGfocuses on the work that facilitates IPv6 connectivity over constrained node networks with the characteristics of:

  • limited power, memory and processing resources
  • hard upper bounds on state, code space and processing cycles
  • optimization of energy and network bandwidth usage
  • lack of some layer 2 services like complete device connectivity and broadcast/multicast

They have some interesting work queued up, including discussion of a revision to RFC 6775 (Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)). They will be meeting on Thursday afternoon in London.

The IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WGwas chartered in 2014 to enable IPv6 for the Time-Slotted Channel Hopping (TSCH) mode that was recently added to IEEE 802.15.4 networks. The 6top Protocol (6P) ID was recently revised and is in IESG last call on its way to adoption – it enables distributed scheduling in 6TiSCH networks. Among the interesting things on their agenda is planning for the next F-Interop 6TiSCH Interoperability event. They are meeting on Wednesday afternoon in London.

The Home Networking (homenet) WG focuses on the evolving networking technology within and among relatively small “residential home” networks. For example, an obvious trend in home networking is the proliferation of networking technology in an increasingly broad range and number of devices. They will be meeting in London on Friday morning and discussing several interesting IDs.

The IPv6 over Low Power Wide-Area Networks (lpwan) WG will be meeting in London on Wednesday morning. Typical LPWANs provide low-rate connectivity to vast numbers of battery-powered devices over distances that may span tens of miles, using license-exempt bands. There is a recently-published LPWAN Overview. They have a very useful overview draft, recently revised.

The IP Wireless Access in Vehicular Environments (ipwave) WG has as its primary deliverable a specification for mechanisms to transmit IPv6 datagrams over IEEE 802.11-OCB mode. For more about this very timely topic, there is a recently updated ID: IP-based Vehicular Networking: Use Cases, Survey and Problem Statement. ipwave will meet on Monday morning in London.

The Authentication and Authorization for Constrained Environments (ace) WG,as its name suggests, is concerned with authentication and authorization mechanisms in constrained environments, where network nodes are limited in CPU, memory and power. This is a critical issue for IoT, for obvious reasons. The proposed standard is the subject of a recently-revised ID. ace will meet on Monday morning.

Routing for IoT is tackled by theRouting Over Low power and Lossy networks (roll) WG which focuses on routing protocols for constrained-node networks. They have 2 meetings in London: Thursday morning and Friday morning.

Finally, in addition to the new protocols and other mechanisms developed by IETF working groups, IoT developers often benefit from additional guidance for efficient implementation techniques and other considerations. The Lightweight Implementation Guidance (lwig) WGis developing such documents and they will meet in London on Wednesday afternoon. The IDs CoAP Implementation Guidance and Building Power-Efficient CoAP Devices for Cellular Networks are useful resources. lwig will be meeting in London on Wednesday afternoon.

I also want to (again) draw your attention to a very interesting (Standards Track) Internet Draft being discussed in the Operations and Management Area Working Group (opsawg) which seems to hold significant promise, and which appears to be gaining some serious traction: “Manufacturer Usage Description Specification“ (MUD). 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. The opsawg meeting will be held on Monday afternoon.

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 101. (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 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.

Related Working Groups at IETF 101

Schedule and locations subject to change. Please refer to the online agenda to confirm.

** All times London Time: GMT **

6lo (IPv6 over Networks of Resource-constrained Nodes) WG
Thursday, 22 March 2018, 13:30-15:30
Buckingham meeting room
Agenda/Materials
Documents
Charter

6tisch (IPv6 over the TSCH mode of IEEE 802.15.4e) WG
Wednesday, 21 March 2018, 13:30-15:00
Viscount meeting room
Agenda/Materials
Documents
Charter

ace (Authentication and Authorization for Constrained Environments) WG
Monday, 19 March 2018, 09:30-12:00
Balmoral Meeting Room
Agenda/Materials
Documents
Charter

core (Constrained RESTful Environments) WG
Monday, 19 March 2018, 13:30-15:30
Richmond/Chelsea/Tower Meeting Room
Tuesday, 20 March 2018, 09:30-12:00
Viscount meeting room
Agenda/Materials
Documents
Charter

homenet (Home Networking) WG
Friday, 23 March 2018, 09:30-11:30
Sandringham Meeting Room
Agenda/Materials
Documents
Charter

ipwave (IP Wireless Access in Vehicular Environments) WG
Monday, 19 March 2018, 09:30-12:00
Sandringham Meeting Room
Agenda/Materials
Documents
Charter

lpwan (IPv6 over Low Power Wide-Area Networks) WG
Wednesday, 21 March 2018, 09:30-12:00
Viscount meeting room
Agenda/Materials
Documents
Charter 

lwig (Light-Weight Implementation Guidance) WG
Wednesday, 21 March 2018, 15:20-16:50
Park Suite Meeting Room
Agenda/Materials
Documents
Charter

opsawg (Operations and Management Area) WG
Monday, 19 March 2018, 13:30-15:30
Blenheim meeting room
Agenda/Materials
Documents
Charter

roll (Routing Over Low power and Lossy networks) WG
Thursday, 22 March 2018, 09:30-12:00
Park Suite Meeting Room
Friday, 23 March 2018, 09:30-12:00
Viscount meeting room
Agenda/Materials
Documents
Charter

suit (Software Updates for Internet of Things) WG
Monday, 19 March 2018, 13:30-15:30
Buckingham meeting room
Agenda/Materials
Documents
Charter

t2trg (Thing-to-Thing) RG
Thursday, 22 March 2018, 15:50-17:50
Blenheim meeting room
Agenda/Materials
Documents
Charter

teep (Trusted Execution Environment Provisioning) WG
Tuesday, 20 March 2018, 13:30-15:30
Balmoral Meeting Room
Agenda/Materials
Documents
Charter

Follow Us

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

Categories
Building Trust Events IETF Improving Technical Security Mutually Agreed Norms for Routing Security (MANRS) Open Internet Standards Securing Border Gateway Protocol (BGP) Technology

Rough Guide to IETF 101: Internet Infrastructure Resilience

In this post of the Internet Society Rough Guide to IETF 101, I’ll focus on important work the IETF is doing that helps improve security and resilience of the Internet infrastructure.

BGP

What happens if an IXP operator begins maintenance work on the switches without ensuring that BGP sessions between the peers have been shut down? A network disruption and outage. A draft now in the RFC editor queue, “Mitigating Negative Impact of Maintenance through BGP Session Culling”, provides guidance to IXP operators on how to avoid such situations by forcefully tearing down the BGP sessions (session culling) affected by the maintenance before the maintenance activities commence. This approach allows BGP speakers to pre-emptively converge onto alternative paths while the lower layer network’s forwarding plane remains fully operational.

Another draft also in the RFC editor queue, “Graceful BGP session shutdown”, addresses issues related to planned maintenance. The procedures described in this document can be applied to reduce or avoid packet loss for outbound and inbound traffic flows initially forwarded along the peering link to be shut down.  These procedures trigger, in both Autonomous Systems (AS), rerouting to alternate paths if they exist within the AS, while allowing the use of the old path until alternate ones are learned.  This ensures that routers always have a valid route available during the convergence process.

Both recommendations have been developed in the GROW WG. They represent simple measures that can have a significant positive impact on overall stability.

RPKI and BGPSEC

The SIDR Operations Working Group (SIDROPS) has taken over the technology developed in SIDR WG and is focused on developing guidelines for the operation of SIDR-aware networks, and providing operational guidance on how to deploy and operate SIDR technologies in existing and new networks.

If you follow the work of SIDR and now SIDROPS WGs you may recall that for more than three years the participants have been discussing an issue of potential operational fragility in the management of certificates in the RPKI in response to the movement of resources across registries. Finally, the IESG has approved it and the draft is in the RFC editor queue.

Here is the summary of the proposal: “Where the procedure specified in RFC 6487 requires that Resource Certificates are rejecting entirely if they are found to over-claim any resources not contained on the issuing certificate, the validation process defined here allows an issuing Certificate Authority to choose to communicate that such Resource Certificates should be accepted for the intersection of their resources and the issuing certificate. This choice is signaled by form of a set of alternative Object Identifiers (OIDs) of RFC 3779 X.509 Extensions for IP Addresses and AS Identifiers, and certificate policy for the Resource Public Key Infrastructure (RFC 6484)”.

A possible sign of RPKI adoption is the fact that IXPs are considering or even performing RPKI checks by the route server. Route server is a common IXP component enabling multilateral peerings at the exchange point. To clarify how such validation can be performed and signalled, if necessary, to the peers, a draft “Signaling Prefix Origin Validation Results from an RPKI Origin Validating BGP Speaker to BGP Peers” is now under discussion. The main argument is whether it is productive to signal validation results instead of simply discarding “invalid” routes and maybe tagging “valid” and “unknown”. This discussion will likely surface at the meeting, too.

DDoS

DDoS attacks are a persistent and growing threat on the Internet.  And as DDoS attacks evolve rapidly in the aspect of volume and sophistication, more efficient cooperation between the victims and parties that can help in mitigating such attacks is required. The ability to quickly and precisely respond to a beginning attack, communicating the exact information to the mitigation service providers is crucial.

Addressing this challenge is what keeps the DDoS Open Threat Signaling (DOTS, http://datatracker.ietf.org/wg/dots/) WG busy. In the DOTS architecture, clients and servers communicate using DOTS signalling.  As a result of signals from a DOTS client, the DOTS server may modify the forwarding path of traffic destined for the attack target(s), for example by diverting traffic to a mitigator or pool of mitigators, where policy may be applied to distinguish and discard attack traffic.

The main work is now concentrated on defining the signal channel (https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ ) that allows a client to ask a DOTS server for help in mitigating an attack, and for the DOTS server to inform the DOTS client about the status of such mitigation. They also work on the optional data channel (https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/) that provides additional capabilities, such as configuration and policy information exchange.

To summarize – there is important work underway at the IETF that will hopefully lead to a more resilient and secure Internet infrastructure.

Related Working Groups at IETF 101

SIDROPS (SIDR Operations) WG
Thursday, 22 March, 15:50-17:50, Park Suite
Agenda: https://datatracker.ietf.org/meeting/101/agenda/sidrops/
Charter: https://datatracker.ietf.org/wg/sidrops/charter/

GROW (Global Routing Operations) WG
Monday, 19 March, 17:40-18:40, Blenheim
Agenda: https://datatracker.ietf.org/meeting/101/agenda/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/

IDR (Inter-Domain Routing) WG
Monday, 19 March, 15:50-17:20, Buckingham
Agenda: https://datatracker.ietf.org/meeting/101/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/

DOTS (DDoS Open Threat Signaling) WG
Tuesday, 20 March, 15:50-18:20, Viscount
Agenda: https://datatracker.ietf.org/meeting/101/agenda/dots/
Charter: https://datatracker.ietf.org/wg/dots/charter/

Follow Us

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