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

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.



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



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

-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