Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 28 May 2015 06:32:21 +0000

> -----Original Message-----
> From: Black, David [mailto:[email-masked]]
> Sent: Thursday, May 28, 2015 3:35 AM
> To: Ram Mohan R (rmohanr); joel jaeggli; [email-masked]; Dan Wing
> (dwing); Tirumaleswar Reddy (tireddy); [email-masked]; ops-
> [email-masked]; [email-masked]; Black, David
> Cc: Black, David; [email-masked]; Alissa Cooper
> ([email-masked])
> Subject: RE: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13
> 
> Unfortunately, one of the major issues just became much more serious.  As
> part of my issue [1], I wrote:
> 
>    I don't
>    see any RFCs listed as updated by this draft, so I'm guessing that this
>    is not intended to promulgate new requirements for all uses of ICE and
>    STUN, but this should be clarified.
> 
> Unfortunately, the required clarification is more than editorial, as upon
> further reading, I see this sentence at the end of Section 3 in this draft:
> 
>    If consent is
>    performed then there is no need to send keepalive messages.
> 
> However, the first sentence in section 10 of RFC 5245 says:
> 
>    All endpoints MUST send keepalives for each media session.
> 
> Therefore, this draft normatively modifies RFC 5245, but there was no
> indication of that modification during IETF Last Call, as the draft contains
> neither an Updates: header nor a summary description of changes to RFC
> 5245.
> 
> This is a serious process problem; please work with your WG chairs and AD
> to determine what to do, as your AD (Alissa) owns the decision about what
> has to happen to correct this mistake in addition to correcting the text in the
> draft.
> 
> ----------
> 
> Moving on to concerns beyond the two major issues ... anything not
> mentioned here (aside from [1] and [2] covered in my previous message,
> plus the above missing info on the updates to RFC 5245) is ok with me.
> 
> > >> [3] In Section 1, please explain what ICE-lite is.  A suitable
> > >> reference should suffice.
> >
> > Yes we will add reference to RFC5245 that describes ICE-lite
> 
> Please add a sentence to summarize ICE-lite, not just the reference.

NEW:
ICE-lite agent defined in section 2.7 of [RFC5245] does not generate connectivity
   checks or runs the ICE state machine, it only needs to be able to
   respond to connectivity checks.  Hence an ICE-lite implementation
   will not generate consent checks, but will just respond to consent
   checks it receives.  No changes are required to ICE-lite
   implementations in order to respond to consent checks, as they are
   processed as normal ICE connectivity checks.

> 
> > >> [4] In Section 4.1, please explain or provide a reference for what
> "paced"
> > >> means in "paced STUN connectivity checks or responses."
> >
> > Pacing is explained in the same section below. Let us know if this is
> > not sufficient/not clear.
> >  <snip>
> >     To prevent expiry of consent, a STUN binding request can be sent
> >     periodically.  To prevent synchronization of consent checks, each
> >     interval MUST be randomized from between 0.8 and 1.2 times the basic
> >     period.  Implementations SHOULD set a default interval of 5 seconds,
> >     resulting in a period between checks of 4 to 6 seconds.
> 
> It's not clear - the word "paced" is absent, and that explanation shows up in
> the middle of the next page after the use of "paced."  I suggest the following
> two changes to the second paragraph in Section 4.1 for clarity:
> 
> First sentence:
> 
>    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.
> 
> a) Delete "paced" from the first line.
> b) Add the following sentence immediately after that first sentence.
> 
>    Additional constraints apply to when these checks are allowed to be sent,
>    including a minimum interval between checks, as further specified in this
>    section.
> 
> -- Everything below here is editorial --
> 
> > >> This mechanism is an incremental modification to the STUN and ICE
> > >> protocols, and can be implemented by one party to a communication
> > >> session; ordinary response generation behavior (already required)
> > >> reflects the cryptographically strong STUN transaction IDs on which
> > >> the mechanism is based.  As a result, the mechanism can be deployed
> > >> at one end of a two-party communication session without impact on
> > >> the other party.  This is implied by section 3 of the draft, but would be
> useful to state explicitly.
> >
> > We will add a new applicability section proposed above and also
> > modified para 3 of Intro to make it clearer that this draft does not
> > change ICE procedures. Please let us know if this solves the comment
> above.
> 
> It does not.  Please add a sentence to say that consent checks can be
> deployed via modifications solely to endpoints that send STUN connectivity
> checks because implementations are already required to respond to such
> checks.  A rephrasing of Section 3 would be a good means of adding this.

