[bfcpbis] comment on draft-sandbakken-dispatch-bfcp-udp-03 text on DTLS connection establishment
"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Thu, 10 November 2011 20:04 UTC
Return-Path: <eckelcu@cisco.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C14E1F0C3B for <bfcpbis@ietfa.amsl.com>; Thu, 10 Nov 2011 12:04:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.259
X-Spam-Level:
X-Spam-Status: No, score=-6.259 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3fZoCbhntnr for <bfcpbis@ietfa.amsl.com>; Thu, 10 Nov 2011 12:04:57 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id F2FA61F0C38 for <bfcpbis@ietf.org>; Thu, 10 Nov 2011 12:04:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=1937; q=dns/txt; s=iport; t=1320955497; x=1322165097; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=egRMO0tqjzI5uCkXVffhIsFS4Er7RfeNS7Q8DZUEPy8=; b=EF+Jh6K28GBMbQUyiNXfKQ4mInMkapIFtd50ZcGD6DWaGqYJrS9GDgK/ 9dGsnDuDx8LZ3qRI8TFOw2B7wE7REBD2BAgLqdv6VEDOt/d2tO/Lqtphg zVdfJqGv2n+tyY0o/V6QobnstT30AC1ndZFtrqX+FjLMi/fW1ICONJO2q c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtUGAIQtvE6rRDoG/2dsb2JhbABEmnWPN4EFgXQBBBIBHQpRASoGGAdXAQQbGp9ggSYBnl+JG2MEiA+RWoxV
X-IronPort-AV: E=Sophos;i="4.69,490,1315180800"; d="scan'208";a="13499579"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 10 Nov 2011 20:04:57 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAAK4u7h029114 for <bfcpbis@ietf.org>; Thu, 10 Nov 2011 20:04:56 GMT
Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 12:04:54 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 10 Nov 2011 12:04:52 -0800
Message-ID: <E1CBF4C7095A3D4CAAAEAD09FBB8E08C05C12E8A@xmb-sjc-234.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: comment on draft-sandbakken-dispatch-bfcp-udp-03 text on DTLS connection establishment
Thread-Index: Acyf5AJaeXSok5sRSQe5iUNKj+EL5w==
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: bfcpbis@ietf.org
X-OriginalArrivalTime: 10 Nov 2011 20:04:54.0041 (UTC) FILETIME=[031BB890:01CC9FE4]
Subject: [bfcpbis] comment on draft-sandbakken-dispatch-bfcp-udp-03 text on DTLS connection establishment
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bfcpbis>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Nov 2011 20:04:57 -0000
There is an inconsistency in draft-sandbakken-dispatch-bfcp-udp-03 in
terms of its recommendations regarding DTLS connection establishment.
Section 4.10. Lower-Layer Security (7) currently reads:
Which party, the client or the floor control server, acts as the
TLS/DTLS server depends on how the underlying TCP/DTLS connection
is established. For example, when the TCP/DTLS connection is
established using an SDP offer/answer exchange [RFC4583], the
answerer (which may be the client or the floor control server)
always acts as the TLS/DTLS server.
This extends the existing text in RFC 4582 to cover DTLS as well.
However, section 5.3. Security Considerations (10) of
draft-sandbakken-dispatch-bfcp-udp-03 reads:
Append to the first paragraph, "Furthermore, when using DTLS over
UDP, considerations for its use with RTP and RTCP are presented in
[RFC5763]. The requirements for the offer/answer exchange, as listed
in Section 5 of that document, MUST be followed."
This conflicts with what was stated in section 4.10, as the
recommendations for DTLS connection establishment in RFC 5763 are not
the same as those provided in RFC 4583 for TLS connection establishment.
The proposed rewording of the text in section 4.10 of
draft-sandbakken-dispatch-bfcp-udp-03 is as follows:
Which party, the client or the floor control server, acts as the
TLS/DTLS server depends on how the underlying TLS/DTLS connection
is established. For a TCP/TLS connection established using an SDP
offer/answer exchange [RFC4583], the answerer (which may be the
client
or the floor control server) always acts as the TLS server. For a
UDP/DTLS connection established using the same exchange, either
party
can be the DTLS server depending on the setup attributes
exchanged,
as defined in [RFC5763].
Cheers,
Charles
- [bfcpbis] comment on draft-sandbakken-dispatch-bf… Charles Eckel (eckelcu)