Subject: [bfcpbis] Updates to draft-ietf-bfcpbis-rfc4583bis required to enable ICE

From: Roman Shpount <[email-masked]>
Date: Thu, 2 Mar 2017 17:14:07 -0500

HI All,

Here is the first draft of changes proposed for this document:

1. In Section 3, we need to define an additional proto field value:
TCP/DTLS/BFCP, which is realized by running BFCP on top of DTLS as descibed
in this specification and running DTLS on top of TCP is realized using the
framing method defined in RFC4571, with DTLS packets being sent and
received instead of RTP/RTCP packets using the shim defined in RFC4571 so
that length field defined in RFC4571 precedes each DTLS message. All
sections of the document should be updated to include the TCP/DTLS/BFCP
transport.

2. References to RFC 5763 should be replaced with references to
draft-ietf-mmusic-dtls-sdp. Document should be updated to use procedures
from draft-ietf-mmusic-dtls-sdp including dtls-id.

3. References to RFC 4572 should be replaced with references to
draft-ietf-mmusic-4572-update. Document should be checked for compliance
with 4572 update.

4. Section 10.5.is redundant with draft-ietf-mmusic-dtls-sdp.

5. We should not be using SHA-1 fingerprints in examples, since they are
deprecated

6. The following section should be added which describes ICE support:

ICE Considerations

When BFCP is used with UDP based ICE candidates RFC5245 then the procedures
for UDP/TLS/BFCP are used.

When BFCP is used with TCP based ICE candidates RFC6544 then the procedures
for TCP/DTLS/BFCP are used.

In ICE environments, during the nomination process, end points go through
multiple ICE candidate pairs, until the most preferred candidate pair is
found. During the nomination process, data can be sent as soon as the first
working candidate pair is found, but the nomination process still continues
and selected candidate pairs can still change while data is sent.
Furthermore, if end points roam between networks, for instance when mobile
end point switches from mobile connection to WiFi, end points will initiate
an ICE restart, which will trigger a new nomination process between the new
set of candidates and likely result in the new nominated candidate pair.

Implementations MUST treat all ICE candidate pairs associated with an BFCP
session on top of a DTLS association as part of the same DTLS association.
Thus, there will only be one BFCP session setup and one DTLS handshake even
if there are multiple valid candidate pairs, and shifting from one
candidate pair to another, including switching between UDP to TCP candidate
pairs, will not impact the BFCP session or DTLS associations. If new
candidates are added, they will also be part of the same BFCP session and
DTLS associations. When transitioning between candidate pairs, different
candidate pairs can be currently active in different directions and
implementations MUST be ready to receive data on any of the candidates,
even if this means sending and receiving data using UDP/TLS/BFCP and
TCP/DTLS/BFCPat the same time in different directions.

In order to maximize the likelihood of interoperability between the end
points, all ICE enabled BFCP end points SHOULD implement support for
UDP/TLS/BFCP.

When an SDP offer or answer is sent with multiple ICE candidates during
initial connection negotiation or after ICE restart, UDP based candidates
SHOULD be included and default candidate SHOULD be chosen from one of those
UDP candidates. The proto value MUST match the transport protocol
associated with the default candidate. If UDP transport is used for the
default candidate, then 'UDP/TLS/BFCP' proto value MUST be used. If TCP
transport is used for the default candidate, then 'TCP/DTLS/BFCP' proto
value MUST be used. Note that under normal circumstances the proto value
for offers and answers sent during ICE nomination SHOULD be 'UDP/TLS/BFCP'.

When a subsequent SDP offer or answer is sent after ICE nomination is
complete and does not initiate ICE restart, it will contain only the
currently negotiated ICE candidate pair. In this case, the proto value MUST
match the transport protocol associated with the currently negotiated ICE
candidate pair. If UDP transport is used for the currently negotiated pair,
then 'UDP/TLS/BFCP' proto value MUST be used. If TCP transport is used for
the currently negotiated pair, then  'TCP/DTLS/BFCP' proto value MUST be
used. Please note that if an end point switches between TCP-based and
UDP-based candidates during the nomination process the end point is not
required to send an SDP offer for the sole purpose of keeping the proto
value of the
associated m- line in sync.