Section 3.
NEW:
The mechanism proposed in the document is an optional extension to the ICE protocol, it can be deployed at one end of the two-party communication session without impact on the other party.

> 
> > >>  [A.1.1 - deployment]
> > >>
> > >> The mechanism has been defined to limit the amount of added traffic
> > >>and to  shut down unwanted traffic, plus contains a facility to
> > >>desynchronize  independent users of this protocol.  Some rationale
> > >>should be added for  the choice of the 30 second timeout period.
> >
> > 30 second timeout period was selected so that consent checks could be
> > sent between 7 to 5 times (to handle packet loss).
> 
> Please add that statement to the draft.

NEW:
30 second timeout period was selected so that consent checks could be sent between 7 to 5 times to handle packet loss.

> 
> > >> [A.1.5 - network impact]
> > >>
> > >> There is an obvious fault condition, namely that consent is lost or
> > >> revoked causing immediate cessation of traffic.  While the details
> > >> depend on the environment in which this mechanism is used, it'd be
> > >> helpful to add a sentence or two on reporting of the state of STUN
> > >> consent-based connectivity and how that reporting should or may
> > >> relate to reporting of the state of other forms of connectivity (e.g., TCP,
> SRTP/SRTCP) that are mentioned in this draft.
> >
> > We specifically discussed in WG about how applications should handle
> > changes in Consent and it was decided to keep it outside the scope of
> > this draft. Para 3 of introduction already has a text that says the same.
> > There can be many possibilities if consent is lost or failed depending
> > on what the application wants.
> 
> Ok, but .. this is not about "how applications should handle" loss of consent;
> it's about "how implementations should report" loss of consent.  Part of this
> is already in Section 7, which indicates how the application learns that
> consent has expired.  It would suffice to add a sentence added to that
> section to indicate that there are other reasons for loss of ability to transmit
> data, and include an example of how at least one other is reported to
> applications.

NEW:
The circuit breaker algorithm discussed in section 7.1 of [I-D.ietf-rtcweb-rtp-usage] could be one of the reasons for ceasing transmission of media and to notify the application about the loss of ability to transmit data.

> 
> > >> [A.1.8 - fault and threshold conditions]
> > >>
> > >> This mechanism is a simple extension to existing protocols, and
> > >> should fit into existing configuration and management for those
> > >> protocols. [A.1.9 - configuration, A.2 - Management (in general)]
> > >>
> > >> It might be useful to mention the utility of tracking frequency and
> > >> duration of loss and re-establishment of consent-based
> > >> connectivity, as such information has operational value.  In
> > >> particular, a discussion of how a server could infer loss of
> > >> connectivity with a client that is using this mechanism might be
> > >> useful to add, as the operational concerns may be more significant
> > >> for servers and related networks than clients. [A.2.2 - management
> information, A.2.3 - fault management].
> >
> > This again seems some thing outside the scope of this draft as it is
> > trying to specify application behavior. Is there some thing that you
> > want us to add in the draft for this?
> 
> Nope, this is again about reporting information, not how applications
> respond to the reports.  In addition, the consumer of this information may
> be a network operation tool of some sort as opposed to a WebRTC
> application.  Specific details of what to track and how to report it belong
> elsewhere, but it would be good to at least add a sentence pointing out that
> it is useful to track frequency and duration of loss of consent, e.g., to assist in
> troubleshooting application problems.

NEW:
WebRTC client application may in-turn notify WebRTC server about loss of consent so that it can track frequency and duration of loss of consent , e.g., to assist in troubleshooting application problems.

Cheers,
-Tiru

> 
> 
> Thanks,
> --David
> 
> > -----Original Message-----
> > From: Black, David
> > Sent: Wednesday, May 27, 2015 3:17 AM
> > To: Ram Mohan R (rmohanr); joel jaeggli; [email-masked]; Dan
> > Wing (dwing); Tirumaleswar Reddy (tireddy); [email-masked];
> > ops- [email-masked]; [email-masked]
> > Cc: Black, David
> > Subject: RE: OPS-Dir review of
> > draft-ietf-rtcweb-stun-consent-freshness-13
> >
> > I'll limit comments here to the two major issues.  Quick summary:
> >
> > [1] Applicability: The proposed text looks generally good, but the definition
> > 	of "consent" needs a couple of clarifications.
> >
> > [2] Security Considerations: The proposed text isn't sufficient.  In addition
> > 	to the new applicability text's reference to the WebRTC security
> > 	architecture draft, a reference to the WebRTC security
> considerations
> > 	draft with specific section pointers needs to be added to the security
> > 	considerations section of this draft.
> >
> > > >> [1] The draft seems to be missing discussion of applicability -
> > > >> what environments and/or protocols is this mechanism intended for
> > > >> or
> > applicable
> > > >> to?
> >
> > > We will add a new section ³Applicability² after the introduction section.
> >
> > I think that proposed applicability section will address most of the concern.
> > As part of this, the definition of consent (Section 2) needs elaboration:
> >
> >    Consent:  The mechanism of obtaining permission to send to a remote
> >       transport address.  Initial consent is obtained using ICE.
> >
> > Two important concepts should be clearer:
> > 	- Permission to send is obtained *from the recipient* of the traffic.
> > 	- The traffic to which permission to send applies is *non-ICE* traffic.
> >
> > > >> [2] The security considerations appear to be incomplete.
> > > >> There should be an explanation of why cryptographically strong
> > > >> STUN transaction IDs are required (e.g., there are no
> > > >> cryptographically strong IDs in the TCP consent mechanism noted
> > > >> on p.4), and there should be a discussion of how and why replays
> > > >> of previous consent responses are harmless (will be ignored by the
> recipient).
> > >
> > > Cryptographically strong STUN transaction IDs are required so that
> > > off-path attacker does not replay old consent responses.
> > >
> > >
> > >
> > > >>The mechanism design
> > > >> appears to be ok, but this rationale should be provided in terms
> > > >>of  attacks that are of concern and how they are prevented - a
> > > >>primary  intent appears to be to resisting off-path attacks.
> > >
> > > We will add the following line to Security Considerations section.
> > >
> > > NEW:
> > >
> > > Consent requires 96 bits transaction ID to be uniformly and randomly
> > > chosen from the interval 0 .. 2**96-1, and be cryptographically strong.
> > > This is good enough security against an off-path attacker replaying
> > > old STUN consent responses.
> >
> > That's good, but the actual problem is a missing reference.  The
> > rationale discussion is in draft-ietf-rtcweb-security, so that draft
> > needs to be added as a normative reference, plus text added to the
> > security considerations section of this consent draft to call
> > attention to sections 3.3 and 4.2 of that rtcweb-security draft.  This
> > is in addition to the citation of sections
> > 4.4 and 5.3 of draft-ietf-rtcweb-security-arch in the proposed new
> > applicability text.
> >
> > Thanks,
> > --David
> >
> > > -----Original Message-----
> > > From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
> > > Sent: Tuesday, May 19, 2015 11:28 AM
> > > To: joel jaeggli; Black, David; [email-masked]; Dan Wing
> > > (dwing); Tirumaleswar Reddy (tireddy); [email-masked];
> > > [email-masked]; [email-masked]
> > > Subject: Re: OPS-Dir review of
> > > draft-ietf-rtcweb-stun-consent-freshness-13
> > >
> > > Hi David/Joel,
> > >
> > > Please see inline for my responses.
> > >
> > >
> > > -----Original Message-----
> > > From: joel jaeggli <[email-masked]>
> > > Date: Friday, 15 May 2015 4:59 am
> > > To: "Black, David" <[email-masked]>, "[email-masked]"
> > > <[email-masked]>, "[email-masked]" <[email-masked]>,
> Cisco
> > > Employee <[email-masked]>, "[email-masked]"
> > > <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]"
> > > <[email-masked]>
> >
> > > Cc: "[email-masked]" <[email-masked]>, "[email-masked]"
> > > <[email-masked]>
> > > Subject: Re: OPS-Dir review of
> > > draft-ietf-rtcweb-stun-consent-freshness-13
> > >
> > > >Thanks David,
> > > >
> > > >I'll be looking with interest for the addressing of items 1/2.
> > > >
> > > >joel
> > > >
> > > >On 5/14/15 4:21 PM, Black, David wrote:
> > > >> I have reviewed this document as part of the Operational
> > > >> directorate's ongoing effort to review all IETF documents being
> processed by the IESG.
> > > >> These comments were written with the intent of improving the
> > > >> operational aspects of the IETF drafts. Comments that are not
> > > >> addressed in last call may be included in AD reviews during the
> > > >> IESG review.  Document editors and WG chairs should treat these
> > > >> comments just like any other last call comments.
> > > >>
> > > >> Document: draft-ietf-rtcweb-stun-consent-freshness-13
> > > >> Reviewer: David Black
> > > >> Review Date: May 14, 2015
> > > >> IETF LC End Date: May 15, 2015 (on -11)
> > > >>
> > > >> Summary: This draft is on the right track, but has open issues
> > > >>  		described in the review.
> > > >>
> > > >> This draft describes use of STUN to obtain ongoing consent to
> > > >> send in a fashion that is secured by the use of cryptographically
> > > >> strong nonces as STUN transaction IDs.
> > > >>
> > > >> -- Major issues --
> > > >>
> > > >> [1] The draft seems to be missing discussion of applicability -
> > > >> what environments and/or protocols is this mechanism intended for
> > > >> or
> > applicable
> > > >> to?  Is this generally applicable wherever ICE and STUN are used?
> > > >> I
> > don't
> > > >> see any RFCs listed as updated by this draft, so I'm guessing
> > > >> that this is not intended to promulgate new requirements for all
> > > >> uses of ICE and STUN, but this should be clarified.  The shepherd
> > > >> writeup implies that this draft is intended primarily for WebRTC.
> > >
> > > This document defines what it takes to obtain, maintain, and lose
> > >    consent to send using ICE. This draft does not restrict on what
> > > applications should use Consent. Currently on webRTC applications
> > > use Consent, however any other application that has Similar security
> > > requirements can use this mechanism. We will add a new section
> > > ³Applicability² after the introduction section.
> > >
> > > <snip>
> > > 2. Applicability
> > >
> > > This document defines what it takes to obtain, maintain, and lose
> > > consent to send using ICE.Verification of peer consent before
> > > sending traffic is necessary in deployments like WebRTC to ensure
> > > that a malicious JavaScript cannot use the browser as a platform for
> > > launching attacks.Section 4.4 and section 5.3 of
> > > [I-D.ietf-rtcweb-security-arch] explains why webRTC application needs
> consent.
> > >
> > > Other Applications that have similar security requirement where it
> > > is required to verify peer's consent before sending non-ICE packets
> > > can use the consent mechanism described in this draft.
> > >
> > >
> > > </snip>
> > >
> > >
> > > Also we will modify para 3 of Intro to make it clearer.
> > >
> > > OLD:
> > > This document defines what it takes to obtain, maintain, and lose
> > >    consent to send.  Consent to send applies to a single 5-tuple.  How
> > >    applications react to changes in consent is not described in this
> > >    document.
> > >
> > >
> > >
> > > NEW:
> > > This document defines what it takes to obtain, maintain, and lose
> > > consent to send. Consent  to send applies to a single 5-tuple.  How
> > > applications react to changes in consent is not
> > >   described in this document. The consent mechanism does not update
> > > the ICE procedures defined in [RFC 5245].
> > >
> > >
> > >
> > >
> > >
> > >
> > > >>
> > > >> [2] The security considerations appear to be incomplete.
> > > >> There should be an explanation of why cryptographically strong
> > > >> STUN transaction IDs are required (e.g., there are no
> > > >> cryptographically strong IDs in the TCP consent mechanism noted
> > > >> on p.4), and there should be a discussion of how and why replays
> > > >> of previous consent responses are harmless (will be ignored by the
> recipient).
> > >
> > > Cryptographically strong STUN transaction IDs are required so that
> > > off-path attacker does not replay old consent responses.
> > >
> > >
> > >
> > > >>The mechanism design
> > > >> appears to be ok, but this rationale should be provided in terms
> > > >>of  attacks that are of concern and how they are prevented - a
> > > >>primary  intent appears to be to resisting off-path attacks.
> > >
> > > We will add the following line to Security Considerations section.
> > >
> > > NEW:
> > >
> > > Consent requires 96 bits transaction ID to be uniformly and randomly
> > > chosen from the interval 0 .. 2**96-1, and be cryptographically strong.
> > > This is good enough security against an off-path attacker replaying
> > > old STUN consent responses.
> > >
> > >
> > >
> > > >>
> > > >> -- Minor Issues --
> > > >>
> > > >> [3] In Section 1, please explain what ICE-lite is.  A suitable
> > > >> reference should suffice.
> > >
> > > Yes we will add reference to RFC5245 that describes ICE-lite
> > >
> > >
> > >
> > > >>
> > > >> [4] In Section 4.1, please explain or provide a reference for
> > > >>what "paced"
> > > >> means in "paced STUN connectivity checks or responses."
> > >
> > > Pacing is explained in the same section below. Let us know if this
> > > is not sufficient/not clear.
> > >  <snip>
> > >     To prevent expiry of consent, a STUN binding request can be sent
> > >     periodically.  To prevent synchronization of consent checks, each
> > >     interval MUST be randomized from between 0.8 and 1.2 times the
> basic
> > >     period.  Implementations SHOULD set a default interval of 5 seconds,
> > >     resulting in a period between checks of 4 to 6 seconds.
> > > </snip>
> > >
> > >
> > >
> > > >>
> > > >> -- Nits/Editorial Comments --
> > > >>
> > > >> The SRTP paragraph in Section 8 (Security Considerations) feels
> > > >>out of place
> > > >> - this looks like design rationale material that would be better
> > > >>located in  Section 3.
> > >
> > > Okay, will move this paragraph to Section 3.
> > >
> > >
> > >
> > > >>
> > > >> idnits 2.13.02 found an unused reference:
> > > >>
> > > >>   == Unused Reference: 'I-D.ietf-rtcweb-overview' is defined on
> > > >>line 320, but
> > > >>      no explicit reference was found in the text
> > > >>
> > > >> That reference is likely to be useful to address the absence of
> > > >>discussion of  applicability (major issue [1], above).
> > >
> > > This reference is not needed. Once we add applicability section we
> > > will reference rtcweb-security-arch draft.
> > >
> > > >>
> > > >> --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ---
> > > >>
> > > >> This mechanism is an incremental modification to the STUN and ICE
> > > >>protocols,  and can be implemented by one party to a communication
> > > >>session; ordinary  response generation behavior (already required)
> > > >>reflects the cryptographically  strong STUN transaction IDs on
> > > >>which the mechanism is based.  As a result, the  mechanism can be
> > > >>deployed at one end of a two-party communication session  without
> > > >>impact on the other party.  This is implied by section 3 of the
> > > >>draft,  but would be useful to state explicitly.
> > >
> > > We will add a new applicability section proposed above and also
> > > modified para 3 of Intro to make it clearer that this draft does not
> > > change ICE procedures. Please let us know if this solves the comment
> above.
> > >
> > >
> > > >>  [A.1.1 - deployment]
> > > >>
> > > >> The mechanism has been defined to limit the amount of added
> > > >>traffic and to  shut down unwanted traffic, plus contains a
> > > >>facility to desynchronize  independent users of this protocol.
> > > >>Some rationale should be added for  the choice of the 30 second
> > > >>timeout period.
> > >
> > > 30 second timeout period was selected so that consent checks could
> > > be sent between 7 to 5 times (to handle packet loss).
> > >
> > >
> > > >> [A.1.5 - network impact]
> > > >>
> > > >> There is an obvious fault condition, namely that consent is lost
> > > >>or revoked  causing immediate cessation of traffic.  While the
> > > >>details depend on the  environment in which this mechanism is
> > > >>used, it'd be helpful to add a sentence  or two on reporting of
> > > >>the state of STUN consent-based connectivity and how  that
> > > >>reporting should or may relate to reporting of the state of other
> > > >>forms  of connectivity (e.g., TCP, SRTP/SRTCP) that are mentioned
> > > >>in this draft.
> > >
> > > We specifically discussed in WG about how applications should handle
> > > changes in Consent and it was decided to keep it outside the scope
> > > of this draft. Para 3 of introduction already has a text that says the same.
> > > There can be many possibilities if consent is lost or failed
> > > depending on what the application wants.
> > >
> > >
> > > >> [A.1.8 - fault and threshold conditions]
> > > >>
> > > >> This mechanism is a simple extension to existing protocols, and
> > > >>should fit  into existing configuration and management for those
> > > >>protocols. [A.1.9 -  configuration, A.2 - Management (in general)]
> > > >>
> > > >> It might be useful to mention the utility of tracking frequency
> > > >>and duration  of loss and re-establishment of consent-based
> > > >>connectivity, as such information  has operational value.  In
> > > >>particular, a discussion of how a server could infer  loss of
> > > >>connectivity with a client that is using this mechanism might be
> > > >>useful  to add, as the operational concerns may be more
> > > >>significant for servers and  related networks than clients. [A.2.2
> > > >>- management information, A.2.3 - fault  management].
> > >
> > > This again seems some thing outside the scope of this draft as it is
> > > trying to specify application behavior. Is there some thing that you
> > > want us to add in the draft for this?
> > >
> > > Regards,
> > > Ram
> > >
> > > >>
> > > >> The primary operational impact of this protocol should be
> > > >>reduction in unwanted  traffic, which is a benefit - the consent
> > > >>check traffic added by this protocol  should not have significant
> > > >>impacts.  The writeup indicates that implementers  have reviewed
> > > >>the draft and implementations are in progress. [A.3 -
> > > >>Documentation]
> > > >>
> > > >> Thanks,
> > > >> --David
> > > >> ----------------------------------------------------
> > > >> David L. Black, Distinguished Engineer EMC Corporation, 176 South
> > > >> St., Hopkinton, MA  01748
> > > >> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > > >> [email-masked]        Mobile: +1 (978) 394-7754
> > > >> ----------------------------------------------------
> > > >>
> > > >>
> > > >>
> > > >
> > > >

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 28 May 2015 12:49:47 +0200

>    processed as normal ICE connectivity checks.

Grammar stickler:

"An ICE-lite agent, as defined in section 2.7 of [RFC5245], does not
generate connectivity check or run the ICE state machine".

.... "Hence an ICE-lite agent will not ..."

I think the second occurence of "implementation" is OK, but the first
one really needs to be "agent".

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 28 May 2015 10:54:18 +0000

> From: rtcweb [mailto:[email-masked]] On Behalf Of Harald
> Alvestrand
> Sent: Thursday, May 28, 2015 4:20 PM
> To: [email-masked]
> Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-
> freshness-13
> 

Thanks, fixed in my local copy.

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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 29 May 2015 03:50:51 +0000

See inline for one comment:

-----Original Message-----
From: "Tirumaleswar Reddy   (tireddy)" <[email-masked]>
Date: Thursday, 28 May 2015 12:02 pm
To: "Black, David ([email-masked])" <[email-masked]>, "joel
jaeggli ([email-masked])" <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [rtcweb] OPS-Dir review
of	draft-ietf-rtcweb-stun-consent-freshness-13

>The circuit breaker algorithm discussed in section 7.1 of
>[I-D.ietf-rtcweb-rtp-usage] could be one of the reasons for ceasing
>transmission of media and to notify the application about the loss of
>ability to transmit data.

