Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24

[Roman Shpount <[e-mail]>]

Christer,

Here is the best I can come up with:

The main use case for TCP/TLS/BFCP is legacy interop. This protocol should
be used if end point needs to communicate with existing equipment that
implements it. This protocol cannot be used with ICE and does not work in
NAT environments. This protocol utilizes TCP for reliable in-order delivery
and relies on these properties of TCP in its implementation, so that
implementation of this protocol is fairly different from  UDP/TLS/BFCP.

The main use case for TCP/DTLS/BFCP is ICE and associated support for NAT
environments. This is the protocol which will be used on the wire and
specified in the m= line when an ICE TCP candidate is used. It is
recommended to use this protocol for new implementations or when endpoints
deployed in NAT environments need to be supported. From implementation
point of view, TCP/DTLS/BFCP protocol compliments UDP/TLS/BFCP since it
allows seamless switch-over between TCP/DTLS/BFCP and UDP/TLS/BFCP within
the same communication session, which is required for ICE support. Both
protocols use the same encryption (DTLS), and the same mechanisms to insure
reliable message delivery. Essentially, TCP/DTLS/BFCP is UDP/TLS/BFCP with
DTLS packets sent over the TCP connection using framing defined in RFC 4571
instead of UDP, so that most of the transport implementation code can be
shared.

Regards,

_____________
Roman Shpount

On Fri, Sep 21, 2018 at 5:21 PM, Christer Holmberg <
[e-mail]> wrote:

> Hi Roman,
>
>
>
> Could you help providing explanation?
>
>
>
> Perhaps a bullet list with each protocol value, and when to use it.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* Roman Shpount [mailto:[e-mail]]
> *Sent:* 11 September 2018 00:23
> *To:* Adam Roach <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24
>
>
>
> Hi Adam,
>
>
>
> On Mon, Sep 10, 2018 at 4:41 PM, Adam Roach <[e-mail]> wrote:
>
>
> §4 (BLOCKING):
>
> >  This document defines five values for the proto field: TCP/BFCP,
> >  TCP/DTLS/BFCP, TCP/TLS/BFCP, UDP/BFCP, and UDP/TLS/BFCP.
>
> Generally, having more ways to do the same things in a protocol leads to
> less
> interoperability rather than more. While the rationale for the four-way
> split
> caused by TLS-versus-plaintext and UDP-versus-TCP is pretty self evident,
> there
> appears to be no rationale in this document for having both TCP/DLTS/BFCP
> and
> TCP/TLS/BFCP; more importantly, the document offers no guidance to
> implementors
> regarding which to use. This is likely to lead to some implementations
> choosing
> one encoding and others choosing the other somewhat arbitrarily. This
> decreases
> the chances of the protocol interoperating.
>
> Minimally, please include guidance regarding which of these two variations
> implementations should use, and under which conditions. On a first glance,
> it
> would appear that the guidance might be that non-ICE uses should use
> TCP/TLS/BFCP for maximal compatibility with RFC 4583 implementations, and
> that
> ICE uses need to use TCP/DTLS/BFCP, as outlined in section 9.
>
>
>
> You are correct, the reason there are two protocols is that TCP/TLS/BFCP
> needs to be supported for legacy interop with RFC4583 but it does not work
> with ICE. Since  ICE is designed as being able to switch between ICE
> candidates, including UDP and TCP based candidates, without disrupting the
> higher level protocol, any ICE transport, including ICE-TCP, should be
> treated as packet-based unreliable transport. As a result, ICE can only
> work with UDP/TLS/DTLS/BFC for UDP candidates or TCP/DTLS/BFCP for TCP
> candidates. Both of these protocols treat underlying transport as
> unreliable with DTLS responsible for packet re-transmission. On the other
> hand,  TCP/TLS/BFCP relies on the underlying transport for reliable
> in-order delivery, which is not provided by ICE. Furthermore, ICE is not
> supported by plain UDP/BFC either, or you will end up with TCP/UDP/BFCP
> (different from TCP/BFCP) which everyone found to be even more confusing. I
> think some explanation of this would be helpful.
>
>
>
> Regards,
>
> _____________
>
> Roman Shpount
>
>
>
>