[SIPForum-techwg] Avaya Contribution for SIPconnect 1.1

Dan Wing dwing at cisco.com
Mon Jun 9 20:36:49 EDT 2008 

> My curiosity was about enterprise to SP where the SP its theoretically
> terminating on the PSTN.

But nobody can predict, prior to sending the Invite, if the call is
going to terminate on the enterprise or on a service provider's PSTN
gateway.  Call forwarding (from your office number to your home number)
is a good example where you can't 'know'.

> Do the carrier proxy platforms support SRTP?

As in, do they remove a=crypto or a=fingerprint, or break DTLS-SRTP
or ZRTP?  I dunno; it depends on how they are configured, I am sure,
and they could be configured to permit those attributes or to block
them.

I know Cisco makes PSTN gateways that support SRTP, and I bet a beer
that others do to (Avaya and Nortel would be high on my list, as they
already support SRTP on their IP PBXs, too).

-d


> I agree any attempt at by at SP to interfere with an enterprise to
> enterprise SRTP stream would "not be a good idea".
> 
> >  
> >  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
> >  >
> >  >
>

More information about the techwg mailing list