[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RTPSec BOF proposal for IETF 68




Cullen,

> I would like to get any comments on it.

IMHO, we need it.  We need that convergence around some smaller number of mechanisms.

My 2 cents,
Dan

--
Dan York, CISSP
Dir of IP Technology, Office of the CTO
Mitel Corp.     http://www.mitel.com
dan_york@xxxxxxxxx +1-613-592-2122
PGP key (F7E3C3B4) available for
secure communication




Cullen Jennings <fluffy@xxxxxxxxx>
Sent by: owner-ietf-rtpsec@xxxxxxxxxxxx

01/19/2007 01:28 PM

       
        To:        ietf-rtpsec@xxxxxxx
        cc:        
        Subject:        RTPSec BOF proposal for IETF 68





The IESG has received the following BOF proposal. I would like to get  
any comments on it.

Thanks, Cullen


>
> RTP Security (RTPSEC)
> ---------------------
>
> - Mailing list: http://www.imc.org/ietf-rtpsec/
>
> - BoF Session Chairs: Dan Wing, Russ Housley
>
> - Sponsoring AD: Cullen Jennings, RAI Area Director
>
>
> There are currently a large number of mechanisms defined or under
> consideration by the IETF to establish SRTP [RFC3711] keys between
> endpoints. Although an endpoint can implement several mechanisms, many
> of these mechanisms are intended to provide standalone solutions and
> these mechanisms are not interoperable with each other. The IETF needs
> to converge on a interoperable solution to this problem.
>
> At IETF 66 in Montreal the Security and RAI areas held a joint RTPSEC
> BOF in an attempt to converge on a set of requirements and broad
> architectural approach for attacking this problem. The results
> can be found in the minutes [0] of that meeting. In the time since
> Montreal, a fair amount of work has been done on various aspects
> of this problem. The purpose of this BOF is to come to agreement
> on an action plan for providing a complete solution.
>
> In Montreal there was broad consensus on the need for some form
> of media-plane key management protocol (MPKMP).
>
> The two major open issues are:
> 1. Whether (and how) the signalling needs to be coupled with
>    the MPKMP(s).
> 2. Which MPKMP(s) should be the basis for future work.
>
> Presentations should focus on architectural issues not technical
> details, which will be resolved in the appropriate WGs.
>
>
> Approximate Agenda
> ---------------------------------------------------------------------
> Chair       Agenda bash                                                                                                 5
> Chair       Summary of Montreal Discussion                                                      15
> Andreassen  Status of MMUSIC SDP negotiation work                  10
> All         Discussion of signalling/MPKMP relationship                                     30
> Zimmermann  ZRTP                                                   15
> McGrew      DTLS-SRTP                                              15
> Other protocols?...
> All         Discussion of which MPKMP(s) to proceed with?          30
> Chair/ADs   Wrap-up
>
>
> The expected outcome of this BOF is to resolve the above issues and
> to come to consensus on:
>
> - The set of work items which must be completed.
> - A work plan for each work item including where it will be performed.
>
>
> Background Reading:
> draft-wing-rtpsec-keying-eval-01.txt
> draft-wing-media-security-requirements-00.txt
> draft-ietf-mmusic-sdp-capability-negotiation-00.txt
> draft-zimmermann-avt-zrtp-02.txt
> draft-fischl-sipping-media-dtls-01
> draft-mcgrew-tls-srtp-00
>
>
> [0] http://www3.ietf.org/proceedings/06jul/minutes/rtpsec.txt
>
>
>