Re: [rtcweb] RFC 5763 Section 6.7.1 (was DTLS, DTLS-SRTP, and 5-tuples)

Jonathan Lennox <jonathan@vidyo.com> Fri, 27 March 2015 16:39 UTC

Return-Path: <jonathan@vidyo.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EA11A0363; Fri, 27 Mar 2015 09:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.566
X-Spam-Level:
X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
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 L-_xL9oC0WpZ; Fri, 27 Mar 2015 09:39:57 -0700 (PDT)
Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383F01A0252; Fri, 27 Mar 2015 09:39:57 -0700 (PDT)
Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id t2RGVkSL027843; Fri, 27 Mar 2015 12:39:56 -0400
Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1t74r6ceah-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Mar 2015 12:39:56 -0400
Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Fri, 27 Mar 2015 11:39:55 -0500
From: Jonathan Lennox <jonathan@vidyo.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>, mmusic <mmusic@ietf.org>
Thread-Topic: [rtcweb] RFC 5763 Section 6.7.1 (was DTLS, DTLS-SRTP, and 5-tuples)
Thread-Index: AQHQaKux5rrdwp+DGkCKzQY17awJSp0w28gA
Date: Fri, 27 Mar 2015 16:39:54 +0000
Message-ID: <A9BD5845-7508-4A7C-925F-915799D3F73A@vidyo.com>
References: <CAOW+2dvHbmDkwqK5tNsdOqkc0EjwW5vhBb6JqL+SehWm40-FLw@mail.gmail.com>
In-Reply-To: <CAOW+2dvHbmDkwqK5tNsdOqkc0EjwW5vhBb6JqL+SehWm40-FLw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [31.133.177.80]
Content-Type: multipart/alternative; boundary="_000_A9BD584575084A7C925F915799D3F73Avidyocom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-27_05:2015-03-27,2015-03-27,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503270161
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/ZpGXOGZ4qzrfmQJV8CFJC4UwkfE>
Subject: Re: [rtcweb] RFC 5763 Section 6.7.1 (was DTLS, DTLS-SRTP, and 5-tuples)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2015 16:39:58 -0000

On Mar 26, 2015, at 6:41 PM, Bernard Aboba <bernard.aboba@gmail.com<mailto:bernard.aboba@gmail.com>> wrote:

RFC 5763 Section 6.7.1 explains much of what we've been talking about on this thread.
6.7.1<http://tools.ietf.org/html/rfc5763#section-6.7.1>. ICE Interaction

   Interactive Connectivity Establishment (ICE), as specified in
   [RFC5245<http://tools.ietf.org/html/rfc5245>] provides a methodology of allowing participants in
   multimedia sessions to verify mutual connectivity.  When ICE is being
   used, the ICE connectivity checks are performed before the DTLS
   handshake begins.  Note that if aggressive nomination mode is used,
   multiple candidate pairs may be marked valid before ICE finally
   converges on a single candidate pair.  Implementations MUST treat all
   ICE candidate pairs associated with a single component as part of the
   same DTLS association.  Thus, there will be only one DTLS handshake
   even if there are multiple valid candidate pairs.  Note that this may
   mean adjusting the endpoint IP addresses if the selected candidate
   pair shifts, just as if the DTLS packets were an ordinary media
   stream
(Adding MMUSIC.)

The one recommendation I’d make for this problem is that one of the DTLS-SCTP drafts (probably ietf-mmusic-sctp-sdp, I guess?) should repeat this text from 5763.