Subject: [tcpm] poll for adoption of draft-gont-tcpm-tcp-timestamps-03

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Mon, 8 Mar 2010 13:49:32 -0600

Hello, Fernando has made an update to his draft on the
generation of TCP timestamps, and asked us to poll the
TCPM WG to have this particular document adopted as a
WG draft for BCP.

http://tools.ietf.org/html/draft-gont-tcpm-tcp-timestamps-03

This was briefly discussed at IETF 73 in Minneapolis,
and the decision was delayed until more people had read
it.

Please respond if you either:

(1) Support making this document a WG document with the
    target for BCP.

(2) Oppose making this document a WG document.

Of course, other comments are also welcome :).

It's relatively short, so if people could respond in the
next 2 weeks, this would allow us to determine consensus
during the week of the IETF meeting.

--
Wes Eddy
MTI Systems

---

From: Mark Allman <[email-masked]>
Date: Mon, 22 Mar 2010 14:06:07 -0400

> Of course, other comments are also welcome :).

Well...  Um... Something Else.

Thoughts:

  - First, its fine technology.  I find the security implications to be
    pretty dubious (an attacker guessing a TS and then leveraging that
    seems a Pretty Damned Remote Possibility).  But, the connection
    identifier re-use business is nice enough.

    So, I think we should take on this work in some fashion (which is
    not exactly what (1) indicates in taking "this document [...] for
    BCP").

  - But, to me, the right thing to do here is to roll these changes into
    the work item this WG already has going: 1323bis.  Clearly how to
    generate timestamps (section 2 of the Gont I-D) is within bounds for
    that document.  In addition, section 3 of the Gont document can
    readily be viewed as another application of timestamps (a la RTTM
    & PAWS).  

  - So, I don't know why we'd spin off a second document when we are
    already updating the main document in this space.  TCP is fragmented
    enough and so when we can fit things together we should.  Further,
    its one less document this WG will have to food fight over.

  - Why straight to BCP?  I don't really have any technological issues
    here I want to flog, but it strikes me as pretty weird to move
    a mechanism like this right to BCP.  Even if I don't have a lot of
    technical heartburn, we seemingly have a 'standards track' for a
    reason. 

My two cents ...

allman

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 22 Mar 2010 11:25:09 -0700

Mark brings up a good point, IMO. My thinking here is that ISN
generation RFC (1948) is an informational RFC and did really update RFC
793. (may be RFC 793 is very holy and you can't really have a bis for
that? ;-) Following the same analogy, this draft can be a standalone
draft which recommends that something can be done as it is structured
currently. OTOH, the same text can be folded as part of the RFC1323bis
as well. Looks like it is boiling down to be a procedural question here
?

Just my few cents,
-Anantha 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mark Allman
> Sent: Monday, March 22, 2010 11:06 AM
> To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
> Cc: [email-masked]
> Subject: Re: [tcpm] poll for adoption of 
> draft-gont-tcpm-tcp-timestamps-03
> 
>

---

From: <[email-masked]>
Date: Mon, 22 Mar 2010 19:43:26 +0000

On 22 Mar 2010, at 18:06, Mark Allman wrote:
>    the work item this WG already has going: 1323bis.

http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-01
is based on
http://www.ietf.org/mail-archive/web-old/ietf-announce-old/current/msg25824.html

1323bis has been going since 2003, and that's only in its current form.

http://www.kohala.com/start/tcplw-extensions.txt
predates that by another decade. (I've found this particular draft
useful previously.)

So, this prompts the question as to when this ever-iterated document
might be published.

>    already updating the main document in this space.

if it's relatively self-contained without dependencies, treat it as
a separate work item, and get it published, rather than getting bogged
down in a larger item that is already close to two decades overdue.

>    TCP is fragmented

1323bis is too large, and too old. It's a massive food fight waiting
to happen once people not even born when it was started wade in,
not to mention a large editing work effort.

My vote is to keep the timestamps stuff self-contained and separate.
Publish what you can.

>    technical heartburn, we seemingly have a 'standards track' for a

I don't disagree.

Lloyd Wood
[email-masked]
http://sat-net.com/L.Wood

---

From: Mark Allman <[email-masked]>
Date: Mon, 22 Mar 2010 16:19:06 -0400

I don't track this stuff very closely.  So,

  - If 1323bis is not happening then going with an independent document
    is fine with me.  

  - It just strikes me as strange to do both strands independently if we
    are in fact doing both strands.

  - 1323bis can always pick this up at some point and obsolete any small
    document (as we have done for instance with 5681 picking up 3390 and
    3042).

  - I need to see more justification before agreeing that this
    straight-to-BCP track is reasonable.

allman

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Mar 2010 09:01:10 -0700

Yet another attempt to redefine TCP fields as providing "security".

By randomizing the initial timestamp, we now need to keep per-connection
timestamp offsets, which increases both state and processing. It also
means that incoming connections to socket pairs in TIME_WAIT would
silently fail roughly half the time, requiring undue timeouts.

I don't think this represents an appropriate recommendation for the
community, and oppose making it a WG doc.

Joe

Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Mar 2010 14:23:24 -0300

Hi, Joe,

> timestamp offsets, which increases both state and processing. 

Huh? I don't follow this. Could you clarify what's the "extra state" and
"extra processing" you're referring to?

> It also

Joe, please read the I-D. It's *without* this RFC1948-like scheme that
timeouts/delays could occur. -- this mod actually improves the handling
of incoming connection requests (SYNs), allowing connections that would
have otherwise failed.

(see also the reference to Mike Silbersack's presentation at BSDCan)

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

---

From: John Heffner <[email-masked]>
Date: Tue, 23 Mar 2010 13:28:56 -0400

> silently fail roughly half the time, requiring undue timeouts.

If I understand correctly, that's not the case.  The function from Section 2:
  timestamp = T() + F(localhost, localport, remotehost, remoteport, secret_key)
has no per-connection state*, and should not result in any issues with
TIME_WAIT connections.  Though it does not say so explicitly, my
understanding is that secret_key is intended to be a system-wide value
initialized on boot with random data..

It seems like a very reasonable approach to me -- low-cost and easy to
implement with no major downsides.

  -John

* I guess there would be some soft state, because you'll want to cache
the value of F().

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Mar 2010 10:50:32 -0700

> "extra processing" you're referring to?

   timestamp = T() + F(localhost, localport, remotehost, remoteport,
   secret_key)

Either I need to keep the result of F(...), or I need to recompute for
each timestamp. The former costs processing, the latter costs state.

Either way, you're adding an index and an add to the timestamp
calculation. That's processing. We're talking about extra steps for
every packet.

> of incoming connection requests (SYNs), allowing connections that would

The document never asserts that the "secret_key" would never change.

If it does change, you run the risk that F(...) will end up being
sufficiently lower that you fall through your checks and treat the SYN
as a silent discard, which causes delays.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Mar 2010 15:34:03 -0300

Joe,

> each timestamp. The former costs processing, the latter costs state.

I would argue that the benefits of this proposal outweigh e.g., the
"extra state" (four bytes?) you're referring to.

> as a silent discard, which causes delays.

I disagree. The delays are caused by RFC1337 (or by RFC793 itself), and
*not* by the proposal in this I-D. i.e., the worst-case scenario of the
proposal in this I-D is never worse than RFC1337 or RFC 793.

That said, you may perform "heuristics" to decide when to change the key
(e.g., when there has not been connections for 2MSL, or when the number
of ongoing connections is really small). This should be already well
understood, as the considerations for key changes are the same as for
RFC1948 (for the generation of TCP ISNs).

P.S.: I'm "surprised" to hear your comment, since during an informal
meeting at the MPLS IETF with me and David Borman, you did support this I-D.

P.S.: Just wanted to make my point. I won't respond further messages
unless I have something else to add (not previously stated), in the
hopes of keeping the S/N ratio of this list at a decent level.

Thanks,

---

From: Mark Allman <[email-masked]>
Date: Tue, 23 Mar 2010 15:05:15 -0400

> Yet another attempt to redefine TCP fields as providing "security".

Yeah, that's pretty bogus.

But, I don't think the rest of your argument holds much water.  In
particular, 

  - Yeah, more state, but not a lot more state.  Yeah, more computation,
    but not a lot more computation.  I think if moved forward this would
    be something like a MAY or a SHOULD, not a MUST.  So, if someone had
    a good reason (and sometimes state and computation are in short
    supply) and they didn't want to do this, fine.

  - Perhaps the document needs clarification on the secret portion of
    the computation, but I don't buy that this will unduly cause issues.
    Worst case, we're where we are now---i.e., you discard SYNs until
    the end of TIME_WAIT.  Best case, we understand that a new
    connection is a new connection and we can truncate TIME_WAIT.

I just don't see the big worry here.  If its optionally keeping a long
around and doing an add / packet I think that is a quite minor
complaint. 

On the other hand, is this really *needed*?  No, absolutely not.  The
client has the needed control right now in that it can just use a
different ephemeral port for each connection.  And, unless you have some
sort of Really Pathological Case then you're not going to need to re-use
ephemerals often enough to hit a problem with everything being wedged in
TIME_WAIT.  So, don't get me wrong, I won't be terribly sad to see this
just go away.  But, it seems to me that plenty of people think its
reasonable enough that the WG should take it on.  And, in the absence of
any actual big issues it seems to be like that ought to be enough.

allman

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Mar 2010 12:31:38 -0700

See below...

Mark Allman wrote:
> On the other hand, is this really *needed*?  No, absolutely not.

So then why bother? Are we in favor of just adding state and computation
to TCP?

Consider benefit vs the cost, where cost is not just state and
processing, but also specification complexity.

And it's useful to consider that this isn't the only such mod coming
down the pike. We just got done recommending random ephemeral ports. Now
we want random timestamp offsets. How much of this do we actually need,
and can we just keep it simple other than that?

> The

IMO, the threshold for changing TCP ought to be "do we absolutely need
it", not "absent big issues and seems reasonable".

Joe

---

From: Mark Allman <[email-masked]>
Date: Tue, 23 Mar 2010 15:43:11 -0400

Joe-

> it", not "absent big issues and seems reasonable".

I don't buy that bar.  Some of your work is not absolutely needed.
(Mine, too, BTW.)  Doesn't mean it isn't useful.

The "bar" is a fuzzy thing.  You don't find the cost-v-benefit for this
worthwhile.  Fine.  I assume the chairs are noting that.  Others find it
worthwhile.  I assume the chairs are noting that, as well.  So, lets
just---you and I---consider our points made.

allman

---

From: Mark Allman <[email-masked]>
Date: Tue, 23 Mar 2010 23:15:29 -0400

Folks-

Joe and I had a conversation (or something like that) off-list about
this draft.  Yeah, it was just as stupid as you can imagine given the
two principals.

I don't think either of our on-list comments were quite as precise as
perhaps they could have and I *think* we agree on something here.  Joe
will no doubt inform you of how wrong I still am.  In any case ...

This document really has two parts: (1) a mechanism that provides a
random starting point for timestamps based on a hash of the 4-tuple and
some secret sauce and (2) a mechanism for TIME-WAIT truncation based on
observed timestamps on subsequent connections involving the same
4-tuple.  However, these two items are really not related at all---other
than that they both involve timestamps.

It seems from our on- and off-list discussion that both of us find (2)
useful.  But, it doesn't depend on (1) at all.  Further, I believe we
both find (1) to be dubious (there seems to be not much security benefit
and there are concerns about storage & computation (more Joe's than
mine, but)).

So, a compromise proposal could be to take (2) as a work item and
jettison (1).  I personally would support a (2)-not-(1) document more
strongly than the current version.

Or, at least perhaps we could see more motivation for (1) that would
sway us to understanding the tangible benefit it offers.

In all seriousness, I believe this note accurately represents the
result of the discussion Joe and I had and both welcome his corrections
and apologize if I have mis-represented anything.

allman

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Mar 2010 01:11:24 -0300

> than that they both involve timestamps.

The relationship is that (2) needs timestamps that are
monotonically-increasing across connections. (1) provides a scheme that
complies with such requirement and that also has the good property that
it makes it hard for an off-path attacker to guess the timestamps in use
by victim connections.

> and there are concerns about storage & computation (more Joe's than

32 bits of additional state for each connection is such a big deal?

> sway us to understanding the tangible benefit it offers.

Using unpredictable values is acting pro-actively. If we, say, propose
to have a global counter for generating the timestamps, at some point
we'll be re-hashing the same type of discussion we've had for "in
window" attacks, but for TCP timestamps.

Actually, at least part of this discussion has already taken place:
there's a CERT advisory on predictable timestamps (I think I referenced
it in the I-D), and some implementations have chosen to trivially
randomize the timestamps (i.e., "just call "random()"), which does not
allow (2) to work - most likely because they didn't want predictable
timestamps, but didin't have any other option at hand.

Thanks,

---

From: Mark Allman <[email-masked]>
Date: Wed, 24 Mar 2010 09:09:06 -0400

Hi Fernando!

> monotonically-increasing across connections. 

Yep- we agree on that requirement.

> (1) provides a scheme that
> complies with such requirement 

Yep, it does.

But, (1) does not somehow uniquely address that requirement.

> and that also has the good property that it makes it hard for an
> off-path attacker to guess the timestamps in use by victim
> connections.

The question is whether this is really important or not.

> window" attacks, but for TCP timestamps.

Well, we can encase a whole lot of stuff in "be pro-active".  I don't
think thats the right touchstone at all.  E.g., wouldn't it be
pro-active to encode the user's favorite color (in RGB, say) in a TCP
option to make it even harder to mess with the connection?  If you want
to be so pro-active why are we not just saying every TCP connection
should use the auth option?  Or, IPsec?  I find the "be pro-active"
framing to be essentially a non-argument.  If the "problem" can't be
motivated with anything beyond "be pro-active" then it isn't much of a
problem it seems to me.

I seriously doubt we ever will do the re-hashing you're talking about:

(1) An off path attacker already has to throw a bunch of packets at some
    connection if it knows the 4-tuple---a big if.  E.g., about 42K
    packets if you assume a 100KB window.

(2) Assuming we both (i) use the entire ephemeral port range and (ii)
    make the choice of ephemerals unpredictable (per recommendation
    coming from TSVWG) an attacker now has to throw an enormous amount
    of packets at some connection.  E.g., assuming a 100KB window (which
    is bigger than we generally see) it would take 2.7 billion packets
    to exhaustively search the space---or, a mere 1.35 billion on
    average to muck with things.

(3) Using back-of-the-envelope math, sourcing SYNs at 1Gbps means it
    would take more than 500 seconds on average (i.e., to send the 1.35
    billion SYNs noted above) to find a connection assuming you knew one
    was going on and you knew three of the four elements of the 4-tuple.
    But, such long-lived connections are the very small exception, not
    the rule.  So, you're not even aiming for a stable target on the
    timescales on which you can reliably bring down a connection.  Even
    if you could gather 100x that capacity and reduce the time to 5
    seconds that is still longer than nearly all the connections.

    (And, thats a bunch of resources to expend on the "benefit" of
    hosing up one TCP connection.)

(4) And, yes, you could get lucky, but the odds are pretty long given a
    space of 2.7 billion.

So, to be clear, thats (1) knowing a 3-tuple, (2) using 1Gbps of sending
capacity, (3) assuming a generally large TCP window and (4) needing a
connection to last over 500 seconds before we can reliably cause
problems **for one TCP connection**.

So then, yeah, with timestamps you also have to pass the PAWS check on
top of all that and so its even harder.  And, if you can somehow find an
endhost's global clock then this reduces to the non-timestamp case.
But, if you can't then you have some additional shot in the dark.  But,
even without adding this additional variable I hope you can see my
skepticism and thinking that this adds basically nothing tangible to the
situation because the bar is already So Damn High.  Further, at some
point you have to just decide that if you are going to count on a
particular connection then you need to quit playing cat & mouse and
actually secure the connection.  I.e., really be pro-active.

> it in the I-D),

I can't find the reference in the I-D.  Can you provide it?  Perhaps
they have more substantive motivation that you are providing.

allman

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Mar 2010 13:22:07 -0300

Hi, Mark,

> But, (1) does not somehow uniquely address that requirement.

Agreed.

> The question is whether this is really important or not.

If the question is whether I think this is a vector that is currently
being exploited or that will be exploited in the near term, I fully
agree with you: I believe this is very unlikely.

However, 32 bits of additional "state information" doesn't look like a
big deal to me.  So my argument was (?) that would fail on the side of
unpredictable timestamps (i.e., this is so cheap....).  -- but please
see the end of this e-mail.

>> Using unpredictable values is acting pro-actively. If we, say, propose
[....]
> should use the auth option?  Or, IPsec?  

I guess two possible answers would be:
* They are not a local policy, such as this algorithm (you do need the
other side to cooperate to get TCP-AO or IPsec working)
* They're hard to deploy for the general case, in practice.

(But yes, I see your point)

> situation because the bar is already So Damn High.  

As mentioned above, I fully agree with you. For the most part, my take
is (was?) that the overhead needed for unpredictable timestamps is so
small that *I* would fail on the side of unpredictable timestamps.

That said, if we don't recommend the RFC1948-like scheme, one could
mention it as a "possible" approach ("MAY", or just an appendix with no
RFC2119 text... or well, completely remove it if the wg decides so). I'd
argue that the I-D should probably mention that if a global clock is
used, the initial value should be randomized at system boot time, so
that the system uptime is not leaked.

> they have more substantive motivation that you are providing.

It's "US-CERT Vulnerability Note VU#637934", available at:
https://www.kb.cert.org/vuls/id/637934 -- I realize that while it
discusses a timestamps-based vulnerability, it does not really discusses
predictable timestamps (sorry :-( ).

FWIW, re-reading this advisory caused me to re-analyze some of the
"timestamps randomization" stuff:

* While Section 4.2.2 of RFC1323 states some requirements for the
Timestamp Clock, receivers don't "enforce" these requirements. That is,
the timestamp will be considered valid if SEG.TSval >= TS.Recent. That
means that an attacker would need to try only two timestamps to guess a
"valid" one.
* So the timestamps don't really add much to the mitigation of off-path
attacks, and in that case, a global counter that is initialized at
system boot time with a random value would do.

(I guess that one could implement some type of "timestamps window", but
this *would* be unnecessarily complex. -- Just for curiosity sake, I'll
probably check the proposal that was made in 2005 (by Kacheong Poon?) to
use timestamps as a mitigation for off-path attacks, to figure out how
they used timestamps for this purpose).

Thanks!

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Wed, 24 Mar 2010 09:55:40 -0700

Hi, all,

Overall, I'll agree with what Mark posted below, except that I'm still
not sure this whole thing makes sense.

As per subsequent exchanges, the doc breaks into three separate issues:

	1) random starting timestamp
	2) monotonically increasing timestamp
		(required only per socket-pair)
	3) TIME_WAIT truncation

