Re: scope of derive

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

I think DERIVE is a viable approach for spoofing protection and I 
haven't found
a convincing argument that would counter that really. (abstracting now from
the dialog package).  In fact, DERIVE is MORE viable than anything else 
which
has been discussed. RFC4474 has turned out not to be viable, and neither did
From, P-Asserted-Identity or other possible "just-nothing" approach. To 
provide
arguments: we know that RFC4474 has not been deployed. We thus do not have
running code and cannot rely on it. sipit reports show two implementations,
one of them is ours in SER, which to my best knowledge has not found
a deployment. I guess that's because reliance on CAs and excessive message
integrity. (who in the world does NOT rewrite SDP???) Security of 
plain-text
From/PAI hopefuly requires no discussion.

I understand you have been worried about B2BUA. That's a legitimate concern,
but let's face it...fixing applications is fixing consequences and not the
problem. Today it is DERIVE, yesterday it was REFER and tommorrow it is 
going
to be FOOBAR -- fixing the apps doesn't help. Fixing the root of the problem
is fixing the B2BUA, such as by making them more deterministic. Hadriel's
draft about sesssion id is IMO a real specific step torwards that.

Well -- we may have a way for doing reverse-routability checks which is 
simpler.
DERIVE a la SPF would avoid all of this SIP pain, however at the loss of 
per-dialog
granularity. The "resolution" would then degrade to administrative 
domain-name
ownership as opposed to "dialog ownership". In fact, we have recently 
deployed
SPF for our domain and instantly observed a dramatic increase in number 
of faked
emails that have been dropped.

To me that would be a reasonable answer to dealing with all of the SIP 
complexity
(and B2BUA, and SBC, and what-have-you). One could even guess that the share
of positive cases would be initially higher -- it takes only reliance on
configuration of sender's DNS (as opposed to updating B2BUA).

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