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

["Elwell, John" <[e-mail]>]

Peter,

I could not locate the particular requirements in the referenced document, which does not seem to have a Requirements section as such. Please cite the particular requirements that answer my questions and point to the section/paragraph where rationale for those requirements is given.

The Internet Draft will need to be enhanced to give more rationale for requirements, rather than rely on reference to a relatively large external document that allegedly has requirements hidden somewhere within it.

Thanks,

John 

> -----Original Message-----
> From: Leis, Peter (NSN - DE/Munich) [mailto:[e-mail]] 
> Sent: 20 May 2010 10:05
> To: Elwell, John; ext Hadriel Kaplan; Dawes, Peter, VF-Group; 
> [e-mail]
> Subject: RE: [dispatch] New I-D: 
> draft-dawes-dispatch-mediasec-parameter-01
> 
> hello,
> 
> sorry for the late reply.
> 
> The requirments for media-plane security in 3GPP IMS have been defined
> in TS 33.328 http://www.3gpp.org/ftp/Specs/html-info/33328.htm . 
> 
> For SDES SRTP there are two modes defined, one is end2end and one is
> end2accessedge. We need to provide a solution for both modes.
> 
> And for end2accessedge we do have a requirement that the UE knows
> whether or not the network (P-CSCF) will support SDES-SRTP before the
> session takes place as described below.
> 
> Peter
> 
> > -----Original Message-----
> > From: ext Elwell, John [mailto:[e-mail]] 
> > Sent: Friday, May 07, 2010 4:17 PM
> > To: Leis, Peter (NSN - DE/Munich); ext Hadriel Kaplan; Dawes, 
> > Peter, VF-Group; [e-mail]
> > Subject: RE: [dispatch] New I-D: 
> > draft-dawes-dispatch-mediasec-parameter-01
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: [e-mail] 
> > > [mailto:[e-mail]] On Behalf Of Leis, Peter 
> > > (NSN - DE/Munich)
> > > Sent: 03 May 2010 14:32
> > > To: ext Hadriel Kaplan; Dawes, Peter, VF-Group; [e-mail]
> > > Subject: Re: [dispatch] New I-D: 
> > > draft-dawes-dispatch-mediasec-parameter-01
> > > 
> > > 
> > > comments inline 
> > > 
> > > > -----Original Message-----
> > > > From: ext Hadriel Kaplan [mailto:[e-mail]] 
> > > > Sent: Friday, April 30, 2010 5:47 PM
> > > > To: Leis, Peter (NSN - DE/Munich); Dawes, Peter, VF-Group; 
> > > > [e-mail]
> > > > Subject: RE: [dispatch] New I-D: 
> > > > draft-dawes-dispatch-mediasec-parameter-01
> > > > 
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Leis, Peter (NSN - DE/Munich) 
> [mailto:[e-mail]]
> > > > > Sent: Friday, April 30, 2010 4:17 AM
> > > > > To: Hadriel Kaplan; Dawes, Peter, VF-Group; [e-mail]
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: ext Hadriel Kaplan [mailto:[e-mail]]
> > > > > > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dispatch
> > > 
> > 
>