Subject: Re: [bfcpbis] Eric Rescorla's Discuss on draft-ietf-bfcpbis-rfc4583bis-26: (with DISCUSS and COMMENT)

From: Christer Holmberg <[email-masked]>
Date: Sun, 2 Dec 2018 19:29:36 +0000

Hi,

Eventhough Ekr changed his position from DISCUSS to No Objection, he did have some COMMENTs in his initial review. They can not be seen in the datatracker anymore, but I will still address them.
    
    > S 5.3.
    >      The SDP Offer/Answer procedures for the 'confid' attribute are
    >      defined in Section 10.
    >   
    >   5.3.  SDP 'userid' Attribute
    >   
    >      This section defines the SDP userid' media-level attribute.  The
    >
    > Are there any security considerations around this attribute?
    
The userid does identify a participant (however, it does not contains any user information), but I think the security considerations associated with it belong to 4582bis.

---
    
    > S 5.5.
    >      'bfcpver' attribute in offers and answers.  The attribute value, if
    >      present, MUST be in accordance with the definition of the Version
    >      field in [I-D.ietf-bfcpbis-rfc4582bis].  If the attribute is not
    >      present, endpoints MUST assume a default value in accordance with
    >      [I-D.ietf-bfcpbis-rfc4582bis]: when used over a reliable transport
    >      the default attribute value is "1", and when used over an unreliable
    >
    > Just for clarity: UDP over TURN-TCP is an unreliable transport, right?
    
I would assume so, but I guess that question is not BFCP specific?

---    

    > S 7.1.
    >      deliver a BFCP message and times out, the endpoint that attempted to
    >      send the message (i.e., the one that detected the TCP timeout) MUST
    >      send an offer in order to re-establish the TCP connection.
    >   
    >      Endpoints that use the offer/answer mechanism to negotiate TCP
    >      connections MUST support the 'setup' and 'connection' attributes.
    >
    > You probably need a reference here.
    
I will add a reference.

---    

    >S 10.1.
    >   
    >      o  MUST associate an SDP 'floorid' attribute (Section 5.4) with the
    >         'm' line; and
    >   
    >      o  MUST associate an SDP 'label' attribute ([RFC4574]) with the 'm'
    >         line of each BFCP-controlled media stream.
    >
    > We managed to mostly purge "associate" from BUNDLE. Can we do it here
    > too?

    We could, but I'd prefer not to. It is not a widely used as in BUNDLE, so my suggestion is we keep it.
    
---
    
    > S 10.2.
    >      o  MUST insert a corresponding 'm' line in the answer, with an
    >         identical 'm' line proto value [RFC3264]; and
    >   
    >      o  MUST associate a 'bfcpver' attribute with the 'm' line.  The
    >         answerer only indicates support of BFCP versions also supported by
    >         the offerer; and
    >
    > Is this an odd way of saying you must subset what the offer contained?
    
    Yes - assuming including the same set of values would still count as a subset.

    If so, we could say:

    "The versions indicated by the answer MUST be a subset of the versions indicated by the offerer in the corresponding offer."
    
Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Dec 2018 16:48:30 -0800

On Sun, Dec 2, 2018 at 11:29 AM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> Eventhough Ekr changed his position from DISCUSS to No Objection, he did
> have some COMMENTs in his initial review. They can not be seen in the
> datatracker anymore, but I will still address them.
>
>     > S 5.3.
> The userid does identify a participant (however, it does not contains any
> user information), but I think the security considerations associated with
> it belong to 4582bis.
>

OK.

---
> I would assume so, but I guess that question is not BFCP specific?

Sorry, what I mean is "does BFCP count it as an unreliable transport". I
agree it is unreliable.

> so my suggestion is we keep it.

I would prefer to lose it, but I'm notwilling to go to the mat over it.

>     "The versions indicated by the answer MUST be a subset of the versions
> indicated by the offerer in the corresponding offer."
>

Yes, though perhaps the term "proper subset" is not widely known outside US
technical circles, so we could say "must be the same or a subset of"

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Dec 2018 14:01:01 +0000

Hi,

---

> Sorry, what I mean is "does BFCP count it as an unreliable transport". I agree it is unreliable.

Do you think we need to add some text about it?

Related to that, if ICE is used, if both UDP and TCP candidates are offered, endpoints might not know what kind of transport will eventually be selected. Perhaps there should be a note about that?

Something like:

"Note: When ICE is used, where the candidates represent both reliable and unreliable transports, the ICE process will determine what type of transport will eventually be used."

---    
    
> I would prefer to lose it, but I'm not willing to go to the mat over it.

I will see what I can do.

