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

[Joe Touch <[e-mail]>]

I think it would be very useful to highlight the problem and provide
information on how to solve it at the application layer in an
informational RFC. I'd suggest it'd be useful to include very specific
examples, e.g., with socket options, to show a potential mechanism. I
also think the doc should include a discussion of making slow progress
as related to this issue, and potentially a similar DOS opportunity.

I don't think the doc should change 1122's text; IMO, TCP isn't the one
who ought to make this decision, thus TCP ought to hang out as long as
the application lets it.

I don't think the doc should mention whether the timer should be
embedded in TCP as an implementation decision. IMO, that crosses into a
TCP mod, and since it isn't absolutely necessary, I don't see a reason
to do so there. I do think it would be more useful to give the example
of putting this in the kernel as a shared mechanism, with discussion to
motivate it.

Finally, if this is an informational RFC and the solution is soley at
the app layer, it ought to be taken to TSVWG, rather than in TCPM. I
don't consider this a downgrading, but rather to gain a wider audience
for a very real issue.

Joe

Anantha Ramaiah (ananth) wrote:
> I managed to read all the responses so far on this thread. At the time
> of writing this email, there have been 54 email exchanges (includes the
> authors' responses) around 9 people have responded so far not counting
> the private email exchanges. In order to prevent rat-holing this further
> I would like to step back a little and pose the following questions :-
> 
> A) Do we agree that it is a problem ? [the title of the thread]
> 
>    Most people seem to agree on this.
> 
> B) Do we think this is an issue to be dealt at the transport layer?
> 
>    Here there seems to be mixed reaction. Granted that there may be many
> people feeling that this is an application issue and not a transport
> issue.
> 
> Now expanding on B), 
> 
> Now the draft is talking about 2 things actually 3 things.
> 
> 1) It is asking to correct/clarify the verbiage of RFC 1122. ie., RFC
> 1122 tells the connections MUST persist forever as long as ACK's are
> received. Now, clearly as demonstrated in the draft, there needs to be
> some ammount of robustness that can be built into the TCP layer, which
> can allow the connection to be aborted after some stipulated time. Is
> this considered a change in the standards? 
> 
> 2) The draft also outlines a solution that can be helpful to deal when a
> particular host is compromised with malicious intent. Agreed this may
> not be the only solution possible, but it is one such. This purely falls
> into "INFORMATIONAL" category. There is no TCP protocol change, it is
> upto the implementation to chose an algorithm of choice. I think the
> majority of the objection so far seems to be w.r.t point : "why TCP
> layer should be responsible for resource allocation shemes"?  Again, I
> think this is merely a suggestion and some implementations can chose to
> implement it that way, there is no need to standardize this.
> 
> 3) It also DOES mention about the application's role. Ie., in particular
> it suggests the following :- 
>    "Applications can assist TCP's role in solving this problem.  They
> can
>    register for an event notification when the TCP connection enters or
>    exits persist condition.  They can use the notification mechanism to
>    implement their own scheme of deciding which persist connections to
>    clear.  They can also suggest timeout or retry values to TCP."
> 
> This only proves that the draft indeed does mention about application's
> role in assisiting the problem. Again the above purely falls into
> "informational" category.
> 
> So, in summary : Clearly 1) above calls for some change in existing TCP
> behaviour. So even though it is not strictly "on the wire" change ( like
> someone was pointing out) it is a change to the TCP standards. Now, why
> can't TCP be made robust which would help to address situations like
> this documented in the draft?  Is there a resistance to change the RFC
> 1122 verbiage even though it is helpful to do so? It is matter a
> providing a new timer in TCP ( I think Ted menioned it in one his
> emails)
> 
> 2) and 3)  doesn't need any change to the standards. They illustrate the
> problem and provide solutions and suggestions.
> 
> Given that there seems to be an agreement that this is a problem, the
> way I look at is 1) above calls for a change in the standards. 2) and 3)
> are more informational purpose only.
> 
> FWIW, the current "intended status" of the draft stands as
> informational. 
> 
> Thoughts/comments? Esp. there seems to to be some scope on re-wording
> some sections of the draft to make the case more explicit, if that
> helps?
> 
> -Anantha
> 
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tcpm

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