Re: [tcpm] 793bis: TCP Quiet Time

[Matt Mathis <[e-mail]>]

What Joe said s/effect/opportunities/

Is there standards language anywhere about successive connections sharing
sequence space and timestamps?  If there is, I missed it.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
       however our response must be carefully measured:
            too strong would be hypocritical and risks spiraling out of
control;
            too weak risks being mistaken for tacit approval.


On Thu, Dec 19, 2019 at 6:57 AM Joe Touch <[e-mail]> wrote:

> This discussion seems to be overlooking the effect of timestamps.
>
> Joe
>
> On Dec 18, 2019, at 9:39 PM, Matt Mathis <
> mattmathis=[e-mail]> wrote:
>
> I am under the impression that web servers do something different:
> Normally the client sends the FIN, and the server holds FIN wait, but often
> discards it before 2MSL to reduce memory pressure, however if the server
> receives a new SYN for the same connection 4tuple (before it is discarded),
> the server has the option to continue in the same sequence space, one byte
> after the FIN.
>
> I haven't looked, but what happens if a connection is in FIN wait, and a
> new SYN arrives?
>
> Thanks,
> --MM--
> The best way to predict the future is to create it.  - Alan Kay
>
> We must not tolerate intolerance;
>        however our response must be carefully measured:
>             too strong would be hypocritical and risks spiraling out of
> control;
>             too weak risks being mistaken for tacit approval.
>
>
> On Wed, Dec 18, 2019 at 8:16 PM Neal Cardwell <ncardwell=
> [e-mail]> wrote:
>
>> On Wed, Dec 18, 2019 at 8:28 PM Yuchung Cheng
>> <ycheng=[e-mail]> wrote:
>> >
>> > On Wed, Dec 18, 2019 at 1:33 PM Wesley Eddy <[e-mail]>
>> wrote:
>> > >
>> > > I don't think I noticed anyone responding to Gorry's comment below,
>> and
>> > > I haven't made any alterations in the 793bis draft with regard to this
>> > > (other than fixing some spelling mistakes).  I wanted to pull this
>> into
>> > > its own thread in case other people have thoughts or would like to
>> > > discuss further what the quiet time concept's relevance is in 2020.
>> > I probably am missing something. What's the issue of the text? Linux
>> > to my knowledge does
>> > not implement this quiet time.
>> > But there are other injection attacks or basic checksum issues etc to
>> > corrupt TCP. (Serious) application that solely relying on TCP's
>> > integrity is signing up for troubles already ...
>>
>> I would agree with Yuchung's remarks and the general point that the
>> "TCP Quiet Time Concept" from RFC 793 does not seem to be of practical
>> importance today, from a number of perspectives:
>>
>> o I'm not aware of any major TCP implementation that actually follows
>> the "TCP Quiet Time" approach.
>>
>> o Most production applications AFAIK end up using SO_REUSEADDR,
>> indicating a need to reuse ports quickly and a lack of concern about
>> this kind of issue with old packets ending up mixed into new
>> connections.
>>
>> o Applications that care about this should be using cryptography.
>>
>> o Users today expect to be able to reboot a machine and get back on
>> the network in less than 2 minutes.
>>
>> best,
>> neal
>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
>