Subject: [rtcweb] STUN for keep-alive

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Sep 2011 11:48:43 +0200

Hi,

Assuming we would use ICE for media authorization, it has been indicated that, for legacy interoperability, a gateway would be required in many cases (as the legacy entities might not support ICE).

ICE "bundles" functions together, meaning that if you use STUN for media authorization purpose (which is a part of the connectivity check purpose), you will also use STUN for keep-alive purpose (for UDP based media).

My question is: would we be able to relax the requirement to use STUN for keep-alive? Because, eventhough the keep-alives messages aren't authenticated, and do not trigger responses, a gateway would still have to process them, and since a gateway typically would serve a large number of browser clients, that could have quite big performance impact (the number of STUN keep-alives sent per session of course depend on how much other media traffic there is, but still).

So, for RTP based media, one could use RTP, and for UDP based data channels "dummy" UDP packets (unless there is a protocol on top of UDP which provides a keep-alive mechanism itself).

Regards,

Christer

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 14 Sep 2011 15:55:13 +0530

Christer,

|Because, eventhough the keep-alives messages aren't authenticated, 
|and do not trigger responses, a gateway would still have to process 
|them, and since a gateway typically would serve a large number of 
|browser clients, that could have quite big performance impact 
|(the number of STUN keep-alives sent per session of course depend 
|on how much other media traffic there is, but still).

STUN keepalives are required by ICE only in the absence of media
traffic. Here are the snip from RFC 5245:

<snip>
10.  Keepalives

If there has been no packet sent on the candidate pair ICE is using
for a media component for Tr seconds (where packets include those
defined for the component (RTP or RTCP) and previous keepalives), an
agent MUST generate a keepalive on that pair.  Tr SHOULD be
configurable and SHOULD have a default of 15 seconds.  Tr MUST NOT be
configured to less than 15 seconds.
</snip>

<snip>
20.2.3.  Keepalives

STUN keepalives (in the form of STUN Binding Indications) are sent in
the middle of a media session.  However, they are sent only in the
absence of actual media traffic. In deployments that are not
utilizing Voice Activity Detection (VAD), the keepalives are never
used and there is no increase in bandwidth usage.  When VAD is being
used, keepalives will be sent during silence periods.  This involves
a single packet every 15-20 seconds, far less than the packet every
20-30 ms that is sent when there is voice.  Therefore, keepalives
don't have any real impact on capacity planning.
</snip>

Do you think there is still a problem?

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Christer Holmberg
|Sent: Wednesday, September 14, 2011 3:19 PM
|To: [email-masked]
|Subject: [rtcweb] STUN for keep-alive
|
|
|Hi,
|
|Assuming we would use ICE for media authorization, it has been
indicated that, for legacy
|interoperability, a gateway would be required in many cases (as the
legacy entities might not support
|ICE).
|
|ICE "bundles" functions together, meaning that if you use STUN for
media authorization purpose (which
|is a part of the connectivity check purpose), you will also use STUN
for keep-alive purpose (for UDP
|based media).
|
|My question is: would we be able to relax the requirement to use STUN
for keep-alive? Because,
|eventhough the keep-alives messages aren't authenticated, and do not
trigger responses, a gateway
|would still have to process them, and since a gateway typically would
serve a large number of browser
|clients, that could have quite big performance impact (the number of
STUN keep-alives sent per session
|of course depend on how much other media traffic there is, but still).
|
|So, for RTP based media, one could use RTP, and for UDP based data
channels "dummy" UDP packets
|(unless there is a protocol on top of UDP which provides a keep-alive
mechanism itself).
|
|Regards,
|
|Christer
|
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Sep 2011 12:29:17 +0200

Hi, 

>|Because, eventhough the keep-alives messages aren't authenticated, and 
>|do not trigger responses, a gateway would still have to 
>|process them, and since a gateway typically would serve a large number of browser 
>|STUN keep-alives sent per session of course depend on how much other 
>|media traffic there is, but still).
> 
>STUN keepalives are required by ICE only in the absence of 
>media traffic.

Yes. That's what I meant with the:

	"(the number of STUN keep-alives sent per session of course depend on how much other media traffic there is, but still)"

...statement :)

>Here are the snip from RFC 5245:
> 
><snip>
>10.  Keepalives
> 
>If there has been no packet sent on the candidate pair ICE is 
>using for a media component for Tr seconds (where packets 
>include those defined for the component (RTP or RTCP) and 
>previous keepalives), an agent MUST generate a keepalive on 
>that pair.  Tr SHOULD be configurable and SHOULD have a 
>default of 15 seconds.  Tr MUST NOT be configured to less 
>than 15 seconds.
></snip>
> 
><snip>
>20.2.3.  Keepalives
> 
>STUN keepalives (in the form of STUN Binding Indications) are 
>sent in the middle of a media session.  However, they are 
>sent only in the absence of actual media traffic. In 
>deployments that are not utilizing Voice Activity Detection 
>(VAD), the keepalives are never used and there is no increase 
>in bandwidth usage.  When VAD is being used, keepalives will 
>be sent during silence periods.  This involves a single 
>packet every 15-20 seconds, far less than the packet every 
>20-30 ms that is sent when there is voice.  Therefore, 
>keepalives don't have any real impact on capacity planning.
></snip>
> 

Well, it depends on the amount of outgoing media traffic, but in cases where you only receive media you would still need to send keep-alives.

Regards,

Christer

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 14 Sep 2011 16:53:52 +0530

|Well, it depends on the amount of outgoing media traffic, 
|but in cases where you only receive media you would still 
|need to send keep-alives.

If you are not sending anything the NAT binding in that direction will
likely timeout. On the other hand, if you are operating in a controlled
environment ICE already allows you to set the STUN keepalive duration to
the longest duration possible in your environment, so it is already
flexible.

However, it mandates STUN keepalives to be used when an agent is a full
ICE implementation and is communicating with a peer that supports ICE
(lite/full). Are you saying it should allow a different UDP keepalive
method because it can possible have a lesser performance impact?

Muthu

|-----Original Message-----
|From: Christer Holmberg [mailto:[email-masked]]
|Sent: Wednesday, September 14, 2011 3:59 PM
|To: Muthu Arul Mozhi Perumal (mperumal); [email-masked]
|Subject: RE: [rtcweb] STUN for keep-alive
|
|
|Hi,
|
|>|Because, eventhough the keep-alives messages aren't authenticated,
and
|>|do not trigger responses, a gateway would still have to
|>|process them, and since a gateway typically would serve a large
number of browser
|>|clients, that could have quite big performance impact (the number of
|>|STUN keep-alives sent per session of course depend on how much other
|>|media traffic there is, but still).
|>
|>STUN keepalives are required by ICE only in the absence of
|>media traffic.
|
|Yes. That's what I meant with the:
|
|	"(the number of STUN keep-alives sent per session of course
depend on how much other media
|traffic there is, but still)"
|
|...statement :)
|
|>Here are the snip from RFC 5245:
|>
|><snip>
|>10.  Keepalives
|>
|>If there has been no packet sent on the candidate pair ICE is
|>using for a media component for Tr seconds (where packets
|>include those defined for the component (RTP or RTCP) and
|>previous keepalives), an agent MUST generate a keepalive on
|>that pair.  Tr SHOULD be configurable and SHOULD have a
|>default of 15 seconds.  Tr MUST NOT be configured to less
|>than 15 seconds.
|></snip>
|>
|><snip>
|>20.2.3.  Keepalives
|>
|>STUN keepalives (in the form of STUN Binding Indications) are
|>sent in the middle of a media session.  However, they are
|>sent only in the absence of actual media traffic. In
|>deployments that are not utilizing Voice Activity Detection
|>(VAD), the keepalives are never used and there is no increase
|>in bandwidth usage.  When VAD is being used, keepalives will
|>be sent during silence periods.  This involves a single
|>packet every 15-20 seconds, far less than the packet every
|>20-30 ms that is sent when there is voice.  Therefore,
|>keepalives don't have any real impact on capacity planning.
|></snip>
|>
|>Do you think there is still a problem?
|
|Well, it depends on the amount of outgoing media traffic, but in cases
where you only receive media
|you would still need to send keep-alives.
|
|Regards,
|
|Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Sep 2011 13:30:44 +0200

Hi, 

>>|where you only receive media you would still need to send keep-alives.
> 
> If you are not sending anything the NAT binding in that 
> direction will likely timeout. On the other hand, if you are 
> operating in a controlled environment ICE already allows you 
> to set the STUN keepalive duration to the longest duration 
> possible in your environment, so it is already flexible.

Sure, but there is still a max time between the keep-alives.

>However, it mandates STUN keepalives to be used when an agent 
>is a full ICE implementation and is communicating with a peer 
>that supports ICE (lite/full). Are you saying it should allow 
>a different UDP keepalive method because it can possible have 
>a lesser performance impact?

Yes.

Also, it's not only about how often the STUN keep-alives would be sent, and the perfomance impact that would have. Using e.g. RTP, the media handler would not have to be prepared to receive the STUN keep-alives in the first place, it could simply just relay whatever comes on the media plane.

Regards,

Christer

> process them, 
> |>|and since a gateway typically would serve a large
> number of browser
> |>STUN keepalives are required by ICE only in the absence of media 
> |>traffic.
> |
> |>If there has been no packet sent on the candidate pair ICE is using 
> |>for a media component for Tr seconds (where packets include those 
> |>defined for the component (RTP or RTCP) and previous 
> keepalives), an 
> |>agent MUST generate a keepalive on that pair.  Tr SHOULD be 
> |>configurable and SHOULD have a default of 15 seconds.  Tr 
> MUST NOT be 
> |>configured to less than 15 seconds.
> |></snip>
> |>
> |><snip>
> |>20.2.3.  Keepalives
> |>
> |>STUN keepalives (in the form of STUN Binding Indications) 
> are sent in 
> |>the middle of a media session.  However, they are sent only in the 
> |>absence of actual media traffic. In deployments that are 
> not utilizing 
> |>Voice Activity Detection (VAD), the keepalives are never used and 
> |>there is no increase in bandwidth usage.  When VAD is being used, 
> |>keepalives will be sent during silence periods.  This involves a 
> |>single packet every 15-20 seconds, far less than the packet every 
> |>20-30 ms that is sent when there is voice.  Therefore, keepalives 
> |>don't have any real impact on capacity planning.
> |></snip>
> |>
> but in cases

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 14 Sep 2011 17:38:45 +0530

|Sure, but there is still a max time between the keep-alives.

You are free to set it to a very long duration that disables keepalives
for all practical purposes (assuming such duration is represented by a
32-bit unsigned integer you can set it to ~136 years).

|Using e.g. RTP, the media handler would not have to be 
|prepared to receive the STUN keep-alives in the first place, 
|it could simply just relay whatever comes on the media plane.

If the media handles can handle STUN binding requests efficiently I
don't see why they can't handle STUN binding indications (keepalives) in
a similar manner. On the other hand, if the media handles aren't STUN
aware and are just relaying STUN binding requests in the media plane as
UDP/RTP, they would do the same also for STUN keepalives.

Muthu

|-----Original Message-----
|From: Christer Holmberg [mailto:[email-masked]]
|Sent: Wednesday, September 14, 2011 5:01 PM
|To: Muthu Arul Mozhi Perumal (mperumal); [email-masked]
|Subject: RE: [rtcweb] STUN for keep-alive
|
|
|Hi,
|
|>>|Well, it depends on the amount of outgoing media traffic, but in
cases
|>>|where you only receive media you would still need to send
keep-alives.
|>
|> If you are not sending anything the NAT binding in that
|> direction will likely timeout. On the other hand, if you are
|> operating in a controlled environment ICE already allows you
|> to set the STUN keepalive duration to the longest duration
|> possible in your environment, so it is already flexible.
|
|Sure, but there is still a max time between the keep-alives.
|
|>However, it mandates STUN keepalives to be used when an agent
|>is a full ICE implementation and is communicating with a peer
|>that supports ICE (lite/full). Are you saying it should allow
|>a different UDP keepalive method because it can possible have
|>a lesser performance impact?
|
|Yes.
|
|Also, it's not only about how often the STUN keep-alives would be sent,
and the perfomance impact that
|would have. Using e.g. RTP, the media handler would not have to be
prepared to receive the STUN keep-
|alives in the first place, it could simply just relay whatever comes on
the media plane.
|
|Regards,
|
|Christer
|
|
|
|
|> |-----Original Message-----
|> |From: Christer Holmberg [mailto:[email-masked]]
|> |Sent: Wednesday, September 14, 2011 3:59 PM
|> |To: Muthu Arul Mozhi Perumal (mperumal); [email-masked]
|> |Subject: RE: [rtcweb] STUN for keep-alive
|> |
|> |
|> |Hi,
|> |
|> |>|Because, eventhough the keep-alives messages aren't authenticated,
|> and
|> |>|do not trigger responses, a gateway would still have to
|> process them,
|> |>|and since a gateway typically would serve a large
|> number of browser
|> |>|clients, that could have quite big performance impact (the
|> number of
|> |>|STUN keep-alives sent per session of course depend on how
|> much other
|> |>|media traffic there is, but still).
|> |>
|> |>STUN keepalives are required by ICE only in the absence of media
|> |>traffic.
|> |
|> |Yes. That's what I meant with the:
|> |
|> |	"(the number of STUN keep-alives sent per session of course
|> depend on how much other media
|> |traffic there is, but still)"
|> |
|> |...statement :)
|> |
|> |>Here are the snip from RFC 5245:
|> |>
|> |><snip>
|> |>10.  Keepalives
|> |>
|> |>If there has been no packet sent on the candidate pair ICE is using
|> |>for a media component for Tr seconds (where packets include those
|> |>defined for the component (RTP or RTCP) and previous
|> keepalives), an
|> |>agent MUST generate a keepalive on that pair.  Tr SHOULD be
|> |>configurable and SHOULD have a default of 15 seconds.  Tr
|> MUST NOT be
|> |>configured to less than 15 seconds.
|> |></snip>
|> |>
|> |><snip>
|> |>20.2.3.  Keepalives
|> |>
|> |>STUN keepalives (in the form of STUN Binding Indications)
|> are sent in
|> |>the middle of a media session.  However, they are sent only in the
|> |>absence of actual media traffic. In deployments that are
|> not utilizing
|> |>Voice Activity Detection (VAD), the keepalives are never used and
|> |>there is no increase in bandwidth usage.  When VAD is being used,
|> |>keepalives will be sent during silence periods.  This involves a
|> |>single packet every 15-20 seconds, far less than the packet every
|> |>20-30 ms that is sent when there is voice.  Therefore, keepalives
|> |>don't have any real impact on capacity planning.
|> |></snip>
|> |>
|> |>Do you think there is still a problem?
|> |
|> |Well, it depends on the amount of outgoing media traffic,
|> but in cases
|> where you only receive media
|> |you would still need to send keep-alives.
|> |
|> |Regards,
|> |
|> |Christer
|>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Sep 2011 15:07:40 +0200

Hi, 

>You are free to set it to a very long duration that disables 
>keepalives for all practical purposes (assuming such duration 
>is represented by a 32-bit unsigned integer you can set it to 
>~136 years).

Yes, but at the end of the day something has to be sent in order to keep the NAT binding open.

>>|Using e.g. RTP, the media handler would not have to be prepared to 
>>|receive the STUN keep-alives in the first place, it could 
>>|simply just 
>>|relay whatever comes on the media plane.
> 
> If the media handles can handle STUN binding requests 
> efficiently I don't see why they can't handle STUN binding 
> indications (keepalives) in a similar manner.

I believe it knows when to expect those. But, in any case, the main reason behind the proposal is to decrease the number of STUN requests.

> On the other hand, if the media handles aren't STUN aware and are just 
> relaying STUN binding requests in the media plane as UDP/RTP, 
> they would do the same also for STUN keepalives.

Sure, I was talking about the case where the gateway terminates ICE and STUN.

Regards,

Christer

> |> If you are not sending anything the NAT binding in that direction 
> |> will likely timeout. On the other hand, if you are operating in a 
> |> controlled environment ICE already allows you to set the STUN 
> |> keepalive duration to the longest duration possible in your 
> |> environment, so it is already flexible.
> |
> |>However, it mandates STUN keepalives to be used when an agent is a 
> |>full ICE implementation and is communicating with a peer 
> that supports 
> |>ICE (lite/full). Are you saying it should allow a different UDP 
> |>keepalive method because it can possible have a lesser performance 
> |>impact?
> |
> |Yes.
> |

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 14 Sep 2011 10:45:47 -0400

> Well, it depends on the amount of outgoing media traffic, but in cases where you only receive media you would still need to send keep-alives.

Remember, RTCWeb is (probably) mandating RTP/RTCP mux.  I'd need to do some math to be certain, but I'm pretty sure that in almost all normal circumstances, the RTCP regular reporting interval should be significantly smaller than the STUN keepalive interval.

---

From: Randell Jesup <[email-masked]>
Date: Wed, 14 Sep 2011 08:04:26 -0700

> Remember, RTCWeb is (probably) mandating RTP/RTCP mux.  I'd need to do some math to be certain, but I'm pretty sure that in almost all normal circumstances, the RTCP regular reporting interval shou…

Agreed; I think it would require a bizarre session setup (RR=0) to force 
the RTCP interval out far enough to cause problems.  (Don't forget to 
include the +- 50% in the calculation.)

RFC 3556:

       o  If RR is zero, then the proportion of participants that are
          senders can never be greater than RS/(RS+RR), and therefore
          non-senders never get any RTCP bandwidth independent of the
          number of senders.

Obviously, RR values near 0 could also cause a problem.  A statement 
about not using RR values that would result in RTCP intervals greater 
than N should be enough I think.

BTW: Have we mandated that RTP & RTCP be muxed always to all 
destinations, or that it must be supported and offered?  If you're 
talking to a legacy device that doesn't mux, what happens?

-- 
Randell Jesup
[email-masked]

---

From: sisalem <[email-masked]>
Date: Wed, 14 Sep 2011 17:11:17 +0200

as far as I remember this was more thought for multicast sessions. for 
unicast the interval was 5 seconds (+-50%)

cheers

On 9/14/11 5:04 PM, Randell Jesup wrote:
>>> Well, it depends on the amount of outgoing media traffic, but in 
>>> cases where you only receive media you would still need to send 
>>> keep-alives.
>> Remember, RTCWeb is (probably) mandating RTP/RTCP mux.  I'd need to 
>> do some math to be certain, but I'm pretty sure that in almost all 
>> normal circumstances, the RTCP regular reporting interval should be 
>> significantly smaller than the STUN keepalive interval.
>
> Agreed; I think it would require a bizarre session setup (RR=0) to 
> force the RTCP interval out far enough to cause problems.  (Don't 
> forget to include the +- 50% in the calculation.)
>
> RFC 3556:
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 14 Sep 2011 17:21:34 +0200

> significantly smaller than the STUN keepalive interval.

You don't need to do the math, I have already done it and it got
included into RFC 6263 and quoted below.

But, my personal view is that for all reasonable configurations of RTCP
you are in fact transmitting RTCP in each direction more often than the
ICE default of 15 seconds.

---- Quote Start Here ----

