[tcpm] draft-moncaster-tcpm-rcv-cheat-01

[Alfred Hönes <[e-mail]>]

Hello,
after studying the Internet-Draft authored by you,
            draft-moncaster-tcpm-rcv-cheat-01,
I'd like to submit a few comments, mostly addressing textual
flaws I found in that memo.

The items below are presented in (almost) textual order.
To give more context, sometimes I quote larger blocks of text
literally and show the replacement proposed using the shorthand
notation:

   <original draft text>
---
   <modified text>

I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.  I also try to accomodate published
RFC-Ed policy on style and punctuation etc. in my proposals.


(1)  General

The prologue of the draft says:

 Changes from previous drafts (to be removed by the RFC Editor)
   From -00 to -01:
      Draft rewritten to emphasise testing for non-compliance.  Some
      changes to protocol to remove possible unwanted interactions with
      other TCP variants.  Sections added on comparison of solutions and
      alternative uses of test.

Unfortunately, this change apparently has not been performed
perfectly.  I still find numerous instances of old-style wording
in the text, like "cheating", "honest", "dishonest", "misbehaving",
etc. ...

I recommend that this should be reconsidered systematically.
Among the terms listed, only "misbehaving" might be appropriate
in certain places, in the new spirit of the draft.

For brevity, below I omit quoting most occurrences of this issue
unless there are other reasons to do so as well, or they appear
particularly significant.  I hope that the above list of terms is
exhaustive, such that these places can be located easily.


(2)  Section 1

(2a)

Typo: In the 3rd paragraph, change  "optimisitic"  -->  "optimistic".

(2b)

In the 8th paragraph,

   In order for a sender ...

I recommend to apply the following clarification and improvement
 of language:
                                      [...]  Instead, the sender
|  emulates network re-ordering then network loss to test that the
|  receiver reacts as it should as defined within the basic TCP
   protocol.  It is important that the level of emulated re-ordering
   that such a test introduces should not adversely impact compliant
   receivers.
---
                                      [...]  Instead, the sender
|  emulates network re-ordering, and then network loss, to test that the
                               ^^^^^                  ^
|  receiver reacts as it should according to the basic TCP protocol.  It
                                ^^^^^^^^^^^^
   is important that the level of emulated re-ordering that such a test
   introduces should not adversely impact compliant receivers.


(3)  Section 5.1

The first paragraph twice says "re-transmitted" when in fact it
refers to the *first* transmission of a packet that has been
artificially delayed as requested by the test procedure.
I propose to replace "re-transmitted" by "transmitted".

However, in an implementation these transmissions might be handled
using code otherwise used for re-transmissions; thus alternatively
it might arguably make sense to just (single-/double-)quote this
word to indicate the reuse/abuse of code.
As this background might not be immediately clear to a reader
(without further elaboration), I recommend the former change.


(4)  Section 5.2

In the first paragraph of Section 5.2, the draft says:

                                      [...].  The nonce works by
   randomly setting the ECN field to ECN(0) or ECN(1).  It then
   maintains the least significant bit of the sum of this value and
   stores the expected sum for each segment boundary.  [...]

The "It then maintains ..." is potentially misleading.
I recommend to substitute inequivocally "The sender maintains ...".

Furthermore, I suggest to add the definite article:
"in experimental [RFC3540]"  -->  "in the experimental [RFC3540]"

Altogether, the initial part of the modified first paragraph will be:

   The authors of the ECN scheme [RFC3168] identified the failure to
   echo ECN marks as a potential attack on ECN.  The ECN nonce was
|  proposed as a possible solution to this in the experimental
   [RFC3540].  It uses a 1 bit nonce in every IP header.  The nonce
|  works by randomly setting the ECN field to ECN(0) or ECN(1).  The
|  sender then maintains the least significant bit of the sum of this
   value and stores the expected sum for each segment boundary.  At the
   receiver end, the same 1-bit sum is calculated and is echoed back in
   the NS (nonce sum) flag added to the TCP header.  [...]


(5)  Section 6

According to (1), change the title:

6.  The Test for Receiver Cheating
---
6.  The Test for a Non-conforming Receiver


(6)  Section 6.2.1

In the first paragraph od Section 6.2.1, the draft says:

                                                      [...].  If K is
   less than 5, the sender can proceed straight to the deterministic
   test.  [...]

