[SIPForum-techwg] Avaya Contribution for SIPconnect 1.1

[Dan Wing]

Richard,

I do not believe that service provider equipment (B2BUAs, SIP proxies) needs
to do anything to enable enterprise-to-enterprise SRTP, as Francois wants to
allow, other than pass along the necessary "a=" lines and, if the media keying
happens over the signaling path, to not block it (that is, allow DTLS-SRTP or
ZRTP).  This is clearly implementable.

If service providers interfere with this, enterprises will route around the
service providers and federate directly with each other (using IPsec, SRTP, or
whatever they like) so that their business communications are protected from
industrial espionage.

-d


> -----Original Message-----
> From: techwg-bounces at sipforum.org 
> [mailto:techwg-bounces at sipforum.org] On Behalf Of Richard Shockey
> Sent: Monday, June 09, 2008 10:38 AM
> To: 'Francois Audet'; 'DOLLY, MARTIN C, ATTLABS'; 'Johnston, 
> Alan B (Alan)'; techwg at sipforum.org
> Subject: Re: [SIPForum-techwg] Avaya Contribution for SIPconnect 1.1
> 
> Does anyone have any idea how many service providers can 
> support SRTP now.  
> 
>  
> 
> What level of support is there for SRTP in the CSCF's ??  
> 
>  
> 
> What level of support do we plan on seeing within this decade?
> 
>  
> 
> I point this out since one of the stated goals of 1.1 is a 
> IMPLEMENTABLE specification.
> 
>  
> 
> From: techwg-bounces at sipforum.org 
> [mailto:techwg-bounces at sipforum.org] On Behalf Of Francois Audet
> Sent: Monday, June 09, 2008 11:55 AM
> To: DOLLY, MARTIN C, ATTLABS; Johnston, Alan B (Alan); 
> techwg at sipforum.org
> Subject: Re: [SIPForum-techwg] Avaya Contribution for SIPconnect 1.1
> 
>  
> 
> It could be for both, although really, SRTP is end-to-end. So 
> if a service provider doesn't find it necessary to support in 
> its media gateways, then it won't be used.
> 
>  
> 
> The major point is that before you use SRTP-only, you really 
> need to make sure that everybody in the network supports it 
> because calls will fail otherwise. In practical deployment 
> today, it is generally not feasible. Therefore, you really 
> need a way to "turn off" SRTP-only as it is likely to be 
> deployed only in specialized applications. The "best-effort 
> SRTP" using media negotiation will be very useful because 
> it's designed to be backward compatible.
> 
>  
> 
> IPsec vs TLS/SRTP is not an "either/or". IPsec is just 
> securing the access network, not end-to-end media. If a 
> service provider wishes to use IPsec at the access, it's ok. 
> We should probably say something about it in the document. 
> It's a good point. I can see that there will be many cases 
> where, for example, the service provider will require IPsec 
> at the access, but enterprises may want to use SRTP end-to-end.
> 
> 	 
> 
> ________________________________
> 
> 	From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly at att.com] 
> 	Sent: Saturday, June 07, 2008 07:02
> 	To: Audet, Francois (SC100:3055); Johnston, Alan B 
> (Alan); techwg at sipforum.org
> 	Subject: RE: [SIPForum-techwg] Avaya Contribution for 
> SIPconnect 1.1
> 
> 	Francois,
> 
> 	 
> 
> 	So, is SRTP intended within a enterprise and between 
> the same corporate campuses only, or is it also intended to 
> be used toward a service provider?
> 
> 	 
> 
> 	And the same question for mandating TCP/TLS?
> 
> 	 
> 
> 	We would prefer using IPsec for interconnection.
> 
> 	 
> 
> 	Martin
> 
> 	 
> 
> ________________________________
> 
> 	From: techwg-bounces at sipforum.org 
> [mailto:techwg-bounces at sipforum.org] On Behalf Of Francois Audet
> 	Sent: Friday, June 06, 2008 1:21 PM
> 	To: Johnston, Alan B (Alan); techwg at sipforum.org
> 	Subject: Re: [SIPForum-techwg] Avaya Contribution for 
> SIPconnect 1.1
> 
> 	Hi Alan,
> 
> 	 
> 
> 	This is great. Lots of useful material in there.
> 
> 	 
> 
> 	Here are a few comments:
> 
> 	*	I like the connected identity addition. This 
> will be quite useful. 
> 	*	I like the new section on media security. I 
> think we need to be a little more explicit on the "Always 
> SRTP" implications of your text (i.e., the call will fail if 
> both ends do not support SRTP, and therefore use with 
> caution). I think we could address it by having a sub-section 
> for "Always SRTP" and another one for "Best-Effort SRTP". I 
> could provide some text for the "Best-Effort SRTP" section 
> providing guidance on the use of 
> draft-ietf-mmusic-sdp-capability-negotiation (which should be 
> RFC by the time SIPConnect 1.1 is done). 
> 	*	I like the way you are handling Presence and IM 
> support. I think this is exactly how we should treat it.
> 	*	It would be nice to explain that the reason 
> PUBLISH is not supported at this time is that it's normally 
> used within the domain of the enterpise (i.e., you could move 
> it to the next paragraph that talks about resource lists, 
> XCAP, watcher info.
> 
> 		 
> 
> ________________________________
> 
> 		From: techwg-bounces at sipforum.org 
> [mailto:techwg-bounces at sipforum.org] On Behalf Of Johnston, 
> Alan B (Alan)
> 		Sent: Friday, June 06, 2008 08:25
> 		To: techwg at sipforum.org
> 		Subject: [SIPForum-techwg] Avaya Contribution 
> for SIPconnect 1.1
> 
> 		All,
> 
> 		 
> 
> 		Here is a contribution from Avaya for 
> SIPconnect 1.1.  In some areas it is more 2.0 than 1.1 but it 
> really is quite a lot of work to revise the specification, 
> and to do so but add little of interest or value could be a 
> mistake.  For example, we propose adding secure media and 
> presence exchange to SIPconnect.
> 
> 		 
> 
> 		     
http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,146/
Itemid,75/
> 
> 		 
> 
> 		Comments are most welcome.
> 
> 		 
> 
> 		Thanks,
> 
> 		Alan
> 
>