Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CD01B2D5E for ; Mon, 19 Oct 2015 15:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chsTnRH6a4UG for ; Mon, 19 Oct 2015 15:04:10 -0700 (PDT) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B3581B2D4E for ; Mon, 19 Oct 2015 15:04:10 -0700 (PDT) Received: by igbdj2 with SMTP id dj2so1415057igb.1 for ; Mon, 19 Oct 2015 15:04:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ck/EhBNyhXpzy9IEI3R6yng/tjDLRicmfsgG19rXNjU=; b=aCoOflwyoHyn/HL3bpbsvsmRACqWA3UWVIFYoBPgSb7CHzoCJHMMsmTsrqxg49MlKu oiBOvYhV2vbB7iwT+1KxYMbNq3Y32RcRImVRw/CqhmeWWDbyJhRcmb/MhjU+eqgOKYJp oSvAab7f6Ry2Yx082en1QEnjd0lJIL4fsk5d2/8opbLic/SkYm0FKTfAw6zYKi3G9Yod Kh9Hk7NElWehqet6CoESX50cfhlgAbEU5bTosXzYDS93QDlyoDVDGrxaic8cvn06s4hj xQALs3AwFk5+NcJv6iT8BPRwQ5KuxfyVtiPIycN8rmVv9IDmjWVstzT8tA6LQgKiWbXb EgZg== X-Gm-Message-State: ALoCoQnAqh1gSD95vS+P9UHKlAGq2pKE5FbKeAFfPElTubp1UW4CW0RReaLjkXs6/LqupOiNpxa3 X-Received: by 10.50.134.37 with SMTP id ph5mr323351igb.88.1445292249758; Mon, 19 Oct 2015 15:04:09 -0700 (PDT) Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com. [209.85.213.179]) by smtp.gmail.com with ESMTPSA id a28sm15963ioj.20.2015.10.19.15.04.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2015 15:04:09 -0700 (PDT) Received: by igbkq10 with SMTP id kq10so60155489igb.0 for ; Mon, 19 Oct 2015 15:04:08 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.73.98 with SMTP id k2mr20671507igv.96.1445292248664; Mon, 19 Oct 2015 15:04:08 -0700 (PDT) Received: by 10.36.205.67 with HTTP; Mon, 19 Oct 2015 15:04:08 -0700 (PDT) In-Reply-To: <56256376.1080602@alum.mit.edu> References: <7594FB04B1934943A5C02806D1A2204B37B6FFE9@ESESSMB209.ericsson.se> <56256376.1080602@alum.mit.edu> Date: Mon, 19 Oct 2015 18:04:08 -0400 Message-ID: From: Roman Shpount To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e01184e1a1411a505227c53e6 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Draft new version: DTLS-SDP-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 22:04:13 -0000 --089e01184e1a1411a505227c53e6 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 19, 2015 at 5:41 PM, Paul Kyzivat wrote: > A few comments while reading it: > > * Section 5.1 vs. 6.2: > > For the initial offer of a DTLS m-line there isn't any option whether to > establish a DTLS association - one is going to be established. Section 5.1 > says use of dtls-connection is optional, but 6.2 says it is required. Which > is it? > Anything which is compliant with the new specification MUST include dtls-connection attribute. When inter-operating with legacy RFC5763 implementations, complaint implementation can receive an offer without dtls-connection attribute. In such cases, this attribute has no default value, and other means needs to be used in order for endpoints to determine whether an offer or answer is associated with an event that requires the DTLS association to be re-established. We will extend the language in 5.1 to make this explicit. > * Section 6.3: > > There seems to be an bug in this text: > > If an answerer receives an offer that contains an SDP 'dtls- > 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 'dtls-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. > > IIUC, in "The same applies ... with a 'new' value" the 'new' should be > 'existing'. Otherwise it simply reiterates the prior sentence. This > particularly includes the case when the answerer has no existing > association. > You are correct, we will update the document. > If a new DTLS association is to be established, and if the answerer > becomes DTLS client, the answerer MUST initiate the procedures for > establishing the DTLS association. If the answerer becomes DTLS > server, it MUST wait for the offerer to establish the DTLS > association. > > Isn't there a timing problem here? What if this case applies, but the > offerer won't know it until receiving the answer? (I.e., when the offer > contained 'existing'.) In that case the messages to initiate might outrun > the answer, and arrive before the offerer is ready for them. > We will extend the language that if new DTLS association can be established as a result of this offer/answer exchange, and if setup attribute "actpass" or "passive", end point should be ready to accept the DTLS ClientHello. Handling of DTLS association and associated media is somewhat tricky since, on one hand end point would not want to discard DTLS packets to avoid connection setup delay, on the other hand setting up DTLS association and processing media received over this connection can be dangerous, since remote party cannot be authenticate until signaling and fingerprint is received. We will propose the language to deal with this based on the discussions which took place in ORTC group. In section 8: > > It is possible to send an INVITE request which does not contain an > SDP offer. Such INVITE request is often referred to as an 'empty > INVITE', or an 'offerless INVITE'. The receiving endpoint will > include the SDP offer in a response associated with the response. > When the endpoint generates such SDP offer, it MUST assign an SDP > connection attribute, with a 'new' value, to each 'm-' line that > describes DTLS protected media. If ICE is used, the endpoint MUST > allocate a new set of ICE candidates, in order to ensure that two > DTLS association would not be running over the same transport. > > Can you explain your thinking here? This makes sense if the response is > the initial offer. But if there has been a prior O/A in the dialog, then > this doesn't seem right to me. > > Please look at my email in A.1. The end point which receives an offerless INVITE does not know if the offer generated in response to it will be used by some sort of 3PCC agent to setup a connection to new end point or will be used within the existing connection. Since this ambiguity exists, we decided to propose that a safer option should be used and new connection should be created. _____________ Roman Shpount --089e01184e1a1411a505227c53e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Oct 19, 2015 at 5:41 PM, Paul Kyzivat <pkyzivat@alum.mit.edu&g= t; wrote:
A few comments while reading it:

