Categories
Deploy360 Domain Name System (DNS) Transport Layer Security (TLS)

DPRIVE experimental service debuts @ IETF 99

TLS badgeThe IETF is not only a place to discuss the development of Internet protocols, but also offers a place for developers and operators to ‘eat their own dog food’ on the meeting network. And given that the IETF DPRIVE Working Group has published some RFC specifications over the past year, the most recent IETF 99 in Prague provided a timely opportunity to run an experimental DNS-over-TLS service.

DNS queries and responses are currently transmitted over the Internet entirely in the clear, and whilst DNSSEC is able to authenticate a response from a DNS server, it does not actually encrypt the transmitted information. The aim of DPRIVE is therefore to add mechanisms to provide confidentiality to DNS transactions and address concerns about pervasive monitoring using TLS or DTLS to encrypt queries and responses between DNS clients and servers.

Some information about how the experimental DNS-over-TLS service was set-up on the IETF network can be found on the IETF99 Experiments page, but the DNS Privacy Project offers a list of experimental servers supporting both IPv4 and IPv6 if you want to try this out yourself. You also can check out their up status.

Categories
Deploy360 IETF IPv6

Deploy360@IETF99, Day 5: Kdo se moc ptá, moc se dozví

There’s a couple of sessions of interest on the last day of IETF 99 before we say na shledanou to the City of a Hundred Spires.

Both sessions are running in parallel on the Friday morning starting at 09.30 CEST/UTC+2. ACME will continue to discuss the ACME specification, as well as the addition of CAA checking for compliance with CA/B Forum guidelines. There’s also new drafts specifying how to issue certificates for telephone numbers, how to issue certificates for VoIP service providers to Secure Telephony Identity, and ACME extensions to enable the issuance of short-term and automatically renewed certificates, certificates for e-mail recipients that want to use S/MIME, and certificates for use by TLS e-mail services.


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


Alternatively you can check out LPWAN that’s working on enabling IPv6 connectivity with very low wireless transmission rates between battery-powered devices spread across multiple kilometres. This will be discussing five drafts related to IPv6 header fragmentation and compression, as well as ICMPv6 usage over LPWANs.

That brings this IETF to an end, so it’s goodbye from us in Prague. Many thanks for reading along this week… please do read our other IETF 99-related posts … and we’ll see you at IETF 100 on 12-17 November 2017 in Singapore!

Relevant Working Groups

Categories
Deploy360 Domain Name System Security Extensions (DNSSEC) Internet of Things (IoT)

Deploy360@IETF99, Day 4: IoT, IPv6, DNSSEC & TLS

Thursday at IETF 99 in Prague is a mixture of overflow sessions, the Internet-of-Things, and encryption. Each day we’re bringing you blog posts pointing out what Deploy360 will be focusing on.

Our day doesn’t actually start until 13.30 CEST/UTC+2, with the second part of V6OPS. This will continue discussing the ten drafts from whichever point it left them on Tuesday morning (see our Day 2 post for more information).

If you have V6OPS fatigue, then alternatively check out ROLL. This focuses on routing for the Internet-of-Things and has six drafts up for discussion.


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


The second afternoon session at 15.50 CEST/UTC+2 features IPWAVE. This will be discussing two drafts on transmitting IPv6 over over IEEE 802.11-OCB in Vehicle-to-Internet and Vehicle-to-Infrastructure networks, and on a problem statement for IP Wireless Access in Vehicular Environments. A further draft summarises a survey on IP-based Vehicular Networking for Intelligent Transportation Systems.

There’s two working groups during the evening session starting at 18.10 CEST/UTC+2. UTA is discussing three drafts related to the compulsory use of TLS for SMTP, an interesting one proposing to obsolete clear text transfer for e-mail, and one proposing an SMTP service extension.

Finally, there’s the second part of DNSOP. There appears to be just the one DNSSEC-related draft in this session, on algorithm negotiation.

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

Relevant Working Groups

Categories
Deploy360 Events IETF IPv6

Deploy360@IETF99, Day 3: IPv6 & TLS

After a packed first couple of days, Wednesday at IETF 99 in Prague is a bit quieter for us. Each day we’re bringing you blog posts pointing out what Deploy360 will be focusing on.

There’s just the three working groups to follow today, starting at 09.30 CEST/UTC+2 with TLS. A couple of very important drafts up for discussion though, with both the TLS 1.3 and DTLS 1.3 specifications in last call. There’s also a couple of other interesting drafts relating to DANE record and DNSSEC authentication chain extension for TLS, and Data Center use of Static DH in TLS 1.3.


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


Alternatively, there’s DMM that will be discussing at least one IPv6-relevant draft on the Applicability of Segment Routing IPv6 to the user-plane of mobile networks.

During the first afternoon session at 13.30 CEST/UTC+2, there’s DHC. This will continue to discuss four DHCPv6 related drafts, as well as hear about the DHCPv6 deployment experiences at Comcast.

Don’t forget that from 17.10 CDT/UTC-6 onwards will be the IETF Plenary Session. This is being held in Congress Hall I/II.

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

