Re: [tcpm] [Fwd: I-D ACTION:draft-eggert-tcpm-tcp-abort-timeout-option-00.txt]

At 09:13 21/04/2004 +0200, Lars Eggert wrote:

>this announcement doesn't seem to have made it onto the list. I'd 
>appreciate some group feedback on the ID.

Here's my feedback on your draft. Note that some of my comments are some 
"eitorial" notes, while others are technical stuff.

Page 2, first para: It says "In between connected periods, mobile hosts may 
experience disconnected periods during which no network service is available."
I'd probably re-phrase it as "Mobile hosts may experience periods of time 
during which no network service is available."

Page 2, first para: It says "....their established TCP connections can 
abort during periods of disconnection."
I'd write it as "....their established connections may be aborted during 
periods of disconnection."

Page 2, second para: It says "If a disconnection lasts longer than the user 
timeout, the TCP connection will abort".
I'd say "....will be aborted", instead.

Page 2, third para: It says "Instead of a single user timeout, some TCP 
implementations offer finer-grained mechanisms"
IMHO, it should say "policies" instead of "mechanisms".

Page 2, third para: It says "The Host Requirements document".
I'd say "RFC" instead of "document".

Page 2, fourth para: It says "This document specifies a new TCP option - 
the Abort Timeout Option".
IMHO, "Abort timeout" is a misnomer. I'd call it "Connection Timeout", instead.
(I would also change all instances of "abort timeout" to "connection timeout").

Page 3, first para: It says "A host wishing to negotiate a specific abort 
timeout for a connection MAY include the TCP Abort Timeout Option".
As you say "A host wishing to negotiate a specific abort timeout", I'm not 
sure whether I'd say "MAY" (i.e., I'd probably say "MUST"). (I would do say 
"MAY" if you just said "A host MAY include the TCP Abort Timeout Option").

Page 3, first para: It says "It MUST NOT include an Abort Timeout Option in 
any other segment."
Note that the ATO is included in segments other than those with the SYN bit 
set. See Figure 2, the one on the right: The ATO is included in a pure-ACK 
segment (i.e., the SYN bit is not set).

Page 3, second para: It says "Connections use abort timeouts negotiated 
with Abort Timeout Options during the ESTABLISHED state only."
I'd write it as "The negotiated timeout is meant to be used only during the 
ESTABLISHED state."

Page 3, fourth para: It says "Upon receipt of a segment with the Abort 
Timeout Option, the receiving host decides whether to accept, shorten, or 
reject its peer's proposed abort timeout."
Why shouldn't the receiving host be able to *enlarge* the proposed abort 
timeout?

Page 3, fifth para: It says "This will either be the SYN-ACK, if it 
received the peer's Timeout Abort Option...."
It should say "Abort Timeout Option" instead of "Timeout Abort Option".

Page 3, fifth para: It says:
"  When a receiving host accepts or shortens the offered abort timeout,
    it MUST include an Abort Timeout Option with the corresponding
    timeout value in the next segment it sends.  This will either be the
    SYN-ACK, if it received the peer's Timeout Abort Option in the SYN
    segment, or the first ACK if it received the option in the SYN-ACK
    segment."
Consider the following scenario:
Host A receives the peer's ATO in the SYN-ACK segment, and thus includes 
the ATO in the first ACK. This ACK is lost. Before the peer timouts and 
retransmits the SYN-ACK segment, A sends some data to the peer. In this 
scenario, the peer will think A does not support the ATO, when it *does* 
support it.

Page 4: Have you considered using the "TCP Abort Timeout Option" in a 
similar fashion to TCP's MSS option? I mean, rather than "negotiating" a 
timeout, I'd just make the end-points "suggest" a timeout. The option would 
be sent in the SYN segment, in the same way as the MSS option. The timout 
wouldn't need to be symmetrical, either. How to deal with the option would 
be a policy of each system. However, I'd probably suggest that the larger 
of both values (in case both end-points included the ATO) is chosen, 
provided it's not larger than a per-system defined limit (that means, if 
one of the endpoints specifies a timeout period of, say, 60 minutes, but 
the system limit is 40 minutes, then *40* minutes would be chosen for the 
timeout period).

Page 4, second para: It says "It MUST then also use its default timeout 
value for the connection."
I'd probably remove the word "also".

Page 4, fourth para: It says "If it does, the connection MUST use the abort 
timeout contained inside the Abort Timeout Option."
I'd say "TCP" instead of "the connection".

Page 4, fifth para: It says "This causes the connection to use the default 
abort timeout, thus ensuring interoperability."
I'd say "TCP" instead of "the connection".

Page 5, first para: "The TCP specification [1] does not define a range for 
permitted abort timeouts."
Shouldn't it say "of" instead of "for"?

Page 5, second para: It says "Very short timeout values can affect TCP 
retransmissions over high-delay paths."
I'm not sure what you mean here.

Page 6, first para: It says "Connections could default to starting with 
shorter timeouts and only negotiate longer timeouts when disconnection was 
imminent."
I'd probably say "short" instead of "shorter".

Page 6, first para: It says "Connections could default to starting with 
shorter timeouts and only negotiate longer timeouts when disconnection was 
imminent."
What do you mean by "when disconnection was imminent"?

Page 6, first para: It says "This may reduce the amount of state held 
during times of disconnection."
I'm not sure what you mean here.

Page 6, third para: It says "It may be useful to permit finer-grained 
timeouts, e.g., milliseconds instead of seconds."
What would you use such a timeout period for?

Page 6, third para: "For example, a 16-bit timeout value with a granularity 
of seconds allows timeout values up to 18.2 hours, whereas a 32-bit 
timestamp with millisecond granularity allows timeout values up to 49.7 days."
I'd stick to a granularity of seconds. Regarding the length of the timeout 
field, I'm not sure there's a real use for a timeout of, say 49.7 days. So 
I'd probably stick to a 16-bit field.

Page 7, second para: It says
"  However, when an attacker completes the three-way handshakes of its
    throw-away connections it can amplify the effects of resource
    exhaustion attacks, because the attacked server must maintain the
    connection state associated with the throw-away connections for
    longer durations."
If the attacker was able to complete the three-way handshake, then it's 
likely he will also be able to ACK whatever the victim is sending over the 
connection, so that the connection is not aborted. OTOH, note that, in 
principle, the throw-away connections will be aborted only if the victim 
sends data on the connection. If that's not the case then there's no reason 
for the connection to timeout.
If you're thinking about TCP's Keepalive mechanism, I'd say that given the 
large timeout values it usually has, it would not stop the attack.

Page 7, third para: It says "Although this is arguably the most complete 
solution, it depends on external mechanisms to establish trust."
I'd probably say "the trust relationship", instead of "trust".

Page 8, it says:
'   [6]  Moskowitz, R., "Host Identity Protocol Architecture",
         draft-moskowitz-hip-arch-05 (work in progress), October 2003.'
I think there should be a new version of this draft.

Just my two cents,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm