lkml.org 
[lkml]   [2008]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/3] Support arbitrary initial TCP timestamps
    > > Adding yet another member to the already bloated tcp_sock structure to
    > > implement this is too high a cost.
    >
    > Yes, I was worried that would be deemed too high of a cost, but it was
    > the most efficient way I could think to accomplish what I wanted.
    >
    > > I would instead prefer that there be some global random number
    > > calculated when the first TCP socket is created, and use that as a
    > > global offset. You can even recompute it every few hours if you
    > > like.
    >
    > That would work fine if my mine purpose was to randomize the tcp
    > timestamp to mitigate the leak in information regarding uptime, but
    > despite the brief description, that's only a side effect of what I
    > intended to do. What I wanted was a way to be able to choose an initial
    > tcp timestamp for a particular connection that was not tied directly to
    > jiffies.
    >
    > The two patches following this show my intended use case. I intend to
    > enhance syncookie support to allow it to support advanced tcp options
    > (sack and window scaling). Normally syncookies encode the bare minimum
    > state of a connection in the ISN they choose, but the 32bit ISN isn't
    > enough to encode advanced tcp options so you are left with a working but
    > crippled tcp stack during a synflood attack. If in addition to choosing
    > an ISN we are able to choose an initial tcp timestamp, we are then able
    > to encode an additional 32 bits of information that can contain more of
    > the advanced tcp options.

    Perhaps I should clarify. I don't see a way to implement the additional
    syncookie enhancements without storing an offset in some type of
    per-socket structure. Given that, is it still deemed too high of a cost?
    Is enhancing syncookies not deemed important enough to warrant the
    additional 4 bytes? What if there was an additional config variable to
    support arbitrary/random tcp timestamps, and then syncookies only used
    the additional options when that setting was chosen? Is there some
    possiblity I'm missing that could get this feature in a form suitable
    for inclusion? Thanks.

    --Glenn



    \
     
     \ /
      Last update: 2008-02-19 18:57    [W:0.041 / U:5.088 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site