When you have a lot of users, attempting to cache for them server-side is
not really possible, and opens the site up to some interesting DoS vectors.
There are easier ways to attack servers and clients (e.g. use DNS to
perform various attacks, simply send a SYN flood, etc.) than messing with
this, but it should always only be advisory.
The interesting thing about the client mucking with this data is that, so
long as the server's TCP implementation is smart enough not to kill itself
(and some simple limits accomplish that), the only on the client harms is
itself...
-=R
On Mon, Apr 15, 2013 at 3:26 PM, Eggert, Lars <lars@netapp.com> wrote:
> Hi,
>
> On Apr 15, 2013, at 15:15, Roberto Peon <grmocg@gmail.com> wrote:
> > If it was defined as an opaque blob that the transport layer delegates to
> > the application layer to transmit and cache, would it seem as scary?
> ...
> > I think you mistake the intent. The intent is to make it easy for
> transport
> > experimentation by giving a mechanism that can be implemented today of
> > storing transport-related data, and by giving that back to the transport
> > layer upon session resumption.
>
> why does the app need to be involved here at all? It TCP wants to cache
> state from one connection instance to the next, it can (and does, in some
> cases) already do so.
>
> Yeah, for HTTP, you might want the HTTP client to hold that state instead
> of the HTTP server as an optimization, so you need to get it in and out of
> the server kernel. But is that really of general usefulness? There seem to
> be some significant security challenges here, such as whether a server
> would even trust this opaque information, given that the client could have
> messed with it. (Blindly using this state could have detrimental effects on
> other connections the server has open.)
>
> Lars