Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 12 Nov 2014 16:16:21 +0000

Hi Christer,

Thanks for your review. Please see inline

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Date: Monday, 27 October 2014 11:40 pm
To: Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [rtcweb] I-D Action:
draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions

>Hi,
>
>Thanks for putting together the new version! It makes a number of things
>more clear :)
>
>I do still have a few comments/questions (hopefully editorial ones),
>though:
>
>Q1:
>-----
>
>I think it would be good to explicitly clarify that, when consent expires
>on a 5-tuple/candidate pair, it does not affect other 5-tuples within the
>session. I have received questions on that, so I think some words would
>be useful to make it more clear.
>
>(Of course, one CAN choose to terminate the whole session if consent
>expires on a candidate pair, but that depends on application policy).

Section 4.1 5th paragraph currently has this text:

"if a valid STUN binding response
   corresponding to any STUN request sent in the last 30 seconds has not
   been received from the remote peer's transport address, the endpoint
   MUST cease transmission on that 5-tuple.²

When Consent expires it is up to the application policy to decide on what
to do. As you said it can choose to terminate the whole session or
continue sending data on other 5-tuples. In this draft we should just say
that the endpoint stops transmission on that 5-tuple for which consent
failed which is what the above text in the draft says. IMO that is
sufficient.

>
>
>Q2:
>-----
>
>If consent expires, and I stop sending application data, will I still
>send STUN keep-alives etc, to keep the candidate pair, NAT bindings etc
>alive? 
>
>There IS text saying:
>
>	"An endpoint that is not sending any application data does not need to
>   	maintain consent.  However, the endpoint needs to ensure its NAT or
>   	firewall mappings persist which can be done using keepalive or other
>   	techniques (see Section 10 of [RFC5245] and see [RFC6263])."
>
>However, that seems to be more related to cases where I don't intend to
>send application data to begin with.
>
>So, perhaps the text above can be modified, to clarify that keepalives
>etc will still be sent if consent expires.

Applications can continues to do what they were doing as part of STUN/ICE
(like
sending STUN binding indications for NAT/FW keepalives or whatever).
 If some application wants to act on Consent expiry and do some thing it
can do so however such a thing
is not in the scope of this draft. So IMO this is outside scope of this
draft and is a application policy.

>
>
>Q3:
>-----
>
>Section 4.1. says:
>
>	"If the endpoint wants to send application data, it needs to first obtain
>   	consent if its consent has expired."
>
>If my consent has expired, is the a time period before I can try to
>obtain consent again? Can I just continue sending STUN binding requests
>even if my consent expires, and wait to obtain consent again?

After consent fails, browser notifies the java script and there should be
no mechanism available for java script to again tell the browser to start
all over again (consider a malicious java script); IMO consent can be only
be re-started with ICE-restart.

>
>(I obviously won't send any application data until I obtain consent
>again.)
>
>
>Q4:
>-----
>
>When my consent expires, is it considered an error if I also choose to
>not receive any data? If not, I think it would be good to indicate that
>one may choose to also stop receiving data in case consent expires.

Consent check only deals with whether to send media or not. If Consent
fails it is up the application to decide on what other actions it need to
take (like stopping receiving media e.t.c)

>
>
>Q5:
>-----
>
>Assuming I send RTP and RTCP on separate 5-tuples, and consent expires on
>one of the 5-tuples. I assume that will impact both 5-tuples, and in that
>case I think it would be good to clarify.

Again this is application specific behaviour. If consent fails for one
5-tuple,
the application can choose to stop data on related 5-tuples as well. Don’t
see
a need to have such a text in this draft. We will have to document several
such application behaviours
 if we start to do.

Regards,
Ram

>Thanks!
>Regards,
>Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 18 Nov 2014 16:40:57 +0000

Hi,

In general, it seems like you want to leave out text just because it is "application specific". In my experience, if something is application specific, it should be stated. Otherwise people will argue in future about who is right and wrong.

Please see inline for more.

