[tcpm] [Fwd: Some feedback for draft-ananth-tcpm-persist-02.txt]

[Fernando Gont <[e-mail]>]

Folks,

A while ago I had sent some feedback to the authors of the tcpm-persist
I-D. I'm forwarding my comments to the wg.


-------- Original Message --------
Subject: Some feedback for draft-ananth-tcpm-persist-02.txt
Date: Sun, 10 Jan 2010 15:11:03 -0300
From: Fernando Gont <[e-mail]>
To: Murali Bashyam <[e-mail]>,  "Mahesh Jethanandani
(mahesh)" <[e-mail]>, "Anantha Ramaiah (ananth)" <[e-mail]>

Folks,

See some quoted portions of your I-D, and my comments inline....


>    This is important
>    because typically applications would want the TCP connection to stay
>    open unless it explicitly closes the connection.  For example take
>    the case of user running a print job and the printer ran out of paper
>    waiting for the user intervention.  It would be premature for TCP to
>    take action on its own.  Hence TCP cannot act as a resource manager
>    and it is the system or application's responsibility to take
>    appropriate action.

This is not necessarily the case. e.g., in the case of orphaned
connections, it's *TCP*'s responsibility (or, well, the OS) to take
appropriate action.


> 
>    At the same time, many existing TCP implementations that adhere
>    strictly to the above verbiage of RFC 1122, may fall victim to DOS
>    attacks, if appropriate measures are not followed.

Nit: s/DOS/DoS/ (an in other places as well)



>    Applications on the sender can transfer all the data to the TCP
>    socket and subsequently close the socket leaving the connection in
>    orphaned state.  

You should probably clarify this term ("orphaned"). e.g., "connections
with no controlling process"....



>    CERT is putting a advisory in this regard[VU723308] and is making
>    vendors aware of this DoS scenario.

Nit: There's a missing space in "regard[VU723308]". Also, CERT-FI has
publish an advisory on the same issue. And UK CPNI has published a TCP
security report that contains a lengthy discussion on this attack (and
different variants, and the possible counter-measures.



>    In such cases, and specially when the receiver is reliably
>    acknowledging zero window probe, to achieve robustness, the system
>    should be able to take appropriate action on those TCP connections
>    and reclaim resources.

I'd s/robustness/resiliency/. (Actually, I'd argue that by aborting
these connections, you're actually *reducing* TCP's robustness).


>    In order to accomplish this action, TCP MAY provide a feedback
>    regarding the persist condition to the application if requested to do
>    so or the application or the resource manager can query the health of
>    the TCP connection which would allow it to take the desired action.
>    All such actions are in complete compliance of RFC 793 and RFC 1122.

As mentioned other times, I think the app cares about the connection
making progress (or not), and not really about the reason for the lack
of progress (see the discussion in the CPNI paper about these issues).


Aside: FWIW, RFC 793 describes an ABORT() call that an app is free to
use at any time. Therefore, I'd argue that if the *app* takes action,
RFC 1122 is irrelevant. Only if you need *TCP* to take action you should
mention/care about what RFC 1122 says.



>    It also suggests that TCP MUST not abort any connection until either
>    explicitly requested by the application to do so.  The implementation
>    guidelines of the request and the action are documented in Section 7,
>    and the details of mitigating the DoS attack are left to the
>    implementer.

You probably want to s/MUST not/MUST NOT/.


>    The interface allows applications to inform TCP that when the local
>    connection stays in persist condition it can be cleared after a set
>    time.  Note that the default value of this option is indefinite.

s/cleared/aborted/.

Also, did you mean "infinite" rather than "indefinite"?



>    TCP sender will save the current time in the connection block when it
>    receives a zero window ACK.  This time is referred to as the persist
>    entry time.  Thereafter every time the probe timer expires and before
>    it sends another probe or an ACK carrying zero window is received a
>    check will be done to see how long the connection has been in persist
>    condition by comparing the current time to the persist entry time.
>    If the timeout has been exceeded, the connection will be aborted.
> 
>    Any time a ACK is received that advertises a non-zero window, the
>    persist entry time is cleared to take the connection out of persist
>    condition.

You should probably remove this, or just mention this as a possible
implementation approach. That is, one could implement the same
functionality without following this specific implementation strategy.

P.S.: Please let me know if you'd like me to post my feedback to the
mailing-list.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1







-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1