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

[Harald Alvestrand <[e-mail]>]

Den 16. okt. 2017 12:02, skrev Christer Holmberg:
> Hi Harald,
> 
> Some feedback on your comments.
> 
>> 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!

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

> 
>> * 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

> 
> 
>> * 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!

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

> 
> Regards,
> 
> Christer
>