[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MMUSIC] Re: draft-ietf-mmusic-ice-05: Issue with handling when doing DDoS prevention
Some good questions here, Magnus. Replies inline.
Magnus Westerlund wrote:
Hi,
If one likes to do DDos prevention as a media sender. How does that
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.
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?
I think the spec should address this, yes.
As I see it one can do a few things.
1. Put media transmission on hold during the initial establishment.
By hold, do you mean literally on hold (i.e., a=inactive)? Or just,
don't send media there until verified?
2. Allow the media transmission for a specific period that should allow
the ICE process to conclude and the media delivery verification to
complete.
For a high rate codec this can still be pretty decent amplification.
3. Do 2 and specify limits on media bandwidths allowed during the
initial period.
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.
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.
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.
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.
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.
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.
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?
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?
Per above, I think we should stay away from doing this.
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.
Agreed.
Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711
Cisco Systems
jdrosen at cisco.com FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic