Jiri, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Jiri Kuthan > Sent: 29 March 2009 14:38 > To: Francois Audet > Cc: [email protected] > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > Francois Audet wrote: > > I think our views are not that appart. > > > > See belows. > > > >> -----Original Message----- > >> From: Jiri Kuthan [mailto:[email protected]] > >> Sent: Saturday, March 28, 2009 13:02 > >> To: [email protected] > >> Cc: Audet, Francois (SC100:3055) > >> Subject: francois' comments and why RFC4474 not used in the field > >> > >> As we were running out of time in the meeting, I wanted to > >> follow up on an argument which Francois has made: RFC 4474 > >> works if the identity provider and verifiers are "next to > >> each other", thus we have no problem with this RFC. > >> > >> /* hope I didn't misinterpret, let me know should that be > the case */ > > > > First part is currect, but I didn't say "thus we have no > problem with > > this RFC." > > > > As you say, it only works if the identity provider and the > verifier are > > "next to each other". A federation of Enterprises for > example. Or between > > service providers. > > > > However, one of the most predominant model today doesn't > work like this. > > A domain is often relying on a third party, a "service provider". > > > > So it's really not "end-to-end". That was the point I was > trying to make. > > > > RFC 4474 appears to work fine for end-to-end identity: > unfortunately, > > many deployment models (perhaps the majority) and in fact, > not end-to-end, > > but mediated. In a typical scenario, each end would have it's own > > "service provider", so 2 intermediaries. > > > >> I'm worried this is only a wishful thinking. While perfectly > >> logical, still even in such constrained setups some bizzar > >> ALGs do in my experience appear in the middle, change SDP and > >> make thus the identity worthless. > > > > Yes, I agree 4474 doesn't work if there are intermidiaries. > > > >> I think the bottom line is the protocol is not really end-to-end. > > > > EXACTLY! > > > > > >> It makes quite some assumptions about the quality of > >> underlying network (particularly about not changing SDPs) as > >> opposed to trying to deal with lack of it. In fact, SDP > >> payloads are changed at quite a number of devices: proxy > >> servers, B2BUAs, SBCs, you name it. Assuming there is nothing > >> in the way which won't change SDP is just NOT ROBUST. > >> > >> Other way to look at it is it is function overloading. You > >> ask for identity and get message integrity -- consequently > >> when the latter fails, the former, which you really initially > >> wanted, fails too. ekr's argument is certainly right that a > >> message of certain origin but uncertain content is close > to worthless. > >> OTOH, the particular piece, IP address and port numbers in > >> SDP are certainly not to be covered by a message integrity checks. > >> In fact, for accepting calls based on who is calling, as a > >> minimalistic application example, one does not need message > >> integrity. > >> > >> In conclusion, I do not think that RFC4474 can be of any help > >> (other than in controlled environments which beats its > >> purpose) as long as IP/port in SDP are message-integrity-protected. > > Thanks for the clarifications. I think we are on the same page then. > > > > > Here is what I think: > > > > RFC 4474 can work in the following situations: > > > > 1 - Enterprise-to-Enterprise: i.e., the network as a dumb > pipe. The enterprises > > have their own SBCs modifying SIP/SDP (or they can use ICE). > > > > 2 - Subscriber on Service provider A to Subscriber on > service provider B: > > i.e., the "domain" for the first subscriber is actually > that of the subscriber. > > This can work for "residential users" and small enterprises. > > > > 3 - Any permutation of the above. > > > > In all those cases, there is effectively end-to-end > > > > RFC 4474 does NOT work if it's not end-to-end. For example, if > > the "Enterprise" has it's own domain, but it relies on it's > > service provider to perform a number of functions. NAT traversal, > > topology hiding, etc. > > > > So, what can we do? I see 2 possibilities: > > > > 1 - Make it end-to-end. This means tackling one by one the > problem areas. > > Use TURN/ICE instead for relying on SDP payload > manipulation. Use > > Call-ID and Contact headers that don't reveal topology, etc. > > > > 2 - Create a non end-to-end Identity assertion mechanism > that is different > > from RFC 4474 and more secure than P-Asserted-Identity. > I have a > > feeling that it won't be trivial. We may have to define the > > trust relationship between the ends and the intermediaries. > > > > What I was trying to say in the meeting is that for "end-to-end > > identity", 4474 appears to work. But if the problem we are trying to > > solve is NOT end-to-end identity, but strong mediated > identity, then, > > let's just say so. It's just a DIFFERENT problem to solve. > > Well, I'm afraid that 1 is too complicated to work. Bringing > TURN/ICE to > work is already quite an enterprise, and as much success I wish to it, > I would be careful and avoid dependency on it (which is generally > a good protocol design practice anyhow). > > 2 is then probably the safer direction to me. The point is really that > RFC4474 is not having as broad applicability as we have hoped, and > leaving SIP without Identity is going to be real-time irritating, > compared to convenience of Email's off-line irritation. > > Some of the RFC 4474 applicability limitations could be lifted by > reducing its integrity protection scope. I'm not sure how popular > will it be then (some have had different opinions on adoptability > of things relying on CA) but it seems worth trying. > > I would not dare to restrain ourselves to fixing RFC4474 though. > I'm very much in favor of testing other alternatives. IETF has > had a very successful tradition of testing several approaches. > A more ellaborated email on the topic was BTW recently written > by Dave Crocker: > http://www.ietf.org/mail-archive/web/mmox/current/msg01233.html > > Obviously DERIVE (or perhaps non-SIP based reverse verifications) > appears a feasible alternative to me (because easy to deploy and > offering incentives to do so), but given the interest it is quite > certain there will be more different alternatives. [JRE] I am open to such alternative suggestions. I think the problem with DERIVE was that it still was impacted by the idiosyncrasies of SIP, i.e., B2BUAs and backwards compatibility with UACs. Perhaps we need a non-SIP-based solution.
John _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
