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

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 <alissa@cooperw.in> 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:
> "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?
>
> 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.”
>
> Alissa
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>