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, 5 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
> ----------------------------------------------------------------------
>