QUICのパケット番号のエンコーディング/デコーディングについて

QUICクライアントの、接続の実装をしているときには動作に問題がなかったので気が付かなかったのですが、パケット番号のエンコーディング、デコーディングが必要になります。

パケット番号は0~262-1 までの値をとります。一方で、QUICのパケットのフォーマットを見ると、1~4バイトまでしか格納できません。なので、そのままではパケット番号を格納することができなくなります。

パケット番号を格納するために、パケット番号の下位ビットのみを含めます。これにより必要となるビット数を削減できます。

続きを読む

技術書典14 で「詳解QUICクライアント接続編」という本を頒布します

2023年5月20日(土)から6月4日(日) に行われる 技術書典14に参加します。

プロトコル研究所」というサークルで「詳解QUICクライアント接続編」というタイトルで本を頒布します。

5月21日(日)には池袋サンシャインシティ 展示ホールDで行われるオフラインマーケットに え10 のスペースでオフライン参加もします。

続きを読む

QUICのechoクライアントを作ってみました&技術同人誌を書いています

twitter には書いていたのですが、s2n-quicのecho exampleと接続し、echoを送りあうQUICクライアントを作っていました。

github.com

この時の経験を技術同人誌にしてまとめようとしています。 いつ出すかは確定していませんが、近いうちに出せるとよいなと思いながら作業を進めています。

以下はサンプルページです。

サンプル1

サンプル2

サンプル3

RFC9001 A.2. Client Initial のQUICパケットの暗号化とQUICヘッダーの保護をやってみる

今回は、RFC9001 A.2. Client Initial にある、QUICのパケットの暗号化と、QUICヘッダ―の保護のサンプルを実際に行ってみます。

このサンプルでは、Initialパケットの暗号化とヘッダーの保護のサンプルを提示しています。

本記事では、最初にQUICパケットの暗号化とQUICヘッダーの保護がどのように行われているかを確認し、そのあとに実装を説明します。

Initialパケットのヘッダーは以下のようになっています。

c300000001088394c8f03e5157080000449e00000002

Initialパケットのペイロードは以下のようになっています。ここはCRYPTOフレームしか含まれていませんが、この後に1162バイトになるまでPADDINGフレームが含まれます。

060040f1010000ed0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e868
04fe3a47f06a2b69484c000004130113 02010000c000000010000e00000b6578
616d706c652e636f6dff01000100000a 00080006001d00170018001000070005
04616c706e0005000501000000000033 00260024001d00209370b2c9caa47fba
baf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b000302030400
0d0010000e0403050306030203080408 050806002d00020101001c0002400100
3900320408ffffffffffffffff050480 00ffff07048000ffff08011001048000
75300901100f088394c8f03e51570806 048000ffff
続きを読む

RFC9001のA.2. Client Initial にあるCRYPTOフレームのサンプルを読み解いてみる

RFC9001 A.2. Client Initial にある以下のCRYPTO Frameを読み解いてみます。

060040f1010000ed0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e868
04fe3a47f06a2b69484c000004130113 02010000c000000010000e00000b6578
616d706c652e636f6dff01000100000a 00080006001d00170018001000070005
04616c706e0005000501000000000033 00260024001d00209370b2c9caa47fba
baf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748002b000302030400
0d0010000e0403050306030203080408 050806002d00020101001c0002400100
3900320408ffffffffffffffff050480 00ffff07048000ffff08011001048000
75300901100f088394c8f03e51570806 048000ffff

先に結果を書くと、以下のようになります。

CRYPTOフレームの定義があります。そのあとに、TLS1.3のClientHelloが含まれます。ClientHelloの拡張の中には、QUIC Transport Paramter 拡張も含まれています。

060040f1: CRYPTOフレームの定義
010000ed: Handshakeの定義
0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e868: 
0303ebf8fa56f129 39b9584a3896472ec40bb863cfd3e86804fe3a47f06a2b69484c00000413011302010000c0 : Client Helloの定義(extensionの長さを示す部分まで)
00000010000e00000b6578616d706c652e636f6d: server_name拡張の定義
ff01000100:  Renegotiation Indication 拡張
000a00080006001d00170018: supported group 拡張
00100007000504616c706e: ALPN拡張
000500050100000000: status request 拡張
003300260024001d00209370b2c9caa47fbabaf4559fedba753de171fa71f50f1ce1 5d43e994ec74d748: key share拡張
002b0003020304: supported versions拡張
000d0010000e0403050306030203080408050806: signature algorithms 拡張
002d00020101:  Pre-Shared Key Exchange Modes 拡張
001c00024001: Record Size Limit 拡張
003900320408ffffffffffffffff05048000ffff07048000ffff0801100104800075300901100f088394c8f03e51570806048000ffff: QUIC Transport Parameter 拡張
続きを読む

Improving the reliability of the QUIC Handshake のメモ

Huitema氏が投稿していたImproving the reliability of the QUIC Handshakeという記事のメモです。

QUIC Interop Runner でのテストの中でも、しばしば失敗が検出されたものを紹介しています。

そのケースに対して、問題の起こり方、RFCに対してどのように反映されたのかが書かれています。

続きを読む