Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 1 May 2015 09:15:34 +0000

Hi Alissa,

Thanks for your review. Please see inline for my responses.

-----Original Message-----
From: Alissa Cooper <[email-masked]>
Date: Friday, 1 May 2015 6:02 am
To: "[email-masked]" <[email-masked]>
Subject: [rtcweb] AD evaluation:
draft-ietf-rtcweb-stun-consent-freshness-11

>I have reviewed draft-ietf-rtcweb-stun-consent-freshness-11 in
>preparation for IETF LC. The document is in good shape and I will request
>the last call shortly. I have a couple of questions I¹d like to discuss
>while the last call is ongoing, though. I¹m not entirely caught up on
>mailing list traffic so apologies if these questions/comments have
>already been discussed.
>
>Section 4.1:
>"An endpoint that is not sending any application data does not need to
>   maintain consent.  However, failure to send could cause any NAT or
>   firewall mappings for the flow to expire.  Furthermore, having one
>   peer unable to send is detrimental to many protocols."
>
>It sounds like the unstated implication here is that if you are such an
>endpoint, you should keep doing consent checks anyway to maintain
>consent. Should that be stated explicitly, or am I misunderstanding?

This is for endpoints that does not send any application data. In such
cases there may be endpoints that may not send consent. We discussed about
mandating sending consent always but there was objections to that in WG
and this statement was introduced to give flexibility so that endpoints
that does not intend to send any data on a 5-tuple may choose not to
maintain consent and can use ICE keepalives
http://tools.ietf.org/html/rfc5245#section-10.

>
>Section 7:
>The normative MAY here seems odd. It seems like this section could be
>replaced with:
>
>"The W3C specification [cite] may provide an API hook that generates an
>event when consent has expired for a given 5-tuple, meaning that
>transmission of data has ceased.  This could indicate what application
>data is affected, such as media or data channels.²

I am fine with changing this.

Regards,
Ram

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 1 May 2015 09:54:42 -0700

On 30 April 2015 at 17:32, Alissa Cooper <[email-masked]> wrote:
> It sounds like the unstated implication here is that if you are such an endpoint, you should keep doing consent checks anyway to maintain consent. Should that be stated explicitly, or am I misunderstanding?

Can you tell that this is my text?

Yep, the unspoken implication is that if you stop maintaining consent,
a flow is highly likely to break.  I'm OK with making that explicit.

... .  Absent better information about the network, an endpoint SHOULD
maintain consent if there is any possibility that a flow might be
needed again.

