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

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 24 Jul 2006 21:28:15 +0300

Hi,

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

[CHH] The PRACK (or UPDATE) can also include the "give permission to play early media" indicator, if we would end up with such solution. We should try to "re-use" as many of the current setup transactions as possible, and not add new ones.

I still think one does not have to ask permission when sending 200 OK. That will cause clipping. When a user answers a call he should not have to wait before starting to talk.

Regards,

Christer

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: "Brian Stucker" <[email-masked]>
Date: Mon, 24 Jul 2006 15:49:45 -0500

You might take a quick peek at the draft I put out this morning. The
mechanism described there is trying to reuse as many of the existing
transactions as possible. Take a look at section 6, I think it covers
off (at least roughly) what you are describing.

http://ietf.obsidian97.dyndns.org/drafts/draft-stucker-sipping-early-med
ia-coping-00.txt

Regards,
Brian

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Monday, July 24, 2006 1:28 PM
> To: Jeroen Van Bemmel; Dean Willis
> Cc: sipping
> Subject: RE: [Sipping] Some thoughts on fixing early media
> 
> Hi,
> 
> 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)?
> 
> [CHH] The PRACK (or UPDATE) can also include the "give 
> permission to play early media" indicator, if we would end up 
> with such solution. We should try to "re-use" as many of the 
> current setup transactions as possible, and not add new ones.
> 
> I still think one does not have to ask permission when 
> sending 200 OK. That will cause clipping. When a user answers 
> a call he should not have to wait before starting to talk.
> 
> Regards,
> 
> Christer
> 
> Regards,
> 
> Jeroen
> 
> > 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.
> 
> 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
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>