Jiri, > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Jiri Kuthan > Sent: 06 December 2008 07:49 > To: Scott Lawrence > Cc: [email protected] > Subject: Re: [Sip] scope of derive > > Scott Lawrence wrote: > > Excellent analysis of the context and applicability of > DERIVE, Dean. In > > it, you wrote: > > > >> [...] DERIVE assumes that > >> the identity expressed in the request being examined is a > routable > >> identity, and that there is a indirect return routability > for that > >> identity. By indirect return routability, I mean that a > new request > >> targeted to that identity will reach the user agent that > originated > >> the request. Further, DERIVE assumes that the UA reached by the > >> indirect return routability path has knowledge of the > request being > >> examined and that it can attest to that knowledge, thereby > >> establishing the veracity of the identity expressed in the > request to > >> the level of "this identity resolves in the routing > topology to the > >> node that sent the request". > > > > There are two issues with these assumptions that I think > are worth one > > further level of analysis: > > > > A From Address will often fail to reach the caller if used > as a request > > target. > > > > For DERIVE to work the "indirect return > routability" test needs > > to reach the specific UA that originated the call whose > > authenticity is being checked. In environments > with any kind of > > gateway, this will often not be the case. If I'm > calling from a > > non-SIP environment into SIP, even if that translation > > accurately preserves my identity as a From address > (for example, > > my PSTN carrier provides a valid caller-id which then is > > accurately translated to a From header), that > address is often > > not going to have the property that it is sure to > route back to > > the very same gateway that the INVITE came from. > What's more, > > there's no other reason why it should - an AOR is > an identifier, > > not a route description. > > > > SUBSCRIBE is not INVITE > > > > It is by no means assured that a SUBSCRIBE request will be > > routed to the same set of UAs that an INVITE would be. In > > particular, a SUBSCRIBE coming from outside the > callers domain > > may often be subject to policy based routing or > rejected without > > ever reaching the UA of even a legitimate caller. > > > > These factors are the ones that I was referring to in the > Minneapolis > > meeting when I said that a DERIVE-based test would have a high > > false-alarm rate > > > > I agree but I don't think that's the point. Remember that DERIVE is > about the > positive test, the negative tests are worthless. In other > words this is > about > the migration path and not about the starting point (every single > extension takes > some new lines of code, without which there is 0% deployment). > Importantly, while > DERIVE grows, the worthless share declines and reinforces the > value of > the positive > share. [JRE] The number of negatives will diminish, true, but it will never approach zero, because there will always be negative cases arising from forking, call forwarding, problematic B2BUAs, etc.. So it is a question whether it will get sufficiently close to zero that the odd false negative can safely be ignored. I am rather doubtful.
John > > > > - that is, that the indirect return routability test > > would fail even for a legitimate caller with a legitimate > From address. > > The point is the *positive* case. > I bet I can name you 10 reasons why the negative case can > occur but I'm not > interested the negative case. (it is not "false positive", it is > worthless zero-bit-long piece of information). > > > > > I believe this rate would be so high that it would > certainly be unsuited > > to any automated filtering - the best it could do would be > to offer a > > user-interface indication of failure at call presentation > time. Even in > > that case, it would indicate an unverified caller so often that the > > callee would be unwise to make any firm judgment based on it, so the > > callee is in exactly the position they are in today - the > From address > > is a hint. > > > > > > > > Why are you exactly interested in studying the negative case > when it is > obviously without value? > > -jiri > _______________________________________________ > 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
