Re: Mirja Kühlewind's Discuss on draft-iet f-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT)

Hi Ekr,

thanks for you quick reply. See below.

> Am 15.08.2017 um 18:04 schrieb Eric Rescorla <[email protected]>:
> 
> 
> 
> On Tue, Aug 15, 2017 at 7:47 AM, Mirja Kühlewind <[email protected]> wrote:
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-mmusic-dtls-sdp-28: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> This is nothing big and should be easy to fix:
> 
> On section 7.1, of course...
> "If DTLS is transported on top of a connection-oriented transport
>    protocol (e.g., TCP or SCTP), where all IP packets are acknowledged,
> 
> Incidentally, this text is not true, because IP packets are not necessarily
> acknowledged. It is upper-level PDUs which are acknowledged.

Right! Good catch!
> 
>  
>    all DTLS packets associated with a previous DTLS association MUST be
>    acknowledged (or timed out) before a new DTLS association can be
>    established on the same instance of that transport (5-tuple)."
> I don't think this would be necessary for QUIC. The point here is, I believe,
> not the fact that TCP and SCTP are connection-oriented, but that
> re-transmissions cannot be easily distinguished from the original packet. So
> the point is rather the use of a reliable protocol that retransmits in a
> specific way. However, why would you use DTLS with TCP instead of TLS?
> 
> ICE can switch-hit between UDP and TCP (sometimes mid-connection) and the
> consensus was that it was much easier to run the same protocol over the
> channel below (i.e., DTLS) rather than try to switch between TLS and DTLS.
> 
> 
> And I
> also don't think you want to use DTLS with QUIC because it has it's own crypto.
> 
> Quite possibly, but in that case this whole document just won't apply to QUIC.

Yes.

> 
>  
> I guess the recommendation should rather be that reliable transports should use
> TLS, and if DTLS is needed a new DTLS connection can only be established if
> there is not retransmission ambiguity which is always the case when all
> outstanding packets are ack'ed or considered lost (timed out). 
> 
> It's not just retransmission ambiguity but also reordering. That said, I'm not sure
> this text is going down a useful line, and I'll take a look at that in my review.

Right! Thanks!

> 
> -Ekr
> 
> Or am I missing
> the point?
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> A couple mostly editorial comments:
> - Probably a nit: In section 3.2 'must' is used while in section 3.3 'MUST' is
> used. I would assume that both sections should probably use the same.
> 
> - in sec 5.1: "Because of
>    this, if an unordered transport is used for the DTLS association, a
>    new transport (3-tuple) must be allocated by at least one of the
>    endpoints so that DTLS packets can be de-multiplexed."
> Why is this a 3-tuple (instead of a 5-tuple)? I guess you talk about the source
> address, source port, transport 3-tuple? May say this more explicitly.  Also
> the word of the use transport is confusing to me here because it's used for the
> transport protocol as well as for the transport 'connection' (if a
> connection-oriented transport protocol is used). Maybe s/new transport/new
> flow/? Moreover, there should probably be a 'MUST' here instead of 'must'!
> 
> - sec 5.2:"In addition, the offerer MUST insert in the
>    offer an SDP 'tls-id' attribute with a unique attribute value."
> Is that a MUST or rather a SHOULD? The rest of the text reads like this should
> be a SHOULD.
> 
> - Shouldn't this document cite RFC6347 normatively, e.g. here (sec 5.3):
> "... the answerer MUST initiate a DTLS handshake by sending a
>    DTLS ClientHello message towards the offerer."
> 
> - I would like to see more discussion about linkability based on the
> introduction of the "tls-id" in the security considerations section.
> 
> 
> 

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic