Subject: [tcpm] WG Last call for draft-ietf-tcpm-tcp-timestamps-00.txt

From: David Borman <[email-masked]>
Date: Thu, 16 Sep 2010 13:18:30 -0500

Wes and I would like to start a two week working group last call on:

	draft-ietf-tcpm-tcp-timestamps-00.txt

If you have any comments, please send them to the mailing list.  There hasn't been any recent discussion on the mailing list about this document, so we'd really like to see some comments, even if they are just "yes, it's ok", i.e., we need positive feedback to move this forward.

Please send your comments to the list by Friday, Oct 1, 2010.

		-David Borman and Wes Eddy, TCPM co-chairs

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Sep 2010 11:36:49 -0700

Hi, all,

The following notes, FWIW, are fixable, but should be fixed before 
proceeding.

Joe

-----
Major issues:

This doc claims it's OK (BCP in fact) to use timestamps to avoid 
time-wait, but agrees that there's no monotonicity requirement for 
timestamps, and doesn't require one. That doesn't seem consistent.

Further, this doc notes that this is not current practice, so the BCP 
track doesn't seem appropriate. It might be more useful to consider this 
Informational.

A few other observations:

A useful non-normative reference explaining the problem is:
T. Faber, J. Touch, and W. Yue, “The TIME-WAIT state in TCP and Its 
Effect on Busy Servers,” in Proc. IEEE Infocom, 1999, pp. 1573-1583.

The doc claims that RFC793 uses ISN generation is based on incrementing. 
RFC1948 suggests otherwise, and should be discussed in this context (and 
cited).

Sec 4.1 has a major heading (4.) that implies there are multiple corner 
cases, but only one is described. This should be cleaned up, or other 
corner cases should be added (e.g., as per Alfred's note back in 2009 on 
the -00 individual submission)

----

On 9/16/2010 11:18 AM, David Borman wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Fernando Gont <[email-masked]>
Date: Fri, 17 Sep 2010 14:27:35 -0300

Hi, Joe,

Thanks so much for your feedback! Please find my comments inline....

> timestamps, and doesn't require one. That doesn't seem consistent.

That was probably my fault while splitting the I-D. The discussion had
been over non-predictability of timestamps rather than over
monotonicity. Do you think it would be okay to add a SHOULD for
monotonicity?

> track doesn't seem appropriate. It might be more useful to consider this

It is. Linux does this, for example. And IIRC FreeBSD does this, too.
IIRC, only OpenBSD does TCP timestamps randomization in such a way that
monotonicity is not guaranteed.

> Effect on Busy Servers,” in Proc. IEEE Infocom, 1999, pp. 1573-1583.

Agreed. For some reason, I had not included this one, but will certainly
add this to the next rev.

> RFC1948 suggests otherwise, and should be discussed in this context (and

Well, even RFC1948 is based on incrementing... although not in a way
that makes ISN predictable for an off-path attacker.

> cases, but only one is described. 

Yeah, the title is a "mis-title". It tries to address "all corner
cases", but this is the only one that has been identified. -- which
actually isn't, as noted in the I-D.

> This should be cleaned up, or other

Do you mean I should remove the section? Rename it? Move it to an
appendix? Please suggest a way forward....

Thanks!

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Sep 2010 11:22:58 -0700

> monotonicity. Do you think it would be okay to add a SHOULD for

I don't think this document should make recommendations like that. IMO, 
it's more appropriate to consider the impact of non-monotonicity on the 
other recommendations (which should be minor, as you note - they would 
just make the mechanism fail the way it would if not used at all).

> monotonicity is not guaranteed.

Then the discussion needs to be updated accordingly, and those OS's that 
include this should be noted (as well as those that don't and why). 
Also, it'd be useful to explain why some OSs randomize the timestamps 
(if that's for security, does it suggest that this mechanism would be 
less useful in the future?)

> that makes ISN predictable for an off-path attacker.

That needs to be discussed.

> appendix? Please suggest a way forward....

I think there are other corner cases from Alfred's 2009 note that could 
be included, and the toplevel heading (4.) could introduce the list, 
which would make the plural still applicable.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 17 Sep 2010 16:28:27 -0300

Hi, Joe,

> just make the mechanism fail the way it would if not used at all).

Why not? For instance, this was adopted by rfc1323bis....

> Then the discussion needs to be updated accordingly, 

Will do.

> and those OS's that

The reason is probably the same for "why do stacks do predictable ISNs?"

> (if that's for security, 

Yes, the reason is security.

> does it suggest that this mechanism would be

No, it doesn't. As noted in draft-gont-timestamps-generation, trivial
randomization is probably not the most wise approach to unpredictability.

And OpenBSD also does trivial ISN randomization rather than RFC1948...
not the best possible approach, either.

> That needs to be discussed.

What (specifically) do you expect the I-D to discuss? -- Just not that
RFC1948 produces incremental ISNs, or what?

> which would make the plural still applicable.

I cannot find those corner cases. Could you point out the corner cases
you're referring to?

Thanks!

Kind regards,

---

From: John Heffner <[email-masked]>
Date: Fri, 17 Sep 2010 17:54:15 -0400

I was a little surprised this is in last call right now, but I guess
that forced me to read it carefully. :)  I don't think it's quite
ready for publication as-is, particularly as a BCP.

This draft is revising RFC793 and RFC1122, in that it allows TIME-WAIT
reuse even when the new SYN's sequence number is less than RCV.NXT (if
the new incarnation is protected by timestamps).  Technically, I think
this is fine, but doesn't this imply standards track?

