Re: [MMUSIC] Draft new version: DTLS-SDP-01

Roman Shpount <roman@telurix.com> Mon, 19 October 2015 22:04 UTC

Return-Path: <roman@telurix.com>
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 <mmusic@ietfa.amsl.com>; 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 <mmusic@ietfa.amsl.com>; 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 <mmusic@ietf.org>; Mon, 19 Oct 2015 15:04:10 -0700 (PDT)
Received: by igbdj2 with SMTP id dj2so1415057igb.1 for <mmusic@ietf.org>; 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 <mmusic@ietf.org> (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 <mmusic@ietf.org>; 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: <CAD5OKxsnAJOiHw+G=OpF+C8_Y-HJA6gNmNSjR0YLzdyUiiL1vA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary=089e01184e1a1411a505227c53e6
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/7L3Pj0Qvj55RCu-VOo70pXUE4u4>
Cc: "mmusic@ietf.org" <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 <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Oct 2015 22:04:13 -0000

On Mon, Oct 19, 2015 at 5:41 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> 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