[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [MMUSIC] Thinking about best-effort encryption
> You'll get very significant pushback from nework operators because
> of increase demand on proxies.
>
> It also means that it's unsecure at answer time.
Er, I don't think so. If you offer RTP/SAVP, and it's rejected by the
answerer (called party), the called party's phone won't ring at all.
> It's a valid mechanism, but I don't think it's the best we can do.
Due to HERFP, I consider re-inviting a mechanism that cannot work. Unless
we fix HERFP or deprecate forking.
> I think IKR is right: we need to answer the very basic question
> about do we "HAVE to use SAVP" to mean best effort.
>
> The draft that Hadriel and I did assume "No".
> Flemming's draft assume "Yes".
A correction: both drafts put RTP/AVP in the "m=" line.
The offer in draft-andreasen-mmusic-sdp-capability-negotiation-01.txt, on
page 16, is here (I show the interesting lines with "**"):
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
** m=audio 3456 RTP/AVP 0 18
a=sqn: 0
** a=cdsc: 1 audio RTP/AVP 0 18
** a=cdsc: 3 audio RTP/SAVP 0 18
a=capar: 1 a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32
a=pcfg: c=3,4 a=1
a=pcfg: c=1,2
The answer is described and shown on page 17:
Bob receives the SDP offer from Alice. Bob supports RTP, but not
SRTP, and hence he accepts the potential configuration for RTP
provided by Alice:
v=0
o=- 24351 621814 IN IP4 128.96.41.2
s=
c=IN IP4 128.96.41.2
t=0 0
** m=audio 4567 RTP/AVP 0 18
a=acfg: c=1,2
-d
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@xxxxxxxxx]
> > Sent: Thursday, November 02, 2006 2:17 PM
> > To: EKR
> > Cc: ietf-rtpsec@xxxxxxxxxxxx; mmusic@xxxxxxxx
> > Subject: Re: [MMUSIC] Thinking about best-effort encryption
> >
> > While doing an update or reinvite may seem inelegant, I think
> > it makes reasonable sense for the best effort mode. It
> > certainly solves some problems regarding early media.
> >
> > Paul
> >
> > EKR wrote:
> > > As people will recall, in the RTPSEC meeting in Montreal
> it became
> > > clear that we needed some way to support best-effort encryption.
> > > Loosely speaking, it seems to me that there are two major
> > ways to do this:
> > >
> > > - Have nothing in the signalling and probe in the media plane
> > > as ZRTP does in bump in the wire mode.
> > > - Have something in the offer that says "I will speak SRTP"
> > > but doesn't require it.
> > >
> > > There have been a bunch of different suggestions about how
> > to do this
> > > (draft-andreasen-mmusic-sdp-capability-negotiation-01,
> > > draft-kaplan-mmusic-best-effort-srtp-01,
> > draft-zimmermann-avt-zrtp-02,
> > > etc...). Regardless of which key management protocol we
> ultimately
> > > choose, we need to sort the fundamental architectural issue of:
> > >
> > > Does the signalling (SDP) have to reflect RTP/SAVP?
> > >
> > >
> > > If the answer to this question is "Yes", then we either need to:
> > >
> > > 1. Have some convenient way to offer multiple profiles (Flemming's
> > > draft surveys the space of options here).
> > > 2. Do an UPDATE with RTP/SAVP for every secure connection. I get
> > > the impression people find this distasteful.
> > >
> > > If the answer is "No", then you can simplify the
> > offer/answer exchange
> > > by having the signal that you will do security in an
> a-line, but at
> > > the cost of having the profile no longer reflect what's
> on the wire.
> > >
> > > In either case, it seems like deciding this architectural
> issue is
> > > something we need to do before we spend a lot of time
> > discussing the
> > > details of mechanisms.
> > >
> > > -Ekr
> > >
> > > _______________________________________________
> > > mmusic mailing list
> > > mmusic@xxxxxxxx
> > > https://www1.ietf.org/mailman/listinfo/mmusic
> > >
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic@xxxxxxxx
> > https://www1.ietf.org/mailman/listinfo/mmusic
> >