John, >it is difficult to tell whether a better-than-nothing approach would be >worthwhile.
Is this not for the market to decide? (Who are we?) Henry On 12/5/08 8:39 AM, "Elwell, John" <[EMAIL PROTECTED]> wrote: Viktor, > -----Original Message----- > From: Victor Pascual Ávila [mailto:[EMAIL PROTECTED] > Sent: 05 December 2008 13:47 > To: Elwell, John > Cc: Jiri Kuthan; [email protected]; Cullen Jennings > Subject: Re: [Sip] scope of derive > > On Fri, Dec 5, 2008 at 12:34 PM, Elwell, John > <[EMAIL PROTECTED]> wrote: > > Jiri, > > > > It is well-known that I am not comfortable that we have a > **deployable** > > solution for preventing From URI spoofing. The reason it is not > > deployable is because of B2BUAs, and to some extent because of > > E.164-based URIs and the way they are handled in practice. > Furthermore > > there are issues with PSTN interworking, but we can't do much about > > that. > > > > I have tried to articulate these issues by means of several > I-Ds over > > the last year or so, but capturing a "problem statement" > acceptable to > > all seems to be an elusive goal. > > > > The reason seems to be that if I describe the problem in a > certain way > > (e.g., B2BUAs break the RFC 4474 signature), people say > "but we can get > > round this by doing A", so the problem statement has to be > extended to > > say why A doesn't work, and then people say "but you can > get round it by > > doing B", so the problem statement has to be further > extended to say why > > B will not work, and so on ad infinitum. > > > > So I would welcome any other attempts to write the problem > statement. > > The whole identity problem cannot be solved in one shot. [JRE] Jiri asked about problem statement, not solution. > IMO the scope of DERIVE is very limited, which I consider to be a good > thing if we really want to have a deployable solution. > > Starting from the very beginning, I'm wondering if folks agree that: > - From URI spoofing is a problem > - Existing mechanisms present some shortcomings (see > draft-elwell-sip-e2e-identity-important) > - An "as much end-to-end as possible" solution is desired > - This solution is desired to be *simple and deployable* > - In the absence of some sort of authentication mechanism, URI > verification is "better-than-nothing" > - A "better-than-nothing" approach to URI verification may provide the > desired level of simplicity and deployability. [JRE] The word "may" is important here. Until we find an approach that is viable (and I don't think we are quite there yet with DERIVE), it is difficult to tell whether a better-than-nothing approach would be worthwhile. John > - The used mechanism should work on a per-session basis. This might be > done by using any unique session-identifier/token shared between the > calling and the called parties. > > I'd like to hear your opinions on this. > > Cheers, > -- > Victor Pascual Ávila > _______________________________________________ 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 _______________________________________________ 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
