Last Call Review of draft-ietf-fecframe-interleaved-fec-scheme-
review-ietf-fecframe-interleaved-fec-scheme-secdir-lc-kivinen-2009-12-09-00

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.

This document defines new RTP payload format for sending forward error
correction that is generated by the 1-D interleaved parity code.

The security considerations section refers to the generic RTP
(RFC3550) security considerations. It also mentions generic solutions
to different security problems (encryption for confidentiality,
integrity protection mechanism for integrity and authentication of the
source of the payload).

It does not list any specific mechanisms, but points to Secure
Real-time Transport Protocol SRTP (RFC3711), IPsec (RFC4301) and TLS
(RFC5246).

The only thing missing from the security considerations section is
that it should mention that the repair flow should require exactly
same security features that what is provided to the source flow. The
repair flow packets are xor of the multiple source flow packets, and
if those do not get exactly same confidentiality, integrity and
authentication of source protection then the original source flow
confidentiality, integrity or authentication of the source could be
compromized.

I.e. it is not acceptable for using for example AES, SHA2-256 to
protect source flow, but send repair flow without encryption and
without integrity protection, as when doing that attacker can replace
repair flow packets, and cause source flow packets to drop triggering
error correcting procedures on the receiver which will then use repair
flow packets having weaker security than source flow packets.
-- 
kivinen at iki.fi