In general, the document feels like it could really be tightened up.
It's kind of verbose, which, if anything, makes it less clear.  IMO
this ideally would be a single subsection of RFC1323bis.  I know this
has been said before and it may not be practical.

A few specific questions/comments:

In Section 3, it says that a connection in TIME-WAIT can be
assassinated when a "timestamp that is smaller than the last timestamp
seen on the previous incarnation of the connection" is received.  How?
 I thought assassination only occurred from old data.

It may be worth noting that the PAWS check is still done on incoming SYNs.

This needs further explanation, or a citation (it feels out of place):
o  If a SYN segment is received for a connection in any synchronized
      state other than TIME-WAIT, respond with an ACK, applying rate-
      throttling.

The "Corner-cases" section seems unnecessary, or at least misnamed.

Thanks,
  -John

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Sep 2010 15:42:23 -0700

> Why not? For instance, this was adopted by rfc1323bis....

I don't see this document as significant motivation on its own for a 
SHOULD. If you want to remind readers that this is/will be a SHOULD in 
rfc1323bis, that's fine, but for the reasons cited there.

> not the best possible approach, either.

My point is that if OS's are doing randomization for security (and since 
security concerns are increasing, that behavior may be more common), 
doesn't this undermine your use of the timestamps because you're 
expecting monotonicity?	

> RFC1948 produces incremental ISNs, or what?

You need to cite RFC1948, and indicate how it affects (or doesn't) your 
solution. It's insufficient to ignore it (i.e., just capture this email 
thread's discussion in text).

> I cannot find those corner cases. Could you point out the corner cases

See attached.

Joe

Subject: [tcpm] draft-gont-tcpm-tcp-timestamps-00
From: Alfred Hönes <[email-masked]>
To: [email-masked]
Date: Wed, 14 Jan 2009 00:16:29 +0100 (MEZ)
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>

Folks,

I have reviewed the I-D, draft-gont-tcpm-tcp-timestamps-00,
which has been submitted to the WG for consideration.

The basic idea in the draft seems to be so logical and such
an immediate step forward in the spirit of RFC 1122 that,
if the TCP timestamps option already had been defined during
the development of RFC 1122, I suspect that it readily would
have been incorporated and recommended therein!

Besides a small couple of textual flaws and improvement requests
I already have communicated off-list to the author, there seems
to be a double oversight in the second part of the algorithm in
section 3:

a)  There's no "Otherwise, ..." clause.

    Fix: Copy the sibling clause literally from the end of the
    first part of the algorithm to the end of the second part!

b)  The following (potentially rare) corner case, in which it
    would have been possible according to the rules in RFC 1122
    to establish a new connection notwithstanding a previous
    incarnation in the TIME-WAIT state, has not been considered:

    -  old connection didn't use TSO,
    -  new SYN segment with TSO,
    -  local policy / socket options would lead to SYN-ACK without TSO,
    -  new incoming Sequence Number > last corresponding old SN

    Including this case into the second alternative of the second
    part of the algorithm would therefore further improve the benefit
    of the algorithm.

    It might be preferable to make the answer to the question
        'would the new connection be using timestamps?'
    the primary criterion for distinguishing between the first
    and the second alternative in the second part of the algorithm.
    Doing so would allow to simplify the text otherwise necessary
    to describe the preconditions in the second alternative.

    I have submitted ot the author some possible text variants to
    accommodate these considerations and discussed their mutual
    benefit.  For the sake of brevity, I have omitted the details
    here, shortly ahead of a promised update to the draft.

