Subject: [MMUSIC] draft-ietf-mmusic-ice-05: Issue with handling when doing DDoS prevention

From: Magnus Westerlund <[email-masked]>
Date: Tue, 02 Aug 2005 18:56:42 +0200

Hi,

If one likes to do DDos prevention as a media sender. How does that 
actually work in ICE when doing offer/answer?

First of all, having the active address and sending media during the ICE 
exchange do allow one to use the ICE connectivity checking time to 
deliver media to a target of a DDos. Should there be any recommendations 
around this behavior? As I see it one can do a few things.

1. Put media transmission on hold during the initial establishment.

2. Allow the media transmission for a specific period that should allow 
the ICE process to conclude and the media delivery verification to complete.

3. Do 2 and specify limits on media bandwidths allowed during the 
initial period.

Secondly what happens when the ICE exchange results in a re-invite but 
the other end point (B) does not yet have received an answer from (A) on 
its own binding requests. Also here there are several different results 
that one could see.

1. Not respond until B has verified binding requests in direction B->A. 
Prevents us sending anything else than STUN binding requests and do that 
according to the retransmission timers in STUN.

2. Answer directly and do the verification later. Allows media to be 
sent directly. However it does allow an attacker to get media sent to a 
target for a while longer.

So I think the problem boils down to a first fundamental question:

Is is okay to send media before verification has been successful?

and if it is, how much?

if not, then we need to look into the issue in signalling. Can one hold 
of a response and are the needs to do a 1xx response?

I definitely see a problem if one would allow media transmission without 
any limitations for times up to the 50 second timer in ICE. There 
clearly needs to be some limitations in an open network.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Aug 2005 19:42:17 -0400

Some good questions here, Magnus. Replies inline.

> actually work in ICE when doing offer/answer?

This is a good question. I have in the past advertised ICE as a way to 
prevent media DDos attacks, but the latest draft does have the endpoint 
sending media places prior to connectivity checks completing, in order 
to reduce post-dial delay.

As such, I think there is a fundamental tradeoff here between call setup 
delay and DoS protection.

> around this behavior? 

I think the spec should address this, yes.

> As I see it one can do a few things.
> 

By hold, do you mean literally on hold (i.e., a=inactive)? Or just, 
don't send media there until verified?

> the ICE process to conclude and the media delivery verification to 

For a high rate codec this can still be pretty decent amplification.

> 3. Do 2 and specify limits on media bandwidths allowed during the 

Sure, but the codecs may not easily allow that.

I'd propose (1), assuming "on-hold" means that you simply delay 
transmitting the media until a stun check to the active address 
succeeds. Then you can send media there without a reinvite. That is 
going to increase the post-pickup delay by an RTT unless you use 
preconditions. Like I said, thats the fundamental tradeoff. However, I 
think its one worth making. As such, I'd propose that ICE-06 say that 
you SHOULD NOT send media until a connectivity check to the active 
address succeeds, and explain why.

> its own binding requests.

Right - you raised this excellent point during the meeting. Back at 
IETF62 I had proposed a three-way handshake mechanism was needed to 
properly fix this. However that is a big change in STUN no matter how 
you try and do it.

> Also here there are several different results 
> that one could see.
> 

Not respond means delaying the answer; that will cause SIP message 
retransmission needlessly. We've had this problem in 3pcc and have tried 
to avoid it.

> target for a while longer.

Not necessarily. I think the agent would generate an answer, and place 
into the SDP an active address which its verified in both directions if 
it has one, and if not, put one in there which has been "half" verified. 
However, it wouldn't send media until it has verified full connectivity 
with the STUN checks. When those succeed, it can send media.

Does that seem reasonable?

> of a response and are the needs to do a 1xx response?

Per above, I think we should stay away from doing this.

> clearly needs to be some limitations in an open network.

Agreed.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 24 Aug 2005 11:45:48 +0200

> don't send media there until verified?

That one don't send any media until verification has happened.

> 
>>
>> 2. Allow the media transmission for a specific period that should 
>> allow the ICE process to conclude and the media delivery verification 
>> to complete.
> 
> 

Agreed. Thus I think it is quite dangerous.

> Sure, but the codecs may not easily allow that. 

And also limits are always hard to specify.

> address succeeds, and explain why.

I think SHOULD NOT is the right level. Are you certain that the post 
pickup delay would increase? Isn't the most likely case with ICE that 
you use pre-conditions anyway as you like to perform all the STUN 
exchanges before it rings. Or at least during the time it rings. If the 
path is verified prior to the actual call start then no extra time 
should be needed. But I do understand that there are cases when extra 
delay will be noticeable by the user.

>> the other end point (B) does not yet have received an answer from (A) 
>> on its own binding requests.
> 
> 

It seems to me that one will have some nasty interactions when one 
switches from STUN checks to media and promote a specific port to usage. 
For a while that port needs to support both STUN and media if one looks 
at the desired functionality (Answerer can continue to do checks) and 
still follow offer answer requirement (Support media reception according 
to offer).

> 
>> Also here there are several different results that one could see.
>>
>> 1. Not respond until B has verified binding requests in direction 
>> B->A. Prevents us sending anything else than STUN binding requests and 
>> do that according to the retransmission timers in STUN.
> 
> 
>> sent directly. However it does allow an attacker to get media sent to 
>> a target for a while longer.
> 
> 

Yes, however it does have these interesting problem that you need to 
keep stun or what you are using for verification flowing while normal 
media can happen. Or was you planning to do another reinvite to promote 
the other direction into usage?

Cheers

Magnus Westerlund