Subject: [rtcweb] State of the Forking discussion

From: Magnus Westerlund <[email-masked]>
Date: Thu, 3 Nov 2011 11:13:25 +0100

WG,

I just reviewed the last weeks Forking discussion. This includes the
threads "RTCWeb Forking usecase [was RE:
draft-kaplan-rtcweb-sip-interworking-requirements-00]" and "Media
forking solution for SIP interoperability (without a media gateway)"

As far as I can tell there is not yet even a rough consensus. Therefore
I will attempt to summarize what I personally believe to be the
important points and alternatives in this discussion. Keep in mind that
my assumptions or understanding may be unclear or have errors. So don't
hesitate to challenge what I write.

I think it is important that there are in fact at least two important
questions here.

1. Is forking needed to be supported at all?

2. If it is supported in which form would it supported in.

so lets start looking into the arguments and possibilities for these two
questions. And I do hope that you will read to the end of this mail
which is quite long.

Lets start with the high level functionality part. Is forking needed and
what usage does it have. So forking is all about sending out an
invitation to a media session including an actual media configuration
offer, i.e. SDP Offer, then get more than a single answer to that offer
back. How you deal with these answers as they come in is the difference
between serial and parallel forking. So lets define those.

Parallel forking: For each answer you receive you establish a new actual
media session. Thus if you receive two answers you will have to
different media sessions that are potentially in use at the same time.

Serial forking: The first answer is received and results the
establishment of a media session. At a later point in time a second
answer is received. At that point you take the decision if that second
answer is going to be used to establish a new media session that
replaces the first one. In other words at any given time you will only
have a single media session established based on each offer.

So there has been a number of different views on how one can see on
forking. And I think I will have to bring in a bit reflections on how
this can be done with the current PeerConnection API.

A) No forking is needed: Between WebRTC end-points there is no need for
forking. Instead the application can send out session invitations to the
peers it wants to talk to. These are without any SDP Offer equivalent,
instead end-points that want to communicate they create PeerConnections,
which results in SDP Offers. Thus the communication initiating end-point
becomes the ones that provides SDP answers and get one PeerConnection
per remote end-point that actually want to communicate.

B) We need to have some interworking with SIP: So the fundamental here
is that it needs to be reasonable to interwork with SIP, independent if
one uses a SIP in JS in the application running on the WebRTC enabled
browser, or have signalling gateway in the webserver, or as a remote
WebRTC peer. The issue is that A)'s method of initiating call doesn't
work well with SIP. There is a need to send a SIP Invite with an SDP
Offer and that can result in multiple answers.

To resolve this one could deal with this in a couple of different ways:

B1) Use Iñaki's proposal which forces the WebRTC application to create a
second PeerConnection and then forces an update in the SIP domain with
the second peer-connections Offer. However, it was pointed out that this
doesn't work with SIP Provisional answers, as used by ICE for example,
unless PRACK is supported. The level of PRACK support is reasonable but
far from universal so this would limit the SIP UAs one can interwork
with. However, from WebRTC perspective no forking support is needed. A
single PeerConnection results in one offer and a single answer is
processed.

B2) Require WebRTC to handle replace Answers: So the idea here is that
one changes the PeerConnection API and have underlying functionality so
that at any point in time a new Answer can pushed onto a PeerConnection
and that forces the media session to be reestablished if needed. So if
the ICE candidate list is different an ICE restart happens. This clearly
supports serial forking. It also can create some complexities in the
underlying SDP handling logic if one desires to minimize the media impact.

B3) Local side shared parameters in multiple PeerConnections: The idea
in this proposal is that all PeerConnections generated in a browser
context, like a tab will implicit share the fundamental parameters like
ICE candidates etc for the number of media streams added. So if one
creates a second PeerConnection with the same audio+video MediaStream
object added I will get an offer that is mostly identical to the the
first PeerConnection, thus I can push in the answer from the first
PeerConnection Offer into the second PC object and it will still work.
The downside of this is that it is implicit and it becomes difficult to
determine when it works and when it will fail. It will also be highly
dependent on the application performing the right process to get it to
work. It also causes a sharing of the parameters when not needed or
desired, which primarily is an issue from a security point of view,
especially with SDES keys (see below). The positive is this likely
requires no API changes. This method would also support parallel forking.

B4) Cloning/Factory for PeerConnection: On the API level there will be
explicit support for generating multiple PeerConnections from the same
base. This could either be a factory for PeerConnections or some Object
constructor that clones an existing PeerConnection but that is a W3C
question. By being explicit some of the B3) issues goes away and the
applications can choose when this should happen or not. This also
support parallel forking as the application can deal with each media
session independently. This clearly will have some impact on the API.

Additional considerations:

Shared SDES keys: B2 to B4 will result in that SDES keys from the
Offering party to be used towards all invited parties. This is security
risk as any of the invited parties can spoof the offering side towards
any of the other invited parties. This threat can be resolved by having
the inviter rekey immediately after having received an answer.

Sharing ICE candidates: B3 and B4 and also B2 to some degree will share
the ICE candidates. That has certain implications. One is the positive
in that it minimizes the resource consumption as additional
PeerConnections come at very little extra cost, no need for additional
ICE gathering candidate phases, and also be very quick as no external
communication is required. The downside of this is that the end-points
candidates must always be kept alive as long as some PeerConnection
instance exist. Because the browser never knows when the application may
create an additional PC and expect them to have the same ICE candidates.
It should also be noted that the answering WebRTC end-point will need to
gather candidates for each offer. Otherwise it will become impossible to
create multiple PeerConnections between the same end-points if that is
desired by the application.

I know the above doesn't list all of the pro and cons of the different
alternatives. So please fill in additional arguments. And if I missed
some proposal please add that also if relevant

As you may have noted I the two questions in the above have kind of
floated together. The reason for this is that I think the majority are
fine with having SIP support as long as it doesn't have to high cost or
complexity associated with it. Thus, the question how becomes very
intertwined with forking support yes or no.

So please continue the discussion

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Nov 2011 12:53:39 +0100

Hi Magnus,

Question #1: Is forking needed to be supported at all?

Answer: 	Yes

Question #2: If it is supported in which form would it supported in?

Answer: 	Serial (ie one "active" media session at any given time) forking is enough.

		Solution B2, B3 or B4 - whatever is possible and least complex from a PeerConnection perspective :)

Regards,

