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

From: James Kempf <[email-masked]>
Date: Tue, 16 May 2000 05:05:52 -0700

>Giuseppe Ricagni writes:
> >    * possible optimizations (e.g.: signalling for a basic call to an
>Australian
> >      fixed network number from an Italian mobile roaming to Australia could
>be
> >      processed locally, without any "tromboning")
>
>   If during call setup there needs to be a round
>   trip to the home network, it pretty much negates
>   any advantage of proxying the call locally. 
>

When you take roaming into account, there is an advantage. Suppose the
Italian now in Australia moves. If the home proxy is used, the network
has to go back to the home to roam. If a local proxy is used, there is
reduced latency. With a local proxy, you pay the round trip cost
to the home network just once.

In addition, some people have been talking about using SIP for other
kinds of in-call signalling. If the mobile has to go all the way
back to the home proxy, there is simply too much latency.

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

---

From: "Glenn Morrow" <[email-masked]>
Date: Tue, 16 May 2000 09:07:05 -0500

I don't believe people are opposed to the proposal by the security task
force for the basic public infrastructure. 

I believe the concern is the verbage wanting to get rid of support for the
other methods of security such as a separate encryption of headers and
values at the application level. 

The primary reason I see for this back-pressure being that the trust model
only goes so far for certain types of organizations and individuals. Please
take a look at say a STU-III terminal and it's requirements.

To remove these built-in mechanisms would undermine a rather significant
advantage of SIP over other signaling methods. 

Respectfully,

Glenn

++++++++++++++++++++++++++++

The problem with having 25 mechanisms for security is that the probability
of
being able to build a secure system goes down because different vendors make
different choices and thus we get non-interoperability and even the
probability of having any
solution implemented in a given instance goes down.
 
I would prefer to see one less than perfect solution that works most of the
time
then 25 solutions, each perfect for one kind of system.   The existing
mechanisms
aren't close to good enough for such a status.  There are already too many
options.
 
I don't really care what mechanism we choose as as long as we pick one,
and then really work towards getting everyone to implement it.  The present
situation,
which AFAIK there a precious few implementations, and does not provide an
adequate
level of security, is not satisfactory.  Augmenting it with lots more
alternatives is not 
satisfactory.
 
Brian

---

From: Jörgen Björkner <[email-masked]>
Date: Wed, 17 May 2000 15:23:05 +0200

The home proxy always should be within the signaling path, even though you
have roamed into another network. This is very important from a value added
service perspective. 

I have no opinion if is bad or not to force a client to signal through a
proxy in the visited network or not. There could be other reasons than
billing to do this, for example would the visited network do some logging,
or needs to route the messages through a SIP aware firewall. Note that I am
not proposing firewalls to be there, but some operators might want them... I
think that billing for media (i.e. voice) must be coupled to the transport
layer.

The reason to have the home proxy within the signaling path is to be able to
offer services that is invoked before the call is set up. One example is a
speed dial dial service that translates one request URI to something else
depending on a users preferences.

Is it correct for a UAC to add a route header to indicate to a proxy in the
visited network that it should forward the request to the home server?
Section 6.37 is a bit confusing since it says "The route request-header
field determines the route taken by a request..." I guess it should be
changed to "The route request-header field determines the route a request
will take..." since it not yet been routed this way when the field is added.

I have understood that some groups proposes a solution where the services is
downloaded to the visited network. The solution with downloaded services has
one severe problem, the fact that the execution environment must be
homogenous between the operators. This is very limiting for a operator that
want to distinguish himself and attract customers by providing creative
services, which is very important on todays competitive market. A successful
service might need to retrive information from an information system that
the users service provider has access to. This means that althouh the code
will be able to execute when it is downloaded to the visited network so will
the information that is needed not be accessible.

I don't think this would affect the call setup time in any significant way,
and users is today used to longer call setup times when the roam into
another operators network.

/Jörgen

-----Original Message-----
From: James Kempf
To: Michael Thomas; Giuseppe Ricagni
Cc: [email-masked]; [email-masked]; James Kempf; Michael
Thomas
Sent: 2000-05-16 14:05
Subject: Re: [SIP] Minutes of SIP Security task force in Adelaide

---

From: "Sinnreich, Henry" <[email-masked]>
Date: Mon, 22 May 2000 20:24:55 +0000

>That way, the market
>   decides rather than a bunch of standards
>   weenies

Wow Michael! The Internet is defined entirely by its standard protocols,
developed with great care by 'weenies', and not by 'market decides'
managers. We know a lot of protocols developed by 'market decides' managers
that are now history.

>>   view this as a bug, not a feature.
Actually, the portability of the service may seem very attractive to
customers, and is one of the SIP potential applications. I could upload my
preferences to the convenient service when on travel for example, to reduce
some costs. Also, I could change these preferences when on travel, so as to
adjust them to my changed needs. Enlightened service providers that allow
such conveniences may be preferred by customers.

My two cents, Henry

>From: Michael Thomas [mailto:[email-masked]]
>Sent: Monday, May 22, 2000 2:55 PM
>To: James Kempf
>Cc: [email-masked]; [email-masked]; [email-masked]
>James Kempf writes:
> > >   I don't know what services the roaming network
> > >   wants to provide -- other than trying to shoehorn
> > >   themselves into the call. Even if, there is nothing
> > >   to prevent me from obtaining those service even if
> > >   it's routed through my home proxy first.
> > >
> > 
> > 
> > What about having a standardized XML-based user profile description?
> > That way, the guy that wants to set up a telephony provider in
> > his garage can have the same access to a description of his
> > services as anybody else.
>
>   I think we have arrived at an impasse since I
>   view this as a bug, not a feature. A standardized
>   scheme always locks you to the least common
>   denominator when you want to remote the
>   features. That sounds like a shame to me; if I
>   run it through my home proxy, I can have as
>   many whacko features as I want to cook up
>   without having to convince the world that
>   they're a Good Idea. That way, the market
>   decides rather than a bunch of standards
>   weenies (present company excluded, yadda
>   yadda).
>
>		Mike
>
>

---

From: "Schroeder, Tim" <[email-masked]>
Date: Tue, 23 May 2000 11:13:22 -0500

James Kempf [mailto:[email-masked]] writes:
  The other thing a standardized user profile format would let me do is
  edit services on any  Web browser rather than have to call up the phone 
  company and wait for them change my service profile. 

That may be true, but a standardized user profile format certainly isn't
required to be able to edit services with a web browser!  
	
Tim Schroeder
[email-masked]
SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX  78759

---

From: "Sinnreich, Henry" <[email-masked]>
Date: Tue, 23 May 2000 16:22:36 +0000

>a standardized user profile format 
>certainly isn't

There may be outsourcing arrangements between service providers or with
resellers, where a standard user profile format is beneficial. The customer
may be an enterprise with thousands of individual users. If a change is
required in the OSS, entering it by hand in a web browser is a scary
proposition.

This is the reason why I believe the user profile should be machine
readable, in standard XML format.

Henry

>From: Schroeder, Tim [mailto:[email-masked]]
>Sent: Tuesday, May 23, 2000 11:13 AM
>To: [email-masked]
>Subject: RE: [SIP] Minutes of SIP Security task force in Adelaide
>
>