8.  RTCP Flow Keepalive

   RTCP packets are sent periodically and can thus normally keep the NAT
   mappings open as long as they are sent frequently enough.  There are
   two conditions for that.  First, RTCP needs to be used
   bidirectionally and in a symmetric fashion, as described in
   [RFC4961].  Secondly, RTCP needs to be sent frequently enough.
   However, there are certain configurations that can break this latter
   assumption.

   There are two factors that need to be considered to ensure that RTCP
   is sent frequently enough.  First, the RTCP bandwidth needs to be
   sufficiently large so that transmission will occur more frequently
   than the longest acceptable packet transmission interval (Tr).  The
   worst-case RTCP interval (Twc) can be calculated using this formula
   by inserting the max value of the following parameters:

   o  Maximum RTCP packet size (avg_rtcp_size_max)

   o  Maximum number of participants (members_max)

   o  RTCP receiver bandwidth (rtcp_bw)

   The RTCP bandwidth value to use here is for a worst case, which will
   be the receiver proportion when all members except one are not
   senders.  This can be approximated to be all members.  Thus, for
   sessions where RR and RS values [RFC3556] are used, then rtcp_bw
   shall be set to RR.  For sessions where the [RFC3550]-defined
   proportions of RTCP bandwidth are used (i.e., 1/4 of the bandwidth
   for senders and 3/4 of the bandwidth for receivers), then rtcp_bw
   will be 5% of 3/4 of the AS value [RFC4566] in bits per second.

   Twc = 1.5 / 1.21828 * members_max * rtcp_bw / avg_rtcp_size_max * 8

   The second factor is the minimum RTCP interval Tmin defined in
   [RFC3550].  Its base value is 5 seconds, but it might also be scaled
   to 360 divided by the session bandwidth in kbps.  The Extended RTP
   Profile for Real-time Transport Control Protocol (RTCP)-Based
   Feedback (RTP/AVPF) [RFC4585] also allows for the setting of a
   trr-int parameter, which is a minimal RTCP interval for regular RTCP
   packets.  It is also used as the Tmin value in the regular Td
   calculation.  An analysis of the algorithm shows that the longest
   possible regular RTCP interval is:

   RTCP_int_max = trr-int * 1.5 + Td * 1.5 / 1.21828

   And as long as there is sufficient bandwidth according to criteria 1
   below, then the algorithm can be simplified by setting Td = trr-int,
   giving

   RTCP_int_max = trr-int * (1.5 + 1.5 / 1.21828) = 2.73123 * trr-int

   Thus, the requirements for the RTCP parameters are as follows for
   functioning keepalive:

   1.  Ensure that sufficient RTCP bandwidth is provided by calculating
       Twc, and ensure that the resulting value is less than or equal
       to Tr.

   2.  If AVP or SAVP [RFC3711] is used, the Tmin value can't be greater
       than Tr divided by 1.5 / (e-3/2).

   3.  If AVPF or SAVPF [RFC5124] is to be used, trr-min must not be set
       to a value greater than Tr / 3.

----- End of Quote ----

-- 

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: Harald Alvestrand <[email-masked]>
Date: Wed, 14 Sep 2011 18:14:30 +0200

> I believe it knows when to expect those. But, in any case, the main reason behind the proposal is to decrease the number of STUN requests.
I think it's a more urgent desire that we should minimize the number of 
variants of protocols in use.
Defining a variant of ICE that modifies the keepalive mechanism seems to 
me like a Bad Idea.

                      Harald

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 14 Sep 2011 10:13:19 -0700

One new concern in this context is maintaining the consent freshness.
The browser
needs to be sure that the recipient of traffic is stil responding in a
way that can't be
forged. It's likely RTCP provides this (though we'd need to analyze to
be sure) but
perhaps better would be to mandate STUN checks at enough frequency that
you get some sort of level of freshness.... maybe every 2 minutes or something.

-Ekr

On Wed, Sep 14, 2011 at 9:14 AM, Harald Alvestrand <[email-masked]> wrote:
>> I believe it knows when to expect those. But, in any case, the main reason
>> behind the proposal is to decrease the number of STUN requests.
>
> Defining a variant of ICE that modifies the keepalive mechanism seems to me
> like a Bad Idea.
>
>                     Harald
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Sep 2011 19:20:33 +0200

Hi, 

>The browser needs to be sure that the recipient of traffic is stil responding in a way that can't be forged. It's likely RTCP provides this (though we'd need to analyze to be sure) but perhaps better would be to mandate STUN checks 
>at enough frequency that you get some sort of level of freshness.... maybe every 2 minutes or something.

Please note that the STUN keep-alives are implemented using STUN indication messages, so there are no replies (nor does the receiver perform an authentication check).

Regards,

Christer

On Wed, Sep 14, 2011 at 9:14 AM, Harald Alvestrand <[email-masked]> wrote:
>>> keepalives for all practical purposes (assuming such duration is 
>>> represented by a 32-bit unsigned integer you can set it to
>>> ~136 years).
>>
>>>> |receive the STUN keep-alives in the first place, it could simply 
>>>> |just relay whatever comes on the media plane.
>>>
>>> don't see why they can't handle STUN binding indications 
>>> (keepalives) in a similar manner.
>>
>> I believe it knows when to expect those. But, in any case, the main 
>> reason behind the proposal is to decrease the number of STUN requests.
>
> I think it's a more urgent desire that we should minimize the number 
> of variants of protocols in use.
> Defining a variant of ICE that modifies the keepalive mechanism seems 
> to me like a Bad Idea.
>
>                     Harald
>

---

From: Göran Eriksson AP <[email-masked]>
Date: Wed, 14 Sep 2011 19:22:04 +0200

Can we assume that all PeerConnections will include an audio/video stream-
some may have only a 'data' connection between the
browsers- can't rely on RTCP can we (assuming we don't use RTCP for
generic data)?

Göran

On 2011-09-14 19:13, "Eric Rescorla" <[email-masked]> wrote:

>>> Yes, but at the end of the day something has to be sent in order to
>>>keep
>>> the NAT binding open.
>>>
>>>reason
>>to me

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 14 Sep 2011 10:32:02 -0700

> Please note that the STUN keep-alives are implemented using STUN indication messages, so there are no replies (nor does the receiver perform an authentication check).

Oh... I had forgotten that.... that's not good.

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 16 Sep 2011 11:04:59 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Muthu Arul Mozhi Perumal (mperumal)
> Sent: Wednesday, September 14, 2011 4:24 AM
> To: Christer Holmberg; [email-masked]
> Subject: Re: [rtcweb] STUN for keep-alive
> 

PCP can allow the client to know and control the NAT's UDP timeout,
http://tools.ietf.org/html/draft-ietf-pcp-base-13#section-7.3.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 16 Sep 2011 11:07:56 -0700

> Behalf Of Eric Rescorla
> Sent: Wednesday, September 14, 2011 10:32 AM
> To: Christer Holmberg
> Cc: [email-masked]
> >>The browser needs to be sure that the recipient of traffic is stil
> responding in a way that can't be forged. It's likely RTCP provides
> this (though we'd need to analyze to be sure) but perhaps better would
> be to mandate STUN checks
> > Please note that the STUN keep-alives are implemented using STUN
> indication messages, so there are no replies (nor does the receiver
> perform an authentication check).
> 
> 

The RTCP receiver reports should be adequate for 'consent freshness', no?
If I still like receiving the traffic, I'll report that I'm receiving it.
If I have crashed or disconnected or am not listening on that port, I won't.

-d

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 16 Sep 2011 11:17:42 -0700

> http://tools.ietf.org/html/draft-ietf-pcp-base-13#section-7.3.

NAT64 doesn't have to worry about UDP content or timeouts like in IPv4 
when set up correctly, yet we can' expect everybody to use such 
configuration we consider correct. +1 for OAuth MAC for this reason.

-- 

---
<i>The wheel.</i metro-link=t dzonatasolyndra>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 Sep 2011 11:30:46 -0700

> If I have crashed or disconnected or am not listening on that port, I won't.

I believe so, though I'd have to make sure there's enough entropy. And of course
some implementations may not do RTCP...

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 16 Sep 2011 12:34:26 -0700

> Behalf Of Dzonatas Sol
> Sent: Friday, September 16, 2011 11:18 AM
> To: [email-masked]
> >> environment ICE already allows you to set the STUN keepalive
> duration
> >> to
> configuration we consider correct. 

There are two types of NAT64:  stateless (which has the characteristic
you describe) and stateful (which would require keepalive traffic
for all the reasons today's NAPT44 devices require keepalives).  I
don't know what is meant by "when set up correctly".

-d

> +1 for OAuth MAC for this reason.
> 
> 
> 
> >

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 16 Sep 2011 12:57:28 -0700

On 09/16/2011 12:34 PM, Dan Wing wrote:
>>>> If you are not sending anything the NAT binding in that direction
>>>>          
>> will
>>      
>>>> likely timeout. On the other hand, if you are operating in a
>>>>          
>> controlled
>>      

We call those "which would require keepalive traffic" simply battery 
systems (in simulation-only context).

Chakra and aha (no AI, no artificial entropy)! Is there an additional 
"signaling" when SIP throws 402? Within the box we first assume the 
battery is the source. In physical simulations, we consider the ground 
is the source ("historic").

I think JSON can send-on its own port and not constantly munge with XML 
ports that forces an option to show. JSON could be the default for 
websockets.

>>>> However, it mandates STUN keepalives to be used when an agent is a
>>>>          
>> full
>>      
>>>> ICE implementation and is communicating with a peer that supports
>>>>          
>> ICE
>>      
>>>> (lite/full). Are you saying it should allow a different UDP
>>>>          
>> keepalive
>>      
>>>> |>|Because, eventhough the keep-alives messages aren't
>>>>          
>> authenticated,
>>      
>>>> and
>>>> |>|clients, that could have quite big performance impact (the number
>>>>          
>> of
>>      
>>>> |>|STUN keep-alives sent per session of course depend on how much
>>>>          
>> other
>>      
>>>> |Well, it depends on the amount of outgoing media traffic, but in
>>>>          
>> cases
>>      

-- 

---

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 18 Sep 2011 23:10:34 +0200

On 09/16/2011 08:30 PM, Eric Rescorla wrote:
> On Fri, Sep 16, 2011 at 11:07 AM, Dan Wing<[email-masked]>  wrote:
Depending on RTCP seems less uncomfortable with SRTP than with plaintext 
RTCP.
I don't think we want to support RTCP-less applicaitons; if saying "no" 
to them helps them not occur (it doesn't always help...)

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 19 Sep 2011 08:35:44 +0200

18 sep 2011 kl. 23:10 skrev Harald Alvestrand:

> I don't think we want to support RTCP-less applicaitons; if saying "no" to them helps them not occur (it doesn't always help...)

No, we don't want to support applications without RTCP. +1.

/O

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 19 Sep 2011 11:19:34 +0000

I agree for rtcweb <-> rtcweb, but for going to/from non-rtcweb devices this is a problem.  Unfortunately lots of SIP devices don't generate RTCP.  Undoubtedly going to non-rtcweb will often require gateways of some form or other in the media plane, if for nothing else than ICE termination; but making such gateways generate fake RTCP is asking for the price to go up.  :(

-hadriel

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 19 Sep 2011 13:29:48 +0200

> I agree for rtcweb <-> rtcweb, but for going to/from non-rtcweb devices this is a problem.  Unfortunately lots of SIP devices don't generate RTCP.  Undoubtedly going to non-rtcweb will often requir…
That takes us back to the core question: How much should we let the old luggage of SIP affect the architecture of the new shining stuff we're creating here?

I agree that the SIP world has failed in implementing RTCP. Maybe we should discuss why and see what we can come up with. Some of my observations from working with RTCP in SIP:

 - NAT effects on the RTCP stream is mostly not handled
 - RTCP Bye is not really used 
 - Some devices have a policy/setting that says "Send RTCP every Y minute". Calls under Y minutes doesn't get RTCP, not even a BYE with final status
 - A well-known vendor sends RTCP with time stamps from year 2031

I think the coupling between actual codec quality and RTCP is missing with the ALAW/ULAW codecs. With more adaptive codecs and of course video, RTCP is becoming a requirement.  The current PSTN-centric mostly ALAW/ULAW SIP devices only needs RTCP to measure quality after the call is over which means that it's not a selling feature.

So if we rephrase the issue: I think RTCP should be a MUST for rtcweb implementations. However, calls should not fail when communicating with RTP implementations that doesn't send RTCP. 

/O

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 19 Sep 2011 11:53:18 +0000

I agree with everything you said, including the rephrasing at the end. (and is what I meant - be strict on send, liberal on receive)
:)

-hadriel

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 19 Sep 2011 16:39:58 +0200

Hi,

As an individual I like to provide some analyze of the entropy in
RTP/RTCP. Please consider, comment and provide opinion about the number
of bits.

> some implementations may not do RTCP...

So one case of attack is the one when the webserver S uses the connected
clients to attack target T by instructing client C to send to target T.
So the Server or some server controlled entity A needs to send RTCP to C
that makes C believe T is responding, i.e. spoofed source address that
are T's plus the content of the RTCP RR. Please note that SRTP will not
provide any protection if the webserver knows the key. Thus if security
description is allowed, which appear reasonable if supporting legacy is
the goal, which is the reason for this whole proposal.

Then lets analyze the entropy provided by RTP/RTCP.

RTP header:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X|  CC   |M|     PT      |       sequence number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So this is what is sent from C to T in a sequence.

Lets go through the fields in order:

V: fixed field
P: Indicator bit for padding. Not reported
X: Extension header indicator. Not reported
CC: CSRC Count: Normally 0. Not reported
M: Defined by payload type. Not reported
PT: Payload type, defined in signalling know by server
Sequence number: Hopefully random initial offset. Monotonically
incremented. Reported
Timestamp: Random offset, Not reported
SSRC: Random drawn. Likely signalled as it needs to be mapped to media
streams in current API. Reported

Lets then look at the fields present in an RR or SR
RTCP Report block

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
report |                 SSRC_1 (SSRC of first source)                 |
block  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1    | fraction lost |       cumulative number of packets lost       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           extended highest sequence number received           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      interarrival jitter                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         last SR (LSR)                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   delay since last SR (DLSR)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SSRC_1: Assumed to be known by webserver

Fraction lost: can be selected 0 or low value

cumulative number of packets lost: Can be selected, just needs to
increase at some interval if fraction lost isn't 0.

Extended highest sequence number: Top 16 bit will be 0 when starting up.
Now only the lowest 16 needs to be guessed. How difficult depends on the
packet rate, higher packet rate makes it easier as the range that C will
find the report valid for is larger. To make this robust any RTCP
reporting that contains a extended sequence number matching what was
sent the last few seconds (3-5) probably needs to be excepted. So actual
bits of entropy may be as few as 8. Here a bad implementation case exist
where the stack start at 0 and work its way up when it is close to 0 bits.

Interarrival jitter: can't be checked and a reasonable low value can be
selected.

last SR: This one contains the middle 32-bits out of the SR's NTP that C
sends. So this is likely based on the system clock. But if the system is
synchronized with an NTP server, then the general range can be guessed.
However, without intercepting the SR packet the time of transmitting the
latest SR is unknown. For a time synchronized sender that transmits only
regular SR reports using AVPF the trr-int will make the attacker aware
of how often new SRs will be transmitted. And initially this field may
be set to 0. So the first few intervals (3-5 * 3-5s = 9-25s) this field
provide 0 protection. After that if one require the SR field to be
correctly filled this field likely contains around 12 bits of entropy
for a known clock base.

DLSR can be set freely by attacker.

The SDES packet provide no protection and it the only other mandated
RTCP packet in a compound.

Thus my estimate is that RTCP in the first 10 seconds, which appears to
be the time interval we are interested can only provide the protection
to the level of difficulty it is to guess the sequence number field
within the range that has been sent the last 5 seconds, which I guess is
in the range of 8-12 bits of entropy.

If you mandate that the Last SR field is non-zero, which may delay the
the verification, allowing for more forward packets (attack packet) to
be sent, then we appear to get 20-24 bits.

I would claim this is to little randomness. It might be okay if one has
a paranoid implementation that clamps down on a stream that gets any
non-consistent RTCP packet. However, I would consider such behavior a
risk for being target of a denial of service attack against a media
stream that has a valid counter part.

I rather have more bits of entropy and continuing to allow a flow as
long as there are reports that are consistent often enough. That makes
the attacker spend resources without any major impact. Thus very little
more amplification than what a straight overload attack causes.

An attacker can also use multiple SSRCs to send its faked receiver
reports with. Thus making it difficult to determine if the one matching
the report is a valid feedback or a series of spoofed packets. Thus it
can also generate a number of guesses against C without invalidating
each sequence of guesses necessary to unlock high rate mode.

What is missing in this analyze is what impact on off-path attackers the
congestion control mechanism and its reports have. However, as they are
likely based on sequence numbers the reporting does not get
substantially more difficult, maybe only the range needed to be hit gets
slightly more compact.

Magnus Westerlund

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 19 Sep 2011 08:09:41 -0700

> From: Harald Alvestrand [mailto:[email-masked]]
> Sent: Sunday, September 18, 2011 2:11 PM
> To: Eric Rescorla
> Cc: Dan Wing; [email-masked]
> >>>>> at enough frequency that you get some sort of level of
> freshness....
> >>> maybe every 2 minutes or something.

(Case in point: RTCP has long been a requirement for RTP, but 
implementation was still skipped by Cisco, and probably others.)

I don't know how much entropy Eric was looking for.  RTCP receiver
reports only echo back the SSRC, which is 32 bits and is going to
be static for the duration of each RTP session (yes, SSRC collision
could make it change.  But that is atypical.)  STUN request/response
echoes back the 96-bit transaction id, which changes as often as the
requestor likes (typically each new STUN transaction).

Which would someone skip -- skip sending/implementing RTCP for 
consent freshness, or skip sending/implementing STUN request/response 
for consent freshness?  The STUN request/response is also additional
data, whereas RTCP is something that is "already being sent" (thus
the consent freshness isn't adding more bits on the wire).

-d

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 19 Sep 2011 17:35:23 +0200

> requestor likes (typically each new STUN transaction).

As I wrote in
http://www.ietf.org/mail-archive/web/rtcweb/current/msg01327.html

The amount of entropy in an RTCP message may be as low as 8 bits. If
certain restrictions is accepted then we can probably reach 20-24 bits
without requiring more than basic RTCP provides.

> the consent freshness isn't adding more bits on the wire).

I think RTCP may work for consent freshness. A longer series of
consistent RTCP messages to maintain the consent seems reasonable,
despite the low number of entropy bits per actual message. But, I do
think RTCP might have to few bits for the initial check where one wants
a rapid indication that it is fine to send media at higher bit-rates.

Cheers

Magnus Westerlund

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 19 Sep 2011 08:59:39 -0700

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Monday, September 19, 2011 8:35 AM
> To: Dan Wing
> Cc: 'Harald Alvestrand'; 'Eric Rescorla'; [email-masked]
> Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive]
> 
> >>>> If I have crashed or disconnected or am not listening on that
> port,
> >> I won't.

Thanks for that pointer.

In that post, you wrote:

  "So one case of attack is the one when the webserver S uses 
   the connected clients to attack target T by instructing client 
   C to send to target T. 
   ..."

That attack is what Jonathan called the 'voice hammer' attack.  
ICE solves that attack very well, 
http://tools.ietf.org/html/rfc5245#section-18.5.1 -- is more
needed for that attack?

When Eric mentioned 'consent freshness', it was the first time I 
had seen him use that term.  (No, I didn't search the archives.)
My interpretation 'consent freshness' is that, after a call had been
up and running the RTP receiver might die or disconnect from the
network, and a new host or restarted application might take over
that IP address and possibly also start listening on that same
UDP port.  By 'consent freshness', he wants a valid listener to
occasionally say "yes, I still like receiving this flow" 
and he wants other listeners to not send that message -- causing
the sender to eventually give up.

-d

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Sep 2011 09:16:18 -0700

> had seen him use that term.  (No, I didn't search the archives.)

Yeah, I just made it up. Maybe not the best term....

> the sender to eventually give up.

Yep. I'm certainly open to arguments that this isn't important... :)

-Ekr

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Mon, 19 Sep 2011 22:11:45 +0530

Another aspect to consider:
As per RFC 3550, the bare minimal valid RTCP packet is a compound RTCP packet containing:
- An RR packet with the reception report count set to 0 (RC=0) and
- An SDES packet with CNAME

Such a packet would look like this:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    RC=0 |   PT=RR=201   |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     SSRC of packet sender                     |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
header |V=2|P|   SC=1  |  PT=SDES=202  |             length            |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk  |                     SSRC of packet sender                     |
  1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    CNAME=1    |     length    |user & domain padded to 32-bit |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I've seen endpoints sending/accepting such a packet as an indication for session liveliness. However, there is no entropy at all in this packet. Suppose an attacker manages to bring the receiver down and captures such a RTCP packet. The attacker can keep replaying it (from the spoofed source transport address) to make the sender believe that the receiver is still alive and muted.

Perhaps, RTCWeb apps should try to negotiate an RTCP extension carrying a monotonically increasing number that must be part of every RTCP report together with SRTCP, for replay attack protection. 

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
|Sent: Monday, September 19, 2011 9:05 PM
|To: Dan Wing (dwing)
|Cc: [email-masked]
|Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive]
|
|On 2011-09-19 17:09, Dan Wing wrote:
|>> -----Original Message-----
|>> From: Harald Alvestrand [mailto:[email-masked]]
|>> Sent: Sunday, September 18, 2011 2:11 PM
|>> To: Eric Rescorla
|>> Cc: Dan Wing; [email-masked]
|>> Subject: Re: [rtcweb] STUN for keep-alive
|>>
|>> On 09/16/2011 08:30 PM, Eric Rescorla wrote:
|>>> On Fri, Sep 16, 2011 at 11:07 AM, Dan Wing<[email-masked]>  wrote:
|>>>>> -----Original Message-----
|>>>>> From: [email-masked] [mailto:[email-masked]] On
|>>>>> Behalf Of Eric Rescorla
|>>>>> Sent: Wednesday, September 14, 2011 10:32 AM
|>>>>> To: Christer Holmberg
|>>>>> Cc: [email-masked]
|>>>>> Subject: Re: [rtcweb] STUN for keep-alive
|>>>>>
|>>>>> On Wed, Sep 14, 2011 at 10:20 AM, Christer Holmberg
|>>>>> <[email-masked]>  wrote:
|>>>>>> Hi,
|>>>>>>
|>>>>>>> One new concern in this context is maintaining the consent
|>> freshness.
|>>>>>>> The browser needs to be sure that the recipient of traffic is
|>> stil
|>>>>> responding in a way that can't be forged. It's likely RTCP provides
|>>>>> this (though we'd need to analyze to be sure) but perhaps better
|>> would
|>>>>> be to mandate STUN checks
|>>>>>>> at enough frequency that you get some sort of level of
|>> freshness....
|>>>>> maybe every 2 minutes or something.
|>>>>>> Please note that the STUN keep-alives are implemented using STUN
|>>>>> indication messages, so there are no replies (nor does the receiver
|>>>>> perform an authentication check).
|>>>>>
|>>>>>
|>>>>> Oh... I had forgotten that.... that's not good.
|>>>> The RTCP receiver reports should be adequate for 'consent
|>> freshness', no?
|>>>> If I still like receiving the traffic, I'll report that I'm
|>> receiving it.
|>>>> If I have crashed or disconnected or am not listening on that port,
|>> I won't.
|>>> I believe so, though I'd have to make sure there's enough entropy.
|>> And of course
|>>> some implementations may not do RTCP...
|>> Depending on RTCP seems less uncomfortable with SRTP than with
|>> plaintext
|>> RTCP.
|>> I don't think we want to support RTCP-less applicaitons; if saying "no"
|>> to them helps them not occur (it doesn't always help...)
|>
|> (Case in point: RTCP has long been a requirement for RTP, but
|> implementation was still skipped by Cisco, and probably others.)
|>
|> I don't know how much entropy Eric was looking for.  RTCP receiver
|> reports only echo back the SSRC, which is 32 bits and is going to
|> be static for the duration of each RTP session (yes, SSRC collision
|> could make it change.  But that is atypical.)  STUN request/response
|> echoes back the 96-bit transaction id, which changes as often as the
|> requestor likes (typically each new STUN transaction).
|
|As I wrote in
|http://www.ietf.org/mail-archive/web/rtcweb/current/msg01327.html
|
|The amount of entropy in an RTCP message may be as low as 8 bits. If
|certain restrictions is accepted then we can probably reach 20-24 bits
|without requiring more than basic RTCP provides.
|
|>
|> Which would someone skip -- skip sending/implementing RTCP for
|> consent freshness, or skip sending/implementing STUN request/response
|> for consent freshness?  The STUN request/response is also additional
|> data, whereas RTCP is something that is "already being sent" (thus
|> the consent freshness isn't adding more bits on the wire).
|
|I think RTCP may work for consent freshness. A longer series of
|consistent RTCP messages to maintain the consent seems reasonable,
|despite the low number of entropy bits per actual message. But, I do
|think RTCP might have to few bits for the initial check where one wants
|a rapid indication that it is fine to send media at higher bit-rates.
|
|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]
|----------------------------------------------------------------------
|
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Randell Jesup <[email-masked]>
Date: Mon, 19 Sep 2011 13:36:32 -0400

> RTP/RTCP. Please consider, comment and provide opinion about the number
Thanks for the excellent analysis, Magnus.

> the goal, which is the reason for this whole proposal.

I would disagree with one aspect of that: I don't know that we need to
support SDES, and if we do, we only need to support it for "legacy"
connections, not true webrtc browser-to-browser connections, which I
assert should always be DTLS.  Of course, non-encrypted RTP to a legacy
device would have no protection against spoofing of return RTCP at all.

Note that we need to complete a valid ICE exchange with the target
per the current spec, so T can only be attacked to begin with if the ICE
exchange can be spoofed.  The original scenario from Eric was about "how
do I determine if the recipient wants to *continue* to receive data
after a valid exchange (for example after ending the call or
rebooting/crashing).  I haven't checked the properties of ICE and the
ability to spoof it, but before analyzing the entropy required to attack
the return RTCP 'freshness' state, we need to show that the attack could
be begun, or state that ICE is not mandatory for some connections.

As you mention, if we need extra entropy it might be possible to add it,
but not if we are assuming that the other side is a legacy SDES device.

-- 
Randell Jesup
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 20 Sep 2011 10:18:00 +0200

On 2011-09-19 18:41, Muthu Arul Mozhi Perumal (mperumal) wrote:
> Another aspect to consider: As per RFC 3550, the bare minimal valid
> RTCP packet is a compound RTCP packet containing: - An RR packet with
> the reception report count set to 0 (RC=0) and - An SDES packet with
> CNAME
> 
> 0                   1                   2                   3 0 1 2 3
> 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
> header |V=2|P|    RC=0 |   PT=RR=201   |             length
> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
> SSRC of packet sender                     | 
> header |V=2|P|   SC=1  |  PT=SDES=202  |             length
> | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 
> chunk  |                     SSRC of packet sender
> | 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
> CNAME=1    |     length    |user & domain padded to 32-bit | 
> I've seen endpoints sending/accepting such a packet as an indication
> for session liveliness. However, there is no entropy at all in this
> packet. Suppose an attacker manages to bring the receiver down and
> captures such a RTCP packet. The attacker can keep replaying it (from
> the spoofed source transport address) to make the sender believe that
> the receiver is still alive and muted.

well, the reasonable assumption if you are using this for consent
freshness is to verify that your flow is reported on in a reasonable
way. That do provide some entropy in sequence number and Last SR field
in the report block as I wrote in my other email.

> 
> Perhaps, RTCWeb apps should try to negotiate an RTCP extension
> carrying a monotonically increasing number that must be part of every
> RTCP report together with SRTCP, for replay attack protection.

That is a possibility, but I think one can start by ensuring that one
actually check for ones own traffic being reported back. That gives you
some entropy. Which is a slightly longer context gives you good
verification that you are not contining sending into a location where
there receiver you intended to have sent to moves away.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 20 Sep 2011 10:29:05 +0200

> device would have no protection against spoofing of return RTCP at all.

I think this analyze is valid for several different proposals that has
been raised.

1) Consent Freshness, i.e. the verification that a previous verified
destination continues to be present

2) Use RTCP instead of ICE for delivery consent, especially against
legacy which likely doesn't support ICE nor SRTP.

And I would also observe that we have no WG consensus on the security
mechanism. We have no WG document containing an assumption, nor have we
made a consensus call about what mechanism to support. I agree that DTLS
seems to have strong support as default keying mechanism, but also their
has been a fair amount of voices that thinks Security Descriptions
should be supported also to make keying towards legacy SRTP systems much
simpler.

Yes, it is likely time to do the consensus calls on the media security
mechanisms so that will be settled.

> be begun, or state that ICE is not mandatory for some connections.

But, if we want to look at not using ICE with legacy and still establish
consent to receive then RTCP has been discussed and I did want to
provide some indication of how strong this is.

Which I agree is fairly week, that considering that one appear to need
several RRs in sequence that are consistent combined with the reporter
having received SRs to be reasonably sure, which implies 10-30 seconds
before consent is being established as a less than working idea.

Cheers

Magnus Westerlund

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 20 Sep 2011 11:40:41 +0200

> So if we rephrase the issue: I think RTCP should be a MUST for rtcweb implementations. However, calls should not fail when communicating with RTP implementations that doesn't send RTCP.

+1

Be flexible on receiving and strict in sending.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 21 Sep 2011 10:19:36 +0200

Hi,
(as individual)

If I interpret this correctly, you are arguing that an RTCWEB
implementation shall support a remote end-point that doesn't support RTCP.

My question on that topic is:

What about congestion control against these end-points?

I personally have assumed RTCP with reasonable RTCP bandwidth and
minimal interval (not 5 second) being needed to have even medium time
scale (Several RTTs) adaptation.

I see congestion control for media as a MUST have due to the attack
vector that exist in RTCWEB implementations. A Webservice that has
sufficient amount of users visiting it can create additional
PeerConnections beyond what is necessary for the service that is the
front. These additional PeerConnections can be used to create traffic
load over selected paths in the Internet by selecting a good pairs of
peers to establish these overload streams. If there is no congestion
control, or at least isn't reasonably fair sharing it could push large
amount of other traffic out of the way on the paths selected by the
attacker to be targeted.

In addition it is needed to prevent the media quality to be very bad due
to overloading a path by one self. There is still paths that potentially
have issues even with a single G.711 voice stream, such as a GPRS link
to a cellular.

Cheers

Magnus Westerlund

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 21 Sep 2011 09:02:16 +0000

> implementation shall support a remote end-point that doesn't support RTCP.

Yes, although we could make that allowance/exception for audio only - in fact, G.711 only if it comes down to it.

Ultimately there is no indication in SIP/SDP that an device does not support RTCP.  So what would you have the Rtcweb browser do?  Once it starts sending media if it doesn't receive RTCP within time X then terminate the session automatically?  Would users be ok with that?

> amount of other traffic out of the way on the paths selected by the

If I understand your concern correctly, you're worried about the case of a malicious site controlling unsuspecting users as a botnet, making calls to each other and flooding the network paths between?

That can happen anyway: all ends are under control of the malicious site, so ICE will succeed... and even if the media layer starts throttling itself in a few seconds, the script can just keep creating/destroying PeerConnections, feeding new SDP to trigger port number changes, etc. And do so for video and audio and data channels concurrently or intermixed.

-hadriel

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 21 Sep 2011 14:17:35 +0200

On 2011-09-21 11:02, Hadriel Kaplan wrote:
> Yes, although we could make that allowance/exception for audio only -
> in fact, G.711 only if it comes down to it.

Well, I don't know if we can argue that one past the Transport Area
Director? I know I can argue 400 bps as an acceptable non congestion
controlled rate. And that is because that is the equivalent of a full
backed off TCP connection that sends one full Ethernet frame every 30
seconds. We probably can argue 4kbps also as an acceptable rate. But
getting to the next magnitude is more problematic, especially in the
light that there still exist a reasonable large number of access links
around the world that don't have more than a few 10kbps in capacity.

> 
> Ultimately there is no indication in SIP/SDP that an device does not
> support RTCP.  So what would you have the Rtcweb browser do?  Once it
> starts sending media if it doesn't receive RTCP within time X then
> terminate the session automatically?  Would users be ok with that?

I think that must be part of the adaptation/congestion control
algorithm. IF you don't get transport feedback you must stop sending. A
TCP connection that doesn't get ACKs will also not send.

Well, it is a transport failure and you would have to indicate that
connection is lost or something like this.

> 
> 
>> I see congestion control for media as a MUST have due to the
>> attack vector that exist in RTCWEB implementations. A Webservice
>> that has sufficient amount of users visiting it can create
>> additional PeerConnections beyond what is necessary for the service
>> that is the front. These additional PeerConnections can be used to
>> create traffic load over selected paths in the Internet by
>> selecting a good pairs of peers to establish these overload
>> streams. If there is no congestion control, or at least isn't
>> reasonably fair sharing it could push large amount of other traffic
>> out of the way on the paths selected by the attacker to be
>> targeted.
> 
> If I understand your concern correctly, you're worried about the case
> of a malicious site controlling unsuspecting users as a botnet,
> making calls to each other and flooding the network paths between?

Yes.

> 
> That can happen anyway: all ends are under control of the malicious
> site, so ICE will succeed... and even if the media layer starts
> throttling itself in a few seconds, the script can just keep
> creating/destroying PeerConnections, feeding new SDP to trigger port
> number changes, etc. And do so for video and audio and data channels
> concurrently or intermixed.

Yes, ICE is not a protection against this. And you are correct that if
you can start at rate higher than your "fair" share and then get
throttled down to the fair rate, then Congestion Control provides less
of a protection against this attack than if you start at or below your
fair share. But, you don't have knowledge about the acceptable rate
prior to actually sending. That combined with the issue of slow starting
media makes it a hard nut to crakc. I don't have really good answer to
the issue and it is clear that some compromise will be reached.

Cheers

Magnus Westerlund

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 21 Sep 2011 19:30:34 +0000

On Sep 21, 2011, at 8:17 AM, Magnus Westerlund wrote:

> Director?

Hmmm… how about by pointing out this is RTP over UDP and not TCP, and that we're following RFC 3550, which does not mandate reception of RTCP to continue the session?  I would think a Transport Area AD would know how UDP works. ;)

> I know I can argue 400 bps as an acceptable non congestion

Then the call quality will suck and the user will hang up.

BTW, are you suggesting that even with G.711, that rtcweb do some form of congestion control based on the RTCP packets?  At that point we're not even talking about RTP/AVP for PCMU/PCMA then are we?  This is some new profile, not AVP.

-hadriel

---

From: Colin Perkins <[email-masked]>
Date: Wed, 21 Sep 2011 21:34:20 +0100

> BTW, are you suggesting that even with G.711, that rtcweb do some form of congestion control based on the RTCP packets?  At that point we're not even talking about RTP/AVP for PCMU/PCMA then are we…

Well, the AVP spec [RFC3551, page 5] does say:

      If best-effort service is being used, RTP receivers SHOULD monitor
      packet loss to ensure that the packet loss rate is within
      acceptable parameters.  Packet loss is considered acceptable if a
      TCP flow across the same network path and experiencing the same
      network conditions would achieve an average throughput, measured
      on a reasonable timescale, that is not less than the RTP flow is
      achieving.  This condition can be satisfied by implementing
      congestion control mechanisms to adapt the transmission rate (or
      the number of layers subscribed for a layered multicast session),
      or by arranging for a receiver to leave the session if the loss
      rate is unacceptably high.

      The comparison to TCP cannot be specified exactly, but is intended
      as an "order-of-magnitude" comparison in timescale and throughput.
      The timescale on which TCP throughput is measured is the round-
      trip time of the connection.  In essence, this requirement states
      that it is not acceptable to deploy an application (using RTP or
      any other transport protocol) on the best-effort Internet which
      consumes bandwidth arbitrarily and does not compete fairly with
      TCP within an order of magnitude.

-- 
Colin Perkins
http://csperkins.org/

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 21 Sep 2011 21:19:54 +0000

We still don't need RTCP for that - use received RTP sequence number gaps, if necessary. (yeah it assumes symmetric path and bandwidth, and bi-dir media)

But anyway, there is no means of "dialing-down" G.711.  It's not adaptive.  Or are we saying the sender should start skipping samples and hope the receiver does PLC?

Really, the user will hang up if call quality sucks.  We don't need to be smarter than humans.

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 21 Sep 2011 23:22:38 +0200

2011/9/21 Hadriel Kaplan <[email-masked]>:
> We don't need to be smarter than humans.

I expected we are all humans XD

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 21 Sep 2011 21:35:14 +0000

Oh I dunno... I suspect some members on this list are Eliza programs, because I can predict their responses.  ;)

---

From: Colin Perkins <[email-masked]>
Date: Wed, 21 Sep 2011 22:36:11 +0100

No, as it says, you stop sending if you can't adjust and the loss rate is too high. And, sure, the user will probably hang-up anyway if the quality is bad, but it's worthwhile having a sanity check to drop the call if they don't, whether implemented based on RTCP reports or otherwise.

Colin

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 22 Sep 2011 09:48:14 +0200

On 2011-09-21 23:19, Hadriel Kaplan wrote:
> 
> We still don't need RTCP for that - use received RTP sequence number
> gaps, if necessary. (yeah it assumes symmetric path and bandwidth,
> and bi-dir media)

That doesn't really work without RTCP. You are assuming that path load
is symmetric so that any loss in A-B direction will be correspondingly
reflected on the flow in B-A direction. That is certainly not a common
property for IP paths. Thus without RTCP the sender has no knowledge
about what packet loss rate his flow is seeing.

> 
> But anyway, there is no means of "dialing-down" G.711.  It's not
> adaptive.  Or are we saying the sender should start skipping samples
> and hope the receiver does PLC?

Well, switch to a lower bandwidth codec.

> to be smarter than humans.

Well, the complications with G.711 is that there can be quite
significant loss before you don't understand anything.

But, if I interpret http://www.rfc-editor.org/rfc/rfc3714.txt correctly
for reasonably long paths we will in fact talk about such high packet
loss rates the call will be use less.

However, that is still not the only issue here. I agree that as long as
there is a human in the other end listening to the flow that is fine.

But if you don't have a human listening the premise of RTCWEB is that
you will be able to establish data flows across a path that is in fact
not connected to the rendering element in the other end. Thus no user
will detect the high packet loss and turn of the flow. It will continue
and be a DoS attack on the congested link because this flow takes
significantly more than its fair share.

That is my issue.

We are coming back to the most difficult trade-offs for RTCWEB. Legacy
interoperability vs Security. We have several different aspects which
makes legacy interoperability with a too simple device a big security risk.

Media transmission consent -> Requiring ICE support
Path Overload DoS concerns -> Requiring Congestion Control for both
media and data.
RTCWEB deployment model and concerns for privacy and confenditality ->
Media security (what level is still not agreed on)

All of the above are clear barriers against legacy interoperability.

Cheers

Magnus Westerlund

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 22 Sep 2011 11:00:32 +0000

> about what packet loss rate his flow is seeing.

That would be the part where I said "(yeah it assumes symmetric path and bandwidth, and bi-dir media)".
:)

> Well, switch to a lower bandwidth codec.

That's not really possible in the PSTN. :(
One could drop it to AMR or G.729 in some cases, but those are under royalty so I doubt an rtcweb browser will do them.

> significantly more than its fair share.

Right, but as I said previously, if the concern is a malicious server/JS, it can do it anyway even with congestion control.
If the concern is just that the far-end is dead or terminated the call but the local side didn't get the memo, we can solve that other ways.

> All of the above are clear barriers against legacy interoperability.

Yup.  I don't doubt we'll need some form of media-plane gateway either in the web server or separate to interop with legacy - I'm just trying to keep it from becoming so expensive and complicated that it would be cheaper/easier/better to use SIP softclients or plugins instead.

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 22 Sep 2011 13:01:02 +0200

> All of the above are clear barriers against legacy interoperability.

Hi Magnus, what do you exacly mean with "legacy interoperability"?

If you mean interoperability with SIP or XMPP I don't think that is
"legacy" as both protocols define extended features for the media
plane (including security concerns). It's true that some very-basic
SIP deployments and devices just use RTP without ICE, media security
and so, but that's not a written rule.

Regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 22 Sep 2011 13:08:21 +0200

> Yup.  I don't doubt we'll need some form of media-plane gateway either in the web server or separate to interop with legacy - I'm just trying to keep it from becoming so expensive and complicated t…

I can understand that some requirements can be imposed to RTCweb
environments in the media plane, but try at least to make it
compatible with VoIP networks out there. For example, requiring SRTP o
ZRTP could make sense (anyhow I don't see why that should be a
requirement in a local intranet in which plain-RTP is already used for
SIP communication).

If WebRTC forces the creation of media gateways when
intercommunicating with other RTP worlds (SIP, XMPP) that's not good
at all. Adding requirements it's ok, making it impossible by design is
not.

Regards.

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

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 22 Sep 2011 17:49:11 +0530

|That is a possibility, but I think one can start by ensuring 
|that one actually check for ones own traffic being reported 
|back. That gives you some entropy. Which is a slightly longer 
|context gives you good verification that you are not contining
|sending into a location where there receiver you intended to
|have sent to moves away.

Agree it would suffice in general. However, for cases like double hold (SDP offer with a=inactive) where you would be neither sending nor receiving media the attacker can keep replaying the RTCP packets with an empty report block (that no zero entropy) making you think the other end is still alive.

Of course, you may ultimately disconnect the call but it could mean a DOS attack.. 

Muthu

|-----Original Message-----
|From: Magnus Westerlund [mailto:[email-masked]]
|Sent: Tuesday, September 20, 2011 1:48 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: Dan Wing (dwing); [email-masked]
|Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive]
|
|On 2011-09-19 18:41, Muthu Arul Mozhi Perumal (mperumal) wrote:
|> Another aspect to consider: As per RFC 3550, the bare minimal valid
|> RTCP packet is a compound RTCP packet containing: - An RR packet with
|> the reception report count set to 0 (RC=0) and - An SDES packet with
|> CNAME
|>
|> Such a packet would look like this:
|>
|> 0                   1                   2                   3 0 1 2 3
|> 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|> header |V=2|P|    RC=0 |   PT=RR=201   |             length
|> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|> SSRC of packet sender                     |
|> +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|> header |V=2|P|   SC=1  |  PT=SDES=202  |             length
|> | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|> chunk  |                     SSRC of packet sender
|> | 1
|> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|> CNAME=1    |     length    |user & domain padded to 32-bit |
|> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|>
|> I've seen endpoints sending/accepting such a packet as an indication
|> for session liveliness. However, there is no entropy at all in this
|> packet. Suppose an attacker manages to bring the receiver down and
|> captures such a RTCP packet. The attacker can keep replaying it (from
|> the spoofed source transport address) to make the sender believe that
|> the receiver is still alive and muted.
|
|well, the reasonable assumption if you are using this for consent
|freshness is to verify that your flow is reported on in a reasonable
|way. That do provide some entropy in sequence number and Last SR field
|in the report block as I wrote in my other email.
|
|>
|> Perhaps, RTCWeb apps should try to negotiate an RTCP extension
|> carrying a monotonically increasing number that must be part of every
|> RTCP report together with SRTCP, for replay attack protection.
|
|That is a possibility, but I think one can start by ensuring that one
|actually check for ones own traffic being reported back. That gives you
|some entropy. Which is a slightly longer context gives you good
|verification that you are not contining sending into a location where
|there receiver you intended to have sent to moves away.
|
|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: Magnus Westerlund <[email-masked]>
Date: Thu, 22 Sep 2011 14:22:06 +0200

