Subject: Re: [tcpm] some questions related to PAWS

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 16 Jul 2013 16:11:37 +0000

Hi Yoshifumi,

> Sorry. As you mentioned, PAWS is receiver logic. What I meant was 
> disabling PAWS check. 
>
> Something like, "I want to have TS for RTTM, but I don't want to 
> drop packets without TS unless the sender sends data 4GB in less 
> than 2MSL". In this case, the node needs to measure receiving rate 
> to check if PAWS check is required. 
>
> It might be tricky, but I still think it's one possibility. one 
> might prefer it rather than dropping packets without TS blindly.

After re-reading this thread, I believe the update should state how the mechanism SHOULD work; if a receiver decides to unilaterally accept segments, that are according to this document deemed not acceptable, so be it...

Further, coming up with a mechanism to selectively negotiate for certain functions to be used with TSopt clearly goes beyond the scope of the -bis update. You might want to keep an eye on the TS exposure / negotiation drafts that Mirja, Brian and I are collectively working on (and would allow extensibility for such functionality).

Best regards,

Richard Scheffenegger

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 16 Jul 2013 16:23:22 +0000

For what it'S worth, I reworded that MUST and MAY to a SHOULD and SHOULD NOT:

   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 an <RST> segment (see Section 4.2 for details).  If a non-
~  <RST> segment is received without a TSopt, a TCP SHOULD drop the
~  segment and SHOULD NOT send an <ACK> for the last in-sequence
   segment.  A TCP MUST NOT abort a TCP connection because any segment
   lacks an expected TSopt.

And added the following paragraph suggested by Joe as last point in the Security/Middlebox section, to point out that the -bis update may uncover broken middleboxes, potentially leading to stale TCP sessions.

~     *  It must be noted that [RFC1323] doesn't address the case of the
~        Timestamps option being dropped or selectively omitted after
~        being negotiated, and that the update in this document may
~        cause some broken middlebox behavior to be detected
~        (potentially unresponsive TCP sessions).

I think these two updates reflect what has been discussed on list...

