Re: [rtcweb] Question about ICE-Lite server

Justin Uberti <juberti@google.com> Fri, 11 July 2014 16:17 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CB41B2B63 for <rtcweb@ietfa.amsl.com>; Fri, 11 Jul 2014 09:17:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level:
X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKLkq2AqUT9c for <rtcweb@ietfa.amsl.com>; Fri, 11 Jul 2014 09:17:01 -0700 (PDT)
Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9181B2B60 for <rtcweb@ietf.org>; Fri, 11 Jul 2014 09:17:01 -0700 (PDT)
Received: by mail-vc0-f170.google.com with SMTP id hu12so1383682vcb.29 for <rtcweb@ietf.org>; Fri, 11 Jul 2014 09:17:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wYrKUeJ2I3rTLJ0IxsHfRaiTASuMPzZrSQLwpfM848E=; b=ElxH7u0yQoksCRFg8xKnEJUR+/DkBeIpxgIw8L2mCyEhsVeUCrnAmZ4RI1VBpr9mQU ojANC2YXfHvHYArKS0XXkBN7fuXsf0KhmWpKtvaF/oqxKqWFyi8OnM420pcRCa8dXK51 6AtdIBblc/+hLK98PiipKzbCK8pa2N64byHkOgoeEco0kD/eVNJKKhiYa14OV4p6o1jy mZ5qbH6sP9xYyzCBswi8Bbqo7ssBgkyklNPEgJftEaXz3HYu8ZvzBc1r9srp/yQ89Bk7 afUI1BLjau/0mmWNYgpS/gve1DUtzrfiVLvkLTMpWlXKOf3EVaX4QGV/z9uKB+aVOnmQ bGoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wYrKUeJ2I3rTLJ0IxsHfRaiTASuMPzZrSQLwpfM848E=; b=EOmjFs0hIvVRXyQ9QwnF58gVtbMbqhk1z4bt0RNu+Ubecj/1gnwV4FJi3XvNfLOaQx +LJcmoBC+Tvlh0TLZAqu9/ukAgMzVBIQI76gc7sJybXfy6AsAIW8MVjUImvMxAxTFJVj 541mJiLHVMJbt7NlqyILIEdkcIwhYET0lBHs01mT90CHEWBXpn6XlGwXsX+qK42euglA wIP7O+F7WI8i097a5BqKBJi846jX+WBwdOxccBdUonsBoAP5KDBXOyHU/7aEXo7NQe9l bfkbX6GzUROlDQDnXf2r/dLSFs+hkgib27KxKmj9w8mOgKTlh+Rz9v3ml6MMBKJTmMVf Y15Q==
X-Gm-Message-State: ALoCoQlFc3w3a46M3XcwR5htAfSLYK416pBJoZ43zWJXcJ32VDsd4knuvamdIw0b6ZXBPQvAsfXp
X-Received: by 10.220.59.65 with SMTP id k1mr10778366vch.22.1405095420959; Fri, 11 Jul 2014 09:17:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.27.8 with HTTP; Fri, 11 Jul 2014 09:16:39 -0700 (PDT)
In-Reply-To: <CAD5OKxthZpRdBCKSrM3HaVk2GcQVNDnqP+2ENGJt-X43oXaS+A@mail.gmail.com>
References: <CALiegf=kLtiUKoue=ahXP4fUhLJNNd8vCaQTECQxjK5R7cjLTQ@mail.gmail.com> <53B91327.50401@alvestrand.no> <CAD5OKxthZpRdBCKSrM3HaVk2GcQVNDnqP+2ENGJt-X43oXaS+A@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Fri, 11 Jul 2014 09:16:39 -0700
Message-ID: <CAOJ7v-0i1eDv5fmWHHoYecLsVW87Gh7K97AE4+Uhc5=ksdVZEg@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Content-Type: multipart/alternative; boundary="001a11c295027144fd04fded45df"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YZxmlpNERyaqmL8Z2tiuQyKmU7s
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Question about ICE-Lite server
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 11 Jul 2014 16:17:03 -0000

On Mon, Jul 7, 2014 at 12:46 PM, Roman Shpount <roman@telurix.com> wrote:

> To me this sounds like "can an endpoint participate in ICE without
>> participating in the exchange of candidates" - and my immediate reaction is
>> "if it could, it would be a security risk".
>>
>> I don't think it's possible. And I think that's a Good Thing.
>>
>>
> Since ICE-Lite server does not send any connectivity checks, it can
> operate with virtually no information about the remote side. It certainly
> does not need any information about the candidates. All it cares about that
> the other side supports ICE, if there was an ICE mismatch and if remote
> side is full or lite implementation. All checks from remote side are
> validated using the local password. If remote side is lite or does not
> support ICE media can be sent immediately, otherwise it will need to wait
> for a connectivity check with the use attribute. Very, very simple.
>
>
This seems fine to me. For ICE server implementations, there really is no
need to receive candidates from the client. All client candidates can be
generated based on incoming connectivity checks (i.e. prflx candidatates).
And yes, you would use the contents of the PRIORITY attribute to determine
the candidate priority.