Note that #1 interferes with #2, because selecting a timestamp in the
high end of the number space could present problems in maintaining #2
over the long term for very busy hosts. However, let's put that aside
for now, since we can easily say "pick something in the low 1/2 of the
range)" to address that issue.

The issues with #1 being a protection have already been discussed.
Depending on how #1 is specified, there are varying implications.

The current spec for #1 requires:

	a- a hash per socket pair (e.g., on receipt of a SYN)

	b- larger retained state during TIME_WAIT

	c- retained state beyond TIME_WAIT (to enforce #2,
	since the timestamp start is per-socketpair)

(a) is expensive - 20 instructions per 32-bit word *in the critical
path*, or 520 instructions. Compare that to roughly 100-300 instructions
to process a TCP packet. You're more than doubling the cost for TCP
processing in just this one step; other steps (randomizing ISN, etc.)
make things worse. The only way around this is for everyone - client and
server - to keep per-socketpair timestamps around for a long time.

(b) is no big deal

(c), however, is huge. Busy servers already toss out TIME_WAITs early to
save space. There's very little reason to believe they'd keep
per-socketpair timestamps around to ensure monotonicity.

So let's expect that (c) won't happen. That means (a) requires
computation, which is bad.

The only way to recover this, AFAICT, is to claim that the
timestamp_start is selected by some arbitrary function, but reused
across connections. It can't - and doesn't need to be - per-connection
specific.

