Subject: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness

From: Christian Groves <[email-masked]>
Date: Wed, 08 Oct 2014 14:51:53 +1100

Hello,

I have a couple of comments on draft-ietf-rtcweb-stun-consent-freshness-07:

1) Cl.4.1/draft-ietf-rtcweb-stun-consent-freshness refers to both "ICE 
binding requests" and "STUN binding requests". Is there a distinction 
between them? e.g. "ICE binding requests" refer to 
7.1.2/draft-ietf-mmusic-rfc5245bis-02 and STUN binding request indicates 
a non-extended binding request as per RFC5389.

2) Just to confirm when Consent is first given. Is the 30sec consent 
period assumed after the initial ICE exchange? I found the second 
paragraph in cl.4.1 not so clear as it talks about subsequent consent 
before the initial consent in paragraph 5. I'd suggest modifying it 
along the lines of:
"An endpoint MUST NOT send application data (e.g., RTP, RTCP, SCTP, 
DTLS), over any transport protocol (e.g., UDP, TCP) on an ICE-initiated 
connection unless the receiving endpoint consents to receive the data.  
Initial consent is granted as a result of a successful ICE connectivity 
check on a particular transport address. Consent expires after a fixed 
amount of time. As a result, subsequent consent MUST be obtained 
following the procedure described in this document.

During ICE restart consent checks MUST continue to be sent on previously 
validated pair, and MUST be responded to on the previously validated 
pair, until ICE restart completes."

Regards, Christian

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 8 Oct 2014 06:41:10 +0000

Hi Christian,

Thanks for your comments. Please see inline

-----Original Message-----
From: Christian Groves <[email-masked]>
Date: Wednesday, 8 October 2014 9:21 am
To: "[email-masked]" <[email-masked]>
Subject: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness

>Hello,
>
>I have a couple of comments on
>draft-ietf-rtcweb-stun-consent-freshness-07:
>

We will change it to STUN binding requests to keep it consistent with the
rest of the document.

>period assumed after the initial ICE exchange?

Paragraph 4 in Section 4.1 has this text. Hope this is sufficient.

"The initial Consent to send traffic is obtained by ICE.  Consent
   expires after 30 seconds."

> I found the second

Sure will make this change.

Regards,
Ram

>
>Regards, Christian
>
>_______________________________________________
>rtcweb mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Christian Groves <[email-masked]>
Date: Thu, 09 Oct 2014 12:59:49 +1100

Hello Ram,

Thanks for the response. A further question. The draft focuses on sender 
behaviour with regards to consent, i.e. it indicates that an endpoint 
must not send data if consent hasn't been granted. What about receiver 
behaviour? E.g. what happens if the sending end point is not well 
behaved and sends application data beyond the consent period, what 
should the receiver do?

Regards, Christian

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 9 Oct 2014 06:42:53 +0000

> From: rtcweb [mailto:[email-masked]] On Behalf Of Christian
> Groves
> Sent: Thursday, October 09, 2014 7:30 AM
> To: Ram Mohan R (rmohanr); [email-masked]
> Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness
> 
> Hello Ram,
> 
> behaviour with regards to consent, i.e. it indicates that an endpoint must not
> send data if consent hasn't been granted. What about receiver behaviour?
> E.g. what happens if the sending end point is not well behaved and sends
> application data beyond the consent period, what should the receiver do ?

The receiver can use DTLS fatal error to immediately revoke the consent. But if sender does not care about consent revocation then the receiver has to rely on other techniques (like closing the FW mapping etc.).  The javascript may be malicious, hence consent checks are done by the browser (which serves as user's TCB)) and browser has to be trusted to do the right thing.

-Tiru

> >> 1) Cl.4.1/draft-ietf-rtcweb-stun-consent-freshness refers to both
> >> "ICE binding requests" and "STUN binding requests". Is there a
> >> distinction between them? e.g. "ICE binding requests" refer to
> >> 7.1.2/draft-ietf-mmusic-rfc5245bis-02 and STUN binding request
> >> indicates a non-extended binding request as per RFC5389.
> > We will change it to STUN binding requests to keep it consistent with
> > the rest of the document.
> >
> >> DTLS), over any transport protocol (e.g., UDP, TCP) on an
> >> ICE-initiated connection unless the receiving endpoint consents to receive
> the data.
> >> Initial consent is granted as a result of a successful ICE
> >> connectivity check on a particular transport address. Consent expires
> >> after a fixed amount of time. As a result, subsequent consent MUST be
> >> obtained following the procedure described in this document.
> >>
> >> During ICE restart consent checks MUST continue to be sent on
> >> previously validated pair, and MUST be responded to on the previously
> >> validated pair, until ICE restart completes."

