Subject: [MMUSIC] SDP Capability Negotation: Minutes of 12/19/06 conference call

From: Flemming Andreasen <[email-masked]>
Date: Mon, 01 Jan 2007 23:01:25 -0500

Greetings

The SDP Capability Negotiation Design team held its first conference 
call on 12/12/06. The attendees were:

Cullen Jennings
Flemming Andreasen
Thomas Stach
Roni Even
Bob Gilman
Colin Perkins

The items discussed were

1) Feedback on the open issues posted to the list (REQ-50, 150, and 160)
----------------------------------------------------------------------------
The design team had already discussed these on the last call and were in 
general agreement with those requirements as stated in the current 
requirements document. So far, there has not been any feedback on any of 
these on the mailing list. Roni Even furthermore noted that alternatives 
between media streams are not used in current products (which argues for 
keeping REQ-160 optional).

2) Review updated requirements (85, 121, 122, 301 and 302)
---------------------------------------------------------------
There was consensus within the design team on the updated requirements 
(85, 121, 122, 301 and 302), however REQ-85 generated a bit of 
discussion around whether we should make a distinction between SIP 
B2BUAs and SIP proxies as middle-boxes and impose different requirements 
on them. It was suggested that B2BUAs should not pass anything in the 
SDP that they do not understand, as that might interfere with correct 
operation. Conversely, such a requirement does not allow for 
transparency and even proxies may need to understand the extensions in 
certain middle-box scenarios. The design team agreed it was best to stay 
silent on this from a requirements point of view, but that we should add 
a couple of informative statements around middle-boxes (proxies versus 
B2BUAs) and how the new capability negotiation extensions may affect 
them if they pass them through without understanding them (and e.g. they 
process media).

3) Should we have some security requirements, and if so, what are they ?
-------------------------------------------------------------------------
SDP capability negotiation introduces a new set of security issues, and 
the question was whether the requirements document should try and 
address those by identifying specific security requirements. Cullen did 
not see a need for specific security requirements in the document and 
the team agreed with that. We will however be making certain security 
assumptions, and those need to be documented. More specifically:
- Whatever is carrying the SDP is assumed to provide integrity (but not 
confidentiality), and from there we need to protect against downgrade 
attacks.
- We do not provide the security solution for "whatever is carrying the 
SDP"
- We will have to describe our trust model (e.g. end-to-end and using 
"identity", or trusted with hop-by-hop signaling)

We will only provide the security assumptions in the requirements 
document. All the "real" security considerations (and assumptions) of 
course need to go in the solutions document. One security consideration 
that will eventually need to be described is the playing out of early 
media prior to receiving an answer (or other indication of the answerers 
chosen configuration).

4) Next call and plan forward
------------------------------
An updated requirements document in accordance with the above will be 
published soon. Once that is done, the plan is to issue a WGLC to ensure 
working group consensus on the requirements
An updated solution document will be published by 1/2/07.
We will not have a call on 1/2/07. The next call will be on 1/9/07, 
where the updated solution document will be discussed.

Thanks

-- Flemming

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 02 Jan 2007 09:54:05 -0500

Flemming Andreasen wrote:
> call on 12/12/06. 
Oops - that should obviously have said:

The SDP Capability Negotiation Design team held its second conference 
call on 12/19/06.

> The attendees were:
> The design team had already discussed these on the last call and were 
> in general agreement with those requirements as stated in the current 
> requirements document. So far, there has not been any feedback on any 
> of these on the mailing list. Roni Even furthermore noted that 
> alternatives between media streams are not used in current products 
> (which argues for keeping REQ-160 optional).
>
>
> B2BUAs and SIP proxies as middle-boxes and impose different 
> requirements on them. It was suggested that B2BUAs should not pass 
> anything in the SDP that they do not understand, as that might 
> interfere with correct operation. Conversely, such a requirement does 
> not allow for transparency and even proxies may need to understand the 
> extensions in certain middle-box scenarios. The design team agreed it 
> was best to stay silent on this from a requirements point of view, but 
> that we should add a couple of informative statements around 
> middle-boxes (proxies versus B2BUAs) and how the new capability 
> negotiation extensions may affect them if they pass them through 
> without understanding them (and e.g. they process media).
>
>
> SDP capability negotiation introduces a new set of security issues, 
> and the question was whether the requirements document should try and 
> address those by identifying specific security requirements. Cullen 
> did not see a need for specific security requirements in the document 
> and the team agreed with that. We will however be making certain 
> security assumptions, and those need to be documented. More specifically:
> - Whatever is carrying the SDP is assumed to provide integrity (but 
> not confidentiality), and from there we need to protect against 
> downgrade attacks.
> - We do not provide the security solution for "whatever is carrying 
> the SDP"
> course need to go in the solutions document. One security 
> consideration that will eventually need to be described is the playing 
> out of early media prior to receiving an answer (or other indication 
> of the answerers chosen configuration).
>
>
> published soon. Once that is done, the plan is to issue a WGLC to 
> ensure working group consensus on the requirements