Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis
Tom Kristensen <2mkristensen@gmail.com> Wed, 16 April 2014 17:05 UTC
Return-Path: <2mkristensen@gmail.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1C91A028E for <bfcpbis@ietfa.amsl.com>; Wed, 16 Apr 2014 10:05:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 hDidbwk6rs_O for <bfcpbis@ietfa.amsl.com>; Wed, 16 Apr 2014 10:05:07 -0700 (PDT)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3401A01DF for <bfcpbis@ietf.org>; Wed, 16 Apr 2014 10:05:07 -0700 (PDT)
Received: by mail-qg0-f48.google.com with SMTP id i50so3752523qgf.35 for <bfcpbis@ietf.org>; Wed, 16 Apr 2014 10:05:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Og+IIrYHoglU0iP4COF9zyPY/AWsM7dyzWwNfOe+Tqg=; b=Fxr/NaZV4sWEtrX/iBV3YWmIN9+D5LiRZPsNkCHjYwSvTH+CJm8K/TB1PaLeb7PVtA AKZOMfIeeZs/2GdzNX/xutYrFqskgmjYSsSPmC8s+2swXlsdDv3f02GFhm8y+Au70s7B XjhjgCw5YitYdYCFyoKFaAgVwDLBd8Babvi9TtueqYFnowmpkXEkD0p4Dtk+C3PjPe0U z9ZC7Ey0Ml55A0ipN+kH5OLXecbqr0qtcgmC0/C7fyrxJqHR3bAF/xeq08qRslQUHeHM OQ3VXO8T9c9/kUVc9f4uHM0Sy6HCcgQhvt9aO4zNWZOtUQ70/TOOUw782upZJ1un9a34 CG/g==
MIME-Version: 1.0
X-Received: by 10.224.22.195 with SMTP id o3mr4627524qab.51.1397667904161; Wed, 16 Apr 2014 10:05:04 -0700 (PDT)
Received: by 10.229.2.66 with HTTP; Wed, 16 Apr 2014 10:05:04 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D26AD60@ESESSMB209.ericsson.se>
References: <CF589899.23B24%eckelcu@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D26AD25@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D26AD60@ESESSMB209.ericsson.se>
Date: Wed, 16 Apr 2014 19:05:04 +0200
Message-ID: <CAFHv=r_r6Qpav1M+fMrXKjgJxnLxuFeygZAZB2e51J4r9HhSwA@mail.gmail.com>
From: Tom Kristensen <2mkristensen@gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="047d7b5da5bbf13f8d04f72beacc"
Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/Mw9Vfs9LNcGcvhDkBF_CrSMLlLc
Cc: "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "Charles Eckel (eckelcu)" <eckelcu@cisco.com>, Tom Kristensen <tomkrist@cisco.com>
Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Apr 2014 17:05:13 -0000
I'm starting with addressing this last issue first: RFC 4583 has lived fine for some years and do have a number of interoperable implementations out there. This happened without structuring the O/A procedures using RFC 3264 as a blueprint as was suggested for Christer's draft in MMUSIC. Additinally, this issue never raised during SDP directorate review. I propose we do not restructure rfc4583bis this way. -- Tom On 29 March 2014 12:44, Christer Holmberg <christer.holmberg@ericsson.com>wrote: > Hi, > > > > Another thing. > > > > As part of the WGLC for one of my draft in MMUSIC, I received comments > that the SDP O/A procedures should be structured according to RFC 3264, ie > “Sending of initial offer”, “Modifying session”, “Processing of answer” etc. > > > > Eventhough this is not MMUSIC, you may want to consider doing the same J > > > > Regards, > > > > Christer > > > > > > > > > > *From:* bfcpbis [mailto:bfcpbis-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* 29 March 2014 13:41 > *To:* Charles Eckel (eckelcu) > > *Cc:* bfcpbis@ietf.org > *Subject:* Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and > 4583bis > > > > Hi Charles, > > > > Without commenting on specifics at this point, I really think we should > try to get the SDP Offer/Answer procedures into one place (4583bis). > > > > 4582bis can define actions taken by the DTLS client and server, but should > not define how those roles are determined. 4583bis then defines how the > roles are determined when using SDP O/A. > > > > Regards, > > > > Christer > > > > *From:* Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com<eckelcu@cisco.com>] > > *Sent:* 27 March 2014 01:11 > *To:* Christer Holmberg > *Cc:* bfcpbis@ietf.org > *Subject:* Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and > 4583bis > > > > Hi Christer, > > > > Thanks for your comments. The more I looked into them the more complex and > tangled things became. Let me try to walk through the current state of > affairs and then propose a potential solutions. > > > > RFC 4582 breaks connection establishment into two cases: > > 1. when SDP offer/answer IS NOT used > 2. when SDP offer/answer IS used > > For (1), RFC 4582 points to RFC 5018. draft-ietf-bfcpbis-rfc4582bis-11 > adds a reference to RFC 5239 for XCON. > > RFC 5018 deals with the connection establishment, reestablishment, and > TLS usage. > > RFC 5239 points back to RFC 5018 for connection establishment. > > RFC 5018 does not deal with DTLS. Unless we restrict DTLS to cases in > which SDP offer/answer is used, we need to update RFC 5018 to deal with > DTLS. Someone please tell me otherwise. > > > > Section 6.2 of draft-ietf-bfcpbis-rfc4582bis-11 describes how to extend > RFC 5018 when dealing with BFCP over UDP or DTLS. I think this should be > relocated to an update to RFC 5018, and connection reestablishment should > be described as well. > > > > For (2), RFC 4582 provides a teaser but points to RFC 4583 for the > normative language. draft-ietf-bfcpbis-rfc4582bis-11 similarly points to > draft-ietf-bfcpbis-rfc4583bis-09. Christer comments are in regard to > inconsistencies here. I provided comments on those inline. > > > > *From: *Christer Holmberg <christer.holmberg@ericsson.com> > *Date: *Tuesday, March 25, 2014 at 12:39 PM > *To: *"bfcpbis@ietf.org" <bfcpbis@ietf.org> > *Subject: *[bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis > > > > Hi, > > > > Section 7 in 4582bis, which says: > > > > “7. Lower-Layer Security > > > > BFCP relies on lower-layer security mechanisms to provide replay and > > integrity protection and confidentiality. BFCP floor control servers > > and clients (which include both floor participants and floor chairs) > > > > MUST support TLS for transport over TCP [6] and MUST support DTLS [7] > > for transport over UDP. Any BFCP entity MAY support other security > > mechanisms. > > > > BFCP entities MUST support, at a minimum, the > > TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6]. > > > > 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 [9], the answerer (which may be the client or > > the floor control server) always acts as the TLS server. If the TCP > > connection is lost, the active endpoint, i.e., the current TLS > > client, is responsible for re-establishing the TCP connection. > > Unless a new TLS session is negotiated, subsequent SDP offers and > > answers will not impact the previously negotiated TLS roles. > > > > For a UDP/DTLS connection established using the an SDP offer/answer > > exchange, either party can be the DTLS server depending on the setup > > attributes exchanged; examples can be found in [23].” > > > > *First*, we already earlier discussed that the active TCP endpoint is > responsible for re-establishing the TCP connection, and that will be > corrected in the next version of the draft. > > > > Yes. > > > > > > However, we have discussed a similar topic in CLUE, and we were wondering > whether it would be good that, whoever detects a connection failure, sends > a new offer in order to re-establish the connection. It does not matter if > both endpoints send an offer – the offer/answer race condition rules will > take care of that. > > > > In CLUE, is this for a TCP/TLS connection, or for a DTLS connection? > > For DTLS, we specifically chose to alter the behavior, as described in > section 9.1 of 4583bis: > > > > "Endpoints that use the offer/answer model to establish a DTLS > > association MUST support the 'setup' attribute, as defined in [7]. > > When DTLS is used with UDP, the 'setup' attribute indicates which of > > the endpoints (client or floor control server) initiates the DTLS > > association setup. The requirements for the offer/answer exchange > > specified in [13], Section 5 MUST be followed when using DTLS. > > > > Informational note: How to determine which endpoint to initiate > > the TLS/DTLS association depends on the selected underlying > > transport. It was decided to keep the original semantics in [15] > > for TCP to retain backwards compatibility. When using UDP, the > > procedure above was preferred since it adheres to [13] as used for > > DTLS-SRTP, it does not overload offer/answer semantics, and it > > works for offerless INVITE in scenarios with B2BUAs." > > > > > > > > > > *Second*, Section 8.1 in 4583bis says: > > > > “When the existing TCP connection is reset following the rules in [8], > > the client MUST generate an offer towards the floor control server in > > order to reestablish the connection. If a TCP connection cannot > > deliver a BFCP message and times out, the entity that attempted to > > send the message (i.e., the one that detected the TCP timeout) MUST > > generate an offer in order to reestablish the TCP connection.” > > > > > > I am not sure what is meant by “TCP connection is reset following the > rules in [8]”. Which rules are you referring to? > > > > Reset means closed and reestablished. The word “reset” was used in RFC > 4582 and reused in 4582bis. Perhaps we should change it closed and > reestablished to avoid confusion? > > > > > > Then, the text says that the client always re-established the TCP > connection. Is that aligned with the text in 4582bis, saying that the > active party does the reestablishment? Is the client always active? > > > > I think it is a little confusing that both 4582bis and 4583bis defines SDP > Offer/Answer procedures. Shouldn’t they only be in 4583bis? > > > > Yes, I think so. RFC 4582 mixed some SDP offer/answer text into its > section on lower layer security, and 4582bis followed suit. It would be > better to have all the details of connection establishment and > reestablishment in when using SDP offer/answer in 4583bis. > > > > > > > > > > *Third*, the last paragraph, talking about UDP/DTLS, says that either > party can be DTLS server depending on the setup attributes exchanged. But, > nowhere is it described how the setup attribute is used to determine the > DTLS server role J > > > > I assume it is done in the same way as for TCP/TLS, but that is not > written anywhere. > > > > The text I pasted from 4583bis above describes this. If we put all the > connection management stuff in 4583bis instead of leaving it split across > 4582bis and 4583bis, this should be clear. > > > > Cheers, > > Charles > > > > > > > > Regards, > > > > Christer > > > > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > > -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/
- Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 45… Christer Holmberg
- [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bi… Christer Holmberg
- Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 45… Charles Eckel (eckelcu)
- Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 45… Christer Holmberg
- Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 45… Tom Kristensen
- Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 45… Tom Kristensen
- Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 45… Christer Holmberg
- Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 45… Christer Holmberg
- Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 45… Tom Kristensen
- Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 45… Charles Eckel (eckelcu)