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 - that is, that the indirect return routability test
would fail even for a legitimate caller with a legitimate From address.
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.
_______________________________________________
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
