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

[Mark Allman <[e-mail]>]

Joe-

You and I are just going to disagree.

> That OS is required to reserve per-connection resources when
> connections are created. It can halt new connections.

If this is the general reading of the spec then TCP has a built-in DoS
vulnerability that we need to fix.

> It *CANNOT* kill existing connections to make up for poor resource
> management and call itself compliant with the current language in
> 1122.

I disagree.

> >     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.
> 
> The lack of common sense came when the OS designer failed to allocate
> sufficient per-connection resources. Throw your stones in their
> direction, please.

Huh?  The lack of allocation of sufficient per-connection resources?
What?  The problem here is that the OS *did* allocate resources and with
a low-rate handshake those resources can be tied up indefinitely.  I
have no idea how the OS "failed to allocate sufficient per-connection
resources".

If a TCP were omniscient and could know the workload to be imposed on it
arbitrarily far into the future then perhaps it could wisely allocate
resources to avoid this problem.  But, since that is impossible then a
host can get into resource contention problems and in that case it
should have the flexibility to mitigate these problems.

It is absurd to me that a TCP (or any protocol) would allow a peer to
indefinitely tie up a local resource without being subject to local
policies on that resource.  I cannot imagine that such a notion falls
within the spirit of 793 & 1122.  If we have wide-spread agreement that
your interpretation is right then I support a one-page standards-track
RFC that says it is not.

allman

_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm