Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-12

From: Christer Holmberg <[email-masked]>
Date: Sat, 21 May 2016 16:02:52 +0000

Hi,

I've submitted a new version (-12) of draft-ietf-mmusic-dtls-sdp.

The new version contains some additional restrictions regarding the establishment of a new DTLS association.

Also, as message size again seems to matter, I've changed the name of the attribute from 'dtls-association-id' to 'dtls-id'.

GitHub: https://github.com/cdh4u/draft-dtls-sdp (individual repo)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 May 2016 12:39:02 -0400

On 5/21/16 12:02 PM, Christer Holmberg wrote:
> Hi,
>
> I’ve submitted a new version (-12) of draft-ietf-mmusic-dtls-sdp.

This generally seems good.

> establishment of a new DTLS association.

I have a slight issue with how this was done. In section 5.1 is the 
following new text:

    When an answerer needs to establish a new DTLS association, if
    unreliable transport is used, and if the offerer did not allocate a
    new transport, the answerer MUST allocate a new transport for the
    offer in answer a way that it can disambiguate any packets associated
    with new DTLS association from any packets associated with any other
    DTLS association.  This typically means using a local address and or
    port, or a set of ICE candidates (see Section 6), which were not
    recently used for any other DTLS association.

I agree with the point of this, but the qualifier "if unreliable 
transport is used" doesn't seem to be the right one. I don't think the 
issue has anything to do with unreliability. For instance I don't think 
it would apply if using unreliable SCTP streams. I think the real issue 
is that UDP is not a connection-oriented transport.

I'm not sure what language to use here that would cover the *right* 
other non-UDP protocols. (AFAIK there are none that qualify.) If you 
can't come up with something I guess I would make this UDP-specific.

Note there is similar text with the same problem in Section 6.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Tue, 24 May 2016 13:39:30 -0400

On Tue, May 24, 2016 at 12:39 PM, Paul Kyzivat <[email-masked]>
wrote:

> I agree with the point of this, but the qualifier "if unreliable transport
> is used" doesn't seem to be the right one. I don't think the issue has
> anything to do with unreliability. For instance I don't think it would
> apply if using unreliable SCTP streams. I think the real issue is that UDP
> is not a connection-oriented transport.
>
> I'm not sure what language to use here that would cover the *right* other
> non-UDP protocols. (AFAIK there are none that qualify.) If you can't come
> up with something I guess I would make this UDP-specific.
>

This is actually the problem with either unreliable or un-ordered delivery
properties of the protocol. If it is known that all packets for DTLS
association have already been delivered (or failed to deliver) to the
remote party, then this protocol can be reused for the new DTLS
association. If it is known that DTLS packets for new association will be
delivered after packets for old DTLS association, then transport can be
reused for new DTLS association. For UDP, only the first condition can be
satisfied, provided that reasonable time have passed since the last packet
was sent and no packets for existing DTLS association are left in flight
over the network. For SCTP, if receipt confirmation was received for all
the DTLS packets for a given association, the same SCTP connection can be
reused for the new DTLS association. If in-order SCTP channel is used for
DTLS, then SCTP channel can also be reused for the new DTLS association.

Taking a step back, there are three protocols which can be in used in
practice to carry DTLS:

1. UDP

2. TCP with RFC 4571 framing. This protocol should be considered
unreliable, non-connection oriented since it is typically used to bridge
with UDP

3. SCTP. DTLS over SCTP is defined in RFC6083 and most likely broken. It is
also, as far as know, is not used by anybody in conjunction with
offer/answer.

What we are trying to do in this paragraph is carve out DTLS over SCTP
without explicitly naming it. Do you think it would be better if define
this as "if unreliable or un-ordered transport is used"?

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 May 2016 14:07:48 -0400

On 5/24/16 1:39 PM, Roman Shpount wrote:
> On Tue, May 24, 2016 at 12:39 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     transport is used" doesn't seem to be the right one. I don't think
>     the issue has anything to do with unreliability. For instance I
>     don't think it would apply if using unreliable SCTP streams. I think
>     the real issue is that UDP is not a connection-oriented transport.
>
> This is actually the problem with either unreliable or un-ordered
> delivery properties of the protocol. If it is known that all packets for
> DTLS association have already been delivered (or failed to deliver) to
> the remote party, then this protocol can be reused for the new DTLS
> association. If it is known that DTLS packets for new association will
> be delivered after packets for old DTLS association, then transport can
> be reused for new DTLS association. For UDP, only the first condition
> can be satisfied, provided that reasonable time have passed since the
> last packet was sent and no packets for existing DTLS association are
> left in flight over the network. For SCTP, if receipt confirmation was
> received for all the DTLS packets for a given association, the same SCTP
> connection can be reused for the new DTLS association. If in-order SCTP
> channel is used for DTLS, then SCTP channel can also be reused for the
> new DTLS association.
>
> 3. SCTP. DTLS over SCTP is defined in RFC6083 and most likely broken. It
> is also, as far as know, is not used by anybody in conjunction with
> offer/answer.
>

I'm happy if the words cover the specific relevant conditions. Given 
your explanation, I guess "unreliable or un-ordered" works.

I'm a little unclear about SCTP in this regard. IIUC RFC6083 does the 
DTLS setup over a reliable, ordered-delivery stream. So the concerns 
here wouldn't apply to it. So are you considering some other potential 
DTLS over SCTP mapping?

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Tue, 24 May 2016 15:05:36 -0400

On Tue, May 24, 2016 at 2:07 PM, Paul Kyzivat <[email-masked]> wrote:

> I'm happy if the words cover the specific relevant conditions. Given your
> explanation, I guess "unreliable or un-ordered" works.
>
> I'm a little unclear about SCTP in this regard. IIUC RFC6083 does the DTLS
> setup over a reliable, ordered-delivery stream. So the concerns here
> wouldn't apply to it. So are you considering some other potential DTLS over
> SCTP mapping?
>

This is exactly what I am saying: If DTLS is running over SCTP with
reliable, ordered delivery stream, then DTLS packet disambiguation is not a
problem and new DTLS association can always be established over an existing
transport. In fact RFC6083 says that SCTP should be reused for new DTLS
associations. Because of this, if answerer wants to establish a new DTLS
association and offer contains an SCTP transport, answerer can reuse the
SCTP transport for new DTLS association.

If DTLS is running over UDP (unreliable and un-ordered), transport
disambiguation concerns do apply. This means either offerer or answerer
MUST allocate new address/port or set of candidates when new DTLS
association is established. Furthermore, if ICE is used and offerer did not
initiate an ICE restart, new DTLS association MUST NOT be  established,
since new transport cannot be allocated and packets cannot be disambiguated.

Regards,
______________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 May 2016 16:05:56 -0400

On 5/24/16 3:05 PM, Roman Shpount wrote:
> On Tue, May 24, 2016 at 2:07 PM, Paul Kyzivat <[email-masked]
>     I'm a little unclear about SCTP in this regard. IIUC RFC6083 does
>     the DTLS setup over a reliable, ordered-delivery stream. So the
>     concerns here wouldn't apply to it. So are you considering some
>     other potential DTLS over SCTP mapping?
>
>
> reliable, ordered delivery stream, then DTLS packet disambiguation is
> not a problem and new DTLS association can always be established over an
> existing transport. In fact RFC6083 says that SCTP should be reused for
> new DTLS associations. Because of this, if answerer wants to establish a
> new DTLS association and offer contains an SCTP transport, answerer can
> reuse the SCTP transport for new DTLS association.
>
> association is established. Furthermore, if ICE is used and offerer did
> not initiate an ICE restart, new DTLS association MUST NOT be
>  established, since new transport cannot be allocated and packets cannot
> be disambiguated.

