Subject: Re: Thoughts on draft-gont-6man-deprecate-atomfrag-generation-01

From: Fernando Gont <[email-masked]>
Date: Tue, 02 Dec 2014 07:03:18 -0300

Hi, Alberto,

On 11/27/2014 03:12 PM, Alberto Leiva wrote:
> 
> About the firewall statement:
> 
> The Linux firewall (iptables) requires connection tracking (conntrack)
> while operating on stateful mode. Connection tracking, in turn, depends
> on defragmentation.
> 
> This can be seen while configuring a stateful firewall. The iptables
> command automatically inserts the respective defrag if needed:
> 
> $ # List all modules named "defrag".
> $ lsmod | grep defrag
> $
> $ # Create a random stateful rule.
> # iptables -A FORWARD -i ppp0 -m state ! --state NEW -j DROP
> $
> $ # List the modules again.
> $ # First column in the output is module name. Fourth column is modules
> which depend on it.
> $ lsmod | grep defrag
> nf_defrag_ipv4         12758  1 nf_conntrack_ipv4
> 
> My dilemma is that this has several side effects, of which the most
> hazardous one for my implementation is the unavoidable disregard of the
> DF flag of nf_defrag_ipv4 from certain kernels. If I put an Ubuntu 12.04
> machine (kernel 3.2) as a firewall, it turns off the DF flag of any
> fragments that traverse it.

You mean your NAT64 software produces the fragment, and it is then
handled by the reassembly code, which essentially clears the flag?

> Of course, fragments with DF=true are pretty nonsensical anyway (as far
> as I know), but they aren't illegal either.

They could be employed for UDP PathMTU Discovery....

> About the fragment header problem:
> 
> It's not very important, since it's not completely eradicated by the
> draft yet it's not hard to work around anyway, but in case you're curious...
> 
> After packets have traversed one of the defragmentation modules, the
> tendency of the packet manipulation API of the Linux kernel is to hide
> the packet's fragmentation-related data. I guess this is done to
> simplify the code elsewhere. Any module who depends on either defrag
> does not have to worry about fragmentation at all.
> 
> For example, in kernels 3.13 and above, the fragment headers of IPv6
> fragments are deleted and subsecuent fragments (fragment offset != 0)
> are hidden. When I ask for the length of the packet, it returns the
> length of all fragments combined (minus redundant layer 3 headers, of
> course). Even though by analyzing the memory I can see that the packet
> I'm fetched is truncated, I can ask for data and the API will peek on
> subsequent fragments if needed. This is all reverted when the packet is
> forwarded (unless some random module "linearizes" the packet, in which
> all fragmentation leftovers are irreversibly eradicated and I might well
> be reading and forwarding misleading data).
> 
> It's nice, but it demands some hackery when I need to compatibilize with
> the following idea from RFC 6145:
> 
>     In addition, the rules in Section 4.1 use the presence of an IPv6
> Fragment Header to indicate that the sender might not be using path MTU
> discovery

FWIW, this *might* be interesting to note in our I-D. If you could think
of some short text/paragraph that summarizes this issue, please do let
us know.

(I guess, something along the lines of "In some versions of some
operating systems (e.g. Linux XXX) the use stateful firewalls can also
interfere with the ability of a translator to employ fragmentation for
signaling as specified in [RFC6145].").

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1