Re: [secdir] Review of draft-ietf-fecframe-interleaved-fec-scheme-05

["Ali C. Begen (abegen)" <[e-mail]>]

Hi Tero,

Thanks for the review. Yes, we should add that to the document, which is something I tend to do in the next revision.

Cheers, acbegen.

> -----Original Message-----
> From: Tero Kivinen [mailto:[e-mail]]
> Sent: Monday, December 07, 2009 8:01 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; fecframe-
> [e-mail]
> Subject: Review of draft-ietf-fecframe-interleaved-fec-scheme-05
> 
> 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.
> --
> [e-mail]