Subject: RE: [MMUSIC] FW: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp- 00.txt

From: "Elwell, John" <[email-masked]>
Date: Thu, 07 Sep 2006 08:03:04 +0100

Francois,

Perhaps you misunderstood my proposal.

My proposal was similar to that in your draft, except that we have an a=srtp
line to say "if you understand this, please interpret rtp/avp as rtp/savp".
Then the crypto information can be either at media level or at session
level. This would get around my concern about lack of support for session
level crypto parameters. It would not get around my other concern about
MIKEY options that do not rely on waiting for an SDP answer to arrive before
rendering media.

However, reading between the lines I think you prefer to move forward with a
BCP RFC rather than a standards track RFC, and my proposal above would
indeed require a standards track RFC. But I hope you can see that it is a
lot simpler than the sdp-cap proposal.

John

> -----Original Message-----
> From: Francois Audet [mailto:[email-masked]] 
> Sent: 06 September 2006 22:02
> To: Elwell, John; Hadriel Kaplan; [email-masked]
> Subject: RE: [MMUSIC] FW: I-D 
> ACTION:draft-kaplan-mmusic-best-effort-srtp- 00.txt
> 
> Hi John,
> 
> You shouldn't keep quiet ;^)
> 
> I'm not against the idea. I'm just thinking that it would 
> end-up looking
> very similar to sip-cap, since in order to be backward compatible, the
> whole SRTP component would have to be "prefixed" with some some of
> attribute to make it invisible to a UA that doesn't unserstand SAVP.
> But maybe I'm wrong.
> 
> I'd even encourage you to write a draft on it. I can even help.
> 
> I'd be very happy to see all the various proposal on the table, so we
> can
> finally pick one. I'm really not attached to any one in particular.
> 
> 
> 
> > -----Original Message-----
> > From: Elwell, John [mailto:[email-masked]] 
> > Sent: Wednesday, September 06, 2006 1:35 PM
> > To: Audet, Francois (SC100:3055); Hadriel Kaplan; [email-masked]
> > Subject: RE: [MMUSIC] FW: I-D 
> > ACTION:draft-kaplan-mmusic-best-effort-srtp- 00.txt
> > 
> > Francois,
> > 
> > I am supportive of trying to solve this problem quickly. I 
> > was just pointing out some shortcomings of the proposal and 
> > making sure that we have explored all reasonable alternatives 
> > that might close some of these shortcomings. In the absence 
> > of support I will keep quiet.
> > 
> > John 
> > 
> > > -----Original Message-----
> > > From: Francois Audet [mailto:[email-masked]]
> > > Sent: 06 September 2006 19:53
> > > To: Elwell, John; Hadriel Kaplan; [email-masked]
> > > Subject: RE: [MMUSIC] FW: I-D
> > > ACTION:draft-kaplan-mmusic-best-effort-srtp- 00.txt
> > > 
> > > I'm not sure I agree.
> > > 
> > > The sdp-cap proposal was a "usage" of an existing RFC. 
> > > 
> > > While it may be "more complex" from a theoretical point of 
> > view, the 
> > > process of standardizing yet another SDP extension to do 
> this seems 
> > > much more "complex"
> > > from a procedural point of view.
> > > 
> > > This group has an appetite for making seamingly simple problems 
> > > complex.
> > > I do not
> > > see why this particular one wouldn't expand to be just as 
> > "complex" as 
> > > the sdp-cap proposal when we are done with it.
> > > 
> > > As I stated in Montreal, what really bothers me about this is the 
> > > unresponsiveness of the IETF in providing a mechanism for 
> > supporting 
> > > best-effort backward-compatible SRTP.
> > > 
> > > We are at a point now where the industry is way ahead of 
> > the standard.
> > > Implementors have
> > > been working on this particular item for 2-3 years now. 
> > Implementors 
> > > don't understand why IETF can't make up our mind on such 
> a trivial 
> > > problem.
> > > 
> > > The consequence of this is a proliferation of ways to do 
> > best-effort 
> > > SRTP. They mostly are variations of either port 
> > overloading, multiple 
> > > ports and
> > > AVP+crypto/kmgmt.
> > > Mostly not interoperable obviously.
> > > 
> > > We are very close to a point of losing our relevance. 
> > > 
> > > <<<<rant off>>>>
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Elwell, John [mailto:[email-masked]]
> > > > Sent: Tuesday, September 05, 2006 11:40 PM
> > > > To: Audet, Francois (SC100:3055); Hadriel Kaplan; 
> [email-masked]
> > > > Subject: RE: [MMUSIC] FW: I-D
> > > > ACTION:draft-kaplan-mmusic-best-effort-srtp- 00.txt
> > > > 
> > > > I think it's a lot simpler, addressing this particular 
> problem of 
> > > > SSRTP versus RTP.
> > > > 
> > > > John
> > > > 
> > > > > -----Original Message-----
> > > > > From: Francois Audet [mailto:[email-masked]]
> > > > > Sent: 05 September 2006 21:43
> > > > > To: Elwell, John; Hadriel Kaplan; [email-masked]
> > > > > Subject: RE: [MMUSIC] FW: I-D
> > > > > ACTION:draft-kaplan-mmusic-best-effort-srtp- 00.txt
> > > > > 
> > > > > 
> > > > > > It is a question of whether a new RFC, perhaps 
> defining a new 
> > > > > > attribute, would be worthwhile in terms of gaining a larger 
> > > > > > catchment of legacy devices with which we can fall 
> > back to RTP.
> > > > > 
> > > > > 
> > > > > How is that any different from the sdp-cap proposal in 
> > Montreal? 
> > > > > 
> > > > 
> > > 
> > 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 7 Sep 2006 13:49:16 -0500

