Subject: [clue] AD evaluation: draft-ietf-clue-datachannel

From: Alissa Cooper <[email-masked]>
Date: Fri, 10 Jun 2016 11:48:58 -0700

I have reviewed this document in preparation for IETF last call. I think it is almost ready. I have a couple of questions I'd like to discuss first and some nits that should be resolved together with any last call comments.

I will note that the security considerations here ultimately rely on draft-ietf-rtcweb-security and draft-ietf-rtcweb-security-arch, which are not finished yet. This means it is hard to fully evaluate this spec at this time. We can proceed with IETF LC after discussion of the questions below, but I would suggest either not proceeding further than that until those documents are done, or developing specific text for this document that documents the security considerations if you don't want to wait.

Questions:

1) In Section 3.2.5, the text says "Other features of [RFC5061] MUST NOT be used." Can you clarify what "other features" this is in reference to? Is this just about the ability to set a primary IP address, or something else? I think it would help to be more specific here.

2) I think Section 3.3 needs to be more clear about whether it is specifying things for all WebRTC data channels, or just for CLUE data channels. 3.3.1 uses the term WebRTC data channel when I would have expected it to use the term CLUE data channel.

3) IF DCEP is out of scope, why do you then say that this specification relies on the security properties of draft-ietf-rtcweb-data-protocol?

Nits:

- Sec. 1

I find it a bit odd to say that DCEP is out of scope here but not mention that negotiation of the CLUE data channel is defined in draft-ietf-clue-signaling. I think at a minimum a reference to the signaling doc is needed, and would also recommend dropping the note about DCEP unless you think you really need it.

- Sec 3.2.3

s/A CLUE entity MUST NOT use the partial reliability and limited retransmission SCTP extensions/A CLUE entity MUST NOT use the partial reliability or limited retransmission SCTP extensions

Thanks,
Alissa

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 12 Jun 2016 17:41:55 +0000

Hi Alissa,

Thanks for your comments! See inline.

> I will note that the security considerations here ultimately rely on draft-ietf-rtcweb-security and draft-ietf-rtcweb-security-arch, which are not finished yet. This
> means it is hard to fully evaluate this spec at this time. We can proceed with IETF LC after discussion of the questions below, but I would suggest either not
> proceeding further than that until those documents are done, or developing specific text for this document that documents the security considerations if you don't want to wait.

I am ok waiting for the generic rtcweb-security drafts to be finished. After that it will be easier to see what/if CLUE data channel specific security text we need to add.

-------------

Questions:

The text refers to the new 'Supported Extensions Parameter' parameter, a generic mechanism for signalling support of SCTP extensions, defined in RFC 5061.

I more or less copied the text from draft-ietf-rtcweb-data-channel:

   "o  The dynamic address reconfiguration extension defined in [RFC5061]
      MUST be used to signal the support of the stream reset extension
      defined in [RFC6525].  Other features of [RFC5061] are OPTIONAL."

So, I guess we could simply refer to that text, and say something like:

    "As defined in [ref-to-draft-rtcweb-data-channel], the dynamic address reconfiguration extension 
     ('Supported Extensions Parameter' parameter) defined in [RFC5061] must be used to signal the 
     support of the stream reset extension defined in [RFC6525]. Other features of [RFC5061]
     MUST NOT be used for CLUE data channels."

Now, if you think that the 'Supported Extensions Parameter' parameter shall be spelt out explicitly, I guess that comment should also be given for draft-ietf-rtcweb-data-channel.

-------------

I can change to "CLUE data channel" in section 3.3.1.

In section 3.3.1.1 I think we shall keep "WebRTC data channel", because the text is about WebRTC data channels in general.

-------------

> 3) IF DCEP is out of scope, why do you then say that this specification relies on the security properties of draft-ietf-rtcweb-data-protocol?

DCEP used to be in scope, and when we made it out of scope it seems like I forgot to remove the text from the security considerations. I will remove the text.

-------------

Nits:

> - Sec. 1
>
> I find it a bit odd to say that DCEP is out of scope here but not mention that negotiation of the CLUE data channel is defined in 
> draft-ietf-clue-signaling. I think at a minimum a reference to the signaling doc is needed, and would also recommend dropping 
> the note about DCEP unless you think you really need it.

The negotiating of the CLUE data channel is defined in draft-ietf-mmusic-data-channel-sdpneg, which the does does reference.

draft-ietf-clue-signaling is more about negotiating the CLUE session in general.

I suggest to keep the test as it is.

-------------

> s/A CLUE entity MUST NOT use the partial reliability and limited retransmission SCTP extensions/A CLUE entity MUST NOT use the partial reliability or limited retransmission SCTP extensions

Will fix as suggested.

-------------

I've created a pull request with the suggested changes:

https://github.com/cdh4u/draft-clue-datachannel/tree/alissa_comments

Thanks!

Regards,

Christer

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 20 Jun 2016 10:48:00 -0700

Thanks Christer, this all looks good. One comment below.

> On Jun 12, 2016, at 10:41 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Alissa,
> 

Ok. If anyone else disagrees, please speak up. Otherwise I think you can publish a revision and I’ll change the state to indicate that we’re waiting on an external document.

Thanks,
Alissa

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Jun 2016 09:25:27 +0000

Hi,

I¹ll fix the other things, and submit a new version.

Thanks!

Regards,

Christer

On 20/06/16 20:48, "Alissa Cooper" <[email-masked]> wrote:

>>> I will note that the security considerations here ultimately rely on
>>>draft-ietf-rtcweb-security and draft-ietf-rtcweb-security-arch, which
>>>are not finished yet. This
>>> means it is hard to fully evaluate this spec at this time. We can
>>>proceed with IETF LC after discussion of the questions below, but I
>>>would suggest either not
>>> proceeding further than that until those documents are done, or
>>>developing specific text for this document that documents the security
>>>considerations if you don't want to wait.
>> 
>> I am ok waiting for the generic rtcweb-security drafts to be finished.
>>After that it will be easier to see what/if CLUE data channel specific
>>security text we need to add.
>
>Ok. If anyone else disagrees, please speak up. Otherwise I think you can
>publish a revision and I¹ll change the state to indicate that we¹re
>waiting on an external document.
>
>Thanks,
>Alissa
>
>
>> 
>> -------------
>> 
>> Questions:
>> 
>> 1) In Section 3.2.5, the text says "Other features of [RFC5061] MUST
>>NOT be used." Can you clarify what "other features" this is in reference
>>to? Is this just about the ability to set a primary IP address, or
>>something else? I think it would help to be more specific here.
>> 
>> The text refers to the new 'Supported Extensions Parameter' parameter,
>>a generic mechanism for signalling support of SCTP extensions, defined
>>in RFC 5061.
>> 
>> Now, if you think that the 'Supported Extensions Parameter' parameter
>>shall be spelt out explicitly, I guess that comment should also be given
>>for draft-ietf-rtcweb-data-channel.
>> 
>> -------------
>> 
>> 2) I think Section 3.3 needs to be more clear about whether it is
>>specifying things for all WebRTC data channels, or just for CLUE data
>>channels. 3.3.1 uses the term WebRTC data channel when I would have
>>expected it to use the term CLUE data channel.
>> 
>> In section 3.3.1.1 I think we shall keep "WebRTC data channel", because
>>the text is about WebRTC data channels in general.
>> 
>> -------------
>> 
>>> 3) IF DCEP is out of scope, why do you then say that this
>>>specification relies on the security properties of
>>>draft-ietf-rtcweb-data-protocol?
>> 
>> DCEP used to be in scope, and when we made it out of scope it seems
>>like I forgot to remove the text from the security considerations. I
>>will remove the text.
>> 
>> -------------
>> 
>> Nits:
>> 
>>> - Sec. 1
>>> 
>>> I find it a bit odd to say that DCEP is out of scope here but not
>>>mention that negotiation of the CLUE data channel is defined in
>>> draft-ietf-clue-signaling. I think at a minimum a reference to the
>>>signaling doc is needed, and would also recommend dropping
>> The negotiating of the CLUE data channel is defined in
>>draft-ietf-mmusic-data-channel-sdpneg, which the does does reference.
>> 
>>> s/A CLUE entity MUST NOT use the partial reliability and limited
>>>retransmission SCTP extensions/A CLUE entity MUST NOT use the partial
>>>reliability or limited retransmission SCTP extensions
>> 
>> Will fix as suggested.
>> 
>> -------------
>>