Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01

From: "Dawes, Peter, VF-Group" <[email-masked]>
Date: Thu, 27 May 2010 15:45:39 +0200

Hello James,
I think the scenario you have in mind is 

UA1 <-----------> SBC/B2BUA1 <-------------> Core Network
<----------->SBC/B2BUA2 <-------> UA2

I guess that your suggestion is that media plane security runs between
UA1 and UA2 and that SBC/B2BUA1 and SBC/B2BUA2 should have the security
keys in order to perform lawful intercept. This end-to-end scenario is
possible, and lawful intercept can work as you described in such a
scenario.

However, the scenario for draft-dawes-dispatch-mediasec-parameter-01 is
that media plane security runs between UA1 <-----------> SBC/B2BUA1 and
is decrypted by SBC/B2BUA1 before continuing in the direction of UA2. 

Lawful intercept is not the only reason that 3GPP did not adopt
DTLS-SRTP. Middleboxes that block the media path until the caller
receives 200 OK also make security setup in the media path unuseable
because they cause a period of silence while media plane security is
being set up, which is why the draft describes exchange of media plane
security capabilities at registration. 

Regards,
Peter

Message: 1
Date: Wed, 28 Apr 2010 16:24:55 -0500
From: "James M. Polk" <[email-masked]>
Subject: Re: [dispatch] New I-D:
	draft-dawes-dispatch-mediasec-parameter-01
To: Paul Kyzivat <[email-masked]>,	"DRAGE, Keith (Keith)"
	<[email-masked]>
Cc: "Dawes, Peter, VF-Group" <[email-masked]>,
	"[email-masked]" <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 12:26 PM 4/28/2010, Paul Kyzivat wrote:

>DRAGE, Keith (Keith) wrote:
>>The underlying way this works is described in:
>>http://www.3gpp.org/ftp/Specs/html-info/33328.htm
>>Search for "a2ae" for the relevant bits of text.
>>The first hop device is in fact a B2BUA with media, where it needs to 
>>implement these procedures.
>
>This is the key thing I was suspecting.
>If it needs to be a B2BUA for this to work, then talking about it as a 
>proxy is inappropriate.
>
>         Thanks,
>         Paul
>
>>The general use case for these procedures would seem to be where you 
>>have an access technology that is not secure in itself, but needs some

>>level of security therefore provided. So WLAN uses accessing 3G would 
>>use it, but 3G users would not,

this makes it appear in an SBC role (which does always receive the
media) more than a B2BUA role (which doesn't always (i.e., perhaps
rarely) receive the media).

If this is agreed to, then this can be more of an e2e scenario in which
DTLS-SRTP can be used, in which the P-CSCF has the decryption keys for
the media - thus able to meet the requirements for LI that the IETF
cannot address, per RFC 2804, as Adam stated already.

I'm also not completely clear now SRTP can be used at all in this
scenario, given the scenario assumes that SRTP breaks the requirements
for LI capture. Thus, isn't this doc advocating a mandate that
(effectively) "there shall be no SRTP between the UE and the first hop
proxy (that really isn't a proxy) because it breaks the LI requirements
that 3GPP wants to address (that the IETF can't)"....

this appears curious at best

James

>>because the underlying bearers are already security protected to an
extent.
>>I'll leave Peter to discuss how much more introductory material should

>>be in the document, but this at least will hopefully help you 
>>understand what is happening.
>>regards
>>Keith
>>>-----Original Message-----
>>>From: [email-masked] [mailto:[email-masked]]
>>>On Behalf Of Paul Kyzivat
>>>Sent: Wednesday, April 28, 2010 2:30 PM
>>>To: Dawes, Peter, VF-Group
>>>Cc: [email-masked]
>>>Subject: Re: [dispatch] New I-D: 
>>>draft-dawes-dispatch-mediasec-parameter-01
>>>
>>>Peter - a question:
>>>
>>>Dawes, Peter, VF-Group wrote:
>>>>Hello All,
>>>>An updated draft is available on the topic of providing
>>>security for
>>>>the media plane between a SIP client and its first-hop proxy
>>>(http://www.ietf.org/id/draft-dawes-dispatch-mediasec-paramete
>>> >> r-01.txt).
>>>>This draft defines a "mediasec" header field parameter and
>>>a "mediasec"
>>>>option tag to extend RFC 3329 "Security Mechanism Agreement for the 
>>>>Session Initiation Protocol (SIP)" to apply to the media plane.
>>>I am confused about the concept of "security for the media plane 
>>>between a SIP client and its first-hop proxy".
>>>
>>>A proxy has no involvement with media. I read through the draft to 
>>>understand better, but didn't gain enlightenment there. In fact I 
>>>found no mention of proxies at all. However I did find that the 
>>>mechanism only applies in cases where there is a single Via header, 
>>>which means the server must be one hop removed from the client.
>>>
>>>So I haven't been able to discern if this is just a matter of the 
>>>first hop from the client enforcing a requirement that media security

>>>be used between the UAC and UAS, or if there is some expectation that

>>>the proxy will in fact control the receipt and encryption/decryption 
>>>of the media.
>>>
>>>That might have been clearer if the examples showed the SDP.
>>>
>>>         Thanks,
>>>         Paul
>>>_______________________________________________
>>>dispatch mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/dispatch
>_______________________________________________
>dispatch mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dispatch

------------------------------

Peter Dawes
Group R&D
 
Tel: +44 (0)7717 275009
Fax: +44 (0)1635 234873

E-mail: [email-masked]
 
www.betavine.net  - Web
betavine.mobi  - Mobile Web
 
Vodafone Group Services Limited
Registered Office: Vodafone House, The Connection, Newbury, Berkshire
RG14 2FN Registered in England No 3802001

Regards,
Peter