Take that out of the equation, and we get:

 timestamp = T() + secret_key

That's fast, ensures #2, and allows #3 without the need to retain state
even after TIME_WAIT is gone.

Since we don't need the F(socketpair) part, let's strip that out and
move on - and call this what it is:

	"Reducing TIME_WAIT using timestamps"

The randomization part is marginally useful, but not the most
significant part of this mechanism, IMO.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Mar 2010 15:13:32 -0300

Joe Touch wrote:

> over the long term for very busy hosts. 

I don't follow this. The timestamp clock can be initilized to a random
value. Once initilized, it's simply incremented as a counter. How does
this interfere with #2?

> However, let's put that aside

Timestamps are compared in the same way as sequence numbers, IIRC. So
you don't need to implement this "low 1/2" magic....

> 	b- larger retained state during TIME_WAIT

I don't follow "b". What's the additional state here? You just need to
keep TS.Recent, as RFC1323 already requires -- there's no additional state.

> 	since the timestamp start is per-socketpair)

I don't follow this one, either.

With the current I-D, timestamps are generated in the same way ISNs are
generated with RFC1948. So there's no requirement of "retained state
beyond TIME-WAIT state". Actually, this is the beuty of the RFC1948 scheme.

> server - to keep per-socketpair timestamps around for a long time.

