Subject: [tsvwg] Stephen Farrell's No Objection on draft-ietf-tsvwg-sctp-prpolicies-06: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 03 Feb 2015 05:52:11 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-tsvwg-sctp-prpolicies-06: No Objection

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 http://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:
http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/

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

So I assume the ability to say "please re-tx this 2^32-1
times" is said to not introduce any new security
consideration, because that is not sent over the wire.
However, could there not be a DoS against a kernel from
userland? And if that limit is set based on some WebRTC JS
(is it? I don't know) then wouldn't that be a way to DoS a
browser and possibly the other end of a WebRTC data channel
too?

So, perhaps noting the above would be good, as well as
saying that implementations SHOULD or MUST have a limit that
they enforce on the max number of re-tx's? (Apologies if
that is there already and I missed it.)

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 3 Feb 2015 15:22:14 +0100

> On 03 Feb 2015, at 14:52, Stephen Farrell <[email-masked]> wrote:
> 
Hi Stephen,

thank you very much for your review. Please see my comments in-line.

Best regards
Michael
> http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/
The retransmission policy defined in
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-06#section-3.1
limits the number of retransmissions, it doesn't enforce them:
  "Using the Limited Retransmission Policy allows the sender of a user
   message to specify an upper limit for the number of retransmissions
   for each DATA chunk of the given user messages."
The rate at which it is retransmitted is controlled by the normal
SCTP congestion and flowcontrol. Also the number of retransmissions
might be limited by other SCTP procedures. So this policies can make
the number of retransmissions smaller than it would be without
using it, but not larger. Therefore the term "upper limit" in the
above sentence.
> userland? And if that limit is set based on some WebRTC JS
At least not by using a PR-SCTP policy. An application can try
to call send() as fast as possible, but the kernel has methods
of defending itself: Return -1 and set errno to EWOULDBLOCK
in case of a non-blocking socket or send operation, or the
kernel can just block it.
> browser and possibly the other end of a WebRTC data channel
I don't see know. Using any PR-SCTP policy will result in
giving up sending a message earlier than normal SCTP would do.
> that is there already and I missed it.)
There are mechanisms in the base protocol which still apply
here. It is not formulated in a limit of retransmissions,
but as a limit of consecutive retransmissions. See
https://tools.ietf.org/html/rfc4960#section-8.1

I can add a sentence to
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-06#section-3.1
stating:

Please note that using this policy does not affect the handling of the
thresholds 'Association.Max.Retrans' and 'Path.Max.Retrans' as specified
in Section 8 of [RFC 4960].

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 03 Feb 2015 14:26:25 +0000

Hi Michael,

> in Section 8 of [RFC 4960].

That would have helped me, (because of my ignorance:-) but since
it's stated already I'm entirely fine if you add or or not, as
you prefer.

Cheers,
S.

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 3 Feb 2015 15:29:47 +0100

> On 03 Feb 2015, at 15:26, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi Michael,
> 
Since it would have helped, I've added it to CVS version, so it will
be in the update rev.

Best regards
Michael