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


113

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

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

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

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

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


10
この質問に基づいて、私は愚かではないようです。そうです、私はこの権利を読んでいます。(現実の世界では)新しい拡張ヘッダーをIPv6に追加することは不可能です。 stackoverflow.com/questions/9847923/...
AdamIerymenko

10
そしてはい、ヘッダーの長さを計算するにはリンクされたリストのトラバーサルが必要であるように見えます:stackoverflow.com/questions/14762193/…誤解 しないでください。IPv6は素晴らしく、必要とされています。しかし、これはまだ骨の折れているようです。
AdamIerymenko 2013

3
仕様(先頭のコメントにリンクされている)は、ルーターはヘッダーを見ることが想定されていないため、どのヘッダーを追加してもかまいません。宛先ノードのみがヘッダーを見ることになっています。
アンデルスE.アンデルセン

2
ただのメモ:「hair-brained」はかなり紛らわしい綴りであり、「hare-brained」が好まれるはずです(ソース:tfd
pzkpfw

2
正しいつづりが1つしかない限り、これは「頭脳」です。
アランB

回答:


33

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

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

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

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


97

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

RFC 2460から:

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


15
良い。私は私の心を失っていると思った。したがって、そうです、それは本当に完全に拡張できない設計です...少なくとも帯域内シグナリングや他のハックなしでは。これは、両端を制御し、アプリの新しいバージョンのみを考慮する必要があるアプリケーションプロトコルでは言い訳になりませんが、何百年も続くように設計されたものでは許されません...
AdamIerymenko 2013

8
不明なヘッダーを無視する機能があると、はるかに複雑な問題が発生します。(中間プロキシがカプセル化ESPヘッダーを認識せずにTCPヘッダーを変更した場合はどうなりますか?)この場合、単純さは「拡張可能」に勝ります!
jman 2013

4
@Max IPv6には、文字通り、地球上のすべての原子に1つを割り当てるのに十分なアドレスがあります。このスペースを使い果たすインターネットに接続されたトースターの数はありません。
タイラーマクヘンリー2013

8
@Max絶対にIPv7が必要になるとは決して言いませんが、IPv6を使用すると、地球の大気(130,000km上)の1 立方ミリメートルごとに一意のアドレスを与えるのに十分なアドレス空間があります... 100,000倍。つまり、他の銀河の植民地化を開始すると、心配なことはあるかもしれませんが、それまではかなり良いことです。
シンコデナダ2013

4
一部のコンテキストが欠落しています:With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.
東武

28

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

不正解です。理由:

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

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


1
そして、あなたはそのICMPパケットが実際の送信者へのNATを通過することを確信していますか?
デクスター

5
@Dexter ipv6はNATを停止します...うまくいけば
Janus Troelsen

2
@Dexter:これらのICMPパケットは、いくつかの理由で到着する必要があります。たとえば、パイプのMTUが縮小し(PPPoEまたはVPNが原因でパケットのカプセル化が発生した可能性があります)、送信されるパケットが大きすぎる場合、ICMPパケットが返され、パケットが大きすぎるというメッセージが表示されます。
ビル・リンチ

4
@JanusTroelsen全員があなたの希望を共有するわけではありません。
デクスター

4

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

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

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.