Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]

[hat off]

I am not sure where in this thread to weigh in, so I am just replying to
the last thing in my inbox.

I think a couple of things:

  + I disagree with everyone who says this problem of a bunch of clients
    wedging connections on a server into ZWP in the attempt to consume
    a large number of resources can be mitigated effectively at the
    application layer.  Perhaps if a server has one application process
    (or a bunch of tightly coupled processes under one app controller)
    then this could be handled.  But, fundamentally a set of
    applications cannot be expected to have the cross-connection and
    cross-application viewpoint that TCP or the operating system has.
    Therefore, applications cannot solve such a problem.

  + I disagree with the reading of RFCs 793 & 1122 that a connection
    that is doing zero window probing must remain up forever as long as
    the probes are being ACKed.  I think in 'times of trouble' a TCP is
    well within its rights to terminate a connection and I do not think
    that should in any way be viewed as non-compliant.  TCP connections
    are local resources and therefore should remain under local
    control.  If something locally determines that resources are low and
    connection should be terminated for whatever reason then I don't see
    how that is any of anyone else's business.

    That doesn't mean I think the words in 1122 are wrong.  That means I
    think that if folks would call a stack that has run out of memory
    (or, hits some threshold, say) and therefore kills some connections
    that are doing ZWP "non-conformant" then they are simply wrong and
    applying too much protocol lawyering and too little common sense.

    Hence, I don't think the standards need changed in any way.

  + I believe that managing local resources according to local policy is
    reasonable.  Therefore, I don't think we need to standardize *a* way
    to mitigate the attack described in this document.  I think stacks
    can be free to mitigate it (or not) as they see fit.

  + I would not have a problem with a crisp and clean document that
    showed *a* solution to the problem.  Especially good would be a
    demonstration that the problem is a problem in the wild and has not
    been mitigated.  [See my previous---unanswered as far as I can
    tell---note on why I think the tests in the draft are inconclusive
    at best.]  This document could be a technical report or a short
    workshop paper or an informational RFC.

    (As an example, see the SYN-flood RFC.  This describes a fully local
    solution to a problem in an informational way.  There is no strict
    reason to standardize anything in that document, but it is crisp,
    clean and complete and the WG found it something nice to have
    documented.  This persist document is a far cry from the SYN flood
    document at the moment, but I suppose one could envision that a
    document that covers purging connections when resource constrained
    could be developed.)

allman