TCP Fast Open
draft-ietf-tcpm-fastopen-10

Note: This ballot was opened for revision 09 and is now closed.

Barry Leiba Yes

Comment (2014-08-13 for -09)
No email
send info
I think this is a Truly Fine thing to experiment with, and I'm very eager to see more deployment of it.

I have a number of comments about the document.  None of these are blocking, but some of them are quite significant and I urge you to consider them and to chat with me about them if it will help.  Thanks.

To the document shepherd: thanks especially for the detailed answer to question 9 in the shepherd writeup.

-- Section 4.1.1 --
You talk about two options (Fast Open Cookie and Fast Open Cookie Request), but they're really the same option, so that's a little confusing.  To make it more confusing, the document at least once refers just to a "Fast Open option".

I suggest that you consistently refer to this as the "Fast Open Option" throughout the document, and say that a Fast Open request is made using a Fast Open Option with a length of 2, and a Fast Open cookie is sent using a Fast Open Option with a length greater than 2.  I think this will make things much more consistent, and clearer.

-- Section 4.1.2 --

   The server is in charge of cookie generation and authentication. The
   cookie SHOULD be a message authentication code tag with the following
   properties:

Why "SHOULD"?  What might be a reason for a server not to do this?

-- Section 4.1.3 --
Please expand "MSS" on first use.

The "RECOMMEND" in the second paragraph doesn't appear to be a protocol requirement, and should probaby be lower case, not a 2119 key word.

   In particular it's known an IPv4 receiver
   advertised MSS less than 536 bytes would result in transmission of an
   unexpected large segment.

I can't parse that.  Can you rephrase, please?

In general, this section has quite a number of English problems that would benefit from a quick editing pass by a native speaker.

-- Section 4.2.1 --
Is the double "SHOULD" in bullet 2 really what you want?  It seems to me that what this means to say, 2119-wise, is that when the server responds with a SYN-ACK, the SYN-ACK SHOULD [be set up as specified].

The last two paragraphs seem out of place here.  I suggest putting them into a new Section 4.2.1.1, clearly labelled as an alternative solution that could be explored if problems develop with this one.  Or perhaps even put this into the "related work" section (currently Section 8, but see my comment below).

-- Section 4.2.2 --

   5. Send the SYN-ACK packet. The packet MAY include a Fast Open
      Option.

Doesn't that MAY conflict with the SHOULD that I complain about above, in Section 4.2.1 ?

-- Section 6 --
I think the "i.e." here is not correct, and that you mean "e.g."  (This is one reason I recommend that people avoid using these Latin abbreviations.)

-- Section 6.3.1 --

   Although not all GET requests are idem-potent

Really?  According to RFC 7231, Sections 4.2.2 and 4.2.1, GET is an idempotent method.

RFC 7231, Section 4.2.2:
   Of the request methods
   defined by this specification, PUT, DELETE, and safe request methods
   are idempotent.

RFC 7231, Section 4.2.1:
   Of the request methods defined by this specification, the GET, HEAD,
   OPTIONS, and TRACE methods are defined to be safe.

And "idempotent" is one word, not hyphenated; please fix that here and in Section 6.3.3.

-- Section 6.3.2 --
What does this section have to do with this spec?

-- Section 7.1 --

   Further study is required to
   evaluate the performance impact of these malicious drop behaviors.

It may work against this protocol, but is there actually evidence that there's malicious intent here?  If not, I would avoid describing it as "malicious".  Dropping the word (if not the packets) seems like the right thing.

   Another interesting study is the (loss of) TFO performance benefit
   behind certain carrier-grade NAT.

Why the parentheses?  Shouldn't it just be "the loss of TFO performance benefit", without the parens?

-- Section 7.2 --

   The implementation can provide an experimental feature
   to allow zero length, or null, cookies as opposed to the minimum 4
   bytes cookies. Thus the server may return a null cookie and the
   client will send data in SYN with it subsequently.

Haven't you cut yourself off here by using a zero-length cookie to mean a cookie request?  How would this work?

-- Section 8 --
A very small point: I would make this an Appendix, rather than a mainline section.

(Martin Stiemerling) Yes

(Jari Arkko) No Objection

(Richard Barnes) No Objection

Comment (2014-08-20 for -09)
No email
send info
It may be worth noting for completeness that a server could implement a scheme where cookie values are entirely random, with state stored on the server.  And also worth noting the (many) reasons that this is a bad idea.

In section 4.1.2, I would expand the second property to note that this implies that the cookie must be generated with a cryptographic operation using a secret key specific to the server, such as encryption, MAC, or signature.

Alissa Cooper No Objection

Comment (2014-08-20 for -09)
No email
send info
Glad this has been documented.

(Spencer Dawkins) No Objection

Comment (2014-08-18 for -09)
No email
send info
Please do consider Barry's questions - I'm not repeating them, but I had several of them myself.

For Martin: this specification points out that TFO can be used to speed up TLS (piggybacking on the SYN exchange). Is it obvious whether TCPINC could also use TFO?

(Adrian Farrel) No Objection

Comment (2014-08-20 for -09)
No email
send info
Thanks for bringing this forward as Experimental. Thanks also for Section 7 which is really helpful.

(Stephen Farrell) No Objection

Comment (2014-08-18 for -09)
No email
send info
general: would this work with CGAs? I guess, only for a short
while, but that's probably ok for consenting peers, right?
Presumably not worth a mention.

possible new security consideration: if an application
supports TFO and might include sensitive data in the SYN
(think cookies) then this seems to provide a new and slightly
more efficient way to steal that sensitive data. I don't
think this is worth noting to be honest, but raise it just in
case you do. I think the bad actor here has to write less
code maybe compared to the situation without TFO.

6.3.4 - I wondered how TFO would affect page load times if
all links are accessed via TLS. Any info on that?

The author affiliations on page 1 don't quite match those at
the end.

The secdir review [1] noted some nits and was ack'd but I
think the nits are maybe still there (one anyway).

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg04708.html

(Brian Haberman) No Objection

Comment (2014-08-18 for -09)
No email
send info
I agree with Barry that this a useful experimental document.  I have a few things for the authors/WG to consider as a part of this experimentation.

1. How does this functionality work in the presence of an anycast IP address for the server?

2. Are there functional changes needed to work with load balancers?

(Joel Jaeggli) No Objection

(Ted Lemon) No Objection

(Kathleen Moriarty) No Objection