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

[Tom Kristensen <[e-mail]>]

In the upcoming version, I've simply added an informational note at the 
end of Section 8. Authentication. It reads:

     "Informational note: How to determine which endpoint to initiate
       the TLS/DTLS association depends on the selected underlying
       transport.  It was decided to keep the original semantics in [15]
       for TCP to retain backwards compatibility.  When using UDP, the
       procedure above was preferred since it adheres to [13] as used for
       DTLS-SRTP, it does not overload offer/answer semantics, and it
       works for offerless INVITE in scenarios with B2BUAs."

Where [15] == RFC 4582 and [13] == RFC 5763.

-- Tom

On 11/06/2012 12:01 AM, Charles Eckel (eckelcu) wrote:
> Works for me.
>
> Thanks,
> Charles
>
>    
>> -----Original Message-----
>> From: Gonzalo Camarillo [mailto:[e-mail]]
>> Sent: Monday, November 05, 2012 8:00 AM
>> To: Charles Eckel (eckelcu)
>> Cc: Tom Kristensen (tomkrist); [e-mail]
>> Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-03
>>
>> Hi Charles,
>>
>> the point is that if we have decided not to be consistent across
>> transports, we need to explain why in the RFCs. So, please, add some
>> text (a few sentences should be enough) explaining why (i.e., something
>> along the lines of your email below).
>>
>> Thanks,
>>
>> Gonzalo
>>
>> On 04/11/2012 6:44 PM, 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
>>>>          
>
>