Best regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Sep 2010 15:45:50 -0700

On 9/17/2010 2:54 PM, John Heffner wrote:
...
>        state other than TIME-WAIT, respond with an ACK, applying rate-

I was wondering about this too-- I don't see why SYNs would be handled 
differently at all except in TIME-WAIT.

I.e., the text seems like it should read:

  o  If a SYN segment is received for a connection in any synchronized
         state other than TIME-WAIT, respond as per RFC793.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 17 Sep 2010 21:50:57 -0300

Hi, John,

> this is fine, but doesn't this imply standards track?

Probaby. It should probably modify RFC1323, rather than RFC793 regarding
this....

> It's kind of verbose, which, if anything, makes it less clear. 

Are you suggesting that the processing rules would be better explained
in pseudo-code, or what?

>  I thought assassination only occurred from old data.

See RFC1337. If the TCP implements RFC793 (rather than RFC 1337), the
TIME-WAIT state would be assassinated.

> It may be worth noting that the PAWS check is still done on incoming SYNs.

Not sure what you mean.

>       state other than TIME-WAIT, respond with an ACK, applying rate-

IIRC, this is from tcp-secure, so I agree that a reference is warranted.
Here I'm summing up the processing of SYN segments in every state.

> The "Corner-cases" section seems unnecessary, or at least misnamed.

Agreed. IMO, it could be moved into an Appendix, or removed altogether.

Thanks!

Kind regards,
Fernando

---

From: Fernando Gont <[email-masked]>
Date: Sat, 18 Sep 2010 14:44:27 -0300

>         state other than TIME-WAIT, respond as per RFC793.

This is the behavior specified by tcp-secure.

If we were to reference other specs, this should probably be "as per
RFC1337" -- although RFC1337 is informational... but certainly TIME-WAIT
state assassination is not a good thing.

Thanks!

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 18 Sep 2010 15:11:48 -0300

> rfc1323bis, that's fine, but for the reasons cited there.

I don't follow. Why the same requirement would not be appropriate here,
but *would* in another document?

> doesn't this undermine your use of the timestamps because you're

No, it doesn't. Just pick a good randomization scheme. Randomization
does not necessarily mean issuing a random() call. For instance, the
algorithm that was included in previous versions of this I-D did
randomization, while still producing a monotonically-increasing sequence
(a la RFC1948)

> thread's discussion in text).

Ok, good. Will do.

>> I cannot find those corner cases. Could you point out the corner cases

The single point that Alfred raised could probably be included in the
processing rules already present. -- although it's a very unlikely case,
so one could consider that as a corner case. -- any preference for any
particular approach?

Thanks!

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Sep 2010 08:52:44 -0700

> This is the behavior specified by tcp-secure.

If this is  *necessary* for your algorithm to work, you need to explain 
the rationale in more detail, and include more of a discussion of its 
linkage to tcp-secure. AFAICT, however, this algorithm has no 
relationship to tcp-secure.

Regardless, you should not include descriptions of TCP actions not 
modified (this doc is not rfc793bis).

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Sep 2010 10:20:58 -0700

Hi, Fernando,

> but *would* in another document?

I'm asking you to answer that question. Is that SHOULD necessary here? 
My concern is that you basically need the majority of clients to change 
their behavior to benefit, and it only benefits some servers (in 
particular, ones with high connection rates to specific hosts).

If you want to say that rfc1323bis recommends it, and this mechanism 
also benefits from it, that's easier to justify.

> randomization, while still producing a monotonically-increasing sequence

So here's the questions again:

- are you expecting randomization for security reasons to be more widely 
deployed?

AFAICT, you didn't answer that.

- does randomization interfere with your mechanism?

Yes, if it isn't also monotonic. I wouldn't characterize it as trivial 
or not; monotonicity is a specific property that has nothing to do with 
randomness directly.

So you might need to say that:

	IF randomization is applied, then this mechanism
	benefits ONLY IF that randomization is also monotonic.

If you want to include an example of such a mechanism in an appendix, 
that would be useful. (but this doc wouldn't be recommending it as a 
SHOULD, just to be clear).

...
> so one could consider that as a corner case. -- any preference for any

Nope.

Thanks,

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Sep 2010 05:05:59 -0300

Hi, Joe,

