Subject: RE: [Sipping] Some thoughts on fixing early media

From: Jeroen Van Bemmel <[email-masked]>
Date: Mon, 24 Jul 2006 12:44:36 +0200

Some more thought on voice hammers: It seems that this would mainly be an issue for automatic response systems, since a human behind a UAS would detect that something is odd (and probably hang up)

What if for such systems, we mandate that transmission must not start until either ACK or PRACK is received, ie require return routability on the UAS Contact (icm unique random grid)?

Regards,

Jeroen

-----Oorspronkelijk bericht -----
Van: "Dean Willis" <[email-masked]>
Aan: "Christer Holmberg" <[email-masked]>
CC: "sipping" <[email-masked]>
Verzonden: 23-7-06 20:07
Onderwerp: Re: [Sipping] Some thoughts on fixing early media

On Jul 23, 2006, at 12:14 AM, Christer Holmberg wrote:

> Hi Brian,
>
> What if an UAS wants to send 200 OK (and media) before the UAC has  
> told him it's ok to send media? Someone would have to send an  
> UPDATE, to switch the media to sendrecv.
>

That's the design goal here, I think -- giving the UAC an opportunity  
to consider and accept, defer, or reject media, be it early or  
otherwise.

> Or, are you proposing that the UAS, until it's given permission to  
> send media, wouldn't even alert the user behind it?

I suppose that would depend on the nature of the UAS. But if we made  
this assumption in all cases, it seems like this would let us fix the  
forking-to-multiple-answers problem. We've more or less found away  
for a UAC that care to serialize its forking,  even if its proxy  
forks parallel.

If we couple this to some sort of indicator to the UAC about what the  
media (especially early) flow is (I mean, how it is being used, or at  
least whether or not is required for normal operation)) we might have  
a fairly complete solution set for the problem.

I haven't thought this entirely through, but I believe it also  
reduces the attack scenario that Jonathan Rosenberg calls the "voice  
hammer", which basically involves sending an INVITE (probably with a  
spoofed source)  that includes an SDP offer pointing at the victim.  
If the recipient of the INVITE starts blasting media out according to  
that SDP, the victim gets sprayed with RTP packets, and (outside of  
an ICMP source quench, which never works anyhow) has basically no way  
to tell the sender to stop -- something like a 1,000 to 1 amplifier  
that also allows anonymous attacks. I believe Brian's model in effect  
requires verified return-routability before transitioning to active  
media. This doesn't prevent the attack, but at least prevents the  
typical use of a spoofed source address. If we were to couple this to  
another requirement that signaling and media be at the same IP  
address (sorry, softswitch vendors), we'd have a fairly complete  
answer to the voice hammer, since spoofing with return routability is  
MUCH harder than simple source spoofing.

--
Dean

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Dean Willis <[email-masked]>
Date: Mon, 24 Jul 2006 11:57:16 -0500

> Some more thought on voice hammers: It seems that this would mainly be an issue for automatic response systems, since a human behind a UAS would detect that something is odd (and probably hang up)
You can still get a pretty good hammer out of something that's doing 
nothing but playing "foreign ringtone" as media. So the scope is a 
little bigger than automatic response systems -- probably automatic 
response systems PLUS anything that sends early media.

> What if for such systems, we mandate that transmission must not start until either ACK or PRACK is received, ie require return routability on the UAS Contact (icm unique random grid)?

That at least lets us know where the "voice hammer" request came from, 
if we find out we've been hammering somebody.

--
dean