[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pf reassemble tcp problem in latest snapshot?
>From what I can tell, the problem isn't with OSX. At least, not
10.3.5 anyway, as all my tcp packets have timestamps in them. Looks
like swscan.apple.com (which is the site in question at IP
17.250.248.95) is running a NetApp NetCache. Or maybe there's a load
balancer in front of it that behaves differently than other balancers.
In any case, the problem appears to be the RFCs. Maybe a TCP stack
was implemented based on RFC 1072. Maybe someone implemented RTTM and
not PAWS. Whatever the case, it's not clear to me personally that
it's a bug, nor is it clear to me how many companies' doors I'd have
to beat down to fix the problem, or how much hardware/how many sites
out there have the problem.
It seems that the biggest problem is this: how do you know a TCP stack
that is using timestamps has implemented PAWS, and not just RTTM.
Barring issues of being able to determine the scenario, it doesn't
make sense to allow communications with TCP stacks that don't
implement timestamps at all, but disallow communications with stacks
that implement RTTM and not PAWS.
The issue of being able to determine the case where a stack uses RTTM
and not PAWS is a little dicey, which I suppose is the only reason
we're having this conversation.
On that note, here's a possible solution:
1. Assume a TCP session using timestamps implements both RTTM and
PAWS, in other words keep the same current pf behavior including
dropping packets with invalid timestamps. pf would determine this I
assume the same way it does now, by the 3 way handshake.
2. Initially, allow packets with no timestamps after the 3whs.
3. Keep a counter per session, initialized to 8, for example (no
needto keep track of per direction information, as far as I can see).
4. Increment the counter when you see a packet with everything valid
except the fact that it has no timestamp. Allow the packet to pass.
5. Decrement the counter when you see a packet that has no timestamp
that *also* has some other problem with it (not being within the tcp
window, for instance). Enough information in the packet would have to
be correct for it to match up to the tcp state in question, of course.
6. If the counter reaches 0, for example, enable strict enforcement of
PAWS for the session and unconditionally drop packets with no
timestamps.
7. If the counter reaches 15, for example, disable PAWS enforcement
permanently for the session.
8. After either #6 or #7 occurs, don't do #4 or #5 anymore, no need.
I realize the above might seem like a bit of a hack, but RFC 1323
doesn't appear to be designed for security. It appears to be designed
to protect against legitimate problems like excess latency or high
bandwidth. I see its potential to add security to TCP sessions as
most people on this list certainly do, but it's definitely a hack in
general, although a damn good one.
Thoughts? I'm willing to mock Apple, but only under the condition
that I understand what's going on fully. With my current
understanding, I'd be on questionable ground. That, and as far as I
can see, the above solution would solve the problem.
On Sat, 11 Sep 2004 18:59:08 -0600, Theo de Raadt
<deraadt@cvs.openbsd.org> wrote:
> And go yell at Apple. Go mock them somewhere public.
>
> > > Hmm. Is apple's software update site breaking some RFC? Bug in pf?
> > > very weird.
> >
> > It's a slippery slope. RFC1323 doesn't specifically require including a
> > TCP timestamp on all data packets. But it is implicitly required for
> > PAWS to make any sense at all. In the high speed TCP world, Apple is
> > doing the equivalent of not checking sequence numbers.
> >
> > We have a workaround in PF for load balancers that timestamp on the 3whs
> > but then strip timestamps off all further packets. I don't see a direct
> > workaround for this in the code.
> >
> > If it affects all MacOS systems, you can try replacing your scrub rule
> > with these two:
> > scrub on fxp0 from os MacOS no-df random-id
> > scrub on fxp0 all no-df random-id reassemble tcp
> >
> > Or possibly use the FreeBSD fingerprint (iirc MacOS X uses the FreeBSD
> > 4.x TCP stack)
> >
> > .mike