Summary

  • RFC 2979 は、意図的なセキュリティ拒否と、準拠した通信を意図せず壊す障害を分け、後者の修正責任をファイアウォールと関連ソフトウェアに置いた。
  • Path MTU Discovery のエラーと SMTP 拡張の例は、単純に見える規則でも中間装置が通信を破綻させうることを示した。

ポリシー上の拒否とプロトコル障害は同じではない

2000年前後、エンドツーエンドの理想は実務上の境界に直面していた。組織は価値ある内部システムを、全面的には信頼できないネットワークにつなぐようになり、通信を選別するファイアウォールがその境界に置かれた。しかし動作の説明は不十分なことが多く、実装差が本来のセキュリティ方針を超えた問題を生んでいた。

RFC 2775 はすでに「透明性」を、エンドツーエンド機能、性能、アドレス透明性など複数の論点に分けていた。RFC 2979 はこれを運用上の契約に絞る。ファイアウォール、トンネル、アクセス交渉を導入しても、それがなければ動作する正当かつ標準準拠の利用を、意図せず失敗させてはならない。起きた場合はファイアウォールや関連ソフトウェアを直すべきで、既存プロトコルや実装の変更を求めるべきではない。

これはすべてのパケットを通せという要求ではない。サイトは標準に沿った通信であっても、正当でないと判断したアクセスを遮断できる。SOCKS のような追加認証・認可手段を設け、特定構成でその利用を求めることも認められる。ただし、その手段を必須にしない構成も許す必要がある。重要なのは、方針に基づく意図的な拒否と、中間装置が通信を理解できずに起こす偶発的な破綻とを区別することだ。

ICMP エラーを捨てると正当な通信がブラックホールに落ちる

Path MTU Discovery の例は具体的だった。IPv4 の送信側は Don't Fragment ビットを立てて送れる。途中リンクが大きさに対応できなければ、ルーターは ICMP「Destination Unreachable / Fragmentation Needed」を返し、送信側にパケットを小さくするよう知らせる。ファイアウォールが送信を許可しながら応答だけ捨てると、送信側は通らないサイズの通信を繰り返すことになる。これは有効な防御判断ではなく、ブラックホールである。

RFC 2979 は、ICMP を一律に通せとは述べていない。正当な送信に対応するエラーと、Echo、Redirect、無関係なエラーを区別し、後者をサイト方針で遮断できるとした。同じプロトコル群にも、正規の通信に必要な制御情報と、拒否してよいトラフィックがある。文脈が判断を変える。

SMTP の拡張応答が三者間の不整合をつくる

SMTP ではクライアントが EHLO で拡張機能を尋ね、サーバーが機能一覧を返し、クライアントが利用するものを選ぶ。プロキシが EHLO コマンドを許可するだけで、サーバーの応答一覧を絞り込まなければ、両端はプロキシ自身が扱えない拡張を合意してしまう。両端は自然に振る舞っていても、中間装置が正しく中継できない対話を成立させてしまう。

教訓はすべてのファイアウォールが新しい拡張を実装しなければならないということではない。RFC 2979 は、アプリケーションに不利益がない範囲でファイアウォールを通りやすく設計するよう勧めた。80番ポートが開いていそうだからという理由だけで、新プロトコルを HTTP に包むことも戒めている。安全なサブセット、適切な通過手段、別ポートの登録のほうが明快なことがある。

RFC が示す範囲と、示さない範囲

RFC 2979 は Informational 文書であり、インターネット標準ではない。草案の履歴は2000年8月の IESG 承認と同年10月の公開を記録している。ここから分かるのは設計原則と例であって、製品の採用率、実装の適合度、迂回の減少、あるいは安全性向上の実測ではない。

その歴史的な貢献は責任の境界を示したことだ。セキュリティ方針は通信を拒否できるが、偶発的な非互換をアプリ開発者の回避策に黙って転嫁してはならない。運用者は障害時に「意図的な拒否」か「フィルター、プロキシ、パーサーによる準拠通信の破壊」かを分類できる。この診断法は RFC から導く現在の推論であり、当時の現場の実態を測った記録ではない。

RFC 3093 は隣接する別の文書だ。2001年4月1日付の Informational RFC は IP/TCP を HTTP 内に運ぶ Firewall Enhancement Protocol を提案した。RFC 2979 の失敗や、そのトンネルの実運用を証明するものではない。またファイアウォール機能と NAT は別物だと RFC 2979 は明記している。ひとつの機器が両方を担うことはあっても、機能を混同してはいけない。

出典：RFC 2979、RFC 2775、RFC 3093、草案履歴、RFC 1191、RFC 1869。