NOTE: The text in the paragraph above only applies when the usage of ICE
has been negotiated. If ICE is not used, the proto value MUST always
reflect the transport protocol used at any given time.

Regards,
_____________
Roman Shpount

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 2 Mar 2017 23:29:37 +0000

Roman,

Thanks for this.
As an individual, your proposed changes look good to me. Please see two comments inline [cue]

From: Roman Shpount <[email-masked]>
Date: Thursday, March 2, 2017 at 2:14 PM
To: Charles Eckel <[email-masked]>
Cc: Gonzalo Camarillo <[email-masked]>, Tom Kristensen <[email-masked]>, Christer Holmberg <[email-masked]>, Tom Kristensen <[email-masked]>, Mary Barnes <[email-masked]>, Paul Jones <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Updates to draft-ietf-bfcpbis-rfc4583bis required to enable ICE

HI All,

1. In Section 3, we need to define an additional proto field value: TCP/DTLS/BFCP, which is realized by running BFCP on top of DTLS as descibed in this specification and running DTLS on top of TCP is realized using the framing method defined in RFC4571, with DTLS packets being sent and received instead of RTP/RTCP packets using the shim defined in RFC4571 so that length field defined in RFC4571 precedes each DTLS message. All sections of the document should be updated to include the TCP/DTLS/BFCP transport.

[cue] We define the proto field value UDP/TLS/BFCP in this draft for BFCP over DTLS. Would it not be more straightforward and consistent to define the new proto value as TCP/UDP/TLS/BFCP instead of TCP/DTLS/BFCP?

2. References to RFC 5763 should be replaced with references to draft-ietf-mmusic-dtls-sdp. Document should be updated to use procedures from draft-ietf-mmusic-dtls-sdp including dtls-id.

[cue] We previously decided to stick with RFC 5763 because draft-ietf-mmusic-dtls-sdp including dtls-id. Given the state of draft-ietf-mmusic-dtls-sdp including dtls-id at this time, I agree it is now appropriate to reference it instead of RFC 5763.
3. References to RFC 4572 should be replaced with references to draft-ietf-mmusic-4572-update. Document should be checked for compliance with 4572 update.

4. Section 10.5.is<http://10.5.is> redundant with draft-ietf-mmusic-dtls-sdp.

5. We should not be using SHA-1 fingerprints in examples, since they are deprecated

ICE Considerations

When BFCP is used with UDP based ICE candidates RFC5245 then the procedures for UDP/TLS/BFCP are used.

When BFCP is used with TCP based ICE candidates RFC6544 then the procedures for TCP/DTLS/BFCP are used.

In ICE environments, during the nomination process, end points go through multiple ICE candidate pairs, until the most preferred candidate pair is found. During the nomination process, data can be sent as soon as the first working candidate pair is found, but the nomination process still continues and selected candidate pairs can still change while data is sent. Furthermore, if end points roam between networks, for instance when mobile end point switches from mobile connection to WiFi, end points will initiate an ICE restart, which will trigger a new nomination process between the new set of candidates and likely result in the new nominated candidate pair.

Implementations MUST treat all ICE candidate pairs associated with an BFCP session on top of a DTLS association as part of the same DTLS association. Thus, there will only be one BFCP session setup and one DTLS handshake even if there are multiple valid candidate pairs, and shifting from one candidate pair to another, including switching between UDP to TCP candidate pairs, will not impact the BFCP session or DTLS associations. If new candidates are added, they will also be part of the same BFCP session and DTLS associations. When transitioning between candidate pairs, different candidate pairs can be currently active in different directions and implementations MUST be ready to receive data on any of the candidates, even if this means sending and receiving data using UDP/TLS/BFCP and TCP/DTLS/BFCPat the same time in different directions.

