[MMUSIC] Mirja Kühlewind's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT)

[Mirja Kühlewind <[e-mail]>]

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,
   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? And I
also don't think you want to use DTLS with QUIC because it has it's own crypto.
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).  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.