Re: 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.


> - 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