Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12

Christer Holmberg <> Tue, 17 October 2017 19:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D24DC133085; Tue, 17 Oct 2017 12:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Mqv48RzgOaiN; Tue, 17 Oct 2017 12:26:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CCA08132D4E; Tue, 17 Oct 2017 12:26:29 -0700 (PDT)
X-AuditID: c1b4fb2d-bddff7000000268d-f8-59e659632c5c
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 99.C8.09869.36956E95; Tue, 17 Oct 2017 21:26:28 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0352.000; Tue, 17 Oct 2017 21:26:27 +0200
From: Christer Holmberg <>
To: Harald Alvestrand <>, "" <>
CC: "" <>
Thread-Topic: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12
Thread-Index: AQHTQRqIopdqNKi4M0G7+rZLE/Y/d6LmXBGAgAGqxYCAAG9bcA==
Date: Tue, 17 Oct 2017 19:26:27 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7n25K5LNIg4ZDXBbH+rrYLL5dqLVY +6+d3YHZ48qEK6weS5b8ZApgiuKySUnNySxLLdK3S+DKOPR7DltBj27Fh56zrA2MP7S7GDk5 JARMJN5tOs/WxcjFISRwhFHi86uL7BDOEkaJA/27mLoYOTjYBCwkuv+BNYgIeEt8/NzKBGIz C6hL3Fl8jh3EFhZwlFgy5yIjRI2TRO+jm6ww9tNzy8DGsAioSrSecgUJ8wr4Stx/94cZYtVK RonTHV/ZQBKcQHPert4FNodRQEzi+6k1ULvEJW49mc8EcbSAxJI955khbFGJl4//sULYShKN S56wguxiFtCUWL9LH6JVUWJK90N2iL2CEidnPmGZwCg6C8nUWQgds5B0zELSsYCRZRWjaHFq cXFuupGxXmpRZnJxcX6eXl5qySZGYKwc3PJbdwfj6teOhxgFOBiVeHhPhT2LFGJNLCuuzD3E KMHBrCTCq2cLFOJNSaysSi3Kjy8qzUktPsQozcGiJM7rsO9ChJBAemJJanZqakFqEUyWiYNT qoFxcZzi8vf5WReWHXi641+91vyEgisVobG6V1VKLKPl/IWZjiacYeqRN5oh8K/q9f/7/DIW ArsE1x7XzUtUZJ+qs/FBeTijGOvFpcfV9to/MBT01JRbFeCrHvPqrePzM7euFe52MpePfMhV /GRn2a9FMaxei9ubGQoeTZ39af+uN/OvH7DcfXyiEktxRqKhFnNRcSIApX3gQZECAAA=
Archived-At: <>
Subject: Re: [rtcweb] WGLC Review of draft-ietf-ice-rfc5245bis-12
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Oct 2017 19:26:32 -0000


>>> Most important points:
>>> * The protocol has been designed and revised to be usable with 
>>> non-media data, but the introduction and abstract do not reflect 
>>> this. Expunging the media bias from the body of the document is 
>>> probably not worth it, but the intro and abstract should mention it.
>> We COULD do a search/replace operation, and replace "media" with "data".
>> We would end up with terms like "data stream", "data packets" etc, but 
>> I guess that it would be ok.
>> In the "data definition" we would then describe that data includes 
>> both RTP and non-RTP data.
> I would like that! I was proposing a smaller change because it's so late in the cycle, but better is better!

Well, the cycle is moving very slowly, so... :)
>>> * Security considerations should mention the problem that ICE reveals 
>>> addresses that might otherwise remain hidden, and that this is a 
>>> privacy concern.
>> I would be glad if someone could provide text for that, to make sure 
>> we get it right.
> The paragraph I suggested in the PDF was:
> “The process of probing for candidates reveals the source addresses of the client and its peer to any on-network 
>   listening attacker, and the process of exchanging candidates reveals the addresses to any attacker that is able to 
>   see the negotiation. Some addresses, such as the server reflexive addresses gathered through the local interface 
>   of VPN users, may be sensitive information. If these potential attacks can’t be mitigated, the implementation may 
>   want to institute controls for which addresses are revealed to the negotiation and/or probing process. Such controls 
>   need to be specified as part of the ICE usage.”
> Of course, that's only my suggestion.

It's a good suggestion in my opinion. Unless someone objects, I suggest we add it to the Security Considerations.

>>> * The document has removed all the SDP specific parts (good), but the 
>>> requirements it places on the negotiation mechanism aren¹t 
>>> collectively documented anywhere. A section describing this would 
>>> help comprehension for people developing signalling protocols for use with ICE.
>> I can think of the following requirements:
>> REQ: There MUST be a mechanism for ICE agents to determine whether the 
>> remote peer supports ICE
>> REQ: There MUST be a mechanism for ICE agents to exchange candidate 
>> information
>> REQ: There MUST be a mechanism for ICE agents to indicate an ICE 
>> restart to the remote peer
> I was thinking of something like:
> The exchange of information MUST result in the following information being available to the ICE agent:
> - Whether the remote peer supports ICE at all
> - What ICE options, if any, are supported
> - Whether the remote peer is Lite or Full
> - Whether the remote peer thinks it's the Initiating Agent or not
> - What candidates the remote peer wishes to make available
> - Whether an ICE restart is desired

Looks ok, but I am not sure what mean by the 4th, regarding thinking it's the initiating agent or not.

>>> * The definition of "component" talks about a component having one 
>>> address. I believe that in current usage, it should be defined to 
>>> have an address pair. (non-symmetric RTP is dead).
>> Or, should we say "having one candidate pair"?
>> <t hangText="Component:"> A component is a piece of a data stream 
>> requiring a candidate pair; a data stream may require multiple 
>> components, each of which has to work for the data stream as a whole 
>> to work.  For media streams based on RTP, unless RTP and RTCP are 
>> multiplexed in the same port, there are two components per media 
>> stream -- one for RTP, and one for RTCP.</t>
> This works for me!

Unless someone objects, I will add it.

>> Regarding non-symmetric RTP, the spec says that the selected candidate 
>> pair MUST be used for sending and receiving media, so I guess that 
>> means symmetric RTP. Perhaps it would be good to point that out.
> Can't harm.

I will add text (unless it's already said somewhere).