> relationship to tcp-secure.

Exactly: this requirement of tcp-secure does not affect this algorithm.

> modified (this doc is not rfc793bis).

The description is not included in normative text. It's just included
for convenience of the reader: i.e., allow the reader how the proposal
fits into the rest of SYN-processing.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Sep 2010 05:45:21 -0300

Hi, Joe,

> I'm asking you to answer that question. Is that SHOULD necessary here?

Are you arguing in favor of a "MAY" rather than a "SHOULD"?

> particular, ones with high connection rates to specific hosts).

You're assuming that most implementations do tcp timestamps
randomization (and they don't). Other than that, you don't lose anything
in the worst-case scenario.

> also benefits from it, that's easier to justify.

I don't follow. IIRC, rfc1323 incorporates this as a result of this I-D.
And even then I don't understand how "rfc1323bis does this" is a better
justification than the one I'm giving.

> AFAICT, you didn't answer that.

I expect randomization scheme such as the one proposed in my other I-D
to be more widely deployed.

> SHOULD, just to be clear).

Perfect. Will do.

>> so one could consider that as a corner case. -- any preference for any

As noted by Alfred, his concern is already addressed in the current
version of the I-D.

Thanks!

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Wed, 22 Sep 2010 07:37:13 -0700

Hi, Fernando,

> Exactly: this requirement of tcp-secure does not affect this algorithm.

In that case, it should not be noted in this doc. As you've already 
seen, the behavior depends on the variant of TCP deployed. tcp-secure is 
NOT required for all TCP implementations.

> fits into the rest of SYN-processing.

That's not necessary and is confusing; only the normative changes should 
be described.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 22 Sep 2010 07:43:46 -0700

Hi, Fernando,

> Are you arguing in favor of a "MAY" rather than a "SHOULD"?

I'm arguing that this doc would explain what happens when various 
choices are made, but I don't recall WG discussion on 2119-level 
recommendations on a requirement for timestamps being monotonic across 
connections.

> in the worst-case scenario.

I'm assuming that implementations aren't currently required to have 
monotonic timestamps across connections, and adding that bar is 
substantial. If we count 'majority', I'd want to understand what 
cellphones, etc. do, FWIW.

> justification than the one I'm giving.

OK -so if 1323 incorporates this primarily because of this I-D, then 
this I-D is the place to resolve it. See above regarding 2119 discussion.

> to be more widely deployed.

I asked whether randomization would be increasingly deployed for 
security reasons. If that's true, then we need to understand what 
algorithm will be deployed and whether it is likely to be monotonic 
across connections.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Wed, 22 Sep 2010 08:04:00 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Joe Touch
> Sent: Wednesday, September 22, 2010 7:37 AM
> To: Fernando Gont
> Cc: [email-masked] WG
> Subject: Re: [tcpm] WG Last call for 
> >> If this is  *necessary* for your algorithm to work, you need to 
> >> explain the rationale in more detail, and include more of a 
> >> discussion of its linkage to tcp-secure. AFAICT, however, this 
> >> algorithm has no relationship to tcp-secure.
> >
> In that case, it should not be noted in this doc. As you've 
> already seen, the behavior depends on the variant of TCP 
> deployed. tcp-secure is NOT required for all TCP implementations.

I dis-agree. For stacks which implement RFC 5961, and the current
recommendations this sort of a clarification would definitely help.
There is no harm in mentioning that in the document, IMO.

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Wed, 22 Sep 2010 08:29:38 -0700

On 9/22/2010 8:04 AM, Anantha Ramaiah (ananth) wrote:
...
> recommendations this sort of a clarification would definitely help.

Is tcp-secure insufficient in describing how SYNs are processed in 
established states? If so, then it needs to be revised, since there's no 
guarantee that this doc would be read by those implementing tcp-secure.

