Subject: [tcpm] Re: UTO: SHOULD send option in first segment after the SYN?

From: "Mahdavi, Jamshid" <[email-masked]>
Date: Sat, 14 Oct 2006 00:02:36 -0700

Fernando asked that I send my comments on this text back to the list.

> A host that supports the TCP User Timeout Option SHOULD include one
> in each packet that carries a SYN flag, but need not.  [MEDINA] has
> shown that unknown options are correctly handled by the vast majority
> of modern TCP stacks.  It is thus not necessary to require
> negotiation of the use of the TCP User Timeout Option during the
> three-way handshake of a connection.  However, including a TCP User
> Timeout Option in each segment that has the SYN flag set will result
> in TCP being able to adopt a user timeout with knowledge of that used
> by the peer TCP, since the beginning of the data transfer phase.

I think this paragraph is somewhat misleading.  I read the MEDINA reference, and it says that 0.2% of connections fail with unknown options on the SYN, while 3% of connections fail with unknown options (or unnegotiated timestamps) later in the connection.

While it technically correct to say "the vast majority", failing 3% of connections is pretty severe.  Furthermore, should an application choose to use a UTO in midconnection, and the connection fails, there is not much that the application can do about this.

MEDINA does not provide analysis as to the root cause of the 3% failures.  One could hypothesize that 3% of host operating systems exhibit the problem, or that 3% of routers / firewalls do, etc.  Should applications start choosing to use this option, it seems quite possible that users who experience failure would be unable to really do anything about the problem, short of switching from that application to a different one.

My original suggestion to Fernando was simply to clarify the risk in the text.  After discussing a bit I came to the conclusion that we probably should do more than just acknowledge the risk and instead try to reduce it.  The way to do this would be to do a SYN option negotiation, just like other features such as timestamps and SACK.  MEDINA has shown that this is an order of magnitude safer, and it allows for further remedies in the form of backing off of the option negotiation (within the stack) should there be a failure.  Together these would make such a solution significantly more robust.

It strikes me that one could draw an analogy between this and the Path MTU Black Hole problem.  That has ended up being a very annoying problem.  It seems to me (based on MEDINA) that this option could turn into a similar situation where connections mysteriously fail; doing our best to prevent that seems like a good idea. 

--J

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Fernando Gont <[email-masked]>
Date: Mon, 16 Oct 2006 04:16:39 -0300

Jamshid,

>My original suggestion to Fernando was simply to clarify the risk in 
>the text.  After discussing a bit I came to the conclusion that we 
>probably should do more than just acknowledge the risk and instead 
>try to reduce it.  The way to do this would be to do a SYN option 
>negotiation, just like other features such as timestamps and 
>SACK.  MEDINA has shown that this is an order of magnitude safer, 
>and it allows for further remedies in the form of backing off of the 
>option negotiation (within the stack) should there be a 
>failure.  Together these would make such a solution significantly more robust.

Given that there has been discussion about this issue on this mailing 
list, and the consensus had been to *not* require the option in the 
3WHS, my take take is:

