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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 06 Jul 2020 12:49:27 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-tcpm-rto-consider-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/

----------------------------------------------------------------------
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.)

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.

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?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

As a general note, the style of this document is somewhat divergent from
what I understand to be "modern RFC style".  While there's not a strict
requirement to adhere to such a common style, and I do not have specific
suggestions for changes, it did seem noteworthy.

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.)

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 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.

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.

nit(?): "inconsistent deviations" may be redundant?

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]

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.

        (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.

            There are cases where two copies of some data are
            transmitted in a way whereby the sender can tell which is
            being acknowledged by an incoming ACK.  E.g., TCP's
            timestamp option [RFC7323] allows for segments to be
            uniquely identified and hence avoid the ambiguity.  In such
            cases there is no ambiguity and the resulting samples can
            update the RTO.

Perhaps note that QUIC was designed from the start to avoid the
ambiguity about retransmitted segments?

    (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?

    (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.)

        As with guideline (3), an exception to this rule exists if an
        IETF standardized mechanism determines that a particular loss is
        not due to congestion.

(Same as above.)

Section 5

    Also, note, that in addition to the experiments discussed in [AP99],

nit: s/note, that/note that,/

    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.

    Finally, we note that while allowing implementations to be more
    aggressive could in fact increase the number of needless
    retransmissions the above requirements fail safe in that they insist

nit: I suggest a comma after "needless retransmissions"

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.

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.

    [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.

---

From: "Mark Allman" <[email-masked]>
Date: Tue, 07 Jul 2020 09:52:26 -0400

[resend using better From to get past all the moderation stuff;
 sorry if this is a repeat]

Hi Benjamin!

> 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 ...

> 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.)

> (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.

> 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
>
> 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.

> 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.

> bullet ("does not update or obsolete any existing") trumps this one, but

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.

> 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.

> property does not excuse a lack of explicit mention as a property of

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.

> "segment" feels like use of TCP-specific terminology without disclaimer

(I can change this to 'packet'.)

> If it's a MUST with an exception, doesn't that make it ... no longer a

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.

> 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.

> 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:
>
> 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.

> implies that it should be categorized as normative.  Similarly for RFC

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.

> Fix the typo, please -- RFC 2134 is the articles of incorporation of

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

---

From: "Mark Allman" <[email-masked]>
Date: Tue, 07 Jul 2020 09:49:06 -0400

Hi Benjamin!

(A note can be added.)

Hmm.

allman

---

From: Martin Duke <[email-masked]>
Date: Thu, 9 Jul 2020 08:16:56 -0700

Benjamin and I discussed this briefly in the telechat. I would summarize as
follows:

- We seem to have clear agreement on all but the first DISCUSS point
- We should probably say something about the security implications of
spoofed acks but not be too specific. The document doesn't really have a
section (that I can find right now) that discusses the properties of ACKs,
so perhaps the best place to put this is in security considerations.
Something to the effect of

"An attacker could spoof a sufficient number of receiver messages to either
alter the feedback time calculation, or indicate the receipt of packets
that did not actually arrive at the receiver. Endpoints SHOULD include
measures to make it hard for off-path attackers to guess the fields of
these packets to mitigate this attack"

Together with the agreed fixes, this should be enough to move forward.

Martin

On Tue, Jul 7, 2020 at 8:01 AM Mark Allman <[email-masked]>
wrote:

> .... well, WGAS about the packets?! :)
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Thu, 9 Jul 2020 08:55:09 -0700 (PDT)

> so perhaps the best place to put this is in security considerations.

Isn't it a mistake to discuss in "security considerations" a
topic that is not in the main body of the document?

> these packets to mitigate this attack"

Such an ambigous statement added without discussion of how one might
implment a "measure to make it hard" for an implementer would be
a No-op as I have nothing to base what it is I SHOULD do from this
document, nor any reference to another document.

IMHO, trying to address off-path attacks in this draft is out of scope.  

The specification of those details should be in the transport protocol
itself, not in a generized document such as this, as it is only in
those documents that methods to mitigate attacks can reasonably be
documented.  Perhaps say that "transport protocols SHOULD document
techniques for mitigation against attacks that could perturb the
estimate of RTT"?  But even that is, IMHO, beyond the scope of what
this document should be covering as now it is saying what other
documents should contain.

I understand the desire to say something about the issues of
an off path attack, but is this document really the right place
to try and address that concern?

Regards,
Rodney W. Grimes

-- 
Rod Grimes                                                 [email-masked]

---

From: "Mark Allman" <[email-masked]>
Date: Thu, 09 Jul 2020 12:17:18 -0400

Hello all!

Thanks for all the comments from everyone.  The comments that have
come across except for the below seem small and reasonable for the
most part.  I am way booked until mid-next week, so I'll endeavor to
do a rev then.

> Something to the effect of

I'll take a stab at addressing this and we can iterate.  As I
mentioned previously, some non-normative encouraging seems fine.
Going beyond that seems more thorny, I think.  I'll take a crack at
it and then we'll have something concrete to discuss / beat me with!

allman

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 10 Jul 2020 19:40:15 -0700

>     non-spoofable for FT measurements (among many other reasons, of

[I'll take this one in the ensuing thread]

> important and so getting away from them is fine.

Thanks.

> think about what we can and cannot count on.  And to what degree.

That's why I tried to emphasize my point as being about "the literal
meaning of what these words say".  To say that the only thing that is 100%
fully reliable is the timeout is one thing, but to say that the only thing
we can "count on" has subtly different semantics.  That is, we can rely on
something without it being 100% reliable, and to say that the timeout is
the only thing we can rely on is false.  To say that the timeout is the
only fully reliable signal that we have is (AFAIK) true.

> to make the second bullet more clear would be (in hindsight!)

I look forward to it, thanks.

> been used forever and, yet, deviates from rto-consider.

I may have some small amount of experience with people wanting to
update things that have been used forever and deviate from current best
practices :)
I think (at least from what I can see; maybe I'm off in a bubble) that the
security area has learned to accomodate what cannot be changed without
breaking "everything" as a side effect, but still insist on best practices
where possible (i.e., for new things).  So I'm optimistic that the IETF as
a whole can do so as well.

> through this text and think about it again.

For this one, even "be relied upon ultimately" might be enough (albeit
stilted language).  In my parsing, at least, "can ultimately be relied
upon" is more about "when it comes to the end, it's alwayw an option" than
"is fundamentally reliable".  Maybe something about "detect loss reliably"
would be less stilted, as input for your further thoughts.

> overly specify that one has to do this.

Sure.

> the good reason has to look like.

One thing that people will do is say thing like "with one exception, you
MUST do X.  The exception is Y".  Having the execption as a separate
statement like the current text makes it veer into the territory of
internal inconsistency, whereas the joined-up construction is a coherent
thought.

> is that "exponential backoff" is enough.

Okay.  Thanks for confirming.

> doubt meant to clarify to someone.  But, this discussion can be

Well, I think your discussion here has cleared one thing up for me, at
least -- I totally missed the "steady-state" vs. "initial" distinction the
first time around.

Anyway, to be more clear about what I found ambiguous: the current text
says, paraphrasing "some people do X.  RFC 6298 says to do Y, and X is
less than Y.  This is different than what we say in section 4".  The
ambiguity is about the "this" in "this is different" -- is it X or Y?

Hopefully that helps you clean things up.

> all fails safely because the endpoint will backoff when detecting

Thanks for explaining it like that; I think I get it now.

> I dunno.  The entirety of the algorithm is given in rto-consider.

Ah, I didn't work through it in enough detail to pick that up.

>   update the RTO (see [KP87,RFC6298] for a broader discussion of

Sure, that looks fine.

Thanks again,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 10 Jul 2020 19:55:01 -0700

Hi Rod,

> topic that is not in the main body of the document?

Generally, yes.  What is "the topic" you were thinking of?

I see us talk about using acknowledgments to get RTT samples.  I also see
us talk about how the absence of an ACK is a signal for loss.  However, in
some cases, the inverse is not true: the presence of an ACK is not a
reliable signal for completed delivery.  In other words, best practices for
detecing loss include both being confident there is loss and being confident
there is not loss, and you have to worry about off-path attacks to use
in-protocol ACKs to be confident there is not loss.  Crypto is a great way
to protect your ACKs from off-path attacks, but is not the only way to do
so.

I do note that I qualified my remark with quite a long predicate, and have
not really seen anyone attempting to confirm or reject that predicate as
being the goal of the document.

> IMHO, trying to address off-path attacks in this draft is out of scope.  

Perhaps you could say what you think the scope is, then?

> to try and address that concern?

If you want an accurate loss signal, you need an accurate non-loss signal.
I think it's appropriate to make a note of that, along with some indication
of what's needed to get an accurate non-loss signal, in the context of the
BCP 72 threat model.  Exactly what words we use to give that indication are
not terribly important to me (and I note that anything we say in this
document is subject to the "SHOULD be used by all time-based loss detection
mechanisms" from Section 2, so even nominally MUST-level requirements still
have an escape clause).

-Ben

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Sat, 11 Jul 2020 00:35:35 -0700 (PDT)

Hello Ben,

> Generally, yes.  What is "the topic" you were thinking of?

spoofed acks, or a security precaution regarding acks.

> to protect your ACKs from off-path attacks, but is not the only way to do

The abstract of the document only says "detection of loss" it does not
mention detecting "non loss" so I would consider non loss detection out
of scope.  Further nothing in section 3 mentions your "confident there
is not loss."  Perhaps the scope needs to have that?

Further I see nothing in the section 3 "Scope" that speaks to protection
of ACKs.  It specifically state that this is a "protocol-agnostic" draft,
I would consider an ACK to be protocol specific, in particular it is
specific to several transport protocols that are connection oriented.

Hence I assert speaking of security concerns for ACKs is out of scope,
or additional scope needs added to section 3.

> being the goal of the document.

I would need to go back to that email containing the long predicate
to respond to this.

> Perhaps you could say what you think the scope is, then?

See above, and section 3 of the document.

> If you want an accurate loss signal, you need an accurate non-loss signal.

Then the scope of this document needs amended to say that accurate non-loss
signals are in scope and then go on to define exactly what an accurate non-loss
signal is.

---

From: "Mark Allman" <[email-masked]>
Date: Mon, 27 Jul 2020 11:21:22 -0400

> Something to the effect of

Thanks for all the comments, folks.  I just posted -17.  Several
things ...

  - First, on the main point of Ben's DISCUSS, I added some
    non-normative words to requirement 2a in section 4 to encourage
    the use of ACKs that cannot be readily spoofed.  I ran the text
    by Martin & Ben last week and while I don't want to speak for
    them, both seemed satisfied.  (Ben- The words submitted are
    further honed based on your note.)

  - I take the COMMENTS as suggestions.  The typos and small errors
    were all fixed.  For the larger comments I tried to clarify
    where these indicated that was needed.  But, I didn't change
    something for every comment.  And, I especially didn't try to
    figure out / address the more nebulous comments.

  - I can enumerate the changes based on the COMMENTS, if that's
    useful.  However, my understanding of COMMENTS is that they're
    suggestions and as such I'd much rather just refer you to the
    diffs if you are interested in some specific comment.

Please yell if I missed something.

Thanks,
allman