netfilter buglog - Feb 2004 - [Bug 48] conntrack breaks udp path mtu discovery

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=48





------- Additional Comments From tatonet@tiscali.it  2004-02-25 15:05 -------
I know that this is an old bug report, but it's still opened...  
If we save the size of each single fragment we have to face another problem: 
how should we re-fragment the packet if original fragments were partially or 
totally overlapped? 
 
Another approach could be the following: 
if the DF flag is set in the fragments of a packet, the maximum length 
fragment determines the fate of the whole packet during routing.   
A possible solution could be to save the maximum length of fragments in 
PRE_ROUTING. Then we can use this maximum length to re-fragment on 
POST_ROUTING (possibly producing more or less fragments than received) and we 
can set the DF flag on fragments. 
In this way NAT can shrink or enlarge packets without causing any problem. 
 
(yes, I know... my English is terrible... ;) ) 
 



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=48





------- Additional Comments From laforge@netfilter.org  2004-02-25 15:37 -------
Yes, the 'saving all fragment sizes' approach is just too complex. 
It's just a
theoretical option.

Saving the maximum fragment size would work, yes.  However, where would we store
it?   This cannot be done by the connection tracking code, since it just hands
off all fragments to the normal IPv4 ip_defrag(), with no way knowing what the
resulting skb's address might be (before the packet is completed).

Hacking ip_fragment to store this kind of information would most likely not go
into the mainstream kernel.  This means we would have to invent defragmentation
on our own :(

There simply is no satisfactory solution, I have to admit.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=48





------- Additional Comments From tatonet@tiscali.it  2004-02-25 16:44 -------
Hi Harald, 
First of all I must say that I'm still studying conntrack, so it's
likely that
I'm wrong. 
When conntrack calls ip_defrag() (in ip_ct_gather_frags()), it passes a skb 
containing a fragment and, eventually, receives a skb containing the complete 
datagram.  
I think we could use the identification field in the fragment that causes 
ip_defrag to return a skb. 
We have to maintain a table with (identification, skb_address, max_frags_len) 
records.  
Each time ip_ct_gather_frags() calls ip_defrag() we update the max_frags_len 
field in the record with the right identification field (or we create a new 
record). When ip_defrag returns a skb, we fill skb_address field. 
On POST_ROUTING we have to check each skb against that table and, if an entry 
is found then we fragment the packet using max_frags_len and we can set the DF 
flag in each fragment. 
However, because we don't know if the kernel discards the fragments, we
should
have a timeout on each entry in the table. 
Can it work? I know, this approach sounds inefficient. Is it worth it? 
 



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=48





------- Additional Comments From laforge@netfilter.org  2004-02-25 17:39 -------
yes, of course this can be done.  But then, as you indicated, there are timeout
issues.  And our timeout would have to _exactly_ and race-free match the
ip_defrag timer, since otherwise we would end up in a setup where the fragment
can still be completed but our entry already vanished.  

I really don't think that his is a viable option.




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=48





------- Additional Comments From tatonet@tiscali.it  2004-02-26 00:30 -------
Hi Harald, sorry for bother you again. 
I agree with you that the solution I've proposed isn't applicable, but I
think
that conntrack really shouldn't break path MTU discovery. 
In IPv4 this conntrack behaviour (although is not correct) isn't a big
problem
because it produces IP datagrams with DF not set: intermediate routers can 
fragment again datagrams so that they can reach destination (source will think 
that it has guessed a good path MTU). 
However, now that netfilter has a new (experimental) l3-indipendent conntrack 
(developed by Yasuyuki Kozakai), we must face a similar problem with IPv6. UDP 
packets in IPv6 datagrams could be fragmented at source, but they will never be 
fragmented by intermediate routers.  
So if we follow the IPv4 conntrack modus operandi we will always produce IPv6 
fragments of a certain (output interface MTU ?) size independently of the size 
of original fragments. If source performs path MTU discovery and for that it 
has to reduce the size of fragments, conntrack will make it impossible. 
More generally, if we must modify original IPv6 fragments, we must preserve 
their size (or at least their maximum size)... 
 



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.