Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide

From: James Kempf <[email-masked]>
Date: Wed, 17 May 2000 05:06:36 -0700

>
>   Question: isn't it the case that the roamed 
>   system needs to do a database dip on the
>   home system to get their subscriber
>   information? If so, even in the current
>   situation, you have a round trip to the home
>   system. This is why I'm extremely dubious that
>   there is any substantial difference in call
>   setup time. The same would be true in the scenario
>   you propose: in order to proxy my service onto
>   the roamed proxy, it would need to do some
>   database dip back to my home proxy to find out
>   my features. If I routed it through my home
>   proxy, it looks like it would actually be
>   *faster* because I'd only need to go through
>   my home proxy rather than
>   foreign-proxy->database-dip-at-home->routing.
>

With the proper security association, the subscriber profile could be forwarded
to the roamed proxy, avoiding the round trip back to the home proxy. This
actually would be a *big* saving from the current cellular networks, where
the remote VLR has to go back to the HLR every time. I've seen some research
work on this for current circuit switched, but it is crufty. It is lots
easier to do it with an all IP network, provided the proper AAA protocols
are in place.

> > I don't have
> > the numbers for intercontinental routing delays in my head but I can
> > believe they must be more than routing delays to a local ISP. 
>
>   Speed of light on fiber is about 20ms/1000miles 
>   as I recall.
>

That's transport. There's also routing. What's the queueing delay?

> > Your web server at home is leveraging off the fact that a company,
> > probably AT&T back when they had a monopoly, strung a wire to your
> > house and installed switching equipment at the local office. They made the
>infrastructue
> > investment years ago that now allows you and your ISP to offer service
> > really cheaply.
>
>   And I bow before New Jersey twice daily
>   to give thanks to Bell above. 
>
> > The UK government just auctioned off UMTS licenses for something like $25B
> > (as in 1 with 9 zeros behind it). Anyone who is not able to come up
> > with that kind of cash will have a hard time offering wireless 
> > telephony service. It will take years to amortize that kind of investment.
> > Of course, there is always the unlicensed spectrum and I'm sure there
> > will be players like Metricom who figure out creative ways to utilize it.
>
>   Oh, please. Let's keep track of where the actual
>   investment is here: it's the air resources and 
>   the raw bandwidth it enables. There's an
>   incremental delta for the switching equipment,
>   but that's by and large the same equipment as
>   landline. This doesn't seem very hard to me:
>   if it's expensive to put bits in the air, then
>   you charge for it. Let's not get taken down the
>   path that the only viable business model for a
>   bandwidth provider is to have monopoly access
>   to the services I can access.
>

It's not a monopoly, but there are very few companies in the world that are
in the position to plunk down $5B or so for a UMTS license. And governments
aren't offering many. It is partially the nature of the radio spectrum
(too many users leads to interference) and partially business politics
as usual.

>   That's the same mentality that didn't invent the
>   Internet. The same Internet which dramatically
>   demonstrates that there are other business
>   models which can turn a tidy profit being a
>   boring unintelligent network operator. If there
>   are good engineering reasons, fine. But
>   please lets not get sucked into bad engineering
>   design driven by old world business models.
>
> > Cellular companies already have romaing agreements. There's nothing new
>about
> > it. 
>
>   I know they do, and my understanding is that
>   feature transparency is one thing that suffers
>   big time because of their current model. 
>   Keeping my features back where I get my 
>   features eliminates that feature synch
>   problem at its root. That is impossible in
>   the circuit switched world, but almost trivial
>   in the SIP world.
>

If features can be easily forwarded between proxies (with the proper
authentication) then it's even easier to get your features whereever
you want them.

> > >   I think we have to demonstrate that there
> > >   are legitimate performance concerns before we
> > >   solve for them.
> > >
> > 
> > Agreed.
>
>   I think what might be useful rather than another
>   round of impassioned polemics here is to see
>   some message flows, paying particular attention
>   to any hidden assumptions about what the home
>   network needs to provide.
>

Agreed! Putting numbers on message flows would answer the question. 
>		 Mike
>
>
>_______________________________________________
>SIP mailing list
>[email-masked]
>http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Michael Thomas <[email-masked]>
Date: Wed, 17 May 2000 11:10:04 -0700 (PDT)

> authentication) then it's even easier to get your features whereever

   That is a monumentally large "if". I know
   of no system which has solved that
   satisfactorily on any reasonable scale.
   Throwing in trust boundaries, and different
   competing vendors installations is just gravy.
   I'd claim that this is an intractible
   problem. Some people might believe that 
   this is solvable, but I remain extremely
   skeptical. IMO, the best way to deal with
   intractible problems is to steer well clear
   of them.

	Mike