Subject: [Gen-art] Gen-ART review of draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 24 Jan 2014 09:02:25 -0600

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01
Reviewer: Vijay K. Gurbani
Review Date: Jan-24-2014
IETF LC End Date: Feb-04-2014
IESG Telechat date: Unknown

Major: 0
Minor: 0
Nits: 1

This document is ready as a Proposed Standard.

Nits:
- S6, "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." I am not sure what you mean by "security processing"
  here --- maybe you meant the byte discard block leaks privacy of the
  user?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: Varun Singh <[email-masked]>
Date: Fri, 24 Jan 2014 18:44:36 +0200

Hi Vijay,

Thank you for the careful review. 

Comment inline. 

Regards,
Varun

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

> On 24.1.2014, at 17.02, "Vijay K. Gurbani" <[email-masked]> wrote:
> 

It is not necessarily privacy of the user, but a situation when the receiver reports a packet as discarded and If the packet was carefully crafted by an attacker,  they infer something about the security processing of the endpoint. 

AFAIR the wording of the paragraph is adapted from other drafts discussing discarded packets (RFC7097 and RFC7002) and with input from sec-dir. That being said, if the wording can be made more clear, I'm happy to incorporate the proposal.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 24 Jan 2014 12:58:04 -0600

On 01/24/2014 10:44 AM, Varun Singh wrote:
>> Nits: - S6, "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." I am not sure what you mean
>> by "security processing" here --- maybe you meant the byte discard
>> block leaks privacy of the user?
>>
> It is not necessarily privacy of the user, but a situation when the
> receiver reports a packet as discarded and If the packet was
> carefully crafted by an attacker,  they infer something about the
> security processing of the endpoint.

Varun: It was not immediately clear to me that your threat model when
you discuss this included the attacker mounting an active attack, but
regardless, the larger question of what you mean by "security
processing" remains --- who is doing the "processing" and how is the
"security" impacted?

If an attacker crafts a packet and sends it to the victim, who discards
it, then the attacker gets a XR Bytes Discarded report block, and at
best the attacker knows that the packet was discarded due to either
early arrival or late arrival (the 'E' bit).  What is the "security
processing" insight that we are worried about here?

Furthermore, if the attacker is capable of mounting an attack such that
it can inject arbitrary packets to the victim, then the attacker is
either in a session with the victim (a session the victim can stop
at any time), or the attacker has usurped the channel between the
victim and the original participant that the victim was conversing
with.  In both cases, I suspect that the damage done is more than the
attacker just getting back discard report blocks.

> AFAIR the wording of the paragraph is adapted from other drafts
> discussing discarded packets (RFC7097 and RFC7002) and with input
> from sec-dir. That being said, if the wording can be made more clear,
> I'm happy to incorporate the proposal.

I would have had the same questions of rfc7097 or rfc7002 if I had been
chosen to Gen-ART review them :-)

I think you need to motivate your threat model in S6 to determine the
mitigation strategies where SRTP/SAVPF will help.  You can discuss this
with your chair or your friendly sec-dir personnel and if they
indicate that no threat model is needed, then please go ahead with the
draft.  Gen-ART reviews are advisory in nature anyway.  However, since
I was confused on reading the section and remain so after our brief
email exchange, I think some text added on the motivation may be helpful
to future readers (and implementers) of the extension.

Cheers,

- vijay

---

From: Varun Singh <[email-masked]>
Date: Fri, 31 Jan 2014 16:25:37 +0200

Hi Vijay,

Apologies for the tardiness, comments inline.

> processing" insight that we are worried about here?

In this particular case, we are worried about a side channel attack. 
The attacker sends a late arriving packet (timestamp in the past)
to the receiver and if the receiver sends a discard report with the 
same number of bytes as the payload of the injected packet, the
attacker may infer that no security processing was performed. 
If it observes no discard report, it may infer that security procedures 
were performed on the packet.

> attacker just getting back discard report blocks.

Agree, this kind of attack can be mounted by any endpoint passively monitoring the session
along the path and since RTP is sent over UDP, the attacker can mount the above attack. 

> mitigation strategies where SRTP/SAVPF will help.  You can discuss this

I think one of the reasons not to explicitly write about the threat model is because
there are several reason to use and not use SRTP/AVPF. they are covered in
ietf-avt-srtp-not-mandatory, and implementors should read that document
to make up their mind.

I hope the chairs can clarify on how to proceed. 

> to future readers (and implementers) of the extension.

Thank you again for the feedback.

Cheers,
Varun.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 31 Jan 2014 08:45:12 -0600

> Apologies for the tardiness, comments inline.

Varun: No worries.  More inline.

> The attacker sends a late arriving packet (timestamp in the past) to
> the receiver and if the receiver sends a discard report with the same
> number of bytes as the payload of the injected packet, the attacker
> may infer that no security processing was performed. If it observes
> no discard report, it may infer that security procedures were
> performed on the packet.

Ah, so you can trivially solve this problem by describing the attack in
the draft, much as you do above.

> I think one of the reasons not to explicitly write about the threat
> model is because there are several reason to use and not use
> SRTP/AVPF. they are covered in ietf-avt-srtp-not-mandatory, and
> implementors should read that document to make up their mind.

My reading of draft-ietf-avt-srtp-not-mandatory is that it does not
absolve RTP extension authors from talking about security, rather it
exhorts them to talk about the specific security problems exhibited
by their proposed extension and furthermore, elaborate how to address
such concerns.

Cheers,

- vijay