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

 

> -----Original Message-----
> From: dispatch-bounces@ietf.org 
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Leis, Peter 
> (NSN - DE/Munich)
> Sent: 03 May 2010 14:32
> To: ext Hadriel Kaplan; Dawes, Peter, VF-Group; dispatch@ietf.org
> Subject: Re: [dispatch] New I-D: 
> draft-dawes-dispatch-mediasec-parameter-01
> 
> 
> comments inline 
> 
> > -----Original Message-----
> > From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com] 
> > Sent: Friday, April 30, 2010 5:47 PM
> > To: Leis, Peter (NSN - DE/Munich); Dawes, Peter, VF-Group; 
> > dispatch@ietf.org
> > Subject: RE: [dispatch] New I-D: 
> > draft-dawes-dispatch-mediasec-parameter-01
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Leis, Peter (NSN - DE/Munich) [mailto:peter.leis@nsn.com]
> > > Sent: Friday, April 30, 2010 4:17 AM
> > > To: Hadriel Kaplan; Dawes, Peter, VF-Group; dispatch@ietf.org
> > > 
> > > > -----Original Message-----
> > > > From: ext Hadriel Kaplan [mailto:HKaplan@acmepacket.com]
> > > > Sent: Thursday, April 29, 2010 6:59 PM
> > > >
> > > > Right, but I'm trying to figure out why that is.  I mean
> > > > what's the reason the UA needs to know at Registration time
> > > > that it's next-hop b2bua can do srtp, instead of letting SDP
> > > > handle it?
> > > >
> > > > I *think* the answer is so that it can later send an INVITE
> > > > with an SDP offer without failing the request - is that 
> > the reason?
> > > 
> > > Right
> >  
> > OK, and I also agree that's a real problem.  That issue was 
> > raised in the IETF in 2006/2007.  There was a very simple 
> > proposal to avoid that, in 
> > draft-kaplan-mmusic-best-effort-srtp, but the decision of the 
> > MMUSIC WG was to instead use 
> > draft-ietf-mmusic-sdp-capability-negotiation to accomplish 
> > it.  That draft is now in the RFC editor's queue.  I know 
> > it's a lot of processing overhead, but that was the decision. 
> >  And I think 3gpp has put support for that into some 
> release or other.
> > 
> 
> The requirement in 3GPP is, that the UE has to know whether or not the
> network (P-CSCF) will support SDES-SRTP before the session 
> takes place,
> if it wants to employ End2AccessEdge media plane security. This will
> ensure that the IMS UE shares the media keys only with the P-CSCF and
> not with some other entity. 
[JRE] Why would the UE "want to employ End2AccessEdge" media plane security, as opposed to E2E media plane security? I would have thought the UE would always prefer the latter. Furthermore, the UE should not use keys that have value outside this particular communication session, so if they get passed on beyond the P-CSCF, no harm is done. In fact, if they reach the remote UA, you can end up with E2E security, which would be great from the UE's perspective.

> In addition, in 3GPP there is a 
> requirement
> that the UE knows whether media plane security is established between
> itself and the network (i.e. End2AccessEdge), or whether media plane
> security is established between itself and the far end. 
[JRE] That would be interesting to know, but it is a more general problem - any B2BUA can terminate SRTP, and SIP does not provide any mechanism to indicate whether SRTP is truly end-to-end or just end-to-some-B2BUA. Also a gateway to TDM will terminate SRTP, and SIP does not provide any means of indicating whether SRTP is truly end-to-end or end-to-first-TDM-gateway.

John

> 
> As you said, CapNeg has a lot of processing overhead, and in addition,
> it does not solve the requirements I have listed.
> 
> 
> > 
> > > > > RFC 3840 does only cover UA indicating support, but not SBC
> > > > indicating
> > > > > support.
> > > >
> > > > Actually, in a way it does.  An SBC is a B2BUA.  As a UA, it
> > > > can indicate feature tags.  What it *can't* do is indicate it
> > > > in the REGISTER response it sends to the UA.  But the UA
> > > > could send an OPTIONS to the B2BUA and get it in a feature
> > > > tag of the response to the OPTIONS.  I know it sucks to send
> > > > more SIP messages, but I don't see how to avoid that and be
> > > > consistent with the SIP architecture.  It's really weird for
> > > > a REGISTER response to indicate media capabilities of the 
> > Registrar.
> > > 
> > > use of OPTIONS was discussed, but due to the additional 
> > signalling, it
> > > was discarded.
> > 
> > Considering all of the other signaling already required 
> > (subscription to reg-event, subscription to presence, xcap, 
> > possibly subscription to Config server) isn't an OPTIONS just 
> > a nit at this point?  And that way this could be a general 
> > solution, instead of a 3gpp-specific one.
> > 
> > 
> > > The indication of network support for SDES-SRTP in response 
> > to REGISTER
> > > is not included by the registrar, but by the network 
> > element placed at
> > > the edge (the SBC/B2BUA)
> > 
> > I know, but from the UA's perspective the REGISTER response 
> > is coming from the Registrar, possibly through proxies.  
> > There's no logical/conceptual model in the IETF for a 
> > REGISTER response to indicate media capabilities of some 
> > middle hop of the REGISTER.
> > 
> > -hadriel
> > 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>