So there is no known transport, other than UDP, where this concern applies?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 May 2016 20:09:49 +0000

Hi,

>> not a problem and new DTLS association can always be established over 
>> an existing transport. In fact RFC6083 says that SCTP should be reused 
>> for new DTLS associations. Because of this, if answerer wants to 
>> establish a new DTLS association and offer contains an SCTP transport, 
>> answerer can reuse the SCTP transport for new DTLS association.
>>
>> disambiguation concerns do apply. This means either offerer or 
>> answerer MUST allocate new address/port or set of candidates when new 
>> DTLS association is established. Furthermore, if ICE is used and 
>> offerer did not initiate an ICE restart, new DTLS association MUST NOT 
>> be  established, since new transport cannot be allocated and packets 
>> cannot be disambiguated.
>

You can have unreliable/unordered SCTP too, can't you?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 24 May 2016 16:11:26 -0400

On Tue, May 24, 2016 at 4:05 PM, Paul Kyzivat <[email-masked]> wrote:

> There are other unreliable unordered transports out there, like ATM AAL5.
I am not sure anybody is concerned about using DTLS over AAL5 at this
point, but this can potentially work and have similar issues to DTLS over
UDP.

P.S. I have no practical experience with ATM, so this is all fairly
theoretical to me.
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 May 2016 13:17:04 -0700

On 24 May 2016 at 12:05, Roman Shpount <[email-masked]> wrote:
> disambiguation concerns do apply.

The concern is the ordered delivery, not reliability.  It's the
possibility that you might get a packet from the last connection after
you start with the new connection.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 May 2016 16:19:35 -0400

> You can have unreliable/unordered SCTP too, can't you?

Yes, but there is no DTLS mapping defined for it. The DTLS mapping in 
6083 says that all the DTLS control messages must go over a reliable, 
ordered, stream 0. (The data can go over other streams with other 
properties.)

So it would take a different DTLS mapping over SCTP to cover this. It is 
hard to imagine why anyone would do this.

I still agree that in principle some new transport could be defined 
where this concern would apply. But no such is currently known or foreseen.

Maybe this doesn't need to change the wording at all. (But adding 
"unordered" does seem worthwhile.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 May 2016 20:27:17 +0000

Hi,

>>>> reliable, ordered delivery stream, then DTLS packet disambiguation 
>>>> is not a problem and new DTLS association can always be established 
>>>> over an existing transport. In fact RFC6083 says that SCTP should be 
>>>> reused for new DTLS associations. Because of this, if answerer wants 
>>>> to establish a new DTLS association and offer contains an SCTP 
>>>> transport, answerer can reuse the SCTP transport for new DTLS association.
>>>>
>>>> answerer MUST allocate new address/port or set of candidates when 
>>>> new DTLS association is established. Furthermore, if ICE is used and 
>>>> offerer did not initiate an ICE restart, new DTLS association MUST 
>>>> NOT be  established, since new transport cannot be allocated and 
>>>> packets cannot be disambiguated.
>>>
> 6083 says that all the DTLS control messages must go over a reliable, ordered, stream 0. (The data can go over other streams with other
> properties.)

True. Comment withdrawn.

>So it would take a different DTLS mapping over SCTP to cover this. It is hard to imagine why anyone would do this.
>
>I still agree that in principle some new transport could be defined where this concern would apply. But no such is currently known or foreseen.
>
>Maybe this doesn't need to change the wording at all. (But adding "unordered" does seem worthwhile.)

Yes. 

And, based on Martin's latest comment, perhaps removing "unreliable".

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 May 2016 06:29:22 +0000

Hi,

Based on the comments on -12, we would replace ³unreliable² with
³unordered² in sections 5.1 and 6.

Ok?

Regards,

Christer

On 24/05/16 23:27, "mmusic on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]>
wrote:

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 May 2016 10:13:47 -0400

> ³unordered² in sections 5.1 and 6.

WFM