Last Call Review of draft-ietf-avtcore-idms-09
review-ietf-avtcore-idms-09-secdir-lc-roca-2013-08-08-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.

--

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
situation.

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.


Cheers,


   Vincent