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

[Roman Shpount <[e-mail]>]

On Tue, Aug 15, 2017 at 10:47 AM, Mirja Kühlewind <[e-mail]>
wrote:

> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-mmusic-dtls-sdp-28: Discuss
>
> 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?
>

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.



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

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.

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

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