Re: [rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03

[Michael Tuexen <[e-mail]>]

On 15 Apr 2014, at 17:55, Magnus Westerlund <[e-mail]> wrote:

> Hi,
> 
> Please see inline for replies.
> 
> On 2014-04-10 13:50, Michael Tuexen wrote:
>> On 04 Mar 2014, at 17:39, Magnus Westerlund <[e-mail]> wrote:
>> 
>>> On 2014-02-25 17:07, Michael Tuexen wrote:
>>>> 
>>>> On Feb 24, 2014, at 5:32 PM, Magnus Westerlund <[e-mail]> wrote:
>>>>> 1. Section 4:
>>>>> Shouldn't this section discuss the priority field?
>>>> I added in the list of consistent properties:
>>>> 
>>>> <t>the priority of the data Channel.</t>
>>>> 
>>>> and in the text below that enumeration:
>>>> 
>>>> ??????
>>> 
>>> Yes, text for this needs to be figured out.
>> We don't define at this place what priority is. The only point is that both
>> sides use the same priority.
> 
> Okay, I agree, the Priority is a property of the established Data
> Channel, and the values and implication of these needs to be defined in
> the Data Channel draft and not here.
OK. The only thing we might want to change in this ID is the type of the
Priority field. It is currently a signed integer, we might want to use
an unsigned integer. But that is a different issue, which I'll need to
discuss with Randell.
> 
>>> 
>>>>> 
>>>>> 2. Section 4:
>>>>> 
>>>>> The method
>>>>> used to determine which side uses odd or even is based on the
>>>>> underlying DTLS connection role when used in WebRTC, with the side
>>>>> acting as the DTLS client using even stream identifiers.
>>>>> 
>>>>> Isn't this unnecessary using the vague word of WebRTC instead of simply
>>>>> pointing to the DTLS roles of the established data channel?
>>> 
>>>> The point is that in the WebRTC you use DCEP/SCTP/DTLS/UDP and therefore
>>>> you can refer to the DTLS role. However, you could use DCEP/SCTP/IP
>>>> or DCEP/SCTP/UDP/IP or DCEP/SCTP over something not involving DTLS.
>>>> In that case DTLS is not used and you can not refer to the DTLS role.
>>>> That is why the restriction is used.
>>> 
>>> Ok, if that concern then you still should be able to write a normative
>>> specification under the condition that it is SCTP over DTLS. If not how
>>> do you determine that? Are suggesting just to hand way or point to a
>>> higher signaling layer.
>> So what about using:
>> 
>> when using <xref target='I-D.ietf-tsvwg-sctp-dtls-encaps'/>, the method used to
>> determine which side uses odd or even is based on the underlying DTLS
>> connection role: the side acting as the DTLS client MUST use Streams with even
>> SCTP stream identifiers, the side acting as the DTLS server MUST use Streams
>> with odd SCTP stream identifiers.</t>
> 
> I think that is fine for when using over DTLS. And to my understanding
> this do require DTLS? If not we need alternative text.
Our current use-case is for SCTP/DTLS. But we don't need DTLS except for
its security properties. However, if someone doesn't use DTLS, he has to
figure out how to determine the even/odd. This is covered by:

<t>To avoid glare in opening Channels, each side MUST use Streams with 
either even or odd SCTP stream identifiers when sending a DATA_CHANNEL_OPEN
message.
When using <xref target='I-D.ietf-tsvwg-sctp-dtls-encaps'/>, the method used to
determine which side uses odd or even is based on the underlying DTLS
connection role: the side acting as the DTLS client MUST use Streams with even
SCTP stream identifiers, the side acting as the DTLS server MUST use Streams
with odd SCTP stream identifiers.</t>

However, we can't provide a method in the general case...
> 
> 
>>>>> 
>>>>> 4. Section 5.1:
>>>>> Label: Variable Length (sequence of characters)
>>>>>    The name of the channel.  This may be an empty string.
>>>>> 
>>>>> Protocol: Variable Length (sequence of characters)
>>>>>    The protocol for the channel.  If this is an empty string the
>>>>>    protocol us unspecified.  If it is an non-empty string, it
>>>>>    specifies an IANA-registered protocol (see Section 8.4).
>>>>> 
>>>>> Both of these fields are strings, shouldn't a particular encoding be
>>>>> specified here? Like UTF-8. Secondly, what values are allowed, the full
>>>>> set of Unicode?
>>> 
>>>> You are right. Any need for restrictions? We only need to be able to
>>>> transform it to a DomString.
>>>> So I changed it to:
>>>> 
>>>> <t hangText='Label: Variable Length (sequence of characters)'>
>>>> <vspace blankLines='0'/>
>>>> The name of the channel as a UTF-8 encoded string.
>>>> This may be an empty string.</t>
>>>> 
>>>> <t hangText='Protocol: Variable Length (sequence of characters)'>
>>>> <vspace blankLines='0'/>
>>>> The protocol for the channel as a UTF-8 encoded string.
>>>> If this is an empty string the protocol us unspecified.
>>>> If it is an non-empty string, it specifies an IANA-registered protocol
>>>> (see <xref target='iana_protocol'/>).</t>
>>> 
>>> I guess this is slightly overtaken by event. It have to be aligned with
>>> what the websocket sub-protocol identifier.
>> The text now reads:
>> <t hangText='Protocol: Variable Length (sequence of characters)'>
>> <vspace blankLines='0'/>
>> The sub-protocol for the channel as a UTF-8 encoded string.
>> If this is an empty string the protocol is unspecified.
>> If it is a non-empty string, it specifies an protocol registered in the
>> 'WebSocket Subprotocol Name Registry' created in
>> <xref target='RFC6455'/>.</t>
> 
> Ok.
> 
>>> 
>>>>> 
>>>>> 5. Section 6:
>>>>> All Data Channel Establishment Protocol messages MUST be sent
>>>>> requesting ordered delivery and using reliable transmission.
>>>>> 
>>>>> I wonder of the use of requesting ordered delivery and using reliable
>>>>> transmission, from an SCTP stream perspective, wouldn't using in both
>>>>> places be appropriate? Or is how object which has been requested to be
>>>>> transmitted unordered interact in SCTP with the ordered ones?
>>> 
>>>> I'm sorry, I don't understand what you are asking...
>>> 
>>> Sorry, it really is a language issue. The above sentence first states
>>> "sent 'requesting' ordered" and later "and 'using' reliable".
>>> 
>>> This inconsistency is what I reacted to.
>> I see. Changed to:
>> <t>All Data Channel Establishment Protocol messages MUST be sent using
>> ordered delivery and reliable transmission.
> 
> Ok
> 
>>> 
>>>> 
>>>>> 6. Section 7:
>>>>> 
>>>>> I think this section can be beefed up a bit. First make clear that the
>>>>> Data Channel's required usage of DTLS ensures that the message integrity
>>>>> and possible source authentication as well as confidentiality. Then
>>>>> going over any security risks with a malicous peer using this protocol.
>>>>> Can a malicous side screw up the peer using this protocol? What are the
>>>>> implications?
>>> 
>>>> Just to double check: Aren't the referenced documents the ones which
>>>> discuss all security stuff in one place?
>>> 
>>> The security document do discuss system level important aspects. But,
>>> from my perspective, details that are very specific to this protocol
>>> should be discussed in this document.
>>> 
>>> I think this is highly relevant in this document as there are others
>>> that are interested in using it.
>> OK. Any concrete suggestions what should be covered?
> 
> I can at least think of potentially relevant issues:
> 
> - Exhaustion attacks by opening all 64k Data channels
You setup 64k streams anyway and it wasn't a problem...
> - Attempting to overflow buffers by including 64k of Strings in Label
> and Protocol fields in the OPEN message.
OK.
> - Attempt to get undocumented behaviour by sending Reliability
> Parameters that aren't defined. Or use out of range Priorities or
> message types.
This is also covered explicitly in the Procedures section by

<t>If a DATA_CHANNEL_OPEN message is received on an already used SCTP stream or
there are any problems with parameters within the DATA_CHANNEL_OPEN message or
the DATA_CHANNEL_OPEN message itself is not well-formed,
the receiver MUST close the corresponding channel using the procedure described
in <xref target='I-D.ietf-rtcweb-data-channel'/> and MUST NOT send a
DATA_CHANNEL_ACK message in response to the received message.
> 
> But that I guess is most of the things I can think of to attempt to
> break the protocol.
I agree.
> 
> Then it is the question of requiring DTLS to ensure it is safe from
> Privacy, Confidentiality, Integrity and possibly source authentication
> concerns.
Sure.

So what about the following Security Considerations section:
<t>The DATA_CHANNEL_OPEN messages contains two variable length fields:
the protocol and the label. A receiver must be prepared to receive
DATA_CHANNEL_OPEN messages where these field have the maximum length of
65535 bytes. Error cases like the use of inconsistent lengths fields,
unknown parameter values or violation the odd/even rule must also be handled
by closing the corresponding channel. An end-point must also be prepared
that the peer open the maximum number of data channels.</t>
<t>When using DCEP over SCTP encapsulated in DTLS as specified in
<xref target='I-D.ietf-tsvwg-sctp-dtls-encaps'/>, security properties
like privacy, integrity, and source authentication can be provided by DTLS.
If DCEP is used without running over DTLS, this is not the case.</t>
<t>For general considerations see <xref target='I-D.ietf-rtcweb-security'/> and
<xref target='I-D.ietf-rtcweb-security-arch'/>.</t>

Does this address your issues?

Best regards
Michael
> 
> 
>>>>> 
>>>>> 11. This comments concerns the relation to the Data Channel
>>>>> specification. So my interpretation is that the WebRTC Data channel
>>>>> draft has become both the base for this specification as well as the one
>>>>> that specifies that the DCEP shall be implemented and supported. For
>>>>> WebRTC I don't think this matters much, but if someone likes to re-use
>>>>> the basic Data Channel specification, this structure makes it more
>>>>> difficult and have no need for the bi-directional negotiated parameter
>>>>> settings that the DCEP provides. In that case one have to sub-set the
>>> 
>>>> I think the data channel draft discusses the data channels independent
>>>> how they are opened. This covers data parameters, user data transmission
>>>> and closing of data channels. The data channel protocol draft discusses
>>>> an in-band protocol for setting up data channels.
>>> 
>>> I think this was discussed today. And make it clear that DCEP
>>> requirement shouldn't be from the Data Channel spec.
>>> 
>>>>> data channel specification. I wonder if it would be better to move some
>>>>> normative statements around, so that the chain of implementation
>>>>> requirement goes draft-ietf-rtcweb-transports ->
>>>>> draft-ietf-rtcweb-data-protocol -> draft-ietf-rtcweb-data-channel thus
>>>>> providing a cleaner and more modular build up of the protocols.
>>>> I think you can implement draft-ietf-rtcweb-data-channel without
>>>> draft-ietf-rtcweb-data-protocol, but not vice versa.
>>>> 
>>>> So you don't like the statement:
>>>> 
>>>>  A simple protocol for internal negotiation is specified in
>>>>  [I-D.ietf-rtcweb-data-protocol] and MUST be supported.
>>>> 
>>>> from draft-ietf-rtcweb-data-channel. What would you suggest?
>>> 
>>> I think the high level requirement on DCEP might be in -rtcweb-transports.
>> It now reads:
>> A simple protocol for in-band negotiation is specified in [I-D.ietf-rtcweb-data-protocol].
> 
> 
> Ok
> 
> 
> Cheers
> 
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
> 
>