(These are deltas vs. http://www.ietf.org/id/draft-ietf-tcpm-1323bis-14.txt ).

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: Pasi Sarolahti [mailto:[email-masked]]
> Sent: Dienstag, 04. Juni 2013 18:28
> To: Scheffenegger, Richard
> Cc: Yoshifumi Nishida; [email-masked]
> Subject: Re: [tcpm] some questions related to PAWS
> 
> On Jun 4, 2013, at 3:05 PM, "Scheffenegger, Richard" <[email-masked]>
> wrote:
> 
> >> It might be tricky, but I still think it's one possibility.
> >> one might prefer it rather than dropping packets without TS blindly.
> >
> > Probably. The sender MUST still provide a TSopt in every segment,
> assuming that the receiver is strictly enforcing PAWS. If a receiver
> chooses to open a broader window for misuse (as apparently two dominant
> stacks currently do), that's their business. Specifying a resiliency
> mechanism and then stipulating it is completely optional to use it, is not
> the best approach for an RFC IMHO. That's an implementers choice.
> 
> Right. But we should also remember PAWS failure should be very rare case,
> where two uncommon events coincide:
> * there is a old segment with wrapped sequence number that happens to hit
> the window
> * the segment has timestamps option removed for some reason
> 
> > I need to find some time to summarize the discussion around this topic
> > that the WG had in the last few days, and pour it into some text for
> > the 1323bis draft. (I'm always happy if someone want's to donate
> > text..:)
> 
> I don't think there has been much disagreement about the fact that to
> ensure reliable operation of PAWS, all segments must have timestamps. I
> tend to agree with you that standardizing an algorithm that works
> unreliably is not elegant, and majority of mailing list feedback seems to
> support this, so this seems clear.
> 
> The trickier thing is, what language to add about the current state, but I
> think we should point out what we know: there are implementations that
> accept segments without timestamp after its successful negotiation (in
> fact no one so far has reported implementation that would discard segments
> without timestamps), and changing to follow the "MUST discard" rule may
> bring up some communication problems as a result of faulty network
> behavior (and there was some reported evidence of this actually
> happening). I'm not suggesting this as a text to be used, but hopefully it
> is an acceptable summary to everyone.
> 
> Not to be said in the document, but just wanted to say it out: even if
> segments without timestamps were accepted, PAWS could still be able to
> detect most cases of sequence wrapping, assuming that timestamps removal
> is a rare case. If user runs into communication problems that can be
> solved by turning timestamps off entirely, the natural reaction is to do
> so. After that there is no PAWS protection at all.
> 
> - Pasi

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 16 Jul 2013 22:50:29 -0700

Hi Richard,

On Tue, Jul 16, 2013 at 9:11 AM, Scheffenegger, Richard <[email-masked]>wrote:

> After re-reading this thread, I believe the update should state how the
> mechanism SHOULD work; if a receiver decides to unilaterally accept
> segments, that are according to this document deemed not acceptable, so be
> it...
>

I agree. I would like to think about PAWS, but updating text for this was
not my intention.

> Further, coming up with a mechanism to selectively negotiate for certain
> functions to be used with TSopt clearly goes beyond the scope of the -bis
> update. You might want to keep an eye on the TS exposure / negotiation
> drafts that Mirja, Brian and I are collectively working on (and would allow
> extensibility for such functionality).

Yep, I will.

--
Yoshifumi

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 17 Jul 2013 00:22:35 -0700

Hi Richard,

Sorry. I might be too picky, but one point..
"SHOULD NOT send an <ACK> for the last in-sequence segment." sounds to me
that I might be able to send other types of segments.
I'm guessing what you meant here is SHOULD NOT send any segments.
But, this means if TS is accidentally dropped from the segment, the draft
explicitly prohibit notifying it.
I'm a bit curious if we need to be explicit here.

--
Yoshifumi

On Tue, Jul 16, 2013 at 9:23 AM, Scheffenegger, Richard <[email-masked]>
wrote:
> And added the following paragraph suggested by Joe as last point in the
Security/Middlebox section, to point out that the -bis update may uncover
broken middleboxes, potentially leading to stale TCP sessions.
> (These are deltas vs.
http://www.ietf.org/id/draft-ietf-tcpm-1323bis-14.txt ).

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 17 Jul 2013 13:06:57 +0000

Hi Yoshifumi,

Well, that unacceptable segment SHOULD NOT trigger an ACK; the sender is free to send a segment for other reasons though (window probe, keepalive, new data).

Perhaps that sentence should better read like:

If a non-<RST> segment is received without a TSopt, a TCP SHOULD silently drop the segment.

Best regards,

Richard Scheffenegger

From: Yoshifumi Nishida [mailto:[email-masked]] 
Sent: Mittwoch, 17. Juli 2013 09:23
To: Scheffenegger, Richard
Cc: Pasi Sarolahti; Yoshifumi Nishida; [email-masked]
Subject: Re: [tcpm] some questions related to PAWS

Hi Richard,

Sorry. I might be too picky, but one point..
"SHOULD NOT send an <ACK> for the last in-sequence segment." sounds to me that I might be able to send other types of segments.
I'm guessing what you meant here is SHOULD NOT send any segments.
But, this means if TS is accidentally dropped from the segment, the draft explicitly prohibit notifying it. 
I'm a bit curious if we need to be explicit here.

--
Yoshifumi

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 17 Jul 2013 09:54:29 -0700

Hi Richard,

On Wed, Jul 17, 2013 at 6:06 AM, Scheffenegger, Richard <[email-masked]>wrote:

>
> Hi Yoshifumi,
>
> Well, that unacceptable segment SHOULD NOT trigger an ACK; the sender is
> free to send a segment for other reasons though (window probe, keepalive,
> new data).
>
>

Yes, I agree. I prefer this one.
--
Yoshifumi

---

From: Joe Touch <[email-masked]>
Date: Sun, 21 Jul 2013 17:15:44 -0700

If PAWS is a "best effort" assurance, then I accept your conclusion.

If PAWS is something we think provides a guarantee (and I do), then it 
is a mistake, and the previous MUST and MUST NOTs should be retained.

I've so far seen discussion talking about the practical side of this 
issue from the standpoint of non-compliant components (notably 
middleboxes). That may be true but remains irrelevant to the impact on 
the connection.

If you keep the SHOULD and SHOULD NOT below, you're effectively killing 
PAWS capability. You need to at least admit that in the text.

Joe

On 7/16/2013 9:23 AM, Scheffenegger, Richard wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 22 Jul 2013 22:55:55 +0300

On Jul 22, 2013, at 3:15 AM, Joe Touch <[email-masked]> wrote:

> If PAWS is something we think provides a guarantee (and I do), then it is a mistake, and the previous MUST and MUST NOTs should be retained.

I think this is a good summary, and something we can hopefully conclude by the meeting (knowing that some people cannot be there, in which case you should make yourselves heard on the list).

> If you keep the SHOULD and SHOULD NOT below, you're effectively killing PAWS capability. You need to at least admit that in the text.

I agree that the text needs to be clear about the consequences of not following the receiver-side SHOULD (or MUST). Even if it was MUST, I think it would be good to have that text, because it seems that there are implementations that accept segments without timestamps.

But I think "killing PAWS capability" is too strongly said. SHOULD would open a window of unreliability to PAWS, making it best effort instead of guarantee, but it would still work in majority of cases.

- Pasi