Re: scope of derive

On Nov 20, 2008, at 5:52 PM, Jiri Kuthan wrote:

> I'm just wondering, if folks could help to explain me this:
> apparently when I asked if people in the WG feel safe about
> IETF's mechanisms deployable to prevent spoofed From, nobody
> spoke up. At the same time, there were some who felt that
> we don't have a problem statement. I would be thankful if
> representatives of the latter group could share with me
> what is the missing piece here to state a problem.
>

So let's define a "spoofed From."

Are we talking about a real UA generating an INVITE request with a  
bogus identity asserted in it's From: field, or are we talking about a  
DOS attack (like a voice-hammer generator) where a device that is not  
a UA is generating an INVITE request that causes the UAS to deliver  
the attack to the victim?


For the first threat, in our current spec family, we have strong  
identity (aka RFC 4474) as a general solution, and weak identity (RFC  
3325) as a point solution for single-domains or federations with  
identity enforcement points in trusted proxies.

For the second threat, we have null-authentication; the UAS can  
challenge the request (which tests direct return routability to the  
UAC) and wait for a response before proceeding to the alerting phase.  
By direct return routability, I mean that we can follow the via-stack  
back to the originating UAS (possibly with help for a via-pruning SBC).

So where does DERIVE fit in?

I believe it attempts to address both problems. It's clearly heavier  
than the existing solution for the second threat, but if we use  
DERIVE, we get this problem fixed for free. So the question of the  
work really seems to be its applicability to the first threat.

Let us move to an examination of the assumptions. 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".

Therein lies the differentiator: Whereas RFC 4474 proves the identity  
cryptographically (that is, through secrets known to the identity- 
holder or to a trusted third party working on behalf of the identity- 
holder), DERIVE proves it functionally (by the definition of  
"functionally" meaning "it works", sorry you Haskell fans!).

Two questions remain:

1) Is a functional verification through indirect return routability  
testing of the identity expressed in a request actually useful?

2) Is the mechanism used by DERIVE reasonable for implementing an  
indirect return routability check?

Let's attack these one at a time.


Question 1: Usefulness of indirect request return-routability checks  
in SIP

Many attacks seen in the Internet rely on forged transmission  
identifiers. For example, consider the once wildly popular Smurf attack:

	 http://en.wikipedia.org/wiki/Smurf_attack

The Smurf attack uses a ICMP echo request with a forged IPsource  
address, where the victim's address is used as its source address  
(i.e, it's "From:"). This initial request is addressed to the  
broadcast address of a remote subnet. If the attack succeeds, each  
host on the remote subnet replies, thereby flooding the victim with  
unexpected ICMP echo request responses.

Although we have not identified a Smurf-like direct amplification  
attack in SIP, it's still obviously possible to use a forged From: to  
cause the victim's phone to ring, thereby making the target UA an  
attack amplifier against the person (or sanity) of the end user. One  
might call this the "ring ring ditch" or "ring ring ginger" attack,  
from the similar childish doorbell prank"

	http://en.wikipedia.org/wiki/Knock_down_ginger

DERIVE clearly reduces the opportunity to use a forged From: to bypass  
controls on the victim's phone. Not perfect, but it passes the script- 
kiddie test.


Consider however the SIP Voice Hammer attack:

	http://tools.ietf.org/id/draft-ietf-mmusic-ice-19.txt, section 18.15.1

This works similarly to Smurf, but it uses a second level of  
indirection. Rather than spoofing the victim's From: address, Voice  
Hammer insert's the victim;s address into the SDP of a SIP INVITE.  
When the target of the request "answers" the call, the target becomes  
an amplifier, spewing RTP packets at the victim.

Indirect return routability testing gives us no direct defense here,  
in that provides some validation of the from: address but we have no  
way of correlating this address with the one used in the SDP. However,  
it does make it harder to originate the attack anonymously, as it  
requires that the attacker establish indirect return routability at  
the SIP level, which presumably gives us a little better chance of  
hunting the perpetrator down and apply other mechanisms (such as  
summary execution) in order to prevent further offenses.

In other words, it's good enough to stop script kiddies.

In a third attack scenario, presume the attacker's goal is to  
impersonate a caller, such as the infamous "Radio-Show Sarkozy/Palin"  
calls.
	
	http://www.huffingtonpost.com/2008/11/01/masked-avengers-prank-cal_n_140023.html

Here the goal is not necessarily to prevent the call, but to give the  
called party some level of comfort as to the authenticity of the  
caller's expression of identity.

Indirect return routability checks clearly establish that the calling  
party is sufficiently in-control of the expressed identity as to be  
able to receive calls directed toward that identity. This is better  
than nothing; it can't prove identity, but it greatly decreases the  
probability of a random radio DJ being able to make a prank call.



Question 2: Does DERIVE provide a reasonable solution?

In order to impact the DoS attacks described in 1, the solution has to  
be "strong enough" that we can reasonably reject a call, at the  
automata level, without bothering the user. No arguments have been  
made that the mechanism in DERIVE is sufficiently widely deployed that  
one can reject calls not using it. One might argue that one could add  
an extension detection mechanism (such as including a modifier in the  
identity) that says "You can expect calls from me to support DERIVE;  
if they don't, it isn't me" that might help. But it's still a pretty  
weak defense against DoS. In the general case, DERIVE does NOT stop  
script kiddies from known DoS attacks, so it may not be useful here.

Consider however the "Radio-Show Sarkozy/Palin" calls; here the  
requirement is not to block the call entirely, but to give additional  
guidance to the user as to how to evaluate the caller's claimed  
identity. Here DERIVE might be useful. It's more use if we have a  
reason to believe that calls from a given party should support DERIVE.  
In the end, it comes down to breadth of availability. Will DERIVE be  
widespread enough that anybody bothers with it? My hunch is that this  
is unlikely, but this might be a useful point of discussion.

--
Dean




_______________________________________________
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