Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis

Tom Kristensen <2mkristensen@gmail.com> Thu, 17 April 2014 16:25 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 B955D1A00DD for <bfcpbis@ietfa.amsl.com>; Thu, 17 Apr 2014 09:25:01 -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 iQ6cBiUMsb0x for <bfcpbis@ietfa.amsl.com>; Thu, 17 Apr 2014 09:24:56 -0700 (PDT)
Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 509AB1A019C for <bfcpbis@ietf.org>; Thu, 17 Apr 2014 09:24:56 -0700 (PDT)
Received: by mail-qa0-f50.google.com with SMTP id ih12so590793qab.37 for <bfcpbis@ietf.org>; Thu, 17 Apr 2014 09:24:52 -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=8QgSPsXfBoceo9oSlLMU9SqjJvVMsJLEZuEwk+cS5wc=; b=UeCTW/CtIKdDlo0AaW5T8nq0+loldRYQoKhNC5Ha6HGBYczHmieg0yonOIcMJkWxt6 hlCQ/lw+899FNfhE/frC78QBKVZQeTip0dCj3jJK8LKhPKKuxAxn6D/or/mOL9/cQLX9 dHe6/pmfLxaOBa4jS4N/8Leo06G4sE+jqKVO215NcN1bQlleOQyEaqmp30y0v0Dy3PU5 SKZpqzXKd7hlfT4FscCV2LZXK3ObUwigfV5s8Cqx7pvzxa13AwSrO0xQ5FC5ex9FhIch /tRxo5D3GqYkBvR0LC+7uQT2amIDqWPyQ2jBI/w3xG/LE6YdmLxHRY5GMxi5FUOjeSzL bExQ==
MIME-Version: 1.0
X-Received: by 10.140.32.97 with SMTP id g88mr17901939qgg.17.1397751892506; Thu, 17 Apr 2014 09:24:52 -0700 (PDT)
Received: by 10.229.2.66 with HTTP; Thu, 17 Apr 2014 09:24:52 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2CC894@ESESSMB209.ericsson.se>
References: <CF589899.23B24%eckelcu@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D26AD25@ESESSMB209.ericsson.se> <CAFHv=r_hQdv86aDZr=t_MjRuhqGbbL2S3dUG6VD5Z5Rp-aa1sw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D2CC894@ESESSMB209.ericsson.se>
Date: Thu, 17 Apr 2014 18:24:52 +0200
Message-ID: <CAFHv=r-qr_7RFzh0yAV7S1hO1kk1=LDRdYOfwLzgD7jK6KADBQ@mail.gmail.com>
From: Tom Kristensen <2mkristensen@gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary=001a113a665a097fcd04f73f794f
Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/1ro91v5QvceEdfnn2cZ_MCopIGM
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: Thu, 17 Apr 2014 16:25:01 -0000

I have never heard of any need for a non-O/A mechanism, UDP/DTLS is
currently used by vendors utilizing offer/answer in a SIP context.


On 16 April 2014 22:36, Christer Holmberg <christer.holmberg@ericsson.com>wrote;wrote:

>  Hi,
>
>
>
> >It would be much clearer and less confusing to have all the SDP
> offer/answer related >procedures in rfc4583bis. I agree and have started
> working on it, i.e. moving content to >rfc4583bis and polishing text in
> rfc4582bis.
>
> >
>
> >However, what do people on this list think about the concerns and sketch
> for solving this >issue proposed by Charles?
>
> >
>
> >And specifically: Do we want to (i) update RFC 5018 with UDP / DTLS or
> do we think it is >even thinkable/doable to (ii) specify UDP / DTLS as a
> transport only when offer/answer is >used? (Not a clean approach, but
> very pragmatic ;) )
>
>
>
> Well, has anyone requested a non-O/A mechanism?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> On 29 March 2014 12:40, Christer Holmberg <christer.holmberg@ericsson.com>
> wrote:
>
>  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]
> *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/
>



-- 
# Cisco                         |  http://www.cisco.com/telepresence/
## tomkrist@cisco.com  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/