Can you elaborate this statement a bit more?

> per-socketpair timestamps around to ensure monotonicity.

There's no need for that. Servers can still toss the TIME-WAIT state as
they currently do, with no harm.

> across connections. It can't - and doesn't need to be - per-connection

If the current proposed scheme (i.e., RFC1948-like) is used,
initialization doesn't matter: it's F() that provides the randomness.

If we recommend "a global timestamp shared by all connections", you just
initilize it to a random value at system boot time, just so that the
system uptime is not leaked. -- and that's it.

Thanks,

---

From: Mark Allman <[email-masked]>
Date: Wed, 24 Mar 2010 15:22:36 -0400

It seems to me we (Joe, you and I) have converged to viewing the
TIME_WAIT truncation business as worth a work item, but the need or
desire for unpredictable timestamps seems to not be worthwhile.
Truncation requires monotonically increasing timestamps across
connections to be somehow ensured.  Seemingly that is such a mundane
requirement that we don't have to wade into the particulars of it in
this document.  Is this summary reasonable?  And, if so, is that OK with
everyone else?

allman

---

From: Joe Touch <[email-masked]>
Date: Wed, 24 Mar 2010 12:58:32 -0700

Mark Allman wrote:
> this document.  Is this summary reasonable? 

I think so.

Joe

