Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt

From: [email-masked]
Date: Sat, 18 May 2013 08:57:53 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF.

	Title           : TCP Extensions for High Performance
	Author(s)       : David Borman
                          Bob Braden
                          Van Jacobson
                          Richard Scheffenegger
	Filename        : draft-ietf-tcpm-1323bis-13.txt
	Pages           : 46
	Date            : 2013-05-18

Abstract:
   This document specifies a set of TCP extensions to improve
   performance over paths with a large bandwidth * delay product and to
   provide reliable operation over very high-speed paths.  It defines
   TCP options for scaled windows and timestamps.  The timestamps are
   used for two distinct mechanisms, RTTM (Round Trip Time Measurement)
   and PAWS (Protection Against Wrapped Sequences).

   This document updates and obsoletes RFC 1323.

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

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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-1323bis-13

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 20 May 2013 12:13:31 -0700

I suggest removing all these texts;

"""If a non-<RST> segment is received without a TSopt, a TCP MAY drop
the segment and send an <ACK> for the last in-sequence segment.  ""
What's the point to ignore a perfectly fine data packet w/o TS-opt and
respond a (DUP)ACK? the sender is probably may trigger fast recovery
falsely. Responding ACKs is not going to make any forward progress  on
buggy implementations or middle-boxes.

""" A TCP MUST NOT abort a TCP connection if a non-<RST> segment is
received without a TSopt. """
TCP should abort only if it's truly in trouble. so let's not
re-emphasize the general rule of trying to keep things going until the
last minute.

"""If a TSopt is received on a connection where TSopt was not
negotiated in the initial three-way handshake, the TSopt MUST be
ignored and the packet processed normally.""" there was an RFC that
states this general rule already?

"""   In the case of crossing <SYN> segments where one <SYN> contains
a TSopt and the other doesn't, both sides MAY send a TSopt in the
<SYN,ACK> segment. """ The prior text on SYN already covers this.

In general I found section 3 has redundant MUST/SHOULD/MAY terms. An
RFC should be parsimonious on these terms so implementer can focus on
key rules.

On Sat, May 18, 2013 at 8:57 AM,  <[email-masked]> wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 May 2013 13:10:10 -0700

> re-emphasize the general rule of trying to keep things going until the

The text currently says:

    Once TSopt has been successfully negotiated (sent and received)
    during the <SYN>, <SYN,ACK> exchange, TSopt MUST be sent in every
    non-<RST> segment for the duration of the connection, and SHOULD be
    sent in a <RST> segment (see Section 4.2 for details).  If a non-
    <RST> segment is received without a TSopt, a TCP MAY drop the segment
    and send an <ACK> for the last in-sequence segment.  A TCP MUST NOT
    abort a TCP connection if a non-<RST> segment is received without a
    TSopt.

This wording leaves a few ambiguities:

- The first MUST implies some sort of uniform non-RST non-TSopt 
processing, but the rest of the paragraph doesn't provide it.

- The last sentence implies that receipt of a RST non-TSopt could cause 
an abort because of the lack of TSopt; it is because 'abort' is the 
consequence of processed RST.

I suggest clarifying this as:

    Once TSopt has been successfully negotiated (sent and received)
    during the <SYN>, <SYN,ACK> exchange, TSopt MUST be sent in every
    non-<RST> segment for the duration of the connection, and SHOULD be
    sent in a <RST> segment (see Section 4.2 for details).  If a non-
    <RST> segment is received without a TSopt, a TCP MUST drop the
    segment
    and MAY also send an <ACK> for the last in-sequence segment.
    A TCP MUST NOT abort a TCP connection because any segment lacks
    an expected TSopt.

Joe

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 22 May 2013 16:35:13 -0700

On Mon, May 20, 2013 at 1:10 PM, Joe Touch <[email-masked]> wrote:
> - The first MUST implies some sort of uniform non-RST non-TSopt processing, but the rest of the paragraph doesn't provide it.
>
> - The last sentence implies that receipt of a RST non-TSopt could cause an abort because of the lack of TSopt; it is because 'abort' is the consequence of processed RST.
>
I like Joe's text better

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 23 May 2013 14:09:26 +0000

Thank you Yuchung!

I have submitted an update with the text clarification from Joe!

Richard Scheffenegger

> On 5/20/2013 01:35 PM, Yuchung Cheng wrote:
> >

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 24 May 2013 09:57:28 +0200

Joe, Yuchung,

>     sent in a <RST> segment (see Section 4.2 for details).

I fail to see the rationale for forcing a TCP connection to always send 
the TSopt in every segment. The timestamp aids to estimate the rtt and 
provides PAWS for long connections. Given the size of the TCP option 
space, we should not force the utilisation of the TSopt in all segments. 
Consider a TCP implementation that supports SACK, RFC1323 and TCP-AO or 
Multipath TCP. When this implementation sends an ACK segment that 
contains a SACK, is it better to encode a long SACK block or to use 
option space to encode a timestamp ? I'd vote for providing a timestamp 
from time to time and reporting accurate SACK blocks.

 > If a non-

Dropping segments that do not contain the TSopt is excessive. There are 
on the Internet middleboxes that coalesce or split segments. While doing 
that, they may remove options. Dropping a segment because it does not 
contain the TSopt which is only informative appears overkill to me. 
Dropping a segment that does not contain the negotiated TCP-AO option 
makes sens, but not for the TSopt.

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 24 May 2013 09:05:29 +0000

Hi Olivier,

> Multipath TCP. When this implementation sends an ACK segment that contains
> a SACK, is it better to encode a long SACK block or to use option space to
> encode a timestamp ? I'd vote for providing a timestamp from time to time
> and reporting accurate SACK blocks.

We have been there; the interaction of multiple options used together was specifically stripped from this update. And randomly sending TSopt or not would break mechanisms like PAWS (and there might be others reliant on TSopt) - see below.

In that particular example you give, that implementation should choose to either limit TCP-AO to consume at most 20 bytes (to allow for 1 SACK block; the semantics of SACK will provide the most "important" blocks repeatedly), or to not use TSopt at all - still limiting TCP-AO to use no more than 32 bytes to allow for a single SACK block...

> Dropping segments that do not contain the TSopt is excessive. There are on
> the Internet middleboxes that coalesce or split segments. While doing

When TS is in use, the receiver will use the PAWS mechanism. Effectively, the TS becomes an extension of the sequence number. Accepting segments without TS could be seen like accepting a segment, where some (arbitrary) number of MSB bits in the sequence number are masked, and the remaining bits found to "probably" fall within the current window...

A middlebox should not strip TSopt if it ever let TSopt through. That is mentioned in section 6, but perhaps your view is that this is not emphasized enough? If a middlebox does remove TSopt any any non-<SYN>-only segment, it is broken and should be removed from the network.

If a middlebox chooses to split TCP segments (rather than IP packets), it needs to properly deal with TSopt too - putting that option, unaltered, in all the fragments created. If it doesn't, it is broken and should be removed.

One way of "motivating" the retirement of broken stuff is to point them out. 

Do you have any recent example of a broken middlebox that does not deal properly with TSopt?

Richard

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 24 May 2013 11:04:45 -0700

On Fri, May 24, 2013 at 12:57 AM, Olivier Bonaventure
<[email-masked]> wrote:
> I fail to see the rationale for forcing a TCP connection to always send the
> TSopt in every segment. The timestamp aids to estimate the rtt and provides
> PAWS for long connections. Given the size of the TCP option space, we should
> not force the utilisation of the TSopt in all segments. Consider a TCP
> implementation that supports SACK, RFC1323 and TCP-AO or Multipath TCP. When
> this implementation sends an ACK segment that contains a SACK, is it better
> to encode a long SACK block or to use option space to encode a timestamp ?
> I'd vote for providing a timestamp from time to time and reporting accurate
> SACK blocks.
>
>
>
>> If a non-
> the Internet middleboxes that coalesce or split segments. While doing that,
> they may remove options. Dropping a segment because it does not contain the
> TSopt which is only informative appears overkill to me. Dropping a segment
> that does not contain the negotiated TCP-AO option makes sens, but not for
> the TSopt.

These are good points. Olivier are you suggesting to change MUST to SHOULD of
these two statements?
1.  TSopt MUST be sent in every non-<RST> segment
2. ... received without a TSopt, TCP MUST drop the segment

Richard: I do see middle-boxes (or receiver!) corrupt TS options, unfortunately.

---

From: Joe Touch <[email-masked]>
Date: Fri, 24 May 2013 11:38:26 -0700

FWIW, I was not opening any new issues; I was clarifying the text only. 
I don't believe my new text changes any of the meaning from the previous 
intended version; IMO it only better handles ambiguities.

We discussed the reason for these requirements before.

Joe

---

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 27 May 2013 13:19:25 +0300

On May 24, 2013, at 10:57 AM, Olivier Bonaventure <[email-masked]> wrote:

> I fail to see the rationale for forcing a TCP connection to always send the TSopt in every segment. The timestamp aids to estimate the rtt and provides PAWS for long connections. Given the size of the TCP option space, we should not force the utilisation of the TSopt in all segments. Consider a TCP implementation that supports SACK, RFC1323 and TCP-AO or Multipath TCP. When this implementation sends an ACK segment that contains a SACK, is it better to encode a long SACK block or to use option space to encode a timestamp ? I'd vote for providing a timestamp from time to time and reporting accurate SACK blocks.

Always including TSopt seems to represent the rough consensus of the WG, even if it might not be a uniform agreement. This was discussed quite extensively some time ago. (Though judging rough consensus from Emails is difficult... we'd need some sort of electronic hum tool :-)

About your question: if you believe Multipath TCP is going to be useful for you, then it might be a reasonable choice to just disable timestamps entirely to make room for MPTCP and SACK, assuming the current work-in-progress spec. What do current MPTCP implementations do about this, by the way?

However...

> Dropping segments that do not contain the TSopt is excessive. There are on the Internet middleboxes that coalesce or split segments. While doing that, they may remove options. Dropping a segment because it does not contain the TSopt which is only informative appears overkill to me. Dropping a segment that does not contain the negotiated TCP-AO option makes sens, but not for the TSopt.

MUST drop all (non-RST) segments without timestamp seems indeed excessive, and not very liberal in what you are accepting [RFC793]. Why is this needed? I don't see why "MUST be sent" on the sending side should imply "MUST drop" on the receiving side.

In the worst case this might discourage enabling timestamps at all, if an implementation wants to be safe against middleboxes as described.

- Pasi

---

From: Christoph Paasch <[email-masked]>
Date: Mon, 27 May 2013 16:53:37 +0200

Hello,

On Mon, May 27, 2013 at 01:19:25PM +0300, Pasi Sarolahti wrote:
> On May 24, 2013, at 10:57 AM, Olivier Bonaventure
> Always including TSopt seems to represent the rough consensus of the WG,
> even if it might not be a uniform agreement. This was discussed quite
> extensively some time ago. (Though judging rough consensus from Emails is
> difficult... we'd need some sort of electronic hum tool :-)
> 
> About your question: if you believe Multipath TCP is going to be useful
> for you, then it might be a reasonable choice to just disable timestamps
> entirely to make room for MPTCP and SACK, assuming the current
> work-in-progress spec. What do current MPTCP implementations do about
> this, by the way?

the Linux Kernel implementation of MPTCP reduces the number of SACK-blocks
per packet, if the MPTCP-options need more space.

As we add an MPTCP DATA_ACK in each packet, if timestamps are enabled we
will set a maximum of 2 SACK-blocks per packet.

But this can probably be changed as described in Appendix A of RFC 6824.

Cheers,
Christoph

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 27 May 2013 15:23:53 +0000

Thanks,

I think Sally Floyd showed more than a decade ago, that the importance of subsequent SACK blocks (after the first) diminishes exponentially...

As long as there is room for one SACK block, SACK will work. The 2nd, 3rd... block will only add redundant information in case of ACK loss, but that information itself will be repeated eventually in the 1st SACK block (once the hole is filled).

Again, I am not supportive of using this as a reason to overhaul TSopt semantics in 1323bis as a whole... (probabilistic TSopt? Eventual PAWS?)

Richard Scheffenegger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christoph Paasch
> Sent: Montag, 27. Mai 2013 16:54
> To: Pasi Sarolahti
> Cc: [email-masked] Extensions; Joe Touch
> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt
> 
> Hello,
> 
> > > I fail to see the rationale for forcing a TCP connection to always
> > > send the TSopt in every segment. The timestamp aids to estimate the
> > > rtt and provides PAWS for long connections. Given the size of the
> > > TCP option space, we should not force the utilisation of the TSopt in
> all segments.
> > > Consider a TCP implementation that supports SACK, RFC1323 and TCP-AO
> > > or Multipath TCP. When this implementation sends an ACK segment that
> > > option space to encode a timestamp ? I'd vote for providing a
> > > timestamp from time to time and reporting accurate SACK blocks.
> >
> > Always including TSopt seems to represent the rough consensus of the
> > WG, even if it might not be a uniform agreement. This was discussed
> > quite extensively some time ago. (Though judging rough consensus from
> > Emails is difficult... we'd need some sort of electronic hum tool :-)
> >
> > About your question: if you believe Multipath TCP is going to be
> > useful for you, then it might be a reasonable choice to just disable
> > timestamps entirely to make room for MPTCP and SACK, assuming the
> > current work-in-progress spec. What do current MPTCP implementations
> > do about this, by the way?
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 May 2013 09:53:51 -0700

On 5/27/2013 3:19 AM, Pasi Sarolahti wrote:
...
> MUST drop all (non-RST) segments without timestamp seems indeed
> In the worst case this might discourage enabling timestamps at all,
> if an implementation wants to be safe against middleboxes as
> described.

We've gone through this multiple times for different issues on this 
mailing list, and have addressed it in the context of this ID in detail.

RST is the *only* way TCP cleans up old connection state. TCP doesn't 
keep things tidy; it cleans up state only when it gets in the way of a 
new connection.

RSTs that happen after a reboot won't necessarily have any state from 
the previous connection. ANY requirement about those RSTs *will* 
interfere with TCP state cleanup, and hosts could end up with the net 
effect of a "memory leak" for all connections that are interrupted by a 
reboot.

That's why RSTs MUST NEVER require anything - even, IMO, a handshake (as 
per RFC 5691).

Joe

---

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 27 May 2013 21:10:35 +0300

>> if an implementation wants to be safe against middleboxes as
[...]
> That's why RSTs MUST NEVER require anything - even, IMO, a handshake (as per RFC 5691).

Fine, but my (and Olivier's) comment was about normal segments that do not carry RST flag. Why MUST those be dropped at the receiver if they are missing TSopt for some reason? This is a new requirement compared to earlier versions of the draft and RFC1323, and I don't think current implementations drop such segments either.

- Pasi

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 May 2013 11:31:32 -0700

On 5/27/2013 11:10 AM, Pasi Sarolahti wrote:
> Fine, but my (and Olivier's) comment was about normal segments that
> do not carry RST flag.

Sorry - I misread your post. However:

> Why MUST those be dropped at the receiver if
> they are missing TSopt for some reason? This is a new requirement
> compared to earlier versions of the draft and RFC1323, and I don't
> think current implementations drop such segments either.

The original requirement was here in -13:

Regarding handling of non-RSTs lacking TSopt, we did discuss this on the 
list; you even cited this within the past day or so:

---
> Emails is difficult... we'd need some sort of electronic hum tool
---

Once you indicate a sender-side MUST, you need to describe how the 
receiver handles exceptions. IMO, there's little point to claiming PAWS 
protection if you're going to react *in any way* to a non-RST segment 
lacking TSopt.

I.e., a sender MUST include implies - IMO - a receiver MUST silently 
discard when the 'must' isn't there.

Joe

---

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 27 May 2013 23:40:52 +0300

On May 27, 2013, at 9:31 PM, Joe Touch <[email-masked]> wrote:

> Regarding handling of non-RSTs lacking TSopt, we did discuss this on the list; you even cited this within the past day or so:
> 
> ---

My recollection is that this discussion concerned sender-side behavior, but there have been tens of Emails during the past weeks, so I might have missed something.

> Once you indicate a sender-side MUST, you need to describe how the receiver handles exceptions. IMO, there's little point to claiming PAWS protection if you're going to react *in any way* to a non-RST segment lacking TSopt.
> 
> I.e., a sender MUST include implies - IMO - a receiver MUST silently discard when the 'must' isn't there.

My reading of the original robustness principle is that TCP receiver should have minimal required validation checks for segments, so I don't think sender-side "MUST include" automatically implies receiver-side "MUST ignore if missing", unless we can point out a clear problem in accepting the segment. Perhaps the possible unreliability of PAWS is such, then.

But there are possible deployment implications in additional receiver check, too. In a perfect world this might work, but RFC 1323 did not have as strict MUST requirement about including TSopt in all segments after handshake, and there are possible middlebox issues as Olivier mentioned. So I think it would be worthwhile addition to the middlebox section, then, to say if a middlebox removes TSopt option, or a resegmenting middlebox does not include it in all segments, that breaks the TCP connection entirely, if this version of spec is followed.

As a mere data point, I did a quick check on Linux that currently seems to first check if timestamp option was in incoming segment, and only then do PAWS check. It does not reject segments because of lack of TSopt, at least based on my quick reading.

- Pasi

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 May 2013 14:38:23 -0700

On 5/27/2013 1:40 PM, Pasi Sarolahti wrote:
>> Regarding handling of non-RSTs lacking TSopt, we did discuss this
>> onthe list; you even cited this within the past day or so:
>>
>> ---
> My recollection is that this discussion concerned sender-side
> behavior, but there have been tens of Emails during the past weeks, so I
> might have missed something.

It was the part about PAWS; if you accept segments omitting TSopt, those
segments aren't PAWS-protected, and so the connection isn't protectd.

>> I.e., a sender MUST include implies - IMO - a receiver MUST
>> silentlydiscard when the 'must' isn't there.
>
> My reading of the original robustness principle is that TCP receiver
> should have minimal required validation checks for segments,

There are four alternatives here regarding robustness:

	1. should the segment be accepted fully?

	2 should the segment generate a response (resend last ACK)?

	3. should the segment be silently ignored?

	4. should the segment generate an error?

Robustness suggests preferring these in order, where appropriate. 
However, if the point of TSopt is PAWS protection, then the best you can 
do is nothing (#3).

 > so I don't
> think sender-side "MUST include" automatically implies receiver-side
> "MUST ignore if missing", unless we can point out a clear problem in
> accepting the segment.

If you cannot point out such a problem, the MUST was clearly 
inappropriate. If there is *any* situation in which a receiver should do 
more than ignore a segment or report an error, then the condition is, at 
best, a SHOULD.

 > Perhaps the possible unreliability of PAWS is such, then.

That was my impression of the list discussion on this issue.

> But there are possible deployment implications in additional
> receiver check, too. In a perfect world this might work, but RFC 1323
> did not have as strict MUST requirement about including TSopt in all
> segments after handshake, and there are possible middlebox issues as
> Olivier mentioned. So I think it would be worthwhile addition to the
> middlebox section, then, to say if a middlebox removes TSopt option,
> or a resegmenting middlebox does not include it in all segments, that
> breaks the TCP connection entirely, if this version of spec is
> followed.

Sure. It's defeating the value of the TSopt. It's inappropriate for a 
connection to claim TSopt protection and not have it.

> As a mere data point, I did a quick check on Linux that currently
> seems to first check if timestamp option was in incoming segment, and
> only then do PAWS check. It does not reject segments because of lack of
> TSopt, at least based on my quick reading.

If there's a safe way to interpret segments without TSopt in a 
TSopt-protected connection, then sure, do it. I don't recall any being 
raised, which is why I suggested the way forward I did.

Joe

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 27 May 2013 22:05:53 +0000

Hi Pasi,

Yes, there was no formal requirement in 1323 (predating 2119), but its in 1323's PAWS section:

  4.2  The PAWS Mechanism
[...]
      The basic idea
      is that a segment can be discarded as an old duplicate if it is
      received with a timestamp SEG.TSval less than some timestamp
      recently received on this connection.

(an undefined TSval might be numeric zero, or TSrecent... 1323 doesn't say.)

We also had discussed the precedence of processing (1323 PAWS vs. 793 in-window acceptance testing), and the 1323 had some ambiguity how to go about this (the 1323 text would actually allow the omission of TSopt sometime along a session, voiding PAWS protection at that time, and potentially undefined (receiver) behavior then...

Regards,

Richard Scheffenegger

> Pasi Sarolahti
> Sent: Montag, 27. Mai 2013 22:41
> To: Joe Touch
> Cc: [email-masked] Extensions
> My recollection is that this discussion concerned sender-side behavior,
> but there have been tens of Emails during the past weeks, so I might have
> missed something.
> 
> should have minimal required validation checks for segments, so I don't
> think sender-side "MUST include" automatically implies receiver-side "MUST
> ignore if missing", unless we can point out a clear problem in accepting
> the segment. Perhaps the possible unreliability of PAWS is such, then.
> 
> But there are possible deployment implications in additional receiver
> check, too. In a perfect world this might work, but RFC 1323 did not have
> as strict MUST requirement about including TSopt in all segments after
> handshake, and there are possible middlebox issues as Olivier mentioned.
> So I think it would be worthwhile addition to the middlebox section, then,
> to say if a middlebox removes TSopt option, or a resegmenting middlebox
> does not include it in all segments, that breaks the TCP connection
> entirely, if this version of spec is followed.
> 
> As a mere data point, I did a quick check on Linux that currently seems to
> first check if timestamp option was in incoming segment, and only then do
> PAWS check. It does not reject segments because of lack of TSopt, at least
> based on my quick reading.
> 
> - Pasi
>

---

From: Pasi Sarolahti <[email-masked]>
Date: Tue, 28 May 2013 11:45:25 +0300

On May 28, 2013, at 12:38 AM, Joe Touch <[email-masked]> wrote:

> Robustness suggests preferring these in order, where appropriate. However, if the point of TSopt is PAWS protection, then the best you can do is nothing (#3).

After the latest addition, there is some inconsistency between Sec. 3.2 and 4.3.

* In the PAWS algorithm in sec. 4.3., there should be an additional step before R1 for checking if Timestamps option is present, and if not, tell to discard the segment (if negotiation had been successful).

* PAWS algorithm tells to send acknowledgment if the check fails. Shouldn't we then, for consistency, require sending acknowledgment also if TSopt is missing? Current MAY in Sec. 3.2. is not very informative in my mind.

But based on my quick Linux check, I believe that currently implementations follow what sec. 4.3. currently says, and what it said in RFC 1323: "if there is Timestamps option in the segment, then [do PAWS check]....". So this would be relevant change compared to RFC 1323 that should also be highlighted in Appendix H, because it may require action from implementors.

> Sure. It's defeating the value of the TSopt. It's inappropriate for a connection to claim TSopt protection and not have it.

So, to reflect the comment Olivier made earlier, I'd suggest expanding the third bullet in the Security Considerations section with something like following:

OLD:
" *  If the Timestamps option is removed from the <SYN> or <SYN,ACK>
         segment, high speed connections that need PAWS would not have
         that protection.  Middleboxes should not remove the Timestamps
         option."

NEW:
" *  If the Timestamps option is removed from the <SYN> or <SYN,ACK>
         segment, high speed connections that need PAWS would not have
         that protection. Successful negotiation of Timestamps option enforces a stricter verification of incoming segments at receiver. If the Timestamps option was removed from a subsequent data segment after a successful negotiation (for example, as part of re-segmentation), the segment is discarded by the receiver without further processing. Middleboxes should not remove the Timestamps option. One study found that 6% of measured HTTP connections had the Timestamps option removed from data segments [Honda11]."

[Honda11]  M. Honda, Y. Nishida, C. Raiciu, A. Greenhalgh, M. Handley, and H. Tokuda. Is it still possible to extend TCP?. In Proc. of ACM Internet Measurement Conference (IMC) '11, Berlin, Germany, November 2011. 

- Pasi

---

From: Joe Touch <[email-masked]>
Date: Wed, 29 May 2013 13:07:30 -0700

Hi, Pasi,

On 5/28/2013 1:45 AM, Pasi Sarolahti wrote:
> * In the PAWS algorithm in sec. 4.3., there should be an additional
> step before R1 for checking if Timestamps option is present, and if not,
> tell to discard the segment (if negotiation had been successful).

IMO, yes.

> * PAWS algorithm tells to send acknowledgment if the check fails.
> Shouldn't we then, for consistency, require sending acknowledgment also
> if TSopt is missing? Current MAY in Sec. 3.2. is not very informative in
> my mind.

I don't think it's useful to send the ACK in that case. The point of 
PAWS is to ignore segments that are not protected. Even sending an ACK 
defeats that. At best, send a dup ack for last segment received 
correctly, but I still think that doing *anything* other than 
silent-drop isn't what PAWS protection intends.

> But based on my quick Linux check, I believe that currently
> implementations follow what sec. 4.3. currently says, and what it said
> in RFC 1323: "if there is Timestamps option in the segment, then [do
> PAWS check]....". So this would be relevant change compared to RFC 1323
> that should also be highlighted in Appendix H, because it may require
> action from implementors.

Yes, if so.

>> Sure. It's defeating the value of the TSopt. It's inappropriate for
>> a  connection to claim TSopt protection and not have it.
>
> So, to reflect the comment Olivier made earlier, I'd suggest
> expanding  the third bullet in the Security Considerations section with something
> like following:
> OLD:
> that protection. Successful negotiation of Timestamps option
> enforces a stricter verification of incoming segments at receiver. If
> the Timestamps option was removed from a subsequent data segment
> after a successful negotiation (for example, as part of
> re-segmentation), the segment is discarded by the receiver without
> further processing. Middleboxes should not remove the Timestamps
> option. One study found that 6% of measured HTTP connections had the
> Timestamps option removed from data segments [Honda11]."

The last sentence seems out of place; why are you including that? If 
there are implications to the 6% drop then you should mention that, but 
I would expect that elsewhere than the security considerations section.

Joe

---

From: Pasi Sarolahti <[email-masked]>
Date: Thu, 30 May 2013 11:36:13 +0300

On May 29, 2013, at 11:07 PM, Joe Touch <[email-masked]> wrote:

> I don't think it's useful to send the ACK in that case. The point of PAWS is to ignore segments that are not protected. Even sending an ACK defeats that. At best, send a dup ack for last segment received correctly, but I still think that doing *anything* other than silent-drop isn't what PAWS protection intends.

The PAWS algorithm motivates sending ACK with recovering from half-open connections (referring to fig. 10 in RFC 793), when one side crashes and re-opens the connection. Wouldn't this same reasoning apply also for missing timestamps case? It is possible that after a reboot the system timestamps setting is reset from enabled to disabled, if that happens to be the boot-time default. In such case the newly opening connection would have its segments discarded by the other side that still remains in established state, because of lack of timestamps, isn't that right?

Admittedly this is not the most likely scenario, but just trying to dig up the reasoning for choosing one way or the other.

Since we are on the path of clarifying the text with normative language, why not do the same also for Section 4.3? We should decide

1) MAY/SHOULD/MUST send response for missing timestamp

2) MAY/SHOULD/MUST send response when timestamp comparison fails (current text on R1 seems to want that this is MUST)

It would be good to provide these with some reasoning, too. For (2) this reasoning already seems to be in place.

Nit: start of section 4.3 uses "REQUIRES" that should not be capitalized because it is not a RFC 2119 keyword. How about just saying something like "if PAWS algorithm is enabled, the following steps MUST be followed", or something. Sorry about splitting hairs, but I think we should be pedantic about the keywords.

> The last sentence seems out of place; why are you including that? If there are implications to the 6% drop then you should mention that, but I would expect that elsewhere than the security considerations section.

Because that paragraph talks about removal of timestamps option. But I agree that the proposed sentence doesn't sit there very well. How about including the reference in the beginning of the Middleboxes section of the text:

"Some middleboxes have been known to remove the TCP options
      described in this document from the TCP segments [Honda11]." (changed <SYN> segment to TCP segments)

The main point is that the current text only talks about dropping options from SYN segments, but this happens also for data segments, as the paper shows. Since we have fairly recent quantified data about this, why not include the reference?

- Pasi

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 30 May 2013 14:28:01 +0000

Thanks Pasi, Joe.

> Even sending an ACK
> defeats that. At best, send a dup ack for last segment received correctly,
> but I still think that doing *anything* other than silent-drop isn't what
> PAWS protection intends.

My understanding is, that failing the PAWS test should be treated like receiving 
a segment that is out-of-window. The reason for failing the PAWS test (missing TSopt, 
or invalid TSval) is secondary, not?

Thus an ACK for the last in-sequence segment should be sent.

> 1) MAY/SHOULD/MUST send response for missing timestamp

This case is not currently covered. As consensus was reached that TSopt should not be allowed to be sent arbitratily for some segments and not for others, I would think a missing timestamp in a segment means, that segment needs to be treated like any other out-of-window segment.

> 2) MAY/SHOULD/MUST send response when timestamp comparison fails (current
> text on R1 seems to want that this is MUST)

For both, I think a MUST would be a appropriate, a SHOULD may suffice. (as an individual contributor).

Fixed the Nit, and updated section 6 as indicated.

Best regards,

Richard Scheffenegger

> Sent: Donnerstag, 30. Mai 2013 10:36
> To: Joe Touch
> >> Shouldn't we then, for consistency, require sending acknowledgment
> >> also if TSopt is missing? Current MAY in Sec. 3.2. is not very
> >> informative in my mind.
> >
> defeats that. At best, send a dup ack for last segment received correctly,
> but I still think that doing *anything* other than silent-drop isn't what
> PAWS protection intends.
> 
> The PAWS algorithm motivates sending ACK with recovering from half-open
> connections (referring to fig. 10 in RFC 793), when one side crashes and
> re-opens the connection. Wouldn't this same reasoning apply also for
> missing timestamps case? It is possible that after a reboot the system
> timestamps setting is reset from enabled to disabled, if that happens to
> be the boot-time default. In such case the newly opening connection would
> have its segments discarded by the other side that still remains in
> established state, because of lack of timestamps, isn't that right?
> 
> Admittedly this is not the most likely scenario, but just trying to dig up
> the reasoning for choosing one way or the other.
> 
> Since we are on the path of clarifying the text with normative language,
> why not do the same also for Section 4.3? We should decide
> 
> 2) MAY/SHOULD/MUST send response when timestamp comparison fails (current
> text on R1 seems to want that this is MUST)
> 
> Nit: start of section 4.3 uses "REQUIRES" that should not be capitalized
> because it is not a RFC 2119 keyword. How about just saying something like
> "if PAWS algorithm is enabled, the following steps MUST be followed", or
> something. Sorry about splitting hairs, but I think we should be pedantic
> about the keywords.
> 
> >>          segment, high speed connections that need PAWS would not
> >> have that protection. Successful negotiation of Timestamps option
> there are implications to the 6% drop then you should mention that, but I
> would expect that elsewhere than the security considerations section.
> 
> Because that paragraph talks about removal of timestamps option. But I
> agree that the proposed sentence doesn't sit there very well. How about
> including the reference in the beginning of the Middleboxes section of the
> text:
> 
> The main point is that the current text only talks about dropping options
> from SYN segments, but this happens also for data segments, as the paper
> shows. Since we have fairly recent quantified data about this, why not
> include the reference?
> 
> - Pasi
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 30 May 2013 09:52:16 -0700

Hi, all,

On 5/30/2013 7:28 AM, Scheffenegger, Richard wrote:
> This case is not currently covered. As consensus was reached that
> TSopt should not be allowed to be sent arbitratily for some segments and
> not for others, I would think a missing timestamp in a segment means,
> that segment needs to be treated like any other out-of-window segment.

Missing a timestamp is a bit different; it not only means that the 
segment should be treated as out-of-window, but there's something else 
amiss with the connection.

I.e., out-of-window might be fixed at some point, but missing TSopt will 
never be fixed. So I don't see what the point of sending a response here 
would be - it's like sending the last-valid ACK when you get any other 
malformed packet (because malformed != expired timestamp) -- which we 
don't do.

> For both, I think a MUST would be a appropriate, a SHOULD may
> suffice.(as an individual contributor).

FWIW, I never like "SHOULD" unless we have an explicit reason for not 
selecting MUST - either a known exception (which we should mention), or 
a reason for wanting to keep the door open.

In this case, I'm not sure what the appropriate behavior would be - 
what's the point of sending a response (e.g., an ACK of the last 
correctly received data) when the timestamp fails?

I.e., I wouldn't send a message unless it provides a purpose. Does it here?

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 30 May 2013 09:59:09 -0700

Hi, all,

...
> Nit: start of section 4.3 uses "REQUIRES" that should not be
> capitalized because it is not a RFC 2119 keyword. How about just saying
> something like "if PAWS algorithm is enabled, the following steps MUST
> be followed", or something. Sorry about splitting hairs, but I think we
> should be pedantic about the keywords.

REQUIRED is a 2119 keyword; I can't see why the present tense shouldn't 
be treated the same way, but MUST is fine too.

>> The last sentence seems out of place; why are you including that?
>> Ifthere are implications to the 6% drop then you should mention that, but
> Because that paragraph talks about removal of timestamps option. But
> I agree that the proposed sentence doesn't sit there very well. How
> about including the reference in the beginning of the Middleboxes
> section of the text:
>

Yup - that's better, IMO.

> The main point is that the current text only talks about dropping
> options from SYN segments, but this happens also for data segments, as
> the paper shows. Since we have fairly recent quantified data about this,
> why not include the reference?

That's fine, it was the placement issue.

However, if your point is that they remove options from data segments 
then you might point that out explicitly in the revised text.

Question - is there a reason a midbox would let the option through on a 
SYN and block it on the data segments? Or are you worried about path 
changes whose data segments go through midboxes that the SYN didn't? 
Again, if that's the case, then you might explain that in the text above 
in the midbox section (1-2 sentences).

Joe

---

From: <[email-masked]>
Date: Fri, 31 May 2013 01:36:53 +0100

> be treated the same way, but MUST is fine too.

If the present tense is permitted, then the past tense (WAS REQUIRED) is also allowed.

Ambiguous, that.

Lloyd Wood
http://sat-net.com/L.Wood/

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Joe Touch [[email-masked]]
Sent: 30 May 2013 17:59
To: Pasi Sarolahti
Cc: [email-masked] Extensions
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt

Hi, all,

...

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 30 May 2013 17:49:17 -0700

> If the present tense is permitted, then the past tense (WAS REQUIRED) is also allowed.

REQUIRED is an adjective, describing a state:

	Y is REQUIRED

X REQUIRES Y is the present tense verb phrase equivalent of:

	Y is REQUIRED by X

If you prefer to use only 2119 language, use the "Y is REQUIRED by X" 
variant.

"was REQUIRED" means past tense, and doesn't thus describe a current 
constraint. I don't think that makes much 2119 sense.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 31 May 2013 12:51:49 +0200

Hi, Richard,

For the most part I've not participated in this discussion at all, but
at times have lurked a bit... A small comment here:

> This case is not currently covered. As consensus was reached that TSopt should not be allowed to be sent arbitratily for some segments and not for others, I would think a missing timestamp in a seg…

Datapoint: Some OSes accept non-timestamped packets because they've fund
that some implementations (or maybe sites "protected" by some sort of
middlebox) at times stop sending timestamps, or include timstamp options
at their own discretion.

Not that I think that accepting such packets is nice (actually, it
doesn't look "clean") -- but at the end of the day, you need to
interoperate with others.

I suggest that the OpenBSD folks are asked about this one... since I
think they were the ones noting the aforementioned issue.

Cheers, and thank you guys for the hard work on rfc1323bis!
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Pasi Sarolahti <[email-masked]>
Date: Fri, 31 May 2013 14:27:25 +0300

On May 30, 2013, at 7:59 PM, Joe Touch <[email-masked]> wrote:
> However, if your point is that they remove options from data segments then you might point that out explicitly in the revised text.
> 
> Question - is there a reason a midbox would let the option through on a SYN and block it on the data segments? Or are you worried about path changes whose data segments go through midboxes that the SYN didn't? Again, if that's the case, then you might explain that in the text above in the midbox section (1-2 sentences).

The paper only speaks about timestamps in data segments, but I didn't notice separate analysis on SYN segments, which in retrospect might have been interesting to see separately. But yes, in most of the mentioned cases probably the option is removed from all segments altogether.

For removing timestamps only from some segments, path changes might be one reason, and in earlier mail re-segmenting middleboxes that didn't properly support timestamps were mentioned as another possible reason. Also TSO is quite common these days, and it is not impossible that some TSO implementations did not properly support timestamps, although I believe that most of them do. So I don't believe this would be a common problem, and can't point out to particular case where this happens, but even if it occurred only rarely, the users that are unlucky enough to be behind that unfortunate path would constantly suffer quite a performance hit, before they learn how to disable timestamps.

I was playing with a new experimental option in our test lab some time ago, and there TSO caused the option to disappear from some of the segments (those that happened to exceed the native segment size when leaving OS), but the option was included in segments that left the OS as small enough to fit on wire. Disabling TSO solved the issue. But I also checked that timestamps were handled correctly in that case :-)

- Pasi

---

From: Joe Touch <[email-masked]>
Date: Fri, 31 May 2013 10:24:59 -0700

> interoperate with others.

Interoperation has two interpretations:

- accept packets under any circumstances

- accept packets that conform to the requirements of the connection

It's critical to note that accepting non-TSopt packets in a connection 
that has successfully negotiated TSopt effectively defeats PAWS. There's 
no such thing as "just for this packet".

So the key question is:
	
	- should a connection follow the constraints of its
	negotiation, or should being "interoperable" trump
	the entire existence of the PAWS feature?

I don't think so. I.e., being "interoperable" here means "being incorrect".

Joe

---

From: Tim Shepard <[email-masked]>
Date: Fri, 31 May 2013 14:47:36 -0400

If a TCP connection has succesfully negotiated timestamp option on,
and a segment shows up with no timestamp option, I can think of only
two reasons for this:

	1.   The other TCP is buggy in some way.  (Or maybe *this*
             TCP implementation is buggy in some way and corrupted
	     the TCB block variable that remembers whether we've got
	     timestamp options on or off.  In any case, there is a
	     bug.)
	
	2.   The segment that arrived is from some old TCP connection,
	     probably to or from some previous user of a reused IP
	     address.  

	     (The MSL is a pure myth.  There's no way to guarantee any
	     upper bound for how long some packet may be delayed in
	     transit.  15+ years ago I did a trivially easy
	     demonstration that delayed several ping packets for over
	     an hour (over lunch), with no Internet routers involved,
	     on a LAN using hardware that was in widespread use at the
	     time.  E.g. Someone trips over a cable which slightly
	     dislodges it, then hours or days later, someone later
	     notices and pushes it back in.)

So, you can either accept the packet (A) or drop the packet (B).

    1. (A)     hmm... other end is buggy, *maybe* accepting the packet
	       would be the right thing.

    1. (B)     other end is buggy, dropping the packet *might* cause a
	       TCP connection to get stuck that otherwise would not
	       have gotten stuck.  (Hard to say... the other end is buggy!)

    2. (A)     data corruption (if the packet is otherwise acceptable)

    2. (B)     clearly the right thing to do.

With no reliable way to distinguish case 1 from case 2 at the
receiver, my gut is to prefer option B and live with the possible
downside of  the  1. (B)  situation.

I also think letting the connection get stuck in the 1. (B) situation
has an upside... it might draw attention to the bug and cause the bug
to get fixed.  

... as long as there is no ambiguity on which of the two TCP
implementations is buggy.  (If we have this problem, then we have a
much bigger problem.)

			-Tim Shepard
			 [email-masked]