Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-03

[Tom Kristensen <[e-mail]>]

 From Charles' explanation and recap, I now see that we may add to 
rfc4583bis text describing the mandated use of setup:actpass in offers 
and recommended use of setup:active in answers.

-- Tom

On 11/05/2012 12:44 AM, Charles Eckel (eckelcu) wrote:
> Hi Gonzalo,
>
> We discussed this at IETF 82. I remember because I presented a slide on it :)
>
> RFC 4582 states the following with regard to TLS:
>
>     Which party, the client or the floor control server, acts as the TLS
>     server depends on how the underlying TCP connection is established.
>     For example, when the TCP connection is established using an SDP
>     offer/answer exchange [7], the answerer (which may be the client or
>     the floor control server) always acts as the TLS server.
>
> For  DTLS, we considered the following alternatives:
>
> 1.The answerer always acts as the TLS/DTLS server, per RFC 4583 (as currently defined)
> 2.The BFCP server always acts as the TLS/DTLS server
> 3.The offerer always offers setup:actpass and the answerer answers either setup:active or setup:passive, where setup:active is RECOMMENDED (per RFC 5763)
>
> The consensus was that (3) was the preferred option, because it adheres to RFC 5763, does not overload offer/answer semantics, and it works for offerless INVITE with B2BUAs.
>
> Additional details are available in the alias archive:
> http://www.ietf.org/mail-archive/web/bfcpbis/current/msg00007.html
> and also in the meeting minutes:
> http://tools.ietf.org/wg/bfcpbis/minutes?item=minutes82.html
>
> At the time of this decision, we did not consider changing the existing guidance in RFC 4582 regarding TLS connection establishment. Doing so would introduce a backward compatibility concern.
>
> Cheers,
> Charles
>
>
>    
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Gonzalo Camarillo
>> Sent: Sunday, November 04, 2012 10:52 AM
>> To: Tom Kristensen (tomkrist)
>> Cc: [e-mail]
>> Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-03
>>
>> Hi Tom,
>>
>> the way it is defined right now, how to determine which endpoint is the
>> TLS or DTLS server is different in TLS (the answerer) and in DTLS
>> (depends on the setup attribute). Why do you think we should not be
>> consistent across both transports?
>>
>> Thanks,
>>
>> Gonzalo
>>
>>
>> On 30/10/2012 8:19 AM, Tom Kristensen wrote:
>>      
>>> Gonzalo,
>>>
>>> I'll add a definition of "BFCP connection" in rfc4582bis to avoid
>>> confusion.
>>>
>>> Regarding the setup attr. I merely reflected in rfc4583bis what has been
>>> part of rfc4582 for a while.
>>> - Cf. http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-06#section-7
>>> - Note that the setup attr. is also used in DTLS-SRTP, cf. RFC 5763.
>>>
>>> -- Tom
>>>
>>> On 10/30/2012 12:51 PM, Gonzalo Camarillo wrote:
>>>        
>>>> Hi Tom,
>>>>
>>>> thanks for your answers.
>>>>
>>>> With respect to the term BFCP connection, in addition to making a
>>>> consistent use of it across both documents, make sure it is defined
>>>> somewhere so that implementers are clear on what it means.
>>>>
>>>> Regarding UDP, we cannot really use the setup attribute for that. That
>>>> attribute is defined for connection oriented protocols. Additionally, we
>>>> need to be consistent regarding DTLS and TLS server determination.
>>>> Section 8 explains how to determine the endpoint acting as the TLS
>>>> server (i.e., the answerer). We cannot determine which endpoint acts as
>>>> the DTLS server in a different way.
>>>>
>>>> Cheers,
>>>>
>>>> Gonzalo
>>>>
>>>>
>>>> On 30/10/2012 11:43 AM, Tom Kristensen wrote:
>>>>
>>>>          
>>>>> On 10/24/2012 04:27 PM, Gonzalo Camarillo wrote:
>>>>>
>>>>>            
>>>>>> Folks,
>>>>>>
>>>>>>
>>>>>>              
>>>>> [...]
>>>>>
>>>>>            
>>>>>> Comments on draft-ietf-bfcpbis-rfc4583bis-03
>>>>>>
>>>>>> Section 3 includes a discussion about how to set the port field. That
>>>>>> discussion is only relevant to TCP. The new draft needs to explain that
>>>>>> and add a discussion about port handling in UDP.
>>>>>>
>>>>>>
>>>>>>              
>>>>> Good catch. Reorganizing the text and adding this for UDP:
>>>>>
>>>>>     "When UDP is used as transport, the port field contains the
>>>>>      port to which the remote endpoint will direct BFCP messages
>>>>>      regardless of the value of the 'setup' attribute."
>>>>>
>>>>>
>>>>>            
>>>>>> Also, the document needs to discuss what is the equivalent of
>>>>>> establishing a TCP connection (i.e., it allows endpoints to start
>>>>>> exchanging BFCP messages) in UDP.
>>>>>>
>>>>>>
>>>>>>              
>>>>> The term "BFCP connection" is used in rfc4582bis/rfc4583bis
>>>>>            
>> independent
>>      
>>>>> of underlying transport.
>>>>>
>>>>>    (For rfc4582bis: I propose we keep this common term regardless of
>>>>> underlying transport and change the three occurrences of "BFCP
>>>>> association" in Section 6.2 and 8.31 to "BFCP connection" as well.)
>>>>>
>>>>> However, we do indeed need to specify the counterpart of Section 7
>>>>>            
>> "TCP
>>      
>>>>> Connection Management" for UDP as transport. Will add a sentence or
>>>>>            
>> two,
>>      
>>>>> since using UDP as transport is quite straight forward. Will also need
>>>>> to add a UDP description to Section 8, i.e. mandate using the 'setup'
>>>>> attribute when DTLS is used.
>>>>>
>>>>> Added to start of Section 7, now renamed to "BFCP Connection
>>>>> Management":
>>>>>     "BFCP connections may use TCP or UDP as underlying transport. BFCP
>>>>>      entities exchanging BFCP messages over UDP will direct the BFCP
>>>>>      messages to the peer side connection address and port provided in
>>>>>      the SDP 'm' line. TCP connection management is more complicated
>>>>>      and is described below."
>>>>> And the subsection named "TCP Connection Management" follows.
>>>>>
>>>>> Added this sentence at the end of Section 8:
>>>>>     "Endpoints that use the offer/answer model to establish a DTLS
>>>>> association MUST
>>>>>      support the 'setup' attribute, as defined in RFC 4145. When
>>>>>      DTLS is used with UDP, the 'setup' attribute indicates which of the
>>>>> endpoints
>>>>>      (client or floor control server) initiates the DTLS association
>>>>> setup."
>>>>>
>>>>>
>>>>>            
>>>>>> Section 6 contains the following new paragraph:
>>>>>>
>>>>>> " Note: In [15] 'm-stream' was erroneously used in Section 9.  Although
>>>>>>      the example was non-normative, it is implemented by some
>>>>>>              
>> vendors.
>>      
>>>>>>      Therefore, it is RECOMMENDED to support parsing and interpreting
>>>>>>      'm-stream' the same way as 'mstrm' when receiving."
>>>>>>
>>>>>> The text should clarify (or be more explicit about) whether existing
>>>>>> implementations are floor control server implementations or client
>>>>>> implementations. The idea is that new implementers know clearly
>>>>>>              
>> what
>>      
>>>>>> exactly they need to support in order to be backwards compatible with
>>>>>> those legacy implementations (whose implementers did not read RFCs
>>>>>>              
>> but
>>      
>>>>>> only the examples :-) ).
>>>>>>
>>>>>>
>>>>>>              
>>>>> Yeah, what kind of developers do this kind of things? :-P
>>>>>
>>>>> Usage of a=floorid (and mstrm/m-stream) applies to endpoints willing
>>>>>            
>> to
>>      
>>>>> act as server, will add this to the second sentence in the note:
>>>>>     "[...] some vendors and occurs in cases where the endpoint is willing
>>>>> to act as an server."
>>>>>
>>>>>
>>>>>            
>>>>>> The last paragraph of Section 8 discusses which entity behaves as the
>>>>>> TLS server. Do we need a similar discussion for DTLS?
>>>>>>
>>>>>>
>>>>>>              
>>>>> Indeed. Handled above.
>>>>>
>>>>> -- Tom
>>>>>
>>>>>
>>>>>            
>>>>          
>>>        
>> _______________________________________________
>> bfcpbis mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>