Subject: RE: [Sipping] Facing Up to Realities in SIP Deployments in Carrie r networks

From: Richard Shockey <[email-masked]>
Date: Fri, 28 Feb 2003 17:03:59 -0500

At 03:16 PM 2/28/2003 -0500, Rosen, Brian wrote:
>Richard
>
>I don't think getting into speculation on what motivates carriers
>to deploy SIP is germane.

It is precisely germane... what motivates carriers is money, fear, greed 
and the economic benefits of one technology vs another, as well the 
regulatory environment they must live in.  This report is a classic version 
of whining why they do'n't want to deploy a superior form of technology 
when the real reasons are manifestly self evident to anyone who cares to 
read their balance sheets or understand the regulatory constraints many of 
them live with.

Most carriers are bankrupt, on the verge of bankruptcy, or worry about 
bankruptcy..and that includes US LEC's, major European PTT's and even  NTT 
in Japan as well ..

>What is germane is:
>·       If SIP-related standardization efforts has been slowing deployment.

IMHO no though the IETF does have it own unique ways of doing things the 
process for SIP has been successful and open.. unlike that of the ITU..and 
need I remind you how many years it took the ITU to produce anything in 
H.323 that resembled inter operability? That we have been able to produce 
as much as we have in as short a period of time and reverse the tide of 
technical opinion on H.323 is a near miracle and a testament to the 
Herculean work of SIP, SIPPING and SIMPLE WG's.

>·       If there are significant difficulties in interworking different
>vendors' products in laboratory trials of both SIP to SIP and SIP to legacy
>network element interoperability.

I cannot directly address the results of SIPit trials since my company does 
not directly have SIP products. I trust others can adequately address this 
issue.

>·       If Efforts to provide lawful intercept and emergency services will
>be hampered by the nature of SIP-based networks.

Our community is working on this and I believe we can deliver a better E911 
than is currently deployed.  At to the intercept issue .. geez I'm sorry 
..any ISP with a decent packet sniffer is already reading all of their 
traffic.... to the FBI, NSA , MI5 etal the Internet is the greatest bonanza 
for intercept ever created.. nothing is encrypted find the ports and you 
can get suck in  whatever you want.

NOT one ISP on the planet is not reading or sampling headers right now in 
order for them to optimize the route announcements on their network or make 
fundamental economic decisions about about how to transit or peer their 
traffic.

>·       If potential users have difficulty comparing products because
>everyone uses different scalability metrics

I'M SHOCKED I'M SHOCKED marketing guys devise smoke and mirrors to describe 
the features and  benefits of their products.

>·       If NAT and firewall traversal is a major issue limiting the
>deployment of SIP

Ok ..this is a problem .for consumer markets not for sensible enterprises 
that acquire their own routeable blocks of addreses. This is a larger 
problem of v4 vs v6 addressing we cannot solve here.

>·       If a standard framework for basic authentication and privacy of
>SIP-based communication is required

Privacy ... what privacy ...the entire signalling and media path is in the 
open but that does not seem to bother folks using SMTP.  I'd love 
opportunistic encryption of both the signalling and media paths but I've 
yet to see the problem adequately dealt with in email ..so  why is this 
suddenly a concern?

>·       If there are significant new security issues relating to:
>-       Interception of signaling and media traffic

M&M attacks sure ..

>-       Introduction of malicious traffic through open interfaces to SIP
>endpoints or other networks

Well Brian ..yes you are right on target here ..the last thing we need is 
open SIP "relays"

>-       The need to authenticate endpoints through insecure networks
>-       Securing network and service management interfaces based on open
>standards.
>
>Note that the above list is largely text lifted from the document.

but its exactly what a legacy bunch of  PPT bellheads would say .. thats my 
point..

>If I think through these issues, I think most of them are just flat out
>true.

Brian the simple problem effecting SIP deployment is much much larger..it 
goes to the heart of the current telecom meltdown and the implied threat 
that IP Communications has on carrier revenues. Once upon a time this was 
all a academic exercise to some service providers ...."oh yes this is very 
interesting we need to know more about blah blah" ..but times have changed 
and it is clear that from a purely revenue perspective VoIP is having a 
negative effect on TDM/SP revenues . VoIP dominated by H.323 now has 10% of 
the global market and has ripped 20 BILLION dollars out of the hands of 
International transport SP's.  The effect at the margin of SIP as it 
deploys in greenfield is amazing etc. Its effect on national LD rates is 
pronounced its clear ..at least in the US we are seeing the beginning of 
flat rate monthly distance free pricing, though I will submit that mobile 
is having a effect on these models as well.

I noted with some amusement the line in the document ..that there is no 
economic justification for deploying ENUM.  Well HELLO..... I've had this 
conversation .. the reply I got from a major US LEC I spoke to was  "OK 
what you are telling me enterprises are going to do this eventually but if 
I deploy this I'm going EBIDA negative in 24 months."

>It may be that some service providers don't care about them, but I think
>most will.

It depends on how high you sit on the PPT management food chain

>  I think that it is well worth our while to sort through this
>list and figure out if the problems can be solved, and how they should be
>solved.  It may be that IETF is not the right place to solve all of them.

Well I can tell you where they will be solved ....in the US it will be in 
either the bankruptcy courts or the FCC.

>Brian

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto:[email-masked]> or <mailto:[email-masked]>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Nilesh Trivedi <[email-masked]>
Date: Fri, 28 Feb 2003 17:54:10 -0500

You make some interesting and realistic points about carrier
deployments but are we trying to solve economical issues here ??

Brian, I understood that the goal of the paper you posted was
purely technological in nature since most of the points you made
addressed technical short-comings or issues the protocol is
trying to deal with.

More inline;

Richard Shockey wrote:

> than is currently deployed.

What community are you referring to ???

>  At to the intercept issue .. geez I'm sorry

I think the point was totally missed. Nobody disagrees to the sniffing that you
are pointing to but the point here is about creating specific holes in the
deployment
where the data can be specifically targetted for tapping and routed under the
covers. This is covered as CALEA and regulatory requirements which to my
knoweldge is still an issue with many SIP vendors out there.

The question if I have to rephrase is: Does not having LI infrastructure a
bottleneck
to SIP deployment thereby discouraging carriers to not go the SIP route ??

> problem of v4 vs v6 addressing we cannot solve here.

I disagree on both fronts. Where you say not a problem for enterprise, the fact
of the matter is that NAT/PAT issues boil down to edges and this applies for
all SIP deployments. Enterprises deal this with fronting thier border proxies
that solve the translation problems but it still is an issue. On the other side
of v4
and v6 addressing story, the reality is we are going to have v4 addresses for a
longer period of time than previously thought and for successful SIP
deployments,
we ought to address it right here and I believe the WG is already working to
find a common solution.