On Sep 13, 2005, at 8:22 AM, Theo Zourzouvillys wrote:


few reasons of the top of my head that the IMS probably chose to do this:

* to assign an S-CSCF to the user, which is needed for further messages

Only because they chose to assign the S-CSCF at registration time, because that's when GSM assigns the MSC. There are other large SIP networks quite happily using a different serving-proxy binding scheme.

* for grabbing the filter criterion from the HSS, which are needed to route
   further messages.

See above.

* roaming, where the P-CSCF is located in a visited network - for ensuring
   the user is allowed to roam with that identity.

Per-request authorization in the home network (or another "strong identity mechanism") could provide the same, without requiring the transitive-trust-over-IPSEC model of IMS, where the P-CSCF learns (from the REGISTER response) about allowed identities and routes, and proceeds to enforce them on behalf of the home network. It could be argued that this model induces several of the most significant attack opportunities on IMS, and it certainly wouldn't have passed IESG security review. For example, any compromise of operational security in the visited network (like a bad employee in a foreign network who can't be prosecuted by the home network operator) opens the window for difficult or impossible to track toll fraud. Telco networks run on inter-company trust, and it usually works great -- but it only takes one or two bad apples to create a big mess. Hence the need for IETF to define limited-scope "P-header" extensions for IMS -- we think they're suitable for use in heavily-insured limited-liability environments, but we're not quite ready to trust them with our secret Swiss account numbers or our secret formula for predicting stock prices and Superbowl winners (Hint: It won't be Dallas this year).


I initially thought "what the hell" when reading through the IMS spec, but am now starting to appreciate the reasons things have been done the way they have while deploying a scarily large SIP network while keeping resources to a
sane level



No doubt, IMS is now quite deeply thought-out and documented in amazing detail. It's a huge body of work, with a lot of clever, even brilliant thinking having gone into it. Of course, it contains a few things I would have done differently . . . then again, so do most of the plays of William Shakespeare, and I'm not a noted playwright.

But like Shakespeare's plays (as well as those of lesser mortals) usually do, it will take a few productions to iron out the bugs in IMS. We're still waiting for that first off-Broadway show and hoping not too much rotten fruit gets thrown at the cast.

--
Dean

_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to