* Section 5.1 vs. 6.2:

For the initial offer of a DTLS m-line there isn't any option whether t= o establish a DTLS association - one is going to be established. Section 5.= 1 says use of dtls-connection is optional, but 6.2 says it is required. Whi= ch is it?

Anything which is compliant w= ith the new specification MUST include dtls-connection attribute. When inte= r-operating with legacy RFC5763 implementations, complaint implementation c= an receive an offer without dtls-connection attribute. In such cases, this = attribute has no default value, and other means needs to be used in order f= or endpoints to=C2=A0determine whether an offer or answer is associated wit= h an event that=C2=A0requires the DTLS association to be re-established.

We will extend the language in 5.1 to make this expl= icit.


* Section 6.3:

There seems to be an bug in this text:

=C2=A0 =C2=A0If an answerer receives an offer that contains an SDP 'dtl= s-
=C2=A0 =C2=A0connection' attribute with a 'new' value, the answ= erer MUST insert a
=C2=A0 =C2=A0'new' value in the associated answer.=C2=A0 The same a= pplies if the
=C2=A0 =C2=A0answerer receives an offer that contains an SDP 'dtls-conn= ection'
=C2=A0 =C2=A0attribute with a 'new' value, but the answerer determi= nes (based on
=C2=A0 =C2=A0the criteria for establishing a new DTLS association) that a n= ew DTLS
=C2=A0 =C2=A0association is to be established.

IIUC, in "The same applies ... with a 'new' value" the &#= 39;new' should be 'existing'. Otherwise it simply reiterates th= e prior sentence. This particularly includes the case when the answerer has= no existing association.

You are corre= ct, we will update the document.
=C2=A0
=C2= =A0 =C2=A0If a new DTLS association is to be established, and if the answer= er
=C2=A0 =C2=A0becomes DTLS client, the answerer MUST initiate the procedures= for
=C2=A0 =C2=A0establishing the DTLS association.=C2=A0 If the answerer becom= es DTLS
=C2=A0 =C2=A0server, it MUST wait for the offerer to establish the DTLS
=C2=A0 =C2=A0association.

Isn't there a timing problem here? What if this case applies, but the o= fferer won't know it until receiving the answer? (I.e., when the offer = contained 'existing'.) In that case the messages to initiate might = outrun the answer, and arrive before the offerer is ready for them.

We will extend the language that if new DTLS a= ssociation can be established as a result of this offer/answer exchange, an= d if setup attribute "actpass" or "passive", end point should be ready to acc= ept the DTLS ClientHello. Handling of DTLS association and associated media= is somewhat tricky since, on one hand end point would not want to discard = DTLS packets to avoid connection setup delay, on the other hand setting up = DTLS association and processing media received over this connection can be = dangerous, since remote party cannot be authenticate until signaling and fi= ngerprint is received.

We will propose the language to deal with this based on t= he discussions which took place in ORTC group.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">In section 8:

=C2=A0 =C2=A0It is possible to send an INVITE request which does not contai= n an
=C2=A0 =C2=A0SDP offer.=C2=A0 Such INVITE request is often referred to as a= n 'empty
=C2=A0 =C2=A0INVITE', or an 'offerless INVITE'.=C2=A0 The recei= ving endpoint will
=C2=A0 =C2=A0include the SDP offer in a response associated with the respon= se.
=C2=A0 =C2=A0When the endpoint generates such SDP offer, it MUST assign an = SDP
=C2=A0 =C2=A0connection attribute, with a 'new' value, to each '= ;m-' line that
=C2=A0 =C2=A0describes DTLS protected media.=C2=A0 If ICE is used, the endp= oint MUST
=C2=A0 =C2=A0allocate a new set of ICE candidates, in order to ensure that = two
=C2=A0 =C2=A0DTLS association would not be running over the same transport.=

Can you explain your thinking here? This makes sense if the response is the= initial offer. But if there has been a prior O/A in the dialog, then this = doesn't seem right to me.


Please look at my email in A.1. The en= d point which receives an offerless INVITE does not know if the offer gener= ated in response to it will be used by some sort of 3PCC agent to setup a c= onnection to new end point or will be used within the existing connection. = Since this ambiguity exists, we decided to propose that a safer option shou= ld be used and new connection should be created.
___________= __
Roman Shpount
=C2=A0
--089e01184e1a1411a505227c53e6--