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

From: Harald Alvestrand <[email-masked]>
Date: Mon, 9 Oct 2017 18:19:56 +0200

I have read through draft-ietf-ice-rfc5245bis-12 - both as a generic
reviewer and with the perspective of "does this do what RTCWEB requires".

I believe this document is good enough to publish, but could be improved
somewhat (usually, all documents can).

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.
* Security considerations should mention the problem that ICE reveals
addresses that might otherwise remain hidden, and that this is a privacy
concern.
* 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.
* 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).

The rest of my suggested changes are nits, I think.

I enclose the full text of my review as PDF; apart from the stuff above,
I don't think those comments needs much WG discussion. Editor: Please
raise issues if you think some do need it!

Hope this is helpful.

Harald

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Oct 2017 16:39:21 +0000

Hi Harald,

Thank you VERY much! :)

I do agree that the document could still be improved, and if I had the time and cycles... But, we need to draw the line somewhere, and that’s why it is important that people read the document in case there is something they think still needs to be fixed.

Regards,

Christer

Sent from my iPhone

> On 9 Oct 2017, at 19.20, Harald Alvestrand <[email-masked]> wrote:
> 
> <ICE BIS rfc5245bis-12 review.pdf>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Oct 2017 10:02:09 +0000

Hi Harald,

Some feedback on your comments.

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

>addresses that might otherwise remain hidden, and that this is a privacy

I would be glad if someone could provide text for that, to make sure we
get it right.

>requirements it places on the negotiation mechanism aren¹t collectively

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

>* The definition of ³component² talks about a component having one

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>

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.

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 17 Oct 2017 16:36:15 +0200

> In the ³data definition² we would then describe that data includes both

I would like that! I was proposing a smaller change because it's so late
in the cycle, but better is better!

> I would be glad if someone could provide text for that, to make sure we

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.

> REQ: There MUST be a mechanism for ICE agents to indicate an ICE restart

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

> stream -- one for RTP, and one for RTCP.</t>

This works for me!

> symmetric RTP. Perhaps it would be good to point that out.

Can't harm.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Oct 2017 19:26:27 +0000

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

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

>>> 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.
>> 
>> REQ: There MUST be a mechanism for ICE agents to indicate an ICE 
>> restart to the remote peer
>
> The exchange of information MUST result in the following information being available to the ICE agent:
>

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"?
>> 
>> 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 

Unless someone objects, I will add it.

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

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 17 Oct 2017 21:32:19 +0200

Leaving in only the one with something left to write...

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

The spec says that the initiating agent will take the CONTROLLING role
if both parties are Full ICE implementations, or if both parties are
Lite implementations. This means that it has to know that it's the
initiating agent.

In cases like Offer/Answer (without glare), it's simple to see which one
is initiating. In cases with 3rd party control (both parties get called
for setup), chat-line systems (both parties initiate a join) or
protocols where glare is possible, something has to make the decision on
which side has the Initiator role.

I'd prefer to abandon the Initiator concept, and say that the exchange
of information should give back the information to each about whether
they should try to take the Controlling role, but that may be a larger
rewrite.

---

From: Peter Thatcher <[email-masked]>
Date: Sat, 28 Oct 2017 17:47:53 +0000

I looked through all of Harald's suggestions and I reviewed the PRs since
then, and it appears to me that most, if not all, of Harald's suggestions
have been incorporated into the doc.

Do the two of you agree, or is there something still missing that we need
to do?

On Tue, Oct 17, 2017 at 12:32 PM Harald Alvestrand <[email-masked]>
wrote:

> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 28 Oct 2017 21:23:16 +0200

I think the rewrites done are entirely satisfactory. There's always things one can quibble about, but finishing is valuable. On to IETF Last Call!

Den 28. oktober 2017 19:47:53 CEST, skrev Peter Thatcher <[email-masked]>:
>> > Looks ok, but I am not sure what mean by the 4th, regarding
>thinking
>> it's the initiating agent or not.
>> >
>> >
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.