Cullen, > -----Original Message----- > From: Cullen Jennings [mailto:[email protected]] > Sent: 01 April 2009 16:06 > To: Elwell, John > Cc: DRAGE, Keith (Keith); [email protected]; Francois Audet > Subject: Re: [Sip] francois' comments and why RFC4474 not > used in the field > > > On Apr 1, 2009, at 4:33 AM, Elwell, John wrote: > > > I would like service providers to chip in here. Suppose I > use service > > providers to establish a call between two enterprises. > Enterprise A > > uses > > SP A for all external traffic, and enterprise B uses SP B for all > > external traffic. We then have a path: > > > > Enterprise A -> SP A -> SP B -> Enterprise B. > > > > What I would like to know is whether SP A and/or SP B would have > > reason > > to change the SDP (also other aspects of the SIP request, but just > > stick > > to SDP for now). If they need to change it, then what > drives this need > > to change the SDP: NAT traversal, topology hiding, media > > steering, ....? > > > > If SPs think they have no reason to change SDP in such situations, > > then > > this part of the problem is solved. However, I very much > doubt that is > > the case. > > > > John > > I think this is exactly the right sort of question to be asking (and > we all agree they have reasons they are currently changing the SDP, > what we need to get at is why). > > I think we also need to know about situations like > > > > > UA A -> SP A -> SP B -> UA B. > Enterprise A -> SP A -> SP B -> SP C -> Enterprise B. [JRE] Yes.
> > And reasons SP B would change it. We also need to understand > for each > use case if it is an E.164 number or email style name. We > need to deal > with the cases where one of both of the ends is the PSTN not an > enterprise. We also need to understand the trust > relationships between > the various entities. By that I mean things like "Enterprise B is > willing to trust SP C (who it pays) will not misroute it calls". Or > that UA A trust SP A not to give A's AOR to someone else. [JRE] Yes, but my contention has already been that I will trust SP A (my local SP) to identify a user in SP A's domain, but not to identify a user in some other domain - for that latter case I would trust that other domain (subject to a valid certificate, of course). I would trust an assertion from Amazon.com, but might not trust an assertion from SP.net that I am talking (perhaps through other SPs) with Amazon.com. I suppose in either case transitive trust is involved. In the one case (by trusting Amazon.com) I am really trusting the CA to assert that it is Amazon.com, whereas in the other case I am trusting my SP to assert that it is Amazon.com. The web way of doing things is to trust a CA rather than to trust an intermediary. > > Then we need to go through use case and figure out which > requirements > derive the modification of key headers or bodies and which use cases > happen in real deployments and which ones are purely hypothetical. > They type of reasons for modification of headers/SDP that have been > raised in past include things like topology hiding, media steering, > nat traversal, and protocol repair. [JRE] Some of this is already discussed in the e2e-identity-important draft. People are adding further information about real deployments on this thread. > > Next we need to work on what the problem is. This includes > things like > "I want to know who's phone I will be talking to if I answer this > ringing call so I can decide if I answer the call" or "I want > to know > who's phone I am talking to at the other end so I can decide what I > might say", or "I want to be able to reject all calls at 2am > that are > not from a phone that is listed in my personal address book". > I'm not > proposing any of these are the right problem statement - I'm just > trying to give examples of they type of statement that if we > agreed on > it would help us make progress. [JRE] I thought a lot of this was covered in e2e-identity-important. Maybe its not said in the right way. > > We have proven over and ever again that without understanding what > problem we are trying to fix, we don't get very far. Saying that the > problem is "4474 does not work", does not help in the > slightest. That > may or may not be true but it is not the problem - it's a statement > about if 4474 as a technology helps solve some unspecified > problem or > not. [JRE]The e2e-identity-important draft does not just say "4474 does not work" but looks at use cases, looks at what they are trying to achieve, and also looks at things that get changed by intermediaries, thereby limiting possible solutions. > > I have been advocating for years now that the discussion > about if 4474 > works for problem X or not is not going to get far without some > agreement on what the various values of X are. [JRE] I know. But I can't seem to find a way of expressing X that works for people. Let's try this. Suppose I receive a call from Amazon.com. I want to know that it is from Amazon.com, because my white list will accept calls from Amazon.com and also, when Amazon.com is displayed, I am prepared to interrupt whatever I am doing to answer a call from Amazon.com. I might give an appropriate greeting and I might be prepared to divulge sensitive information to the caller if I know it is Amazon.com. I might even be interested to know the particular caller from Amazon.com, but not necessarily. If I just see that the call is from my SP, or from some other SP that happens to be in the call path, that means nothing to me. My device can't do effective white list filtering, I can't do effective filtering, I can't answer with an appropriate greeting, I can't know whether it is safe to divulge sensitive information during the call. Furthermore, it is not sufficient just to be told it is from Amazon.com. I require authentication based on a trust anchor, which could a well-known CA, or some other certificate I already have in my store by some out-of-band means. This is the problem I am trying to solve. It is also a problem that RFC 4474 is designed to solve, but depending on the number and behaviour of intermediaries, very often RFC 4474 will not solve it. 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
