Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sctp-sdp-14 - Magnus' comments

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Mar 2015 13:08:07 +0000

Hi Magnus,

Thanks for your comments! See inline.

-----------

1. Section 1:

>   NOTE: TLS is designed to run on top of a byte-stream oriented
>   transport protocol providing a reliable, in-sequence delivery like
>   TCP.  [RFC6083] presents serious limitations with transporting SCTP
>   on top of TLS.  Therefore, defining a mechanism to negotiate media
>   streams transported using SCTP on top of TLS is outside the scope of
>   this specification.
>
> Isn't this all written backward. Shouldn't this paragraph talk about TLS on top of SCTP? I also think you need to reference the actual specification for TLS over SCTP, i.e RFC 3436. My impression is that this paragraph should say the following:
>
>   NOTE: TLS is designed to run on top of a byte-stream oriented
>   transport protocol providing a reliable, in-sequence delivery like
>   TCP.  [RFC6083] presents serious limitations with transporting TLS
>   on top of SCTP [RFC3436].  Therefore, defining a mechanism to
>   negotiate media streams transported using TLS on top of SCTP, i.e.
>   'SCTP/TLS', is outside the scope of this specification.

Correct. Will be fixed.

-----------

2. Section 4.3:

>   [RFC4566] defines that specifications defining new proto values must
>   define the rules by which their media format (fmt) namespace is
>   managed.  Use of an existing MIME subtype for the format is
>   encouraged.  If no MIME subtype exists, it is recommended that a
>   suitable one is registered through the IETF process [RFC6838]
>   [RFC4289] by production of, or reference to, a standards-track RFC
>   that defines the transport protocol for the format.
>
> I get very confused by this paragraph, it looks by a quote from RFC4566 on something that applies on this format, however, I fail to find any text in RFC4566 that relates to "Use of an existing MIME subtype for the format is encouraged."
>
> So is this a rule that applies for these protos? Considering how the fmt string is defined, usage of MIME types are not give, and can also collide with the created registrations.
>
> So what is the intention with the paragraph?

****

-----------

3.  Section 4.4.2:

> Indentation error for tcp-port

Will be fixed.

-----------

4. Section 4.4.2:

> What is the definition of port and token?
>
> Assuming that it is the SDP token, I think you need the lines:
>
> token = <As defined in RFC4566>
> port  = <As defined in RFC4566>

I suggest to say:

	"token and port as defined in RFC4566."

-----------

5. Section 5.1:

> The attribute can be associated with an SDP media description (m-
>  line) with a 'UDP/DTLS/SCTP' or a 'TCP/DTLS/SCTP' proto value, in
>  which case the m- line port value indicates the port of the
>  underlying transport-layer protocol (UDP or TCP), on which SCTP is
>  carried, and the 'sctp-port' value indicates the SCTP port.
>
> Shouldn't the "which" in "in which case the m- line port" be a "that", as that part is necessary, while the next which can actually be removed without changing the actual meaning of the sentence.

So, something like:

	"The attribute can be associated with an SDP media description (m-
	line) with a 'UDP/DTLS/SCTP' or a 'TCP/DTLS/SCTP' proto value. In
 	that case the m- line port value indicates the port of the
	underlying transport-layer protocol (UDP or TCP), and the 'sctp-port' 
	value indicates the SCTP port."

-----------

6. Section 6.2:

>       max-message-size-attr =  "a=max-message-size:" max-message-size
 >      max-message-size      =  1*DIGIT
>
> I have to wonder why max-message-size doesn't have an upper boundary in the number of digits it can contain. What I can read out of the SCTP 
> specification, there are actually no upperbound for the SCTP messages.
>
> But, I would think that we actually want parsers to have a chance of saying no, there is an error here and refuse to parse further. I suggest that max-message-size = 1*40DIGIT. That 
> allows for messages which requires more than 132 bits to be specified as an unsigned integer.

I have no problem to add an upper boundary, if others are ok.

> Otherwise, I will want to test your parsers by giving them an SDP which in this field contains a base64 encoded binary linux distribution. If they can't at least successfully parse it they are not spec compliant ;-).

Perhaps 4566bis should define a generic max value for attributes? Currently I don't think there is any limit.

-----------

