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. 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 identity. 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. _______________________________________________ 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
