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.