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

From: "Scheffenegger, Richard" <[email-masked]>
Date: Sat, 1 Jun 2013 13:57:37 +0000

Hi Tim,

I agree with your reasoning, and think that IF Tsopt was established, under the current semantics, subsequent segments without Tsopt MUST not be accepted.

Sending an ACK for the last in-sequence segment MAY be allowed (but a receiver should not keep sending such an ACK excessively - if it would, and the reason for the non-TSopt segments is a path change where TSopt is being stripped, it could result in a permanent exchange of data/ack, without any forward progress... Although the sender would continuously shrink the cwnd, and limit the wasted bandwidth.)

Olivier remarked, that sometimes a sender might push out the TSopt in favor of other options (MPTCP, SACK). While I believe that even then a segment should not be accepted, if it lacks TSopt, I was wondering if there is any benefit to be had, to allow a fully in-sequence packet to be accepted then (shinking the acceptance window basically to one particular sequence number).

OTOH, the point of SACK is that it being sent during reorder / loss events, so a rule like above wouldn't be all that helpful really...

Does anyone know why Linux does accept non TSopt segments at any time?

In any case, the only proper way for PAWS would be to not accept non-TSopt segments after TSopt has been negotiated.

Regards,

Richard Scheffenegger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tim Shepard
> Sent: Freitag, 31. Mai 2013 20:48
> To: Joe Touch
> Cc: Fernando Gont; [email-masked] Extensions
> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-13.txt
> 
> 
> 
> 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]
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Andre Oppermann <[email-masked]>
Date: Sat, 01 Jun 2013 18:52:08 +0200

On 01.06.2013 15:57, Scheffenegger, Richard wrote:
> Hi Tim,
>
> I agree with your reasoning, and think that IF Tsopt was established, under the current
> semantics, subsequent segments without Tsopt MUST not be accepted.

The problem seems to be that timestamps are used for two separate
purposes: a) better RTT measurements; b) PAWS.

For a) a missing TSopt on a segment wouldn't be fatal, however which
timestamp shall the receiver reflect from now on?  The last one seen?
That would lead to a rapid inflation in apparent RTT seen on the sender.
For b) a missing TSopt is fatal since it makes it impossible to determine
if this segment is actually valid or not.

> Sending an ACK for the last in-sequence segment MAY be allowed (but a receiver should not keep
> sending such an ACK excessively - if it would, and the reason for the non-TSopt segments is a
> path change where TSopt is being stripped, it could result in a permanent exchange of data/ack,
> without any forward progress... Although the sender would continuously shrink the cwnd, and limit
> the wasted bandwidth.)

The more useful behavior is to ignore the segment missing TSopt.  Sending
an ACK doesn't magically fix the bug on the other side and leads to an
ACK war in the worst case.

> Olivier remarked, that sometimes a sender might push out the TSopt in favor of other options
> (MPTCP, SACK). While I believe that even then a segment should not be accepted, if it lacks
> TSopt, I was wondering if there is any benefit to be had, to allow a fully in-sequence packet to
> be accepted then (shinking the acceptance window basically to one particular sequence number).

TSopt should never be pushed out by other options.  Doing so would be a bug.
One wouldn't expect other always present options (MPTCP for example) to be
pushed out either.

> Does anyone know why Linux does accept non TSopt segments at any time?

FreeBSD behaves the same.  I once changed syncache to require TSopt in the
ACK completing the 3WHS when it was negotiated during SYN/SYN-ACK.  It was
reverted a short time later because someone reported a problem where some
buggy device on the path responded with an ACK in parallel to the original
host but missing TSopt.  Since the buggy device was slightly faster a RST
was sent and the connection attempt aborted.  I have no idea why the buggy
device responded in parallel with the real endpoint...  After the acceptance
test was relaxed again there was no further detailed analysis and it was
never found out what kind of device caused the trouble along the path.

The reverse check where TSopt must not be present when not negotiated is
still in place and hasn't caused any known problems.

Other errors with TSopt (not) present in established state are currently
not logged.  I should add in the next days.

> In any case, the only proper way for PAWS would be to not accept non-TSopt segments after TSopt

Agreed.

-- 
Andre

---

From: Yuchung Cheng <[email-masked]>
Date: Sat, 1 Jun 2013 09:54:17 -0700

> Does anyone know why Linux does accept non TSopt segments at any time?

quoting Olivier
"""
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.
"""

