Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Theo de Raadt
> > 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

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Kenneth Gober
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

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Alexander Bluhm
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

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Alexander Bluhm
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

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Theo de Raadt
> 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

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Alexander Bluhm
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

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Simon Perreault
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

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Fernando Gont
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

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Alexander Bluhm
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

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Fernando Gont
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

Re: overlapping IPv6 fragments in pf

2012-01-13 Thread Fernando Gont
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

Re: overlapping IPv6 fragments in pf

2012-01-12 Thread Alexander Bluhm
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

Re: overlapping IPv6 fragments in pf

2012-01-12 Thread Kenneth Gober
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

Re: overlapping IPv6 fragments in pf

2012-01-12 Thread Fernando Gont
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

overlapping IPv6 fragments in pf

2012-01-11 Thread Alexander Bluhm
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