In order to maximize the likelihood of interoperability between the end points, all ICE enabled BFCP end points SHOULD implement support for UDP/TLS/BFCP.

When an SDP offer or answer is sent with multiple ICE candidates during initial connection negotiation or after ICE restart, UDP based candidates SHOULD be included and default candidate SHOULD be chosen from one of those UDP candidates. The proto value MUST match the transport protocol associated with the default candidate. If UDP transport is used for the default candidate, then 'UDP/TLS/BFCP' proto value MUST be used. If TCP transport is used for the default candidate, then 'TCP/DTLS/BFCP' proto value MUST be used. Note that under normal circumstances the proto value for offers and answers sent during ICE nomination SHOULD be 'UDP/TLS/BFCP'.

When a subsequent SDP offer or answer is sent after ICE nomination is complete and does not initiate ICE restart, it will contain only the currently negotiated ICE candidate pair. In this case, the proto value MUST match the transport protocol associated with the currently negotiated ICE candidate pair. If UDP transport is used for the currently negotiated pair, then 'UDP/TLS/BFCP' proto value MUST be used. If TCP transport is used for the currently negotiated pair, then  'TCP/DTLS/BFCP' proto value MUST be used. Please note that if an end point switches between TCP-based and UDP-based candidates during the nomination process the end point is not required to send an SDP offer for the sole purpose of keeping the proto value of the
associated m- line in sync.

NOTE: The text in the paragraph above only applies when the usage of ICE has been negotiated. If ICE is not used, the proto value MUST always reflect the transport protocol used at any given time.

Regards,
_____________
Roman Shpount

Cheers,
Charles

---

From: Roman Shpount <[email-masked]>
Date: Thu, 2 Mar 2017 18:49:58 -0500

Charles,

On Thu, Mar 2, 2017 at 6:29 PM, Charles Eckel (eckelcu) <[email-masked]>
wrote:

> [cue] We define the proto field value UDP/TLS/BFCP in this draft for BFCP
> over DTLS. Would it not be more straightforward and consistent to define
> the new proto value as TCP/UDP/TLS/BFCP instead of TCP/DTLS/BFCP?
>
>
>
I am trying to keep proto names as close as possible to
draft-ietf-mmusic-dtls-sdp. I understand that there are already
implementations which use UDP/TLS/BFCP so we cannot change it to the
technically correct value which is UDP/DTLS/BFCP. After all, we are using
DTLS transport, which is different from TLS.

Since there are no implementations of TCP/DTLS/BFCP, we should use the
technically correct protocol string. There is no UDP layer in TCP/DTLS/BFCP
transport stack, since DTLS packets are passed directly to RFC4571 shim.
Because of this I think TCP/DTLS/BFCP value is accurate and appropriate.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 2 Mar 2017 22:49:01 -0500

I would like to make to additional corrections to my proposed text.

1. The text for seciton 3 should be update to mention that BFCP version for
unreliable transports should be used in case of TCP/DTLS/BFCP:

TCP/DTLS/BFCP, which is realized by running BFCP *for unreliable transports*
on top of DTLS as described in this specification and running DTLS on top
of TCP is realized using the framing method defined in RFC4571, with DTLS
packets being sent and received instead of RTP/RTCP packets using the shim
defined in RFC4571 so that length field defined in RFC4571 precedes each
DTLS message.

2. In ICE considerations, I would like to add:

Using ICE with protocols other then UDP/TLS/BFCP and TCP/DTLS/BFCP is
outside of scope for this specification.

Thank You,

_____________
Roman Shpount

On Thu, Mar 2, 2017 at 6:49 PM, Roman Shpount <[email-masked]>
wrote:

> Charles,
>
> On Thu, Mar 2, 2017 at 6:29 PM, Charles Eckel (eckelcu) <[email-masked]
> > wrote:
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 3 Mar 2017 15:18:10 +0000