(the alternative would be to make this UPDATE tcp-secure, but it doesn't 
change anything in tcp-secure, at least as per Fernando's assessment)

> There is no harm in mentioning that in the document, IMO.

There is no rationale for explaining how this mod *doesn't* interact 
with every detail of either tcp-secure or RFC793.

There is plenty of harm, as well. Adding that detail invites error. 
Consider future changes to SYN processing in established states - would 
they UPDATE this doc? (no, because it's not normative). But then this 
doc would conflict with those changes.

Let's please leave unchanged protocol specs in their original place. at 
best it would be useful to note that "this mod is compatible with, but 
does not depend on, tcp-secure". However, as with the specs, why not add 
such statements for all TCP variants? (TCP-AO, all the congestion 
control algs, etc.)?

Redundancy without purpose isn't useful.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Sep 2010 13:01:43 -0300

Hi, Joe,

> established states? If so, then it needs to be revised, 

It is not that tcp-secure is incomplete. It just that it helps
developers to be able to see how this fits in all the rest of
SYN-processing.

BTW:
Revising tcp-secure? Are we targeting 2016? C'mon, Joe... :-)

> since there's no

This text is non-normative. So I don't see the problem.

> doc would conflict with those changes.

That's always the case with informative text and informative references!

> such statements for all TCP variants? (TCP-AO, all the congestion

Sorry, I don't follow.

Part of tcp-secure is about modifying the processing of SYN segments
based on TCP state - that's not the case with, e.g., TCP-AO.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Wed, 22 Sep 2010 09:10:50 -0700

> developers to be able to see how this fits in all the rest of

They don't need that, since there are no changes in the 'established' 
state; if they did, they would need to know how it fits in with SYN 
processing for every variant of TCP.

Can others on the list please indicate what they think of this issue?

> based on TCP state - that's not the case with, e.g., TCP-AO.

Please see sections 7.4 and 7.4, notably steps 1.a. TCP-AO modifies SYN 
processing only in the listen state; tcp-timestamsp modifies SYN 
processing only in TIME-WAIT.

How other states are handled should never be described, even 
informatively, unless there is a specific reason. There's no reason 
here. The only thing you should be saying is "no change to SYN 
processing in other states".

Joe

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Wed, 22 Sep 2010 11:31:00 -0500

I tend to agree that the best (and correct) thing to do is simply have a sentence that says "This document only modifies incoming SYN processing in the TIME-WAIT state; processing in all other states is unchanged."

This should be totally unambiguous and establish scope without talking about other modifications one-by-one.

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Joe Touch [[email-masked]]
Sent: Wednesday, September 22, 2010 12:10 PM
To: Fernando Gont
Cc: [email-masked]; Anantha Ramaiah (ananth)
Subject: Re: [tcpm] WG Last call for draft-ietf-tcpm-tcp-timestamps-00.txt

...

tcp-timestamsp modifies SYN processing only in TIME-WAIT.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Sep 2010 13:35:13 -0300

Hi, Joe,

> processing for every variant of TCP.

FWIW, tcp-secure talks, in Section 4.2 about "the synchronized state".
May take is that this is a writeo, and it should say "the ESTABLISHED
state", instead.

However, "as is", it is effecting the TIME-WAIT state, too (which is a
synchronized state)

> processing only in the listen state; 

Does it update the TCP state machine?

> processing in other states".

All the above say, I have no problem with dropping the text you mention
if the WG agrees to do so.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Sep 2010 13:45:05 -0300

Hi, Wes,

Just double-checking: So you argue that I should be removing this:

>    o  If the corresponding connection is in the TIME-WAIT state, then,

?

Thanks!

Kind regards,
Fernando

On 22/09/2010 01:31 p.m., Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE

---

From: Joe Touch <[email-masked]>
Date: Wed, 22 Sep 2010 09:51:53 -0700

> However, "as is", it is effecting the TIME-WAIT state, too (which is a

Then it would make sense to explain how or whether tcp-secure interacts 
with SYNs that arrive during TIME-WAIT. Again, if it doesn't affect 
things there or elsewhere, the it's not appropriate to reiterate the 
details of how SYN processing is not changed by this ID.

> Does it update the TCP state machine?

It doesn't add new states, but neither does tcp-secure. It modifies arcs 
and arc processing as per tcp-timestamps. But none of the tcp-timestamp 
modifications affect the changes tcp-secure indicates, as you noted before.

Joe

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Wed, 22 Sep 2010 13:40:03 -0500

Yes; and of course, the sentence above those bullets which which mentions processing of SYNs in all synchronized states, would be changed to say processing of SYNs in TIME-WAIT.

________________________________________
From: Fernando Gont [[email-masked]] On Behalf Of Fernando Gont [[email-masked]]
Sent: Wednesday, September 22, 2010 12:45 PM
To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
Cc: Joe Touch; [email-masked]; Anantha Ramaiah (ananth)
Subject: Re: [tcpm] WG Last call for draft-ietf-tcpm-tcp-timestamps-00.txt

Hi, Wes,

?

Thanks!

Kind regards,
Fernando