Relevant Working Groups

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

Deploy360@IETF99, Day 2: IoT, IPv6, DNSSEC, DPRIV & TLS

Tuesday is another hectic day at IETF 99 in Prague with a lot of relevant sessions for us. Each day we’re bringing you blog posts pointing out what Deploy360 will be focusing on.

The morning starts at 09.30 CEST/UTC+2 with a very full V6OPS meeting (which continues on Thursday afternoon). There’s a couple of deployment case studies up first – on turning IPv4 off in the Microsoft enterprise network, followed by some experiences of using dual-stacked websites with Happy Eyeballs – before a presentation on the current status of IPv6 deployment.

There are ten drafts being discussed, including requirements for IPv6 routers that aims to document a set of IPv6 requirements for routers, switches and middle boxes based on design and architectural experiences; specifying requirements for zero-configuration IPv6 CPEs; and using conditional router advertisements for connecting an enterprise network to multiple ISPs using address space assigned by an ISP. Version 2 of Happy Eyeballs is also being proposed, tweaking the algorithm whereby a dual-stack host tries to establish connections with both IPv4 and IPv6; and there’s an interesting draft proposing deployment of IPv6-only Wi-Fi at IETF meetings.


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


Running in parallel is DPRIVE, which will be discussing the DNS over the QUIC protocol, measuring the usage of DNS-over-TLS, as well as next steps. At the same time, PERC will be discussing a draft related to DTLS tunnelling.

First up in the afternoon at 13.30 CEST/UTC+2 is T2TRG which is reviewing the outcome of the Workshop on IoT Semantic/Hypermedia Interoperability (WISHI), and will discuss what its future activities and deliverables should be.

In the late afternoon session starting at 15.50 CEST/UTC+2, there’s DNSOP (which continues on Thursday afternoon). There doesn’t look to be much DNSSEC-wise on the agenda today, although there is a draft to enhance the automatic updating of DNSSEC trust anchor process (as specified in RFC 5011).

Also running in parallel is CFRG, which discusses and reviews cryptographic mechanisms for network security. There are five drafts being discussed, including on the transition from classical to post-quantum cryptography. In addition, there are two proposals for new cryptographic techniques.

If you’re interested in the Internet-of-Things, then you can also check-out 6LO. This group focuses on facilitating IPv6 connectivity over node networks with limited power, memory and processing resources, and will be discussing drafts on Neighbour Discovery, IPv6 over low-power Bluetooth mesh networks, and transmission of IPv6 over electrical power lines.

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

Relevant Working Groups

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

Rough Guide to IETF 99: A Sampling of Encryption-Related Activities

Encryption is once again a hot topic, and there’s much to discuss at IETF 99 this week in Prague. This time the hottest action will definitely be in the Transport Layer Security (TLS) working group. TLS is considering everything from privacy implications for TLS1.3 to how to reduce handshake latency. As mentioned in previous Rough Guide blogs on the topic, the working group is busy on the completion of the TLS 1.3 specification. It has completed working group last call, and the working group is addressing the comments received during that process. Draft 21 was released on 3 July in anticipation of this week’s discussion. (https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/)

In addition to the TLS 1.3 effort, the TLS working group has kicked off on an update to the Datagram Layer Transport Security (DTLS) Protocol (DTLS 1.3) (https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/) and has a number of additional drafts on the agenda. In particular, based on the mailing list traffic, there will be an active discussion about a draft (https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/). This document proposes a mechanism to address the challenges associated with supporting enterprise requirements in the presence of TLS 1.3. It is a controversial draft and many have indicated that it should not be discussed in the IETF. In addition to the technical merits of the proposal, the implication of RFC 2804 (https://www.rfc-editor.org/info/rfc2804) on this draft will be discussed. A second session on Monday has been added specifically to provide enough time for all the TLS topics.

The next topic of interest for encryption is the Crypto Forum Research Group (cfrg). Always a popular session at IETF, this week the CFRG will discuss six different drafts, including Re-keying Mechanisms for Symmetric Keys (https://datatracker.ietf.org/doc/draft-irtf-cfrg-re-keying), Verifiable Random Functions (https://tools.ietf.org/html/draft-goldbe-vrf-01), Collective Edwards-Curve Digital Signature Algorithm (https://datatracker.ietf.org/doc/draft-ford-cfrg-cosi), The Transition from Classical to Post-Quantum Cryptography (https://tools.ietf.org/html/draft-hoffman-c2pq-01), Hash-Based Signatures ( https://datatracker.ietf.org/doc/draft-mcgrew-hash-sigs), and Kangaroo Twelve (https://tools.ietf.org/html/draft-viguier-kangarootwelve-00).

Three of the working groups focused on updating crypto algorithms and using TLS in IETF protocols are meeting at IETF 99. The CURves, Deprecating and a Little more Encryption (curdle) working group was chartered to add and update the cryptographic mechanisms to some IETF protocols. It will have a very short meeting to discuss key exchange method updates and recommendations for Secure Shell (SSH). There will also be some discussion about potential future work for the curdle working group.

The DKIM Crypto Update (dcrup) working group is just getting started. It will be focused on updating the cryptographic aspecs of RFC 6376 (https://www.rfc-editor.org/info/rfc6376). The new working group has a short agenda this meeting, but given the recent popularity of conversations around cryptography, this may well expand to fill available time. Drafts under discussion include Cryptographic Update to DKIM (draft-ietf-dcrup-dkim-crypto), Cryptographic Algorithm and Key Usage Update to DKIM (draft-ietf-dcrup-dkim-usage), and Defining Elliptic Curve Cryptography Algorithms for use with DKIM (draft-ietf-dcrup-dkim-ecc). Hot topics include key hashes and key sizes.

The final working group discussed in this blog is the Using TLS in Applications (UTA) working group. The uta working group has finished a number of pieces of work, and this week will be focused on a draft related to Strict Transport Security (STS) for mail (SMTP) transfer agents and mail user agents. It will also discuss a draft on the use of TLS to provide confidentiality of email.

All in all, there is plenty to keep the encryption enthusiasts engaged here at IETF 99.

Relevant Working Groups at IETF 99

tls – Transport Layer Security
Monday, 17 July 2017, 1330-1530, Congress Hall I
Wednesday, 19 July 2017, 930-1200, Grand Hilton Ballroom
Agenda: https://www.ietf.org/proceedings/99/agenda/agenda-99-tls-01.txt
Charter: https://datatracker.ietf.org/wg/tls/about/

cfrg – Crypto Forum Research Group
Tuesday, 18 July 2017, 15:50-1750, Congress Hall I
Agenda: https://datatracker.ietf.org/meeting/99/agenda/cfrg/
Charter: https://irtf.org/cfrg

curdle – CURves, Deprecating and a Little more Encryption
Monday, 17 July 2017, 1130-1200, Congress Hall III
Agenda: https://datatracker.ietf.org/meeting/99/agenda/curdle/
Draft: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/

dcrup – DKIM Crypto Update
Thursday, 20 July 2017, 1100-1130, Berlin/Brussels
Agenda: https://datatracker.ietf.org/meeting/99/agenda/dcrup/
Charter: https://datatracker.ietf.org/wg/dcrup/about/

uta – Using TLS in Applications
Thursday, 20 July 2017, 1810-1910, Berlin/Brussels
Agenda: https://datatracker.ietf.org/meeting/99/agenda/uta/
Charter: https://datatracker.ietf.org/wg/uta/about/

Follow Us

There’s a lot going on in Prague, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see http://dev.internetsociety.org/rough-guide-ietf99.

Categories
Building Trust Identity IETF Privacy

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

Trust, Identity, and Privacy continue to be topics of interest for the IETF community. Below I will highlight a few of the many activities. There is something for everyone interested in these areas here at IETF 99 in Prague this week!

The work privacy started before the IETF meeting itself actually began with the IETF 99 Hackathon. As you are reading this, the Hackathon will have already been completed. This Hackathon had the largest attendance ever and reached full capacity. It was an energetic event highlighting a number of emerging technologies. An overview of all the Hackaton projects is available on the Hackathon wiki (https://www.ietf.org/registration/MeetingWiki/wiki/99hackathon).

There are two especially relevant efforts in the Hackathon that I’d like to bring to your attention. The first one is a large collaboration of people working on DNS, DNSSEC, and DNS privacy. This is a well-established project that has been active in several recent IETF Hackathon events. The second was a team of people working on HTTP error code 451 (RFC7725). This is an error code to report legal obstacles for serving a webpage. During the hackathon they focused on implementing and measuring this status code to make censorship more transparent.

Moving onto the extensive work on trust, and identity, and privacy in the IETF, I will remind folks that the excellent work of the DNS Privacy working group (dprive) was covered in an earlier rough guide post (https://dev.internetsociety.org/blog/tech-matters/2017/07/rough-guide-ietf-99-dns-privacy-and-security-including-dnssec).

The first two working groups I’m going to highlight in this post are working on topics related to the certificate infrastructure for the Internet. The Automated Certificate Management Environment (acme) working group is specifying ways to automate certificate issuance, validation, revocation and renewal. The main order of business is to discuss the working group last call comments on the core specification Automatic Certificate Management Environment (https://datatracker.ietf.org/doc/draft-ietf-acme-acme). The working group will also be discussing working group last call comments on the CAA Record Extensions for Account URI and ACME Method Binding (https://datatracker.ietf.org/doc/draft-ietf-acme-caa) document. New drafts to be discussed include ACME Identifiers and Challenges for Telephone Numbers (https://datatracker.ietf.org/doc/draft-ietf-acme-telephone) and ACME Identifiers and Challenges for VoIP Service Providers (https://datatracker.ietf.org/doc/draft-ietf-acme-service-provider).

The second certificate related working group is the Public Notary Transparency (trans) working group. It has been working since 2014 to improve the confidence of users in the Web PKI. The underlying premise of this work is to create transparent logs of certificates so that mis-issuance can be detected. That which is transparent can be observed and monitored for unexpected behavior. The core document (https://datatracker.ietf.org/doc/html/draft-ietf-trans-rfc6962-bis) is in working group last call.

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 working 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, a DTLS profile for ACE, a CBOR Web Token (CWT), and an architecture for authorization in constrained environments. In addition, there will be discussion of a number of new drafts for working group consideration.

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 99 will be another busy week for those interested in this area including sessions on both Tuesday and Friday. Agenda items for these two sessions include a mutual TLS profile, security, incremental authorization, JWT best practices, device flow, token exchange, and token binding.

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. This working group will be discussing two key drafts: Token Binding for 0-RTT TLS 1.3 Connections (draft-ietf-tokbind-tls13-0rtt), and HTTPS Token Binding with TLS Terminating Reverse Proxies (draft-campbell-tokbind-ttrp-00). This working group works in collaboration with the TLS, HTTPbis and Oauth WGs and with the W3C webappsec WG.

Also related to oauth, the Security Events (SECEVENT) working group is working on an Event Token specification that includes a JWT extension for expressing security events and a syntax for communicating the event-specific data. This is a fairly new WG, formally chartered in January 2017. The meeting this week will discuss several topics including the token specification, token delivery, a management API, and use cases for RISC and SCIM.

More related to the identity of devices than the identity of individuals but included here for completeness, the Identity Enable Networks (ideas) BoF proposes to examine how existing protocols that separate identifiers from their location may benefit from the concept of identity. The two drafts that form the structure of the meeting are Problem Statement for Identity Enabled Networks (draft-padma-ideas-problem-statement) and Gap Analysis for Identity Enabled Networks (draft-xyz-ideas-gap-analysis). Also under discussion is Identities and Identifiers for ION and the IETF. Come along to this session if you are interested in seeing whether or not the IETF might charter work in this space.

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. This week the talks include Post-quantum Crypto, Pretty Easy Privacy (pEp), and a Certificate Limitation Profile.

Finally, for those with a keen interest in privacy, the W3C Privacy Interest Group (PING) will again be meeting for their regular PING and friends get-together during the lunch break on Thursday, 20 July 2017 in Rokoska. Anyone with an interest in privacy is invited to join the meeting (but it is bring your own lunch).

All in all, an action packed week for trust, identity, and privacy related topics here at IETF 99!

Relevant Working Groups at IETF 99

acme (Automated Certificate Management Environment) WG
Friday, 21 July 2017, 0930-1130, Athens/Barcelona
Agenda: https://datatracker.ietf.org/meeting/99/agenda/acme/
Charter: https://datatracker.ietf.org/wg/acme/about/

trans (Public Notary Transparency) WG
Wednesday, 19 July 2017, 1520-1650, Berlin/Brussels
Charter: https://datatracker.ietf.org/wg/trans/about/

ace (Authentication and Authorization for Constrained Environments) WG
Monday, 17 July 2017, 09:30-1200, Congress Hall I
Agenda: https://datatracker.ietf.org/meeting/99/agenda/ace/
Charter: https://datatracker.ietf.org/wg/ace/about/

oauth (Web Authorization Protocol) WG
Tuesday, 18 July 2017, 1330-1530, Berlin/Brussels
Friday, 21 July 2017, 0930-1130), Karlin III
Agenda: https://datatracker.ietf.org/meeting/99/agenda/oauth/
Charter: https://datatracker.ietf.org/wg/oauth/about/

tokbind (Token Binding) WG
Monday, 17 July 2017, 1550-1720, Berlin/Brussels
Agenda: https://datatracker.ietf.org/meeting/99/agenda/tokbind/
Charter: https://datatracker.ietf.org/wg/tokbind/about/

secevent (Security Events) WG
Tuesday, 18 July 2017, 0930-1200, Karlin I/II
Agenda: https://datatracker.ietf.org/meeting/99/agenda/secevent/
Charter: https://datatracker.ietf.org/wg/secevent/about/

ideas (Identity Enable Networks) BOF
Wednesday, 19 July 2017, 1330-1500, Congress Hall II
Agenda: https://datatracker.ietf.org/meeting/99/agenda/ideas/
Documents: https://datatracker.ietf.org/wg/ideas/documents/

saag (Security Area open meeting)
Thursday, 20 July 2017, 1330-1530, Congress Hall III
Agenda: https://datatracker.ietf.org/meeting/99/agenda/saag/

Follow Us

There’s a lot going on in Prague, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see http://dev.internetsociety.org/rough-guide-ietf99.

Categories
Deploy360 IETF IPv6

Deploy360@IETF99, Day 1: IoT, IPv6 & SIDR

It’s another busy week at IETF 99 in Prague, and we’ll be bringing you daily blog posts that highlight what Deploy360 will be focused on during that day. And Monday sees a packed agenda with three working groups on the Internet-of-Things, a couple on routing, one on encryption, and an important IPv6 Maintenance WG session.

The day kicks off at 09.30 CEST/UTC+2 with 6MAN, and the big development is the move of the IPv6 specification to Internet Standard Status, as despite being widely deployed, IPv6 has remained a ‘Draft Standard’ since its original publication in 1998. There are also two working group drafts on updating the IPv6 Addressing Architecture as currently defined in RFC 4291, and on IPv6 Node Requirements as currently defined in RFC 6434. Other existing drafts up for discussion include recommendations on IPv6 address usage and on Route Information Options in Redirect Messages.

There are three new drafts being proposed, including one that covers scenarios when IPv6 hosts might not be able to properly detect that a network has changed IPv6 addressing and proposes changes to the Default Address Selection algorithm defined in RFC6724; another that proposes a mechanism for IPv6 hosts to retrieve additional information about network access through multiple interfaces; whilst the remaining draft defines the AERO address for use by mobile networks with a tethered network of IoT devices requiring a unique link-local address after receiving a delegated prefix.


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


Running in parallel is ACE which is developing authentication and authorization mechanisms for accessing resources on network nodes with limited CPU, memory and power. Amongst the ten drafts on the agenda, there’s one proposing a DTLS profile for ACE.

Also at the same time is CURDLE which is chartered to add cryptographic mechanisms to some IETF protocols, and to make implementation requirements including deprecation of old algorithms. The agenda isn’t very comprehensive at the moment, but nine drafts were recently submitted to the IESG for publication, and what will certainly be discussed today is a draft on key change methods for SSH.

In the afternoon, Homenet is meeting from 13.30 CEST/UTC+2. This is developing protocols for residential networks based on IPv6, and will continue to discuss updated drafts relating to a name resolution and service discovery architecture for homenetshow the Babel routing protocol can be used in conjunction with the HNCP protocol in a Homenet scenario, and the use of .homenet as a special use top-level domain to replace .home. There are also three new drafts relating to the service discovery and registration aspects of Homenet.

Running in parallel is 6TiSCH. There will be summaries of the 1st F-Interop 6TiSCH Interoperability Event and OpenWSN Hackathon, followed by discussions on the updated drafts related to the 6top protocol that enables distributed scheduling, as well as a draft related to security functionality.

The later afternoon session sees SIDROPS meeting from 15.50 CEST/UTC+2. This is taking the technology developed by SIDR and is developing guidelines for the operation of SIDR-aware networks, as well as providing operational guidance on how to deploy and operate SIDR technologies in existing and new networks. One particularly interesting draft proposes to use blockchain technology to validate IP address delegation, whilst another describes an approach to validate the content of the RPKI certificate tree. A couple of other drafts aim to clarify existing approaches to RPKI validation.

Concluding the day is GROW during the evening session. This group looks at the operational problems associated with the IPv4 and IPv6 global routing systems, and whilst theres’s no agenda for this meeting yet, four new and updated drafts were recently published on more graceful shutting down of BGP sessions, how to minimise the impact of maintenance on BGP sessions, and extensions to the BGP monitoring protocol.

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

Relevant Working Groups

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

Our Hot Topics @ IETF 99

Next week is IETF 99 in Prague which will be the fourth time the IETF has been held in the city. The Deploy360 team will be represented by Megan Kruse and Dan York, along with ISOC’s Chief Internet Technology Officer Olaf Kolkman. We’ll once again be highlighting the latest IPv6, DNSSEC, Securing BGP and TLS related developments.

Our colleagues are planning to cover the following sessions, so please come and say hello!

Monday, 17 July 2017

Tuesday, 18 July 2017

Wednesday, 19 July 2017

Thursday, 20 July 2017

Friday, 21 July 2017

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

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

Categories
IETF Improving Technical Security IPv6 Open Internet Standards

Rough Guide to IETF 99: IPv6

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

IPv6 global adoption rates have seen another 25% increase since the start of 2017, taking them to close to 20% overall with Belgium leading the way at close to 50%. This is attributable to more ISPs and mobile operators rolling out IPv6 as pools of IPv4 addresses approach depletion, that has kept the cost of IPv4 addresses on the brokerage market fairly static, although these costs are still expected to rise over the next couple of years. With many of the major content and cloud providers now supporting IPv6, and substantial interest in home networking, remote sensing/controllers, and vehicular networks, IPv6 looms large in the standardisation work at the IETF, which is also encouraging the use of IPv6 examples in all of its documentation.

The IPv6 Maintenance (6man) Working Group meets first thing on Monday and the big development is the move of the IPv6 specification to Internet Standard Status. It may come as a surprise to many that despite being widely deployed, IPv6 as defined in RFC 2460 has remained a ‘Draft Standard’ since its original publication in 1998.

There are also two working group drafts on updating the IPv6 Addressing Architecture as currently defined in RFC 4291 (https://tools.ietf.org/html/draft-ietf-6man-rfc4291bis), and on IPv6 Node Requirements as currently defined in RFC 6434 (https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis). Other existing drafts up for discussion include recommendations on IPv6 address usage (https://tools.ietf.org/html/draft-gont-6man-address-usage-recommendations) and on Route Information Options in Redirect Messages (https://tools.ietf.org/html/draft-templin-6man-rio-redirect).

There are also three new drafts being proposed, including one that covers scenarios when IPv6 hosts might not be able to properly detect that a network has changed IPv6 addressing and proposes changes to the Default Address Selection algorithm defined in RFC6724 (https://tools.ietf.org/html/draft-linkova-6man-default-addr-selection-update-00); another that proposes a mechanism for IPv6 hosts to retrieve additional information about network access through multiple interfaces (https://tools.ietf.org/html/draft-bruneau-intarea-provisioning-domains-01); whilst the remaining draft defines something called an AERO address for use by mobile networks with a tethered network of IoT devices requiring a unique link-local address after receiving a delegated prefix (https://tools.ietf.org/html/draft-templin-6man-aeroaddr-00).

The Homenet (homenet) Working Group develops protocols for residential networks based on IPv6 and is therefore one of the most active groups at the moment. This will meet on Monday afternoon, and will continue to discuss updated drafts related to a name resolution and service discovery architecture for homenets (https://tools.ietf.org/html/draft-tldm-simple-homenet-naming-02); how the Babel routing protocol can be used in conjunction with the HNCP protocol in a Homenet scenario (https://tools.ietf.org/html/draft-ietf-homenet-babel-profile-02), and the use of .homenet as a special use top-level domain to replace .home (https://tools.ietf.org/html/draft-ietf-homenet-dot-09). Three new drafts relate to the service discovery and registration aspects of Homenet (https://tools.ietf.org/html/draft-sctl-service-registration-00, https://tools.ietf.org/html/draft-sctl-discovery-broker-00, https://tools.ietf.org/html/draft-sctl-dnssd-mdns-relay-00).

Running in parallel is the IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) Working Group. 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. At this meeting there will be summaries of the 1st F-Interop 6TiSCH Interoperability Event and OpenWSN Hackathon, followed by discussions on the updated drafts related to the 6top protocol that enables distributed scheduling (https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-09 and https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-05), as well as a draft related to security functionality (https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-03).

Tuesday kicks off with a very busy IPv6 Operations (v6ops) Working Group, which continues on Thursday afternoon. There’s a couple of deployment case studies up first – on turning IPv4 off in the Microsoft enterprise network, followed by some experiences of using dual-stacked websites with Happy Eyeballs. Co-Chair Lee Howard will then discuss the current status of IPv6 deployment.

There are ten drafts being discussed, including requirements for IPv6 routers that aims to document a set of IPv6 requirements for routers, switches and middle boxes based on design and architectural experiences (https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs-00); specifying requirements for zero-configuration IPv6 CPEs (https://tools.ietf.org/html/draft-baker-v6ops-cpe-autoconfigure-00); and using conditional router advertisements for connecting an enterprise network to multiple ISPs using address space assigned by an ISP (https://tools.ietf.org/html/draft-linkova-v6ops-conditional-ras-01). Version 2 of Happy Eyeballs is also being proposed, tweaking the algorithm whereby a dual-stack host tries to establish connections with both IPv4 and IPv6 (https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-02); and there’s an interesting draft proposing deployment of IPv6-only Wi-Fi at IETF meetings.

The remaining four drafts are proposed updates to RFC 7084 that outlines basic requirements for IPv6 Customer Edge Routers (https://tools.ietf.org/html/draft-ietf-v6ops-rfc7084-bis). As well as updating the basic requirements for routers with HNCP (https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis4-hncp), the other drafts specify both minimum (https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis2) and transitional requirements (https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis2).

The Thing-to-Thing (T2TRG) Working Group on Tuesday afternoon is taking the opportunity to review the outcome of the Workshop on IoT Semantic/Hypermedia Interoperability (WISHI), and discuss what its future activities and deliverables should be.

Then there’s the IPv6 over Networks of Resource Constrained Nodes (6lo) Working Group on Tuesday evening. 6lo focuses on facilitating IPv6 connectivity over node networks with limited power, memory and processing resources. The agenda has yet to be published, but the group has recently been working on Neighbour Discovery, IPv6 over low-power Bluetooth mesh networks, and transmission of IPv6 over electrical power lines, amongst other issues.

The remainder of the week is a bit quieter, although the Distributed Mobility Management (dmm) Working Group on Wednesday morning will be discussing at least one IPv6-relevant draft on the Applicability of the Segment Routing IPv6 to the user-plane of mobile networks (https://datatracker.ietf.org/meeting/99/agenda/dmm/). The Dynamic Host Configuration (dhc) Working Group in the afternoon will continue to discuss four DHCPv6 related drafts, as well as hear about the DHCPv6 deployment experiences at Comcast.

The new IP Wireless Access in Vehicular Environments (ipwave) Working Group will also be meeting on Thursday afternoon, and whilst has yet to publish its agenda, is working on a specification for transmitting IPv6 datagrams over IEEE 802.11-OCB in Vehicle-to-Internet and Vehicle-to-Infrastructure communications.

Rounding off the week is the IPv6 over Low Power Wide-Area Networks (lpwan) Working Group on Friday morning that’s working on enabling IPv6 connectivity with very low wireless transmission rates between battery-powered devices spread across multiple kilometres. This will be discussing five drafts related to IPv6 header fragmentation and compression, as well as ICMPv6 usage over LPWANs.

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

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

http://dev.internetsociety.org/deploy360/start/
http://dev.internetsociety.org/deploy360/ipv6/

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 99 posts.

IPv6-related Working Groups at IETF 99:

6MAN (IPv6 Maintenance ) WG
Monday, 17 July 2017 0930-1200 UTC+2, Grand Hilton Ballroom
Agenda: https://datatracker.ietf.org/meeting/99/agenda/6man/
Documents: https://datatracker.ietf.org/wg/6man/documents/
Charter: https://datatracker.ietf.org/wg/6man/charter/

Homenet (Home Networking) WG
Monday, 17 July 2017 1330-1530 UTC+2, Grand Hilton Ballroom
Agenda: https://datatracker.ietf.org/meeting/99/agenda/homenet/
Documents: https://datatracker.ietf.org/wg/homenet/documents/
Charter: https://datatracker.ietf.org/wg/homenet/charter/

6TISCH (IPv6 over the TSCH mode of IEEE 802.15.4e)
Monday, 17 July 2017 1330-1530 UTC+2, Karlin I/II
Agenda: https://datatracker.ietf.org/meeting/99/agenda/6tisch/
Documents: https://datatracker.ietf.org/wg/6tisch/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-6tisch/

V6OPS (IPv6 Operations) Working Group
Tuesday, 18 July 2017 0930-1200 UTC+2, Congress Hall II &
Thursday, 20 July 2017 1330-1530 UTC+2, Grand Hilton Ballroom
Agenda: https://datatracker.ietf.org/meeting/99/agenda/v6ops/
Documents: https://datatracker.ietf.org/wg/v6ops/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-v6ops/

T2TRG (Thing-to-Thing) WG
Tuesday, 18 July 2017 1330-1530 UTC+2, Grand Hilton Ballroom
Agenda: https://datatracker.ietf.org/meeting/99/agenda/t2trg/
Documents: https://datatracker.ietf.org/group/t2trg/documents/
Charter: https://datatracker.ietf.org/group/t2trg/charter/

6LO (IPv6 over Networks of Resource Constrained Nodes) WG
Tuesday, 18 July 2017 1550-1750 UTC+2, Karlin I/II
Agenda: https://datatracker.ietf.org/meeting/99/agenda/6lo/
Documents: https://datatracker.ietf.org/wg/6lo/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-6lo/

DMM (Distributed Mobility Manager) WG
Wednesday, 19 July 2017 0930-1200 UTC+2, Berlin/Brussels
Agenda: https://datatracker.ietf.org/meeting/99/agenda/dmm/
Documents: https://datatracker.ietf.org/wg/dmm/documents/
Charter: https://datatracker.ietf.org/wg/dmm/charter/

IPWAVE (IP Wireless Access in Vehicular Environments)
Thursday, 20 July 2017 1550-1750 UTC+2, Athens/Barcelona
Agenda: https://datatracker.ietf.org/meeting/99/agenda/ipwave/
Documents: https://datatracker.ietf.org/wg/ipwave/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-ipwave/

LPWAN (IPv6 over Low Power Wide-Area Networks)
Friday, 21 July 2017 0930-1130 UTC+2, Karlin I/II
Agenda: https://datatracker.ietf.org/meeting/99/agenda/lpwan/
Documents: https://datatracker.ietf.org/wg/lpwan/documents/
Charter: https://datatracker.ietf.org/doc/charter-ietf-lpwan/

Follow Us

There’s a lot going on in Prague, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see https://dev.internetsociety.org/tag/ietf99/.

Categories
IETF Improving Technical Security Open Internet Standards Technology

ISOC Rough Guide to IETF 99: Internet Infrastructure Resilience

IETF 99 is next week in Prague, and I’d like to take a moment to discuss some of the interesting things happening there related to Internet infrastructure resilience in this installment of the Rough Guide to IETF 99.

Simple solutions sometimes have a huge impact. Like a simple requirement that “routes are neither imported nor exported unless specifically enabled by configuration”, as specified in an Internet draft “Default EBGP Route Propagation Behavior Without Policies”. The draft is submitted to IESG and expected to be published as a Standards Track RFC soon.

This specification intends to limit the impact of misbehaving networks by requiring the explicit configuration of both BGP Import and Export Policies for an External BGP (EBGP) session such as customers, peers, or confederation boundaries for all enabled address families. When widely deployed, this measure should reduce the occurrence of route leaks and some other routing misconfigurations.

Speaking of route leaks, there are still two proposals addressing the route leak problem. Now both are IDR WG documents: “Methods for Detection and Mitigation of BGP Route Leaks” (http://datatracker.ietf.org/doc/draft-ietf-idr-route-leak-detection-mitigation), and “Route Leak Prevention using Roles in Update and Open messages” (https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/). The first approach uses a so-called RLP Route Leak Prevention field to inform upstream networks and lateral peers of a “leaked” route. Another one leverages the BGP Open message to establish an agreement of the (customer, provider, complex) relationship of two BGP neighboring speakers in order to enforce appropriate configuration on both sides. Propagated routes are then marked with a flag according to agreed relationship allowing detection and mitigation of route leaks.

In the area of RPKI and BGPSEC a recently chartered 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. The first of such guidelines was just published and will probably be discussed during the WG meeting: “Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties” (https://datatracker.ietf.org/doc/draft-madi-sidrops-rp). Being a relying party is not an easy job – one has to comply to dozen of RFCs, from protocol specifications to best practices – and this document attempts to outline a set of baseline requirements imposed on RPs and provides a single reference point for requirements for RP software for use in the RPKI, as segmented with orthogonal functionalities:

  • Fetching and Caching RPKI Repository Objects
  • Processing Certificates and CRLs
  • Processing RPKI Repository Signed Objects
  • Delivering Validated Cache Data to BGP Speakers

The IDR WG continues working on the proposal “Making Route Servers Aware of Data Link Failures at IXPs” (https://datatracker.ietf.org/doc/draft-ietf-idr-rs-bfd/). When route servers are used, the data plane is not congruent with the control plane. Therefore, the peers on the Internet exchange can lose data connectivity without the control plane being aware of it, and packets are dropped on the floor. This document proposes a means for the peers to verify connectivity amongst themselves, and a means of communicating the knowledge of the failure back to the route server. There was quite some discussion on the mailing list about whether communication of failures back to the RS is necessary. I imagine this discussion will continue during the WG session.

It seems the OPSEC WG will discuss another attempt at addressing the source IP spoofing problem. A draft “Enhanced Feasible-Path Unicast Reverse Path Filtering Anti-spoofing” (https://tools.ietf.org/html/draft-sriram-opsec-urpf-improvements) proposed a method that does not have the drawbacks of the existing modes of Unicast Reverse Path Filtering (uRPF) – strict, feasible and loose. Apart from implementation issues and a potential performance hit, uRPF presents risks of dropping traffic by an ISP implementing it. These were the major obstacles in the way of its deployment and protection against IP-spoofed traffic.

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. The goal of the group is to develop a communications protocol intended to facilitate the programmatic, coordinated mitigation of such attacks via a standards-based mechanism. This protocol should support requests for DDoS mitigation services and status updates across inter-organizational administrative boundaries. Specifications outlining the requirements, architecture and the use cases for DOTs are maturing and will be discussed at the meeting.

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 99

SIDROPS (SIDR Operations) WG
Monday, 17 July, 15:50-17:20, Congress Hall III
Agenda: https://datatracker.ietf.org/meeting/99/agenda/sidrops/
Charter: https://datatracker.ietf.org/wg/sidrops/charter/

GROW (Global Routing Operations) WG
Monday, 17 July, 17:40-18:40, Congress Hall III
Agenda: https://datatracker.ietf.org/meeting/99/agenda/grow/
Charter: https://datatracker.ietf.org/wg/grow/charter/

IDR (Inter-Domain Routing Working Group) WG
Thursday, 20 July, 09:30-12:00, Congress Hall III
Agenda: https://datatracker.ietf.org/meeting/99/agenda/idr/
Charter: https://datatracker.ietf.org/wg/idr/charter/

DOTS (DDoS Open Threat Signaling) WG
Thursday, 20 July, 15:50-17:50, Berlin/Brussels
Agenda: https://datatracker.ietf.org/meeting/99/agenda/dots/
Charter: https://datatracker.ietf.org/wg/dots/charter/

OPSEC (Operational Security) WG
Wednesday, 19 July, 13:30-15:00, Berlin/Brussels
Agenda: https://datatracker.ietf.org/meeting/99/agenda/opsec/
Charter: https://datatracker.ietf.org/wg/opsec/charter/

Follow Us

There’s a lot going on in Prague, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see http://dev.internetsociety.org/rough-guide-ietf99.

Categories
IETF Open Internet Standards

IETF Journal July 2017 Issue Available Online Now

The July 2017 issue of the IETF Journal is now online at http://www.ietfjournal.org/journal-issues/july-2017/. With IETF 99 in Prague just over one week away, this is the perfect time to get caught up on what’s been happening in the world of Internet standards lately.

Our cover article is a deep dive into Segment Routing, a new traffic-engineering technology being developed by the SPRING Working Group. Also in this issue, you’ll learn about the many activities of the new Education and Mentoring Directorate, which aims to enhance the productivity, diversity, and inclusiveness of the IETF.

We also present an update from the Security Automation and Continuous Monitoring WG, BoF updates, a readout from the pre-IETF Hackathon, and an article about the Internet Society Policy Guests to the IETF. Our regular columns from the IETF, IAB, and IRTF chairs and coverage of the IETF plenary wrap up the issue.

There will be print copies available at IETF in Prague, the email version will hit subscribers’ inboxes early next week, and hard copies will arrive to print subscribers shortly thereafter. You can subscribe at https://dev.internetsociety.org/form/ietfj, if you haven’t already.

We’ll also highlight specific articles via our social media channels – https://twitter.com/ietfjournal and https://www.facebook.com/ietfjournal/.

If you are interested in writing for the next issue, or know someone who may be, please let us know via email to ietfjournal@isoc.org.

Happy reading!