ア | イ | ウ | エ | オ |
カ | キ | ク | ケ | コ |
サ | シ | ス | セ | ソ |
タ | チ | ツ | テ | ト |
ナ | ニ | ヌ | ネ | ノ |
ハ | ヒ | フ | ヘ | ホ |
マ | ミ | ム | メ | モ |
ヤ | ユ | ヨ | ||
ラ | リ | ル | レ | ロ |
ワ | ヰ | ヴ | ヱ | ヲ |
ン |
A | B | C | D | E |
F | G | H | I | J |
K | L | M | N | O |
P | Q | R | S | T |
U | V | W | X | Y |
Z | 数字 | 記号 |
「IPv4ヘッダー中のセキュリティフラグ」を定義するRFC。evil bitを定義するもので、情報提供プロトコル(Informational)として公開されている。
昨今、クラッキング、すなわちネットワーク経由での破壊活動が世界的な問題となっている。
Microsoft Outlook ExpressやMicrosoft Windows、IISの不具合を利用したワームの流行などがその代表といえる。
そこで2003(平成15)年4月1日、満を持してRFC 3514が発行された。
この機能のうち、受信部分では「悪意あるパケットの除外」が期待され、極めて安全な運用が実現される可能性がある。悪意あるパケットに脅える日々から解放されるだろうことは疑う余地が無い。
送信部分では、NATやプロクシー経由の通信にevil bitを立てるべき、ともされている。
また、インセキュアなシステムはクラッシュするか侵入される等を選択しても良い、などと規定されているあたりが笑いのポイントである。
しかし、このRFCに完全に準拠すると、逆にセキュリティホールが出来る。なぜなら、evil bitが0のパケットに対しては、無害であることを仮定する必要があり(SHOULD)、防護手段を講じてはならない(SHOULD NOT)、としているからである。evil bitが1のパケットを排除するだけなら、セキュリティホールにはならないだろう。
なお、一般に、これはジョークRFCと呼ばれている。
コメントなどを投稿するフォームは、日本語対応時のみ表示されます