(Thanks for the suggestion on Sec7.  I wasn't happy with it before.)

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 1 May 2015 14:44:01 -0400

I did notice one other odd thing though, in Section 4.1:

   Consent expires after 30 seconds.  That is, 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.  STUN consent responses
   received after consent expiry do not re-establish consent, and may be
   discarded or cause an ICMP error....

   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, is needed to obtain consent to send.

[BA] I am curious about the reasons behind this text.  Is there a security
vulnerability that this addresses?  From a transport point of view, 30
second outages are quite possible on the Internet due to routing transients
and so will introduce some brittleness, effectively requiring an ICE
restart (with attendant re-gathering).  As a counter-example, congestion
controlled protocols such as TCP do not give up this quickly.  So I'm
wondering if this is taking on a function better handled in circuit
breakers/congestion control specifications.

On Thu, Apr 30, 2015 at 8:32 PM, Alissa Cooper <[email-masked]> wrote:

> I have reviewed draft-ietf-rtcweb-stun-consent-freshness-11 in preparation
> for IETF LC. The document is in good shape and I will request the last call
> shortly. I have a couple of questions I’d like to discuss while the last
> call is ongoing, though. I’m not entirely caught up on mailing list traffic
> so apologies if these questions/comments have already been discussed.
>
> Section 4.1:
> endpoint, you should keep doing consent checks anyway to maintain consent.
> Should that be stated explicitly, or am I misunderstanding?
>
> Section 7:
> transmission of data has ceased.  This could indicate what application data
> is affected, such as media or data channels.”
>
> Alissa

---

From: Martin Thomson <[email-masked]>
Date: Fri, 1 May 2015 13:06:18 -0700

On 1 May 2015 at 11:44, Bernard Aboba <[email-masked]> wrote:
> and so will introduce some brittleness, effectively requiring an ICE restart
> (with attendant re-gathering).  As a counter-example, congestion controlled
> protocols such as TCP do not give up this quickly.  So I'm wondering if this
> is taking on a function better handled in circuit breakers/congestion
> control specifications.

There was a long discussion on this point and this only documents the
conclusion.  My recollection is that the concern is a robustness one,
not a security one.

See the thread here:
https://mailarchive.ietf.org/arch/msg/rtcweb/O1Hk9vFmfj4VnKLxyrBw029Hw4M

Sorry about the length, we're short on brevity, it seems.

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 1 May 2015 16:19:34 -0700

> maintain consent if there is any possibility that a flow might be

WFM

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 4 May 2015 05:27:10 +0000

Hi Alissa/ all,

Attached is the diffs with the comments incorporated. Please let me know
if its fine.

Regards,
Ram

-----Original Message-----
From: Alissa Cooper <[email-masked]>
Date: Saturday, 2 May 2015 4:49 am
To: Martin Thomson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [rtcweb] AD evaluation:

>>> It sounds like the unstated implication here is that if you are such
>>>an endpoint, you should keep doing consent checks anyway to maintain

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 6 May 2015 06:53:29 +0000

Hi,

I don't think you need to continue doing consent because of NAT issues, if you are sending normal STUN keep-alives.

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Alissa Cooper
Sent: 2. toukokuuta 2015 2:20
To: Martin Thomson
Cc: [email-masked]
Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11

WFM

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 7 May 2015 03:57:32 +0000

Hi Christer,

Martin¹s statement says SHOULD here and does not mandate. ICE keepalives
could also be used to keep the NAT state

Regards,
Ram

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Date: Wednesday, 6 May 2015 12:23 pm
To: Alissa Cooper <[email-masked]>, Martin Thomson
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [rtcweb] AD evaluation:
draft-ietf-rtcweb-stun-consent-freshness-11

>Hi,
>
>I don't think you need to continue doing consent because of NAT issues,
>if you are sending normal STUN keep-alives.
>
>Regards,
>
>Christer
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 May 2015 05:33:33 +0000

Hi,

>Martin¹s statement says SHOULD here and does not mandate. ICE keepalives could also be used to keep the NAT state

There needs to be a good justification for a SHOULD, and consent was never intended for NAT keep-alives.

Also keep in mind that, with the "virtual connection" concept, there might be a big number of ICE connections - some of which you may never use. Why send consent on those, if there is no media?

Regards,

Christer

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Date: Wednesday, 6 May 2015 12:23 pm
To: Alissa Cooper <[email-masked]>, Martin Thomson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [rtcweb] AD evaluation:

>> Yep, the unspoken implication is that if you stop maintaining 
>> consent, a flow is highly likely to break.  I'm OK with making that explicit.
>> 
>> ... .  Absent better information about the network, an endpoint 
>> SHOULD maintain consent if there is any possibility that a flow might 
>> be needed again.
>
>WFM
>
>>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 7 May 2015 07:24:42 +0000

> From: rtcweb [mailto:[email-masked]] On Behalf Of Christer
> Holmberg
> Sent: Thursday, May 07, 2015 11:04 AM
> To: Ram Mohan R (rmohanr); Alissa Cooper; Martin Thomson
> Cc: [email-masked]
> >Martin¹s statement says SHOULD here and does not mandate. ICE
> >keepalives could also be used to keep the NAT state
> 
> Also keep in mind that, with the "virtual connection" concept, there might be
> a big number of ICE connections - some of which you may never use. Why
> send consent on those, if there is no media?

ICE keepalives or consent is only required for candidate pairs selected for media, http://tools.ietf.org/html/rfc5245#section-10 mandates sending keepalives if no packet is sent on the candidate pair ICE is using for a media component for Tr seconds. STUN Binding Indication or consent can be used for keepalives.

-Tiru

> >On May 1, 2015, at 9:54 AM, Martin Thomson
> >wrote:

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 May 2015 09:10:21 +0000

Hi,

>> Also keep in mind that, with the "virtual connection" concept, there 
>> might be a big number of ICE connections - some of which you may never 
>> use. Why send consent on those, if there is no media?
>
> ICE keepalives or consent is only required for candidate pairs selected for media, 

Correct. But, you may have multiple candidate pairs "selected for media", but that doesn't mean you are sending media on all of them. Very likely you are, at any given time, only sending media on one of them.

> http://tools.ietf.org/html/rfc5245#section-10 mandates sending keepalives if no packet is sent on the candidate pair ICE is using for a media component for Tr seconds. STUN Binding Indication or consent can be used for keepalives.

Correct. My issue is why there should be a "SHOULD send consent" on candidate pairs currently not used for sending media. In such case, only the NAT bindings need to be maintained, and the keep-alives take care of that.

Regards,

Christer

> >I don't think you need to continue doing consent because of NAT 
> >issues, if you are sending normal STUN keep-alives.
> >
> >Regards,
> >
> >Christer
> >
> >>> It sounds like the unstated implication here is that if you are 
> >>>such an endpoint, you should keep doing consent checks anyway to 
> >>>maintain consent. Should that be stated explicitly, or am I misunderstanding?
> >>
> >> SHOULD maintain consent if there is any possibility that a flow 
> >> might be needed again.
> >
> >WFM
> >
> >>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 7 May 2015 09:19:29 +0000

Hi Christer,

How about the below text. Does it sound better ?

OLD:

   An endpoint that is not sending any application data does not need to
   maintain consent.  However, failure to send could cause any NAT or
   firewall mappings for the flow to expire.  Furthermore, having one
   peer unable to send is detrimental to many protocols.  Absent better
   information about the network, an endpoint SHOULD maintain consent if
   there is any possibility that a flow might be needed again.

NEW:

   An endpoint that is not sending any application data does not need to
   maintain consent. However, failure to send could cause any NAT or
   firewall mappings for the flow to expire.  Furthermore, having one
   peer unable to send is detrimental to many protocols.  Absent better
   information about the network, if an 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]).

Ram

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Date: Thursday, 7 May 2015 2:40 pm
To: "Tirumaleswar Reddy (tireddy)" <[email-masked]>, Cisco Employee
<[email-masked]>, Alissa Cooper <[email-masked]>, Martin Thomson
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [rtcweb] AD evaluation:
draft-ietf-rtcweb-stun-consent-freshness-11

>Correct. But, you may have multiple candidate pairs "selected for media",
>but that doesn't mean you are sending media on all of them. Very likely
>you are, at any given time, only sending media on one of them.
>
>> http://tools.ietf.org/html/rfc5245#section-10 mandates sending
>>keepalives if no packet is sent on the candidate pair ICE is using for a
>>media component for Tr seconds. STUN Binding Indication or consent can
>>be used for keepalives.
>
>Correct. My issue is why there should be a "SHOULD send consent" on
>candidate pairs currently not used for sending media. In such case, only
>the NAT bindings need to be maintained, and the keep-alives take care of
>that.
>
>Regards,
>
>Christer
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 May 2015 09:49:49 +0000

Hi,

The text looks ok, but I think we can simplify/clarify it a little. 

For example, the usage of "flow" is a little strange, since we explicitly say that no media is sent :)

Also, "failure" is the wrong wording in my opinion, because there is no failure.

What about:

   An endpoint that is not sending any application data does not need to
   maintain consent. However, not sending any traffic could cause NAT or
   firewall mappings to expire.  Furthermore, having one peer unable to send 
   is detrimental to many protocols.  Absent better information about the 
   network, if an endpoint needs to ensure its NAT or firewall mappings do
   not expire, it can be done using keepalive or  other techniques (see 
   Section 10 of [RFC5245] and see [RFC6263]).

Regards,

Christer

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: 7. toukokuuta 2015 12:19
To: Christer Holmberg; Tirumaleswar Reddy (tireddy); Alissa Cooper; Martin Thomson
Cc: [email-masked]
Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11

Hi Christer,

OLD:

NEW:

Ram

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Date: Thursday, 7 May 2015 2:40 pm
To: "Tirumaleswar Reddy (tireddy)" <[email-masked]>, Cisco Employee <[email-masked]>, Alissa Cooper <[email-masked]>, Martin Thomson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [rtcweb] AD evaluation:

>>> might be a big number of ICE connections - some of which you may 
>>> never use. Why send consent on those, if there is no media?
>>
>Correct. But, you may have multiple candidate pairs "selected for 
>media", but that doesn't mean you are sending media on all of them. 
>Very likely you are, at any given time, only sending media on one of them.
>
>>keepalives if no packet is sent on the candidate pair ICE is using for 
>>a media component for Tr seconds. STUN Binding Indication or consent 
>>can be used for keepalives.
>
>candidate pairs currently not used for sending media. In such case, 
>only the NAT bindings need to be maintained, and the keep-alives take 
>care of that.
>
>Regards,
>
>Christer
>
>
>
>> >>> "An endpoint that is not sending any application data does not 
>> >>> need
>>to
>> >> consent, a flow is highly likely to break.  I'm OK with making 
>> >> that
>>explicit.
>> >>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 7 May 2015 10:41:53 +0000

Proposed text WFM

Regards,
Ram

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Date: Thursday, 7 May 2015 3:19 pm
To: Cisco Employee <[email-masked]>, "Tirumaleswar Reddy (tireddy)"
<[email-masked]>, Alissa Cooper <[email-masked]>, Martin Thomson

---

From: Martin Thomson <[email-masked]>
Date: Fri, 8 May 2015 05:41:54 -0700

My intent was to highlight the potential need for re-use. This loses that,
so it ends up saying nothing really. It is otherwise ok in the sense that
it concentrates on the keep alive aspect.
On May 7, 2015 4:49 AM, "Christer Holmberg" <[email-masked]>
wrote:

> To: "Tirumaleswar Reddy (tireddy)" <[email-masked]>, Cisco Employee <
> [email-masked]>, Alissa Cooper <[email-masked]>, Martin Thomson <
> [email-masked]>

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 8 May 2015 06:11:14 -0700

Ok with me.
Alissa

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 11 May 2015 13:53:25 +0000

Attached is the diffs with comment from Christer incorporated. Please let
me know if any one else has comments. If not I will publish this diff as a
new revision.

Regards,
Ram

-----Original Message-----
From: Alissa Cooper <[email-masked]>
Date: Friday, 8 May 2015 6:41 pm
To: Christer Holmberg <[email-masked]>
Cc: Cisco Employee <[email-masked]>, "Tirumaleswar Reddy (tireddy)"
<[email-masked]>, Martin Thomson <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: Re: [rtcweb] AD evaluation:
draft-ietf-rtcweb-stun-consent-freshness-11

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 14 May 2015 03:18:28 +0000

Hi Alissa/All,

I just published the revision that address below comments. Link -
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/
Diff - 
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshness

Regards,
Ram

-----Original Message-----
From: Cisco Employee <[email-masked]>
Date: Monday, 11 May 2015 7:24 pm
To: Alissa Cooper <[email-masked]>, Christer Holmberg
<[email-masked]>, Martin Thomson <[email-masked]>
Cc: "Tirumaleswar Reddy (tireddy)" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [rtcweb] AD evaluation:
draft-ietf-rtcweb-stun-consent-freshness-11