Christer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: 3. marraskuuta 2011 12:13
> To: [email-masked]
> Subject: [rtcweb] State of the Forking discussion
> 
> WG,
> 
> I just reviewed the last weeks Forking discussion. This 
> includes the threads "RTCWeb Forking usecase [was RE:
> draft-kaplan-rtcweb-sip-interworking-requirements-00]" and 
> "Media forking solution for SIP interoperability (without a 
> media gateway)"
> 
> As far as I can tell there is not yet even a rough consensus. 
> Therefore I will attempt to summarize what I personally 
> believe to be the important points and alternatives in this 
> discussion. Keep in mind that my assumptions or understanding 
> may be unclear or have errors. So don't hesitate to challenge 
> what I write.
> 
> I think it is important that there are in fact at least two 
> important questions here.
> 
> so lets start looking into the arguments and possibilities 
> for these two questions. And I do hope that you will read to 
> the end of this mail which is quite long.
> 
> Lets start with the high level functionality part. Is forking 
> needed and what usage does it have. So forking is all about 
> sending out an invitation to a media session including an 
> actual media configuration offer, i.e. SDP Offer, then get 
> more than a single answer to that offer back. How you deal 
> with these answers as they come in is the difference between 
> serial and parallel forking. So lets define those.
> 
> Parallel forking: For each answer you receive you establish a 
> new actual media session. Thus if you receive two answers you 
> will have to different media sessions that are potentially in 
> use at the same time.
> 
> establishment of a media session. At a later point in time a 
> second answer is received. At that point you take the 
> decision if that second answer is going to be used to 
> establish a new media session that replaces the first one. In 
> other words at any given time you will only have a single 
> media session established based on each offer.
> 
> So there has been a number of different views on how one can 
> see on forking. And I think I will have to bring in a bit 
> reflections on how this can be done with the current 
> PeerConnection API.
> 
> A) No forking is needed: Between WebRTC end-points there is 
> no need for forking. Instead the application can send out 
> session invitations to the peers it wants to talk to. These 
> are without any SDP Offer equivalent, instead end-points that 
> want to communicate they create PeerConnections, which 
> results in SDP Offers. Thus the communication initiating 
> end-point becomes the ones that provides SDP answers and get 
> one PeerConnection per remote end-point that actually want to 
> communicate.
> 
> B) We need to have some interworking with SIP: So the 
> fundamental here is that it needs to be reasonable to 
> interwork with SIP, independent if one uses a SIP in JS in 
> the application running on the WebRTC enabled browser, or 
> have signalling gateway in the webserver, or as a remote 
> WebRTC peer. The issue is that A)'s method of initiating call 
> doesn't work well with SIP. There is a need to send a SIP 
> Invite with an SDP Offer and that can result in multiple answers.
> 
> B1) Use Iñaki's proposal which forces the WebRTC application 
> to create a second PeerConnection and then forces an update 
> in the SIP domain with the second peer-connections Offer. 
> However, it was pointed out that this doesn't work with SIP 
> Provisional answers, as used by ICE for example, unless PRACK 
> is supported. The level of PRACK support is reasonable but 
> far from universal so this would limit the SIP UAs one can 
> interwork with. However, from WebRTC perspective no forking 
> support is needed. A single PeerConnection results in one 
> offer and a single answer is processed.
> 
> B2) Require WebRTC to handle replace Answers: So the idea 
> here is that one changes the PeerConnection API and have 
> underlying functionality so that at any point in time a new 
> Answer can pushed onto a PeerConnection and that forces the 
> media session to be reestablished if needed. So if the ICE 
> candidate list is different an ICE restart happens. This 
> clearly supports serial forking. It also can create some 
> complexities in the underlying SDP handling logic if one 
> desires to minimize the media impact.
> 
> B3) Local side shared parameters in multiple PeerConnections: 
> The idea in this proposal is that all PeerConnections 
> generated in a browser context, like a tab will implicit 
> share the fundamental parameters like ICE candidates etc for 
> the number of media streams added. So if one creates a second 
> PeerConnection with the same audio+video MediaStream object 
> added I will get an offer that is mostly identical to the the 
> first PeerConnection, thus I can push in the answer from the 
> first PeerConnection Offer into the second PC object and it 
> will still work.
> The downside of this is that it is implicit and it becomes 
> difficult to determine when it works and when it will fail. 
> It will also be highly dependent on the application 
> performing the right process to get it to work. It also 
> causes a sharing of the parameters when not needed or 
> desired, which primarily is an issue from a security point of 
> view, especially with SDES keys (see below). The positive is 
> this likely requires no API changes. This method would also 
> support parallel forking.
> 
> B4) Cloning/Factory for PeerConnection: On the API level 
> there will be explicit support for generating multiple 
> PeerConnections from the same base. This could either be a 
> factory for PeerConnections or some Object constructor that 
> clones an existing PeerConnection but that is a W3C question. 
> By being explicit some of the B3) issues goes away and the 
> applications can choose when this should happen or not. This 
> also support parallel forking as the application can deal 
> with each media session independently. This clearly will have 
> some impact on the API.
> 
> 
> Shared SDES keys: B2 to B4 will result in that SDES keys from 
> the Offering party to be used towards all invited parties. 
> This is security risk as any of the invited parties can spoof 
> the offering side towards any of the other invited parties. 
> This threat can be resolved by having the inviter rekey 
> immediately after having received an answer.
> 
> Sharing ICE candidates: B3 and B4 and also B2 to some degree 
> will share the ICE candidates. That has certain implications. 
> One is the positive in that it minimizes the resource 
> consumption as additional PeerConnections come at very little 
> extra cost, no need for additional ICE gathering candidate 
> phases, and also be very quick as no external communication 
> is required. The downside of this is that the end-points 
> candidates must always be kept alive as long as some 
> PeerConnection instance exist. Because the browser never 
> knows when the application may create an additional PC and 
> expect them to have the same ICE candidates.
> It should also be noted that the answering WebRTC end-point 
> will need to gather candidates for each offer. Otherwise it 
> will become impossible to create multiple PeerConnections 
> between the same end-points if that is desired by the application.
> 
> 
> I know the above doesn't list all of the pro and cons of the 
> different alternatives. So please fill in additional 
> arguments. And if I missed some proposal please add that also 
> if relevant
> 
> As you may have noted I the two questions in the above have 
> kind of floated together. The reason for this is that I think 
> the majority are fine with having SIP support as long as it 
> doesn't have to high cost or complexity associated with it. 
> Thus, the question how becomes very intertwined with forking 
> support yes or no.
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Ravindran Parthasarathi <[email-masked]>
Date: Thu, 3 Nov 2011 12:07:34 +0000

Hi Magnus,

Question #2: If it is supported in which form would it supported in?
             I support for B3 or B4 as it covers both serial & parallel forking.  I'm interested in parallel forking because serial forking support is partial support of forking in terms of SIP (RFC 3261) which may leads to interop issue and also, it is always possible to get 2 18x response with different to-tag and different SDP answers while interworking with SIP (2 dialogs with 2 different offer/answer pair at this stage) and 200 may came any one of the remote (first or second). Also, WebRTC forking infrastructure shall be used for other services as mentioned in http://www.ietf.org/mail-archive/web/rtcweb/current/msg02516.html. 
       
Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Christer Holmberg
>Sent: Thursday, November 03, 2011 5:24 PM
>To: Magnus Westerlund; [email-masked]
>Subject: Re: [rtcweb] State of the Forking discussion
>
>
>Hi Magnus,
>
>
>
>		Solution B2, B3 or B4 - whatever is possible and least
>complex from a PeerConnection perspective :)
>
>
>Regards,
>
>Christer
>
>
>
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 3 Nov 2011 13:27:39 +0100

2011/11/3 Ravindran Parthasarathi <[email-masked]>:
>             I support for B3 or B4 as it covers both serial & parallel forking.

> I'm interested in parallel forking because serial forking support is partial support of forking in terms of SIP (RFC 3261) which may leads to interop issue and also, it is always possible to get 2 18x response with different to-tag and different SDP answers while interworking with SIP (2 dialogs with 2 different offer/answer pair at this stage)

Right. But note however that most of the SIP devices just choose a
single media session and render that to the human (regardless there
could be N sessions due to multiple 18X with different Totag and
SDPs). So I don't consider this a very important limitation as the
very same occurs in 99% of SIP phones.

> and 200 may came any one of the remote (first or second).

Yes, but that is not parallel forking, it's serial forking. For this
last case we don't require WebRTC to support media parallel forking,
but just the hability to *replace* the media information of the remote
peer with a new one (the SDP in 200) by reusing the same local
PeerConnection.

So this is case B2 above, and not B3 or B4.

> Also, WebRTC forking infrastructure shall be used for other services as mentioned in http://www.ietf.org/mail-archive/web/rtcweb/current/msg02516.html.

You already received a reply in that thread. The use cases you
describe there don't require media-forking. Instead they require N
media streams from different PeerConnections in local side. Then we
can discuss about the need (or not) for mixing different streams in
the browser (like a 3-Way-Call in legacy telephony), but that is not
about media forking at all.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 3 Nov 2011 13:03:20 +0000

> very same occurs in 99% of SIP phones.

Yes but what's cool is that browsers are a platform type that could actually render two streams at the same time: per the current requirements, the browser can mix incoming audio streams and display separate videos, and send out the same audio/video to multiple peers - so parallel forking could actually really work well for in WebRTC as compared to SIP.  :)

But anyway as we keep saying, we don't need native forking ability in the browser for WebRTC's sake, since it can all be done with app code - the main benefit to having it is to federate/interop with SIP more easily/sanely.

How hard is it to put in the browsers?  Has W3C given any input on this?

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Nov 2011 14:07:11 +0100

I thought we were asked to answer Magnus's questions - not to argue each others answers :)

Regards,

Christer 

> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 3. marraskuuta 2011 15:03
> To: Iñaki Baz Castillo
> Cc: [email-masked]
> Yes but what's cool is that browsers are a platform type that 
> could actually render two streams at the same time: per the 
> current requirements, the browser can mix incoming audio 
> streams and display separate videos, and send out the same 
> audio/video to multiple peers - so parallel forking could 
> actually really work well for in WebRTC as compared to SIP.  :)
> 
> But anyway as we keep saying, we don't need native forking 
> ability in the browser for WebRTC's sake, since it can all be 
> done with app code - the main benefit to having it is to 
> federate/interop with SIP more easily/sanely.
>

---

From: Randell Jesup <[email-masked]>
Date: Thu, 03 Nov 2011 10:30:38 -0400

> 1. Is forking needed to be supported at all?

Yes.

> 2. If it is supported in which form would it supported in.

B4, but I disagree with the assertion that the driving force should be 
SIP interop (though that's a positive aspect).

I've mentioned before non-SIP uses of WebRTC that require forking, and 
where parallel forking would be preferable (see, 
Wolfgang/Hadriel/Michael - non-SIP-related reasons!) ;-)

1) mesh conference

You send an offer to the server (say to invite my-work-group to chat). 
The server forwards the OFFER to each member of my-work-group.  Each 
member who answers both accepts your offer, and sends their own offer to 
the server to be mirrored to the other members of my-work-group.  Note 
that in this case the app (interacting with the server) is cognizant of 
the mesh conference state, which active offers are from members of the 
mesh, etc.  Without forking this would require many more offers to be 
generated. I think parallel forking would make it faster and easier for 
an application developer to implement architectures like this.

Also (IMPORTANT): would generation of "new" offers require separate user 
consent for security?  How would rtcweb distinguish between that and a 
totally different call to another destination?

2) games

In games (or virtual "3d space" conferences where locality comes into 
play) you might have a "hanging" offer with the server used to connect 
you to another player when the radio you, or come close to you, etc. 
Again the speed and consent issues come into play, plus the ease of use 
for the application writer.

There are more, I'm just recounting some I'd already mentioned.

> the inviter rekey immediately after having received an answer.

I'm on record as seriously disliking SDES, but if it's used that would 
be a way to resolve it before media is allowed to flow.

-- 
Randell Jesup
[email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Nov 2011 15:50:32 -0700

<in my individual contributor role>

Much of this I don't feel too strongly about but there is one thing that I do have a strong opinion on. I don't want to require PRACK for legacy SIP support because it is has many problems. 

Cullen

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 8 Nov 2011 17:25:13 -0800

I support SRTP being "mandatory to implement" but not "mandatory to use".  With respect to mandating a keying mechanism, I would point out the arguments in the following document: http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory It appears that the arguments made in this document also apply to RTCWEB in that many (though not all) of the use cases mentioned there are also to be supported by RTCWEB, potentially leading to disparate keying requirements.   2.  RTP Applications and Deployment Scenarios

   The range of application and deployment scenarios where RTP has been

Perkins & Westerlund       Expires May 3, 2012                  [Page 3]
    used includes, but is not limited to, the following:

   o  Point-to-point voice telephony (fixed and wireless networks)

   o  Point-to-point voice and video conferencing

   o  Centralised group video conferencing with a multipoint conference
      unit (MCU)

   o  Any Source Multicast video conferencing (light-weight sessions;
      Mbone conferencing)

   o  Point-to-point streaming audio and/or video

   o  Source-specific multicast (SSM) streaming to large group (IPTV and
      3GPP Multimedia Broadcast Multicast Service (MBMS) [MBMS])

   o  Replicated unicast streaming to a group

   o  Interconnecting components in music production studios and video
      editing suites

   o  Interconnecting components of distributed simulation systems

   o  Streaming real-time sensor data

   As can be seen, these scenarios vary from point-to-point to very
   large multicast groups, from interactive to non-interactive, and from
   low bandwidth (kilobits per second) to very high bandwidth (multiple
   gigabits per second).  While most of these applications run over UDP
   [RFC0768], some use TCP [RFC0793], [RFC4614] or DCCP [RFC4340] as
   their underlying transport.  Some run on highly reliable optical
   networks, others use low rate unreliable wireless networks.  Some
   applications of RTP operate entirely within a single trust domain,
   others are inter-domain, with untrusted (and potentially unknown)
   users.  The range of scenarios is wide, and growing both in number
   and in heterogeneity.

3.  Implications for RTP Security

   The wide range of application scenarios where RTP is used has led to
   the development of multiple solutions for securing RTP media streams
   and RTCP control messages, considering different requirements.
   Perhaps the most widely applicable of these solutions is the Secure
   RTP (SRTP) framework [RFC3711].  This is an application-level media
   security solution, encrypting the media payload data (but not the RTP
   headers) to provide some degree of confidentiality, and providing   optional source origin authentication.  It was carefully designed to
   be both low overhead, and to support the group communication features
   of RTP, across a range of networks.

   SRTP is not the only media security solution in use, however, and
   alternatives are more appropriate for some scenarios.  For example,
   many client-server streaming media applications can run over a single
   TCP connection, multiplexing media data with control information on
   that connection (RTSP [I-D.ietf-mmusic-rfc2326bis] is a widely used
   example of such a protocol).  One way to provide media security for
   such client-server media applications is to use TLS [RFC5246] to
   protect the TCP connection, sending the RTP media data over the TLS
   connection.  Using the SRTP framework in addition to TLS is
   unnecessary, and would result in double encryption of the media, and
   SRTP cannot be used instead of TLS since it is RTP-specific, and so
   cannot protect the control traffic.

   Other RTP use cases work over networks which provide security at the
   network layer, using IPsec.  For example, certain 3GPP networks need
   IPsec security associations for other purposes, and can reuse those
   to secure the RTP session [TS-33210].  SRTP is, again, unnecessary in
   such environments, and its use would only introduce overhead for no
   gain.

   For some applications it is sufficient to protect the RTP payload
   data while leaving RTP, transport, and network layer headers
   unprotected.  An example of this is RTP broadcast over DVB-H
   [ETSI.TS.102.474], where one mode of operation uses ISMA Cryp 2.0
   [ISMA] to encrypt the RTP payload data only.

   All these are application scenarios where RTP has seen commercial
   deployment.  Other use cases exist, with additional requirements.
   For example, if the media transport is done over UDP [RFC0768], DCCP
   [RFC4340] or SCTP [RFC4960], then using DTLS [RFC4347] to protect the
   whole RTP packets is an option.  There is no media security protocol
   that is appropriate for all these environments.  Accordingly,
   multiple RTP media security protocols can be expected to remain in
   wide use.

4.  Implications for Key Management

   With such a diverse range of use cases come a range of different
   protocols for RTP session establishment.  Mechanisms used to provide
   security keying for these different session establishment protocols
   can basically be put into two categories: inband and out-of-band in
   relation to the session establishment mechanism.  The requirements
   for these solutions are highly varying.  Thus a wide range of
  solutions have been developed in this space:

   o  A common use case for RTP is probably point-to-point voice calls
      or centralised group conferences, negotiated using SIP [RFC3261]
      with the SDP offer/answer model [RFC3264], operating on a trusted
      infrastructure.  In such environments, SDP security descriptions
      [RFC4568], or the MIKEY [RFC3830] protocol using the Key
      Management Extensions for SDP [RFC4567], are appropriate keying
      mechanisms, where the keying messages/material are embedded in the
      SDP [RFC4566] exchange.  The infrastructure may be secured by
      protecting the SDP exchange in SIP using TLS or S/MIME, for
      example [RFC3261].  Protocols such as DTLS-SRTP [RFC5764] or ZRTP
      [RFC6189] are also appropriate in such environments.

   o  Point-to-point RTP sessions may be negotiated using SIP with the
      offer/answer model, but operating over a network with untrusted
      infrastructure.  In such environments, the key management protocol
      can be run on the media path, bypassing the untrusted
      infrastructure.  Protocols such as DTLS-SRTP [RFC5764] or ZRTP
      [RFC6189] are useful here, as are inband mechanism that protect
      the keying material such as MIKEY [RFC3830] using the Key
      Management Extensions for SDP [RFC4567].  It should be noted that
      the end-points for all the above mechanisms must prevent total
      downgrade to no security for the RTP media streams.

   o  For point-to-point client-server streaming of RTP over RTSP, a TLS
      association is appropriate to manage keying material, in much the
      same manner as would be used to secure an HTTP session.  But also
      using SRTP with DTLS-SRTP keying or DTLS are appropriate choices.

   o  A session description may be sent by email, secured using S/MIME
      or PGP, or retrieved from a web page, using HTTP with TLS.

   o  A session description may be distributed to a multicast group
      using SAP or FLUTE secured with S/MIME.

   o  A session description may be distributed using the Open Mobile
      Alliance DRM key management specification [OMA-DRM] when using a
      point-to-point streaming session setup with RTSP in the 3GPP PSS
      environment [PSS].

   o  In the 3GPP Multimedia Broadcast Multicast Service (MBMS) system,
      HTTP and MIKEY are used for key management [MBMS-SEC].

   A more detailed survey of requirements for media security management
   protocols can be found in [RFC5479].  As can be seen, the range of
   use cases is wide, and there is no single protocol that is
   appropriate for all scenarios.  These solutions have been further  diversified by the existence of infrastructure elements such as
   authentication solutions that are tied into the key management.
     Magnus said:  "Yes, we haven't spent much time on the security consideration section
yet. "A mandatory to implement media security solution will be required
to be picked" is pointer at this WG not the implementor.

I would also point at our Charter that in its last paragraph says:
"The products of the working group will support security and keying as
required by BCP 61"

If you haven't read BCP 61 you probably should. It is basically says two
things. IETF should pick strong security and it shall be MANDATORY to
IMPLEMENT. I at least as chair will ensure that we have fulfilled this.
And that means for RTP not only encryption and integrity protection,
probably SRTP, but also a keying method.

Yes, we (authors of draft-ietf-rtcweb-rtp-usage) will write that SRTP is
a MUST implement as soon as we have that consensus established. But we
will need a keying scheme also and determine where it should be documented.

Cheers

Magnus Westerlund
"

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Nov 2011 10:20:31 +0100

Hi, 

> Much of this I don't feel too strongly about but there is one 
> thing that I do have a strong opinion on. I don't want to 
> require PRACK for legacy SIP support because it is has many problems. 

If you are not using PRACK, you will not be able to receive a "real" answer before 200 OK, at a point where forking will be no issue anymore :)

