New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pflang + IPv6 extension headers are currently a poor match #239

Open
kbara opened this Issue Jul 1, 2015 · 0 comments

Comments

Projects
None yet
1 participant
@kbara
Contributor

kbara commented Jul 1, 2015

Pflang, as implemented by both pflua and libpcap, compiles pflang expressions to checks against fixed offsets, before looking at any packets. The consequence of their current implementations is that in the presence of IPv6 extension headers (aside from the special case of exactly one extension header, IPv6-frag), pflang expressions such as tcp or udp do not match packets that they would match in the absence of IPv6 extension headers.

% ./env pflua-compile "ip6 and tcp"
local cast = require("ffi").cast
return function(P,length)
   if length < 54 then return false end
   if cast("uint16_t*", P+12)[0] ~= 56710 then return false end
   local var2 = P[20]
   if var2 == 6 then return true end
   if length < 55 then return false end
   if var2 ~= 44 then return false end
   return P[54] == 6
end
% tcpdump -d "ip6 and tcp" 
(000) ldh      [12]
(001) jeq      #0x86dd          jt 2    jf 8
(002) ldb      [20] <-- IPv6 next header field
(003) jeq      #0x6             jt 7    jf 4 <-- TCP
(004) jeq      #0x2c            jt 5    jf 8 <-- IPv6 fragment
(005) ldb      [54] <-- IPv6 next header field of the fragment header
(006) jeq      #0x6             jt 7    jf 8 <-- TCP
(007) ret      #65535
(008) ret      #0

In both libpcap and pflua, byte 20 (the IPv6 'next header') field is being checked against values 6 (TCP) and 0x2c (44, IPv6 fragment header). [1] If there is an IPv6 fragment header, byte 54 is then checked to see whether that header's "next header" field value is 6 (TCP).

If the next header is an IPv6 extension header other than an IPv6 fragment header, or there is more than one IPv6 extension header, the encapsulated protocol will not be matched by either pflang implementation.

This is a known shortcoming of libpcap, and is somewhat awkward to fix while targeting BPF; the tcpdump-workers bugtracker and mailing list have occasional discussions about how to address it.

[1] The values are enumerated at http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment