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