7. Section 9.3.3:

>   If the underlying transport protocol is modified, the endpoints MUST
>   establish a new DTLS connection.  In such case the 'active/passive'
>   status of the endpoints will again be determined following the
>   procedures in [RFC4145], and the new status will be used to determine
>   the (D)TLS roles of the endpoints associated with the new DTLS
>   connection.
>
> I don't understand what "modified" in the above paragraph actually included.
>
> So, I would assume switching from UDP/DTLS/SCTP to TCP/DTLS/SCTP is modified.

Correct.

> I also can believe that changing the port or address for the UDP/TCP is such a modification.

Correct.

> But, what about updating ICE candidates?
> What happens if new candidate pairs are promoted?

Currently, if the IP address and/or port is changed (e.g. if you change candidate pair), that IS a transport protocol modification.

However, this is currently discussed in the "DTLS, DTLS-SRTP, and 5-tuples" thread on the RTCWEB list. A "virtual connection" concept is discussed, where a connection could span multiple 5-tuples (the 5-tuple of each associated candidate pair). That means that e.g. a single DTLS connection could span multiple 5-tuples (you can send ClientHello on one 5-tuple, receive a ServerHello on another 5-tuple, etc), and you would not have to re-establish the DTLS connection if you move from one candidate to another.

Yes, that discussion DOES belong to MMUSIC, and hopefully it will be "moved" there :)

-----------

8. Section 10.2:

>   o  MUST, if the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP'
>      or 'TCP/DTLS/SCTP', associate an SDP setup attribute, with an
>      'actpass' value, with the m- line (see Section 9.3);
>
> Why is "actpass" required? There is nothing in Section 9.3 that causes a situation that requires the offerer to use actpass.

The reference to section 9.3 is more for the description of the attribute.

The reason for mandating "actpass" is because RFC 5763 does it for DTLS-SRTP.

-----------

9. section 10.2 and Section 10.3:

> What about 'holdconn'. It must at least be possible to give in an answer. Per RFC 4145 it appears legal to offer also.

I guess we could say that, if 'holdconn' is used, it means that neither the underlaying  transport protocol, nor any DTLS connection, nor any protocols running on top of DTLS are established.

-----------

10. Section 13.1:

> You must fix the indentation issues in the examples.

Will be fixed.

-----------

11. Section 14.:

>   This specification does not introduce new security considerations in
>   addition to those defined in the specifications listed above.
>
> I don't believe this. You are specifying two protocol combinations that aren't specified in any of the referenced drafts: "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". At a minimum this requires consideration of any security issues in [I-D.ietf-tsvwg-sctp-dtls-encaps].

Correct, that needs to be added:

	"[RFC4960] defines general SCTP security considerations, while
	[RFC6083] defines security considerations when using DTLS on top of
	SCTP, and [I-D.ietf-tsvwg-sctp-dtls-encaps] defines security 
	considerations when using SCTP on top of DTLS."

> I also would prefer if you actually had done the work to summarize all the more significant issues for the combinations that this document specifies.

So, you want a summary of the security considerations for UDP, TCP, SCTP, DTLS, SCTP-over-DTLS and DTLS-over-SCTP?

-----------

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Mar 2015 13:15:14 +0000

Hi,

Seems like I forgot to reply to one of your comments:

-----------

> So what is the intention with the paragraph?

Paul contributed this text, so I'll ask him to answer first :)

-----------

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Mar 2015 18:48:39 -0400

> Seems like I forgot to reply to one of your comments:

I was certainly involved in discussions of this, but I can't currently 
find them. (How long ago was it???)

Reviewing 4566 again, while it does "encourage" use of existing MIME 
types (and registration of new ones when no existing one will do) for 
*UDP*, it *doesn't* do that for other proto values. It does require that 
rules for interpretation of the <fmt> MUST be defined when registering a 
new proto. So such rules for the SCTP protos defined in this draft must 
also be defined in this draft.

It seems that section 15.3 is intended to serve this purpose, together 
with section 4.4.2 (ABNF of m-line) that shows only a single <fmt> value 
is allowed. The MIME type registry (or syntax) are not being used - a 
new registry is being created. So I agree that the above text needs some 
rework.

	Thanks,
	Paul