> And, if so, is that OK with
> everyone else?
> 
> allman
> 
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 26 Mar 2010 15:53:49 -0300

Hi, Mark,

>  this document.  Is this summary reasonable?  And, if so, is that OK 
> with everyone else?

As a result of our discussion, I think a possible way forward would be
for the doc to just require monotonically-increasing timestamps across
connections, and TIME_WAIT truncation (with RFC2119-language).

However, I think that an appendix (with no normative language) that
describes a few possible algorithms to achieve monotonically-increasing
timestamps might still be helpful/useful.

One might include in that appendix the trivial "global timestamps clock"
(with randomized initial value at system boot time) and the RFC1948-like
scheme. My rationale is that if we're requiring monotonically-increasing
timestamps, it would be helpful to at least mention possible approaches
(without any requirements or specific choice).

Some stacks already randomize timestamps (trivially....with random()
)(e.g., OpenBSD). And my take is that unless we offer them an algorithm
that generates unpredictable timestamps, they might not want to use the
predictable "global timestamp clock" approach. -- and I think it would
be best if everybody jumped into the "monotonically-increasing
timestamps" wagon, no matter whether they are predictable or not.

This is just me thinking out loud. -- If there's contention on the
timestamps generation thing, I have no problem with splitting the I-D,
and striping off the "timestamps generation algorithms" from the current
I-D.

