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

[Christer Holmberg <[e-mail]>]

Hi,

>>> 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).

Regards,

Christer