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

"Ram Mohan R (rmohanr)" <> Tue, 19 May 2015 15:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 823711A8AAC; Tue, 19 May 2015 08:28:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q9nZj2t3AMMr; Tue, 19 May 2015 08:28:05 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F88F1A8BB0; Tue, 19 May 2015 08:28:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=10414; q=dns/txt; s=iport; t=1432049285; x=1433258885; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=3GT3vSpTWj0gQefdDJECRzsi4v4sMfB3okS6B4QVLj4=; b=lYzTzoRfmOzoS753IjD9xLnWUrrAi6Wy2cdsyw01OpIklIzhUStTn5nd QUtR43U2FAoSeszTSwaVkp0pAp9j1ubUygJlXpJM9yBUl9fwci7wPHt/+ Xt7q/PSKmYYTdJ5qtQvs3SuLO6S9SIdpcwZSsFZYoOb5Aji4WAqmv3xEs Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.13,458,1427760000"; d="scan'208";a="151378652"
Received: from ([]) by with ESMTP; 19 May 2015 15:28:04 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t4JFS469020803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 May 2015 15:28:04 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Tue, 19 May 2015 10:28:04 -0500
From: "Ram Mohan R (rmohanr)" <>
To: joel jaeggli <>, "Black, David" <>, "" <>, "Dan Wing (dwing)" <>, "Tirumaleswar Reddy (tireddy)" <>, "" <>, "" <>, "" <>
Thread-Topic: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13
Thread-Index: AQHQkkhlFSffw99jN0Sa47pQKspsMw==
Date: Tue, 19 May 2015 15:28:03 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 May 2015 15:28:08 -0000

Hi David/Joel,

Please see inline for my responses.

-----Original Message-----
From: joel jaeggli <>
Date: Friday, 15 May 2015 4:59 am
To: "Black, David" <>, ""
<>, "" <>, Cisco
Employee <>, "" <>,
"" <>, ""
Cc: "" <>, "" <>
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.
>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
>> to?  Is this generally applicable wherever ICE and STUN are used?  I
>> 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.

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.


Also we will modify para 3 of Intro to make it clearer.

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

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.


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

>> -- Nits/Editorial Comments --
>> The SRTP paragraph in Section 8 (Security Considerations) feels out of
>> - 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
>> and can be implemented by one party to a communication session; ordinary
>> response generation behavior (already required) reflects the
>> 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
>> without impact on the other party.  This is implied by section 3 of the
>> 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
>> 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
>> 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
>> or two on reporting of the state of STUN consent-based connectivity and
>> that reporting should or may relate to reporting of the state of other
>> of connectivity (e.g., TCP, SRTP/SRTCP) that are mentioned in this

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
>> 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
>> of loss and re-establishment of consent-based connectivity, as such
>> 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
>> related networks than clients. [A.2.2 - management information, A.2.3 -
>> 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?


>> The primary operational impact of this protocol should be reduction in
>> traffic, which is a benefit - the consent check traffic added by this
>> should not have significant impacts.  The writeup indicates that
>> have reviewed the draft and implementations are in progress. [A.3 -
>> Thanks,
>> --David
>> ----------------------------------------------------
>> David L. Black, Distinguished Engineer
>> EMC Corporation, 176 South St., Hopkinton, MA  01748
>> +1 (508) 293-7953             FAX: +1 (508) 293-7786
>>        Mobile: +1 (978) 394-7754
>> ----------------------------------------------------