新しい暗号を組み込んだQUICを動かそう (その1) 〜低遅延性が必要なインターネットプロトコルを求めて - 探索編 -

更新日：2023.09.22

こんにちは、暗号のおねえさんことGMOインターネットグループデベロッパーエキスパートの酒見(@ysakemin)です。

みなさん、毎日暗号実装してますか？　暗号の高速実装ってワクワクしますよね！
今回の話題は高速実装ではないのですけども。

今回の記事は、私が主に活動を行っている低遅延暗号 Areion を実際のインターネットプロトコルに組み込んでみよう！という話題です。
みなさんはAreionって聞けば、Areion は「低遅延性と高い安全性」を有していることはご存知だと思うので、Areionに関する話は割愛しますね･:*+.(( °ω° ))/.:+

さて、低遅延性に注目してIETFのInternet-Draftを調査していくと、低遅延性を必要としている領域としてQUICが注目度大です！
そこで我々は・・・興味を持ってくれた方が気軽に試せるように、Areionが適用されたQUICの実装を用意することにしました。
AreionのQUIC実装を実現するまでの愛と感動の物語を、これから何回かの記事に分けて報告します。
いまのところ、次のような感じで3回くらいかな？の想定です。

その1: 低遅延性が必要なインターネットプロトコルを求めて - 探索編 -

その2: Areion meets QUIC - 実装編 -

その3: 世界が前進した日 - そして伝説へ -

今回の記事では、その第一弾として、QUICの既存実装の選び方や選定した既存実装の紹介を行います。

Areion対応のQUICの実現の流れ

今回の試作では、既存のQUIC実装を活用して次のステップで行いました。
なお、今回の記事ではQUIC自体の仕様詳細や実装方法の説明はスコープ外としています。

ベースとなるQUIC実装を選ぶ
選んだQUIC実装の暗号化部分にAreionを組み込む
Areion対応のQUICが動作するかを確認する

QUICとは

QUICは、Googleが設計したトランスポート層の通信プロトコルであり、通信のパフォーマンスを向上させることを目的の一つとしています。2015年にGoogleからIETFに標準化提案があり、2020年にQUICの初版としてQUIC version 1がRFC9000として発行されました。

QUICの歴史や仕様の解説については、とてもたくさんの記事が出ているため、そちらをご参照いただければと思います。

QUICのOSS選定

まず、QUICの既存実装の中から今回利用する実装を選んでいきたいのですが・・・
QUICの既存実装は、多くのベンダーやコミュニティから公開されており、その数はナント20個以上あります！！

こんなにたくさんあると、どれを使ったらいいんだろう？と迷ってしまいますね・・・。
QUICの既存実装の情報はIETFでQUICの議論を行なっているQUIC WGでまとめられており、以下から参照可能です。
言語やQUICのどのversionまで対応しているかなど、各既存実装の特徴がまとめられています。

＜QUICの実装に関する情報一覧＞
https://github.com/quicwg/base-drafts/wiki/Implementations

今回は、以下のような観点で選んでいきました。

QUICプロトコルとしては、version 1以降に対応されているか？
QUICのハンドシェイク部分であるTLS1.3のレイヤはOpenSSLやOpenSSL folkがベースとなっているか？
- 当初のプロジェクト計画として、Areionを広く利用してもらうために、OpenSSLへの適用を見込んでいたため
クライアントとサーバの両方の機能を備えているか？
ライセンス
- 広く利用してもらうために、なるべく利用制限が少ないライセンスとする

上記の観点で絞り込んでいくと、msquicやngtcp2などいくつかの実装まで絞り込まれます。

これらの実装をさらに見ていったところ、いくつかの既存実装でquictlsというOpenSSLのfolkが使われていることを発見しました。

quictlsを調べていくと、msquicやChronium、Nodejsなど、よく使われているソフトウェアで採用されていることがわかったため、今回はquictlsを採用することにしました！

msquicやChroniumについてはquictlsのREADMEに、NodejsについてはGitHubのpull requestsの方で採用されていることをご確認いただけます。

また、補足となりますが、quictlsのREADMEでは、OpenSSLでQUIC対応がされていない状況であるが、quictlsではOpenSSLが正式にQUIC実装を出すまで適切なサポートが提供されることが明記されております。

This fork is intended as stopgap solution to enable higher level frameworks 
and runtimes to use QUIC with the proven and reliable TLS functionality from OpenSSL. 
This fork will be maintained until OpenSSL officially provides reasonable support for 
QUIC implementations.

(引用元：https://github.com/quictls/openssl)

この記述から、quictlsでは安定的なメンテナンスも期待できそうです。

なお、quictlsを用いたQUIC実装はいくつかあるのですが、今回はquictlsの実装メンバーが実装しているmsquicを採用しました。

修正対象のOSSについて

Areionの適用先となる既存のQUIC実装が選べたので、最後にこれらの実装の概要についてまとめます。
今回はmsquicとquictlsにAreion対応をしていきますが、このQUIC実装にいれてくれたらいいのに・・・というリクエストありましたら、ぜひご意見いただけるとうれしいです・・・！

msquic
- 概要
  - QUICの全体のプロトコルを実装したもの
    - セキュリティ部分は後述のquictlsを採用
- 実装者
  - Microsoft
- 公開URL
  - https://github.com/microsoft/msquic
quictls
- 概要
  - QUICプロトコルで使用されるTLS1.3プロトコルなどのセキュリティ部分を担当
- 実装者
  - AkamaiとMicrosoft
- 公開URL
  - https://github.com/quictls/openssl

(余談)OpenSSL本家のQUIC対応について

今回選定したのはquictlsだったのですが、OpenSSL本家でのQUIC対応ってどうなっているの？というのも気になるところかと思います。

2020年ごろは、OpenSSLコミュニティから発信されているブログの中でQUIC対応の重要性について言及しているものの、OpenSSL 3.0のリリースに集中するため、QUICの対応についてのリリーススケジュールなどは明らかになっていませんでした。
当時、QUIC対応の要望が高まっている中で、OpenSSLでは直近対応されないというお知らせをみて驚いたのを覚えております。。。

しかし、その後、現在では、先日(2023年9月7日）OpenSSL 3.2 Alpha1がリリースされ、クライアント側のQUIC機能が組み込まれたことが発表されました。

今後のOpenSSL projectのロードマップでは、OpenSSL 3.4で完全にQUICプロトコルに対応を計画しているようなので、OpenSSL本家のQUIC対応にも目が離せませんね！