> My proposal was similar to that in your draft, except that we 
> have an a=srtp line to say "if you understand this, please 
> interpret rtp/avp as rtp/savp".

Yes, I had indeed completely misinterpreted your proposal. I tought you
wanted an a= line AND a separate m line for SRTP and RTP (like sdp-cap).

> Then the crypto information can be either at media level or 
> at session level. This would get around my concern about lack 
> of support for session level crypto parameters. 

There would probably have been other ways to address this particular
problem, but it probably makes it cleaner.

I guess your proposal makes it slightly cleaner in general. I think
I like it.

> It would not 
> get around my other concern about MIKEY options that do not 
> rely on waiting for an SDP answer to arrive before rendering media.

Correct. I don't believe there is a solution to that problem, except
using the in-band mechanism that RTPSEC has been talking about. This
proposal is designed to be forward compatible with that.

> However, reading between the lines I think you prefer to move 
> forward with a BCP RFC rather than a standards track RFC, and 
> my proposal above would indeed require a standards track RFC. 
> But I hope you can see that it is a lot simpler than the 
> sdp-cap proposal.

Actually, I don't mind if it is BCP or standards-track. 

Maybe we can put your idea into a revision to our draft as a possible
improvement.

Hadriel, what do you think?

Anybody else?

> > I'm not against the idea. I'm just thinking that it would end-up 
> > looking very similar to sip-cap, since in order to be backward 
> > compatible, the whole SRTP component would have to be 
> "prefixed" with 
> > some some of attribute to make it invisible to a UA that doesn't 
> > unserstand SAVP.
> > But maybe I'm wrong.
> > 
> > can finally pick one. I'm really not attached to any one in 
> > particular.
> > 
> > 
> > 
> > > I am supportive of trying to solve this problem quickly. 
> I was just 
> > > pointing out some shortcomings of the proposal and making 
> sure that 
> > > we have explored all reasonable alternatives that might 
> close some 
> > > of these shortcomings. In the absence of support I will 
> keep quiet.
> > > 
> > > John
> > >

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 8 Sep 2006 21:09:57 -0400

Sorry, didn't see this email (our mail system apparently decides some mmusic
email is spam :)

Yeah I misunderstood it as well - I also thought a second m= line was
involved.

-hadriel

