[bfcpbis] BFCP-UDP and DTLS

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 28 November 2012 08:55 UTC

Return-Path: <christer.holmberg@ericsson.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 B47DF21F84D5 for <bfcpbis@ietfa.amsl.com>; Wed, 28 Nov 2012 00:55:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.059
X-Spam-Level:
X-Spam-Status: No, score=-6.059 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FYKCu323SfP for <bfcpbis@ietfa.amsl.com>; Wed, 28 Nov 2012 00:55:34 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6064321F846B for <bfcpbis@ietf.org>; Wed, 28 Nov 2012 00:55:34 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1e6d000002d2c-fd-50b5d185d218
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D4.37.11564.581D5B05; Wed, 28 Nov 2012 09:55:33 +0100 (CET)
Received: from ESESSHC015.ericsson.se (153.88.183.63) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 28 Nov 2012 09:55:32 +0100
Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0318.001; Wed, 28 Nov 2012 09:55:32 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Thread-Topic: BFCP-UDP and DTLS
Thread-Index: Ac3NRJglVoRPliakSkmUjyl/HukRqA==
Date: Wed, 28 Nov 2012 08:55:31 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B047F4F@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.16]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B047F4FESESSMB209ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+JvjW7rxa0BBoc+i1n8W3eUyYHRY8mS n0wBjFFcNimpOZllqUX6dglcGYePRRTsk6vonzqTtYFxn1QXIweHhICJxPNfFV2MnECmmMSF e+vZuhi5OIQETjJKbD5+B8rZySjxd0UbO4SzhFHi8v6jLCDdbAIWEt3/tEG6RQQ0JTZvv8sE EhYWkJJY3Z0EEZaX2DsXpBrE1pNYNGMZG4jNIqAq0fuzgR3E5hXwlri25h8jiM0IdMT3U2uY QGxmAXGJW0/mM0EcJyCxZM95ZghbVOLl43+sELaixM6z7cwQ9fkS297sYoaYKShxcuYTsL1C AtoSLYsnsE9gFJmFZOwsJC2zkLRAxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYzsuYmZ OenlhpsYgTFycMtv3R2Mp86JHGKU5mBREuflStrvLySQnliSmp2aWpBaFF9UmpNafIiRiYNT qoHRgjPRuUbBLWFz0xp9mz0z//bGebK8fPX44I62qb8uHJ3rv3BOWMDv8E17rju+e+EobPxW xD7v8YX1Sy2WRexYuuXiAmeThmu+Vr8cIvirEnmnfekoff3D/ZN78nWtyX2Lt1/8Z9myXH9T rKlp3M6ghK9bMr80bCmSs7G943jjfW7moSvRl05fVmIpzkg01GIuKk4EAESjHspfAgAA
Subject: [bfcpbis] BFCP-UDP and DTLS
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: Wed, 28 Nov 2012 08:55:35 -0000

Hi,

I haven't really been following the BFCPbis work, so I appologize if the following has been discussed.

draft-ietf-bfcpbis-rfc4583bis-03 refers to section 5 of RFC 5763 for the SDP Offer/Answer procedures, and DTLS role selection (TLS client/server).

However, I think it would also be good to refer to section 6.7 of RFC 5763. Especially section 6.7.2 is important, in my view. It says that the passive UA sends a STUN request, in order to open the NAT pin hole, which means both UAs don't have to be active if they are behind NATs, and don't support ICE. Otherwise it could cause problem, if both are active and end up acting as TLS clients.

Regards,

Christer