ietf
[Top] [All Lists]

Re: [AVTCORE] Last Call: <draft-ietf-avt-srtp-not-mandatory-14.txt> (Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution) to Informational RFC

2013-12-09 16:16:49

On Dec 5, 2013, at 4:12 PM, Roni Even 
<ron(_dot_)even(_dot_)tlv(_at_)gmail(_dot_)com> wrote:

Cullen,
Let's say hypothetically that the AVTcore WG will propose and get consensus
that for RTCweb usage the security mechanism MUST use SDES for key exchange,
do you see this as a binding recommendation for RTCweb? The selection was
done by RTCweb and not by AVTcore.

I was pushing more on the privacy / confidentiality for RTP vs the keying, so 
more SRTP than SDES. 



The document does not say that there should be no security but says that it
is up to the usage or a for a decision. The security option document provide
the information about the different security options available and where
they are used.

Roni Even

-----Original Message-----
From: avt [mailto:avt-bounces(_at_)ietf(_dot_)org] On Behalf Of Cullen 
Jennings
(fluffy)
Sent: 05 December, 2013 6:57 PM
To: ietf(_at_)ietf(_dot_)org
Cc: avt(_at_)ietf(_dot_)org WG
Subject: Re: [AVTCORE] Last Call:
<draft-ietf-avt-srtp-not-mandatory-14.txt>
(Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single
Media Security Solution) to Informational RFC


Given the hum in the IETF plenary at the last IETF, I no longer think this
document represents IETF consensus. Given the hum in RTCWeb working group,
I doubt this represents the consensus of the RAI area either.

I think I would be tempted to resolve this by saying for each different
scenario
RTP is used in (SIP, RTSP, Mulitcast etc) exactly how it needs to be
secured and
for scenarios not listed such as new usages, what the requirements are.
For
something like SIP, having just one way to secure RTP is much better than
having many ways.



On Nov 22, 2013, at 3:07 PM, The IESG <iesg-secretary(_at_)ietf(_dot_)org> 
wrote:


The IESG has received a request from the Audio/Video Transport Core
Maintenance WG (avtcore) to consider the following document:
- 'Securing the RTP Protocol Framework: Why RTP Does Not Mandate a
Single
 Media Security Solution'
<draft-ietf-avt-srtp-not-mandatory-14.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2013-12-06. Exceptionally, 
comments may
be sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain 
the
beginning of the Subject line to allow automated sorting.

Abstract


 This memo discusses the problem of securing real-time multimedia
 sessions, and explains why the Real-time Transport Protocol (RTP),
 and the associated RTP Control Protocol (RTCP), do not mandate a
 single media security mechanism.  Guidelines for designers and
 reviewers of future RTP extensions are provided, to ensure that
 appropriate security mechanisms are mandated, and that any such
 mechanisms are specified in a manner that conforms with the RTP
 architecture.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory/ball
ot/


No IPR declarations have been submitted directly on this I-D.


_______________________________________________
Audio/Video Transport Core Maintenance avt(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Core Maintenance
avt(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/avt



<Prev in Thread] Current Thread [Next in Thread>