不明な拡張を含むIPv6拡張ヘッダーの解析

私は非常に単純なネットフィルターを作成しており、IPv6ヘッダーを解析してICMPv6タイプ、TCP / UDPポート番号などに一致させる場所に到達しています。

それで、IPv6パケット形式について詳しく読んでいて、まるで…ええと...何度も何度も何度も読んで、実際に正しく読み取っていることを確認しなければなりませんでした。40バイトの固定ヘッダーから始めて、次のヘッダーフィールドを見なければならないようです。次に、最後に到達するまで、リンクリストのように、次のヘッダーの次のヘッダーフィールドを確認する必要があります。ペイロードがある場合は、それに従います。

問題は、固定ヘッダーにも拡張ヘッダーにも長さフィールドがないことです。このリンクされたリストを最後まで追跡できるように、拡張ヘッダータイプとそのサイズのテーブルが必要です。

これは私を奇妙な、おそらくはうんざりしたデザインだと思います。認識できない拡張ヘッダータイプが見つかった場合はどうなりますか？私は何をしますか？長さはわかりません。ネットフィルターではパケットを許可するため、攻撃者は偽のヘッダータイプを含めることでネットフィルターを回避できるため、パケットを破棄してブロックする必要があると思います。しかし、これは、プロトコルが拡張される場合、新しい拡張が使用される場合は、これまでに作成されたすべてのIPv6ヘッダー解析ソフトウェアを同時に更新する必要があることを意味します。

それで、使用している拡張機能がわからない場合、どのようにしてIPv6ヘッダーを解析できますか？長さがわからないので、不明な拡張子のヘッダーをスキップするにはどうすればよいですか？

解析できないものに遭遇した場合は、すでに解析した内容に基づいて決定を下すか、アクションを実行する必要があります。

IPv6では、各拡張ヘッダーがパケットの残りの部分を「ラップ」するため、設計はそのようになります。ルーティングヘッダーが表示され、次に聞いたことのないヘッダー、ペイロードが表示される場合は、ペイロードを解析できません。ペイロードの意味は、原則として、解釈方法がわからないヘッダーによって異なります。

必要なのはルーティングヘッダーだけなので、ルーターはこのようなパケットをルーティングできます。ディープパケットインスペクションガジェットなどは、多くのことを知る必要がありますが、いずれにしてもそれが運命です。

追加のために編集：このデザインは、ミドルボックスが知っていることだけを変更できることを意味します。ミドルボックスが知らないヘッダーを見つけた場合、オプションは2つしかありません：拒否または渡す。IPv4では、不明な拡張子を削除して残りを渡すこともできます。IMOこのプロパティにより、設計の拡張性が低下するのではなく、改善されます。

認識できない拡張ヘッダータイプが見つかった場合はどうなりますか？

RFC 2460から：

ヘッダーを処理した結果、ノードが次のヘッダーに進む必要があるが、現在のヘッダーの次のヘッダー値がノードによって認識されない場合、パケットを破棄し、ソースにICMPパラメータ問題メッセージを送信する必要があります。パケットのICMPコード値1（「認識されない次のヘッダータイプが検出されました」）と、元のパケット内の認識されない値のオフセットを含むICMPポインターフィールド。ノードがIPv6ヘッダー以外のヘッダーでゼロの次ヘッダー値を検出した場合も、同じアクションを実行する必要があります。

（現実の世界では）IPv6に新しい拡張ヘッダーを追加することは不可能です。

不正解です。理由：

1. 宛先ホストのみが、認識されない拡張ヘッダーに基づいて拒否を許可されます（リンクした質問で言及されている1つの例外を除く）

2. 新しい拡張ヘッダーが何らかのオプションである場合（それが望ましい）、ICMPエラーが表示され、それなしで再試行できます。

更新RFC 6564はこのケースをカバーしています。それはあなたが説明するシナリオを正確にレイアウトし、あなたのようなミドルボックスが少なくともいつかは動作することができる新しい拡張ヘッダー（もし定義されていれば）のフォーマットを提示します。

新しい拡張ヘッダーを作成してIPv6を拡張するのではなく、新しい宛先オプションを追加することを念頭に置いてください。不明な宛先オプションを処理するには、それは簡単であるか、少なくともはるかに簡単なはずです。