Subject: [tcpm] soft errors comments

From: Mark Allman <[email-masked]>
Date: Mon, 23 Oct 2006 13:50:08 -0400

[chair hat sitting on the auction block ... anyone? ... anyone?
 ... well, regardless, I am not wearing it ...]
 
Fernando-

I read through soft errors this morning.  The following are some
comments:

  - All-in-all I think this document is coming along.  I don't think it
    is quite the TCP-modification-neutral document the WG decided to
    write.  I.e., I think that after reading the document one could
    certainly get the impression that changing soft errors to hard
    errors in SYN states is the intent of the document.

  - E.g., in the abstract you talk about the document "describ[ing] a
    modification" to TCP.  While one could argue that the text is not
    wrong or that the text does not say a change is being made, I think
    this sort of language is suggestive.  I think it would be more clear
    to say that the document "does not change TCP's standard response to
    ICMP messages, but sketches a non-standard, but widely-used change
    to TCP".

    This more explicit language could help things everywhere you discuss
    a "modification".

  - In addition, when you spell out the change in section 4 I think it
    would be nice if you could add a small blurb that notes this change
    is widely implemented, but that the IETF could not come to consensus
    on changing the standard behavior.  Basically, reasonable people
    disagreed.

  - I'd like to see the enumeration of "soft errors" in the intro.  You
    have it buried in section 4, which makes the reader wonder for a few
    pages what you are actually talking about.

  - In the intro you might note that "fault isolation" is done using
    methods besides ICMP messages (rexmt count, time).  I.e., ICMPs are
    not the only way.

  - Intro: "it documents a modification" --> "it documents a
    non-standard, but widely-used modification"

  - It is weird that you quote RFC2119 for the meaning of MUST, etc.,
    but the only place you use those terms is in paraphrasing of
    RFC1122---which came out before the definitions.

  - I found this sentence confusing:

      In case the connection times out before the segment is
      acknowledged, TCP won't be able to provide more information than
      the timeout condition.

    What do you mean?

  - "TCP will use this information" --> "TCP may use this information"

    (In general, statements of fact from [Stevens] should probably be
    tempered.  I.e., [Stevens] is not a standard and while it certainly
    describes implemented and known behavior it does not describe
    absolute requirements.)

  - "attempts would be inappropriate" --> "attempts may be
    inappropriate"

    That is, if a SYN gets lost in the network we all just eat that now
    without wailing on the reload button.  If a SYN gets lost many times
    then we are less patient, of course.

  - I also found [Shneiderman], [Thadani] and [Guynes] to be sort of
    tenuous references, although I would not necessarily suggest getting
    rid of them.  In 3.1 these seem to be connected to "the web", but
    they are not about the web.  I think you can probably find some
    words to say these studies are suggestive of people's behavior
    without making it too concrete.

  - Section 4: "It must be noted that this behavior" ...  what behavior?
    I do know you mean the "workaround", but better words could be used
    here.

  - I found 5 to be suboptimal.  In particular, you are bringing up
    alternatives and yet not in a neutral way.  You are basically
    arguing them all down---and, using some pretty hand wavy stuff.
    
    E.g., the last paragraph of 5.1 is a big hand-wave.  Probably
    non-interactive connections just don't care about any of this
    stuff.  And, then you are trying to make judgments about the user's
    "likely" satisfaction.  This paragraph is unneeded.  

    You did the general discussion earlier as to the drawbacks of
    waiting.  If you want to put something in the intro of section 5
    that reminds us of that main drawback then OK.

  - Of course, "the workaround" weakens security.  Saying that it does
    not is dis-ingenuous, I think.  The workaround sets up a case
    whereby a connection can be aborted more quickly than it could using
    standard TCP.  That is a *security consideration*.  It doesn't
    matter if it is slight or you have a fix for the general ICMP attack
    problem or whatever.  It ought to be noted.  And, the document
    surely should not say that TCP is not weakened.

  - I am not sure nsynrexmt is new, as you note.  There is likely a
    retransmit counter already in most stacks.  (And, while you're in
    the 3WHS it doesn't seem like you'll be counting anything by the
    SYN.)

  - "not solving the problem" --> "not entirely solving the problems"
    (surely, it helps)

  - In A.2 you note "all" apps need changed.  It's not clear to me that
    all apps would care about this problem.

  - In A.3 you note that parallel SYNs would make it hard to distinguish
    normal connection from DoS.  Exactly how many IP addresses do you
    think a name is going to have?  I think either your IP address count
    is way too high or your notion of a DoS attack is not high enough.
    That is, a DoS attack is going to send more than a handful of SYNs
    or it isn't going to DoS.  I suggest just removing this.

I hope those are somehow helpful.

allman

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