Subject: [tsvwg] Comments on SCTP PR policies draft (-02)

From: [email-masked]
Date: Tue, 20 May 2014 09:23:21 +0100

I have read the SCTP PR policies draft
(draft-ietf-tsvwg-sctp-prpolicies-02). This is short and was an easy read,
but I have few comments noted below, and one question.

Best wishes,

Gorry

---

Section 2:

/This section defined/This section defines/

I think this section needs RFC 2119 language - see below, because it
defines protocol mechanisms.

Section 2.1

/The sender must abandon a user message...//The sender MUST abandon a user
message.../

/includes the fast and the timer based/includes both fast and timer-based/

/Limiting the number of retransmissions to 0 is allowed. /
The sender MAY limit the number of retransmissions to 0./

/send any retransmissions either./perform any retransmissions./

/in the WebRTC protocol stack./
- REF needed to this usage.

Section 2.2

/the SCTP stack may abandon other user messages/
- I understand this as a sender-side change, if this is so please be
explicit, otherwise please explain.

/stack may abandon/stack MAY abandon/

/or failing the send call (if used in non-blocking
   mode)./
- unclear to me: does this mean the send call fails?

Section 3.1

/in [RFC6458]/in [RFC6458]./

---

Question on 2.2/security model
- I assume that this mechanism can take transmit opportunity away from
other flows, hence in theory starving another SCTP association of
resource. If this is so, can it be used on a host to mount a DOS attack on
another flow originating from the same sender? - This doesn't seem
serious, given the attacker already needs access to the sending host.

---

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 20 May 2014 10:46:13 +0200

> but I have few comments noted below, and one question.
Hi Gorry,

thank you very much for your comments. See me responses in-line.

Best regards
Michael
> /This section defined/This section defines/
Fixed.
> defines protocol mechanisms.
That implies changing the document from Informational to Proposed Standard.
Is that OK? I'm happy to do that... We even reference this document in
the normative reference section of a document targeting for PS.
> /The sender must abandon a user message...//The sender MUST abandon a user
I agree, but we need to head for PS then...
> /includes the fast and the timer based/includes both fast and timer-based/
Fixed.
> The sender MAY limit the number of retransmissions to 0./
Same as above. PS OK?
> /send any retransmissions either./perform any retransmissions./
Fixed.
> - REF needed to this usage.
Added reference to http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-09
which has also a normative reference to this ID.
> explicit, otherwise please explain.
Changed to

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.

Clear enough?
> /stack may abandon/stack MAY abandon/
See the PS question above.
> - unclear to me: does this mean the send call fails?
Correct. In non-blocking mode the send call returns -1 and the errno
is set to EWOULDBLOCK/EAGAIN.
Could you elaborate on what is not clear such that the text can be improved.
> /in [RFC6458]/in [RFC6458]./
Fixed.
> another flow originating from the same sender? - This doesn't seem
PR-SCTP in general doesn't make an SCTP association more aggressive than
the CC allows. So I don't see a problem with the general mechanism. I also
don't see how you can become more aggressive by using the specific policies
defined in this document.
I don't see how you can take away transmit opportunities from other
associations. Using the SCTP_PR_SCTP_TTL policy you might take transmission
policies from the association away in case of messages abandoning before
they are transmitted, but that makes you send less than allowed, not more.

---

From: [email-masked]
Date: Tue, 20 May 2014 10:52:11 +0100

See response in-line.

Gorry

> That implies changing the document from Informational to Proposed
I don't think so - I can check on whether our AD would sanction use of RFC
2119 language within INFO.

>> The sender MAY limit the number of retransmissions to 0./

The question is really where is the protocol behaviour specified? If it's
in this document then let's do it clearly.

> Added reference to
> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-09
OK

> user messages of the same SCTP association with a priority lower than the
Yes, clear to me.

> Could you elaborate on what is not clear such that the text can be
In that case it is just wording.
Maybe try something like:
/or failing to complete the send call/
or
/or the send call fails/

>> another flow originating from the same sender?
>T his doesn't seem
> don't see how you can become more aggressive by using the specific
> policies defined in this document.
>
I didn't say that - the attack I was speculating about was a host DoS
attack on the stack, not a network DOS attack on capacity.

> associations. Using the SCTP_PR_SCTP_TTL policy you might take
> transmission.
>
Right, so I was hoping you'd say this - which means that you can only
pre-empt flows from the same association? What I'd like to figure-out is
where the "priority" is applied - within a single association or between
entirely separate associations (from different apps).

> they are transmitted, but that makes you send less than allowed, not more.
I got that.

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 20 May 2014 22:53:23 +0200

> See response in-line.
See in-line.

Best regards
Michael
>> user messages of the same SCTP association with a priority lower than the
Great.
> /or failing to complete the send call/
OK. I'm using 'or the send call fails'.
> entirely separate associations (from different apps).
Only within a single association.
>> they are transmitted, but that makes you send less than allowed, not more.
So we don't need additional text, right?

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 21 May 2014 09:52:40 +0100

OK, let's just work on the last topic a little further...

> Only within a single association.
This should certainly be written in the section where you speak of 
priority, and also within the security considerations section.

> So we don't need additional text, right?
It would be good also to note this does not change the CC model for SCTP.

i.e. The CC rules must take into account any loss, even though the 
packet is not retransmitted (that would be the norm for SCTP-PR, 
correct?), but worthwhile saying as a second point in the security 
considerations form a network perspective.

>>>> serious, given the attacker already needs access to the sending host.

I think it may be worth tagging this in the boilerplate as an update to 
RFC 3758, have you considered this - it helps explain this as a simple 
addition.

Gorry

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 21 May 2014 14:03:28 +0200

On 21 May 2014, at 10:52, Gorry Fairhurst <[email-masked]> wrote:

> This should certainly be written in the section where you speak of priority, and also within the security considerations section.
My current text says:

<section title='Priority Policy'
         anchor='prio'>
<t>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 messages of the same SCTP association with a priority lower than the
provided one. ...

So I guess it is addressed in the section where the policy is defined.

We can repeat this in the security section if you want...
> It would be good also to note this does not change the CC model for SCTP.
But this is a consequence of PR-SCTP as defined in RFC 3758, independent from
the particular policy being used. Therefore I think it really doesn't fit here,
since this document only deals with additional policies.
> 
> i.e. The CC rules must take into account any loss, even though the packet is not retransmitted (that would be the norm for SCTP-PR, correct?), but worthwhile saying as a second point in the security considerations form a network perspective.
We can state that, now problem. But from a principle point, we just define points
for abandoning messages, nothing else. But we can make that clear. However, I would
prefer to write this with RFC 2119 language in the text defining that policy.
> I think it may be worth tagging this in the boilerplate as an update to RFC 3758, have you considered this - it helps explain this as a simple addition.
If you want to take the update route, shouldn't it update RFC 3758 (because of adding policies)
and RFC 6458? However, other documents also extending RFC 6458 don't update it...

I'm also not sure if updating RFC 3758 is right. You might want to implement only RFC 3758
without the policies defined in this document. It is an addition...

Best regards
Michael