Blockchain Building Trust Deploy360 Improving Technical Security Internet of Things (IoT)

ISOC has goals at TNC18

This week is TNC18, the largest European research and education networking conference, which is being held at the Lerkendal Stadium in Trondheim, Norway – the home of current Norwegian Football Champions Rosenborg BK. Of course we’re actually in a conference centre underneath one of the grandstands and not on the pitch, but this is still a premier event that brings together managers, network engineers, and researchers from R&E networks in Europe and the rest of the world.

The Internet Society is not only one of the conference sponsors, but has a significant role in the programme as well. Our colleague Karen O’Donoghue on Monday spoke about NRENs and IoT Security in the ‘What’s Coming Next In Privacy Innovation‘ session, where she’s discussing the security and privacy challenges of burgeoning numbers of IoT devices and how these will impact R&E communities. ISOC is encouraging the development of best practices through the Online Trust Alliance’s IoT Security & Privacy Trust Framework, and this is a good opportunity to discuss how the NREN community can take the lead in adopting good operational practice.

Karen will also be talking about Time and Security during the ‘Security‘ session on Tuesday. Time synchronisation is critical for many Internet applications, and for many years NTP has worked fine without any real consideration for security. However, in recent years there have been an increasing number of attacks on the time synchronisation system in order to create disruption and cause damage, so there has been ongoing work in both the IETF and IEEE to secure the NTP and PTP protocols.

Our other colleague Steve Olshansky will be presenting on Blockchain and Digital Identity during the lightning talks session on Tuesday. He’ll be discussing whether Blockchain can be used for identity and access management, and what the implications are for user privacy and control over their identity.

I was organising the GLIF session on Monday too, which focused on recent developments in the global lightpath space that are used to support large-scale high-bandwidth research applications such as the Square Kilometre Array and Global Research Platform. In particular, networks are increasingly becoming software driven as more services move into the cloud, and whilst this hides the complexity from users, it makes managing networks more complex and requires more sophisticated measurement and monitoring. R&E networks cannot continue to justify higher bandwidth networks on a handful of big data research projects alone, and need to ensure good access to compute and storage clusters for the smaller research projects as well.

In addition, we’re raising awareness of routing security issues by providing some MANRS information in the conference poster session, as well as having some prominent ‘advertising’ around the venue. By offering four simple but concrete actions – namely filtering, anti-spoofing, improved coordination and global validation – network operators can collectively improve the security and reliability of the Internet.

If you’re unable to make it to TNC18 in person, the sessions are being both streamed and recorded.


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

Building Trust Improving Technical Security Time Security

Time Synchronization, Security, and Trust

Time is something that is often overlooked or taken for granted, but the accuracy and reliability of time is critical to our lives and must be protected. Time is a core concept underlying nearly all physical and virtual systems. Distributed computer systems, key to many functions inherent in our daily lives, rely on accurate and reliable time, yet we rarely stop and think about how that time is constructed and represented. Accurate and reliable time is needed to determine when an event occurs, in what order a particular sequence of events occurs, or when to schedule an event that is to occur at a particular time in the future. Finally, and of particular interest to our trust agenda here at the Internet Society, quality reliable time is required for many of the security technologies that help provide trust for the Internet. It is a vital and often overlooked part of the Internet infrastructure.

Some specific examples where accurate reliable secure time information is vital include:

  • The finance sector where there are high demands on the time synchronization of business clocks in trading systems. This is especially true in the high frequency trading where a new EU legislation called Markets in Financial Instruments Directive (MiFID II) requires a timestamping granularity of 1 microsecond and a maximal divergence from Coordinated Universal Time (UTC) of 100 microseconds. Similar requirements are formulated by the US Securities and Exchange Commission (SEC Rule 613).
  • The power industry for control of devices in the energy transmission and distribution network along with components in substation automation networks. These devices provide information about voltage, current, and phase angle used to derive the current state of the electrical infrastructure, a critical piece of national infrastructure.
  • Various manufacturing industries for the synchronization of machine parts in motion control type processes, for instance in a rolling mill or for printing presses.
  • Virtually all distributed systems where synchronization of logging information enables error tracking and thus contributes to system stability and system integrity.
  • Internet security technologies rely on a crucial interdependent relationship between security mechanisms and time synchronization. For example, certificates, a key component of security solutions, are used to determine that numerous types of resources are identified securely and correctly. These solutions rely on accurate time of day to establish the validity of certificates. There is a stereotypical “chicken and egg” problem where accurate time is needed to establish the security mechanism (the certificate). In turn, you need the security mechanism (the certificate) to be valid in order to establish that the information exchanged for time synchronization purposes has not been corrupted. As more security mechanisms are being deployed, we are increasingly relying on certificates and, in turn, secure time.

Despite the vital nature of time, the protocols that have historically provided the time infrastructure that we rely upon have not adopted adequate security mechanisms. There are two primary protocols for the synchronization of time over packet based (IP) networks. The Network Time Protocol (NTP), defined primarily by RFC 5905, and the IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems (IEEE 1588). Both of these standards lack mechanisms to secure these protocols.

However, as threats against Internet infrastructure have increased, both the IETF and IEEE technical communities have been working to provide new security mechanisms to address this deficiency. Later today, I will be presenting an analysis ( of the emerging security solutions for both NTP and IEEE 1588 at the IEEE International Symposium of Precision Clock Synchronization (ISPCS). Slides are also available online at

Both of the IETF NTP working group and IEEE 1588 working group standards efforts described in the paper are open standards ( processes. Participation is open and comments and contributions are welcome!