Thoughts?

Thanks!

Kind regards,

---

From: Alexander Zimmermann <[email-masked]>
Date: Fri, 26 Mar 2010 19:41:23 +0000

Hi Fernando,

first of all, I didn't read your draft, so please apologizes my
maybe stupid remark.

I guess your algo. is not compatible with the timestamp generation
in RFC 4987 (3.6.  SYN Cookies). Right?

Should we mention that?

Alex

---

From: Fernando Gont <[email-masked]>
Date: Fri, 26 Mar 2010 17:31:26 -0300

Hi, Alexander,

> in RFC 4987 (3.6.  SYN Cookies). Right?

Actually, there's an interesting part to it:

What matters is that the client-side (i.e., the TCP performing the
active open) generates timestamps such that they are
monotonically-increasing across connections, as *those* are the
timestamps that are used for "recycling" connections that are in the
TIME_WAIT state.

The timestamp generation implemented by FreeBSD makes sense for the
server-side (the side implementing the extended SYN-cookies). Therefore,
both approaches can co-exist: i.e., clients could generate timestamps
such that they are monotonically-increasing (and thus allow the
recycling of connections in the TIME_WAIT state), while servers can
generate timestamps with the FreeBSD scheme, such that they allow for
extended SYN cookies.

Does this make sense?

P.S.: Yes, clearly, this would be worth noting... and in particular,
could be taken as a motivation for splitting the generation of
timestamps into a separate I-D.

Thanks so much for your comments!

Kind regards,

---

From: Alexander Zimmermann <[email-masked]>
Date: Fri, 26 Mar 2010 20:52:36 +0000

Hi Fernando,

thank you for clarification. I've got it.

Alex

---

From: Joe Touch <[email-masked]>
Date: Fri, 26 Mar 2010 16:49:59 -0700

Presuming this is the path forward, one issue that needs to be addressed:

	- what happens when one side assumes the timestamps are
	monotonically increasing, but they're not

As recent exchanges suggest, there are possible reasons why either side
might want to implement timestamps differently. In that case, it's might
not be realistic to assume monotonicity.

It's not appropriate to consider client/server roles here; the issue is
who shuts down the connection and thus holds the TIME_WAIT - that is
often the server, but need not be.

Overall, if this suggestion requires the TIME_WAIT side assume
properties of the other end, it may *require* a flag to ensure.

Given we're not talking about such a flag, the entire mechanism may be
moot as a result.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sat, 27 Mar 2010 01:14:20 -0300

Hi, Joe,

These are interesting points to be addressed/clarified. Thanks!

I will try to address these in the next rev of the document. --
Meanwhile, comments inline....

Joe Touch wrote:
> - what happens when one side assumes the timestamps are monotonically
> increasing, but they're not

Worst case scenario: the TIME_WAIT state cannot be recycled, and hence
the situation is no worse and no better than the current state of
affairs, namely:
a) The TIME_WAIT state is assasinated [RFC793], with the connection
request being rejected
b) The SYN segment is ignored, and thus the connection request times
out, or is accepted after future retransmissions of the SYN [RFC1337]

> As recent exchanges suggest, there are possible reasons why either
> side might want to implement timestamps differently. In that case,
> it's might not be realistic to assume monotonicity.

It's not really about assuming that timestamps are intentionally
monotonically-increasing. *If* they are, no matter whether that was by
choice or by chance, you can recycle the TCB.

*If* timestamps are monotonically-increasing, then you're sort of
assured that the aforementioned "heuristics" will work.

This parallels the processing of ISNs in the BSD hack (allowed by the
very RFC793). There are stacks that completely randomize the ISNs (e.g.,
OpenBSD). If the ISN of an incoming SYN is larger than the last SEQ seen
for a connection in the TIME_WAIT state, you recycle the TCB. If ISNs
are randomized, these heuristics may or may not kick in.

> It's not appropriate to consider client/server roles here; the issue
> is who shuts down the connection and thus holds the TIME_WAIT - that
> is often the server, but need not be.

What I meant is that the side more concerned with recycling TCBs in the
TIME_WAIT state is the server-side. And that the side that should
generate monotonically-increasing timestamps is the client-side.

You're right that which side remains in the TIME_WAIT state depends on
which side performs the "active close" (rather than on client vs.
server). But if it's the client TCB that remains in the TIME_WAIT state,
 the collision would not even occur, as it would be detected and avoided
by the client itself.

> properties of the other end, it may *require* a flag to ensure.

I believe this is unnecessary. The beauty of this "TIME_WAIT tossing"
things is that this is a local policy, that can be applied even without
agreement with the other side.

Clearly, for the sake of this policy, it's better if clients generate
timestamps such that they are monotonically-increasing across
connections. If the chances of TIME_WAIT tossing are reduced.

> Given we're not talking about such a flag, the entire mechanism may
> be moot as a result.

THe "TIME_WAIT tossing" thing is a local policy, rather than a
mechanism. If clients generate timestamps such that they are
monotonically-increasing they clearly contribute to the success of this
policy. That's it.

Again, the heuristics performed by BSD-derived kernels with the ISN of
incoming SYNs when there's a previous incarnation of the same connection
in the TIME_WAIT state.

Thanks!

Kind regards,

---

From: Christian Huitema <[email-masked]>
Date: Sat, 27 Mar 2010 04:30:33 +0000

> connections. If the chances of TIME_WAIT tossing are reduced.

What are the side effects if a computer reboots, keeps the same IP address, looses memory of the previous time stamps, and then tries to reestablish the previous connection?

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Sat, 27 Mar 2010 02:33:24 -0300

Hello, Christian,

Christian Huitema wrote:
>> Clearly, for the sake of this policy, it's better if clients
>> generate timestamps such that they are monotonically-increasing
>> across connections. If the chances of TIME_WAIT tossing are
>> reduced.
> 
> What are the side effects if a computer reboots, keeps the same IP
> address, looses memory of the previous time stamps, and then tries to
> reestablish the previous connection?

As per RFC 793, hosts must not establish new connections for a period of
2MSL after they boot (this is the "quiet time" concept defined in
RFC793). As a result, specs-wise, that scenario should never occur.

If a host does not comply with the "quiet time concept" (i.e.,
reality-based world), then:

* If the selected timestamp for the new connection is
monotonically-increasing wrt the last timestamp seen on the previous
incarnation of the connection, the TIME_WAIT state is tossed (i.e., the
"heuristics" kicks in).

* Otherwise, as explained in my previous response to Joe's post, the
connection request may time out or be rejected (i.e., this is no worse
than the current state-of-affairs without this policy).

i.e., I don't see any side-effects....

Thanks!

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Mar 2010 16:36:51 -0700

Hi, all,

Given how this issue has evolved, it might be useful to hold off on the
adoption decision to see the revised idea in its full context, i.e., in
a revision of the doc...

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 29 Mar 2010 22:18:14 -0300

> adoption decision to see the revised idea in its full context, i.e., in

I don't follow what you mean by "how this issue has evolved". Some
people asked for clarifications, and I have clarified those issues.

If you want this even with the tiny details, here's it:

* TCPs performing the active open should select timestamps such that
they are monotonically increasing across connections. -- This does not
mandate monotonically-increasng timestamps for TCPs that perform the
passive open, as they may be willing to implement the extended syn
cookies thing described a while ago by andre Opperman.

* Processing of incoming SYN segments is done according to what's
already in the I-D. Tihs has no bad side effect, no matter what the
timestamps generation algorithm at the remote TCP.

Please let's move on....

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Mar 2010 19:29:09 -0700

> people asked for clarifications, and I have clarified those issues.

The 03 draft focused on creating an algorithm that prevented guess-based
attacks.

The discussion, as far as I can tell, has focused on the most peripheral
part of 03 - the use of TS to cut TIME_WAIT.

IMO, that's a sufficient change that we're no longer considering a mere
evolution of 03. The title, abstract, and most of the discussion will
change.

Other points need to be addressed, notably:

	- are TS values already sufficiently monotonic, or is
	an alg needed?

	- is per-socketpair state needed to support monotonicity?

	- interaction with SYN cookies

	- corner cases (when not monotonic, whether that can be
	known, when it's supported on only one side, etc.)

	- whether this depends on knowing which end will close the
	connection first at SYN time

I don't feel discussion on the mailing list is sufficient to consider
the entirety of this proposal, and not just whether it's possible, but
whether it's necessary.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 30 Mar 2010 00:06:35 -0300

Joe,

> The 03 draft focused on creating an algorithm that prevented guess-based

No. Version -03 focuses on creating an algorithm such that timestamps
are monotonically-increasing. Another property of the algorithm is that
timestamps are hard to guess. Finally, the doc proposes an algorithm for
improved handling of SYN segments.

See the abstract. It's not a "protecting TCP against blid attacks via
tcp timestamps" at all.

> part of 03 - the use of TS to cut TIME_WAIT.

Peripheral? Please compare the length of Section 2 and Section 3. Most
of the I-D is about processing SYN segments, rather than about
generating timestamps.

> evolution of 03. The title, abstract, and most of the discussion will

I disagree. But won't continue arguing on this one. You have apposed to
this I-D since the thread was started. Hopefully the chairs have noted
that. But hey have also noted the rest of the people, that did support it.

> 	- are TS values already sufficiently monotonic, or is

What's "sufficiently monotonic"? There's no requirement for
monotonically-increasing timestamps across connections.

> 	- is per-socketpair state needed to support monotonicity?

Obviously not. It *is* useful for the algorithm currently proposed in
the I-D.

> 	- interaction with SYN cookies

Note sure what you mean. Obviously, if timestamps are "on", you can take
advantage of this. If not, no.

> 	known, when it's supported on only one side, etc.)

This has all been clarified.

> 	connection first at SYN time

I have already clarified this. It doesn't matter who ends-up closing the
connection.

> the entirety of this proposal, and not just whether it's possible, but

Joe, you have been opposed to this I-D, are opposed to this I-D, and
will be opposed to this I-D. Point taken.

Can the rest of us, if we agree, get some work done?

P.S.: Again, nobody is shipping the I-D for publication as an RFC. So
don't expect the I-D to be perfect at this point.

Thanks,

---

From: Mark Allman <[email-masked]>
Date: Mon, 29 Mar 2010 23:06:53 -0400

Catching up, I will chime in with three things ...

  - It still seems to me like we have pretty well converged that the
    draft's value is in terms of the TIME_WAIT truncation scheme.

  - My own opinion is that the draft can simply say "this scheme works
    best with monotonically increasing timestamps" and leave it at
    that.

    I.e., it isn't a strict requirement because the fall-back is just
    what we have without timestamps and if it were a strict requirement
    we'd have to think about flags and such.

    I.e., TCP implementers are smart folks who don't need RFC pages to
    define for them how to generate a monotonic sequence of timestamps
    and so my view is that doing so is useless detail.

  - I agree with Joe's note below that this discussion has led to an
    evolved understanding of the issues and what will be in the draft
    and it'd be nice to see either (a) a new draft from Fernando that we
    can adopt or at least (b) an outline from the chairs that sketches
    a WG document and its major components that can then be filled in by
    some editor.

allman

---

From: Fernando Gont <[email-masked]>
Date: Tue, 30 Mar 2010 00:12:29 -0300

Mark,

I can publish such a rev.

Will split the "timestamps generation" into a separate I-D, and will
address in the current draft those points that needed clarification, etc.

Thanks,
Fernando

Mark Allman wrote:
> ------------------------------------------------------------------------
>