* We will try to clarify this in the document (if you want to suggest 
text, that'll be more than welcome)
* I will keep an eye on the list to sense if there's consensus to 
change the document to require the option in the 3WHS (that was the 
original proposal, but there was consensus to change the draft as it 
currently is). Of course, if there's consensus to do so, we'll make the change.

Thanks for your feedback, and also for posting this on the mailing list!

Kindest regards,

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

---

From: "Caitlin Bestler" <[email-masked]>
Date: Mon, 16 Oct 2006 09:15:14 -0700

Mahdavi, Jamshid wrote:
>> shown that unknown options are correctly handled by the vast
>> majority of modern TCP stacks.  It is thus not necessary to require
>> in TCP being able to adopt a user timeout with knowledge of that
>> used by the peer TCP, since the beginning of the data transfer phase.
> 
> I think this paragraph is somewhat misleading.  I read the
> MEDINA reference, and it says that 0.2% of connections fail
> with unknown options on the SYN, while 3% of connections fail
> with unknown options (or unnegotiated timestamps) later in
> the connection.
> 
> While it technically correct to say "the vast majority",
> failing 3% of connections is pretty severe.  Furthermore,
> should an application choose to use a UTO in midconnection,
> and the connection fails, there is not much that the
> application can do about this.
> 
> MEDINA does not provide analysis as to the root cause of the
> 3% failures.  One could hypothesize that 3% of host operating
> systems exhibit the problem, or that 3% of routers /
> firewalls do, etc.  Should applications start choosing to use
> this option, it seems quite possible that users who
> experience failure would be unable to really do anything
> about the problem, short of switching from that application
> to a different one.
> 
> My original suggestion to Fernando was simply to clarify the
> risk in the text.  After discussing a bit I came to the
> conclusion that we probably should do more than just
> acknowledge the risk and instead try to reduce it.  The way
> to do this would be to do a SYN option negotiation, just like
> other features such as timestamps and SACK.  MEDINA has shown
> that this is an order of magnitude safer, and it allows for
> further remedies in the form of backing off of the option
> negotiation (within the stack) should there be a failure.
> Together these would make such a solution significantly more robust.
> 
> It strikes me that one could draw an analogy between this and
> the Path MTU Black Hole problem.  That has ended up being a
> very annoying problem.  It seems to me (based on MEDINA) that
> this option could turn into a similar situation where
> connections mysteriously fail; doing our best to prevent that
> seems like a good idea.
> 
> --J
> 

As currently proposed an implementation is always free to simply
ignore a UTO suggestion for any number of reasons, including not
having a convenient place to store the information due to internal
state issues.

We should not lose that. Your logic almost suggests that the
passive side MUST reject a connection with the UTO option if
it does not intend to honor it. In my opinion that wouuld be
a mistake.

---

From: "Mahdavi, Jamshid" <[email-masked]>
Date: Mon, 16 Oct 2006 09:28:37 -0700

You are arguing that the option should be advisory, meaning that it can
be ignored if the stack chooses to.  I wasn't trying to suggest
otherwise on that account.

I think there are two cases to consider:

(1) Both stacks are UTO capable, but one side chooses not to use it.  In
that case, if we were to use a SYN negotiation, the stacks would agree
they are capable, and then the applications can choose whether or not to
use the option with no unexpected results.

(2) A UTO capable stack is trying to use the option when talking to a
stack which is not UTO capable (or there is some middlebox which is not
UTO capable).  In this case, I was observing that, according to the
reference cited in the draft, 3% of such connections could mysteriously
die in the middle with no explanation and no way to recover.  I thought
this seemed pretty severe and desirable to avoid.

--Jamshid

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]] 
Sent: Monday, October 16, 2006 9:15 AM
To: Mahdavi, Jamshid; [email-masked]
Subject: RE: [tcpm] Re: UTO: SHOULD send option in first segment after
the SYN?

---

From: "Caitlin Bestler" <[email-masked]>
Date: Mon, 16 Oct 2006 09:41:27 -0700

Mahdavi, Jamshid wrote:
> You are arguing that the option should be advisory, meaning
> that it can be ignored if the stack chooses to.  I wasn't
> trying to suggest otherwise on that account.
> 
> (1) Both stacks are UTO capable, but one side chooses not to
> use it.  In that case, if we were to use a SYN negotiation,
> the stacks would agree they are capable, and then the
> applications can choose whether or not to use the option with no
> unexpected results. 
> 
> (2) A UTO capable stack is trying to use the option when
> talking to a stack which is not UTO capable (or there is some
> middlebox which is not UTO capable).  In this case, I was
> observing that, according to the reference cited in the
> draft, 3% of such connections could mysteriously die in the
> middle with no explanation and no way to recover.  I thought

The failure of existing implementations to properly handle
old requirements is hardly a justification for creating a
new one.

If we are going to design around faulty handling of options
we would do so by limiting new options for truly emergency
level problems that could be solved no other way.

UTO clearly does not meeet that. But as an *advisory*
signal from peer to peer it may be worthwhile.

I am particularly concerned with adding any requirement
for retention of more stateful data in a response to
an unconfirmed SYN. And I don't believe that rejecting
all connection requests that include a UTO is much of
an option, since any stack could easily support the extra
data *after* the existence of the remote peer is confirmed.

Increasing the amount of data kept about a alledged peer
is not a good idea.

If you want to require that anyone who intends to ever
use a UTO MUST send it in the SYN, I would not have
an objection. But if you intend to require that a later
UTO MUST be rejected if it was not negotiated at connection
setup then you are increasing the amount of stateful data
that must be kept from the receipt of the first SYN.

---

From: "Mahdavi, Jamshid" <[email-masked]>
Date: Mon, 16 Oct 2006 09:51:51 -0700

> that must be kept from the receipt of the first SYN.

I was thinking more the former than the latter, but even that may have
implementation problems if you are trying to do it without remembering
anything.  (The goal being that one SHOULD NOT send a UTO if the peer
did not say he supports it on the handshake.)

I'm not deeply attached to making a substantive change here; my main
point is that the text as currently written claims pretty strongly that
it is safe to do this in mid-connection, and I think that is inaccurate
and misinterprets the data in MEDINA.  It would certainly fair to say
something like, "while research has shown that 3% of such connections
can fail, these failures do not follow existing requirements and don't
warrant taking special measures to ensure perfect robustness."

