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

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 15 Aug 2017 07:47:23 -0700

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.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Aug 2017 09:04:08 -0700

> https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/

Incidentally, this text is not true, because IP packets are not necessarily
acknowledged. It is upper-level PDUs which are acknowledged.

> 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

Quite possibly, but in that case this whole document just won't apply to
QUIC.

> 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

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 15 Aug 2017 18:32:46 +0200

Hi Ekr,

thanks for you quick reply. See below.

> Am 15.08.2017 um 18:04 schrieb Eric Rescorla <[email-masked]>:
> 
> 
> 
> On Tue, Aug 15, 2017 at 7:47 AM, Mirja Kühlewind <[email-masked]> wrote:

Right! Good catch!
> Quite possibly, but in that case this whole document just won't apply to QUIC.

Yes.

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

---

From: Roman Shpount <[email-masked]>
Date: Tue, 15 Aug 2017 13:59:01 -0400

> outstanding packets are ack'ed or considered lost (timed out).  Or am I

This whole section was added because of RFC6083  (DTLS over SCTP, not to be
confused with SCTP over DTLS). I am not sure if anybody implemented DTLS
over SCTP with SDP based negotiation so this language is highly
theoretical. The issue is that DTLS over SCTP as it is defined in RFC6083
is not compatible with DTLS over UDP. Essentially RFC6083 removes
re-transmission logic from DTLS stack and uses re-transmission logic in
SCTP. It also states that a single SCTP association should be reused for
multiple DTLS associations and DTLS association cannot span across multiple
underlying transports. The intention of this text was to say that for DTLS
over SCTP implementation should use different procedures since it is,
essentially, different DTLS (without re-transmission logic). We have tried
to generalize the language, but I am not sure the result is quite clear. My
preference at the time was not cover DTLS over SCTP in this draft at all.
Since EKR  is reviewing this, and since he is one of RFC6083 authors, he
can probably suggest a better language.

This text does not apply to DTLS over TCP. DTLS over TCP is primarily used
for ICE TCP candidates. In this case transport is still treated as
unreliable un-ordered for two reasons:

a. ICE can switch between candidates and transports, so when switch from
UDP to TCP candidate pair occurs DTLS still needs to handle re-transmission
or out of order packets. Even switching between two TCP candidates can
result in un-ordered packet delivery.

b. DTLS over TCP is often single hop, where TCP connection is terminated by
SBC and UDP being used on the other leg. DTLS association in this cases
continues to be end-to-end and will have to deal with re-transmission and
out of order packets.

I do not think we even though about QUIC here but most likely QUIC will not
be used used with DTLS.

> flow/? Moreover, there should probably be a 'MUST' here instead of 'must'!

Each end point allocates a 3-tuple for connection (transport/address
/port). Connections are disambiguated using 5 tuple (transport/source
address/source port/destination address/destination port). We can make this
more explicit.

> Is that a MUST or rather a SHOULD? The rest of the text reads like this

Implementations compliant with this specification MUST insert tls-id in
offers and respond with answer with tls-id if tls-id was present in the
offer. This is how end points indicate that they support this specification.

Regards,
_____________
Roman Shpount