There may be multiple reasons for a webRTC endpoint to cease transmission
(one being circuit breaker) and I feel we should not add all those here in
consent draft.

Also the the above statement indicates a need for a new API to notify the
application about the loss of ability and this is some thing outside the
scope of this document.

IMO this text looks out of place and we should not add this to draft.

Regards,
Ram

---

From: "Black, David" <[email-masked]>
Date: Fri, 29 May 2015 18:24:42 +0000

> Also the above statement indicates a need for a new API to notify the

At the moment, the new API is in scope, as it's discussed in section 7:

7.  API Recommendations

   The W3C specification [W3C-WEBRTC] 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.

If that section remains in the draft, I would be happy with adding one
sentence to the end of that paragraph:

   That API hook could also include other reasons for loss of ability
   to send data, e.g., tripping of the circuit breaker mechanism
   discussed in section 7.1 of [I-D.ietf-rtcweb-rtp-usage].

Alternatively, Section 7 could be deleted - I could live with that,
although I'd prefer that section 7 remain, as I'd expect readers to
be interested in how an application learns that consent has expired.

Thanks,
--David

> Sent: Thursday, May 28, 2015 11:51 PM
> To: Tirumaleswar Reddy (tireddy); Black, David; joel jaeggli
> ([email-masked]); [email-masked]; [email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 30 May 2015 09:25:49 +0200

> be interested in how an application learns that consent has expired.

I'd prefer to limit the number of documents that try to design APIs.

Can we do something more generic, like "Applications that use the RTWEB
transport will need to be notified when transmission ceases due to
expiry of consent. The design of APIs to carry these notifications is
out of scope for this document."?

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 30 May 2015 10:44:57 -0700

> out of scope for this document."?

[BA] Agree with Harald. Loss of STUN consent on a 5-tuple is quite different from tripping a circuit breaker. Let's not design the APIs in this document.

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 31 May 2015 13:38:12 +0000

Hi,

>> Can we do something more generic, like "Applications that use the 
>> RTWEB transport will need to be notified when transmission ceases 
>> due to expiry of consent. The design of APIs to carry these 
>> notifications  is out of scope for this document."?
>
> [BA] Agree with Harald. Loss of STUN consent on a 5-tuple is quite different from tripping 
> a circuit breaker. Let's not design the APIs in this document.

I agree on the not-designing-the-API part.

Regarding Harald's suggested text, it's fine - but I don't think it belongs in this document. Shouldn't it be in the RTCWEB overview and/or security document instead?

The consent freshness draft could then state that the mechanism/requirements how applications are made aware of consent expiration is outside the scope of the document.

Regards,

Christer

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 1 Jun 2015 06:01:09 +0000

WFM. I am fine with keeping APIs out of scope for consent document. It
will be better to have all APIs in one document and have reference to that
where ever applicable.

Regards,
Ram

-----Original Message-----
From: Christer Holmberg <[email-masked]>
Date: Sunday, 31 May 2015 7:08 pm
To: Bernard Aboba <[email-masked]>, Harald Alvestrand
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [rtcweb] OPS-Dir review of
draft-ietf-rtcweb-stun-consent-freshness-13

>Regarding Harald's suggested text, it's fine - but I don't think it
>belongs in this document. Shouldn't it be in the RTCWEB overview and/or
>security document instead?
>
>The consent freshness draft could then state that the
>mechanism/requirements how applications are made aware of consent
>expiration is outside the scope of the document.
>
>Regards,
>
>Christer
>
>
>
>
>