QUICの概要
SMB over QUIC は 2021年11月4日に正式リリースされました。
この発表は、Microsoft のイベント Ignite カンファレンスの中で行われました。その際、Microsoft のプリンシパル プログラム マネージャーである Ned Pyle 氏が登壇し、SMB over QUIC の機能、利点、そして実用性についてデモを交えて紹介しました。SMBの技術に精通し、熱心に追い続けてきた人々にとっては、驚きではなかったことでしょう。
私たちは現在、SMB over QUIC に対応した Android クライアントのデモも用意しています。このデモは、SMBテクノロジースタックの進化を追っている業界関係者の注目を集めています。本記事では、SMB over QUIC の具体的なユースケースや実用性について、わかりやすく解説していきます。
QUICとは？
- QUICは、IETF（インターネット技術標準化委員会）によって標準化された新しい通信プロトコルで、従来のTCPの代替として設計されました。主にインターネット通信を前提に、UDPベースで動作し、パフォーマンスと輻輳制御の向上を実現します。
- QUICは、TCPと同等の信頼性と汎用性を維持することを目指しています。
- 通信は常に暗号化されており、TLS 1.3 と証明書ベースの認証が必須です。これにより、接続トンネルの安全性が保証されます。
- Microsoft は、このQUICプロトコルの IETF 標準仕様に基づいたオープンソース実装「MSQuic」を開発・公開しています。
QUICの主な利点とは？
QUICは、従来のTCPやHTTP/2の課題を解消することを目的とし、クラウドスケールのアプリケーションやサービス開発に最適なプロトコルとして設計されました。
- TLS 1.3内蔵なので、従来のTCPを用いたTLSハンドシェイクおよび暗号鍵交換の工程を、単一のハンドシェイクで簡略化し、TLS接続時間を短縮
- UDP上で動作するため、TCP特有のデータ転送時のオーバーヘッドを排除
- 信頼性のあるデータとないデータの両方を並列ストリームで送信可能
- パケットロス発生時における、高い接続パフォーマンスの維持
・HTTP/2 over TCP では、データパケットが1つでも失われると「ヘッド・オブ・ライン・ブロッキング（HOLブロッキング）」が発生します。つまり、1つのパケットが到着するまで、受信側は他のすべてのストリームも待たされてしまい、接続全体の性能が著しく低下します。
・QUICは各ストリームが独立してデータパケットを目的地に届けることができるため、パケットロスによる影響が大幅に軽減されます。
・さらに、信頼性のないデータグラムを扱うための拡張仕様も現在ドラフトとして策定中です。
- TLS 1.3による、セッションチケットを用いたサーバー toクライアントの接続再利用
- 接続の移行（ネットワークの変更）が容易なため、より安定した接続が実現
・ネットワークが変更される（IPアドレスやポートが変わる）と、TCPでは接続がタイムアウトし、再接続が必要になります。
・一方でQUICは、ユニークな識別子（unique identifiers）」を使用することで、接続の移行をスムーズに実現します。たとえIPアドレスが変わっても、新しい接続を確立するのではなく、パケットを1つ送るだけで再接続が完了します。 - 開発の容易さが、より迅速な導入を後押し
・QUICはアプリケーションレベルで実装できるため、より簡単かつ柔軟に扱うことができます。
・一方、TCPはOSのカーネルに組み込まれているため、その実装に依存することになります。
QUIC導入における課題
ここでは、QUICの導入にあたって指摘されている批判や課題について、簡単に見ていきます。まず第一に、多くの人々はQUICの利点を十分に認識していない、あるいは現在のTCPで特に困っていないため、そのままで満足しているという点が挙げられます。その結果、TCPの持つ欠点があまり意識されず、QUICへの関心が高まりにくいという現状があります。
パフォーマンスに関する懸念：
現在のところ、QUICは25Gbpsの通信速度には対応していません。しかし、現在のユースケースにおいて、それが本当に必要でしょうか？もちろん、現時点でできないことも、将来的には可能になるでしょう。Microsoft Tech Community に掲載されている「Making MsQuic Blazing Fast」の記事では、パフォーマンス向上とオフロード処理に関するさまざまな取り組みが紹介されています。たとえば、Windows Server 2022では以下のような機能が改善されています：
UDP セグメンテーション オフロード（USO）
UDP レシーブ サイド スケーリング（RSS）
UDP データパスの最適化 など
- 変化への抵抗と不確実性：多くの旧式のセキュリティアプライアンスは、依然としてQUICを正しく処理できません。そのため、業界全体で、NAT（ネットワークアドレス変換）やECMP（等コストマルチパス）環境における「4タプル（通信を識別するための「送信元IP・送信元ポート・宛先IP・宛先ポート」の4つの情報）」と「Connection ID」の扱いに関する課題に取り組む必要があります。
- TLSインスペクションの必要性やアプリケーションの可視性・制御に関するセキュリティ上の懸念があります。
- UDPを使用することによって、DDoS検出・防御の仕組みが機能しなくなるリスクがあるほか、検索語や閲覧履歴のログ取得・レポート作成にも課題があります。また、ファイアウォールにおけるポートの開放は、それ自体がリスクを伴います。
- QUICは、TLS 1.3 や HTTPS を基盤とすることによって独自の利点を持っていますが、こうした特性は、接続の再開（Connection Resumption）や0-RTT（ゼロラウンドトリップ接続）といった、特定のアーキテクチャ上の選択につながります。
- これらの懸念事項の大半は、TLS 1.3およびPerfect Forward Secrecy（完全前方秘匿性）の必須化に関連しています。
それでもなお、世界中でSMB over QUICの実証が行われています。
SMB over QUIC
SMB over QUICはUDPポート443 上で動作し、認証とデータ転送の両方が常にTLS 1.3で暗号化されます。これはQUICプロトコルの仕様によるものです。その結果、TCPポート445をファイアウォールで開放することなく、インターネット経由で安全にSMBを利用することが可能になります。これは非常に大きな利点です。というのも、多くの企業のセキュリティ部門やISPはTCP/445をファイアウォールでブロックしているためです。このことは、Azureファイル共有へアクセスしようとした多くのユーザーが直面した現実でもあります。
通常、インターネット経由でオンプレミスまたはAzure上のSMBファイル共有にアクセスするには、TCP/445がブロックされている環境ではVPN接続が唯一の選択肢でした。しかし、SMB over QUICはこのVPNの必要性を取り除くことで、利便性とセキュリティを両立させています。さらに、社内ネットワークでのアクセスも、社外からのアクセスも、まったく同じユーザー体験を提供することができます。このため、MicrosoftはSMB over QUICを「TLS 1.3が自動で組み込まれたVPN付きのSMB」と呼ぶことを好んでいます。
私たちは、Windows Server 2022 Datacenter: Azure Edition のプレビュー版で SMB over QUIC が利用可能になって以来、継続的にテストを行ってきました。
MicrosoftがSMBにおいてQUICを高く評価しているのは、このプロトコルがユーザー体験を重視した設計であり、セキュアでネットワーク変更にも強く、接続が安定しているためです。さらにSMB over QUICは、ユーザーがどこで働いていても透過的な体験を提供し、VPNを不要にするという点でも優れています。加えて、ここまでに述べた利点は、クラウド対応かつスケーラブルなサービスを設計するうえで、エンジニアリング的にも理にかなった選択肢であると言えるでしょう。
SMB over QUIC 導入における課題
QUICの導入に関する課題についてはすでに述べましたが、SMB over QUICの導入における大きな課題のひとつは、技術的な問題でも政治的な理由でもありません。それは、対応するクライアントOSの不足です。本稿執筆時点では、SMB over QUICをサポートしているのはWindows 11 と Windows Server 2022 Datacenter Azure Edition のみです。後者は、Azure または Azure Stack HCI 上でのみ動作します。今後、Azure Files も SMB over QUIC に対応予定ですが、対応可能なクライアントの少なさという根本的な課題の解決には至りません。
一部の組織ではWindows 11への移行が急速に進んでいるものの、世界の大多数は依然としてWindows 10を使用しており、しばらくはこの状況が続くと見られます。MicrosoftがSMB over QUICをWindows 10にバックポートする可能性はあるものの、現時点ではそのような計画は発表されていません。また忘れてはならないのは、サーバー自体もSMBクライアントとして動作することがあるという点です。しかし、Windows Server 2022でさえSMB over QUICには対応しておらず、ましてやWindows Server 2019は非対応です。一方、Sambaでは、将来的にSMB over QUICのクライアントおよびサーバー両方のサポートが確実に進むと見られており、これによりLinux環境の一部には有効なソリューションが提供されることになります。
それでもなお、モバイルクライアントや非Linux系オペレーティングシステムの領域には、依然として大きな空白が残されています。これらの多くのデバイスは、AppleのiOSまたはAndroidのいずれかで動作しています。モバイルデバイス向けにSMB over QUICクライアントを開発することで、どれだけ多くのユースケースや顧客を獲得できるかを想像してみてください。そのような背景から、Igniteで披露されたデモには非常に大きな意味があります。Androidは、スマートフォンやタブレットを活用する多くのビジネスユーザーや業務アプリケーションの基盤となっており、Visuality Systemsがまさにターゲットとしているのがこのユーザー層です。この用途に対しては、Visuality SystemsのJNQ™ライブラリを活用することができます。
安心してください。Visuality SystemsはiOSへの対応も見逃していません。そしてもちろん、Linuxベースのクライアントも忘れていません。そのために活用されるのが、YNQ™ライブラリです。このライブラリは、Windows以外の（組み込み系を含む）システムにおいて、Windowsベースのマシンとの相互運用が可能なSMBサーバー／クライアントソリューションを開発するための基盤を提供します。さらに、YNQ™はSMBシステムドライバーの実装にも使用されます。
QUICの利点のひとつとして、ユーザーモードでソリューションを開発できることを先に述べました。ただし、SMB over QUICでは話がやや複雑になります。なぜなら、SMBはカーネルレベルのスタックと密接に関係しているため、単純にWindows OS上のSMBサーバースタックを置き換えたり、横から割り込んだりすることはできないからです。とはいえ、QUICやTCPを介してSMBファイル共有にアクセスできるクライアントアプリや、完全なファイルマネージャーアプリを作成すること自体は可能です。
Microsoftは、Ignite 2021において、Visuality Systemsとの協力のもと、そのような実例を紹介しました。Visuality Systemsは、IT業界向けに長年にわたってSMBソリューションを開発してきた実績のある企業です。同社は、ストレージシステム、プリンター、組み込み機器、モバイル、デスクトップ、ノートPCなど、さまざまなOS環境に対応したソリューションを提供しています。Java環境向けには、Windows、Linux、Android向けに使用可能なJNQ™ライブラリを提供しています。さらに、モバイルおよび組み込みシステム向けのYNQ™ライブラリを用いることで、iOSを含む非Linux系OS向けのソリューション構築も可能となります。
ユースケース
REST APIやオブジェクトストレージが大きな可能性と普及を見せている一方で、ファイルシステムが終わったというわけでは決してありません。むしろその逆で、Azureが「Azure Files」というPaaS型ファイル共有サービスへの継続的な投資を行っていること自体が、その価値の継続を示しています。さらに、SMB3もリリースのたびに改良されており、進化を続けています。
QUICは将来性がある、着実に成長を遂げているプロトコルです。SMB over QUICは、まさにファイルシステムがクラウド時代において価値を提供し続けるために必要な仕組みです。
モバイルアプリケーションや組み込みシステムはあらゆる場所に存在し、IoTは世界中のあらゆる市場セグメントで爆発的な成長を見せています。5Gによるインターネット接続の高速化・安定化が進む中で、クラウドベースのサブスクリプション型ソリューションはさらに拡大していくことが予想されます。製造、監視、サプライチェーン、ロボティクス、物流、ゲーミング、e-ヘルス、自動運転、ドローンといった分野では、これらの成長に伴い、安全かつ簡単にファイル共有へアクセスできる手段（VPNなしで）が極めて重要になります。それこそが、SMB over QUICが提供する価値です。
Visuality Systemsは、あらゆるデバイスやOSからSMB over QUICを利用できる環境を開くことで、この可能性を現実のものにしています。
それではご紹介しましょう
それでは、Visuality Systemsの製品ラインナップをご紹介しましょう。あわせて、私たちのラボ環境で動作させた、CLIベースのファイルマネージャーデモ（Javaアプリ）のスクリーンショットもご覧いただきます！
YNQ™
YNQ™は、Visuality Systemsが提供する組み込み向けSMBライブラリのブランド名です。このライブラリは、Windows以外の組み込みシステム向けに開発されたSMBサーバーおよびSMBクライアントの接続を可能にし、Windowsベースのマシンとの相互運用性を実現します。YNQ™のクライアントとサーバーの両方で、SMB over QUICへの対応が提供される予定です。ここでいう「組み込みシステム」は、広い意味で解釈してください。たとえば、AppleのiPad（タブレット）やiPhone（スマートフォン）といったiOSデバイスにも対応しています。つまり、このライブラリを使えば、iOS上で動作するSMB over QUIC対応のクライアントアプリケーションを開発することが可能です。さらに、Windows以外のオペレーティングシステム向けに、SMBのシステムドライバーも提供されています。
YNQ™は、オペレーティングシステム、CPU、コンパイラを問わず、ほぼあらゆる環境に統合できる柔軟性を備えて設計されています。このYNQ™を用いたファイル共有により、複数の組み込みデバイス同士が互いのSMB共有フォルダにリモートでアクセスし、ファイルの閲覧、読み取り、書き込み、編集、コピー、削除、更新といった操作を実行することが可能です。これらの操作では、ファイル全体をローカルのディスクやメモリに転送する必要がなく、非常に効率的です。
JNQ™
私のラボで稼働しているいくつかのシステムは、ネイティブでSMB over QUICをサポートしていません。たとえば、Windows Server 2022 や 2019、Windows 10、Ubuntu 20.04 や 21.04 といった最新のオペレーティングシステムですら、SMB over QUICには対応していません。それでも、Visuality Systemsがデモ用に構築したアプリケーションのおかげで、これらのクライアントシステムから Windows Server Datacenter Azure Edition 上のWindowsファイル共有に、SMB over QUIC経由でアクセスすることができています。このデモアプリケーションは、Visuality Systemsが提供するJavaベースのSMBクライアントライブラリ（JNQ SMB クライアントライブラリ）を活用しています。このライブラリは、Oracle Java、OpenJDK、IBM Javaなど、主要なJava実装すべてで利用可能です。さらに、JNQ™はJavaアプリケーション（Java 1.5以上）に対して、SMBファイル／データ共有のクライアント機能を提供します。
以下のスクリーンショットをご覧ください。SMB over QUIC にネイティブ対応していない Linux や Windows のオペレーティングシステムからでも、Windows Server 2022 Datacenter Azure Edition 上のファイル共有にアクセスできている様子をご確認いただけます。
同じアプリケーションをWindows 10上でも実行しており、SMB over QUICを通じてファイル共有にアクセスできています。このアプリケーションは、Windows 8やWindows 7、さらにはWindows 11上でも動作可能です。このアプリケーションは、Visuality Systemsのライブラリを利用しており、OSに標準搭載されているSMBクライアントの機能に依存していません。
Visuality SystemsのSMBライブラリを活用することで、さまざまなオペレーティングシステムやプラットフォームが、SMB over QUICを通じたインターネット越しのセキュアなファイル共有アクセスの恩恵を受けられるようになります。
最後の例として、Androidを見てみましょう。下のスクリーンショットは、Visuality Systemsのファイルマネージャーアプリでの動作例です。
このアプリは、TCPとQUICの両方に対応しています。そうです、Androidのスマートフォンやタブレットからでも、SMB over QUICが利用できるのです。また、システムのDNS設定をそのまま使用することも、カスタムDNSを指定することも可能です。
Linux用システムドライバー
もし、SMBクライアントをシステムドライバーとして提供できたらどうでしょうか？
たとえば、任意のLinuxシステムにインストールできるようなものを、そして、そのドライバーがSMB over QUICに対応していたら？それはつまり、Linuxホストにドライバーをインストールするだけで、UbuntuのNautilusファイルマネージャーから、SMB over QUICを使って直接ファイル共有にアクセスできるということを意味します。
驚くべきことに、Visuality Systemsはこのドライバーに対するSMB over QUICサポートの開発に取り組んでいます。可能性は無限大です！
認証方式：NTLMv2 と Kerberos
Visuality Systems のライブラリは、NTLMv2 と Kerberos の両方に対応しています。企業ネットワークのように Active Directory 環境が構成されており、ドメインコントローラーに到達可能な場合は、Kerberos 認証が利用可能となり、クライアントはそれを使用してファイルサーバーへのアクセス認証を行います。これは、推奨される最も安全な認証方式です。一方、ドメインコントローラーや Kerberos が利用できない環境では、NTLMv2 が試行され、可能であれば使用されます（ただし、NTLMv2 がブロックまたは無効化されていないことが前提です）。
たとえば、インターネット上のクライアントがドメインコントローラーに直接アクセスできない場合、NTLMv2 が使用されます。この一連の認証プロセスは、QUIC の TLS 1.3 による AES-128 または AES-256 暗号化トンネル内で保護・暗号化されており、情報が収集・傍受される危険から守られています。
ヒント：
NTLMがどこで、いつ使われているかを確認する簡単な方法のひとつは、グループポリシーを使って監査を有効にすることです。これにより、ドメインコントローラー上の「Microsoft-Windows-NTLM/Operational」イベントログで、どのクライアントからNTLM認証が発生しているかを確認できます。
Kerberos対応とKDCプロキシサーバーのサポートについて
セキュリティに関する会議でチーフ・インフォメーション・セキュリティ・オフィサー（CISO）を混乱させたいなら、「このソリューションはNTLMv2が必要です」と言ってみるとよいでしょう。もちろん、多くの組織では依然として必要に迫られてNTLMv2を有効にしているのが現実です。正しく構成すれば大きな問題が起きるわけではありませんが、技術的負債の観点から見ても、また継続的にセキュリティ水準を引き上げている組織にとっては、歓迎される話ではありません。そのため、多くの企業ではNTLMv2の使用を削減、あるいは可能な限り排除しようと取り組んでいます。SMB over QUICがそうした環境で成功するためには、この課題に対応する必要があります。つまり、SMB over QUICは企業ネットワーク内でドメインコントローラーに直接アクセスできる環境でKerberosを使えるだけでは不十分です。KDCプロキシを活用すれば、インターネット経由でもKerberosを使用することが可能になります。このKDCプロキシはHTTPS（ポート443）経由でアクセスできるため、インターネットから安全にKerberos認証が行えるのです。
Windowsでは、クライアントがドメインコントローラーを見つけられない場合に、KDCプロキシの使用を試みるよう設定することができます。さらに、Visuality Systemsのライブラリを活用したカスタムアプリケーションでも、将来的にKDCプロキシを利用できるようになる予定です。現在、同社がそのサポートの実装に取り組んでいるからです。すごいですよね？QUICのおかげでインターネット経由でも安全にSMBファイル共有へアクセスできる上に、Kerberosも活用できるのです。
未来は明るい
注目すべき点として、Azure Files も Kerberos 認証をサポートしていることが挙げられます。KDC プロキシを自社環境に設置するか、Azure 上で IaaS として提供できれば、このようなユースケースにおいてもインターネット越しに Kerberos を利用してファイル共有へアクセスすることが可能になります。将来的に Azure Files が SMB over QUIC をサポートすれば、すぐに利用を開始できる体制が整うというわけです。デバイス側が対応していれば、今後どのような可能性が広がるのか楽しみです。
とはいえ、現時点でも既に、対応している SMB クライアントアプリケーションがあれば、SMB over QUIC を通じてファイル共有を外部に公開することができます。この仕組みを動作させるには、クライアントデバイスがドメインに参加している必要がありますが、それは Linux でも可能です。また、デバイスが AD DS ドメインに参加していない場合でも、条件がそろえば AD の認証情報を用いた認証が可能になる場合もあります。具体的には、デバイスがドメインコントローラーへの直接アクセスを持っているか、KDC プロキシサーバーが利用可能であり、かつクライアント側が Kerberos に対応している必要があります。
将来を見据えるとき、すでに実現可能なことを見落としてはなりません。Windows Server 2022 Datacenter: Azure Edition では、SMB over QUIC を Azure Files や Azure File Sync と組み合わせることで、Azure Files 上のすべてのデータを SMB over QUIC 経由で公開することが可能です。同様のことは、Azure Stack HCI 上で Windows Server 2022 Datacenter: Azure Edition を実行しているオンプレミス環境でも実現できます。
これにより、柔軟なハイブリッド構成も可能になります。たとえば Azure File Sync を利用すれば、オンプレミスのファイルデータを Azure Files に保存・保護できます。そして、Azure IaaS 上で稼働する Windows Server 2022 Datacenter: Azure Edition に対して Azure File Sync を構成しておけば、従来はVPN経由でしかアクセスできなかったそのファイルデータを、SMB over QUIC を通じて安全にインターネット経由で公開できるのです。以下の図をご覧ください。このようなハイブリッド構成では、Visuality Systems の JNQ や YNQ ライブラリを使ったソリューションが、ほぼあらゆるデバイスから SMB over QUIC 経由でファイルデータにアクセスすることが可能になります。
オンプレミス、ハイブリッド、あるいは Azure のパブリッククラウドにおいて、Visuality Systems は SMB over QUIC を通じたファイルデータの活用に、ユーザー、アプリケーション、システムに向けてさらに多くの選択肢を提供していく予定です。その結果、製薬、銀行、保険といった業界から、製造・物流における IoT やロボティクス、さらには自律システム、サービス／デーモン、そして一般ユーザーに至るまで、ほぼあらゆる分野でこのソリューションの恩恵を受けることができるようになります。
SMB over QUIC の可能性
SMB over QUIC には非常に大きな市場と将来性があります。しかし、この市場を本格的に拡大・成長させていくには、SMB over QUIC に対応するクライアントの数がもっと必要です。特に、Windows OS 環境内だけでなく、モバイルを含む他のプラットフォームにも対応クライアントが広がることが不可欠です。まさにその課題に対して取り組んでいるのが Visuality Systems です。彼らは、誰もが自分のアプリケーションの中で SMB over QUIC を活用できるようにするライブラリやソリューションを提供し、市場の拡大を後押ししています。ここで唯一の制限は、あなた自身の想像力だけです。
たとえば、ユーザーやアプリケーションが、Azure Files や Windows Server 2022 Datacenter Azure Edition 上のファイル共有に、インターネット経由で安全にアクセスできるようになることを考えてみてください。先にも述べたとおり、ファイル共有は決して終わった技術ではありません。むしろ、既存の多くのアプリケーションや、これから生まれる新しいソリューションにとって不可欠な存在です。たとえば、現在の開発トレンドであるコンテナ環境ですら、データの永続化に必要なストレージへのアクセス手段として SMB ファイル共有を活用しています。そのようなストレージを SMB over QUIC によって安全かつより利便性の高い形で提供することこそが、Visuality Systems の製品が目指すゴールです。この点において、Visuality Systems の取り組みは Microsoft が掲げる SMB over QUIC のビジョンと完全に一致しています。さらに素晴らしいのは、Visuality Systemsが、 Microsoft クライアントの限られた対応範囲にとどまらず、SMB over QUIC を他の環境にも広げていることです。彼らはまさにパイオニアとして、他の開発者や企業がこの技術を活用し、新たなアプリケーションを生み出せるようにしているのです。
Didier Van Hoye, Technology Strategist & Microsoft MVP
