Subject: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 25 Oct 2013 12:20:35 +0000

Hi all,

The TCPM chairs believe that draft-ietf-tcpm-fastopen-05 addresses all comments received so far. This email therefore starts a working group last call running until ***November 10, 2013***.

IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen

There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-05

The intended status of the document is Experimental.

The document asks for IANA allocation of a new TCP option number. The chairs' understanding is that it is TCPM consensus to ask for IESG approval of such a codepoint allocation.

Please send any comments on the TCPM mailing list until November 10. Notifications of approving the current version (even without other comments) are helpful as well.

Thanks!

Michael
on behalf of the TCPM chairs

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 25 Oct 2013 13:11:37 +0000

As an individual contributor to the TCPM community, I have already suggested to the authors that the statement "(especially given the context of recent revelations)" from Section 6.3.2 should be removed prior to publication. I just want to share this small editorial suggestion with the list as well.

Thanks

Michael (as individual contributor)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Scharf, Michael (Michael)
> Sent: Friday, October 25, 2013 2:21 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05
> 
> Hi all,
> 
> The TCPM chairs believe that draft-ietf-tcpm-fastopen-05 addresses all
> comments received so far. This email therefore starts a working group
> last call running until ***November 10, 2013***.
> 
> IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-05
> 
> The document asks for IANA allocation of a new TCP option number. The
> chairs' understanding is that it is TCPM consensus to ask for IESG
> approval of such a codepoint allocation.
> 
> Please send any comments on the TCPM mailing list until November 10.
> Notifications of approving the current version (even without other
> comments) are helpful as well.
> 
> Thanks!
> 
> Michael
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Fri, 25 Oct 2013 15:50:25 -0700

> approval of such a codepoint allocation.

I don't recall that consensus. In fact, this document already has an 
EX-ID value:

0xF989      Fast Open Cookie/draft-ietf-tcpm-fastopen-03.txt

Why is that not sufficient at this time?

Joe

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 28 Oct 2013 09:48:12 +0000

Hi Joe,

> I don't recall that consensus. In fact, this document already has an

The request for an option number is in the draft since draft-cheng-tcpm-fastopen-00. As far as I recall, it has never been questioned. If I miss some discussion, please let me know.

Given that the document is out already for a long time, and has been discussed many times, I assume that the community is aware of that request and is fine with it. Yet, I explicitly mention this in the WGLC to be sure that this reflects what the community thinks. Comments and feedback is very welcome.

> Why is that not sufficient at this time?

I think this is the wrong question.

I am more interested in the question: Is there a possibility that TCP fast open will be deployed widely so that a 16bit value in the SYN is a waste of option header space? According to my knowledge, the community seems to find it useful in particular for TLS. But maybe the authors want to comment on that, too?

But I believe that the document could be updated with a brief explanation why the dedicated option codepoint is requested. It would probably be a good add-on to the current draft.

As a side note, TCP fast open would also be an opportunity to obtain operational experience with the transition from RFC 6994 to a dedicated codepoint. draft-ietf-tcpm-fastopen is one of the most prominent users of RFC 6994.

Michael

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Oct 2013 09:18:51 -0700

On 10/28/2013 2:48 AM, Scharf, Michael (Michael) wrote:
> The request for an option number is in the draft since
> draft-cheng-tcpm-fastopen-00.

The recommendation changed between 01 and 01 in mid 2012.

The previous request was for a new TCP option KIND, when there was no 
alternative other than to share the experimental ID without protection.

 > As far as I recall, it has never been
> questioned. If I miss some discussion, please let me know.

It has never been discussed either, and that's not what your note said. 
Lack of discussion is not consensus.

As this remains an Experimental doc, I do not support the use of a new 
TCP option KIND. If the extra two bytes are sufficient for testing, they 
ought to be sufficient until this can be reconsidered in the standards 
track.

Joe

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 28 Oct 2013 19:13:08 +0000

Hi,

Are we so constrained with tcp option space to be overly restrictive of allocating some of them to those who are openly engaging with the ietf in a proper ietf processes?

Doing the transition between draft (initial deployment expirience) and rfc would reduce the hassle later... 

And for this draft in particular, there seem to be strong arguments to use this for an entire class of connections.

Of course, these are non technical arguments...

Best regards,
   Richard

Von meinem iPhone gesendet

Am 28.10.2013 um 17:24 schrieb "Joe Touch" <[email-masked]>:

> The previous request was for a new TCP option KIND, when there was no alternative other than to share the experimental ID without protection.
> 
> It has never been discussed either, and that's not what your note said. Lack of discussion is not consensus.
> 
> As this remains an Experimental doc, I do not support the use of a new TCP option KIND. If the extra two bytes are sufficient for testing, they ought to be sufficient until this can be reconsidered in the standards track.
> 
> Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Oct 2013 13:07:18 -0700

> On Oct 28, 2013, at 12:13 PM, "Scheffenegger, Richard" <[email-masked]> wrote:
> 
> Hi,
> 

We should be. The current requirement is that they be standards track. 

> Doing the transition between draft (initial deployment expirience) and rfc would reduce the hassle later...

Or burn an option number if it is abandoned. 

Joe

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 28 Oct 2013 22:07:00 +0000

Hi Joe, all,

The current requirement is IESG approval *or* standards action. As far as I recall, the first variant was used e.g. for MPTCP. In that case, the final decision is up to the IESG, but I guess they will listen to the community to some extent.

Having said this, I am certainly interested in more feedback regarding the option codepoint assignment.

Michael

________________________________________
Von: Joe Touch [[email-masked]]
Gesendet: Montag, 28. Oktober 2013 21:07
An: Scheffenegger, Richard
Cc: Scharf, Michael (Michael); [email-masked]; [email-masked]
Betreff: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Oct 2013 15:14:16 -0700

> On Oct 28, 2013, at 3:07 PM, "Scharf, Michael (Michael)" <[email-masked]> wrote:
> 
> Hi Joe, all,
> 

I said the same thing for that - if we don't have the confidence for standards track, it's too early. IMO IESG action ought to be for de facto standards, not as an exception to IETF consensus. 

The decision for MPTCP partly was due to the lack on a viable alternative - which we have now. 

Joe

---

From: "Smith, Donald" <[email-masked]>
Date: Mon, 28 Oct 2013 23:35:57 +0000

This doesn't work.
Example Implementation: a simple implementation is to use AES_128 to
   encrypt the IPv4 (with padding) or IPv6 address and truncate to 64
   bits. The server can periodically update the key to expire the
   cookies. AES encryption on recent processors is fast and takes only 
   few hundred nanoseconds [RCCJR11].

   If only one valid cookie is allowed per-IP and the server can
   regenerate the cookie independently, the best validation process is
   to simply regenerate a valid cookie and compare it against the
   incoming cookie. In that case if the incoming cookie fails the check,
   a valid cookie is readily available to be sent to the client.