> Sent: Thursday, September 07, 2006 2:49 PM
> Subject: RE: [MMUSIC] FW: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-
> 00.txt
> 
> > Francois,
> >

---

From: Randell Jesup <[email-masked]>
Date: Fri, 22 Sep 2006 19:44:31 -0400

>MIKEY options that do not rely on waiting for an SDP answer to arrive before

Here's some stuff I discussed privately to Hadriel/etc (we've been going back
and forth on this a bit for a while).  ">>" (and ">>>>") quoted stuff is me.

Since this is long, I'll highlight the point I make at the very end about
early media:

>>>I don't think the IETF will allow us to send the receive keys. :(
>>
>>Then IMHO distinguishing between SRTP and RTP is almost meaningless - you
>>can't decode SRTP anyways until you see some sort of answer with the
>>algorithm, auth length, MKI, master key, etc.  And if you have the answer,
>>you don't need to distinguish.
>>
>>So the only issue is whether you decode/play RTP packets which appear
>>before an answer.  This can happen in RTP or SRTP in the case of a slow
>>signalling channel or a dropped packet.  You'll never decode an SRTP packet
>>before you see the answer anyways.  Solving this does have some benefit,
>>though not a huge one.  If we don't solve it, the receiver will be clipped
>>until the answer is received in both cases (RTP and SRTP); if we solve it
>>(with transmit keys), the clipping will remain for SRTP.

That highlights why some form of offering receive keys is critical if early
media support is of any interest.  (This includes delayed 200 OK due to
path issues, dropped packets on the signalling channel, TCP retry on
SIP-TLS, etc.)  Perhaps there's some way you can offer receive keys as a
temporary measure...

Ok, here goes:

>>>   4. Advertising Unique Payload Types 
>>>      
>>>     The basic concept is for the offerer to advertise unique (dynamic) 
>>>     payload types be used for SRTP, for each RTP equivalent payload 
>>>     type. 
>>>      
>>>     The advantages are it is highly unambiguous, it is do-able for a 
>>>     BITW, it is probably more acceptable to the IETF (or at least 
>>>     easier to work around RFCs), and it has no impact on packet size. 
>>>      
>>>     The disadvantages are it doesn't handle SRTCP, it may not work 
>>>     through Firewalls/SBCs/etc., and it can result in a lot of payload 
>>>     types needing to be looked for by the offerer. 
>>
>>Again, SRTCP can be handled via auth checking.  Why wouldn't it work
>>through firewalls/SBCs?  If the payload was advertised in the m= line, the
>>firewall/SBC should let it through unmolested.  
>>
>>>     The editor personally likes this approach, but is worried if adds 
>>>     too much complexity. Also, SRTCP support is important, but we 
>>>     could define PT's for SRTP-protected SR/RR, or we could use the 
>>>     mechanism proposed for the MKI option - namely, assuming the last 
>>>     octets are an Authentication tag and if it passes, it is SRTCP, 
>>>     else it's RTCP, until the answer is received. 
>>
>>Right.  RTCP auth is required anyways, and min 10 bytes, so collision risk
>>is 1/2^80.

>From much much later (there were a lot of options we were considering):

>>One possibility:
>> m=audio 12345 RTP/AVP 0 8 99 100
>> a=savp:99=0 100=8
>>Or:
>> m=audio 12345 RTP/AVP 0 8 99 100
>> a=rtpmap:99  SRTP/8000
>> a=rtpmap:100 SRTP/8000
>> a=savp:99=0 100=8
>>
>>Or:
>> m=audio 12345 RTP/AVP 0 8 99 100
>> a=rtpmap:99  PCMU/8000
>> a=rtpmap:100 PCMA/8000
>> a=savp:99 100
>>
>>Note we could use variants of these to negotiate SAVPF and AVPF as well,
>>for added benefit.
>>
>>a) If they strip attributes as well, we're not going to be negotiating keys
>>anyways
>>b) I can't begin to think of how many things attribute-stripping could break
>>
>>I can understand (though not like) them stripping payloads they don't want
>>you to use (bandwidth).  A bit like some gateways (such as in Bangladesh)
>>refusing to do G.711 for bandwidth reasons.  If so - oh well, you won't be
>>doing SRTP.  If we use a=savp:, then the callee might select the "wrong"
>>PCMU payload type if the attribute is stripped (shouldn't, but might).  If
>>we use a=rtpmap:99 SPCMU/8000 (for example), then some SBCs might strip
>>the payload.
>>
>>I notice that a=rtpmap for dynamic PTs is a "SHOULD" not a "MUST".
>>(RFC4566 5.14).  Doesn't really help in practice.
[snip]
>>This is my favorite algorithm also, IF you have to support no- or
>>small-auth cases.  If you don't have to handle them (or for 4-byte auth if
>>1/2^32 error rate is ok), just check auth.  That avoids the issue with the
>>accidental bid-down.

Another proposal (mentioned above) is to use a test of "if it passes auth,
it's SRTP, else RTP":

>>If it passes auth, then it's pretty likely to be good.  This depends on the
>>length of the auth tag though - auth tags are variable-length themselves!
>>For SRTP, it can be as small as 0, or 4 bytes, or 10, or larger.  As RFC
>>3711 points out, a 4-byte auth could be hit randomly by an attacker in
>>1/2^32 packets (once in 994 days of 20ms packets).  For SRTCP, RFC3711 says
>>the auth tag should be no smaller than 10 bytes, but it could be larger.
>>
>>You still have an issue if you want to use a tag length of 0 (or very small
>>values like 1) for SRTP.  And (assuming 4-byte auth) is 1/2^32 chance of a
>>collision; using default auth length (80 bits), it's vanishingly small.
>>You could recommend using auth for a codec with variable-length payloads.
>>I'm a little unclear on what the MKI value would be, and how unlikely that
>>would be to collide.
>>
>>Possible DoS issue: hitting a UA with packets that don't include auth could
>>cause a UA to lock into RTP mode.  This could also happen from "left over"
>>packets from a previous session.  We'd need to warn against "locking in".
>>
>>Vulnerability in using MKI: MKI isn't encrypted (of course) but it also
>>isn't authenticated.  I'm not sure this matters...

And a later message I wrote:
>>>> Note that any discussion here of early media is based on using receive
>>>> keys; without them we can't decode anything, we don't know the auth
>>>> length, auth/crypto algorithm (f8?), etc.
>>>
>>>True, but the proposal for adding an MKI/Auth would be to use a default
>>>value.  But good point on auth - essentially if it "passes" then
>>>presumably you already have the answer. :)
>>
>>For Auth, yes, modulo the no-auth or very-small-auth cases.  For MKI, the
>>chance of collision is probably much higher.  But how do you even know how
>>long the MKI is without the answer, unless you use receive-keys?
>>
>>>I should have mentioned it wouldn't actually be the final/real
>>>authentication value, just one of a well-known value. 
>>
>>Well, that's very different.  That falls into the same case as MKI, which
>>may well have a much higher collision rate.  And then it's not "auth" and
>>it's not RFC3711, and you've opened it up to injection of "evil" packets.
>>And if you use a fake MKI, then you can't use a real MKI.
>>
>>>I don't think the IETF will allow us to send the receive keys. :(
>>
>>Then IMHO distinguishing between SRTP and RTP is almost meaningless - you
>>can't decode SRTP anyways until you see some sort of answer with the
>>algorithm, auth length, MKI, master key, etc.  And if you have the answer,
>>you don't need to distinguish.
>>
>>So the only issue is whether you decode/play RTP packets which appear
>>before an answer.  This can happen in RTP or SRTP in the case of a slow
>>signalling channel or a dropped packet.  You'll never decode an SRTP packet
>>before you see the answer anyways.  Solving this does have some benefit,
>>though not a huge one.  If we don't solve it, the receiver will be clipped
>>until the answer is received in both cases (RTP and SRTP); if we solve it
>>(with transmit keys), the clipping will remain for SRTP.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)