> Hi Magnus, what do you exacly mean with "legacy interoperability"?

All cases when the involved nodes aren't all implemented against the
RTCWEB specification.

> and so, but that's not a written rule.

I would say both SIP and XMPP based applications are legacy from an
RTCWEB perspective.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 22 Sep 2011 14:30:29 +0200

On 2011-09-22 13:00, Hadriel Kaplan wrote:
>>> adaptive.  Or are we saying the sender should start skipping
>>> samples and hope the receiver does PLC?
>> 
> That's not really possible in the PSTN. :( One could drop it to AMR
> or G.729 in some cases, but those are under royalty so I doubt an
> rtcweb browser will do them.

Yes, I agree that there will be cases where one doesn't have a choice
between hanging up. But, I think that must be part of the map.

>> However, that is still not the only issue here. I agree that as
>> long as there is a human in the other end listening to the flow
>> that is fine.
>> 
>> But if you don't have a human listening the premise of RTCWEB is
>> that you will be able to establish data flows across a path that is
>> in fact not connected to the rendering element in the other end.
>> Thus no user will detect the high packet loss and turn of the flow.
>> It will continue and be a DoS attack on the congested link because
>> this flow takes significantly more than its fair share.
>> 
>> That is my issue.
> 
> Right, but as I said previously, if the concern is a malicious
> server/JS, it can do it anyway even with congestion control. If the
> concern is just that the far-end is dead or terminated the call but
> the local side didn't get the memo, we can solve that other ways.

For the first part, I think we will need some protection against this
case, especially opening high bandwidth flows. Having a startup rate of
64 kbps is likely working in so many network that it isn't unreasonable.

And when it comes to open new PeerConnections, one protection from the
browser side is to have a memory of what media rates that was last used.
So if one open a new connection after terminating one that was limited
to 20kbps just seconds before, then you are very conservative when
starting a new peerConnection.

On the last issue, do you have a suggestion for how to achieve this that
isn't RTCP?

> 
> 
>> We are coming back to the most difficult trade-offs for RTCWEB.
>> Legacy interoperability vs Security. We have several different
>> aspects which makes legacy interoperability with a too simple
>> device a big security risk.
>> 
>> Media transmission consent -> Requiring ICE support Path Overload
>> DoS concerns -> Requiring Congestion Control for both media and
>> data. RTCWEB deployment model and concerns for privacy and
>> confenditality -> Media security (what level is still not agreed
>> on)
>> 
> Yup.  I don't doubt we'll need some form of media-plane gateway
> either in the web server or separate to interop with legacy - I'm
> just trying to keep it from becoming so expensive and complicated
> that it would be cheaper/easier/better to use SIP softclients or
> plugins instead.
> 

I understand and support that we shouldn't have unnecessary
complications for legacy interop. However, but I don't see it being done
by compromising security to the level where RTCWEB can't be deployed
even for browser to browser usage.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 22 Sep 2011 14:37:24 +0200

On 2011-09-22 14:19, Muthu Arul Mozhi Perumal (mperumal) wrote:
> |That is a possibility, but I think one can start by ensuring |that
> one actually check for ones own traffic being reported |back. That
> gives you some entropy. Which is a slightly longer |context gives you
> good verification that you are not contining |sending into a location
> where there receiver you intended to |have sent to moves away.
> 
> Agree it would suffice in general. However, for cases like double
> hold (SDP offer with a=inactive) where you would be neither sending
> nor receiving media the attacker can keep replaying the RTCP packets
> with an empty report block (that no zero entropy) making you think
> the other end is still alive.
> 

If neither party is actually transmitting media then the only traffic is
RTCP in either directions. Thus one RTCP compound packet per SSRC per
regular reporting interval. Unless you have an app that open a lot of
media streams that is usually pretty low bit-rate. And if you actually
have a lot of streams, then the bit-rate will saturate at the configured
RTCP rate. But I would note this is in fact a potential attack vector if
one can set the RTCP bit-rate arbitrary high.

Secondly, I think in those cases a timer on the inactivity from both
parties should be considered to terminate the session.

Cheers

Magnus Westerlund

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 22 Sep 2011 13:34:58 +0000

On Sep 22, 2011, at 8:30 AM, Magnus Westerlund wrote:

>> If the

If we assume that a gateway to legacy has to handle ICE termination anyway, then it can send STUN indications during the call.
The rtcweb browser can use those to see the far end is alive and expecting media on the 5-tuple.
If we're worried about those being faked/spoofed by malicious server/JS, we can modify the indication mechanism (which could also allay ekr's concerns about consent refresh).

> even for browser to browser usage.

Welllll... could we just require specific user consent for calls to/from legacy?

-hadriel

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 22 Sep 2011 19:30:40 +0530

|Secondly, I think in those cases a timer on the inactivity
|from both parties should be considered to terminate the session.

If the timer is based on RTP inactivity it would terminate the session. If it is based on RTCP inactivity (which many implementations do) it wouldn't.

Muthu

|-----Original Message-----
|From: Magnus Westerlund [mailto:[email-masked]]
|Sent: Thursday, September 22, 2011 6:07 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: Dan Wing (dwing); [email-masked]
|Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive]
|
|On 2011-09-22 14:19, Muthu Arul Mozhi Perumal (mperumal) wrote:
|> |That is a possibility, but I think one can start by ensuring |that
|> one actually check for ones own traffic being reported |back. That
|> gives you some entropy. Which is a slightly longer |context gives you
|> good verification that you are not contining |sending into a location
|> where there receiver you intended to |have sent to moves away.
|>
|> Agree it would suffice in general. However, for cases like double
|> hold (SDP offer with a=inactive) where you would be neither sending
|> nor receiving media the attacker can keep replaying the RTCP packets
|> with an empty report block (that no zero entropy) making you think
|> the other end is still alive.
|>
|> Of course, you may ultimately disconnect the call but it could mean a
|> DOS attack..
|
|If neither party is actually transmitting media then the only traffic is
|RTCP in either directions. Thus one RTCP compound packet per SSRC per
|regular reporting interval. Unless you have an app that open a lot of
|media streams that is usually pretty low bit-rate. And if you actually
|have a lot of streams, then the bit-rate will saturate at the configured
|RTCP rate. But I would note this is in fact a potential attack vector if
|one can set the RTCP bit-rate arbitrary high.
|
|Secondly, I think in those cases a timer on the inactivity from both
|parties should be considered to terminate the session.
|
|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: Randell Jesup <[email-masked]>
Date: Thu, 22 Sep 2011 11:09:05 -0400

> If the timer is based on RTP inactivity it would terminate the session. If it is based on RTCP inactivity (which many implementations do) it wouldn't.

There certainly may be use-cases where media in one (or both) directions are
inactive or DTX-muted for considerable periods of time - remember, many of
the use-cases (and unknown interesting future uses) aren't "phone calls".

In particular, I have some interesting use-cases bubbling in the back of my
brain where the data channel remains open at low/no activity and the media
channels are inactive or non-existant for long periods, or where data traffic
predominates and media are often inactive.

-- 
Randell Jesup
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 22 Sep 2011 17:50:10 +0200