Regards,

Christer

> believe to be 
> > the important points and alternatives in this discussion. 
> Keep in mind 
> > that my assumptions or understanding may be unclear or have 
> errors. So 
> > don't hesitate to challenge what I write.
> > 
> important 
> for these 
> > two questions. And I do hope that you will read to the end of this 
> > mail which is quite long.
> > 
> > Lets start with the high level functionality part. Is 
> forking needed 
> > and what usage does it have. So forking is all about sending out an 
> > offer, i.e. SDP Offer, then get more than a single answer to that 
> > offer back. How you deal with these answers as they come in is the 
> > difference between serial and parallel forking. So lets 
> define those.
> > 
> > Parallel forking: For each answer you receive you establish a new 
> > actual media session. Thus if you receive two answers you 
> will have to 
> > A) No forking is needed: Between WebRTC end-points there is no need 
> > for forking. Instead the application can send out session 
> invitations 
> > to the peers it wants to talk to. These are without any SDP Offer 
> > equivalent, instead end-points that want to communicate they create 
> > PeerConnections, which results in SDP Offers. Thus the 
> communication 
> > initiating end-point becomes the ones that provides SDP answers and 
> > get one PeerConnection per remote end-point that actually 
> want to communicate.
> > 
> fundamental here 
> > is that it needs to be reasonable to interwork with SIP, 
> independent 
> > if one uses a SIP in JS in the application running on the WebRTC 
> > enabled browser, or have signalling gateway in the 
> webserver, or as a 
> > remote WebRTC peer. The issue is that A)'s method of 
> initiating call 
> Invite with 
> > an SDP Offer and that can result in multiple answers.
> > 
> > B1) Use Iñaki's proposal which forces the WebRTC 
> application to create 
> > a second PeerConnection and then forces an update in the SIP domain 
> > with the second peer-connections Offer. However, it was pointed out 
> > that this doesn't work with SIP Provisional answers, as used by ICE 
> > for example, unless PRACK is supported. The level of PRACK 
> support is 
> > reasonable but far from universal so this would limit the 
> SIP UAs one 
> > can interwork with. However, from WebRTC perspective no forking 
> here is that 
> > one changes the PeerConnection API and have underlying 
> functionality 
> > so that at any point in time a new Answer can pushed onto a 
> > PeerConnection and that forces the media session to be 
> reestablished 
> > if needed. So if the ICE candidate list is different an ICE restart 
> > happens. This clearly supports serial forking. It also can 
> create some 
> > context, like a tab will implicit share the fundamental parameters 
> > like ICE candidates etc for the number of media streams 
> added. So if 
> > one creates a second PeerConnection with the same audio+video 
> > MediaStream object added I will get an offer that is mostly 
> identical 
> > to the the first PeerConnection, thus I can push in the answer from 
> > the first PeerConnection Offer into the second PC object 
> and it will still work.
> difficult 
> > to determine when it works and when it will fail. It will also be 
> > highly dependent on the application performing the right process to 
> > get it to work. It also causes a sharing of the parameters when not 
> > needed or desired, which primarily is an issue from a 
> security point 
> > of view, especially with SDES keys (see below). The 
> positive is this 
> > likely requires no API changes. This method would also 
> there will be 
> > base. This could either be a factory for PeerConnections or some 
> > Object constructor that clones an existing PeerConnection 
> but that is 
> > a W3C question. By being explicit some of the B3) issues 
> goes away and 
> > the applications can choose when this should happen or not. 
> This also 
> > Offering party to be used towards all invited parties. This is 
> > security risk as any of the invited parties can spoof the offering 
> > side towards any of the other invited parties. This threat can be 
> > resolved by having the inviter rekey immediately after 
> having received an answer.
> > 
> > Sharing ICE candidates: B3 and B4 and also B2 to some degree will 
> > share the ICE candidates. That has certain implications. One is the 
> > positive in that it minimizes the resource consumption as 
> additional 
> > instance exist. Because the browser never knows when the 
> application 
> > may create an additional PC and expect them to have the 
> same ICE candidates.
> will need 
> > to gather candidates for each offer. Otherwise it will become 
> > impossible to create multiple PeerConnections between the same 
> > end-points if that is desired by the application.
> > 
> > 
> > fine with having SIP support as long as it doesn't have to 
> high cost 
> > or complexity associated with it. Thus, the question how 
> becomes very

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Nov 2011 07:40:59 -0700

> If you are not using PRACK, you will not be able to receive a "real" answer before 200 OK, at a point where forking will be no issue anymore :)

I think it is a little more subtle than this. The UAC are not guarantee delivery of the 180s without prack but the UAC typically gets them anyways. Note I am fine with things that do support PRACK, I  just don't want  to require it. I also have had good luck with the systems that send the 180 more than once.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Nov 2011 20:15:43 +0100

Hi,

> I think it is a little more subtle than this. The UAC are not guarantee delivery of the 180s without prack but the UAC typically gets them 
> anyways. Note I am fine with things that do support PRACK, I  just don't want  to require it. I also have had good luck with the systems 
> that send the 180 more than once.

I agree. Many systems use SDPs received in unreliable 180s, as if they would have been received in a reliable 180. 

Of course, a UAC can't send a *new* offer before it has received the SDP reliably, so a forking solution that is based on sending a new offer (read: a solution that requires PRACK) would not work.

Regards,

Christer

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 10 Nov 2011 11:01:38 +0100

Hi,

Regarding the srtp-not-mandatory draft. In the discussion I have so far 
had with for example the security ADs one conclusion is that when we get 
into something that is actually an application or class of applications 
and when that is specified by IETF, IETF do need to pick at least one 
mandatory to implement solution.

As WebRTC is an application using RTP this becomes very applicable to 
the WebRTC work. We do need to pick at least one mandatory to implement 
keying mechanism. We might pick additional mandatory ones if we think 
that is necessary to address the space of usages we see. I think that is 
what the WG must come to consensus on.

Cheers

Magnus