---

    >>> S 10.2.
    >>>      o  MUST insert a corresponding 'm' line in the answer, with an
    >>>         identical 'm' line proto value [RFC3264]; and
    >>>   
    >>>      o  MUST associate a 'bfcpver' attribute with the 'm' line.  The
    >>>         answerer only indicates support of BFCP versions also supported by
    >>>         the offerer; and
    >>>
    >>> Is this an odd way of saying you must subset what the offer contained?
    >> Yes - assuming including the same set of values would still count as a subset.
    >> If so, we could say:
    >> "The versions indicated by the answer MUST be a subset of the versions indicated by the offerer in the corresponding offer."
    >
    > Yes, though perhaps the term "proper subset" is not widely known outside US technical circles, so we could say "must be the same or a subset of"

   I will modify as suggested.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Dec 2018 06:22:49 -0800

On Mon, Dec 3, 2018 at 6:01 AM Christer Holmberg <
[email-masked]> wrote:

> Related to that, if ICE is used, if both UDP and TCP candidates are
> offered, endpoints might not know what kind of transport will eventually be
> selected. Perhaps there should be a note about that?
>
> Something like:
>
> "Note: When ICE is used, where the candidates represent both reliable and
> unreliable transports, the ICE process will determine what type of
> transport will eventually be used."
>

Well, ICE can flip-flop the transport, so I think if you have anything
other than ICE-TCP (which is to say anyone who uses ICE) then you have to
assume it's unreliable

-Ekr

---
>     >> "The versions indicated by the answer MUST be a subset of the
> versions indicated by the offerer in the corresponding offer."
>     >
>     > Yes, though perhaps the term "proper subset" is not widely known
> outside US technical circles, so we could say "must be the same or a subset
> of"
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Dec 2018 14:33:24 +0000

Hi,

---

>> Related to that, if ICE is used, if both UDP and TCP candidates are offered, endpoints might not know what kind of transport will eventually 
>> be selected. Perhaps there should be a note about that?
>>
>> Something like:
>>
> Well, ICE can flip-flop the transport, so I think if you have anything other than ICE-TCP (which is to say anyone who uses ICE) then you have to assume it's unreliable

My point was that when you send the offer, and set the 'bfcpver' attribute value, if you use ICE you may not yet know whether the transport will eventually be reliable or unreliable (if you offer candidates for both reliable and unreliable transports).

I guess we could say that the attribute value must match the transport indicated in the 'm' line. That way things will be correct if the remote peer does not support ICE.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Dec 2018 06:55:07 -0800

On Mon, Dec 3, 2018 at 6:33 AM Christer Holmberg <
[email-masked]> wrote:

> offered, endpoints might not know what kind of transport will eventually
> >> "Note: When ICE is used, where the candidates represent both reliable
> and unreliable transports, the ICE process will determine what type of
> My point was that when you send the offer, and set the 'bfcpver' attribute
> value, if you use ICE you may not yet know whether the transport will
> eventually be reliable or unreliable (if you offer candidates for both
> reliable and unreliable transports).
>
> I guess we could say that the attribute value must match the transport
> indicated in the 'm' line. That way things will be correct if the remote
> peer does not support ICE.
>

i don't really know what this attribute is used for so it's hard for me to
say.

Can you explain what it does?

-Ekr

Regards,

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Dec 2018 15:10:44 +0000

Hi,

>> My point was that when you send the offer, and set the 'bfcpver' attribute value, if you use ICE you may not yet know whether the transport will eventually be reliable 
>> or unreliable (if you offer candidates for both reliable and unreliable transports).
> i don't really know what this attribute is used for so it's hard for me to say.
>

It's used to negotiate the BFCP version. The default values are based on whether the transport is reliable or unreliable, which is a little strange, but 4583bis endpoints will always explicitly include it so there is no issues. I withdraw my comment :)

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 3 Dec 2018 14:08:06 -0500

On Mon, Dec 3, 2018 at 10:11 AM Christer Holmberg <
[email-masked]> wrote:

> >> My point was that when you send the offer, and set the 'bfcpver'
> attribute value, if you use ICE you may not yet know whether the transport
> will eventually be reliable
> It's used to negotiate the BFCP version. The default values are based on
> whether the transport is reliable or unreliable, which is a little strange,
> but 4583bis endpoints will always explicitly include it so there is no
> issues. I withdraw my comment :)
>
>
Any BFCP protocol version used with ICE is always considered unreliable.
ICE-TCP is unreliable since ICE-TCP is not necessarily end-to-end. The only
reliable protocols are TLS/BFCP and TCP/BFCP, neither of which can be used
with ICE.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Dec 2018 19:28:59 +0000

Hi,

Any BFCP protocol version used with ICE is always considered unreliable. ICE-TCP is unreliable since ICE-TCP is not necessarily end-to-end. The only reliable protocols are TLS/BFCP and TCP/BFCP, neither of which can be used with ICE.

A bis endpoint will always explicitly include the 'bfcpver' attribute, so there is no problem.

Regards,

Christer