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

["Ram Mohan R (rmohanr)" <[e-mail]>]

Hi Christer,

Thanks for your review. Please see inline

-----Original Message-----
From: Christer Holmberg <[e-mail]>
Date: Monday, 27 October 2014 11:40 pm
To: Cisco Employee <[e-mail]>, "[e-mail]" <[e-mail]>
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
>