[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070702.221454.18562227.davem@davemloft.net>
Date: Mon, 02 Jul 2007 22:14:54 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: ilpo.jarvinen@...sinki.fi
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH] [TCP]: Fix logic breakage due to DSACK separation
From: "Ilpo_Järvinen" <ilpo.jarvinen@...sinki.fi>
Date: Sat, 16 Jun 2007 02:04:25 +0300 (EEST)
> There are still some things I must think carefully in sacktag processing
> since it does not validate start_seq and end_seq at all which can be
> abused currently at least in tcp-2.6. ...I would rather put end to the
> whole russian roulette in tcp-2.6 sacktag rather than fix/think individual
> cases and leave future modifications of it similarily hazardous. It's not
> very clear to me how to handle all possible cases of invalid SACK blocks
> though, perhaps TCP should just ignore such sack blocks without doing
> any processing based on them, i.e., ignore them whenever start_seq-end_seq
> does not fully fit to snd_una-snd_nxt (expect DSACK of course, which
> should be processed if it's between undo_marker-snd_nxt). Do you have any
> thoughts about this?
I agree. This is a problem that basically every single TCP stack out
there right now is vulnerable to, lots of cpu processing for invalid
or maliciously created SACK blocks. This is why I even considered the
RB-Tree stuff at all.
Therefore the earlier we toss out bad SACK blocks the better, and thus
I agree with a scheme that does validation at the earliest stage
possible as you seem to be suggesting.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists