Skip to main content

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 revision No specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-02-13
Requested 2019-01-30
Authors Paul Jones , David Benham , Christian Groves
I-D 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
Request Last Call review on draft-ietf-perc-private-media-framework by Security Area Directorate Assigned
Reviewed revision 08 (document currently at 12)
Result Has issues
Completed 2019-02-14
review-ietf-perc-private-media-framework-08-secdir-lc-roca-2019-02-14-00
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