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

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Sun, 04 November 2012 15:52 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBD621F85E3 for <bfcpbis@ietfa.amsl.com>; Sun, 4 Nov 2012 07:52:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.874
X-Spam-Level:
X-Spam-Status: No, score=-105.874 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8icXopxlmKU for <bfcpbis@ietfa.amsl.com>; Sun, 4 Nov 2012 07:52:11 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A8D4C21F8503 for <bfcpbis@ietf.org>; Sun, 4 Nov 2012 07:52:10 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1e6d000002d2c-9d-50968f294ecc
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 96.C3.11564.92F86905; Sun, 4 Nov 2012 16:52:09 +0100 (CET)
Received: from [131.160.126.137] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Sun, 4 Nov 2012 16:52:08 +0100
Message-ID: <50968F26.9080403@ericsson.com>
Date: Sun, 04 Nov 2012 10:52:06 -0500
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Tom Kristensen <tomkrist@cisco.com>
References: <5087FAE4.5010900@ericsson.com> <508FA129.1090802@cisco.com> <508FBF31.8000906@ericsson.com> <508FC5C1.4040702@cisco.com>
In-Reply-To: <508FC5C1.4040702@cisco.com>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3Rlezf1qAwf0Dihb/1h1lsrhy5Beb A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXx5m5KwXnNirbnDUwNjOcVuhg5OCQETCT6 X/h0MXICmWISF+6tZ+ti5OIQEjjJKPHt43QmCGcNo8TractYQKp4BbQlLrxdzAxiswioSJz6 /JwJxGYTsJDYcus+WI2oQJTEoY0H2SHqBSVOznwCFhcRUJfo2/sdLM4sICKx4PlvFpAjhAWc JXbuT4LY1coocX3nCrD5nAKaEpuP32ODuE5S4u37V8wQvXoSU662MELY8hLb384BiwsB3bb8 WQvLBEahWUhWz0LSMgtJywJG5lWM7LmJmTnp5YabGIGBenDLb90djKfOiRxilOZgURLn5Ura 7y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBseT1i59m7a5ru9+EaKh/W8qSe5Dl2PIC/e0r Zxde+jaB2VZDOfSf9A+15yL2NmnC0v179NMK+7Ju7yyxfBpeGXzWvLh/d7yz9K45R+arzXPu 3Oq83SBF0O+rwcROqaOqDd+k/rBtWppdf85csNV6SdatLSksrJdDlk7KFN+Vf7Xn2NmQaoY+ JZbijERDLeai4kQAZkZzsiICAAA=
Cc: bfcpbis@ietf.org
Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-03
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bfcpbis>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Nov 2012 15:52:11 -0000

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
>>>
>>>      
>>    
>