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

[Magnus Westerlund <[e-mail]>]

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.

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


>>>>
>>>> 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
- Attempting to overflow buffers by including 64k of Strings in Label
and Protocol fields in the OPEN message.
- Attempt to get undocumented behaviour by sending Reliability
Parameters that aren't defined. Or use out of range Priorities or
message types.

But that I guess is most of the things I can think of to attempt to
break the protocol.

Then it is the question of requiring DTLS to ensure it is safe from
Privacy, Confidentiality, Integrity and possibly source authentication
concerns.


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