* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Herbert Xu @ 2005-05-17 22:11 UTC (permalink / raw)
To: David S. Miller; +Cc: akepner, netdev
In-Reply-To: <20050517.104947.112621738.davem@davemloft.net>
David S. Miller <davem@davemloft.net> wrote:
>
> Decreasing ipfrag_time is also not an option, because then
Here is a possible solution to this:
Instead of measuring the distance using time, let's measure it
in terms of packet counts. So every time we receive a fragmented
packet, we find all waiting fragments with the same src/dst pair.
If the id is identical we perform reassembly, if it isn't we increase
a counter in that fragment. If the counter exceeds a threshold,
we drop the fragment.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: David S. Miller @ 2005-05-17 22:12 UTC (permalink / raw)
To: rick.jones2; +Cc: netdev, netdev-bounce
In-Reply-To: <428A613F.1020303@hp.com>
From: Rick Jones <rick.jones2@hp.com>
Date: Tue, 17 May 2005 14:25:19 -0700
> just how much extra overhead would there be to track the interarrival time of ip
> datagram fragments and would that allow someone to make a guess as to how long
> to reasonably wait for all the fragments to arrive? (or did I miss that being
> shot-down already?)
I spam you with fragments tightly interspaced matching a known
shost/dhost/ID tuple, lowering your interarrival estimate. The
legitimate fragment source can thus never get his fragments in
before the timer expires.
Every other one of these IP fragmentation ideas tends to have
some DoS hole in it.
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: David S. Miller @ 2005-05-17 22:13 UTC (permalink / raw)
To: herbert; +Cc: akepner, netdev
In-Reply-To: <E1DYAHF-0006qW-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 18 May 2005 08:11:01 +1000
> Instead of measuring the distance using time, let's measure it
> in terms of packet counts. So every time we receive a fragmented
> packet, we find all waiting fragments with the same src/dst pair.
> If the id is identical we perform reassembly, if it isn't we increase
> a counter in that fragment. If the counter exceeds a threshold,
> we drop the fragment.
And you protect against purposefully built malicious fragments how?
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Rick Jones @ 2005-05-17 22:18 UTC (permalink / raw)
To: netdev; +Cc: netdev-bounce
In-Reply-To: <Pine.LNX.4.61.0505171501510.3184@linux.site>
Arthur Kepner wrote:
> On Tue, 17 May 2005, Rick Jones wrote:
>
>
>>....
>>or an added heuristic of "if have reassembled N datagrams for the same
>>source/dest/protocol tuple with ID's "larger" than 'this one' since it has
>>arrived, we are probably going to wrap so might as well drop 'this one'" for
>>some judicious and magical selection of N that may be a decent predictor of
>>wrap on top of some existing reassembly timout.
>>....
>
>
> How do you define "larger" in this case? A sender is free to choose
> any ID - they can't be assumed to be montonic, for sure.
Actually, I was ass-u-me-ing they would be monotonic, but thinking about it
more, that doesn't really matter. If N datagrams from that source/dest/prot
tuple have been reassembled since the first/current frag of this datagam has
arrived, chances are still good that the rest of the fragments of this datagram
are toast and any subsequent fragments with a matching src/dst/prot/id would
likely create a frankengram.
in broad handwaving terms, those N other datagrams (non-fragmented or fragmented
and successfully reassembled or not I suspect) are a measure of just how far
"out of order" the rest of the fragments of this datagram happen to be. for
some degree of "out of orderness" we can ass-u-me the datagram is toast.
chosing a strawman, if we've received 24000 datagrams from that source/dest/prot
(perhaps even just that source) since we've started reassembling this datagram
from that source/dest/prot, chances seem pretty good indeed that this datagram
is toast. a value of N even smaller than 24000 might suffice.
the devil seems to be in the accounting.
rick jones
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Rick Jones @ 2005-05-17 22:23 UTC (permalink / raw)
To: netdev; +Cc: netdev-bounce
In-Reply-To: <20050517.151239.74747463.davem@davemloft.net>
David S.Miller wrote:
> From: Rick Jones <rick.jones2@hp.com>
> Date: Tue, 17 May 2005 14:25:19 -0700
>
>
>>just how much extra overhead would there be to track the interarrival time of ip
>>datagram fragments and would that allow someone to make a guess as to how long
>>to reasonably wait for all the fragments to arrive? (or did I miss that being
>>shot-down already?)
>
>
> I spam you with fragments tightly interspaced matching a known
> shost/dhost/ID tuple, lowering your interarrival estimate. The
> legitimate fragment source can thus never get his fragments in
> before the timer expires.
>
> Every other one of these IP fragmentation ideas tends to have
> some DoS hole in it.
Are the holes any larger than the existing ones? I've no idea, and perhaps the
only answer is indeed to say "Then don't do that (fragment)!"
rick jones
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: David Stevens @ 2005-05-17 22:40 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <428A6DAF.7040600@hp.com>
> in broad handwaving terms, those N other datagrams (non-fragmented or
fragmented
> and successfully reassembled or not I suspect) are a measure of just how
far
> "out of order" the rest of the fragments of this datagram happen to be.
for
> some degree of "out of orderness" we can ass-u-me the datagram is toast.
> chosing a strawman, if we've received 24000 datagrams from that
source/dest/prot
> (perhaps even just that source) since we've started reassembling this
datagram
> from that source/dest/prot, chances seem pretty good indeed that this
datagram
> is toast. a value of N even smaller than 24000 might suffice.
> the devil seems to be in the accounting.
This assumes that you have a per-destination IP ID. If it's
per-route,
you can send 1 packet to host A, 65534 to host B through the same route,
and
1 to host A-- wrap on the next received packet, as far as host A is
concerned.
(even sooner, if it's using randomized ID's or a bigger-than-1 increment).
Since it's the other side, which need not be Linux, I think
assumptions about how ID's are generated open the possibility of breaking
something that works now.
I think an estimator for the interarrival time of fragments for
the same packet, per destination, is what you really want here. The
problem is path changes can cause the timeout to change dramatically,
and you don't want something too short to cause you to drop packets
when there was no wrap. But if it's a conservative estimate, it beats
accidental corruption.
I can do DoS or intentional corruption if I can generate a
fragment as soon as I know the ID (by guessing, or by getting my
fragment in after I've seen the the first one sent), so I'm not
sure that can be fixed, except by using IPsec, if it concerns you. :-)
+-DLS
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Herbert Xu @ 2005-05-17 23:08 UTC (permalink / raw)
To: David S. Miller; +Cc: akepner, netdev
In-Reply-To: <20050517.151352.41634495.davem@davemloft.net>
On Tue, May 17, 2005 at 03:13:52PM -0700, David S. Miller wrote:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Wed, 18 May 2005 08:11:01 +1000
>
> > Instead of measuring the distance using time, let's measure it
> > in terms of packet counts. So every time we receive a fragmented
> > packet, we find all waiting fragments with the same src/dst pair.
> > If the id is identical we perform reassembly, if it isn't we increase
> > a counter in that fragment. If the counter exceeds a threshold,
> > we drop the fragment.
>
> And you protect against purposefully built malicious fragments how?
Is it any worse than what we've got now?
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Herbert Xu @ 2005-05-17 23:11 UTC (permalink / raw)
To: David Stevens; +Cc: rick.jones2, netdev
In-Reply-To: <OF16EC9302.031C4230-ON88257004.007BA491-88257004.007C8D46@us.ibm.com>
David Stevens <dlstevens@us.ibm.com> wrote:
>
> This assumes that you have a per-destination IP ID. If it's
> per-route,
> you can send 1 packet to host A, 65534 to host B through the same route,
> and
> 1 to host A-- wrap on the next received packet, as far as host A is
> concerned.
> (even sooner, if it's using randomized ID's or a bigger-than-1 increment).
Such systems would be violating the spirit of RFC791 which says:
The identification field is used to distinguish the fragments of one
datagram from those of another. The originating protocol module of
an internet datagram sets the identification field to a value that
must be unique for that source-destination pair and protocol for the
time the datagram will be active in the internet system.
Are you aware of any extant systems that do this?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: David S. Miller @ 2005-05-17 23:16 UTC (permalink / raw)
To: herbert; +Cc: akepner, netdev
In-Reply-To: <20050517230833.GA26604@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 18 May 2005 09:08:33 +1000
> On Tue, May 17, 2005 at 03:13:52PM -0700, David S. Miller wrote:
> > And you protect against purposefully built malicious fragments how?
>
> Is it any worse than what we've got now?
Good point, in both cases what ends up happening is that
the queue is invalidated. In the existing case it's usually
because the final UDP or whatever checksum doesn't pass.
With your idea it'd be due to the artificially deflated timeout.
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Arthur Kepner @ 2005-05-17 23:20 UTC (permalink / raw)
To: Herbert Xu; +Cc: dlstevens, rick.jones2, netdev
In-Reply-To: <E1DYBED-0006wa-00@gondolin.me.apana.org.au>
On Wed, 18 May 2005, Herbert Xu wrote:
> ....
> Such systems would be violating the spirit of RFC791 which says:
>
> The identification field is used to distinguish the fragments of one
> datagram from those of another. The originating protocol module of
> an internet datagram sets the identification field to a value that
> must be unique for that source-destination pair and protocol for the
> time the datagram will be active in the internet system.
>
> Are you aware of any extant systems that do this?
> ....
Are you aware of any (new) systems that _don't_ violate this? I
wouldn't want to own one of them!
--
Arthur
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Herbert Xu @ 2005-05-17 23:25 UTC (permalink / raw)
To: Arthur Kepner; +Cc: dlstevens, rick.jones2, netdev
In-Reply-To: <Pine.LNX.4.61.0505171612440.3335@linux.site>
On Tue, May 17, 2005 at 04:20:07PM -0700, Arthur Kepner wrote:
> On Wed, 18 May 2005, Herbert Xu wrote:
>
> > ....
> > Such systems would be violating the spirit of RFC791 which says:
> >
> > The identification field is used to distinguish the fragments of one
> > datagram from those of another. The originating protocol module of
> > an internet datagram sets the identification field to a value that
> > must be unique for that source-destination pair and protocol for the
> > time the datagram will be active in the internet system.
> >
> > Are you aware of any extant systems that do this?
> > ....
>
> Are you aware of any (new) systems that _don't_ violate this? I
> wouldn't want to own one of them!
Perhaps you misunderstood what I was saying. I meant are there any
extant systems that would transmit 1 set of fragments to host A with
id x, then 65535 packets host B, and then wrap around and send a new
set of fragments to host A with idx.
Linux will never do this thanks to inetpeer.c.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Herbert Xu @ 2005-05-17 23:28 UTC (permalink / raw)
To: David S. Miller; +Cc: akepner, netdev, Alexey Kuznetsov, Patrick McHardy
In-Reply-To: <20050517.161641.74747565.davem@davemloft.net>
On Tue, May 17, 2005 at 04:16:41PM -0700, David S. Miller wrote:
>
> Good point, in both cases what ends up happening is that
> the queue is invalidated. In the existing case it's usually
> because the final UDP or whatever checksum doesn't pass.
> With your idea it'd be due to the artificially deflated timeout.
It just occured to me that the optimisation in IPv4/IPv6 that performs
fragmentation after tunnel-mode IPsec is fundamentally broken. It
makes IPsec vulnerable to fragmentation attacks.
We have to perform fragmentation before tunnel-mode IPsec.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Patrick McHardy @ 2005-05-17 23:36 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, akepner, netdev, Alexey Kuznetsov
In-Reply-To: <20050517232828.GA26894@gondor.apana.org.au>
Herbert Xu wrote:
> On Tue, May 17, 2005 at 04:16:41PM -0700, David S. Miller wrote:
>
>>Good point, in both cases what ends up happening is that
>>the queue is invalidated. In the existing case it's usually
>>because the final UDP or whatever checksum doesn't pass.
>>With your idea it'd be due to the artificially deflated timeout.
>
>
> It just occured to me that the optimisation in IPv4/IPv6 that performs
> fragmentation after tunnel-mode IPsec is fundamentally broken. It
> makes IPsec vulnerable to fragmentation attacks.
You mean vulnerable at reassembly time? Isn't that something reassembly
and policy checks should take care of?
Regards
Patrick
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Herbert Xu @ 2005-05-17 23:41 UTC (permalink / raw)
To: Patrick McHardy; +Cc: David S. Miller, akepner, netdev, Alexey Kuznetsov
In-Reply-To: <428A800F.6040809@trash.net>
On Wed, May 18, 2005 at 01:36:47AM +0200, Patrick McHardy wrote:
>
> You mean vulnerable at reassembly time? Isn't that something reassembly
> and policy checks should take care of?
I mean that it's vulnerable to the following simple DoS attack by
someone who doesn't otherwise have the capability to drop the
packets between the source and the target.
If the IPsec packets arrive as fragments, the attacker only needs
to guess the identity to cause the entire IPsec packet to be dropped.
If it was fragmented prior to IPsec it would not be vulnerable to
this.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Rick Jones @ 2005-05-17 23:53 UTC (permalink / raw)
To: netdev
In-Reply-To: <OF16EC9302.031C4230-ON88257004.007BA491-88257004.007C8D46@us.ibm.com>
David Stevens wrote:
>
> This assumes that you have a per-destination IP ID. If it's per-route, you
> can send 1 packet to host A, 65534 to host B through the same route, and 1 to
> host A-- wrap on the next received packet, as far as host A is concerned.
> (even sooner, if it's using randomized ID's or a bigger-than-1 increment).
If we were actually looking at the ID's themselves, rather than the count of
datagrams received that would be correct, but someone already pointed-out that
ass-u-me-ing monotonic increasing was not a good thing, so simply count
datagrams completed/recevied on that source/dest pair instead. Then we don't
really care about the sender's IP ID assignment policy.
If someone wants to hit that with a DoS attack, I'm still wondering if that is a
large DoS hole, (larger than existing ones with spoofing fragments) and the
extent to which it depends on whether the attacker is closer to me than the
sender or "on the other side" of the sender from me.
rick jones
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: David Stevens @ 2005-05-17 23:55 UTC (permalink / raw)
To: Herbert Xu; +Cc: Arthur Kepner, netdev, rick.jones2
In-Reply-To: <20050517232556.GA26846@gondor.apana.org.au>
BSD systems, and derivatives, at least 20 years ago, had a single,
global IP ID for all destinations. The requirement was that at least
a single src-dest pair should be unique, which didn't prohibit all IP
ID's generated by the system from being unique. And BSD systems
generated an ID for every IP packet, not just frags, if memory serves.
IP ID wrap wasn't the concern, obviously, since those two pieces make
a wrap on any one destination more likely-- a wrap is for all packets
sent, not just on one interface or to one destination.
Some later systems use randomization of IP ID to make it harder to
inject data into fragments by guessing the ID, which means the entire
IP ID space isn't necessarily consumed before a "wrap" in the
pseudo-random sequence (thus, may happen even sooner than
a simple increment).
I don't know if any recent, common systems use a per-host global
IP ID, but yes, almost every host did 15-20 years ago
(and after RFC 791 :-) ).
+-DLS
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Herbert Xu @ 2005-05-18 0:00 UTC (permalink / raw)
To: David Stevens; +Cc: Arthur Kepner, netdev, rick.jones2
In-Reply-To: <OFAEDFE56B.04D1FB9A-ON88257004.008246B1-88257004.008369F9@us.ibm.com>
On Tue, May 17, 2005 at 04:55:20PM -0700, David Stevens wrote:
>
> I don't know if any recent, common systems use a per-host global
> IP ID, but yes, almost every host did 15-20 years ago
> (and after RFC 791 :-) ).
Unless these dinosaurs have evolved enough to support gigabit then
it's not a problem :)
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Andi Kleen @ 2005-05-18 0:04 UTC (permalink / raw)
To: Herbert Xu; +Cc: dlstevens, rick.jones2, netdev
In-Reply-To: <20050517232556.GA26846@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> writes:
>
> Perhaps you misunderstood what I was saying. I meant are there any
> extant systems that would transmit 1 set of fragments to host A with
> id x, then 65535 packets host B, and then wrap around and send a new
> set of fragments to host A with idx.
>
> Linux will never do this thanks to inetpeer.c.
It will, you just need enough other hosts to thrash inetpeer. How many
you need depends on your available memory.
-Andi
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Nivedita Singhvi @ 2005-05-18 0:06 UTC (permalink / raw)
To: Herbert Xu; +Cc: Arthur Kepner, dlstevens, rick.jones2, netdev
In-Reply-To: <20050517232556.GA26846@gondor.apana.org.au>
Herbert Xu wrote:
>>>Such systems would be violating the spirit of RFC791 which says:
>>>
>>> The identification field is used to distinguish the fragments of one
>>> datagram from those of another. The originating protocol module of
>>> an internet datagram sets the identification field to a value that
>>> must be unique for that source-destination pair and protocol for the
>>> time the datagram will be active in the internet system.
>>>
>>>Are you aware of any extant systems that do this?
>>>....
>>
>>Are you aware of any (new) systems that _don't_ violate this? I
>>wouldn't want to own one of them!
>
>
> Perhaps you misunderstood what I was saying. I meant are there any
> extant systems that would transmit 1 set of fragments to host A with
> id x, then 65535 packets host B, and then wrap around and send a new
> set of fragments to host A with idx.
>
> Linux will never do this thanks to inetpeer.c.
Actually, it depends on which Linux you are using.
Mainline linux certainly has this (per-inetpeer ip_id) - but
at least one distro did not (use inetpeer) :). Not sure
what the current situation is.
Of course, if all the traffic is on the same connection
(which isn't out of the ordinary) would still come down
to the same thing...
thanks,
Nivedita
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Herbert Xu @ 2005-05-18 0:09 UTC (permalink / raw)
To: Andi Kleen; +Cc: dlstevens, rick.jones2, netdev
In-Reply-To: <m11x85762p.fsf@muc.de>
On Wed, May 18, 2005 at 02:04:14AM +0200, Andi Kleen wrote:
> Herbert Xu <herbert@gondor.apana.org.au> writes:
> >
> > Perhaps you misunderstood what I was saying. I meant are there any
> > extant systems that would transmit 1 set of fragments to host A with
> > id x, then 65535 packets host B, and then wrap around and send a new
> > set of fragments to host A with idx.
> >
> > Linux will never do this thanks to inetpeer.c.
>
> It will, you just need enough other hosts to thrash inetpeer. How many
> you need depends on your available memory.
Even when the cache entry is deleted, Linux will allocate an ID randomly
so the chance of what was stated above occuring is very small.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Herbert Xu @ 2005-05-18 0:10 UTC (permalink / raw)
To: Nivedita Singhvi; +Cc: Arthur Kepner, dlstevens, rick.jones2, netdev
In-Reply-To: <428A871F.1000308@us.ibm.com>
On Tue, May 17, 2005 at 05:06:55PM -0700, Nivedita Singhvi wrote:
>
> Mainline linux certainly has this (per-inetpeer ip_id) - but
> at least one distro did not (use inetpeer) :). Not sure
> what the current situation is.
What was the reason for this? Perhaps we can solve their problems
with inetpeer in a better way than disabling it?
> Of course, if all the traffic is on the same connection
> (which isn't out of the ordinary) would still come down
> to the same thing...
Please see my proposal elsewhere in this thread.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Thomas Graf @ 2005-05-18 0:47 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, akepner, netdev
In-Reply-To: <E1DYAHF-0006qW-00@gondolin.me.apana.org.au>
* Herbert Xu <E1DYAHF-0006qW-00@gondolin.me.apana.org.au> 2005-05-18 08:11
> Instead of measuring the distance using time, let's measure it
> in terms of packet counts. So every time we receive a fragmented
> packet, we find all waiting fragments with the same src/dst pair.
> If the id is identical we perform reassembly, if it isn't we increase
> a counter in that fragment. If the counter exceeds a threshold,
> we drop the fragment.
I like this, although the problem is derived to the definition
of the threshold. Any ideas on how to define this? A
combination of your idea together with the idea I stated in
another post which would additional expire fragments earlier
depending on the actual packet (or fragment) rate might give
better results.
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: David S. Miller @ 2005-05-18 0:51 UTC (permalink / raw)
To: herbert; +Cc: niv, akepner, dlstevens, rick.jones2, netdev
In-Reply-To: <20050518001054.GB27212@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly
Date: Wed, 18 May 2005 10:10:54 +1000
> On Tue, May 17, 2005 at 05:06:55PM -0700, Nivedita Singhvi wrote:
> >
> > Mainline linux certainly has this (per-inetpeer ip_id) - but
> > at least one distro did not (use inetpeer) :). Not sure
> > what the current situation is.
>
> What was the reason for this? Perhaps we can solve their problems
> with inetpeer in a better way than disabling it?
Andi Kleen thought inetpeer was a pig, so he removed it from SUSE's
kernel and replaced it with a per-cpu salted IP ID generator. The
initial verion he wrote had serious bugs that severely decreased the
effective ID space, and thus made the NFS corruption problem happen
more frequently.
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: David S. Miller @ 2005-05-18 0:52 UTC (permalink / raw)
To: herbert; +Cc: ak, dlstevens, rick.jones2, netdev
In-Reply-To: <20050518000955.GA27212@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly
Date: Wed, 18 May 2005 10:09:55 +1000
> On Wed, May 18, 2005 at 02:04:14AM +0200, Andi Kleen wrote:
> > Herbert Xu <herbert@gondor.apana.org.au> writes:
> > It will, you just need enough other hosts to thrash inetpeer. How many
> > you need depends on your available memory.
>
> Even when the cache entry is deleted, Linux will allocate an ID randomly
> so the chance of what was stated above occuring is very small.
Yes, that's right. Andi just doesn't like inetpeer, so let's just
move along and accept that. :-)
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Andi Kleen @ 2005-05-18 1:05 UTC (permalink / raw)
To: David S. Miller; +Cc: niv, akepner, dlstevens, rick.jones2, netdev
In-Reply-To: <20050517.175126.74751342.davem@davemloft.net>
"David S. Miller" <davem@davemloft.net> writes:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Subject: Re: [RFC/PATCH] "strict" ipv4 reassembly
> Date: Wed, 18 May 2005 10:10:54 +1000
>
>> On Tue, May 17, 2005 at 05:06:55PM -0700, Nivedita Singhvi wrote:
>> >
>> > Mainline linux certainly has this (per-inetpeer ip_id) - but
>> > at least one distro did not (use inetpeer) :). Not sure
>> > what the current situation is.
>>
>> What was the reason for this? Perhaps we can solve their problems
>> with inetpeer in a better way than disabling it?
>
> Andi Kleen thought inetpeer was a pig, so he removed it from SUSE's
> kernel and replaced it with a per-cpu salted IP ID generator. The
> initial verion he wrote had serious bugs that severely decreased the
> effective ID space, and thus made the NFS corruption problem happen
> more frequently.
That's not true, there were no bugs it in. Or at least none
I know about.
However any randomized IPID scheme decreases the effective IP-ID
space slightly. The only algorithm that uses a bit space perfectly
is a counter :) However I admit the constant to regulate the grainness
was a bit too aggressive at the beginning, which indeed triggered
the NFS corruption problem more frequently. However since the 16bit
space is more or less useless (as Artur demonstrated it cannot
even handle a single Gigabit link) it did not make that much difference anyways.
The eventual workaround for the NFS IP-ID problem that went into
the vendor kernel also did work in a different way on top
of the algorithm.
As for the background (not for you Dave, for other readers ;-) why I
consider inetpeer useless please read the archives. As a hint just
look what kind of functionality it implements and how much of it is
actually enabled by default and think of its relationship to masquerading
(which BTW breaks most of the fancy algorithms proposed so far)
-Andi
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox