Subject: [tsvwg] Barry Leiba's Discuss on draft-ietf-tsvwg-sctp-prpolicies-06: (with DISCUSS and COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Mon, 26 Jan 2015 03:09:43 -0800

Barry Leiba has entered the following ballot position for
draft-ietf-tsvwg-sctp-prpolicies-06: 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 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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have four things I'd like to discuss; three are up here, and one is
down in the non-blocking comments.

1. Section 4 says this:

   Please note that this section is informational only.

How are sections 4.2 thru 4.5 not normative?

2. The table in Section 4.2 shows the two policies that come out of RFC
6458 and the two that come from this document.  Is this the time to
create a registry for these?

3. In Section 6, you say that this adds no security considerations.  Are
there really no security considerations introduced by new conditions
under which messages can be abandoned?  And who determines the message
priorities?  Are there no security considerations involved in that
determination?  Is there no discussion at all that might be useful in
determining reasonable values for Limited Retransmission Policy?

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

-- Section 3.1 --

   The Limited Retransmissions Policy can be used with data channels in
   the WebRTC protocol stack.  See [I-D.ietf-rtcweb-data-channel] for
   more information.

This isn't a DISCUSS, because I don't think I want to block the document
on this, but I would like to discuss it:  Is this meant to put
restrictions on where the Limited Retransmissions Policy can be used?  If
so, it should be clearer about that.  If not, what's the reason for this
specific shout-out?

The same question applies to this paragraph from Section 3.2:

   The Priority Policy can be used in the IPFIX protocol stack.  See
   [RFC7011] for more information.

-- Section 3.2 --

   When storing a user message in the send buffer
   while there is not enough available space, the SCTP stack at the
   sender side MAY abandon other user messages of the same SCTP
   association with a priority lower than the provided one.  The
   algorithm for selecting the message being abandoned is implementation
   specific.

A minor point: the first part is written as allowing multiple messages to
be abandoned, and the last sentence is written in the singular.  Should
the second part say "message(s)" ?

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 26 Jan 2015 12:50:51 +0100

> On 26 Jan 2015, at 12:09, Barry Leiba <[email-masked]> wrote:
> 
Barry,

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

Best regards
Michael
> How are sections 4.2 thru 4.5 not normative?
Section 4 (and all the subsections) deal with the socket API. Up to know
the socket API for SCTP has "only" be specified informational. See
the informational RFC
https://tools.ietf.org/html/rfc6458
and the socket API sections in extensions not covered by the above RFC:
https://tools.ietf.org/html/rfc6525#section-6
https://tools.ietf.org/html/rfc7053#section-7
So for consistency it would be good to keep it that way.

The socket API for IPv6
http://tools.ietf.org/html/rfc3542.html
was also done this way.
> create a registry for these?
Hmm. IANA normally doesn't manage values used only in the socket API.
We just specify the name of the constant and leave the numeric value
up to the implementation. Therefore you get portable source code, but
not portable binaries...
> under which messages can be abandoned?  And who determines the message
https://tools.ietf.org/html/rfc3758#section-7
discusses the generic security issues related to using PR-SCTP. I don't
see any additional ones. Please note that the policies are processed
only on the local node only for the affected association. So a user program
using one socket can't hurt a program using other sockets.
> determination?  Is there no discussion at all that might be useful in
I don't see how one association can hurt another...
> determining reasonable values for Limited Retransmission Policy?
That is up to the application. One value (using 0) is discussed in
the second paragraph of
https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-06#section-3.1
but again: I don't see any security related issue from a specific
policy.
It is not meant to put any kind of restrictions on the uses. It is
meant to provide an example where it is used. Data channel can
be configured to use this policy, but they can also use a different
policy or they can be reliable. That is way we used the formulation
"can be used"...
>   [RFC7011] for more information.
Same answer as above. It is meant as an example.
> the second part say "message(s)" ?
Good point. It should read:
   Using the Priority Policy allows the sender of a user message to
   specify a priority.  When storing a user message in the send buffer
   while there is not enough available space, the SCTP stack at the
   sender side MAY abandon other user message(s) of the same SCTP
   association with a priority lower than the provided one.  The
   algorithm for selecting the message(s) being abandoned is
   implementation specific.
OK?

---

From: Barry Leiba <[email-masked]>
Date: Mon, 26 Jan 2015 08:11:42 -0500

Great; thanks for the quick response, Michael.

> the socket API for SCTP has "only" be specified informational.

Ack; I'll clear this.

> up to the implementation. Therefore you get portable source code, but

But is there not any value in having a list of the names that are in
use, with references to where they're defined?  I'll clear this and
move it to a comment; no need to further respond, but please think
about whether it'd be useful (or not) to have an FCFS registry for
these, even if just for reference purposes.

>> under which messages can be abandoned?  And who determines the message
...
> Please note that the policies are processed

Yes, I get that, and I guess that answers any questions about an
attacker inserting priority 0 messages, or the like.  I'll clear this
one too.

On the non-blocking stuff...

>>   the WebRTC protocol stack.  See [I-D.ietf-rtcweb-data-channel] for
...
> policy or they can be reliable. That is way we used the formulation

Ack.  But I wonder whether implementors might misunderstand, and think
it's meant to be restrictive.  Again, no need to further respond...
but please consider changing the wording (here and in 3.2) to
something like this:

NEW
   The Limited Retransmissions Policy was designed to be used with
   data channels in the WebRTC protocol stack (see
   [I-D.ietf-rtcweb-data-channel]), and can also be used in other
   appropriate situations.
END

...or maybe...

NEW
   The WebRTC protocol stack (see [I-D.ietf-rtcweb-data-channel]), is
   an example of where the Limited Retransmissions Policy might be
   used.
END

Thanks.  Off to clear the DISCUSS now.

Barry

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 26 Jan 2015 18:55:28 +0100

> On 26 Jan 2015, at 14:11, Barry Leiba <[email-masked]> wrote:
> 
OK.
> these, even if just for reference purposes.
We do have lots of these, for example the namespace of all SCTP level
socket options. I don't think IANA manages anything like this right now.
And implementations might have additional constants being used. The
number of kernel implementations is small (Linux, Solaris, FreeBSD)
and we get all of these normally involved in a review. So it wasn't
an issue up to now.
>   an example of where the Limited Retransmissions Policy might be
OK. What about:
<t>The WebRTC protocol stack (see <xref target='I-D.ietf-rtcweb-data-channel'/>),
is an example of where the Limited Retransmissions Policy is used.</t>

and

<t>The IPFIX protocol stack (see <xref target='RFC7011'/>) is an example
of where the Priority Policy can be used.</t>

Best regards
Michael

---

From: Barry Leiba <[email-masked]>
Date: Mon, 26 Jan 2015 19:00:11 +0100

> of where the Priority Policy can be used.</t>

Sure, that gets the point across too.  Thanks!

Barry