要約

  • RFC 862のUDP Echoは受信データを返し、RFC 864のUDP Character Generatorは入力内容を無視して0〜512文字の応答を一件だけ生成した。
  • 最初のデータグラムで送信元をEchoに見せかけると、Chargenの応答がEchoの要求になり、その応答がChargenの次の要求になる。仕掛けた端末は以後送信しなくてもよい。
  • BCP 38はこの組み合わせを具体例として記録し、外部公開と送信元プレフィックスを制御点にした。後の文書は非対称経路を考慮した検査、相手確認、レート制限、サーキットブレーカーを加えた。

ログに残ったのは二つの正常動作だった

片側の記録だけを読むと異常は見えにくい。Character Generatorは要求を一件受け、応答を一件送った。Echoもデータグラムを一件受け、同じ内容を一件返した。どちらも二重応答をしておらず、仕様に反した余分な処理もしていない。

二つの時計を重ねると意味が変わる。Chargenの送信はEchoの受信であり、Echoの送信はChargenの次の受信である。要求を新しく作っている人はいない。直前の応答が次の要求を作るため、因果だけが輪の中を回り続ける。

最初の参加者がしたことは、内容を巧妙に設計することではなかった。送信元アドレスとポートを、もう一方のサービスに見せかけたのである。偽の身元が二つの応答先を閉じた瞬間、発信者は通信から退けた。

試験装置のための最小サービス

RFC 862はEchoをデバッグと測定のサービスとして定義した。TCPでは接続が閉じるまで受け取ったデータを返す。UDPではポート7でデータグラムを受け、その中身を回答データグラムとして送り返す。

RFC 864のCharacter Generatorも試験用だった。TCP版は既知の文字列を連続送信し、速度はTCPのフロー制御に任せる。UDP版はポート19で入力内容を捨て、0から512文字までのランダムな長さを選び、回答を一件返す。要求をまたぐ履歴はない。

実装の容易さは本来の価値だった。認証やコマンド体系を準備しなくても、往復経路や文字の扱いを確認できる。しかし状態を持たないため、「いま届いた要求は、自分の前の応答が別サービスから返されたものか」という因果情報も持てなかった。

RFC 768のUDPは、その簡潔さを運ぶ。データグラムには送信元・宛先ポート、長さ、チェックサムがあり、送信元ポートは回答先として使える。回答前に相手との接続を確立する手順も、相手を認証した関係も作らない。

一件という上限は、系全体の上限ではない

RFC 864は、UDP Chargenが各受信データグラムに一つしか返さないため、要求より速く送信する心配はないと説明した。一つのサービスだけを関数として見れば、その説明は成立する。自分から二件目を生成しないからだ。

ところが、ある関数の出力が別の関数の入力になり、その出力が最初へ戻るなら、一件という数字は取引の終端ではなく輪の一辺になる。局所的な呼び出し回数は有限でも、呼び出しを作る経路が閉じていれば全体の回数は決まらない。

これは設計審査にも残る問題である。コンポーネント単体試験がすべて合格しても、出力先を追わなければフィードバックは見えない。必要なのは「何件返すか」だけでなく、「返したものが再び処理権を得るか」という問いである。

BCP 38は二つのサービスを名指しした

RFC 2827、すなわちBCP 38は、送信元詐称の抽象論だけを書いた文書ではない。UDPパケットを偽装して、あるサイトのCharacter Generatorと別サイトのEchoを接続する例を明記した。二つのシステムは互いにトラフィックを送り続ける。

最初の対策は公開範囲である。文書は、この種の診断ポートを管理ネットワークの外から到達可能にすべきでないとする。サービスまで経路がなければ、外部の一包で応答権を利用されない。プロトコル本文を書き換えず、誰が起動できるかを変える制御だ。

次の対策は、顧客からプロバイダーへ入る場所で送信元を調べることだった。顧客が正当に広告するプレフィックスに属さない送信元なら、外へ運ぶ前に落とす。被害側で受け止めるのではなく、虚偽の主張をネットワークが最初に引き受ける境界で拒否する。

経路の妥当性と端末の本人性は違う

BCP 38自身が限界を示している。許可されたプレフィックス内の別ホストを詐称するパケットは、単純なプレフィックス検査を通る。正しい送信元を使った大量送信も止めない。検査が証明するのは「この顧客範囲から出ても不自然ではない」ことであって、送信した端末の本人性ではない。

さらにマルチホームと非対称経路がある。RFC 3704は厳密、実行可能経路、緩い逆方向検査、ACLを扱った。厳密方式は受信インターフェースが最良の戻り経路と一致することを求めるため、正常な非対称通信まで拒否し得る。

緩い方式はルーティング表に存在しない送信元を落とせるが、詐称の余地は広い。実行可能経路方式は正当な複数経路を認めやすいが、必要な経路情報を維持しなければならない。ACLは明示的でも、プレフィックス変更への追随が要る。方式名だけでなく、現実の経路に対して何を証拠としたかを残す必要がある。

UDPアプリケーションが持つべき最小の判断

RFC 8085は一般のUDP利用に教訓を広げる。ローカルでUDPソケットを特定の相手に接続しても、相手には通知されず、認証済みセッションにもならない。特定の送信元が必要なら、アプリケーションまたはOSが明示的に確認しなければならない。

UDPにはフロー制御もない。短い要求から大きな回答を作る設計は抑え、詐称可能なIPアドレスを認証として使わず、大きな応答を起こす要求を認証・限定することが求められる。レート制限やサーキットブレーカーは、個々の包が正しくても、連続して答える根拠が残っているかを問うための状態になる。

一つの対策が他を代行することはない。公開停止は内部端末を認証しない。プレフィックス検査は同一範囲内の端末を区別しない。レート制限は被害を抑えるが、偽の身元を直さない。だからこそ、用途の薄い診断サービスは、複雑な認証を足す前に公開自体を再考すべきである。

登録番号は利用許可証ではない

現在のIANAサービス名・トランスポートプロトコルポート番号レジストリは、TCP/UDPのポート7をecho、ポート19をchargenとして記録している。独立した実装が同じ入口を探せるのは、この名前空間が安定しているからだ。

レジストリは、いま特定ホストがサービスを動かしていること、外部公開していること、RFCどおりであること、安全であることを証明しない。インシデントではポート番号に加えて、ペイロード、方向、時間差、所有者、応答が次の要求を発生させた証拠が要る。

終了条件を誰が持つのか

EchoもChargenも、理解しやすい局所動作を提供した。問題は悪意ある命令ではなく、偽の送信元によって二つの回答権が接続されたことだった。全経路を見られる当事者がいないため、各サービスは停止の判断材料を持てない。

教訓は、無状態サービスを一律に否定することではない。出力が入力へ戻る経路、応答先を決める身元情報、権限を撤回する境界、因果を復元できる観測を、組み合わせとして設計することである。

制御は分散している。運用者は到達性を決め、アクセス網は送信元主張を狭め、アプリケーションは相手とコストを判断し、監視は二つの正常ログを一つの輪として結ぶ。一対一という局所ルールが安全になるのは、結果の終点をどこかの層が検証できる時だけだ。

出典と証拠の限界

これらは仕様、記録されたループ、フィルタリング方式、後年のUDP指針を裏付ける。現在の公開台数、攻撃頻度、平均増幅率、BCP 38の世界的導入率は示さない。本稿は仕組みを歴史的証拠として扱い、現代の規模推計には使わない。