> > From remote I could build a bot-net of machines that send you
> > illegal fragments and, if you create a state of the bad mappings, you'd
> > run your state table out. When the state table gets full, it will
> > eject other stuff which is more important. Like ssh sessions and such.
> >
> > We
On Fri, Jan 13, 2012 at 1:44 PM, Theo de Raadt wrote:
> From remote I could build a bot-net of machines that send you
> illegal fragments and, if you create a state of the bad mappings, you'd
> run your state table out. When the state table gets full, it will
> eject other stuff which is more imp
On Fri, Jan 13, 2012 at 11:44:20AM -0700, Theo de Raadt wrote:
> > I have to drop them all, "including those not yet received".
>
> That last bit is crazy. You cannot maintain state until the potential
> packets fall out of the fragment cache.
This is also true for the reassembly implementation
On Fri, Jan 13, 2012 at 11:44:20AM -0700, Theo de Raadt wrote:
> > I have to drop them all, "including those not yet received".
>
> That last bit is crazy. You cannot maintain state until the potential
> packets fall out of the fragment cache.
After discussion with deraadt@ it came clear that dr
> On Fri, Jan 13, 2012 at 02:13:09PM -0300, Fernando Gont wrote:
> > If there was a fragment overlap, there was malicious activity, and
> > you're certainly not going to get any legitimate fragment reassembled.
> > Therefore, IMO, it doesn't make sense to tie resources (i.e., keep
> > state) for th
On Fri, Jan 13, 2012 at 02:13:09PM -0300, Fernando Gont wrote:
> If there was a fragment overlap, there was malicious activity, and
> you're certainly not going to get any legitimate fragment reassembled.
> Therefore, IMO, it doesn't make sense to tie resources (i.e., keep
> state) for that.
>
> I
On 2012-01-13 12:13, Fernando Gont wrote:
If you do not keep state, then.
1) If you don't get any further fragments, you saved memory and other
resources, or,
2) If you do get other fragments, they'll be queued, and since other
fragments were dropped, there won't be any reassembled datagram, and
On 01/13/2012 12:11 PM, Alexander Bluhm wrote:
> On Fri, Jan 13, 2012 at 11:01:43AM -0300, Fernando Gont wrote:
>> On 01/12/2012 04:04 PM, Alexander Bluhm wrote:
>>> I have reconsidered it and drop the fragments immediately. The
>>> packet to be reassembled will be dropped after timeout.
>>
>> S
On Fri, Jan 13, 2012 at 11:01:43AM -0300, Fernando Gont wrote:
> On 01/12/2012 04:04 PM, Alexander Bluhm wrote:
> > I have reconsidered it and drop the fragments immediately. The
> > packet to be reassembled will be dropped after timeout.
>
> Sorry: immediately, or after a timeout?
We have a l
On 01/12/2012 02:45 PM, Kenneth Gober wrote:
> I'd argue that you should drop all the "constituent fragments" as soon
> as you receive them.
>
> Since there's no legitimate reason of overlapping fragments, get rid of
> them asap. And if there were more fragments (for the same packe
Hi, Alexander,
On 01/12/2012 04:04 PM, Alexander Bluhm wrote:
> I have reconsidered it and drop the fragments immediately. The
> packet to be reassembled will be dropped after timeout.
Sorry: immediately, or after a timeout?
Now pf
> works like our IPv6 stack.
>
> - Sort pf_fragment fields
On Thu, Jan 12, 2012 at 05:31:00AM -0300, Fernando Gont wrote:
> I'd argue that you should drop all the "constituent fragments" as soon
> as you receive them.
>
> Since there's no legitimate reason of overlapping fragments, get rid of
> them asap. And if there were more fragments (for the same pac
On Thu, Jan 12, 2012 at 3:31 AM, Fernando Gont wrote:
> On 01/12/2012 12:03 AM, Alexander Bluhm wrote:
> > Drop overlapping IPv6 fragments in pf reassembly code. RFC 5722
> > is demanding that. Our stack does that already.
> >
> > The text "constituent fr
On 01/12/2012 12:03 AM, Alexander Bluhm wrote:
> Drop overlapping IPv6 fragments in pf reassembly code. RFC 5722
> is demanding that. Our stack does that already.
>
> The text "constituent fragments, including those not yet received,
> MUST be discarded" does not make c
Hi,
Drop overlapping IPv6 fragments in pf reassembly code. RFC 5722
is demanding that. Our stack does that already.
The text "constituent fragments, including those not yet received,
MUST be discarded" does not make clear, how long to do that. The
easiest way for pf is to wait
15 matches
Mail list logo
