Re: [EME] Is this IMS?

[Hannes Tschofenig <[e-mail]>]

Hi Paul,

I assume that you wanted to reply to the mailing list...

Paul Francis wrote:
> This is quite a good question.  Here's my understanding.  IMS certainly aims
> to have SIP servers authorize flows, and have firewalls enforce the decision
> made by sip servers.  Looking at the 3gpp documents, I gather that there is
> the Go interface that allows the sip servers to tell the firewalls what holes
> to punch (as well as other things like accounting).   So clearly there are
> some common goals here with NUTSS.  But there are many differences:
>
> IMS keeps the host in the dark...with NUTSS we want the host to know what
> middleboxes are being inserted and why, and give it the option to negotiate
> that.
>   
In IMS there is also the option to obtain authorization tokens via SIP 
signaling that are then put into RSVP messages and signaled to the 
middlebox.
In NSIS we used the same concept (even the same token format) to 
authorize flows, as one option.

When it comes to negotiation and knowing what middleboxes are inserted 
then you might think what the purpose of that could potentially be.
Is it for debugging? You cannot seriously think that the end host as a 
particular preference for a particular middlebox. That does not sound 
like zero-configuration to me. Imagine I get a window which asks me 
"Which middlebox do you want to use today? A, B, or C" and then "So, 
what about the next middlebox after B? ..."

> NUTSS has broader goals.  First, it wants to apply to all data flows, not
> just media.

SIP is not only about the establishment of media traffic. You can setup 
any type of end-to-end communication.


>   It wants to be able to negotiate protocols, including security.
>   

Is this the negotiation between the end points?


> It wants to be able to steer packets through middleboxes not on the path (as
> requested either by the ends or by the middle).

You want to use something similar to source routing or QoS routing.

While these type of things make sense for an operator to perform traffic 
engineering it does not make that much sense for an end host.

>   It tries to encompass a wide
> range of topologies, including multi-homed to different domains (and
> including dealing with the assymetric paths that often result from this).
You can accomplish this using other ways as well, such as ICE. ICE would 
allow you to find a working path between the two end points but does not 
require you to select the path it goes through the network. From a 
deployment point of view that's obviously much nicer.
>   
>
> Besides all this, a goal certainly is to have a cleaner protocol.  IMS is
> trying to leverage legacy protocols into doing new things (SIP and COPS), and
> the result, while perhaps workable, isn't ideal.  Below is the paragraph from
> the sigcomm paper that comments on IMS.
>
> PF
>
>
> The other way is to define a protocol that allows the SIP server
> to coordinate with the firewall [32, 50]. This approach suffers from
> a similar problem which may be solved in a brute-force fashion
> by having the SIP server enable a given flow in all possible firewalls
> that the data flow may traverse.
I don't see this brute force approach. That stuff just works fine. You 
can either perform the authorization check without using Diameter 
interaction or you could use Diameter back to a server that created the 
tokens.


>  While in the common case (a
> dual-homed site) this may be reasonable if inefficient, it becomes
> unworkable in scenarios where there are many firewalls.

Why do you think so?

>  For instance,
> a widely replicated distributed firewall addressed as an IP
> anycast group might have hundreds or thousands of firewalls [14].
>   
Which environment has hundreds or thousands of firewalls?
Maybe it is a problem with the network deployment rather than a protocol 
problem.

I don't know reference [14].


Ciao
Hannes

> [32] MARSHALL, W. RFC 3133: Private Session Initiation Protocol
> (SIP) Extensions for Media Authorization , Jan. 2003.
>
> [50] TECHNICAL SPECIFICATION GROUP CORE NETWORK AND
> TERMINALS. 3GPP TS 29.207: Policy control over Go interface,
> Sept. 2005.
>  
>
>   
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:[e-mail]] 
>> Sent: Monday, June 18, 2007 3:24 PM
>> To: [e-mail]
>> Subject: [EME] Is this IMS?
>>
>> Hi all,
>>
>> I went through the requirements draft and the strawman proposal. 
>> Initially, I did not plan to comment because I just wasn't 
>> quite sure whether I misunderstood the entire proposal completely.
>>
>> When I first read the document then I got the impression that 
>> all this stuff already exists. I thought that you are 
>> replicating the 3GPP IMS work (without referencing it). The 
>> only difference I saw was that backup paths were established 
>> but I wasn't quite sure whether this is a good idea anyway.
>>
>> So, what is the new idea about combining SIP (name-based 
>> routing) with path-coupled signaling?
>>
>> Ciao
>> Hannes
>>
>> PS: I haven't read the recent HIP proposal 
>> http://saikat.guha.cc/pub/sigcomm07-nutss.pdf.
>>
>>
>> _______________________________________________
>> EME mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/eme
>>
>>     


_______________________________________________
EME mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/eme