Re: [rtcweb] Summary of ICE discussion
Bernard Aboba <bernard_aboba@hotmail.com> Wed, 05 October 2011 15:32 UTC
Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3618221F8C73 for <rtcweb@ietfa.amsl.com>; Wed, 5 Oct 2011 08:32:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.212
X-Spam-Level:
X-Spam-Status: No, score=-102.212 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLkhPlNecFNJ for <rtcweb@ietfa.amsl.com>; Wed, 5 Oct 2011 08:32:27 -0700 (PDT)
Received: from blu0-omc3-s29.blu0.hotmail.com (blu0-omc3-s29.blu0.hotmail.com [65.55.116.104]) by ietfa.amsl.com (Postfix) with ESMTP id 4801A21F8C6C for <rtcweb@ietf.org>; Wed, 5 Oct 2011 08:32:27 -0700 (PDT)
Received: from BLU152-W46 ([65.55.116.72]) by blu0-omc3-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 08:35:35 -0700
Message-ID: <BLU152-W463B7BC9EE2E0FEB96B3C593F80@phx.gbl>
Content-Type: multipart/alternative; boundary="_1e1433ff-eea4-48c0-945f-db2285b8be1d_"
X-Originating-IP: [98.237.179.165]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Date: Wed, 05 Oct 2011 08:35:34 -0700
Importance: Normal
In-Reply-To: <4E8C10BC.8090104@ericsson.com>
References: <4E8B192E.80809@ericsson.com> <CALiegfmnxO+BrfycOmL=hptBFdcEpsLeBn=zsJTX=ivKBBumWw@mail.gmail.com> <BLU152-W139AA2913C1CFFDB50726193FB0@phx.gbl> <BLU152-W2342F5823933FA1F2B9F9C93FB0@phx.gbl> <37C37EE6-3D48-4C77-A025-3207F040572B@cisco.com> <4E8BC56E.40306@skype.net> <snt0-eas2567EB3C48B254DA9E07FC693F80@phx.gbl>, <4E8C10BC.8090104@ericsson.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 05 Oct 2011 15:35:35.0706 (UTC) FILETIME=[6D1E77A0:01CC8374]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Summary of ICE discussion
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Oct 2011 15:32:28 -0000
What I was trying to point out was that there are very specific conditions under which the browser will consider the STUN exchange to be "successful" that will not be met by a public STUN server, which typically will not support ICE extensions. If we articulate this, it would not be possible to DoS a public STUN server with *media*, which has been the bar we've been applying so far. It should be understood that when the "answer" is not directly available to the offering browser, the STUN exchange is only able to verify the willingness to receive on a particular IP address/port combination. Without multi-plexing, this should ensure that the receiver has consented to each media type. Assuming that we can satisfactorily handle "continuing consent" determination, I'm not sure that we would need ICE extensions to address the issue. This seems like a slippery slope that could result in a continuing stream of ICE extensions. IMHO, the "congestion control" problem is separable. Since it seems inevitable that RTCWeb implementations will support non-adaptive codecs, I don't believe we can rely on "congestion control" for DoS avoidance. > Date: Wed, 5 Oct 2011 10:09:32 +0200 > From: magnus.westerlund@ericsson.com > To: bernard_aboba@hotmail.com > CC: matthew.kaufman@skype.net; rtcweb@ietf.org > Subject: Re: [rtcweb] Summary of ICE discussion > > Hi, > > good that my summary lets us move forward. > > A question on this attack. How common is it that these STUN servers use > other ports than 3478? Would a rule about that port mitigate the issue, > even if it could result in connectivity failures in cases where the NAT > external port is 3478 by chance? > > In addition does these public servers use the username and password > convention from ICE? Isn't that what prevents STUN server deployed for > just determining your server reflexive candidate from actually respond > correctly to a connectivity check? As ICE do concatenate one part > generated by one peer with a part generated by the other peer I don't > see this as an issue as long as the random username fragment is > generated by the browser not the JS. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >
- Re: [rtcweb] Summary of ICE discussion Randell Jesup
- [rtcweb] Summary of ICE discussion Magnus Westerlund
- Re: [rtcweb] Summary of ICE discussion Iñaki Baz Castillo
- Re: [rtcweb] Summary of ICE discussion Randell Jesup
- Re: [rtcweb] Summary of ICE discussion Olle E. Johansson
- Re: [rtcweb] Summary of ICE discussion Eric Rescorla
- Re: [rtcweb] Summary of ICE discussion Cary Bran (cbran)
- Re: [rtcweb] Summary of ICE discussion Hadriel Kaplan
- Re: [rtcweb] Summary of ICE discussion Bernard Aboba
- Re: [rtcweb] Summary of ICE discussion Bernard Aboba
- Re: [rtcweb] Summary of ICE discussion Cullen Jennings
- Re: [rtcweb] Summary of ICE discussion Cullen Jennings
- Re: [rtcweb] Summary of ICE discussion Matthew Kaufman
- Re: [rtcweb] Summary of ICE discussion Matthew Kaufman
- Re: [rtcweb] Summary of ICE discussion Matthew Kaufman
- Re: [rtcweb] Summary of ICE discussion Bernard Aboba
- Re: [rtcweb] Summary of ICE discussion Matthew Kaufman
- Re: [rtcweb] Summary of ICE discussion Ravindran Parthasarathi
- Re: [rtcweb] Summary of ICE discussion Roman Shpount
- Re: [rtcweb] Summary of ICE discussion Magnus Westerlund
- Re: [rtcweb] Summary of ICE discussion Magnus Westerlund
- Re: [rtcweb] Summary of ICE discussion Harald Alvestrand
- Re: [rtcweb] Summary of ICE discussion Harald Alvestrand
- Re: [rtcweb] Summary of ICE discussion Jonathan Lennox
- Re: [rtcweb] Summary of ICE discussion Ravindran Parthasarathi
- Re: [rtcweb] Summary of ICE discussion Bernard Aboba
- Re: [rtcweb] Summary of ICE discussion Harald Alvestrand
- Re: [rtcweb] Summary of ICE discussion Cullen Jennings
- Re: [rtcweb] Summary of ICE discussion Paul Hoffman
- Re: [rtcweb] Summary of ICE discussion sebastien.cubaud
- Re: [rtcweb] Summary of ICE discussion Iñaki Baz Castillo
- [rtcweb] Sebastien Cubaud's non-ICE mechanism (Re… Harald Alvestrand
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… sebastien.cubaud
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Eric Rescorla
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Iñaki Baz Castillo
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Randell Jesup
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Jonathan Rosenberg
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Randell Jesup
- Re: [rtcweb] Summary of ICE discussion sebastien.cubaud
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Iñaki Baz Castillo
- Re: [rtcweb] Summary of ICE discussion Iñaki Baz Castillo
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Tim Panton
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… sebastien.cubaud
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Sebastien Cubaud's non-ICE mechanism… sebastien.cubaud
- Re: [rtcweb] Summary of ICE discussion sebastien.cubaud