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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: Black, David [mailto:[e-mail]]
> Sent: Thursday, May 28, 2015 3:35 AM
> To: Ram Mohan R (rmohanr); joel jaeggli; [e-mail]; Dan Wing
> (dwing); Tirumaleswar Reddy (tireddy); [e-mail]; ops-
> [e-mail]; [e-mail]; Black, David
> Cc: Black, David; [e-mail]; Alissa Cooper
> ([e-mail])
> 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; [e-mail]; Dan
> > Wing (dwing); Tirumaleswar Reddy (tireddy); [e-mail];
> > ops- [e-mail]; [e-mail]
> > 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:[e-mail]]
> > > Sent: Tuesday, May 19, 2015 11:28 AM
> > > To: joel jaeggli; Black, David; [e-mail]; Dan Wing
> > > (dwing); Tirumaleswar Reddy (tireddy); [e-mail];
> > > [e-mail]; [e-mail]
> > > 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 <[e-mail]>
> > > Date: Friday, 15 May 2015 4:59 am
> > > To: "Black, David" <[e-mail]>, "[e-mail]"
> > > <[e-mail]>, "[e-mail]" <[e-mail]>,
> Cisco
> > > Employee <[e-mail]>, "[e-mail]"
> > > <[e-mail]>, "[e-mail]"
> <[e-mail]>, "[e-mail]"
> > > <[e-mail]>
> >
> > > Cc: "[e-mail]" <[e-mail]>, "[e-mail]"
> > > <[e-mail]>
> > > 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
> > > >> [phone]             FAX: [phone]
> > > >> [e-mail]        Mobile: [phone]
> > > >> ----------------------------------------------------
> > > >>
> > > >>
> > > >>
> > > >
> > > >