Skip to main content

Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution
draft-ietf-avt-srtp-not-mandatory-16

Discuss


Yes

(Adrian Farrel)
(Richard Barnes)
(Robert Sparks)

No Objection

(Alexey Melnikov)
(Gonzalo Camarillo)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)

Note: This ballot was opened for revision 08 and is now closed.

Dan Romascanu Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2010-08-24) Unknown
This document does a good job in building the case that SRTP is not universally fit as a security solution for all use cases of RTP. I have however a couple of issues with two sections in the document that I would like to be discussed before I can approve the document: 

1. The last application scenario listed in Section 3 says: 

>  Finally, the link layer may be secure, and it may be known that the
   RTP media data is constrained to that single link (for example, when
   operating in a studio environment, with physical link security).  An
   environment like this is inherently constrained, but might avoid the
   need for application, transport, or network layer media security.

I do not believe that this is relevant in a discussion about securing an IETF protocol. BCP 61 (RFC 3365) Section 6 is very clear in that: 

>  One of the continuing arguments we hear against building security
   into protocols is the argument that a given protocol is intended only
   for use in "protected" environments where security will not be an
   issue.
...
   The solution is that we MUST implement strong security in all
   protocols to provide for the all too frequent day when the protocol
   comes into widespread use in the global Internet.

I suggest to take out this case as irrelevant

2. I am confused about what section 5 tries to say. First I do not know the term 'framework protocol' - this needs to be defined or referred to. What the section seems to say is that for that category of protocols (where RTP belongs) the strong security is more an application issue, where an application may be built of several building blocks, out of which the protocol is only one of them. This seems again to question or even justify an extemption from the requirements of BCP 61 [RFC3365] for RTP or even a whole class of protocols.
Tim Polk Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2010-08-26) Unknown
Note: This is a joint discuss from both Security ADs.  Given the importance of this
document, we are both holding a discuss position so we can participate in the
discussion that follows.

We accept the basic premise of this document: as a “framework protocol”, applying
BCP 61 directly and mandating a single security solution is not appropriate and
would not achieve the goal of BCP 61: ensuring that security mechanisms are
implemented (and thus available) even if it is not turned on in every deployment.
However, we do not believe the proposed solution (leaving the selection to each
application of RTP) is any more likely to achieve that goal.  In most actual deployments,
RTP is basically not secured.  Allowing a thousand flowers to bloom practically 
guarantees that real deployments will not include security mechanisms (since there
is so little prospect of code re-use and many current deployments won’t turn it on.)

To meet the spirit of BCP 61, we recommend that the working group consider the
following approach: specify a small set of solutions that cover the major classes of
applications, and mandate implementation of the appropriate solution for each RTP
application.  RTP application standards would be required to justify a mandatory to
implement security scheme that does not fall within this set.  We believe this solution 
provides the best opportunity to achieve the goals of BCP 61 for RTP-based applications.
Adrian Farrel Former IESG member
Yes
Yes () Unknown

                            
Jari Arkko Former IESG member
Yes
Yes (2010-08-24) Unknown
This is a very much needed document, well written, and makes IMO the
right conclusions.

I did have two issues, however, but decided to place a Yes vote as
opposed to holding a discuss. I do want to talk about these topics
on the IESG telechat, however.

The first issue is that in Section 4 MIKEY is ruled out as mechanism for supporting situations where the SIP infrastructure is untrusted. I do not understand why this is being done. MIKEY can provide end-to-end authentication, which would seem to thwart attacks where SDES would
clearly fail. Can this exclusion be elaborated and/or removed?

The second issue relates to the main recommendations. The documents
makes the argument that RTP applications are so diverse that they can
not live under the same security solution. However, I am left wondering
whether there would be mandatory-to-implement security solutions for
specific applications. Do the authors for some reason believe that is
not feasible or undesirable? Should there be IETF activities started
on making such requirements for specific applications?
Richard Barnes Former IESG member
Yes
Yes (for -14) Unknown

                            
Robert Sparks Former IESG member
Yes
Yes () Unknown

                            
Stephen Farrell Former IESG member
(was Discuss) Yes
Yes (2012-11-19 for -11) Unknown
Many many thanks for working through this. We finally got it!
Alexey Melnikov Former IESG member
No Objection
No Objection () Unknown

                            
David Harrington Former IESG member
No Objection
No Objection (2010-08-25) Unknown
I support Russ's DISCUSS
Gonzalo Camarillo Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
No Objection
No Objection (2010-08-23) Unknown
Section 3., paragraph 4:
>    [ETSI.TS.102.474], where one mode of operation uses ISMAcryp
>    (http://www.isma.tv/specs/ISMA_E&Aspec2.0.pdf) to encrypt the RTP
>    payload data only.

  Nit: It'd be better to refer to this URL as a reference.


Section 4., paragraph 9:
>    authentication solutions that are tied into the key manangement.

  Nit: s/manangement./management./
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection (for -09) Unknown

                            
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection (2012-11-20 for -11) Unknown
I cleared.  Thank you for working through this.
Stewart Bryant Former IESG member
No Objection
No Objection () Unknown