Re: [MMUSIC] actpass redux

Roman Shpount <roman@telurix.com> Fri, 02 June 2017 18:02 UTC

Return-Path: <roman@telurix.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48234128D6F for <mmusic@ietfa.amsl.com>; Fri, 2 Jun 2017 11:02:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Level:
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
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 U0dPf701cu1H for <mmusic@ietfa.amsl.com>; Fri, 2 Jun 2017 11:02:19 -0700 (PDT)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 8DCF212894A for <mmusic@ietf.org>; Fri, 2 Jun 2017 11:02:19 -0700 (PDT)
Received: by mail-pf0-x234.google.com with SMTP id e193so54274963pfh.0 for <mmusic@ietf.org>; Fri, 02 Jun 2017 11:02:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WD6H2ChKc0C7T/ILQ2DgJfdDy4OX/VQoPqISvt6JTYw=; b=dLTjXXPFQw0W+7/4eY+Uhxm3+mh2OAk2d7BragiZoQ78TIROqeE5gsgxMAfg0Xj4GW FZYq3JzROz4H+EFZpb6fqNEebnFJBsbK5/VCKBzAkaUvbFonMXV2EiJ89DzLUKQKzUM2 u7Vx6Lape6tNQRXstC3XwNbZQD1b2ff7RswRXtwSkSwrq3XfU5A0YJBroiwhb0vkosoJ H69vLpi8AjhlJDK3AtGZVNHABCCAKP8VgGzjsmotkCtGOBEfpMsOzX9z1A6AOLcL5x6u Wt2LaJ0YMLukMo1mqfvwjTt0agLP5V9JkJp934Xn4+x/W5VS/yXlgwfp26OpUlI0Zobt SLQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WD6H2ChKc0C7T/ILQ2DgJfdDy4OX/VQoPqISvt6JTYw=; b=bZOkkxHk9ik9DA6FDaRHmETBrG+k5KZEp1gfryh2KH+Vr83zQVhWsJNqo3Kf+X7KlL r/6GrtyTVpXPLy6foH0dH+mTtssPl0NFLIzXG5lUGCHq1qgueQuI2FQDz8EH2KlWpVJ5 +LS1ypBaMtwaJQ+6MGVCMWE5knKWFCBmYz452CKrDEXEq7n5N8o7w2h0KigkRsc3srYH YEtb2QxqpoLUYHvD1K2u54dAZZvB+2+foTcri/BEW/wzMDnjAXBYs4v7MMao7gyTsQBj mCIZtSF7MnIVEd1KhLxrVeA0QSDcfjGTwoO0iL0TI5MyS+jlXrdvFCkjWuH3eG1qmC1L n+XA==
X-Gm-Message-State: AODbwcCebqy151x98oIeyuyFASDvPQElowjQcKka9RrnmSzxGa9vyGgt P0h6rzgaHogownicBuY=
X-Received: by 10.99.113.78 with SMTP id b14mr8335785pgn.229.1496426538816; Fri, 02 Jun 2017 11:02:18 -0700 (PDT)
Received: from mail-pf0-f171.google.com (mail-pf0-f171.google.com. [209.85.192.171]) by smtp.gmail.com with ESMTPSA id n7sm41467649pfk.74.2017.06.02.11.02.18 for <mmusic@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 11:02:18 -0700 (PDT)
Received: by mail-pf0-f171.google.com with SMTP id e193so54274571pfh.0 for <mmusic@ietf.org>; Fri, 02 Jun 2017 11:02:18 -0700 (PDT)
X-Received: by 10.84.225.146 with SMTP id u18mr1074452plj.264.1496426537961; Fri, 02 Jun 2017 11:02:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.169.66 with HTTP; Fri, 2 Jun 2017 11:02:17 -0700 (PDT)
In-Reply-To: <CABcZeBMd2BZgyeFnqafTVyGga4FMoK0xJkPCv0y_wvmBWsg+xg@mail.gmail.com>
References: <CABcZeBMd2BZgyeFnqafTVyGga4FMoK0xJkPCv0y_wvmBWsg+xg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Fri, 02 Jun 2017 14:02:17 -0400
X-Gmail-Original-Message-ID: <CAD5OKxvwgvm3Q4HsCYsewZjRS9ty_g34n9+x87vfLW4Omcm8mw@mail.gmail.com>
Message-ID: <CAD5OKxvwgvm3Q4HsCYsewZjRS9ty_g34n9+x87vfLW4Omcm8mw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="f403045ec5403a4f2c0550fdf4bf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/CrPJvuma1TBAiw6xXa0Jfsbz64s>
Subject: Re: [MMUSIC] actpass redux
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 02 Jun 2017 18:02:21 -0000

Hi All,

There was a discussion regarding the setup attribute value in subsequent
offers when establishing new DTLS association is not desired. Based on that
discussion it was decided that setup value can be either currently
negotiated value or actpass. There are also UDP/DTLS without STUN NAT
traversal scenarios that only work when end point behind NAT is active. I
think sending actpass in offers is a generally safer option, but I think
SHOULD here is more appropriate then MUST.

Please note that https://tools.ietf.org/html/rfc5763#section-5 says:

The endpoint MUST use the setup attribute defined in [RFC4145]. The
endpoint that is the offerer MUST use the setup attribute value of
setup:actpass and be prepared to receive a client_hello before it receives
the answer.


This applies not only to initial but to ALL offers.

Finally, I can double check, but I am fairly sure there are current
implementation that violate this rule.

Regards,

_____________
Roman Shpount

On Fri, Jun 2, 2017 at 12:44 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> Hi folks,
>
> RFC 5763 required (and JSEP imported) that all offers include
>
>   a=setup:actpass
>
> However, assuming I am reading:
>   https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24
>
> correctly, S 4.2 allows the initial offer to contain anything,
> though encourages actpass:
>
>    When an offerer sends the initial offer, the offerer MUST insert an
>    SDP 'setup' attribute according to the procedures in [RFC4145], and
>    one or more SDP 'fingerprint' attributes according to the procedures
>    in [RFC8122].  In addition, the offerer MUST insert in the offer an
>    SDP 'tls-id' attribute with a unique value.
>
>    If the offerer inserts the SDP 'setup' attribute with an 'actpass' or
>    'passive' attribute value, the offerer MUST be prepared to receive a
>    DTLS ClientHello message (if a new DTLS association is established by
>    the answerer) from the answerer before the offerer receives the SDP
>    answer.
>
> For subequent offers, it also gives flexibility but points at 4145.
>
>
> So...
>
> 1. Changing the behavior for initial offers seems like it presents
> a serious interop risk, because previously you could depend on
> the offer being actpass.
>
> 2. JSEP requires actpass for all offers, so at least it's stricter.
>
>
> What was the rationale for these changes? Feel free to point me at the
> mailing list discussion where that happened.
>
> -Ekr
>  Hi folks,
>
> RFC 5763 required (and JSEP imported) that all offers include
>
>   a=setup:actpass
>
> However, assuming I am reading:
>   https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24
>
> correctly, S 4.2 allows the initial offer to contain anything,
> though encourages actpass:
>
>    When an offerer sends the initial offer, the offerer MUST insert an
>    SDP 'setup' attribute according to the procedures in [RFC4145], and
>    one or more SDP 'fingerprint' attributes according to the procedures
>    in [RFC8122].  In addition, the offerer MUST insert in the offer an
>    SDP 'tls-id' attribute with a unique value.
>
>    If the offerer inserts the SDP 'setup' attribute with an 'actpass' or
>    'passive' attribute value, the offerer MUST be prepared to receive a
>    DTLS ClientHello message (if a new DTLS association is established by
>    the answerer) from the answerer before the offerer receives the SDP
>    answer.
>
> For subequent offers, it also gives flexibility but points at 4145.
>
>
> So...
>
> 1. Changing the behavior for initial offers seems like it presents
> a serious interop risk, because previously you could depend on
> the offer being actpass.
>
> 2. JSEP requires actpass for all offers, so at least it's stricter.
>
>
> What was the rationale for these changes? Feel free to point me at the
> mailing list discussion where that happened.
>
> -Ekr
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>