On 2011-11-09 02:25, Bernard Aboba wrote:
> I support SRTP being "mandatory to implement" but not "mandatory to use".
>
> With respect to mandating a keying mechanism, I would point out the
> arguments in the following document:
>
> http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory
>
> It appears that the arguments made in this document also apply to RTCWEB
> in that many (though not all) of the use cases mentioned there are also
> to be supported by RTCWEB, potentially leading to disparate keying
> requirements.
>
>
>     2. RTP Applications and Deployment Scenarios
>
>        3GPP Multimedia Broadcast Multicast Service (MBMS) [MBMS  <http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08#ref-MBMS>])
>
>     [RFC0768  <http://tools.ietf.org/html/rfc0768>], some use TCP [RFC0793  <http://tools.ietf.org/html/rfc0793>], [RFC4614  <http://tools.ietf.org/html/rfc4614>] or DCCP [RFC4340  <http://tools.ietf.org/html/rfc4340>] as
>     RTP (SRTP) framework [RFC3711  <http://tools.ietf.org/html/rfc3711>].  This is an application-level media
>     headers) to provide some degree of confidentiality, and providing
>
>     optional source origin authentication.  It was carefully designed to
>     that connection (RTSP [I-D.ietf-mmusic-rfc2326bis  <http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08#ref-I-D.ietf-mmusic-rfc2326bis>] is a widely used
>     such client-server media applications is to use TLS [RFC5246  <http://tools.ietf.org/html/rfc5246>] to
>     to secure the RTP session [TS-33210  <http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08#ref-TS-33210>].  SRTP is, again, unnecessary in
>     [ETSI.TS.102.474  <http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08#ref-ETSI.TS.102.474>], where one mode of operation uses ISMA Cryp 2.0
>     [ISMA  <http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08#ref-ISMA>] to encrypt the RTP payload data only.
>
>     For example, if the media transport is done over UDP [RFC0768  <http://tools.ietf.org/html/rfc0768>], DCCP
>     [RFC4340  <http://tools.ietf.org/html/rfc4340>] or SCTP [RFC4960  <http://tools.ietf.org/html/rfc4960>], then using DTLS [RFC4347  <http://tools.ietf.org/html/rfc4347>] to protect the
>        or centralised group conferences, negotiated using SIP [RFC3261  <http://tools.ietf.org/html/rfc3261>]
>        with the SDP offer/answer model [RFC3264  <http://tools.ietf.org/html/rfc3264>], operating on a trusted
>        [RFC4568  <http://tools.ietf.org/html/rfc4568>], or the MIKEY [RFC3830  <http://tools.ietf.org/html/rfc3830>] protocol using the Key
>        Management Extensions for SDP [RFC4567  <http://tools.ietf.org/html/rfc4567>], are appropriate keying
>        SDP [RFC4566  <http://tools.ietf.org/html/rfc4566>] exchange.  The infrastructure may be secured by
>        example [RFC3261  <http://tools.ietf.org/html/rfc3261>].  Protocols such as DTLS-SRTP [RFC5764  <http://tools.ietf.org/html/rfc5764>] or ZRTP
>        [RFC6189  <http://tools.ietf.org/html/rfc6189>] are also appropriate in such environments.
>
>        infrastructure.  Protocols such as DTLS-SRTP [RFC5764  <http://tools.ietf.org/html/rfc5764>] or ZRTP
>        [RFC6189  <http://tools.ietf.org/html/rfc6189>] are useful here, as are inband mechanism that protect
>        the keying material such as MIKEY [RFC3830  <http://tools.ietf.org/html/rfc3830>] using the Key
>        Management Extensions for SDP [RFC4567  <http://tools.ietf.org/html/rfc4567>].  It should be noted that
>        Alliance DRM key management specification [OMA-DRM  <http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08#ref-OMA-DRM>] when using a
>        environment [PSS  <http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08#ref-PSS>].
>
>        HTTP and MIKEY are used for key management [MBMS-SEC  <http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08#ref-MBMS-SEC>].
>
>     protocols can be found in [RFC5479  <http://tools.ietf.org/html/rfc5479>].  As can be seen, the range of
>     appropriate for all scenarios.  These solutions have been further
>
>    diversified by the existence of infrastructure elements such as
> Magnus said:
> "Yes, we haven't spent much time on the security consideration section

-- 

Magnus Westerlund

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 11 Nov 2011 21:19:13 -0800

The problem is that WebRTC is not actually a single use case or "application" -- 
it is a framework that could be used to implement applications, including 
many of the unicast use cases described in the srtp-not-mandatory draft. 

As the srtp-not-mandatory draft points out, it is hard for one keying scheme to 
handle a wide range of scenarios.  Even if we exclude the multicast cases, 
there is enough diversity in the unicast scenarios described in the use case 
document (e.g. point-to-point and conferencing) for the logic to still hold up. 

> Date: Thu, 10 Nov 2011 11:01:38 +0100
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]
> Subject: Re: [rtcweb] SRTP mandatory to implement versus mandatory to use
> 
> Hi,
>