Re: [EME] Is this IMS?

Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Mon, 25 June 2007 12:49 UTC

Return-path: <eme-bounces@irtf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2o07-0002ND-Me; Mon, 25 Jun 2007 08:49:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2o06-0002N8-Tx for eme@irtf.org; Mon, 25 Jun 2007 08:49:02 -0400
Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2o04-0000gP-5T for eme@irtf.org; Mon, 25 Jun 2007 08:49:02 -0400
Received: (qmail invoked by alias); 25 Jun 2007 12:48:58 -0000
Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp037) with SMTP; 25 Jun 2007 14:48:58 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+Jt05tYRCJ+z2D065fLVdEoK56cFy4OVkx4nQsUG SegW7NPYveajw5
Message-ID: <467FB9B9.6020708@gmx.net>
Date: Mon, 25 Jun 2007 14:48:57 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Paul Francis <francis@cs.cornell.edu>, eme@irtf.org
Subject: Re: [EME] Is this IMS?
References: <E6F7A586E0A3F94D921755964F6BE006C980C7@EXCHANGE2.cs.cornell.edu>
In-Reply-To: <E6F7A586E0A3F94D921755964F6BE006C980C7@EXCHANGE2.cs.cornell.edu>
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 28aa4dc616a7f0ac0889ef522e9e39ef
Cc:
X-BeenThere: eme@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: end-middle-end research group <eme.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/eme>
List-Post: <mailto:eme@irtf.org>
List-Help: <mailto:eme-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1341623437=="
Errors-To: eme-bounces@irtf.org

Hi Paul,


Paul Francis wrote:
> yes, I meant to reply to the list.
>
>   
I guess you want to post this mail to the list as well.

> Comments inline.  
>
> Though as a meta-comment, please forgive me to the extent that I am not
> up-to-date on IMS, NSIS, SIP, and the rest of it.  Keeping up with that stuff
> is a full-time job.

I agree it is not simple to keep an eye on all these activities.

>   Indeed, one of the reasons for doing something like this
> in IRTF is to get the IMS/NSIS/SIP expertise to throw in their 2-cents, and
> hopefully produce a clean and simple version of where IMS/NSIS/SIP are slowly
> lurching.  Note too that the EME charter is to take a fresh look at this set
> of requirements, do a "clean" design, but then to see to what extent existing
> protocols can be exploited to implement that design.
>   
I think that this needs to be highlighted a bit more in the current work.
You might want to investigate why existing stuff is too complex.

> Indeed, as I read your email, I can imagine two ways to react to EME.  One is
> to say "Oh, all these other protocols (SIP, RSVP, DIAMETER, NSIS, ICE, just
> to list the things you mention...) taken together do this stuff one way or
> another, so why bother with a new design?"   I gather that this is your
> position???

I am currently leaning towards this position considering the amount of 
work that was spend on these protocols and the deployment chance that 
some of these protocols might see. I also tried to extend currently 
deployed protocols, such as done with HIP SIP (but HIP is, to be fair, a 
little bit away from widespread deployment).


>   Another way to react is "Wow, multiple groups of folks are
> trying to cobble together a bunch of protocols to do something they weren't
> really designed to do.  Maybe we ought to step back and see what a clean
> design to all this looks like."  This is where EME RG is coming from.
>   
But you need to understand that I would appreciate a structured approach 
whereby it is clear why existing approaches are problematic.
No doubt, there are problems with existing approaches.



More below:

> PF 
>
>   
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
>> Sent: Tuesday, June 19, 2007 3:13 AM
>> To: Paul Francis; eme@irtf.org
>> Subject: Re: [EME] Is this IMS?
>>
>> 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.
>>     
>
> I wasn't aware of this (for IMS or NSIS).

For NSIS this is described in 
http://tools.ietf.org/wg/nsis/draft-manner-nsis-nslp-auth-03.txt

The following two documents are relevant:

[RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session 
Authorization Policy Element", RFC 3520, April 2003.

[RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session 
Set-up with Media Authorization", RFC 3521,

>   In particular, my understanding of
> NSIS was that it is primarily an on-path approach.
Well. The concept of path-coupled and path-decoupled is somewhat a 
philosophical question particularly when you consider that NSIS (and 
RSVP) need to interact with other protocols.

For NSIS there is even an path-decoupled extension:
http://tools.ietf.org/html/draft-hancock-nsis-pds-problem-04

In an EU funded project, called Ambient Networks, NSIS was extend to 
provider routing based on FQDNs. I will try to find the public document.


> Where does the token come
> >from in NSIS? 
There is currently one specification available that allows you to obtain 
the token via SIP. The NSIS specifications do, however, not need to 
mandate where it comes from.

I also suggested to obtain and use SAML assertions in
http://www.tschofenig.com/drafts/draft-tschofenig-enroll-bootstrapping-saml-02.txt

The basic idea is that document is to obtain a SAML assertion during the 
network access authentication procedure and then to re-use it

There are, however, many other possibility. I suggested essentially 
everything but unfortunately most people don't care too much about 
security and so all my proposals died. This is not a sad thing as such 
since this is a architectural aspect (in some sense) and when people 
would use RSVP and NSIS in the real world then these questions will come 
up again.



>  Also, could you point me to the IMS document that talks about
> the auth tokens?   
>   
I will ask my co-workers since they know the references much better than 
I do.


>   
>> 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? ..."
>>     
>
> Policy is never zero-conf!  But it certainly doesn't have to include the user
> (and rarely would).  For instance, a better example would be one where
> vendors of email virus checking software compete for customers.  So, the
> vendor (say) gives you a piece of software that sets the registry variables
> in your OS so that your email app has its connections steered to one of their
> virus checking boxes...
>   

This is a good example that shows where the problems with the suggested 
approach start. This type of application layer functionality would be 
much better done at a higher layer since the semantic at lower layer is 
missing and everything just becomes a hack.

>   
>>> 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.
>>     
>
> Sure, but SIP has mainly been and still mainly is about media.  (And IMS
> means "IP Multi-media Subsystem.)  We'd like to step away from that a bit and
> consider a protocol that is purely about setting up connections (5-tuple
> flows), and not about setting up "calls".
>   

For some reason SIP has attracted more people from the voice community 
than from other communities. This is already changing with some new work.
For example, consider the following draft

http://www.ietf.org/internet-drafts/draft-garcia-sipping-general-events-00.txt

>   
>>     
>>>   It wants to be able to negotiate protocols, including security.
>>>   
>>>       
>> Is this the negotiation between the end points?
>>     
>
> End-points and middle.  
>
>   
Got it now.

>>     
>>> 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.
>>     
>
> We never suggested that an end-host should do traffic engineering.  QoS or
> traffic engineering per se is not really part of the EME charter.  
>
>   
But the step towards is a small one.
For example, when the end host wants to select a certain middlebox then 
they might want to have a reason for doing so. Just picking a middlebox 
due to the name isn't that exciting.
One good reason could be that the quality along a different path is 
better (whatever the quality criteria might be).

>>>   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.
>>     
>
> If by "deployment" you mean "backwards compability", I absolutely agree.
>
>   
By deployment I was more considering how to incrementally make the 
functionality available.

>>>   
>>>
>>> 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.
>>     
>
> Point taken.  The current NUTSS document avoids the extra interaction between
> middlebox and policybox (two such interactions if the paths are assymetric),
> but there are certainly pros and cons to these two approaches.  
>
>   
You might want to perform this interaction with the policy box for other 
reasons anyway. For example, credit control (charging).

>>     
>>>  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?
>>     
>
> No, you are right.
>
>   
>>>  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].
>>     
>
> Reference 14 refers to a DDoS defense infrastructure that has many
> middleboxes.  Granted, not the common case...
>
>   

Ciao
Hannes

> PF
>
>   
>> 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:Hannes.Tschofenig@gmx.net] 
>>>> Sent: Monday, June 18, 2007 3:24 PM
>>>> To: eme@irtf.org
>>>> 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
>>>> EME@irtf.org
>>>> https://www1.ietf.org/mailman/listinfo/eme
>>>>
>>>>     
>>>>         
>>     


_______________________________________________
EME mailing list
EME@irtf.org
https://www1.ietf.org/mailman/listinfo/eme