Subject: [MMUSIC] draft-holmberg-mmusic-sdp-dtls-00

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Jun 2015 13:52:12 -0400

(Resending. I initially sent to wrong address.)

Christer, I'm glad that you have submitted this document - it is needed. 
I have a few comments.

Section 5.1 starts out talking about the 'connection' attribute, but 
gives no reference. There should be a reference to RFC4145.

In section 6.3:

In the 2nd sentence ("The same...'new'...) *that* occurrence of 'new' 
should be 'existing'.

Then the following paragraph:

    If the answerer does not accept the establishment (or re-
    establishment) of the DTLS association, it MUST reject the offer
    [RFC3264].

isn't right. The answerer may reject the m-line while still accepting 
the offer. (I expect that is what was intended, but it doesn't say that.)

I'd also like to dig a bit more into forking. As noted in section 4.5, 
if forking occurs, then separate DTLS associations will be made with 
each callee. In this case, those distinct DTLS associations will share 
common host candidates. (Can they also end up sharing some relay 
candidates?) Yet the 5-tuples will differ.

Now, suppose that the same endpoint then needs to make a change. For 
instance, maybe it needs to change its fingerprint. In this case it 
needs to create new DTLS associations. In that case it must also use new 
host candidates. Is it permitted to use the same (new) candidates to 
recreate *both* DTLS associations? I can't see any reason why not. I 
also don't see any specific prohibition in the text. But it would be 
good to be explicit about it.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Wed, 17 Jun 2015 16:18:45 -0400

On Wed, Jun 17, 2015 at 1:52 PM, Paul Kyzivat <[email-masked]> wrote:

>
> I'd also like to dig a bit more into forking. As noted in section 4.5, if
> forking occurs, then separate DTLS associations will be made with each
> callee. In this case, those distinct DTLS associations will share common
> host candidates. (Can they also end up sharing some relay candidates?) Yet
> the 5-tuples will differ.
>

The 5-tuples would typically be different and that should be enough for
de-mux. Sharing the same host or relay candidates should not be a problem.

One thing to keep in mind, would be that if allocation of new relay
candidates is done before the exciting relay candidates are released, then
new relay candidates will be different. If relay candidates are released
before allocation, then relay candidates can end up being the same, which
can cause problems. Relay candidates that were closed due to being unused
by previous ICE session, can be reused since no existing DTLS traffic would
be flowing over them. The same closing order restriction also applies to
the host candidates. Otherwise if you release local host candidates before
allocating new one, you might end up with the same local address/ports
combinations.

> instance, maybe it needs to change its fingerprint. In this case it needs
> to create new DTLS associations. In that case it must also use new host
> candidates. Is it permitted to use the same (new) candidates to recreate
> *both* DTLS associations? I can't see any reason why not. I also don't see
> any specific prohibition in the text. But it would be good to be explicit
> about it.
>

If I understand what you are asking, It is possible to use the same host
candidates to update multiple DTLS associations that are created due to
forking. The only requirement is that when DTLS association is updated, the
set of host and related candidates (relay, reflexive) is new for
communications within this specific m= line on connection to this specific
end-point. The end goal is to create a new 5-tuple. This being said, such
usage would be fairly uncommon.

_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Jun 2015 06:11:35 +0000

Hi,

I guess I don’t have too much to add to what Roman said.

But, from a DTLS perspective, forking is the same as e.g. call transfer. Also in that case the local candidates may stay the same, while the remote ones change.

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 17. kesäkuuta 2015 23:19
To: Paul Kyzivat
Cc: IETF MMUSIC WG
Subject: Re: [MMUSIC] draft-holmberg-mmusic-sdp-dtls-00

On Wed, Jun 17, 2015 at 1:52 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

I'd also like to dig a bit more into forking. As noted in section 4.5, if forking occurs, then separate DTLS associations will be made with each callee. In this case, those distinct DTLS associations will share common host candidates. (Can they also end up sharing some relay candidates?) Yet the 5-tuples will differ.

The 5-tuples would typically be different and that should be enough for de-mux. Sharing the same host or relay candidates should not be a problem.

One thing to keep in mind, would be that if allocation of new relay candidates is done before the exciting relay candidates are released, then new relay candidates will be different. If relay candidates are released before allocation, then relay candidates can end up being the same, which can cause problems. Relay candidates that were closed due to being unused by previous ICE session, can be reused since no existing DTLS traffic would be flowing over them. The same closing order restriction also applies to the host candidates. Otherwise if you release local host candidates before allocating new one, you might end up with the same local address/ports combinations.

Now, suppose that the same endpoint then needs to make a change. For instance, maybe it needs to change its fingerprint. In this case it needs to create new DTLS associations. In that case it must also use new host candidates. Is it permitted to use the same (new) candidates to recreate *both* DTLS associations? I can't see any reason why not. I also don't see any specific prohibition in the text. But it would be good to be explicit about it.

If I understand what you are asking, It is possible to use the same host candidates to update multiple DTLS associations that are created due to forking. The only requirement is that when DTLS association is updated, the set of host and related candidates (relay, reflexive) is new for communications within this specific m= line on connection to this specific end-point. The end goal is to create a new 5-tuple. This being said, such usage would be fairly uncommon.

_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Jun 2015 12:59:01 -0400

On 6/18/15 2:11 AM, Christer Holmberg wrote:
> But, from a DTLS perspective, forking is the same as e.g. call transfer.
> Also in that case the local candidates may stay the same, while the
> remote ones change.

There is a difference. In the case of forking you might want to keep 
both forks. (Typically not, but a conference server might.) And even if 
you only want to keep one long term, you may need to keep more than one 
during early media, until you know which one to keep long term.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> *From:*mmusic [mailto:[email-masked]] *On Behalf Of *Roman Shpount
> *Sent:* 17. kesäkuuta 2015 23:19
> *To:* Paul Kyzivat
> *Cc:* IETF MMUSIC WG
> *Subject:* Re: [MMUSIC] draft-holmberg-mmusic-sdp-dtls-00
>
> candidates is done before the exciting relay candidates are released,
> then new relay candidates will be different. If relay candidates are
> released before allocation, then relay candidates can end up being the
> same, which can cause problems. Relay candidates that were closed due to
> being unused by previous ICE session, can be reused since no existing
> DTLS traffic would be flowing over them. The same closing order
> restriction also applies to the host candidates. Otherwise if you
> release local host candidates before allocating new one, you might end
> up with the same local address/ports combinations.
>
>
>     needs to create new DTLS associations. In that case it must also use
>     new host candidates. Is it permitted to use the same (new)
>     candidates to recreate *both* DTLS associations? I can't see any
>     reason why not. I also don't see any specific prohibition in the
>     text. But it would be good to be explicit about it.
>
> forking. The only requirement is that when DTLS association is updated,
> the set of host and related candidates (relay, reflexive) is new for
> communications within this specific m= line on connection to this
> specific end-point. The end goal is to create a new 5-tuple. This being
> said, such usage would be fairly uncommon.
>
> _____________
> Roman Shpount
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Jun 2015 17:07:32 +0000

Hi,

> There is a difference. In the case of forking you might want to keep both forks. (Typically not, but a conference server might.) And even if you only > want to keep one long term, you may need to keep more than one during early media, until you know which one to keep long term.

Sure, there may be a difference in how long you maintain both DTLS associations. But, never the less, you still need separate DTLS associations.

Regards,

Christer

> The 5-tuples would typically be different and that should be enough 
> for de-mux. Sharing the same host or relay candidates should not be a problem.
>
> same, which can cause problems. Relay candidates that were closed due 
> to being unused by previous ICE session, can be reused since no 
> existing DTLS traffic would be flowing over them. The same closing 
> order restriction also applies to the host candidates. Otherwise if 
> you release local host candidates before allocating new one, you might 
> end up with the same local address/ports combinations.
>
>
> If I understand what you are asking, It is possible to use the same 
> host candidates to update multiple DTLS associations that are created 
> due to forking. The only requirement is that when DTLS association is 
> updated, the set of host and related candidates (relay, reflexive) is 
> new for communications within this specific m= line on connection to 
> this specific end-point. The end goal is to create a new 5-tuple. This 
> being said, such usage would be fairly uncommon.
>
> _____________
> Roman Shpount
>