Re: [tcpm] Some ideas building on draft-ietf-tcpm-fastopen-01

Yuchung Cheng <> Sun, 05 August 2012 22:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A23DC21F856D for <>; Sun, 5 Aug 2012 15:32:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.954
X-Spam-Status: No, score=-102.954 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B2G-4rGrXdbO for <>; Sun, 5 Aug 2012 15:32:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 193B121F8562 for <>; Sun, 5 Aug 2012 15:32:28 -0700 (PDT)
Received: by obbwc20 with SMTP id wc20so5516550obb.31 for <>; Sun, 05 Aug 2012 15:32:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=r5DoVVexWcAuIYCOBzqAcmXNPkAJHs0wPAOTpKipJNY=; b=SzoGGSD4DkdzC3dNuH7x8UEw0D7twy4WY4fMOxOeAfNPMBpG+r00XRE4kGXQ4Attgc KD5C4OTa8XkKViKLKOhxQKogRqDRESQk1oyfVLQKBH6rssW97qkp8hF0HMdoTsMveRwT InH8sdunpUFuR1s0SoqpfgV+atXOl4LbZcwplpnMghkdoHkLG4B0wFSMO21VGFuuA/2y cajTtMLDkyaFalA7QB0IqyI76m+VP894yRF+j/DnZPqyjcbjUgRqRrKjHnZxeznsXyUU 0w/lJWnB5wPUvRynKwYz83CEr78a0qvagzPgbIeC6FE+ws5y/CeZuS/eV/25NwcTL+o+ oFUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=r5DoVVexWcAuIYCOBzqAcmXNPkAJHs0wPAOTpKipJNY=; b=o0dbb5YpWHFFfn9kkTiLSfhplvGKB0Uo9YVWNPm4UadERFskiXejdhU7KeOyMi0Yw5 XW9Gim0bf5JQ158oJL3OUxZLAmE0HYZp8byGOMC1ix7MYPYitwYKbAYvJmyIgBh8Xd+L Esb8dzg874CAO9uWpoaNGf1nQYnci2vP/J8oGL5HxnSdcQCZK2p49a86/iUyeQeWuewE gUS0/14kGJUuZsZqDhP8nnWN9gRqxbQCwxsJg8VEuIjf+yoRZUdoM8dwTXObxgxmcyIG nULU78XvCVYAGeiL7cFdr91vKgRQxW0QyeUDRkI72rNsJxuzYqQY/xJ3Zmv3Kk7tKRUc 1Cog==
Received: by with SMTP id ls6mr16182571obc.36.1344205948533; Sun, 05 Aug 2012 15:32:28 -0700 (PDT)
Received: by with SMTP id ls6mr16182559obc.36.1344205948235; Sun, 05 Aug 2012 15:32:28 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 5 Aug 2012 15:32:08 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Yuchung Cheng <>
Date: Sun, 05 Aug 2012 15:32:08 -0700
Message-ID: <>
Content-Type: text/plain; charset="ISO-8859-1"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmaPqtBn/y3i8FVC6EnpOrbpGEzg1mmRkIsOYqtwEyXqF9yOfVIqZpAi8cUxhAotACghzr4lCZ846FFGs1c2JDNJ01li74WNp5EEhvJv5EdIx9nbqjXlP2YfkDbDXn1vkJoBLdAbyytFVDf4hlwW80kBuRmozXqZjzduJnGAukN/n5q0o9jWjsL2pdy2LsGNyjWV9Sc
Subject: Re: [tcpm] Some ideas building on draft-ietf-tcpm-fastopen-01
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 05 Aug 2012 22:32:35 -0000

Hi Bob,

Re-inst. our discussions during the meeting.

On Thu, Jul 26, 2012 at 10:19 PM,  <> wrote:
> Yuchung, Jerry, Sivasankar, Arvind,
> I liked this enough to want to work on improving it. I have a couple of
> proposals that occurred to me, which I've finally made time to write up.
> (I'll send editorial nits from reviewing the draft later)
> ==Proposal #1/ ==
> Fast Open Cookie Request MUST (SHOULD?) be on a FIN
> I believe it would be better for the reasons below if:
> * the client put a fast open cookie request in its FIN, not its SYN (whether
> or not the server has sent a FIN first).
> * Then the server can send the fastopen cookie on the FIN-ACK.
> * If the client times out waiting for a FIN-ACK, it just re-sends as usual.
> * If the server's FIN-ACK never arrives (perhaps because a middlebox has
> eaten it), the client just doesn't have a cookie for the next session and
> uses a 3WHS as normal.
> Note, only the Request would have to be on a FIN. The Fast Open Cookie
> itself would obviously still be on the SYN of subsequent connections. Then,
> when a subsequent connection finishes, it can refresh the cookie on its FIN,
> ready for another connection later.
> This solves a couple of potential problems with a fastopen request-response
> on the initial SYN exchange:
> a) A FIN-cookie sidesteps the risk of unpredictable delay of the very first
> SYN due to some middleboxes dropping new TCP options (any timeouts due to
> non-delivery don't hold up the session, which has already finished)
> b) Transports GETting typical Web pages could (ab)use the fastopen cookie on
> the SYN exchange by opening multiple TCP connections during the initial
> connection without each one suffering the delay of a 3WHS. This creates a
> perverse incentive to use multiple parallel connections, because you can get
> the same latency benefit as HTTP pipelining [Yoshifumi posed this problem
> some time ago].  If clients can only request a fastopen cookie on a FIN,
> they don't have this perverse incentive to not bother with pipelining.
> I have no evidence, but it seems intuitive that if the TCP option got
> through on the first FIN, it might be more likely to get through on the next
> SYN, altho I admit options on SYNs are looked at more closely by
> middleboxes.

