Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Mon, 25 Aug 2014 20:03:52 +0530

An ICE-lite entity by definition doesn't generate STUN requests which means
it doesn't perform consent freshness as described in the draft. If it does,
it is not a ICE-lite entity. You have only two types of entities to interop
test with. I don't see any use of specifying a MUST NOT for ICE-lite.

Muthu

On Mon, Aug 25, 2014 at 6:13 PM, Roman Shpount <[email-masked]> wrote:

> On Mon, Aug 25, 2014 at 6:55 AM, Muthu Arul Mozhi Perumal <
> [email-masked]> wrote:
>
>> I thought a "SHOULD perform" is more appropriate for a WebRTC device as
>> it doesn't implement the public API and might run a proprietary/native app
>> running in a constrained environment and the overhead of performing the
>> periodic consent might overweigh the benefits. However, I don't have an
>> issue of making it a MUST -- at least no one has objected so far. I hear
>> the following options from the discussions so far:
>>
>> Option 1:
>> WebRTC browser - MUST
>> WebRTC device - MUST
>> Other (WebRTC/non-WebRTC) entities - MAY
>>
>> Option 2:
>> Any WebRTC entity doing full ICE - MUST
>> Other (WebRTC/non-WebRTC) entities - MAY
>>
>>
>>
> To be clear, my opinion is
>
> Any WebRTC entity implementing full ICE - MUST
> Any WebRTC entity (such as WebRTC gateway) implementing ICE-lite -- MUST
> NOT
>
> This way we are not inventing entity types and not defining behaviors
> which would never be used (such as sending consent from an end point which
> would send no STUN requests otherwise). This will also reduce the number of
> interop cases from four (full ICE with consent, full iCE without consent,
> ICE-lite, ICE-lite with consent) to only two (full ICE with consent,
> ICE-lite).
> _____________
> Roman Shpount
>
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 25 Aug 2014 10:49:09 -0400

On Mon, Aug 25, 2014 at 10:33 AM, Muthu Arul Mozhi Perumal <
[email-masked]> wrote:

> An ICE-lite entity by definition doesn't generate STUN requests which
> means it doesn't perform consent freshness as described in the draft. If it
> does, it is not a ICE-lite entity. You have only two types of entities to
> interop test with. I don't see any use of specifying a MUST NOT for
> ICE-lite.
>
>
>
This is exactly what I am saying. All full ICE end points for WebRTC must
implement consent freshness. We should not specify consent freshness for
ICE-lite (as it is not specified right now), and we should not define a
special type of end points which will not send consent freshness requests
just because they are ICE-lite (since they already cannot send it).
_____________
Roman Shpount

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Mon, 25 Aug 2014 20:22:09 +0530

Agree.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 25 Aug 2014 15:08:30 +0000

ICE RFC 5245 says ICE-lite clients don’t do candidate gathering+connectivity checks, it does NOT explicitly talks about NOT using STUN for other purpose like consent freshness.
Yes, consent freshness uses the same STUN messages. That should not be a reason to exclude ICE-lite clients from consent freshness checks.

ICE-lite endpoints have same security concerns as ICE-full endpoints. IMHO, independent of STUN connectivity checks, the draft should allow ICE-lite client to do consent freshness, which means the other end (ICE-full or ICE-lite) should acknowledge the STUN requests sent by ICE-lite clients. I believe this is already supported by Chrome and Firefox.

BR
Raju

From: rtcweb [mailto:[email-masked]] On Behalf Of Muthu Arul Mozhi Perumal
Sent: Monday, August 25, 2014 9:52 AM
To: Roman Shpount
Cc: [email-masked]
Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

Agree.

On Mon, Aug 25, 2014 at 8:19 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Aug 25, 2014 at 10:33 AM, Muthu Arul Mozhi Perumal <[email-masked]<mailto:[email-masked]>> wrote:
An ICE-lite entity by definition doesn't generate STUN requests which means it doesn't perform consent freshness as described in the draft. If it does, it is not a ICE-lite entity. You have only two types of entities to interop test with. I don't see any use of specifying a MUST NOT for ICE-lite.