>>Thanks for putting together the new version! It makes a number of 
>>things more clear :)
>>
>>I think it would be good to explicitly clarify that, when consent 
>>expires on a 5-tuple/candidate pair, it does not affect other 5-tuples 
>>within the session. I have received questions on that, so I think some 
>>words would be useful to make it more clear.
>>
> When Consent expires it is up to the application policy to decide on what to do. As you said 
> it can choose to terminate the whole session or continue sending data on other 5-tuples. In this 
> draft we should just say that the endpoint stops transmission on that 5-tuple for which consent 
> failed which is what the above text in the draft says. IMO that is sufficient.

I think it would be good to have some text regarding the impact on other 5-tuples. Something like:

"When consent expires for data sent on a given 5-tuple, the impact on data sent on other 5-tuples
associated with the session is application specific. Applications might choose to send data on other 5-tuples,
or they might choose to stop sending media on all 5-tuples associated with the session (and possibly
terminate the session." 

> Applications can continues to do what they were doing as part of STUN/ICE (like sending STUN 
> binding indications for NAT/FW keepalives or whatever). If some application wants to act on Consent 
> expiry and do some thing it can do so however such a thing is not in the scope of this draft. So IMO this 
> is outside scope of this draft and is a application policy.

Below (Q3) you say that ICE restart would be required after consent expiration, so I guess that means that one should NOT send keep-alives etc.

> After consent fails, browser notifies the java script and there should be no mechanism available 
> for java script to again tell the browser to start all over again (consider a malicious java script); IMO 
> consent can be only be re-started with ICE-restart.

First, Consent can be used by other devices than browsers :)

Second, IF ICE-restart is required, I think the draft should state so.

Third: IF ICE-restart is required, then I don't think keep-alives etc would be needed once consent expires (see Q2 above).

> Consent check only deals with whether to send media or not. If Consent fails it is up the application to 
> decide on what other actions it need to take (like stopping receiving media e.t.c)

Again, I think all these "application decisions" should be stated in the draft :)

Also, if ICE restart is required in order to start sending media again, it seems a little strange that one would still continue to receive media. Or?

>>Q5:
>>-----
>>
>>Assuming I send RTP and RTCP on separate 5-tuples, and consent expires 
>>on one of the 5-tuples. I assume that will impact both 5-tuples, and in 
>>that case I think it would be good to clarify.
>
> Again this is application specific behaviour. If consent fails for one 5-tuple, the application can choose 
> to stop data on related 5-tuples as well. Don't see a need to have such a text in this draft. We will have to 
> document several such application behaviours  if we start to do.

See above regarding application decisions.

Regards,

Christer

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 20 Nov 2014 04:41:02 +0000

Hi Christer,

Please see inline

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Date: Tuesday, 18 November 2014 10:10 pm
To: Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [rtcweb] I-D Action:

>Hi,
>
>In general, it seems like you want to leave out text just because it is
>"application specific". In my experience, if something is application
>specific, it should be stated. Otherwise people will argue in future
>about who is right and wrong.
>

Sure. I will update the above text in the next revision.

>Below (Q3) you say that ICE restart would be required after consent
>expiration, so I guess that means that one should NOT send keep-alives
>etc.
>
>
>>>Q3:
>>>-----
>>>
>>>Section 4.1. says:
>>>

Sure. Agree

>Third: IF ICE-restart is required, then I don't think keep-alives etc
>would be needed once consent expires (see Q2 above).

I take back that. It should not be ICE-restart I guess, since as per the
explanation in http://tools.ietf.org/html/rfc5245#section-9.1.1.1 for
ICE-restart an endpoint may continue to send media on previously selected
5-tuple which is not the case here. In our case once Consent fails we just
stop sending media on that 5-tuple.
I guess brand new media session is required and the application has to do
offer/answer and do ICE again for that tuple.  If we go by that no
Keepalives are needed. We can add some text for that.