Like Jerry's response, I also like your ideas of cookie in FIN to
mitigate middlebox drops.
But I don't think doing so will practically diminish parallel
connections, because
most other time it works better: this change only affects the (first) connection
to get cookies. I personally don't mind adding a MAY for cookie
exchange in FIN stage.

> ==Proposal #2/ ==
> Fastopen cookies (optionally) authenticate both the client's network address
> and the its knowledge of the TCP timestamp option on the segment carrying
> the server's cookie.
> I would like to propose that if the server TCP-timestamps the segment
> carrying its cookie, the client MUST use a timestamp option on the segment
> that starts the subsequent fast open, and in its timestamp echo field it
> must echo the timestamp sent with the earlier cookie. Then:
> i) the server can use the timestamp as part of the material for generating
> and validating the cookie and
> ii) the server can set an expiry_duration, and check whether the echoed
> timestamp is older than time(now) - expiry_duration.
> Reasoning:
> The draft currently says:
> "   3. The cookie expires after a certain amount of time. The reason is
>        detailed in the "Security Consideration" section. This can be
>        done by either periodically changing the server key used to
>        generate cookies or including a timestamp in the cookie.
> "
> Let's take each in turn:
> * Periodically changing the server key: Let's imagine the key changes every
> 30 min. Then all cookies issued in the last 30 mins stop being useful, even
> those just issued a second ago, or a minute ago, or 15 minutes ago...
> * Including a timestamp in the cookie. This is only useful if the timestamp
> is in the clear within the cookie, otherwise the server cannot use it to key
> the cookie. But a timestamp in the clear takes valuable bits away from the
> cookie, weakening its strength. This is unnecessary if there's already space
> for a timestamp option on the segment (which is very common).
> Security Considerations mentions only two ways a client can collect valid
> cookies from other hosts:
> i) compromising other hosts, or
> ii) (legally) taking over the lease of an IP address from a DHCP server.
> But there is a much more problematic third way:
> iii) sitting behind the same NAT as a neighbour (esp. a carrier-grade NAT
> serving thousands of clients), where the NAT uses a common IP address for
> many clients.
> As it stands, the cookie is only dependent on the client's network address.
> Binding a TCP timestamp option into the cookie as well adds a lot more
> entropy.
> With only the IP address for entropy, a client behind a NAT (or an attacker
> in control of a compromised host behind a NAT) can get its own (valid)
> cookie and use it in a brute-force spoof of numerous neighbouring clients -
> to either SYN-flood the server or launch a reflection attack on its
> neighbours by fast-opening loads of new TCP connections requesting large
> data items on behalf of its neighbours, bypassing the safety check of the
> 3WHS.
> In contrast, if a cookie depends on both the client's network address and
> server's timestamp, a cookie requested by a client behind a NAT will only be
> the same as a neighbours cookie served by the same server within the same
> clock tick.
> This doesn't stop attackers getting valid cookies from compromised hosts,
> but it does effectively prevent these more trivial attacks on neighbours.
I also like TS idea but I see two problems in proposal #2:
a) scale: servers need to remember the timestamps. NOTE: in our implementation,
   servers do not need to remember the cookie.

b) a change in TS RFC: SYN ECR value is not 0. Are Mr. firewalls ok with that?

> ==Proposal #3/ ==
> Special cookie values
> (A minor point compared to the two above)
> 4.1.2 Server Cookie handling
> "  Also note the server may want to use special cookie values, e.g.,
>    "0", for specific scenarios. For example, the server wants to notify
>    the client the support of TFO, but chooses not to return a valid
>    cookie for security or performance reasons upon receiving a TFO
>    request.
> "
> I suggest the server just returns the cookie option with length 2 and no
> cookie data, to show it supports the option, but chooses not to give a
Acked. I prefer so actually.

> cookie. Then the server doesn't have to run an extra 'if' test every time it
> generates a cookie, just to check the cookie doesn't collide with a special
> value.
> This would require the value of the cookie option request kind to be
> different from the cookie option kind. Otherwise a response meaning "cookie
> supported but empty" would be confused with a cookie request for the
> half-connection in the opposite direction.
> == Outstanding concern ==
> Similar to a concern of Joe Touch's and Richard Scheffeneger's: dividing up
> TCP implementations into ones with idempotent semantics and ones without.
> This confuses the simple applicability of TCP. We need to work on that - but
> manyana.
Great point. We MUST be more specific about that point in the next revision.

All and all thanks for reviewing our draft :)

> Bob
> [PS. Apologies if you already got this once - I've been 'experimenting' with
> my email]
> _______________________________________________
> tcpm mailing list