On 2011-09-22 15:34, Hadriel Kaplan wrote:
>>> If the concern is just that the far-end is dead or terminated the
>>> call but the local side didn't get the memo, we can solve that
>>> other ways.
>> 
>> On the last issue, do you have a suggestion for how to achieve this
>> that isn't RTCP?
> 
> If we assume that a gateway to legacy has to handle ICE termination
> anyway, then it can send STUN indications during the call. The rtcweb
> browser can use those to see the far end is alive and expecting media
> on the 5-tuple. If we're worried about those being faked/spoofed by
> malicious server/JS, we can modify the indication mechanism (which
> could also allay ekr's concerns about consent refresh).

Yes, the question is if the indications are sufficient as their security
properties even when signed are a bit different from the STUN request
with answer.

>>> either in the web server or separate to interop with legacy -
>>> I'm just trying to keep it from becoming so expensive and
>>> complicated that it would be cheaper/easier/better to use SIP
>>> softclients or plugins instead.
>>> 
>> 
>> complications for legacy interop. However, but I don't see it being
>> done by compromising security to the level where RTCWEB can't be
>> deployed even for browser to browser usage.
> 

No, I don't think so. The user is not capable of determining the
difference between the two consent types. I am not certain that a random
picked person on this very mailing list will be able to explain it and
get agreement on the implications from the others in the first try.

What we might have is some other security indications for some set of
behaviors. But as the assumption discussion have showed it will not be
easy.

Having sounded quite negative, I still think it is worth spending some
time discussing the trade-offs that can be made. But I rather error on
the side of better security initially and then go back and change things
if we realize that it can be done.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 22 Sep 2011 17:54:23 +0200

On 2011-09-22 17:09, Randell Jesup wrote:
>> |Secondly, I think in those cases a timer on the inactivity |from
>> both parties should be considered to terminate the session.
>> 
>> If the timer is based on RTP inactivity it would terminate the
>> session. If it is based on RTCP inactivity (which many
>> implementations do) it wouldn't.
> 
> There certainly may be use-cases where media in one (or both)
> directions are inactive or DTX-muted for considerable periods of time
> - remember, many of the use-cases (and unknown interesting future
> uses) aren't "phone calls".
> 
> In particular, I have some interesting use-cases bubbling in the back
> of my brain where the data channel remains open at low/no activity
> and the media channels are inactive or non-existant for long periods,
> or where data traffic predominates and media are often inactive.
> 
> 

Yes, I definitely believe you. Which only points that we will need to
consider issues like how much background traffic that occurs just from
having the PeerConnection up and being ready for sending media. Maybe
mandate maximum levels when in practice inactive.

It also has implication I think on the continued media consent. As the
point raised Muthu is that when none sends media, there is in fact zero
entropy in the RTCP RR compound packets. Thus RTCP can't be used for that.

Cheers

Magnus Westerlund

---

From: Randell Jesup <[email-masked]>
Date: Thu, 22 Sep 2011 12:51:00 -0400

> entropy in the RTCP RR compound packets. Thus RTCP can't be used for that.
I wonder: could we create a default reliable data channel in all
PeerConnections that's used (solely?) for a heartbeat/"consent freshness"?
In that case, we get to define the heartbeat and can mandate enough entropy.
(Receiving data on reliable SCTP (or TCP) over DTLS might be enough right there.)

-- 
Randell Jesup
[email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 22 Sep 2011 13:29:30 -0600

In the past, we had too many ways of doing keep alive and it resulted in poor interoperability when two sides choose different ways - I'd rather avoid that sort of problem

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 22 Sep 2011 21:37:26 +0200

>> So, for RTP based media, one could use RTP, and for UDP based data channels "dummy" UDP packets (unless there is a protocol on top of UDP which provides a keep-alive mechanism itself).
... if you run DTLS/UDP, DTLS provides a HB mechanism:
http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-02
Best regards
Michael

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 22 Sep 2011 22:21:19 +0000

> properties even when signed are a bit different from the STUN request

When I said "we can modify the indication mechanism", I meant we could extend the way it works.  Right now in ICE you send STUN Indications but don't expect a response.  We can change it to be a request/response model instead, with some random cookie (or just the trans-id) that gets reflected in the response to prevent spoofing. (but not the full-blown hash integrity stuff)

-hadriel

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 23 Sep 2011 09:21:25 +0200

> (Receiving data on reliable SCTP (or TCP) over DTLS might be enough right there.)

The short answer is Yes, you can. But the longer answer is that it might
imply limitations on what deployments are possible.

First of all, this is only in reality practical when you only have a
single 5-tuple in use between the peers. If you don't multiplex all
flows on a single 5-tuple then you will need both consent and keep-alive
for each bi-directional flow the 5-tuple represents.

Secondly, for any consent freshness / heartbeat you do need to transmit
regularly. And considering common NAT timers for UDP we do need to have
keep-alives no less often than every 15 seconds to try to ensure that
the very aggressive timers of 30 seconds don't disconnect the session.

Thirdly one are using resources both in establishing this reliable data
channel, and then when using it for this function. Yes, you will spend
some resources on heartbeat in all cases. But you might have to do it
for multiple flow and then the reliable is an additional flow to
keep-alive if it isn't used for anything else.

So I am not thrilled of establishing an additional flow just for consent
freshness. In fact I am not thrilled by the PeerConnections default UDP
unreliable channel and believe the transports should be only enabled
upon demand from the application for such a transport.

I do see a simplicity in using ICE for keep-alive and consent freshness
as this is likely applicable for all transport protocols that we need
(as they will be over UDP) and aren't TCP to a relay or server.

I do also notice that there are desire for alternative solutions.

Lets keeps the discussion going.

Cheers

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 23 Sep 2011 11:33:29 +0200

> keep-alive if it isn't used for anything else.
And fourthly, any spec that requires a heartbeat channel on the media 
path mandates a media path gateway in order to interoperate with 
non-RTCWEB devices.
> upon demand from the application for such a transport.
We're removing it from the API spec. Whether or not it's mandated, 
that's not the right place to mandate it.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 23 Sep 2011 12:50:43 +0200

On 2011-09-23 11:33, Harald Alvestrand wrote:
> We're removing it from the API spec.

Right. But just for clarity, we're not removing the "default 
connection". Creating a PeerConnection will result in a connection 
(naturally the app in the other browser must also create a PC, and the 
signaling messages must be passed between them and so on for it to 
happen) being set up. My assumption has been that it is set up and kept 
alive using ICE, but I guess other methods are discussed.

> Whether or not it's mandated, that's not the right place to mandate it.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 24 Sep 2011 13:51:52 +0200

> requirement in a local intranet in which plain-RTP is already used for

This is where you get it wrong. You are pushing the decision to the user. They have to evaluate the network
their browser is currently attached to and make a decision on what kind of security they 
need for this particular network. Even in the office, the iPad on your desk might be connected
to 3G because it lost contact with the wifi. 

I think we can not require that users are able to perform a security evaluation of each and
every network the device their browser is running on connects to. Make it secure by default.
I mean, this is the year 2011 and we do have CPUs that can handle it. People walk around
with dual core in their pockets.

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 24 Sep 2011 15:37:43 +0200

Hi. I dont mean that security decisions are taken by the final user, but by
the service provider. If it is a local intranet or the users access the
intranet via a secure vpn, security can be relaxed ans the site provider
could determine that plain rtp is allowed.

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 24 Sep 2011 17:37:07 +0200

On 09/24/2011 03:37 PM, Iñaki Baz Castillo wrote:
>
> Hi. I dont mean that security decisions are taken by the final user, 
> but by the service provider. If it is a local intranet or the users 
> access the intranet via a secure vpn, security can be relaxed ans the 
> site provider could determine that plain rtp is allowed.
>
Remember that in the RTCWEB context, the service provider (the provider 
of the Javascript and the Web service) is presumed malicious.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 24 Sep 2011 17:54:42 +0200

2011/9/24 Harald Alvestrand <[email-masked]>:
>> Hi. I dont mean that security decisions are taken by the final user, but
>> by the service provider. If it is a local intranet or the users access the
> Remember that in the RTCWEB context, the service provider (the provider of
> the Javascript and the Web service) is presumed malicious.

But the user would *always* be asked for permission before
starting/accepting a media session, right? The same as it occurs with
Flash applications asking for micro/webcam usage. Such prompt should
be standarized by RTCweb and should let the user know the security
aspects of the offer:

-------------------
The web site www.domain.org asks you for permissions to start a
audio/[video] session using your micro and web cam.
Audio/video communication is not required to be encripted/secured.

Do you accept?

[ yes ]  [ no ]
------------------

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

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 24 Sep 2011 18:04:58 +0200

On 09/24/2011 05:54 PM, Iñaki Baz Castillo wrote:
> 2011/9/24 Harald Alvestrand<[email-masked]>:
Are we on the same subject line?

In the context we are talking about here (RTCP-less RTP flows), the 
prompt would have to be:

-----------
The web site www.domain.org wishes to send media to some other place on 
the Internet, and to set the option that allows it to communicate 
without using congestion control being available. You have no way of 
figuring out where the packets are going, whether this will cause harm 
to you, your network or anything else between here and there.

Do you accept?

[ yes ] [ no ]
----------
(note that if we want to include the place stuff is going to in the 
prompt, the prompt has to pop up AFTER we've established the call, and 
pop up again every time the transport addres is renegotiated.)

Does this seem reasonable?

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 24 Sep 2011 18:24:25 +0200

2011/9/24 Harald Alvestrand <[email-masked]>:
> In the context we are talking about here (RTCP-less RTP flows), the prompt
> would have to be:
>
> -----------
> The web site www.domain.org wishes to send media to some other place on the
> Internet, and to set the option that allows it to communicate without using
> congestion control being available. You have no way of figuring out where
> the packets are going, whether this will cause harm to you, your network or
> anything else between here and there.
>
> Do you accept?
>
> [ yes ] [ no ]
> ----------
> (note that if we want to include the place stuff is going to in the prompt,
> the prompt has to pop up AFTER we've established the call, and pop up again
> every time the transport addres is renegotiated.)

Just wondering: is not possible to indicate support for RTCP in the
SDP? Anyhow...

> Does this seem reasonable?

No, but what are we trying to prevent? a malicious site could always
initiate a session with a user in behalf of him best friend. I mean a
valid audio/video session (with ICE, RTCP, SRTP and so). The the user
(the WebRTC client) sends RTP there and the malicious site/user
uploads it to Youtube. How can rtcweb security constrains prevent
that???

In the other side, if user A establishes an audio session with user B,
and user B indicates a "malicious" address in the SDP (and does not
send RTCP reports) then user A would realize in just a few seconds
that "something is wrong since there is no audio" and would hangup. In
the meanwhile user A would send a few useless UDP packets to somewhere
within his LAN network, is that so critic?

I really wonder what we are trying to achieve in all these threads
about security in rtcweb.

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

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 24 Sep 2011 18:55:40 +0200

On 09/24/2011 06:24 PM, Iñaki Baz Castillo wrote:
> No, but what are we trying to prevent?
In this case (keepalive using RTCP) we're trying to prevent the 
Javascript running in user A's browser from connecting to user B, having 
user B hang up, and the packets continuing to flow "forever" from A to B.
>   a malicious site could always
If the JS in user A negotiates one connection to user B and another to 
user C, and hears audio from user C, when would he realize that user B 
had dropped off the conference call?
> about security in rtcweb.
If you can formulate your wondering in terms of 
"draft-ietf-rtcweb-security should be changed to say *this* to make it 
clear", that would be most helpful.

I think I'll take my own advice and shut up on this thread...

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 24 Sep 2011 18:58:47 +0200

2011/9/24 Harald Alvestrand <[email-masked]>:
> If you can formulate your wondering in terms of "draft-ietf-rtcweb-security
> should be changed to say *this* to make it clear", that would be most
> helpful.

I will take a look to that draft.
Thanks a lot.

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