This is exactly what I am saying. All full ICE end points for WebRTC must implement consent freshness. We should not specify consent freshness for ICE-lite (as it is not specified right now), and we should not define a special type of end points which will not send consent freshness requests just because they are ICE-lite (since they already cannot send it).
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 25 Aug 2014 12:51:42 -0400

On Mon, Aug 25, 2014 at 11:08 AM, Makaraju, Maridi Raju (Raju) <
[email-masked]> wrote:

>  ICE RFC 5245 says ICE-lite clients don’t do candidate
> gathering+connectivity checks, it does NOT explicitly talks about NOT using
> STUN for other purpose like consent freshness.
>
> Yes, consent freshness uses the same STUN messages. That should not be a
> reason to exclude ICE-lite clients from consent freshness checks.
>
>
>
> ICE-lite endpoints have same security concerns as ICE-full endpoints.
> IMHO, independent of STUN connectivity checks, the draft should allow
> ICE-lite client to do consent freshness, which means the other end
> (ICE-full or ICE-lite) should acknowledge the STUN requests sent by
> ICE-lite clients. I believe this is already supported by Chrome and Firefox.
>
>
>

If someone goes through the trouble of implementing sending STUN bind
requests needed for consent freshness, why would not they implement full
ICE? Incremental work (ie state machine) is not that great.

Sending consent freshness or any other STUN requests is not prohibited by
ICE-lite clients, but it is not defined anywhere either. Let's not define
something which has no reason to exist.
_____________
Roman Shpount

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 25 Aug 2014 17:08:23 +0000

From: Roman Shpount [mailto:[email-masked]]
Sent: Monday, August 25, 2014 11:52 AM

On Mon, Aug 25, 2014 at 11:08 AM, Makaraju, Maridi Raju (Raju) <[email-masked]<mailto:[email-masked]>> wrote:
ICE RFC 5245 says ICE-lite clients don’t do candidate gathering+connectivity checks, it does NOT explicitly talks about NOT using STUN for other purpose like consent freshness.
Yes, consent freshness uses the same STUN messages. That should not be a reason to exclude ICE-lite clients from consent freshness checks.

If someone goes through the trouble of implementing sending STUN bind requests needed for consent freshness, why would not they implement full ICE? Incremental work (ie state machine) is not that great.
<Raju2>
IMO, ICE gathering, connectivity checks, prioritization etc. is much more work than doing just consent checks.
ICE-lite entities (please note gateways in specific) don’t implement ICE-full because they can get away with ICE-lite due to presence of public ip. Why complicate an implementation unnecessarily?
</Raju2>

Sending consent freshness or any other STUN requests is not prohibited by ICE-lite clients, but it is not defined anywhere either. Let's not define something which has no reason to exist.
<Raju2>
IMHO, consent checks for ICE-lite have a security reason to exist; the same security reason why ICE-full clients needed it. Isn’t draft-ietf-rtcweb-stun-consent-freshness right place to define this?
</Raju2>

BR
Raju
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 25 Aug 2014 14:20:05 -0400

On Mon, Aug 25, 2014 at 1:08 PM, Makaraju, Maridi Raju (Raju) <
[email-masked]> wrote:

>  *IMO, ICE gathering, connectivity checks, prioritization etc. is much
> more work than doing just consent checks.*
>
> *ICE-lite entities (please note gateways in specific) don’t implement
> ICE-full because they can get away with ICE-lite due to presence of public
> ip. Why complicate an implementation unnecessarily?*
>
>
If the end-point is located on a public IP, ICE gathering and
prioritization are trivial. The benefits of aggressive nomination, which is
present in full ICE, on the other hand, are quite significant. ICE-full
should be recommended anyway.

> *IMHO, consent checks for ICE-lite have a security reason to exist; the
> same security reason why ICE-full clients needed it. Isn’t
> draft-ietf-rtcweb-stun-consent-freshness right place to define this?*
>
>
> I would prefer no mongrel ICE end points to be defined since I would
prefer never to test against them.
_____________
Roman Shpount