Re: [tcpm] Benjamin Kaduk's Discuss on draft-ietf-tcpm-rto-consider-16: (with DISCUSS and COMMENT)

Mark Allman <mallman@icsi.berkeley.edu> Tue, 07 July 2020 13:49 UTC

Return-Path: <mallman@icsi.berkeley.edu>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8553E3A0CCE for <tcpm@ietfa.amsl.com>; Tue, 7 Jul 2020 06:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icsi-berkeley-edu.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpbdV3vNmhGB for <tcpm@ietfa.amsl.com>; Tue, 7 Jul 2020 06:49:10 -0700 (PDT)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2134B3A0CCC for <tcpm@ietf.org>; Tue, 7 Jul 2020 06:49:10 -0700 (PDT)
Received: by mail-ot1-x329.google.com with SMTP id h1so12167182otq.12 for <tcpm@ietf.org>; Tue, 07 Jul 2020 06:49:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icsi-berkeley-edu.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=EX6bq//cay5hE/MWN8Jbm/Cmt4dGLrkPuHsdSLmW/o0=; b=tmp2Z3kLKIA/fkxK6wiocgqQJzOI0bnT60Z/5+3xX+Sc5CHH9Cc6mkcHAebcYkr2P5 LCMLUvCMUxV2DwEZFEqxjNRXjUuQ9tyex3V9SjPBZ6ePNuJVJmXYhqUjlaLKQck/Yhtr zJipPW6iADqBBp7/PKIm0cthPD8b9cQWVe+xSq7XsYHafKiZLTiBQmrO7nMGDjr/zIo3 uFxL6m/7KiTUNqDPv1dIKk6aPz4hfHNlYPOxarQc0rK6AtAeOWWs81l4oFNvTCv8ZPVx LzorOWmffDXKKB2V+KW87zESIcwtYTHQQEiOxfF+S4GyNmI/eDHViGvQ9iiWruH9TgvA G1Uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=EX6bq//cay5hE/MWN8Jbm/Cmt4dGLrkPuHsdSLmW/o0=; b=MqNNCJCuDanDWsOzE2frtIiwd/Wx8AstaijZXV3C9wk0Nq24vhzf8QMWhdDKmOfHG1 B//0koPvFy7hCwcJ0FmwW+y+6Ykf0/QkZdTZdbMpmtwxMh/AmS1yThqYJmE9SZKz57CK BU75zBQiktGOD8UoWqx2ZEJf9OnZCOoeK6wjImPbjchsuE1pxuqRZc2r0Pnga2XMijC9 5lGSiAPJvyleET9VWu9kze+ngaAYSNomgYzVHFMWVi/HKUxXFeuhXS9AJb6s8Tgiy8w3 YHn/GNnKw0/5mFytEd4bA+B1fTFGM4WOGjiWR58dVycBlMBu3DtV2E81bh/Wdh0+7h97 CBYw==
X-Gm-Message-State: AOAM531LEFjJLT84uVWAevpQ8IYrlSuxlGMhbp1rFlzWUHogkscsUQ3R jQj8XeC88tavEyb+T2rHbt/WBw==
X-Google-Smtp-Source: ABdhPJxBfbyuhGqRB23IbEFJwAu/2E6mGuNEPw6U1pp1MAf+fHJllOEy+cEmo4aUL9ZcUOpKSneaFA==
X-Received: by 2002:a9d:611d:: with SMTP id i29mr17913325otj.42.1594129748930; Tue, 07 Jul 2020 06:49:08 -0700 (PDT)
Received: from [192.168.1.244] ([2600:1700:b380:3f00:5ca4:49cf:6dbb:2f5f]) by smtp.gmail.com with ESMTPSA id i11sm144486oom.9.2020.07.07.06.49.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jul 2020 06:49:08 -0700 (PDT)
From: Mark Allman <mallman@icsi.berkeley.edu>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Tue, 07 Jul 2020 09:49:06 -0400
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <97326820-187D-4A67-BBF0-CC58FAF18F0B@icsi.berkeley.edu>
In-Reply-To: <159406496706.24848.1574717471798101163@ietfa.amsl.com>
References: <159406496706.24848.1574717471798101163@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_D90801A7-890B-4E29-B915-5156ACFE2E06_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/xzjTCyxIg5ILyjHQ1SIzTn9KVT0>
X-Mailman-Approved-At: Tue, 07 Jul 2020 08:01:07 -0700
Subject: Re: [tcpm] Benjamin Kaduk's Discuss on draft-ietf-tcpm-rto-consider-16: (with DISCUSS and COMMENT)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jul 2020 13:49:14 -0000

Hi Benjamin!

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> If we are providing BCP-level requirements for time-based loss
> detection via absence of protocol-level acknowledgment, for new
> protocols, it seems appropriate to mandate that the acknowledgment
> signal is reliable, i.e., not spoofable by at least an off-path
> attacker, and ideally not spoofable by an on-path attacker either.
> I would love for this to be a cryptographically protected
> mechanism, but expect that I can't get away with mandating
> something that strong, and that something with "enough bits of
> entropy" will suffice.  (I'd prefer "enough" to be 128 but could
> perhaps be persuaded that a lower value is appropriate as a
> minimum requirement.)

I have been thinking about this since yesterday and have a few
thoughts ...

  - In some sense, I like the general thought.  It would tighten
    things up.

  - That said, pragmatically, I think the risk from spoofed ACKs is
    pretty small.  For instance, if you want to screw up the RTO you
    need to pretty continuously screw up the FT measurements for
    anything long running.  So, it isn't enough to guess and inject
    correctly once, but you have to do so on an ongoing basis.  And,
    with much less than 128 bits of entropy something like TCP is
    not particularly susceptible to this sort of thing.

  - And, so we can obviously make up a requirement for future
    protocols here, but I don't think that will be a "BCP" or even
    "CP".  It would not be like the rest of the document where the
    aspects of loss detection are well understood.

  - And, we'd have to decide what we meant by "new protocol".  Is
    that some wholly new thing or is that a new algorithm for SCTP
    or TCP or DNS?

  - Perhaps there is some non-normative note that could be added
    that folks are encouraged to think about making the feedback
    non-spoofable for FT measurements (among many other reasons, of
    course).  I dunno ...

> Point S.3 in Section 3 indicates that "[t]he requirements in this
> document apply only to endpoint-to- endpoint unicast
> communication.  Reliable multicast (e.g., [RFC5740]) protocols are
> explicitly outside the scope of this document."  This limitation
> of scope should be reflected in the document's title, Abstract,
> and Introduction.

(A note can be added.)

> I would also like to get an explicit confirmation that the various
> (non-)requirements on the details of exponential backoff and
> reduced weighting for old FT samples are as-intended (see
> COMMENT).  Specifically, are there limitations on the base of the
> exponent for the exponential backoff, and is there a requirement
> to give more recent FT samples more precedence than older FT
> samples when computing an RTO estimate?

Yes- the intent is to not specify the details.  The basic gist of
the document is that we have learned that the details are not hugely
important and so getting away from them is fine.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Abstract
>
>     of congestion along a network path).  While many mechanisms have
>     been designed to detect loss, protocols ultimately can only count on
>     the passage of time without delivery confirmation to declare a
>     packet "lost".  Each implementation of a time-based loss detection
>
> I'm not entirely convinced that the literal meaning of what these
> words say is universally true for all protocols (specifically "can
> only count on" and omitting a qualifier such as "many" or "most"
> protocols or "reliably count on").  Consider, for example, the DTN
> bundle protocol, which has some circumstances in which a given
> store-and-forward node will flat-out not attempt to forward a
> protocol onward to its final recipient, but can send back a status
> report to the sender noting the confirmed lack of delivery.  I
> suggest adding some form of qualifier to admit the possibility of
> such unusual situations.
>
> Section 1
>
>     missing.  However, despite our best intentions and most robust
>     mechanisms we cannot place ultimate faith in receiving such
>     acknowledgments, but can only truly depend on the passage of time.
>     Therefore, our ultimate backstop to ensuring that we detect all loss
>     is a timeout.  [...]
>
> Despite the superficial similarity of tone, a strict reading of
> these words does not seem to share the issue I raised about the
> Abstract.  (That said, this phrasing still seems a bit overblown
> and my personal preference would be to tone it down some.)

The point is objectively true and actually meant to be absolute.
Yes, an explicit non-delivery notification can be sent.  Such
notifications may be useful and even quite important.  But,
ultimately, we cannot be rely upon such things to ensure reliable
communications because they themselves may get lost, corrupted,
delayed, etc.  But, if time somehow stops marching forward then
... well, WGAS about the packets?! :)

Too me this is a crucial protocol building touchstone.  One has to
think about what we can and cannot count on.  And to what degree.

> Section 2
>
>       - This document does not update or obsolete any existing RFC.
>         These previous specifications---while generally consistent with
>         the requirements in this document---reflect community consensus
>         and this document does not change that consensus.
>
>       - The requirements in this document are meant to provide for
>         network safety and, as such, SHOULD be used by all time-based
>         loss detection mechanisms.
>
> I'm not sure that I understand how the combinations of these two
> statements apply to existing specifications.  Is there some sense that
> existing specs might leave some flexibility and when there is such
> flexibility, implementations/deployments SHOULD use the flexibility to
> match this document as closely as possible?  Or are existing deployments
> and implementations of existing RFCs also grandfathered out?  If the
> intent of the second bullet is to only apply to new protocols, please
> say so explicitly.  (Section 4 seems to imply the "only new protocols"
> case, but it's hard to be sure.)

The first bullet is intended to be backwards looking and the second
bullet is intended to be forward looking.  A few extra words there
to make the second bullet more clear would be (in hindsight!)
useful.

>       - The requirements in this document may not be appropriate in all
>         cases and, therefore, inconsistent deviations and variants may
>         be necessary (hence the "SHOULD" in the last bullet).  However,
>         inconsistencies MUST be (a) explained and (b) gather consensus.
>
> Similarly, is this statement only forward-looking?  Presumably the first
> bullet ("does not update or obsolete any existing") trumps this one, but
> it's good to be clear.

Yes- forward looking.  Clarifying words to be added.

> Additionally, I share the GenART reviewer's unease with this
> strong of a requirement and have low confidence that the IETF will
> reliably adhere to it in the future.

In fairness to Stewart---even though I disagree with him---I think
his point is broader than just non-adherence.  (Stewart and I have
iterated on his comments and in fact a number of his LC comments
made the document better.  But, on this point we just fundamentally
disagreed.)

I don't presume to speak for Stewart, but I believe he fears this
will become a touchstone for area-on-area warfare whereby perfectly
justifiable deviations won't be well understood as "perfectly
justifiable" by folks not intimate with the given context.  And,
this will in turn hold things up.  And, he seems especially
concerned about cases where we want to update something that has
been used forever and, yet, deviates from rto-consider.

My take is three-fold ...

  - First, this statement in rto-consider really doesn't change
    anything, IMO.  If we're not explaining why we're doing things
    and not getting consensus then we shouldn't be publishing it.

  - Second, this explicit statement was added to get WG consensus.
    Removing it or softening it would, I believe, run counter to the
    consensus the document has already gathered.

  - Third, IMO, saying a given mechanism has proven to be fine in a
    given context should really be enough justification.  That is,
    yeah, I can see that some protocol lawyer could be pedantic.
    And, that might be annoying, I guess.  But, I think reasonable
    people should be able to form a consensus that rebuts such
    things.

> Section 3
>
>     (S.1) The requirements in this document apply only to the primary or
>           last resort time-based loss detection.
>
> I'm not sure I understand what "primary or last resort [sic]" means.
> Are there time-based loss-detection mechanisms that are neither primary
> nor last resort?  (nit: hyphenate "last-resort" as a compound adjective,
> and many other compound adjectives throughout.)
> (May also affect S.2.)
> I see S.2 links to [DCCM13,CCDJ20,IS20] as examples of non-primary
> non-last-resort schemes, however, I think we should be more clear about
> what we mean when we introduce the term and why we exclude certain
> classes of time-based loss-detection mechanisms.
>
>           detectors.  However, these mechanisms do not obviate the need
>           for a "retransmission timeout" or "RTO" because---as we
>           discuss in Section 1---only the passage of time can ultimately
>           be relied upon to detect loss.  In cases such as these, the
>
> [This text is more like the Abstract's, implying that the passage of
> time is the only way to detect loss, universally]

I dunno.  I would have to think about this a bit.  As you say, we
tried to sprinkle in references to non-last-resort timers.  Perhaps
there are some words we can add here to explain things better.
You're the first one to trip on this.  But, I'd be happy to go
through this text and think about it again.

> Section 4
>
>             In other words, the RTO should represent an empirically-
>             derived reasonable amount of time that the sender should
>             wait for delivery confirmation before deciding the given
>             data is lost.  Network paths are inherently dynamic and
>             therefore it is crucial to incorporate multiple FT samples
>             in the RTO to take into account the delay variation across
>             time.
>
> It feels weird to say that the delay will vary over time here but say
> nothing about the corresponding need to discount very old FT samples.
> Point (b) talks about adding new samples in, but not about removing or
> discounting old samples.  That the TCP example does exhibit this
> property does not excuse a lack of explicit mention as a property of
> note.

I think a note that says "it's fine to discount old samples" is OK
and perfectly within the spirit of the guideline.  I don't want to
overly specify that one has to do this.

>         (d) An RTO mechanism MUST NOT use ambiguous FT samples.
>
>             Assume two copies of some segment X are transmitted at times
>             t0 and t1 and then at time t2 the sender receives
>             confirmation that X in fact arrived.  In some cases, it is
>
> "segment" feels like use of TCP-specific terminology without disclaimer
> or generalization.

(I can change this to 'packet'.)

>     (3) Loss detected by the RTO mechanism MUST be taken as an
>         indication of network congestion and the sending rate adapted
>         using a standard mechanism (e.g., TCP collapses the congestion
>         window to one segment [RFC5681]).
>         [...]
>         An exception to this rule is if an IETF standardized mechanism
>         determines that a particular loss is due to a non-congestion
>         event (e.g., packet corruption).  In such a case a congestion
>
> If it's a MUST with an exception, doesn't that make it ... no longer a
> MUST?

I don't think so.  But, you're no doubt a better protocol lawyer
than I am.  I believe this says you really have to do this, but
there is a **very precise way** to get out of it.  If we made this a
SHOULD then it would be very much looser---i.e., you really ought to
do this unless you have a good reason.  Here we are telling you what
the good reason has to look like.

>     (4) Each time the RTO is used to detect a loss, the value of the RTO
>         MUST be exponentially backed off such that the next firing
>         requires a longer interval.  [...]
>
> Do we expect this to be exponential backoff by doubling, or is it
> admissible to use an alternative base for the exponent?  (Is there
> a minimum allowable value?  E.g., 1.000001 does not seem like it
> would provide much protection for the network.)

The document does not say to double the RTO.  It means to not
specify the constant.

Again, the document is meant to get away from specifics where we
can.  I don't know how to set the minimal acceptable backoff.  I
think we'd all agree 1.000001 is not really going to cut it.  But,
would 1.8?  How about 1.7?  What about 1.3?  I believe the consensus
is that "exponential backoff" is enough.

>     Further, a number of implementations use a steady-state minimum RTO
>     that are less than the 1 second specified in [RFC6298] (which is
>     different from the initial RTO we specify in Section 4, Requirement
>     1).  While the implication of these deviations from the standard may
>
> Just to check: our requirement 1 is the same as RFC 6298, and the "less
> than 1 second" is what's different.  Perhaps wording this akin to "and
> as such is in violation of the RTO specified in Requirement 1 from
> Section 4" would avoid the ambiguity about what is different from what.

Well.  Um.  I read it many times, but cannot understand what you
wrote about the document's ambiguity! ;-) Maybe that is my lack of
coffee, I dunno.  But, let me try anyway ...

RFC 6298 says the INITIAL RTO should be no less than 1sec.  That
agrees with rto-consider (requirement 1).

RFC 6298 further says the MINIMUM RTO over the entire lifetime of a
TCP connection should be no less than 1sec.  There is no
corresponding admonishment in rto-consider.

Probably because these two things are both "1sec" in TCP a lot of
people have gotten them mixed up in their minds during the
development of this document.  The parenthetical you quote was no
doubt meant to clarify to someone.  But, this discussion can be
cleaned up, probably.

> Section 6
>
> Noting that we incorporate the security considerations of RFC 6298
> by reference, and quoting from there:
>
>    In addition, even if the attacker can cause the sender's RTO to reach
>    too small a value, it appears the attacker cannot leverage this into
>    much of an attack (compared to the other damage they can do if they
>    can spoof packets belonging to the connection), since the sending TCP
>    will still back off its timer in the face of an incorrectly
>    transmitted packet's loss due to actual congestion.
>
> Just to check my understanding: this "actual congestion" would
> need to be between the sender and the attacker, right?  Since the
> attacker's spoofed ACKs would cause the sender to not detect loss
> due to congestion that occurs between the attacker and the
> intended recipient.

Oh boy.  My brain is thrashing to try to page back in RFC6298.

The above text isn't the most clear, so I assume I didn't write
it. :)

Hmm.

I think the basic point is that if an attacker can spoof they can do
much worse than impacting the computation of the RTO.  And, if what
they want to do is mess with a connection's performance and not the
reliability of the connection---say because that'd be
user-visible---then they cannot hide real losses.  And, since they
cannot hide real losses then from a network safety perspective this
all fails safely because the endpoint will backoff when detecting
those losses.

> References
>
> The way we cite [KP87] ("MUST use Karn's algorithm [KP87,RFC6298]")
> implies that it should be categorized as normative.  Similarly for RFC
> 6298 itself.

I dunno.  The entirety of the algorithm is given in rto-consider.
So, the reference is really meant to give credit and point people at
a place to read about it in more detail instead of as a pointer that
must be understood to enact the guideline.  Perhaps just a
restructuring ...

  Therefore, in this situation an implementation MUST use Karn's
  algorithm and use neither version of the FT sample and hence not
  update the RTO (see [KP87,RFC6298] for a broader discussion of
  Karn's algorithm).

Or, put them under "Normative".  I really don't much care.

>     [RFC3124] Balakrishnan, H., S. Seshan, "The Congestion Manager", RFC
>         2134, June 2001.
>
> Fix the typo, please -- RFC 2134 is the articles of incorporation of
> ISOC.

Well, I do not want to be anywhere near ISOC anything!  Good catch,
thanks!  (And, what a weird typo ... all the digits are there, but
in such a weird order ...)

allman