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

From: "Black, David" <[email-masked]>
Date: Thu, 14 May 2015 23:21:11 +0000

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.

[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).  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.

-- Minor Issues --

[3] In Section 1, please explain what ICE-lite is.  A suitable reference
should suffice.

[4] In Section 4.1, please explain or provide a reference for what "paced"
means in "paced STUN connectivity checks or responses."

-- 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.

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).

--- 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.  [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.  [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.
[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].

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: joel jaeggli <[email-masked]>
Date: Thu, 14 May 2015 16:29:04 -0700

Thanks David,

I'll be looking with interest for the addressing of items 1/2.

joel

---

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

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

>> 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].

>> 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

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.

>> [3] In Section 1, please explain what ICE-lite is.  A suitable reference

Yes we will add reference to RFC5245 that describes ICE-lite

>> 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>

>> - this looks like design rationale material that would be better

Okay, will move this paragraph to Section 3.

>> applicability (major issue [1], above).

This reference is not needed. Once we add applicability section we will
reference rtcweb-security-arch 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 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]

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.

>> related networks than clients. [A.2.2 - management information, A.2.3 -

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