Subject: [xrblock] Sec Dir and IESG reviews raised for Discard RLE Draft

From: Varun Singh <[email-masked]>
Date: Sun, 21 Jul 2013 12:00:07 +0300

Hi all,

Discard RLE [1] was recently reviewed by Sec Dir [2] and IESG, some issues
were raised, which require input from the WG.

Sec Dir:
The concern is that the fine grained reporting by using discard RLE may
compromise security and if this has been adequately discussed by the WG.

OLD TEXT:
   The security considerations of [RFC3550], [RFC3611], and [RFC4585]
   apply.  Since this document offers only a more precise reporting for
   an already existing metric, no further security implications are
   foreseen.

NEW TEXT:

  The Discard RLE block provides per-packet statistics so the risk to
  confidentiality documented in Section 7, paragraph 3 of [RFC3611]
  applies.  In some situations, returning very detailed error
  information (e.g.,over-range measurement or measurement unavailable)
  using this report block can provide an attacker with insight into the
  security processing.  Where this is a concern, the implementation
  should apply authentication to this report block.  This can be
  achieved by using the AVPF profile together with the Secure RTP
  profile as defined in [RFC3711]; as a prerequisite, an appropriate
  combination of those two profiles (an "SAVPF") is being specified
  [RFC5124].

  Additionally, The security considerations of [RFC3550], [RFC3611],
  and [RFC4585] apply.

Comments or feedback on the above text is appreciated.
Cheers,
Varun

[1]
http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06
[2] http://www.ietf.org/mail-archive/web/secdir/current/msg04048.html

-- 
http://www.netlab.tkk.fi/~varun/

---

From: Varun Singh <[email-masked]>
Date: Tue, 30 Jul 2013 12:07:56 +0200

Hi all,

Based on the input yesterday, I've put together the following proposal
for the Security Considerations section:

The Discard RLE block provides per-packet statistics so the risk to
confidentiality documented in Section 7, paragraph 3 of [RFC3611]
applies.  In some situations, returning very detailed error
information (e.g., over-range measurement or measurement unavailable)
using this report block can provide an attacker with insight into the
security processing.  Implementers should consider the guidance in
[I.D-ietf-avt-srtp-not-mandatory] for using appropriate security mechanisms,
i.e., where security is a concern, the implementation should for example
apply
encryption and authentication to the report block. This can be achieved by
using the AVPF profile together with the Secure RTP profile as defined in
[RFC3711]; as a prerequisite, an appropriate combination of the two
profiles
(an "SAVPF") is specified in [RFC5124].

---
 Feedback and comments are appreciated.

Cheers,
Varun

---

From: Qin Wu <[email-masked]>
Date: Tue, 30 Jul 2013 10:21:20 +0000

The proposed text looks good to me.

Regards!
-Qin
发件人: [email-masked] [mailto:[email-masked]] 代表 Varun Singh
发送时间: 2013年7月30日 18:08
收件人: [email-masked]
主题: Re: [xrblock] Sec Dir and IESG reviews raised for Discard RLE Draft

Hi all,

i.e., where security is a concern, the implementation should for example apply
[RFC3711]; as a prerequisite, an appropriate combination of the two profiles

---

Cheers,
Varun

On Sun, Jul 21, 2013 at 11:00 AM, Varun Singh <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Discard RLE [1] was recently reviewed by Sec Dir [2] and IESG, some issues were raised, which require input from the WG.

Sec Dir:

OLD TEXT:

NEW TEXT:

[1] http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06
[2] http://www.ietf.org/mail-archive/web/secdir/current/msg04048.html

---

From: Qin Wu <[email-masked]>
Date: Tue, 30 Jul 2013 10:29:51 +0000

Does byte discard  block or RLE discard report error information?
One point to add:
If byte discard block is split out or moved, it seems the text like
“
 In some situations, returning very detailed error
information (e.g., over-range measurement or measurement unavailable)
using this report block can provide an attacker with insight into the
security processing.  Implementers should consider the guidance in
[I.D-ietf-avt-srtp-not-mandatory] for using appropriate security mechanisms,
i.e., where security is a concern, the implementation should for example apply
encryption and authentication to the report block. This can be achieved by
using the AVPF profile together with the Secure RTP profile as defined in
[RFC3711]; as a prerequisite, an appropriate combination of the two profiles
(an "SAVPF") is specified in [RFC5124].

”
Should be split out as well.

Regards!
-Qin
发件人: Qin Wu
发送时间: 2013年7月30日 18:21
收件人: 'Varun Singh'; [email-masked]
主题: 答复: [xrblock] Sec Dir and IESG reviews raised for Discard RLE Draft

Regards!
-Qin
发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] 代表 Varun Singh
发送时间: 2013年7月30日 18:08
收件人: [email-masked]<mailto:[email-masked]>
主题: Re: [xrblock] Sec Dir and IESG reviews raised for Discard RLE Draft

Hi all,

---

Cheers,
Varun

Sec Dir:

OLD TEXT:

NEW TEXT:

---

From: Varun Singh <[email-masked]>
Date: Tue, 30 Jul 2013 12:59:17 +0200

Hi Qin,

Error information in this case is the information reported by the XRBLOCK,
i.e.,
if some packets or bytes were discarded.

As far as I understood Stephen Farrell's concern; if lots of forged packets
(by flipping
bits in the RTP packet header) are sent using a side channel can the
attacker look at
the discard reports (any of them) to compromise the security.

In my opinion, packets are only discarded if they arrive outside the
dejitter buffer window,
so forged packets should should not be a concern (as these packets would be
discarded
but not reported).

Cheers,
Varun

On Tue, Jul 30, 2013 at 12:29 PM, Qin Wu <[email-masked]> wrote:

>  Does byte discard  block or RLE discard report error information?****
>
> One point to add:****
>
> If byte discard block is split out or moved, it seems the text like****
>
> “****
>
>  In some situations, returning very detailed error****
>
> information (e.g., over-range measurement or measurement unavailable)****
>
> using this report block can provide an attacker with insight into the****
>
> security processing.  Implementers should consider the guidance in****
>
> [I.D-ietf-avt-srtp-not-mandatory] for using appropriate security
> mechanisms,****
>
> apply ****
> ****
> ****
> profiles ****
> (an "SAVPF") is specified in [RFC5124].****
>
> ** **
>
> ”****
>
> Should be split out as well.****
>
> ** **
>
> ** **
>
> Regards!****
>
> -Qin****
>
> *发件人:* Qin Wu
> *发送时间:* 2013年7月30日 18:21
> *收件人:* 'Varun Singh'; [email-masked]
> *主题:* 答复: [xrblock] Sec Dir and IESG reviews raised for Discard RLE Draft*
> ***
>
> ** **
>
> The proposed text looks good to me.****
>
> ** **
>
> Regards!****
>
> -Qin****
>
> *发件人:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *代表 *Varun Singh
> *发送时间:* 2013年7月30日 18:08
> *收件人:* [email-masked]
> *主题:* Re: [xrblock] Sec Dir and IESG reviews raised for Discard RLE Draft*
> ***
>
> ** **
>
> Hi all,****
>
> ** **
>
> Based on the input yesterday, I've put together the following proposal****
>
> for the Security Considerations section:****
>
> ** **
>
> The Discard RLE block provides per-packet statistics so the risk to****
>
> confidentiality documented in Section 7, paragraph 3 of [RFC3611]****
>
> applies.  In some situations, returning very detailed error****
>
> information (e.g., over-range measurement or measurement unavailable)****
>
> using this report block can provide an attacker with insight into the****
>
> security processing.  Implementers should consider the guidance in****
>
> [I.D-ietf-avt-srtp-not-mandatory] for using appropriate security
> mechanisms,****
>
> apply ****
> ****
> ****
> profiles ****
> (an "SAVPF") is specified in [RFC5124].****
>
> ** **
>
> Additionally, The security considerations of [RFC3550], [RFC3611],****
>
> and [RFC4585] apply.****
>
> ** **
>
> ---****
>
>  Feedback and comments are appreciated.****
>
> ** **
>
> Cheers,****
>
> Varun****
>
> ** **
>
> ** **
>
> ** **
>
> On Sun, Jul 21, 2013 at 11:00 AM, Varun Singh <[email-masked]>
> wrote:****
>
> Hi all,****
>
> ** **
>
> were raised, which require input from the WG.****
>
> ** **
>
> Sec Dir: ****
>
> The concern is that the fine grained reporting by using discard RLE may **
> **
>
> compromise security and if this has been adequately discussed by the WG.**
> **
>
> ** **
>
> OLD TEXT:****
>
>    The security considerations of [RFC3550], [RFC3611], and [RFC4585]****
>
>    apply.  Since this document offers only a more precise reporting for***
> *
>
>    an already existing metric, no further security implications are****
>
>    foreseen.****
>
> ** **
>
> NEW TEXT:****
>
> ** **
>
>   The Discard RLE block provides per-packet statistics so the risk to****
>
>   confidentiality documented in Section 7, paragraph 3 of [RFC3611]****
>
>   applies.  In some situations, returning very detailed error****
>
>   information (e.g.,over-range measurement or measurement unavailable)****
>
>   using this report block can provide an attacker with insight into the***
> *
>
>   security processing.  Where this is a concern, the implementation****
>
>   should apply authentication to this report block.  This can be****
>
>   achieved by using the AVPF profile together with the Secure RTP****
>
>   profile as defined in [RFC3711]; as a prerequisite, an appropriate****
>
>   combination of those two profiles (an "SAVPF") is being specified****
>
>   [RFC5124].****
>
> ** **
>
>   Additionally, The security considerations of [RFC3550], [RFC3611],****
>
>   and [RFC4585] apply.****
>
> ** **
>
> Comments or feedback on the above text is appreciated.****
>
> Cheers,****
>
> Varun****
>
> ** **
>
> ** **
>
> [1]
> ****
> [2] http://www.ietf.org/mail-archive/web/secdir/current/msg04048.html****
>
> ** **
>
> --
> http://www.netlab.tkk.fi/~varun/ ****
>
>
>
> ****
>
> ** **
>
> --
> http://www.netlab.tkk.fi/~varun/ ****
>

