Internet Protocol Next Header escape
In IPv6 header it’s called “Next Header” and in IPv4 header it’s just “Protocol”. This eight bit value contains information about what kind of content we can expect after the IP header. Usual suspect being a value for all familiar TCP, UDP and ICMP. But there’s also other familiar protocols like GRE and L2TP, and parts of bigger systems like IPSec. This header field deserved a closer look since my business is to make sure networks don’t leak, and we design escape tests for that purpose. There are a total of 256 possibilities to try out and this is exactly what our new escape does.
Our testing methodology
There’s 256 possible values to test. We don’t assign values for protocols we already cover with more thorough escapes: TCP, UDP and ICMP. For the remaining 253 values we send IP packet (either IPv4 or IPv6) with proper IP header, the protocol/next header field set to our selected value and our escape payload directly after the IP header.
This is a basic test which shares the same testing principle as we have with testing all ports of TCP or UDP to ensure proper security measures are in place to keep isolated networks isolated.
Random notes about IP protocols
The eight bit field this article focuses on is not a subject to as much discussion as e.g. TCP port numbers are. However, there are some things which can be good or interesting to know.
Mistakes in Firewalling
When designing and implementing firewall rules it’s easy to get stuck in the mindset of IP addresses, TCP and UDP port numbers, and ICMP. It’s easy to forget the other protocols or some IP protocol is left open due to testing and experimentation. The good old rule of deny everything first and allow only what’s needed still stands for this.
Like with TCP and UDP, we have seen this leaking in isolated environments.
Peculiar case in IPv6 fragmentation
IPv6 header contains the field “Next Header”. Specification says it “identifies the type of header immediately following the IPv6 header and uses the same values as the IPv4 Protocol field.” (RFC8200 section 3.)
IPv6 header doesn’t contain fragmentation information or options like IPv4 header does. Any extension IPv6 might require (like fragmentation) is placed after the IPv6 header and the extension type is indicated in the “Next Header” field. The apparent design decision is sound: simplify IPv6 header making it smaller and fixed size of 40 bytes. Compared to IPv4 header with variable length of 20–60 bytes.
This has however led to poor results. Many IPv6 implementations seem to check for known protocols like TCP, UDP or ICMP in “Next Header” and discard the rest. Article about “Dealing with IPv6 Fragmentation in the DNS” from Geoff Huston notes that
Some 37% of endpoints used IPv6-capable DNS resolvers that were incapable of receiving a fragmented IPv6 response.
It seems IPv6’s fragmentation doesn’t work which causes problems for DNS over UDP. Check out references below for link to the article.
IPv6 extensions over IPv4
Since IPv6 Next Header and IPv4 Protocol field share the same values it’s possible to send IPv6 extensions over IPv4. Does it make sense? Probably not. But it’s possible and it might lead to strange or funny results. Our IP Next Header escape of course tests this.
References:
- IANA Assigned Internet Protocol Numbers: https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
- RFC8200: Internet Protocol, Version 6 (IPv6) Specification: https://tools.ietf.org/html/rfc8200
- Dealing with IPv6 Fragmentation in the DNS: https://labs.ripe.net/Members/gih/dealing-with-ipv6-fragmentation-in-the-dns
- Broken packets: IP fragmentation is flawed: https://blog.cloudflare.com/ip-fragmentation-is-broken/
