RFC 3514
読み:アーエフスィーさんごーいちよん
外語:RFC 3514: Request For Comments 3514
「IPv4ヘッダー中のセキュリティフラグ」を定義するRFC。evil bitを定義するもので、情報提供プロトコル(Informational)として公開されている。
情報
- 題名
- The Security Flag in the IPv4 Header
- IPv4ヘッダー中のセキュリティフラグ
- 発行日: 2003(平成15)年4月1日
- 著者: Steven M. Bellovin/AT&T Labs Research
- プロトコル: 情報提供プロトコル(INFORMATIONAL)
- カテゴリー: Informational
- 関係
- 破棄: (なし)
- 被破棄: (なし)
- 被更新: (なし)
- 関連: (なし)
概要
由来
昨今、クラッキング、すなわちネットワーク経由での破壊活動が世界的な問題となっている。
Microsoft Outlook ExpressやMicrosoft Windows、IISの不具合を利用したワームの流行などがその代表といえる。
そこで2003(平成15)年4月1日、満を持してRFC 3514が発行された。
ビット
IPv4ヘッダーには3ビットのフラグ領域があるが、このうち最上位ビットは未使用で、0固定だった。
このRFCにより遂に機能が割り当てられ、「evil bit」(悪意あるビット)として定義された。
クラッカーが悪意あるパケットを送信する場合は、このevil bitを1にすることが推奨されている。
技術
実装
様々なIPv4の実装において、evil bitが1となる「悪意あるパケット」の除外機能が搭載された。
RFC発行当日に、BSDの大御所FreeBSDに実装され(但し翌日には削除)、またアメリカのネットワーカーのコミュニティーSlashdotでも話題騒然となった。
Ethereal/Wiresharkなどでは今もサポートされており、evil bitが表示されるようである。
特徴
この機能のうち、受信部分では「悪意あるパケットの除外」が期待され、極めて安全な運用が実現される可能性がある。悪意あるパケットに脅える日々から解放されるだろうことは疑う余地が無い。
送信部分では、NATやプロクシー経由の通信にevil bitを立てるべき、ともされている。
また、インセキュアなシステムはクラッシュするか侵入される等を選択しても良い、などと規定されているあたりが笑いのポイントである。
しかし、このRFCに完全に準拠すると、逆にセキュリティホールが出来る。なぜなら、evil bitが0のパケットに対しては、無害であることを仮定する必要があり(SHOULD)、防護手段を講じてはならない(SHOULD NOT)、としているからである。evil bitが1のパケットを排除するだけなら、セキュリティホールにはならないだろう。
なお、一般に、これはジョークRFCと呼ばれている。
再検索