解析包含未知扩展的 IPv6扩展头

我正在编写一个非常简单的净过滤器，然后到我想要解析 IPv6报头以匹配诸如 ICMPv6类型、 TCP/UDP 端口号等内容的地方。

所以我深入地阅读了 IPv6数据包格式，我有点像... 嗯... 我不得不一遍又一遍地阅读它，以确保我实际上是正确的阅读它。 在我看来，您必须从40字节的固定头部开始，然后查看它的下一个头部字段。然后，您必须查看下一个标题的下一个标题字段，以此类推，就像链表一样，直到到达结尾。如果有有效载荷，它就会跟着来。

问题是在固定标头或扩展标头中都没有长度字段。您必须有一个扩展头类型及其大小的表，以便您可以追踪这个链接列表到结尾。

我觉得这是一个奇怪的，甚至可能是轻率的设计。如果我遇到一个无法识别的扩展头类型怎么办？我该怎么办？我不知道它的长度。我想我必须扔掉数据包并阻止它，因为在允许数据包通过的网络过滤器中，将允许攻击者通过包含伪造的头类型来逃避网络过滤器。但是这意味着如果协议被扩展，那么如果要使用新的扩展，那么 IPv6头解析软件的每一部分都必须同时更新。

因此，如果我不知道他们使用的扩展，我如何解析 IPv6头文件？既然我不知道一个未知扩展的标题的长度，那么我怎样才能跳过它呢？

38495 次浏览
小开

What if I encounter an unrecognized extension header type?

From RFC 2460:

If, as a result of processing a header, a node is required to proceed to the next header but the Next Header value in the current header is unrecognized by the node, it should discard the packet and send an ICMP Parameter Problem message to the source of the packet, with an ICMP Code value of 1 ("unrecognized Next Header type encountered") and the ICMP Pointer field containing the offset of the unrecognized value within the original packet. The same action should be taken if a node encounters a Next Header value of zero in any header other than an IPv6 header.

小开

It is (in the real world) impossible to add a new extension header to IPv6.

Incorrect, because:

  1. Only the destination host is allowed to reject based on unrecognized extensions headers (with that one exception mentioned in the question you linked)

  2. If your new extension header is in some way optional (it had better be), you will receive an ICMP error about that and can try again without it.

小开
最佳答案

If you run into something you cannot parse, you have to make your decision or perform your action based on what you've parsed already.

The design is that way because in IPv6, each extension header "wraps" the rest of the packet. If you see the routing header, then some header you've never heard of, then the payload, then you cannot parse the payload. The meaning of the payload depends in principle on the header you don't know how to interpret.

Routers can route such packets, because all they need is the routing header. Deep packet inspection gadgets and suchlike need to know a lot, but then that's their fate anyway.

Edited to add: This design means that middleboxes can only change what they know. If a middlebox sees a header it doesn't know, then it has only two options: Reject or pass on. In IPv4 it could also remove the unknown extension and pass on the rest. IMO this property makes the design more rather than less extensible.

小开

The update RFC 6564 covers this case. It lays out exactly the scenario you describe and puts forth a format for any new extension headers (if any are ever defined) which middleboxes such as yours will be able to work with, at least some of the time.

Keep in mind that it isn't intended to extend IPv6 by creating new extension headers, but by adding new Destination Options. It should be trivial, or at least much easier, for you to deal with unknown destination options.


提交答案