Re: Regarding summer of code 2008(writing device drivers)

["Steven M. Bellovin" <smb%cs.columbia.edu@localhost>]

On Fri, 28 Mar 2008 18:47:29 -0400 (EDT)
der Mouse <mouse%Rodents.Montreal.QC.CA@localhost> wrote:

> >> Also, the technique seems susceptible to data injection.  What do
> >> you think?
> > I don't see why there's any more chance of it with this scheme than
> > with normal TCP.
> 
> Sleeper injections, perhaps?  With normal TCP, if you inject a packet,
> it has to be in-window, or it's dropped.  With this, you can inject a
> packet and have it sit in a cache for a more or less unlimited time
> and then have it crawl out and damage the data stream.  (Nontrivial,
> but I'd be very reluctant to declare it impossible.  A lot of traffic
> is a lot more predictable in practice than it's promised to be by
> theory.)

I still don't see the attack.  The packet can only get into the cache
if it's in-window for some stream, plus it passes the TCP checksum.
(Aside: we never want to cache UDP packets without checksum.  In fact,
we never want to send them, but that's a separate rant.)  That means
that a once-valid packet has to be corrupted on the local machine while
sitting in kernel RAM.  Doing that requires root access, but someone
with that access has many easier paths to corrupting an application or
its data.

I'm more worried about accidental contamination, hence my suggestion
about the TCP checksum.
> 
> > First, how much data can be cached in RAM on the receiving machine?
> 
> Quite a lot, if it wants to.  I'm regularly seeing machines these days
> with more RAM than some of my machines have _disk_.
> 
Sure, but how much network traffic do they have?  Is that the best
performance improvement per dollar/euro/yen/zorkmid spent, compared
with using that RAM for file system buffers or executables, especially
when you take the probability of reuse into account.  (Hmm -- for NFS,
it might be a very promising idea...)

                --Steve Bellovin, http://www.cs.columbia.edu/~smb