That would allow someone doing reflection attacks to spoof an syn wait a few seconds for the server to respond (which the attacker wouldn't see) but the attacker knows what src ip he used in the syn so he can generate the syn/ack with a correct TFO cookie.

And maybe I am missing something but this seems to have an extra step in it.

Performing TCP Fast Open in connection 2:

      TCP A (Client)                                    TCP B(Server)
      ______________                                    _____________
      CLOSED                                                   LISTEN

   #1 SYN-SENT       ----- <SYN=x,CookieOpt=C,DATA_A> ---->  SYN-RCVD

   #2 ESTABLISHED    <---- <SYN=y,ACK=x+len(DATA_A)+1> ----  SYN-RCVD

   #3 ESTABLISHED    <---- <ACK=x+len(DATA_A)+1,DATA_B>----  SYN-RCVD

   #4 ESTABLISHED    ----- <ACK=y+1>--------------------> ESTABLISHED

   #5 ESTABLISHED    --- <ACK=y+len(DATA_B)+1>----------> ESTABLISHED

I think you could skip 4 because 5 would be a valid ack so 4 shouldn't be required?

Just one example:
The server can periodically update the key to expire the cookies.

So that should be TFO_server_cookie_expiration (or something like that) and probably should be configurable by the users.

Next there are several timers defined or recommended but they weren't given names.
I find when working with vendors if you have a standard name for a tcp wait or time out value it helps a lot.

Beside the cookie, we RECOMMEND that the
   client caches the MSS and RTT to the server to enhance performance.

Just minor but RECOMMENDED is a key word but afaik RECOMMEND is not.
It could easily be rewritten 
"Besides the cookie, it is RECOMMENDED that ..."

This is just my first set of comments, based on a quick review. I believe there are more areas of concern but wanted to get these posted asap.

(coffee != sleep) & (!coffee == sleep)
 [email-masked]

From: [email-masked] [[email-masked]] on behalf of Scharf, Michael (Michael) [[email-masked]]
Sent: Friday, October 25, 2013 6:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05

Hi all,

Thanks!

Michael

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 28 Oct 2013 21:22:03 -0400

On 10/28/2013 6:14 PM, Joe Touch wrote:
> 
> 
>> On Oct 28, 2013, at 3:07 PM, "Scharf, Michael (Michael)"
>> <[email-masked]> wrote:
>> 
>> Hi Joe, all,
>> 
>> The current requirement is IESG approval *or* standards action. As
>> far as I recall, the first variant was used e.g. for MPTCP. In that
>> case, the final decision is up to the IESG, but I guess they will
>> listen to the community to some extent.
> 
> I said the same thing for that - if we don't have the confidence for
> standards track, it's too early. IMO IESG action ought to be for de
> facto standards, not as an exception to IETF consensus.
> 

Just to be clear, for MPTCP, the IESG approval route was taken,
and I (as a TSV AD at the time) asked that it *not* be approved
by the IESG until it was shown that the working group had
carefully considered the alternative and had shown that it
wouldn't work, and that an option number was needed in order to
deploy large-scale MPTCP "experiments" on the Internet, like the
group was chartered to do.

But it would be up to the current IESG, whether they want to
use that example as a precedent or not, and it would be a good
idea to check with the TSV ADs about their expectation.

-- 
Wes Eddy
MTI Systems

---

From: Kevin Lahey <[email-masked]>
Date: Tue, 29 Oct 2013 12:49:58 -0700

On Oct 28, 2013, at 1:07 PM, Joe Touch wrote:

> We should be.

I have expressed myself on this subject before, so I had planned to stay quiet this time.  But lest silence be taken as assent, I'll say it -- we should certainly allocate this option for Fast Open.

I have a few (mostly rhetorical) questions:

* How many TCP options can we define?
* How many have been defined?
* How many years have we been assigning TCP options?
* How soon does it seem likely that we'll run out?

Bonus questions:
* Are there any previously-assigned options available for reclamation?

I'm certainly open to learning more about why some people are concerned about allocating more options numbers, but I've yet to see a clear explanation (and RFC6994 does not seem to provide one).

Cheers,

Kevin
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Tue, 29 Oct 2013 13:12:45 -0700

> * How many TCP options can we define?

256 (0..255)

> * How many have been defined?

31

> * How many years have we been assigning TCP options?

In principle, since the introduction of TCP.

> * How soon does it seem likely that we'll run out?

That depends on whether old ones can be reused and whether squatted ones 
can be assigned.

> * Are there any previously-assigned options available for reclamation?

There might be as many as 9 of these (listing those obsolete for a long 
time),

A few more, IMO:

How many have been squatted?

10 (i.e., 1/3 more than have been assigned)

Are there any alternatives? (yes, there are now)

Is there a process for assigning them?

The primary one is *standards track*, with an exception as decided by 
the IESG. Exceptions should be rare and justified IMO; the last one 
involved MPTCP because there was no alternative and because there was so 
much squatting on the experimental codepoints; that situation has been 
resolved.

> I'm certainly open to learning more about why some people are
> concerned about allocating more options numbers, but I've yet to see a
> clear explanation (and RFC6994 does not seem to provide one).

The primary reason we have not had problems with over allocation is that 
the bar is intentionally high. That is a poor justification for lowering 
the bar.

The bar might be lowered if it involves reusing abandoned codepoints, 
and if the codepoint will be abandoned after 5-10 years (obsoleted) if 
the option is not in widespread use.

Joe

Joe

---

From: Kevin Lahey <[email-masked]>
Date: Tue, 29 Oct 2013 13:41:49 -0700

On Oct 29, 2013, at 1:12 PM, Joe Touch wrote:

> There might be as many as 9 of these (listing those obsolete for a long time),
> 
> A few more, IMO:
> 

I think that we would have no squatted numbers (or very few) if we made it reasonably easy to get a real number.  At the risk of repeating myself (and I'll stop after this), I really hate it when I see an option number in use, but don't have a way of finding out what it means.  (Wireshark seems very good at keeping up with this stuff, but it isn't very formal.)

> The primary reason we have not had problems with over allocation is that the bar is intentionally high. That is a poor justification for lowering the bar.
> 
> The bar might be lowered if it involves reusing abandoned codepoints, and if the codepoint will be abandoned after 5-10 years (obsoleted) if the option is not in widespread use.

I have seen talk about "terminating" experimental protocols, and putting a "not good after this date" on an option seems reasonable, if the option could be renewed with a later, non-experimental RFC.  I haven't seen any kernels that will carefully check the boot time to determine which TCP options to allow, so I'm not sure how exactly this kind of thing would be enforced.  Perhaps, "It's been five years since this was a valid option, I think we can reuse it now," would be enough.

Cheers,

Kevin
[email-masked]

[I certainly didn't intend to assign you homework, Joe -- I figured that most of us knew the answers to those questions.  But thanks for cheerfully answering them.]

---

From: Joe Touch <[email-masked]>
Date: Tue, 29 Oct 2013 15:29:36 -0700

> On Oct 29, 2013, at 1:12 PM, Joe Touch wrote:
...
> I think that we would have no squatted numbers (or very few) if we
> made it reasonably easy to get a real number.

Some of the squatters:

	- were participating in the standards process, and deployed code
	knowing full well it had not been agreed upon

	- choose not to even go through the IETF process

I.e., it's not just about the numbers being "hard to get". Some people 
don't want to go through process.

> At the risk of repeating
> myself (and I'll stop after this), I really hate it when I see an option
> number in use, but don't have a way of finding out what it means.

IANA keeps this info online for properly assigned codepoints. 
Recognizing squatters ends up defeating the assignment process IMO.

...
> I have seen talk about "terminating" experimental protocols, and
> putting a "not good after this date" on an option seems reasonable, if
> the option could be renewed with a later, non-experimental RFC. I
> haven't seen any kernels that will carefully check the boot time to
> determine which TCP options to allow, so I'm not sure how exactly this
> kind of thing would be enforced. Perhaps, "It's been five years since
> this was a valid option, I think we can reuse it now," would be enough.

If that's the case, why not use the ExID variant for that period?

Joe

---

From: Kevin Lahey <[email-masked]>
Date: Tue, 29 Oct 2013 17:26:12 -0700

On Oct 29, 2013, at 3:29 PM, Joe Touch wrote:

> I.e., it's not just about the numbers being "hard to get". Some people don't want to go through process.

I suspect that some of this has to do with how onerous we decide to make the process.  I see what you mean about there always being a few bad actors, though.

>> the option could be renewed with a later, non-experimental RFC. [...]

> If that's the case, why not use the ExID variant for that period?

There's a strict limit of 40 octets for TCP options (alas).  We shouldn't use two extra octets of that precious space when it's easy to avoid.  For all that, we haven't heard a peep from the authors of Fast Open, so perhaps I'll let it go at that, and see what they have to say for themselves (if anything).

Cheers,

Kevin
[email-masked]

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 30 Oct 2013 09:00:58 -0700

> There's a strict limit of 40 octets for TCP options (alas).  We shouldn't use two extra octets of that precious space when it's easy to avoid.  For all that, we haven't heard a peep from the author…

Who wouldn't want an option code point for an RFC he has worked over 4 years? :)

Is there an alternative? yes the current expid-format is.

Practically middle-boxes are probably more friendly to 254/255 than a new 147.

The real concern is as Kevein mentioned: it's taking an extra 16 bits
on the super tight SYN option space. Say TFO becomes popular and is
standardized after 3 years optimistically. We still have to support
both format for at least 5 years due to the slow implementation
upgrade cycle (so 8 years total). In the mean time if an important
feature is blocked by the extra 16 bit taken, it'd be unfortunate and
end up in an unpleasant solution. So maybe then the new feature would
qualify as "no other alternative".

So I care less about TFO option code point format as long as it works.
I care more about the overall SYN space usage. It'd be a shame we
can't run large experiment with experimental features together,
because what those experiments are for.

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Oct 2013 12:33:14 -0700

On 10/30/2013 9:00 AM, Yuchung Cheng wrote:
...
> Who wouldn't want an option code point for an RFC he has worked over 4 years? :)

Who shouldn't? Someone proposing an experimental extension, rather than 
a standards track one.

...
> qualify as "no other alternative".

That argument says we should never use the ExIDs. I don't buy it; 
anything that's so cramped that 2 bytes makes a difference is a problem 
anyway IMO.

> because what those experiments are for.

What are the other options you need to coexist with, and why does 2 
bytes make a difference?

Finally, your option formats already are likely not word-aligned. Most 
implementations burn those two bytes aligning the options on word 
boundaries *anyway*.

I.e., for this particular option, those two bytes are probably already 
overhead. Wny not use them for something productive?

Joe

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 30 Oct 2013 20:08:26 +0000

In the code I work with, options are padded to word boundaries, but ONLY if all the options to be
written can fit into the space.

Jakob.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: Wednesday, October 30, 2013 12:33 PM
To: Yuchung Cheng
Cc: [email-masked]; [email-masked]
Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-fastopen-05

Finally, your option formats already are likely not word-aligned. Most implementations burn those two bytes aligning the options on word boundaries *anyway*.

I.e., for this particular option, those two bytes are probably already overhead. Wny not use them for something productive?

Joe