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

[Tom Kristensen <[e-mail]>]

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 <[e-mail]>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 <[e-mail]>
> 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:[e-mail]]
> *Sent:* 27 March 2014 01:11
> *To:* Christer Holmberg
> *Cc:* [e-mail]
> *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 <[e-mail]>
> *Date: *Tuesday, March 25, 2014 at 12:39 PM
> *To: *"[e-mail]" <[e-mail]>
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bfcpbis
>
>
>
>
>
> --
> # Cisco                         |  http://www.cisco.com/telepresence/
> ## [e-mail]  |  http://www.tandberg.com
> ###                               |  http://folk.uio.no/tomkri/
>



-- 
# Cisco                         |  http://www.cisco.com/telepresence/
## [e-mail]  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/