There is no perfect solution given the mismatch in approach taken originally within rfc4583bis and in draft-ietf-mmusic-dtls-sdp. Your proposal is acceptable to me, and does have the benefit of being both forward and backward compatible.

Cheers,
Charles

From: Roman Shpount <[email-masked]>
Date: Thursday, March 2, 2017 at 3:49 PM
To: Charles Eckel <[email-masked]>
Cc: Gonzalo Camarillo <[email-masked]>, Tom Kristensen <[email-masked]>, Christer Holmberg <[email-masked]>, Tom Kristensen <[email-masked]>, Mary Barnes <[email-masked]>, Paul Jones <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Updates to draft-ietf-bfcpbis-rfc4583bis required to enable ICE

Charles,

On Thu, Mar 2, 2017 at 6:29 PM, Charles Eckel (eckelcu) <[email-masked]<mailto:[email-masked]>> wrote:
[cue] We define the proto field value UDP/TLS/BFCP in this draft for BFCP over DTLS. Would it not be more straightforward and consistent to define the new proto value as TCP/UDP/TLS/BFCP instead of TCP/DTLS/BFCP?

I am trying to keep proto names as close as possible to draft-ietf-mmusic-dtls-sdp. I understand that there are already implementations which use UDP/TLS/BFCP so we cannot change it to the technically correct value which is UDP/DTLS/BFCP. After all, we are using DTLS transport, which is different from TLS.

Since there are no implementations of TCP/DTLS/BFCP, we should use the technically correct protocol string. There is no UDP layer in TCP/DTLS/BFCP transport stack, since DTLS packets are passed directly to RFC4571 shim. Because of this I think TCP/DTLS/BFCP value is accurate and appropriate.

Regards,
_____________
Roman Shpount

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 3 Mar 2017 15:18:49 +0000

These additions look good to me.

Cheers,
Charles

Date: Thursday, March 2, 2017 at 7:49 PM

1. The text for seciton 3 should be update to mention that BFCP version for unreliable transports should be used in case of TCP/DTLS/BFCP:

TCP/DTLS/BFCP, which is realized by running BFCP for unreliable transports on top of DTLS as described in this specification and running DTLS on top of TCP is realized using the framing method defined in RFC4571, with DTLS packets being sent and received instead of RTP/RTCP packets using the shim defined in RFC4571 so that length field defined in RFC4571 precedes each DTLS message.

Using ICE with protocols other then UDP/TLS/BFCP and TCP/DTLS/BFCP is outside of scope for this specification.

Thank You,

_____________
Roman Shpount

On Thu, Mar 2, 2017 at 6:49 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
Charles,

Regards,
_____________
Roman Shpount

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 10 Mar 2017 02:12:14 +0000

Tom,

How are things coming with updating the draft? Any questions or problems incorporating these changes?
The deadline for internet draft submissions is Monday, March 13. Can we expect an update to post before then?

Cheers,
Charles

From: Charles Eckel <[email-masked]>
Date: Friday, March 3, 2017 at 7:18 AM
To: Roman Shpount <[email-masked]>
Cc: Gonzalo Camarillo <[email-masked]>, Tom Kristensen <[email-masked]>, Christer Holmberg <[email-masked]>, Tom Kristensen <[email-masked]>, Mary Barnes <[email-masked]>, Paul Jones <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Updates to draft-ietf-bfcpbis-rfc4583bis required to enable ICE

Cheers,
Charles

Thank You,

_____________
Roman Shpount

Regards,
_____________
Roman Shpount

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 21 Mar 2017 13:26:20 +0000

Hey Folks,

We are not having a bfcpbis session in Chicago, but we are targeting to have an updated version of the draft for us to review and discuss. Tom is working on this as I type. If you have any comments or concerns regarding the text proposed by Roman within this thread, now is the time to share so they can be addressed in the upcoming version.

Cheers,
Charles

Date: Friday, March 3, 2017 at 4:18 PM

Cheers,
Charles

Thank You,

_____________
Roman Shpount

Regards,
_____________
Roman Shpount