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;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/