[IPV4]: Safer reassembly

Another spin of Herbert Xu's "safer ip reassembly" patch
for 2.6.16.

(The original patch is here:
http://marc.theaimsgroup.com/?l=linux-netdev&m=112281936522415&w=2
and my only contribution is to have tested it.)

This patch (optionally) does additional checks before accepting IP
fragments, which can greatly reduce the possibility of reassembling
fragments which originated from different IP datagrams.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Arthur Kepner <akepner@sgi.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

1 files changed, 23 insertions, 0 deletions

diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index ebc09a159f62..2b7cf19a06ad 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -46,6 +46,29 @@ ipfrag_secret_interval - INTEGER
         for the hash secret) for IP fragments.
         Default: 600
 
+ipfrag_max_dist - INTEGER
+        ipfrag_max_dist is a non-negative integer value which defines the 
+        maximum "disorder" which is allowed among fragments which share a 
+        common IP source address. Note that reordering of packets is 
+        not unusual, but if a large number of fragments arrive from a source 
+        IP address while a particular fragment queue remains incomplete, it 
+        probably indicates that one or more fragments belonging to that queue 
+        have been lost. When ipfrag_max_dist is positive, an additional check 
+        is done on fragments before they are added to a reassembly queue - if 
+        ipfrag_max_dist (or more) fragments have arrived from a particular IP 
+        address between additions to any IP fragment queue using that source 
+        address, it's presumed that one or more fragments in the queue are 
+        lost. The existing fragment queue will be dropped, and a new one 
+        started. An ipfrag_max_dist value of zero disables this check.
+
+        Using a very small value, e.g. 1 or 2, for ipfrag_max_dist can
+        result in unnecessarily dropping fragment queues when normal
+        reordering of packets occurs, which could lead to poor application 
+        performance. Using a very large value, e.g. 50000, increases the 
+        likelihood of incorrectly reassembling IP fragments that originate 
+        from different IP datagrams, which could result in data corruption.
+        Default: 64
+
 INET peer storage:
 
 inet_peer_threshold - INTEGER