Real implementations need to handle things that purists don't like.

---

From: Jakob Heitz <[email-masked]>
Date: Sat, 1 Jun 2013 17:37:50 +0000

On Jun 1, 2013, at 9:52 AM, "Andre Oppermann" <[email-masked]> wrote:

> timestamp shall the receiver reflect from now on?  

Zero

> The last one seen?

---

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 3 Jun 2013 13:18:39 +0300

> I agree with your reasoning, and think that IF Tsopt was established, under the current semantics, subsequent segments without Tsopt MUST not be accepted.

This is true for reliable operation of PAWS, but I did not find any language in RFC 1323 that speaks about the situation when a segment is received without timestamp. Instead, the way how R1 was written "if there is a timestamp option and [...Ts conditions...] then treat the arriving segment as not acceptable" easily leads to interpretation that segment that arrives without timestamp is acceptable. So the implementations that accept such segments are compliant with RFC 1323 in my reading, even if it opens a window of possible failure to the PAWS check.

If we want reliable PAWS, I agree that "MUST not be accepted" is needed, but it seems that practical deployments have opted for imperfect PAWS in favor of being able to deal with problematic middleboxes in the network (or whatever other reason), no matter how rare those might be. I guess this is one of the principle vs. practice issues that implementations need to face these days. If we include this as MUST, I think it would be appropriate to note that many (or most?) current implementations do not have it (i.e., we do not necessarily know about all the deployment implications, referring to the discussion in middlebox part), and also note the check wasn't required by RFC 1323 (but this might have been an oversight).

- Pasi

---

From: Joe Touch <[email-masked]>
Date: Mon, 03 Jun 2013 09:47:05 -0700

> Real implementations need to handle things that purists don't like.

I completely agree. However, what you describe is a middlebox that 
allowed the TSopt in a SYN and then blocked it later.

The middlebox made a decision that broke what the endpoints asked for. 
So whose intentions do we honor?

Given this is the Internet, it seems clear to me that the endpoints are 
in control, and if the middlebox does something that breaks the 
negotiated connection semantics, then it is a real implementation that 
is broken.

If you let the "real implementation" of the middlebox drive the solution 
here, you have just told all the endpoints that PAWS is no longer available.

You cannot have it both ways. There are real implementations at the 
endpoints who care.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 03 Jun 2013 09:58:28 -0700

Hi, Pasi,

On 6/3/2013 3:18 AM, Pasi Sarolahti wrote:
>> I agree with your reasoning, and think that IF Tsopt was
>> established, under the current semantics, subsequent segments
>> without Tsopt MUST not be accepted.
>
> This is true for reliable operation of PAWS, but I did not find any
> language in RFC 1323 that speaks about the situation when a segment
> is received without timestamp. Instead, the way how R1 was written
> "if there is a timestamp option and [...Ts conditions...] then treat
> the arriving segment as not acceptable" easily leads to
> interpretation that segment that arrives without timestamp is
> acceptable.

I disagree with your logic.

On connections that successfully negotiate TSopt, a segment lacking 
TSopt has insufficient information to be considered "acceptable", which 
to me indicates that it is "not acceptable".

I.e., we agree that a segment lacking TSopt has insufficient info; so do 
we assume that such a segment is in-window? or not?

Assuming such a segment is acceptable effectively disables PAWS.

> So the implementations that accept such segments are
> compliant with RFC 1323 in my reading, even if it opens a window of
> possible failure to the PAWS check.

RFC1323 does not specifically address segments lacking TSopt in the PAWS 
section. IMO, you can't claim compliance, but you can claim it doesn't 
violate it if you want - but I don't see the point in that.

> If we want reliable PAWS, I agree that "MUST not be accepted" is
> needed, but it seems that practical deployments have opted for
> imperfect PAWS in favor of being able to deal with problematic
> middleboxes in the network (or whatever other reason), no matter how
> rare those might be. I guess this is one of the principle vs.
> practice issues that implementations need to face these days. If we
> include this as MUST, I think it would be appropriate to note that
> many (or most?) current implementations do not have it (i.e., we do
> not necessarily know about all the deployment implications, referring
> to the discussion in middlebox part), and also note the check wasn't
> required by RFC 1323 (but this might have been an oversight).

I agree that we should note that 1323 doesn't address the case of TSopt 
being dropped or selectively omitted after being negotiated, and that 
the current recommendation may cause some broken middlebox behavior to 
be detected.

Joe