>>fails it is up the application to
>Also, if ICE restart is required in order to start sending media again,
>it seems a little strange that one would still continue to receive media.
>Or?

I don’t think we can mandate applications to stop receiving media as well
if consent fails. Consent is for only sending data.

>>5-tuple, the application can choose

So I can add the below line:

"If consent fails for one 5-tuple, the application can choose
to stop data on related 5-tuples as well or continue”.

Regards,
Ram

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Nov 2014 23:19:20 -0800

It is really hard following these threads, but it looks like this is being
over-thought.

"This document defines what it takes to obtain, maintain, and lose consent
to send. Consent to send applies to a single 5-tuple. What applications
choose to do with this information is not described in this document."

Add that to the introduction perhaps. We run the risk of expanding scope
otherwise.

As for the question of re-acquisition of consent, I think that we should
keep it simple. For this:

"After consent is lost for any reason, the same ICE credentials MUST NOT be
used on the affected 5-tuple again. That means that a new session, or an
ICE restart at least, is needed to obtain consent to send."

Better to keep the rule simple, and we don't want to leave an option open
for a packet-drop-based attack here.

And one more thing ...

> >>>etc will still be sent if consent expires.

I think that we should consider akeep alive as application data, and
subject to to rules of consent.

The text should note that firewall and NAT bindings could be lost, instead.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Nov 2014 16:28:58 +0000

Hi Martin,

>It is really hard following these threads, but it looks like this is being over-thought.
>
>"This document defines what it takes to obtain, maintain, and lose consent to send. Consent 
>to send applies to a single 5-tuple. What applications choose to do with this information is not 
>described in this document."
>
>Add that to the introduction perhaps. We run the risk of expanding scope otherwise.

I agree that we don't need to specify application behaviour. But, I think we do need to be clear regarding the impacts on the transport/ICE layer, when/if/how it can be later re-used etc.

>As for the question of re-acquisition of consent, I think that we should keep it simple. For this:
>
>"After consent is lost for any reason, the same ICE credentials MUST NOT be used on the affected 5-tuple again. 
>That means that a new session, or an ICE restart at least, is needed to obtain consent to send."

My question is how/if the consent lost impacts "normal" ICE (STUN keep-alives etc), transport layer heartbeats etc.

Also, as the entity may still receive media on the 5-tuple, that also means it still have to respond to incoming STUN requests etc.

I think that should be clear in the draft. 

>I think that we should consider a keep alive as application data, and subject to rules of consent.

I am ok with such approach, as long as we document it :)

What about DTLS heartbeats, and other information sent on the transport layer? I ASSUME the entity will maintain those, as it still may receive media

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Nov 2014 16:47:28 +0000

Hi Ram,

>>>>send STUN keep-alives etc, to keep the candidate pair, NAT bindings 
>>>>etc alive?
>>>>
>>>>There IS text saying:>
>>>>
>>>>However, that seems to be more related to cases where I don't intend 
>>>>to send application data to begin with.
>>>>
>>>>So, perhaps the text above can be modified, to clarify that 
>>>>keepalives etc will still be sent if consent expires.
>>>
>>>
>>> Applications can continues to do what they were doing as part of 
>>>STUN/ICE (like sending STUN  binding indications for NAT/FW keepalives 
>>>or whatever). If some application wants to act on Consent  expiry and 
>>>do some thing it can do so however such a thing is not in the scope of 
>>>this draft. So IMO this  is outside scope of this draft and is a 
>>>application policy.
>>
>>>>	"If the endpoint wants to send application data, it needs to first 
>>>>      obtain consent if its consent has expired."
>>>>
>>>>obtain consent again? Can I just continue sending STUN binding 
>>>>requests even if my consent expires, and wait to obtain consent again?
>>>
>>> After consent fails, browser notifies the java script and there 
>>> should be no mechanism available  for java script to again tell the 
>>> browser to start all over again (consider a malicious java script); 
>>> IMO  consent can be only be re-started with ICE-restart.
>>
> I take back that. It should not be ICE-restart I guess, since as per the explanation in 
> http://tools.ietf.org/html/rfc5245#section-9.1.1.1 for ICE-restart an endpoint may 
> continue to send media on previously selected 5-tuple which is not the case here. 
> In our case once Consent fails we just stop sending media on that 5-tuple.
> I guess brand new media session is required and the application has to do offer/answer 
> and do ICE again for that tuple.  If we go by that no Keepalives are needed. We can add some text for that.

