Re: [rtcweb] JSEP: Why always offer actpass?

"Makaraju, Maridi Raju (Raju)" <> Sun, 30 November 2014 13:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BEAF71A0173 for <>; Sun, 30 Nov 2014 05:51:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IpjTCrWCDTHa for <>; Sun, 30 Nov 2014 05:50:59 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A94641A0161 for <>; Sun, 30 Nov 2014 05:50:59 -0800 (PST)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id B2D1CA8AAE774; Sun, 30 Nov 2014 13:50:55 +0000 (GMT)
Received: from ( []) by (GMO) with ESMTP id sAUDotwc009391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 30 Nov 2014 08:50:55 -0500
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Sun, 30 Nov 2014 08:50:55 -0500
From: "Makaraju, Maridi Raju (Raju)" <>
To: Christer Holmberg <>, Roman Shpount <>
Thread-Topic: [rtcweb] JSEP: Why always offer actpass?
Thread-Index: AdAH/G6saC/Ce4vxTgqv23nLTon8JADRev2AAADmq4AAEYxBAAAL0YgAADmeW3A=
Date: Sun, 30 Nov 2014 13:50:54 +0000
Deferred-Delivery: Sun, 30 Nov 2014 13:50:00 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [rtcweb] JSEP: Why always offer actpass?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 30 Nov 2014 13:51:01 -0000

> Hi,
> >>RFC 7345 (UDPTL-DTLS) says the following:
> >>
> >>        "Once an offer/answer exchange has been completed, either endpoint
> >>        send a new offer in order to modify the session.  The endpoints
> can
> >>        reuse the existing DTLS association if the key fingerprint values
> and
> >>        transport parameters indicated by each endpoint are unchanged.
> >>        Otherwise, following the rules for the initial offer/answer
> exchange,
> >>        the endpoints can negotiate and create a new DTLS association and,
> >>        once created, delete the previous DTLS association, following the
> >>        same rules for the initial offer/answer exchange.  Each endpoint
> >>        needs to be prepared to receive data on both the new and old DTLS
> >>        associations as long as both are alive."
> >>
> >> So, I guess that can be read in a way that the setup attribute as such
> does not impact previously
> >> negotiated TLS roles - unless the key fingerprint values and/or transport
> parameters are modified.
> >>
> >> The SCTP-SDP draft currently says that a subsequent offer must not change
> the previously negotiated roles. But, I guess
> >> we could say something similar as in RFC 7345.
> >
> > I have struggled with this language quite a bit from the implementation
> perspective. I think we need to explicitly state
> > that endpoints MUST reuse the existing association if the key fingerprint
> values and transport parameters indicated
> > by each endpoint are unchanged.
> We could take such general approach.
> However, for ‘SCTP/DTLS’ (DTLS over SCTP), I assume that the DTLS connection
> will also be re-established if the underlying SCTP association is re-
> established - even if no transport parameters etc are changed.
> Also, RFC 6083 says:
>                 “Each DTLS connection MUST be established and terminated
> within the same SCTP association.”
> > The way this language reads to me is that endpoints can reuse the existing
> association if they want to, but they can create a new one if they don't.
> Also, when this new
> > association is created, it is unclear if old setup roles MUST be preserved
> or if they MUST be selected based on the current offer/answer exchange. It
> seems the current
> > specification language is not strong or clear enough on this topic.
> In my opinion, IF a new DTLS connection needs to be established (for
> whatever reasons), the current roles should be used.

When ICE is NOT used, how does the offerer know that the answerer does not change the fingerprint and/or transport parameters? I guess it does not know. So, offerer has to be prepared for new DTLS association by offering actpass.
When ICE is used, the answerer can't change transport parameter unless offerer does ICE restart (which changes offerer transport parameters); Ref [1] is very clear on this indicating "DTLS handshake procedure is repeated". However, even when ICE is used, I do not find any restriction about answerer not changing fingerprint. So, even without ICE restart answerer can trigger a DTLS renegotiation by changing its fingerprint.

To conclude all this, IMO whether ICE is used or not, sending actpass for all new offers may be cover all possible scenarios.

   In the case of an ICE restart, the DTLS
   handshake procedure is repeated, and a new DTLS association is
   created.  Once the DTLS handshake is completed and the new DTLS
   association has been created, the previous DTLS association is