---

From: Qin Wu <[email-masked]>
Date: Tue, 30 Jul 2013 12:03:00 +0000

Relying on dejitter buffer to discard forgery packet is one way to solve this issue,
When receiver report error information, this kind of error information also can be
misused by attacker, that’s why we apply encryption and authentication.

Anyway, your clarification makes sense to me.

Regards!
-Qin
发件人: Varun Singh [mailto:[email-masked]]
发送时间: 2013年7月30日 18:59
收件人: Qin Wu
抄送: [email-masked]
主题: Re: 答复: [xrblock] Sec Dir and IESG reviews raised for Discard RLE Draft

Hi Qin,

Error information in this case is the information reported by the XRBLOCK, i.e.,
if some packets or bytes were discarded.

As far as I understood Stephen Farrell's concern; if lots of forged packets (by flipping
bits in the RTP packet header) are sent using a side channel can the attacker look at
the discard reports (any of them) to compromise the security.

In my opinion, packets are only discarded if they arrive outside the dejitter buffer window,
so forged packets should should not be a concern (as these packets would be discarded
but not reported).

Cheers,
Varun

On Tue, Jul 30, 2013 at 12:29 PM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:

”

Regards!
-Qin
发件人: Qin Wu
发送时间: 2013年7月30日 18:21
收件人: 'Varun Singh'; [email-masked]<mailto:[email-masked]>
主题: 答复: [xrblock] Sec Dir and IESG reviews raised for Discard RLE Draft

Regards!
-Qin

Hi all,

---

Cheers,
Varun

Sec Dir:

OLD TEXT:

NEW TEXT:

---

From: Colin Perkins <[email-masked]>
Date: Tue, 30 Jul 2013 14:09:30 +0200

Hi Varun,

As I said in the meeting yesterday, I think this needs to explicitly state that using the Secure RTP profile is one example solution, but others exist and might be more suitable.

Colin

On 30 Jul 2013, at 12:07, Varun Singh <[email-masked]> wrote:
> The Discard RLE block provides per-packet statistics so the risk to confidentiality documented in Section 7, paragraph 3 of [RFC3611] applies.  In some situations, returning very detailed error information (e.g., over-range measurement or measurement unavailable) using this report block can provide an attacker with insight into the security processing.  Implementers should consider the guidance in [I.D-ietf-avt-srtp-not-mandatory] for using appropriate security mechanisms, i.e., where security is a concern, the implementation should for example apply encryption and authentication to the report block. This can be achieved by using the AVPF profile together with the Secure RTP profile as defined in [RFC3711]; as a prerequisite, an appropriate combination of the two profiles (an "SAVPF") is specified in [RFC5124].
> 
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

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

---

From: Varun Singh <[email-masked]>
Date: Tue, 30 Jul 2013 17:31:08 +0200

Hi Colin,

New proposal inline, does it fix the concern?

On Tue, Jul 30, 2013 at 2:09 PM, Colin Perkins <[email-masked]> wrote:

> Hi Varun,
>
> As I said in the meeting yesterday, I think this needs to explicitly state
> that using the Secure RTP profile is one example solution, but others exist
> and might be more suitable.
>
>

The Discard RLE block provides per-packet statistics so the risk to
confidentiality documented in Section 7, paragraph 3 of [RFC3611] applies.
In
some situations, returning very detailed error information (e.g., over-range
measurement or measurement unavailable) using this report block can provide
an
attacker with insight into the security processing. Implementers should
consider the guidance in [I.D-ietf-avt-srtp-not-mandatory] for using
appropriate security mechanisms, i.e., where security is a concern, the
implementation should apply encryption and authentication to the report
block.
For example this can be achieved by using the AVPF profile together with the
Secure RTP profile as defined in [RFC3711]; an appropriate combination of
the
two profiles (an "SAVPF") is specified in [RFC5124]. However, other
mechanisms
also exist (documented in [I.D-ietf-avtcore-rtp-security-options]) and
might be more suitable.

---

From: Colin Perkins <[email-masked]>
Date: Tue, 30 Jul 2013 18:27:56 +0200

Yes, that looks fine. 

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

On 30 Jul 2013, at 17:31, Varun Singh <[email-masked]> wrote:

> confidentiality documented in Section 7, paragraph 3 of [RFC3611] applies. In
> measurement or measurement unavailable) using this report block can provide an
> implementation should apply encryption and authentication to the report block.
> Secure RTP profile as defined in [RFC3711]; an appropriate combination of the
> two profiles (an "SAVPF") is specified in [RFC5124]. However, other mechanisms 
> also exist (documented in [I.D-ietf-avtcore-rtp-security-options]) and might be more suitable.
>