Re: [bfcpbis] [MMUSIC] m= line protocol in case of ICE

[Roman Shpount <[e-mail]>]

Hi All,

I just wanted to add to my previous email, that according to RFC
6544 protocols running over tcp candidates MUST use  RFC 4571 framing (
https://tools.ietf.org/html/rfc6544#section-10.1). This means that BFCP
running over tcp candidate is not TCP/BFCP and will require a different
transport tag.

Regards,

_____________
Roman Shpount

On Thu, Nov 17, 2016 at 9:13 PM, Roman Shpount <[e-mail]> wrote:

> Hi All,
>
> There are three comments I wanted to make regarding general nature of all
> existing protocols designed to work ICE
>
> 1. Protocols running on top of ICE assume that regardless what candidate
> pair is used, including tcp candidates, the underlying network transport is
> unordered and unreliable. During nomination, including continuous
> nomination, candidate pairs can switch, including switching from udp to tcp
> or from tcp to udp. This typically means that protocol re-transmit timers
> are operational, packets are re-ordered at the protocol level, and
>  UDP-friendly packet sizes are used even when packets are sent over tcp
> candidates. For instance DTLS and SCTP re-transmit timers, reordering, and
> fragmentation support are still running when tcp candidates are used.
>
> 2. Protocols do not assume that particular candidate network transport
> runs all the way from origination to final destination of the protocol
> packets. For instance there are SBC which only handle ICE. These SBC run
> the ICE state machine and then transmit the underlying protocol data to the
> final destination using public IP. Because of this, it is not unusual for
> RTP to run over tcp candidate until SBC and then run over UDP to the final
> destination. This is one more reason why re-transmit timers and other
> mechanisms used to deal with UDP are still running over tcp candidates.
>
> 3. I am not aware of any current protocol running over ICE tcp candidates
> which is not using RFC4571 framing. For instance DTLS could have been
> implemented using DTLS protocol framing without RFC4571 over tcp
> candidates, but this was not the case. This is partially done to simplify
> implementation of SBC which terminate ICE and transmit protocol data using
> UDP. By using RFC 4571 framing, SBC can packetize/de-packetize data
> transmitted over tcp candidates without knowing protocol details.
>
> To conclude, up until this point ICE tcp candidates were not treated as
> reliable transport and served simply as another way to transmit UDP packets
> through firewalls. Because of this, I would argue that BFCP running over
> tcp candidate is not the same as TCP/BFCP, in the same way as DTLS running
> over tcp candidate is not TLS.
>
> I would also argue that any protocol running over ICE is, in essence, a
> UDP based protocol, using tcp candidates only as a fall back mechanism for
> firewall traversal, same way as when data is relayed over TURN TCP, it is
> still considered sent over UDP at the protocol level.
>
> If ICE group agrees, I think this should be documented by saying that UDP
> is a MUST implement for any protocol using ICE and that default candidate
> should be UDP based.
>
> Regards,
> _____________
> Roman Shpount
>
> On Thu, Nov 17, 2016 at 8:14 PM, Alan Ford <[e-mail]> wrote:
>
>> Adding bfcpbis.
>>
>> You raise a good point Roman - there’s no definition of how to actually
>> use ICE with BFCP at the protocol level - this only came up in some very
>> late reviews of 4582bis. The initial suggestion was to use the same text as
>> in draft-ietf-mmusic-sctp-sdp-19, but it then raised the point that,
>> given BFCP does not have a MTI protocol, if the offerer supported both they
>> would include their preferred option, but if the receiver supported the
>> other variant, there’s no way to immediately negotiate that without a
>> re-INVITE.
>>
>> Christer’s suggestion to relax the requirement that the m-line protocol *in
>> the answer* matches one of the ICE candidates would support the case
>> where the offerer supports both but prefers UDP, but the answerer only
>> supports TCP. Although no implementations currently do ICE here, this
>> relaxation would leave the door open to gaining this negotiation
>> flexibility in bfcpbis implementations. There seems no reason to have this
>> requirement applied to the answer in the first place.
>>
>> I don’t understand the comment about SBCs; today, tcp candidates are used
>> for media and data channels end-to-end in WebRTC, to name but one
>> implementation.
>>
>> Regards,
>> Alan
>>
>> On 17 Nov 2016, at 03:05, Roman Shpount <[e-mail]> wrote:
>>
>> Adding ICE group to this message.
>>
>> The approach always was that tcp candidates can potentially go only as
>> far as SBC and then be terminated by UDP transport. Because of this
>> everything transmitted over tcp candidate was still considered to be
>> transmitted over the unreliable out-of-order transport. It is also assumed
>> that candidates can switch from UDP to TCP based candidate during
>> nomination. This is why, for instance, we run DTLS with RFC4571 framing
>> over tcp candidates, not TLS. Because of this I always thought that ICE is
>> UDP first with additional TCP transports for situation when UDP will not
>> work. So, as a result, I think ICE-bis should specify that UDP MUST be
>> supported and default candidate MUST be UDP. ICE SDP can reflect this, but
>> I think this is the underlying protocol requirement.
>>
>> I also wanted to add that BFCP needs to examine how ICE support is
>> implemented by this protocol. I think it is not covered in the current
>> drafts. I also think I do not think it is possible for TCP/BFCP to run over
>> ICE. On the other hand UDP/DTLS/BFCP and TCP/DTLS/BFCP would trivial based
>> on current DTLS work.
>>
>> Regards,
>> _____________
>> Roman Shpount
>>
>> On Wed, Nov 16, 2016 at 8:44 PM, Christer Holmberg <
>> [e-mail]> wrote:
>>
>>> I have no problem with Roman’s must-support-UDP suggestion. I guess the
>>> question is whether the BFCP folks could accept that. Cullen did say that
>>> TCP-based BFCP deployments have been around for a decade. But, do they
>>> support ICE?
>>>
>>>
>>>
>>> If we decide to move forward with such approach, we need to ask
>>> ourselves whether must-support-UDP should be an ICE requirement (in which
>>> case the suggestion should be brought to the ICE WG) or whether it should
>>> only be an ICE-using-SIP-SDP requirement.
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Christer
>>>
>>>
>>>
>>> *From:* mmusic [mailto:[e-mail]] *On Behalf Of *Roman
>>> Shpount
>>> *Sent:* 17 November 2016 00:52
>>> *To:* [e-mail]
>>> *Subject:* [MMUSIC] m= line protocol in case of ICE
>>>
>>>
>>>
>>> Hi All,
>>>
>>>
>>>
>>> I just wanted to return to the m= line protocol issue that Christer
>>> raised during the last MMUSIC session.
>>>
>>>
>>>
>>> All the ICE implementations I've seen are primarily UDP based with
>>> support for tcp host candidates which are primarily used to connect to end
>>> points on public IP. If all ICE implementations are continue to be
>>> primarily UDP based, then the simplest solution would be to require UDP
>>> support when any given protocol is implemented over ICE. DTLS and RTP are
>>> already primarily UDP based so this is a non-requirement. Even more, all
>>> protocols that are implemented on top of ICE must assume that underling
>>> transports (including tcp candidates) are unreliable, since candidate pair
>>> can change at any time between reliable and unreliable transports, so this
>>> makes them different from protocols implemented on plain TCP or TLS.
>>>
>>>
>>>
>>> So the first question I wanted to ask is anybody interested in TCP only
>>> ICE implementation where the protocol running on top of such implementation
>>> relies on the reliable delivery of underlying messages? By this I mean,
>>> does anybody wants implement TCP based ICE, with simultaneous open,
>>> reflexive and relay candidates in such a way that ICE implementation will
>>> run from behind NAT without ever needing a UDP candidate?
>>>
>>>
>>>
>>> I understand that BFCP was used for a long time, but I do not think
>>> TCP/BFCP or TCP/TLS/BFCP can even be used with ICE. I think only UDP/BFCP,
>>> UDP/DTLS/BFCP and TCP/DTLS/BFCP can even support ICE.
>>>
>>>
>>>
>>> I think both rfc4582bis and rfc4583bis need a careful review and
>>> additional sections that describe ICE considerations. I think the most
>>> obvious thing would be to specify that ICE can only be supported by
>>> UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP. It will also mean in which case
>>> RFC4571 is used when tcp candidates are used. Furthermore, when tcp
>>> candidate is selected with UDP/BFCP transport, it is not the same thing as
>>> using TCP/BFCP and will need a different transport tag (something like
>>> TCP/UDP/BFCP). Alternatively we can require that only secure versions of
>>> BFCP are used with ICE and only allow ICE usage for UDP/DTLS/BFCP and
>>> TCP/DTLS/BFCP.
>>>
>>>
>>>
>>> To conclude, I would argue that the simplest solution would be that for
>>> all protocols implemented on top of ICE, UDP MUST be supported and default
>>> candidates MUST be UDP based. This avoids building uncomfortable artificial
>>> constructs to avoid ICE mismatch and requires minimal changes to existing
>>> specifications.
>>>
>>>
>>>
>>> Regards,
>>>
>>> _____________
>>> Roman Shpount
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
>>
>