--J

---

From: Fernando Gont <[email-masked]>
Date: Fri, 20 Oct 2006 12:37:20 -0300

Jamshid,

Thanks again for your comments. Please let me know if the changes 
bellow address your comments....

>warrant taking special measures to ensure perfect robustness."

The third paragraph of Section 3 would change to:

"A host that supports the TCP User Timeout Option SHOULD include one
in each packet that carries a SYN flag, but need not.  [MEDINA] has
shown that unknown options are correctly handled by the vast majority
of modern TCP stacks.  while research has shown that 3% of such connections
can fail, these failures do not follow existing requirements and don't
warrant taking special measures to ensure perfect robustness. Therefore,
negotiation of the use of the TCP User Timeout Option during the three-way
handshake is not required.  However, including a TCP User Timeout Option
in each segment that has the SYN flag set will result in TCP being 
able to adopt a user
timeout with knowledge of that used by the peer TCP, since the
beginning of the data transfer phase."

And the first paragraph of Section 4.1 would change to:

"   The large number of middleboxes (firewalls, proxies, protocol
    scrubbers, etc.) currently present in the Internet pose some
    difficulty for deploying new TCP options.  Some firewalls may block
    segments that carry unknown options, preventing connection
    establishment when the SYN or SYN-ACK segment contain a TCP User
    Timeout Option, or causing established connections to fail when an
    unknown option is transmitted during the life of a connection.
    Some recent results, however, indicate that for new TCP options,
    this may not be a significant threat, with only 0.2% of web
    requests failing when carrying an unknown option, and only 3% of
    established connections failing when an unknown TCP option is
    transmitted during the life of a connection [MEDINA]."

Please let me know if this addresses your feedback.

Kindest regards,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 20 Oct 2006 12:58:37 -0300

Caitlin,

In response to your feedback I added a new paragraph to Section 3 of 
the document:

"   A host that supports the TCP User Timeout Option SHOULD include one

    Aditionally, a hosts that supports the TCP User Timeout option SHOULD
    include one in the first packet that does not have the SYN flag set.
    This helps to minimize the amount of state information a TCP must keep
    for connections in non-synchronized states, and is particularly useful
    when mechanisms such as "SYN cookies" [Bernstein] are implemented,
    allowing a newly-established TCP conenction to benefit from the information
    advertised by UTO option, even if the UTO contained in the initial SYN
    segment was not recorded.

    A host that supports the TCP User Timeout Option SHOULD include it in
    the next possible segment to its peer whenever it starts using a new
    user timeout for the connection.  This allows the peer to adapt its
    local user timeout for the connection accordingly."

(The first and last paragraph are included for reference. Only the 
second one has been added).

Please let me know if you think this change addresses your feedback. 
If it doesn't, you may suggest some text.

Thanks!

Kindest regards,

---

From: "Mahdavi, Jamshid" <[email-masked]>
Date: Sat, 21 Oct 2006 09:28:08 -0700

Some tweaks:

- "but need not" seems contradictory.  SHOULD has a 
  meaning which is clear.
- I hate using references as parts of speech, so I 
  reworked the sentences about the Medina reference some.
- I separated the paragraph into two, one covering the concept 
  of getting an early value, and a second discussing why we 
  don't do negotiation and including the Medina reference.
  Looking at the whole flow of this section, we could move this
  second paragraph down into the paragraph that already 
  references RFC1122 since I think these naturally fit together.

Here are the two rewritten paragraphs:

A host that supports the TCP User Timeout Option SHOULD include one
in each packet that carries a SYN flag.  The presence of this option
is not a negotiation of the capability, but simply an advisory message
specifying the currently preferred user timeout value.  This allows
TCP to adopt a user timeout with knowledge of that used by the peer TCP 
from the very beginning of the data transfer phase.

...

A TCP implementation that does not support the TCP User Timeout
Option MUST silently ignore it [RFC1122], thus ensuring
interoperability.
In a study of the effects of middleboxes on transport protocols, Medina 
has shown that unknown TCP options are correctly handled by the vast 
majority of modern TCP stacks [MEDINA].  In this study 3% of 
connections failed when an unknown TCP option appeared in the middle of 
a connection.  Because these failures violate existing requirements to 
ignore unknown options, they do not warrant taking special measures to 
handle these cases.  In particular, we do not define a separate mechanism 
to negotiate support of the TCP User Timeout Option on the 
three-way handshake.

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]]
Sent: Fri 10/20/2006 8:37 AM
To: Mahdavi, Jamshid; Caitlin Bestler; [email-masked]
Subject: RE: [tcpm] Re: UTO: SHOULD send option in first segment after  the SYN?
 
Jamshid,

Kindest regards,