See my reply to Martin's e-mail.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Nov 2014 15:33:54 -1000

> I agree that we don't need to specify application behaviour. But, I think we do need to be clear regarding the impacts on the transport/ICE layer, when/if/how it can be later re-used etc.

How is my response unclear exactly?  IF NOT connectivity check, then
NO DON'T SEND.

> My question is how/if the consent lost impacts "normal" ICE (STUN keep-alives etc), transport layer heartbeats etc.

I don't understand this concern.  You can't use the credentials (see
above), and you can't send anything else.  That's a terminal
condition.

> Also, as the entity may still receive media on the 5-tuple, that also means it still have to respond to incoming STUN requests etc.

This is one of those "application layer" things.  If you want to cease
your own consent in response to losing consent, that's your choice.
We already say that connectivity check responses (connectivity checks
as a whole, actually) aren't subject to consent.

Though there is a real mistake in the draft here:

OLD:
   An endpoint MUST NOT send paced STUN connectivity checks toward any
   transport address unless the receiving endpoint consents to receive
   data.  That is, no application data (e.g., RTP or DTLS) can be sent
NEW:
   An endpoint MUST NOT send data other than paced STUN connectivity
checks or responses toward any
   transport address unless the receiving endpoint consents to receive
   data.  That is, no application data (e.g., RTP or DTLS) can be sent

I'll generate a PR if my co-authors don't get to it.  I don't know how
that happened.

> What about DTLS heartbeats, and other information sent on the transport layer? I ASSUME the entity will maintain those, as it still may receive media

That is unquestionably application-layer data.

The upshot here is that you will probably break RTP because you can't
generate an RR.  You can't generate SCTP acknowledgements either.
Fact is, virtually all protocols are bidirectional and will break if
one party can't send.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Nov 2014 16:03:19 -1000

Please see https://github.com/Draft-Mafia/IETF-drafts/pull/8

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Nov 2014 02:15:07 +0000

Hi,

> I don't understand this concern.  You can't use the credentials (see above), and you can't send anything else.  That's a terminal condition.

So, we need to add text explicitly saying that the credentials can no longer be used, once consent has expired. That makes it clear that one cannot simply "wait for a while", and then start sending media again...

>   An endpoint MUST NOT send data other than paced STUN connectivity checks or responses toward any

Looks good.

>> What about DTLS heartbeats, and other information sent on the 
>> transport layer? I ASSUME the entity will maintain those, as it still 
>> may receive media
>
> The upshot here is that you will probably break RTP because you can't generate an RR.  You can't generate SCTP acknowledgements either.
> Fact is, virtually all protocols are bidirectional and will break if one party can't send.

So, adding a few words about that would be useful, to inform people. Because, as you say, expired consent for sending media will often cause trouble also for received media.

Regards,

Christer

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 21 Nov 2014 05:28:10 +0000

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Date: Friday, 21 November 2014 7:45 am
To: Martin Thomson <[email-masked]>
Cc: Cisco Employee <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [rtcweb] I-D Action:

>>above), and you can't send anything else.  That's a terminal condition.
>
>So, we need to add text explicitly saying that the credentials can no
>longer be used, once consent has expired. That makes it clear that one
>cannot simply "wait for a while", and then start sending media again...
>

+1.

Looks this text was broken in ver 08. Ver 07 has proper text.

Ram

>So, adding a few words about that would be useful, to inform people.
>Because, as you say, expired consent for sending media will often cause
>trouble also for received media.
>
>Regards,
>
>Christer
>
>