I'm in doubt whether that is a good idea, and the test be reasonably
performed in this case.
When the current [send] window size K is less than 5, arguably the
receiver does not obtain an inappropriate share of the sender's
(and the network's) resources, and it is quite unlikely that the
receiver is misbehaving / non-conformant.  In the absence of a strong
indication to this end, it seems to be not justified and invasive to
incur the performance penalty of the deterministic test.
Thus, it seems to me that in the case of K < 5, execution of the test
should be strongly discouraged in general.
There might be an exception to this: working in a dedicated test
scenario; but that should only be done under explicit administrative
control, not routinely by a deployed (e.g. web / media distribution)
server.

Should I err in my diagnosis and you have strong arguments for indeed
immediately turning to the deterministic test in the case K < 5, that
should perhaps be elaborated upon in the text.


(7)  Section 6.2.5

(7a)

In the first bullet, there is an unpleasant use of `optional plural`,
"a non-compliant receiver(s)".
IMHO, it would not harm to simplify the language using plural anyway:

   o  Any TCP sender MAY check the compliance of its receivers using the
      probabilistic test periodically and randomly.  In particular, it
      would be advantageous for any sender that is heavily loaded to
|     identify if it is being taken advantage of by a non-compliant
|     receiver(s).
---           ^^^                                   ^^
   o  Any TCP sender MAY check the compliance of its receivers using the
      probabilistic test periodically and randomly.  In particular, it
      would be advantageous for any sender that is heavily loaded to
|     identify if it is being taken advantage of by non-compliant
|     receivers.


(7b)

The 3rd bullet of Section 6.2.5 says:

OLD:
   o  To perform the test, the sender MUST select a segment N. The
      transmission of this segment MUST be delayed by D places.  D MUST
      lie between 2 and K-2 exclusively where K is the current size of
      the transmit window.  D SHOULD lie between 2 and 6 exclusively
      except in those circumstances when a receiver has failed to
      respond as expected to an earlier test but the sender chooses not
      to proceed to the deterministic test.  D MUST be generated pseudo-
      randomly and unpredictably.  The actual delay SHOULD be such that
      the receiver can't distinguish the test segment from the
      background traffic.  If there are less than D segments worth of
      data in the send buffer then the test should be aborted.

I diagnose abuse of RFC 2119 language here.  (I remember the allegory,
"the IETF has a salt shaker for RFC 2119 language", attributed to such
usage patterns, once applied by one of the authors of that RFC.)
'MUST' should be avoided whenever a protocol entity has no reasonable
alternative behavior to achieve the intended goal.  Thus, I recommend
to get rid of the first two instances of 'MUST' there.
I also strongly recommend to list the preliminary steps required in
one place, at the start of the paragraph.

The phrase, "D SHOULD lie in between 2 and 6 exclusively ..."
IMHO hides the fact that this range for D is rather small, namely
"between 3 and 5 inclusively, i.e. {3,4,5}.
(NB: This small range makes the stated requirement of
 unpredictability questionable for low values of K.)
Since only the upper limit, D < 6, is introduced here as a new
requirement, it might be worth to emphasize that.
(BTW: Since the text deals with natural numbers, it might generally
 be preferable to specify in prose text the much more intuitive
 *inclusive* limits of intervals instead of *exclusive* limits;
 admittedly, in formulae, using '<' is attractive over '<='.)

Finally, the phrase, "the test should be aborted" at the end of the
paragraph seems to be inappropriate.  At this stage, no externally
visible traces of the attempt to perform the test have been created;
all that has been done was to select (within close boundary
conditions) two random integers.  Perhaps, "abolished" or "omitted"
would be better terms than "aborted" here.
As explained later in the draft, not omitting the test when there
are less than D segments in the send buffer incurs a significant
performance penalty and security risk; therefore, in this case I opt
for a stronger requirements language.

Taking altogether, a possible revised version of that bullet is:

NEW:
|  o  To perform the test, the sender selects a segment N and a delay D,
|     in order to delay the transmission of this segment by D places.  D
      MUST lie between 2 and K-2 exclusively where K is the current size
|     of the transmit window.  D SHOULD be less than 6, i.e. be one of
|     3, 4, or 5, except in those circumstances when a receiver has
      failed to respond as expected to an earlier test but the sender
      chooses not to proceed to the deterministic test.  D MUST be
      generated pseudo-randomly and unpredictably.  The actual delay
      SHOULD be such that the receiver can't distinguish the test
      segment from the background traffic.  If there are less than D
|     segments worth of data in the send buffer then the test SHOULD be
|     omitted.

(7c)

For concerns regarding the 4th bullet, see (6) above!

(7d)

The 7th bullet uses sluggish language, not distinguishing properly
between segment numbers (used in the text for explanatory purposes)
and TCP (ACK) sequence numbers (counting octets).
`N` has been introduced as a segment number; hence the following text
gives a wrong indication of a sequence number: "N-1".

   o  If the sender receives any duplicate acknowledgements during a
      testing phase it MUST check to see if they were generated by
|     segment N (i.e. the acknowledged sequence number will be N-1).  If
      they are caused by segment N the sender SHOULD NOT react as if
      they are an indication of congestion.

This text should be revised to use precise language.

(7e)

Various `phases` are always named with a definite article, e.g.
"in the slow start phase", with the exception of the "test phase"
newly introduced by this draft.  I strongly recommend to uniformly
change  "in a test phase"  -->  "in the test phase"  as well, in
subsequent bullets of Section 6.2.5 (4 instances), and in Section
6.3.3 (one instance).

(7f)

In the newly introduced second-to-last bullet, apparently an
"over-shooting" has happened, induced by Section 6.5.1:

OLD:
   o  If a sender is in a test phase and the next segment to be
|     transmitted has either the SYN or RST bits set, then it must
      immediately stop the test, and transmit segment N before
|     transmitting the SYN or RST segment.

The TCP SYN flag is only carried only in the very first TCP segment
sent by either party (not counting possible retransmissions).
It makes absolutely no sense to perform the test for the first
segment since the 3-way-handshake requires the SYN / SYN-ACK
segment at the very beginning of any TCP connection.  Setting SYN
on an outgoing segment later is non-conformant at best -- isn't it?

Note: AFAICS, SYN segments can only be *received* on a synchronized
      TCP connection in case of a sender restart (and for the sender,
      this would have been the first segment of a new connection!);
      protecting against connection abort due to the reception of
      spoofed such segments is what tcpsecure deals with.

The pre-existing text already only allows the test to be performed
for a *data* segment N, thus already excluding its applicability
to the initial (SYN / SYN-ACK) segment of a connection.
To enter the test phase, the sender must already have an existing
connection, and no SYN segment should have to be transmitted then.
Hence, "SYN or" should be removed from the quoted bullet.

Contrary to that, it might be worth considering the FIN flag.
I leave the reasoning as an exercise and just propose to add,
as a catch-all for completeness, the FIN flag to the text,
replacing the two occurrences of FIN:

NEW:                    vvv(7d)
|  o  If a sender is in the test phase and the next segment to be
|     transmitted has either the FIN or RST bits set, then it must
      immediately stop the test, and transmit segment N before
|     transmitting the FIN or RST segment.

The text in Section 6.5.1 should be reconsidered in the light of
these arguments.


(8)  Section 6.3.2

The last sentence in the first paragraph of that section says:

       [...]  A sender would be expected to close a connection with any
   receiver that had failed the deterministic test, but this draft was
   not written to specify what a sender should or must do if a receiver
   fails the test, only how to establish such non-compliance.

IMHO, this phrase partly contradicts the statements made in Section 6.4,
which is the proper place to discuss that topis.
Thus, this sentence should be dropped entirely.


(9)  Section 6.3

Apply (7f) to the second-to-last bullet here as well.


(10)  Section 6.5.1

As explained in item (7f) above, TCP Secure deals with receiver
processing, whereas this draft deals with sender processing only.

It might be true that considering TCP Secure has drawn the
attention to (SYN and) RST, but I do not understand the rationale
given in 6.5.1, under the (accepted) hypothesis that the TCP sender
performing these tests is assumed to follow conformant behavior and
not perform one of the attacks considered in the tcpsecure draft,
against its receiving peer.
Somehow, sending and receiving behavior seem to have been messed up
in the text.

Should I be wrong in this diagnosis, that might be an indication of
that the text needs more elaboration on the topic.
Otherwise, I question whether this section is appropriate.


(11)  Section 6.5.2 -- improper text

The description of the Nagle algorithm is wrong; Nagle deals with
sending only, not with waiting for acknowledgements to send.

The Wikipedia entry for "Nagle Algorithm" contains all you want.
I found it immediately as the number one top entry in YAHOO for
this key-phrase.

Please revise the initial part of Section 6.5.2 accordingly.
And, a ref. to RFC 896 should perhaps be added for this matter.


(12)  Section 6.5 -- important additional consideration

There are important interactions with another TCP extension.
AFAICS, testing should generally not be performed when BETS has
been negotiated in the 3-way-handshake, using TCP Option #20.

BETS (Best Effort Transport Service) is intended for the semi-
reliable transport of bulk data to loss-tolerant receivers,
which are explicitely allowed to send ACKs for non-received /
damaged TCP segments, after exceeding some configurable margins.

For details, please refer to the SCPS-TP specification:
"Space Communications Protocol Specification -- Transport Protocol";
Blue Book, Issue 2; October 2006.  (This is CCSDS 714.0-B-2,
available for download on the CCSDS web site:
    <http://public.ccsds.org/publications/archive/714x0b2.pdf>

(BTW: Thanks to Keith L. Scott, kscott (at) mitre (dot) org, for
pointing me to the Space Data Specifications for the first time!)



Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+



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