Hadriel Kaplan wrote:

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean
Willis
Sent: Friday, December 05, 2008 12:22 PM

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

[snip]

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.

Ummmm... no it doesn't.  It stops me from attacking the intended target's phone 
*directly*, but not as a smurf-style attack.  I simply set my From: to the 
*target's* URI, then send that INVITE to every number I can.  Thus I get other 
devices to flood the target with SUBSCRIBEs.  It's not as annoying as ringing 
the target's phone, for sure, but it's still an attack.  And unlike SMURF or 
hammer attack, it only requires me to know the target's AoR, not its IP or MAC. 
 And unlike a direct INVITE attack, I don't even need authorization or a path 
to reach the intended target; I only need to be able to reach a lot of 
Derive-capable UA's and hope some of them can reach the intended target.

This is a question IMO: what does the attacker gain here? IMO a free topology hiding feature, he is not getting an amplification. Couldn't we lower the concerns by fingerpointing at the
attacker in the DERIVE tests?

-jiri


-hadriel

_______________________________________________
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

Reply via email to