Subject: [MMUSIC] Draft new version: draft-holmberg-mmusic-sdp-dtls-01

From: Christer Holmberg <[email-masked]>
Date: Sat, 20 Jun 2015 13:06:06 +0000

Hi,

Based on the comments and feedback, I've submitted a new version (-01) of the sdp-dtls draft.

It adds more background, and tries to make the procedures more clear.

http://www.ietf.org/id/draft-holmberg-mmusic-sdp-dtls-01.txt

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 20 Jun 2015 13:47:11 -0400

I have a few comments on this version:

* Section 2.1:

    When a new DTLS association is established, an endpoint MUST use a
    new set of transport parameters (IP address and port combination).

The above seems slightly ambiguous: does "an endpoint" mean "each 
endpoint" or "one (of the two) endpoints"?

IIUC we have established that the important point is that the 5-tuple 
must change. So at least one side must change the address or port. But 
if one side is known to do so, then the other side need not do so. So I 
suggest changing the above to:

    When a new DTLS association is established, one of the endpoints
    MUST use a new set of transport parameters (IP address and port
    combination).

But there may be more to sort out about the o/a protocol for 
guaranteeing this. I can see a few:

- if the offer has connection:new then the offer must have new
   transport parameters. Else, if the offer has connection:existing
   but the answer has connection:new then the answer must have new
   transport parameters.

- if the answer has connection:new and the offer didn't have new
   transport parameters, then the answer must have new ones.

Something about the above should probably go into section 6.

* Section 5.1

    A 'connection' attribute value of 'new' indicates that a new DTLS
    association MUST be established.  A 'connection' attribute value of
    'existing' indicates that a new DTLS association MUST NOT be
    established.

I think this is wrong - that the answerer is permitted to answer with 
connection:new.

* Section 6.3

    If an answerer receives an offer that contains an SDP 'connection'
    attribute with a 'new' value, the answerer MUST insert a 'new' value
    in the associated answer.  The same applies if the answerer receives
    an offer that contains an SDP 'connection' attribute with a 'new'
    value, but the answerer determines (based on the criteria for
    establishing a new DTLS association) that a new DTLS association is
    to be established.

I think I previously commented on this: the 2nd sentence "The same 
applies if ... attribute with 'new' value ...". *That* 'new' should be 
'existing' - it is covering an alternative to the first sentence. And 
this aligns with my comment above about section 5.1.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 20 Jun 2015 22:05:40 +0000

Hi Paul,

Thanks for your comments. See inline.

> The above seems slightly ambiguous: does "an endpoint" mean "each endpoint" or "one (of the two) endpoints"?
>
> IIUC we have established that the important point is that the 5-tuple must change. So at least one side must change the address or port. But if one > side is known to do so, then the other side need not do so. So I suggest changing the above to:
>

The idea is that the endpoint(s) which does something the requires a new set of transport parameters needs to use a new set.

So, if e.g. endpoint A wants to change the fingerprint, which requires a new DTLS association, endpoint A needs to use a new set of transport parameters.

> But there may be more to sort out about the o/a protocol for guaranteeing this. I can see a few:
>

Yes.

>   transport parameters, then the answer must have new ones.

Yes.

> I think this is wrong - that the answerer is permitted to answer with connection:new.

The was meant to say that an endpoint sending 'new' needs to use a new set of transport parameters.

However, if the offerer sends 'new', meaning it uses a new set of transport parameters, I am not sure we need to mandate the answerer to use a new set of transport parameters even if it sends 'new' in the answer.

> I think I previously commented on this: the 2nd sentence "The same applies if ... attribute with 'new' value ...". *That* 'new' should be 'existing' - it > is covering an alternative to the first sentence. And this aligns with my comment above about section 5.1.

I'll have a look at that.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Sat, 20 Jun 2015 23:45:02 -0400

> >   transport parameters, then the answer must have new ones.

One thing to keep in mind here, that unless ICE restart was initiated by
the offering side (i.e. it had a different ufrag/pwd even if ti specified
connection:exisiting), answering side cannot allocate a new transport.
Answering side is simply not allowed to respond with a new ufrag/pwd unless
new ufrag/pwd was used in the offer. In cases where offer has the same
ufrag/pwd, answering side must use connection:existing and issue a new
offer to setup new transport and new DTLS association.

_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Jun 2015 07:39:19 +0000

Hi,

> One thing to keep in mind here, that unless ICE restart was initiated by the offering side (i.e. it had a different ufrag/pwd even if it specified 
> connection:exisiting), answering side cannot allocate a new transport. Answering side is simply not allowed to respond with a new ufrag/pwd 
> unless new ufrag/pwd was used in the offer. In cases where offer has the same ufrag/pwd, answering side must use connection:existing and issue > a new offer to setup new transport and new DTLS association.

That's a good point. Is that a generic ICE rule, or something we need to define for DTLS in the draft?

Regards,

Christer

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 22 Jun 2015 09:51:04 +0000

> On 21 Jun 2015, at 01:05, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Paul,
> 

I agree that
If you change the certificate you intend to use, then you need a new DTLS association

however I am not sure that this (i.e. the change of the certificate) also implies the endpoint has to use necessary a new set of transport parameters.

Can you someone clarify this to me?

thanks 
/Sal

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Jun 2015 11:26:55 +0000

Hi Sal,

Unless you change the transport parameters, you may receive DTLS packets associated with the old and new DTLS association on the same address:port.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Salvatore Loreto<mailto:[email-masked]>
Sent: ‎22/‎06/‎2015 12:51
To: Christer Holmberg<mailto:[email-masked]>; Martin Thomson<mailto:[email-masked]>
Cc: Paul Kyzivat<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] Draft new version: draft-holmberg-mmusic-sdp-dtls-01

I agree that

thanks
/Sal

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Jun 2015 09:24:13 -0400

On 6/20/15 11:45 PM, Roman Shpount wrote:
> On Sat, Jun 20, 2015 at 6:05 PM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> the offering side (i.e. it had a different ufrag/pwd even if ti
> specified connection:exisiting), answering side cannot allocate a new
> transport. Answering side is simply not allowed to respond with a new
> ufrag/pwd unless new ufrag/pwd was used in the offer. In cases where
> offer has the same ufrag/pwd, answering side must use
> connection:existing and issue a new offer to setup new transport and new
> DTLS association.

