Last Call Review of draft-ietf-avtcore-idms-09

Request Review of draft-ietf-avtcore-idms
Requested rev. no specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-06-11
Requested 2013-05-30
Authors Ray van Brandenburg, Hans Stokking, Oskar van Deventer, Fernando Boronat, Mario Montagud, Kevin Gross
Draft last updated 2013-08-08
Completed reviews Genart Last Call review of -09 by Dan Romascanu (diff)
Secdir Last Call review of -09 by Vincent Roca (diff)
Assignment Reviewer Vincent Roca
State Completed
Review review-ietf-avtcore-idms-09-secdir-lc-roca-2013-08-08
Reviewed rev. 09 (document currently at 13)
Review result Has Issues
Review completed: 2013-08-08



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.


One minor comment first: It is said that
   "Differences in playout time exceeding configured limits (e.g. more than
    ten seconds) could be an indication of such inconsistent information."
But it could as well be caused by a misbehaving receiver (e.g. with an
intermittent connection) who should better be removed from the destination
set altogether. So I wouldn't speak of "inconsistent information", but rather
"out of bound information" since this situation is "consistent" with the real

Then, using "configured limits" is necessary, sure, but not sufficient. What if
an attacker periodically reports values that are just below this configured
limit? They should be accepted whereas they will negatively impact the session.
And you cannot reduce indefinitely the configured limits.

A third comment. The document only mentions devices (in the example)
that report erroneous information. The problem is broader than that. The
attacker may also be on the route between a legitimate destination to the
source, and be able to alter the report message. Or the attacker may be 
able to forge a packet with erroneous information, masquerading as a
legitimate receiver. So it would be great to broaden the problem statement
with that in mind.

And then it quickly leads to the idea of message integrity verification (to
combat packet modification) and source authentication (to combat
masquerading). You should say something on it.

Of course, the same comments apply for the messages sent on the other
direction, from source to destinations.

A reference to SRTP is missing. Please add.

Finally, since everything depends on precise time synchronization, it should
be highlighted that having a secure time synchronization service is absolutely
required. Otherwise this is another potential means to attack the session.