> On Jul 28, 2014, at 11:49 PM, "Eggert, Lars" <[email protected]> wrote: > > Hi, > >> On 2014-7-28, at 17:45, Joe Touch <[email protected]> wrote: >>> On 7/28/2014 6:52 AM, Eggert, Lars wrote: >>> Protecting the RST is therefore probably impossible. >> >> I disagree. There are at least two viable approaches: >> >> 1) require TCP keepalive and block unprotected RSTs >> this is TCP-AO's approach > > True. But you'd need to send keep-alives pretty frequently to see a benefit > (= detect that the connection is gone faster than you'd do with just a > regular timeout.)
Tcp won't timeout if there is no data to send or ack. Keepalives give timeout behavior when the connection is otherwise idle. > >> 2) block unprotected RSTs *unless* the connection is active >> i.e., any correct TCP packet resets a short timer, >> so that the connection allows RSTs only when the >> timer expires > > I read this a few times but remain confused. Did you maybe mean "allow > unprotected RTSs unless the connection is active?" (Because as written, it > seems backwards?) Yup. Joe > Lars > >> >> FWIW, that timer can be a few seconds - i.e., the time it would take for a >> reboot. >> >> #1 requires idle connections to be active and blocks all unprotected RSTs, >> but cuts a connection (and cleans up state) whenever a connection goes >> completely cold >> >> #2 allows connections to go cold, but makes them susceptible to middlebox >> RSTs during that time >> >> I think #1 makes more sense for things like BGP and #2 is more useful in the >> common case, but an implementation can easily allow #2 as the default and #1 >> to be a configuration option. >> >> Joe > _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