---

From: Christian Groves <[email-masked]>
Date: Thu, 09 Oct 2014 17:50:08 +1100

Hello Tiru,

So does this mean that the receiver also has to keep track of 30 second 
consent period to be able to identify the situation?

Regards, Christian

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 09 Oct 2014 09:00:55 +0200

On 10/09/2014 08:50 AM, Christian Groves wrote:
> Hello Tiru,
>
> So does this mean that the receiver also has to keep track of 30
> second consent period to be able to identify the situation?

If the receiver cares about being flooded without its consent, the
receiver needs to detect that situation and take appropriate action.
Either by watching the 30-second timer or by some other means.

If the receiver doesn't care, it doesn't have to do anything.

I don't think the spec needs to mandate any particular reaction from the
receiver in this situation.

>> The receiver can use DTLS fatal error to immediately revoke the
>> consent. But if sender does not care about consent revocation then
>> the receiver has to rely on other techniques (like closing the FW
>> mapping etc.).  The javascript may be malicious, hence consent checks
>> are done by the browser (which serves as user's TCB)) and browser has
>> to be trusted to do the right thing.
>>
>> -Tiru
>>
>>> Regards, Christian
>>>

-- 
Surveillance is pervasive. Go Dark.

---

From: Christian Groves <[email-masked]>
Date: Thu, 09 Oct 2014 18:21:25 +1100

I don't think it should mandate a particular action but I think it would 
be good to mention some of the possibilities. As it stands nothing is 
mentioned in the draft about the role of the receiver.

If the receiver watches the 30 second timer, how does it distinguish 
between receiving a STUN binding request for the purposes of Consent 
(i.e. linked to application data signalling) and a STUN binding request 
sent for the purposes of a keep alive? I guess that it uses the fact 
that consent related STUN binding request are authenticated and 
keepalive STUN binding requests are not (as per cl.10/RFC5245. Is that 
correct?

Regards, Christian

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 9 Oct 2014 08:29:29 +0000

> Sent: Thursday, October 09, 2014 12:51 PM
> To: [email-masked]
> I don't think it should mandate a particular action but I think it would be
> good to mention some of the possibilities. As it stands nothing is mentioned
> in the draft about the role of the receiver.

The role of receiver to immediately revoke consent either using STUN error code or DTLS fatal alert is discussed in  
http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-07#section-4.2

-Tiru

> 
> If the receiver watches the 30 second timer, how does it distinguish between
> receiving a STUN binding request for the purposes of Consent (i.e. linked to
> application data signalling) and a STUN binding request sent for the purposes
> of a keep alive? I guess that it uses the fact that consent related STUN binding
> request are authenticated and keepalive STUN binding requests are not (as
> per cl.10/RFC5245. Is that correct?
> 
> Regards, Christian
> 
> > I don't think the spec needs to mandate any particular reaction from
> > the receiver in this situation.
> >
> >
> >
> >
> >> Regards, Christian
> >>
> >>>> From: rtcweb [mailto:[email-masked]] On Behalf Of
> >>>> Christian Groves
> >>>> Thanks for the response. A further question. The draft focuses on
> >>>> sender behaviour with regards to consent, i.e. it indicates that an
> >>>> endpoint must not send data if consent hasn't been granted. What
> >>>> about receiver behaviour?
> >>>> E.g. what happens if the sending end point is not well behaved and
> >>>> sends application data beyond the consent period, what should the
> >>>> receiver do ?
> >>> mapping etc.).  The javascript may be malicious, hence consent
> >>> checks are done by the browser (which serves as user's TCB)) and
> >>> browser has to be trusted to do the right thing.
> >>>
> >>> -Tiru
> >>>
> >>>> Regards, Christian
> >>>>
> >>>>> We will change it to STUN binding requests to keep it consistent
> >>>>> with the rest of the document.
> >>>>>
> >>>>>> 2) Just to confirm when Consent is first given. Is the 30sec
> >>>>>> consent period assumed after the initial ICE exchange?
> >>>>>> paragraph in cl.4.1 not so clear as it talks about subsequent
> >>>>>> consent before the initial consent in paragraph 5. I'd suggest
> >>>>>> modifying it along the lines of:
> >>>>>> "An endpoint MUST NOT send application data (e.g., RTP, RTCP,
> >>>>>> SCTP, DTLS), over any transport protocol (e.g., UDP, TCP) on an
> >>>>>> connectivity check on a particular transport address. Consent
> >>>>>> expires after a fixed amount of time. As a result, subsequent
> >>>>>> consent MUST be obtained following the procedure described in this
> document.
> >>>>>>
> >>>>>> previously validated pair, and MUST be responded to on the
> >>>>>> previously validated pair, until ICE restart completes."

---

From: Christian Groves <[email-masked]>
Date: Thu, 09 Oct 2014 20:49:31 +1100

Hello Tiru,

I've seen that text but it talks about the receiving endpoint of a STUN 
binding response. I was referring to the endpoint that receives the STUN 
binding request and sends the response. The draft concentrates on the 
STUN binding request initiator and its notion of consent. It doesn't 
explain what notion of consent that the receiver of the STUN binding 
request. E.g. a STUN binding request receiver may close the connection 
which leads to an immediate revokation but it doesn't mean it has the 
notion of consent. As Harald indicates below the receiver may not care 
at all about it.

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 9 Oct 2014 12:18:39 +0000

Hi,

Why would the receiver have to do anything? Each endpoint uses consent checks to verify that it can SEND media.

Also, keep in mind that if the remote peer is ICE lite, it won't send any consent checks.

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: 9. lokakuuta 2014 12:50
To: Tirumaleswar Reddy (tireddy); [email-masked]
Subject: Re: [rtcweb] Question on draft-ietf-rtcweb-stun-consent-freshness

Hello Tiru,

I've seen that text but it talks about the receiving endpoint of a STUN binding response. I was referring to the endpoint that receives the STUN binding request and sends the response. The draft concentrates on the STUN binding request initiator and its notion of consent. It doesn't explain what notion of consent that the receiver of the STUN binding request. E.g. a STUN binding request receiver may close the connection which leads to an immediate revokation but it doesn't mean it has the notion of consent. As Harald indicates below the receiver may not care at all about it.

Regards, Christian

On 9/10/2014 7:29 PM, Tirumaleswar Reddy (tireddy) wrote:
>> I don't think it should mandate a particular action but I think it 
>> would be good to mention some of the possibilities. As it stands 
>> nothing is mentioned in the draft about the role of the receiver.
> The role of receiver to immediately revoke consent either using STUN 
> error code or DTLS fatal alert is discussed in
>> (i.e. linked to application data signalling) and a STUN binding 
>> request sent for the purposes of a keep alive? I guess that it uses 
>> the fact that consent related STUN binding request are authenticated 
>> and keepalive STUN binding requests are not (as per cl.10/RFC5245. Is that correct?
>>
>> Regards, Christian
>>
>>>>>> sender behaviour with regards to consent, i.e. it indicates that 
>>>>>> an endpoint must not send data if consent hasn't been granted. 
>>>>>> What about receiver behaviour?
>>>>>> E.g. what happens if the sending end point is not well behaved 
>>>>>> and sends application data beyond the consent period, what should 
>>>>>> the receiver do ?
>>>>>>>> 1) Cl.4.1/draft-ietf-rtcweb-stun-consent-freshness refers to 
>>>>>>>> both "ICE binding requests" and "STUN binding requests". Is 
>>>>>>>> there a distinction between them? e.g. "ICE binding requests" 
>>>>>>>> refer to

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 09 Oct 2014 15:35:48 +0200

On 10/09/2014 11:49 AM, Christian Groves wrote:
> Hello Tiru,
>
> I've seen that text but it talks about the receiving endpoint of a 
> STUN binding response. I was referring to the endpoint that receives 
> the STUN binding request and sends the response.

Aha - I was thinking that the "receiver" was the media receiver (the one 
who cares whether he's being DOSed or not), you were talking about the 
receiver of the STUN binding request.

> The draft concentrates on the STUN binding request initiator and its 
> notion of consent. It doesn't explain what notion of consent that the 
> receiver of the STUN binding request.
I think that's simple.

The receiver of the STUN binding request has no business trying to 
figure out why it got a binding request. Its business is to answer it.

It's the initiator who knows why the request was sent.

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Fri, 10 Oct 2014 09:33:09 +0530

> Also, keep in mind that if the remote peer is ICE lite, it won't send any

​Given the security issue with ICE lite, I am wondering whether we should
deprecate it going forward. It was originally conceived as an initial step
towards a full ICE implementation, but I think we didn't have WebRTC then :)

Muthu

> binding request and sends the response. The draft concentrates on the STUN
> binding request initiator and its notion of consent. It doesn't explain
> what notion of consent that the receiver of the STUN binding request. E.g.
> a STUN binding request receiver may close the connection which leads to an
> immediate revokation but it doesn't mean it has the notion of consent. As
> Harald indicates below the receiver may not care at all about it.
>
> Regards, Christian
>