What if the answering side *can't* use the existing connection? (E.g. 
because it doesn't know about it.) The conditions that would lead to 
this situation are exotic, but not impossible. (Things that would cause 
this situation would force the end we are here calling the answerer to 
need to issue its own new offer if it hadn't received an offer first.)

I guess a solution for the answerer in this case is to refuse the m-line 
(port zero), and then send a new offer with connection:new.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Jun 2015 09:32:18 -0400

> So, if e.g. endpoint A wants to change the fingerprint, which requires a new DTLS association, endpoint A needs to use a new set of transport parameters.

That is certainly one approach that will work. See more on this below.

>>    but the answer has connection:new then the answer must have new

This is the algorithm you suggested above.

>>    transport parameters, then the answer must have new ones.

This is a subtly different algorithm. It doesn't require the offerer to 
change transport parameters when specifying connection:new. It *can*, 
but it can also choose not to - forcing the answered to change them. (Or 
refuse the m-line, or refuse the offer.)

It gives the offerer a little more flexibility, but then allows the 
offerer to put more burden on the answerer. There may be some obscure 
cases where the extra flexibility might be useful, though I have not yet 
thought of any.

Either algorithm will work. This spec needs to choose one and explicitly 
state it.

> However, if the offerer sends 'new', meaning it uses a new set of transport parameters, I am not sure we need to mandate the answerer to use a new set of transport parameters even if it sends 'new'…

So your intent was to specify the first of the algorithms I mentioned 
above. I did not get that out of this paragraph.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Jun 2015 16:55:43 +0000

Hi,

>> One thing to keep in mind here, that unless ICE restart was initiated 
>> by the offering side (i.e. it had a different ufrag/pwd even if ti 
>> connection:existing and issue a new offer to setup new transport and 
>> new DTLS association.
>
>because it doesn't know about it.) The conditions that would lead to this situation are 
>exotic, but not impossible. (Things that would cause this situation would force the end 
>we are here calling the answerer to need to issue its own new offer if it hadn't received an offer first.)
>
> I guess a solution for the answerer in this case is to refuse the m-line (port zero), and then send a new offer with connection:new.

I think that is what Roman said in his last sentence above :)

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 22 Jun 2015 13:14:18 -0400

Paul,

What I wanted to see there, was that each party that specifies
"connection:new" SHOULD allocate a new transport. I understand that this
can cause both sides to allocate new transports, but, in case of ICE, or in
case when different addresses or ports are used to send and receive media
(asymmetric media), this is the only way for the end point to guarantee
that it will end up using a new 5-tuple for the created DTLS connection.
With ICE, it is difficult to determine that an end point is not reusing any
of the existing candidates. Without ICE, end point can continue to send
media from the same address/port even though it allocated a new
address/port to receive media. So, the options are either rely on the
remote party guarantee that it actually allocated the new transport and
detect the potential DTLS association collisions or allocate a new
transport and be sure 5-tuple is going to be unique. In cases, where remote
end point can be trusted to use new transport when "connection:new" is
used, rules for allocating new transport can be relaxed, but this is not
recommended.
_____________
Roman Shpount

On Mon, Jun 22, 2015 at 9:32 AM, Paul Kyzivat <[email-masked]> wrote:

> change transport parameters when specifying connection:new. It *can*, but
> it can also choose not to - forcing the answered to change them. (Or refuse
> the m-line, or refuse the offer.)
>
> offerer to put more burden on the answerer. There may be some obscure cases
> where the extra flexibility might be useful, though I have not yet thought
> of any.
>
>> However, if the offerer sends 'new', meaning it uses a new set of
>> transport parameters, I am not sure we need to mandate the answerer to use
>> a new set of transport parameters even if it sends 'new' in the answer.
>>
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 22 Jun 2015 13:14:49 -0400

On Mon, Jun 22, 2015 at 9:24 AM, Paul Kyzivat <[email-masked]> wrote:

> because it doesn't know about it.) The conditions that would lead to this
> situation are exotic, but not impossible. (Things that would cause this
> situation would force the end we are here calling the answerer to need to
> issue its own new offer if it hadn't received an offer first.)
>

This is exactly what I meant in the last sentence.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 22 Jun 2015 13:30:20 -0400

On Mon, Jun 22, 2015 at 3:39 AM, Christer Holmberg <
[email-masked]> wrote:

> the offering side (i.e. it had a different ufrag/pwd even if it specified
> Answering side is simply not allowed to respond with a new ufrag/pwd
> > unless new ufrag/pwd was used in the offer. In cases where offer has the
> same ufrag/pwd, answering side must use connection:existing and issue > a
> new offer to setup new transport and new DTLS association.
>
This is a generic ICE rule defined in RFC 5245 9.2.2 (
https://tools.ietf.org/html/rfc5245#section-9.2.2):

Unless the agent has detected an ICE restart from the offer, the username
fragments, password, and implementation level MUST remain the same as used
previously.  If an agent needs to change one of these it MUST restart ICE
for that media stream by generating an offer; ICE cannot be restarted in an
answer.

I do not think we need to restate this, but we need to specify how this
will affect DTLS setup. Primarily there are two things we want to mention:

1. When ICE is used, new DTLS association can only be setup in an answer,
if it is an answer to ICE restart.

2. If an ICE offer is received, which requires a new DTLS association,
either due to fingerprint or setup role change, or due to "connectiion:new"
attribute, and this offer does not have new ufrag/pwd, then it cannot be
handled. This would indicate an error condition, and media line would need
to be refused with m-line port 0 or the whole offer would need to be
refused with an error response. After that connection would need to be torn
down or renegotiated with a new offer with new transport and DTLS
association.
_____________
Roman Shpount