Last Call Review of draft-ietf-perc-private-media-framework-08
review-ietf-perc-private-media-framework-08-secdir-lc-roca-2019-02-14-00

Request Review of draft-ietf-perc-private-media-framework
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-02-13
Requested 2019-01-30
Draft last updated 2019-02-14
Completed reviews Secdir Last Call review of -08 by Vincent Roca (diff)
Genart Last Call review of -08 by Linda Dunbar (diff)
Tsvart Last Call review of -08 by Gorry Fairhurst (diff)
Secdir Telechat review of -10 by Vincent Roca (diff)
Genart Telechat review of -09 by Linda Dunbar (diff)
Assignment Reviewer Vincent Roca
State Completed
Review review-ietf-perc-private-media-framework-08-secdir-lc-roca-2019-02-14
Reviewed rev. 08 (document currently at 12)
Review result Has Issues
Review completed: 2019-02-14

Review
review-ietf-perc-private-media-framework-08-secdir-lc-roca-2019-02-14

Hello,

I have reviewed this document as part of the security directorate’s ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

Summary: **Has Issues**


I have several significant concerns with respect to the Security Considerations section.

** Section 8.1
Why is it said that:
	"A successful attacker might be able to get the Media Distributor to forward such packets."
Is it really possible? That would be a big design issue! In fact the following sentence suggest the
opposite and I think this is essentially an erroneous manner to present things. Please see comments
on Section 8.2.4 on saying things the other way round.

The same comment applies to the remaining two paragraphs. I suggest the authors explain that the
proposal prevents an attacker to claim being a regular Media Distributor and therefore to fool
endpoints because ...".


** Section 8.2.2. 
Is the following sentence correct:
   The mitigation for a replay attack is to prevent old packets beyond a
   small-to-modest jitter and network re-ordering sized window to be
   rejected.
Is "prevent [...] to be rejected" correct? I'd say "... to be delivered" instead.

Another comment. Replay protection seems to be based on timing considerations rather than on the use
of unique sequence numbers that must not be replayed (except if a wrapping to zero occurs of course).
Is that correct?
Additionally, is this mechanism carefully described in this document? Since it is explained that
E2E replay protection MUST be provided, it's essential to be very clear on how to perform this.
Failing to do so is a big issue.


** Section 8.2.3
It is said that "a Media Distributor can select to not deliver a particular stream for a while."
That's perfectly true, yet is this a "Delayed playout attack"? I'd rather call it a Media Distributor
censorship attack, or something along this line. The main idea behind the attack is not to delay a
stream but to censor a source.

In the second paragraph I don't understand why it is said that:
	"the receiver believing that it is what was said just now, and only delayed due to transport delay."
Any RTP packet contains a timestamp (whose integrity is protected end-to-end if I understand correctly),
and this timestamp is used by the receiver to identify timing issues.
The fact a packet is delayed (significantly) by a Media Distributor cannot be misinterpreted by a receiver
as a "what was said just now". The receiver immediately identifies this delay.

I now understand the title ("delayed playout") but I really suspect this is a mistake as (too much)
delayed packets will not be played at all. 


** Section 8.2.4:
I don't like the way this section is written. It first explains what a Media Distributor could do
if it could alter a certain header field (in this case SSRC), it details the consequences, to finally
explain that this is not possible.
This Security Discussion section is essentially meant to discuss remaining security issues or highlight
specific aspects, not what could happen with a different, non secure, design. 
This text could also be written the other way round: "By including the SSR field into the integrity check,
PERC prevents splicing attacks where...".


** Missing in 8.2
The RTCP flows are not encrypted end-to-end (unlike data flows) but only hop-by-hop.
Consequently, a malicious Media Distributors may corrupt an RTCP packet content (e.g., reception
statistics in RR) or forge malicious RTCP packets which may trigger various effects at a sender.
There are other types of RTCP packets that may be attacked as well with various consequences.
None of this is explained in section 8.2. "Media Distributor Attacks". 


** General comments about 8.1 and 8.2
Insider attacks are a powerful form of attacker model with severe consequences. This is not a big
surprise. I'd be more interesting in a detailed 8.1 section, more likely to happen (weaker attacker
model). 


Suggestion:

** 8.2. Instead of:
	"The Media Distributor can attack the session in a number of possible
   	ways."
I suggest:
	"A malicious or compromised Media Distributor can ..."


Typos: 

** Intro: s/virutalized/virtualized/

** Section 2: s/and is never allowed have access/and is never allowed to have access/

** 8. Security Considerations:
	s/could incorrectly assuming/could incorrectly assume/

	s/This attack is be mitigated/This attack is mitigated/

	s/when an already received packets/when an already received packet/


Other comments:

** Section 6, intro: (it's a detail, but...)
I don't think that the use of "and so forth" is adequate in a specification that aims to be exhaustive.
The list of items addressed in section 6 is finished.


Cheers,

  Vincent