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

joel jaeggli <joelja@bogus.com> Thu, 14 May 2015 23:29 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30471B2D78; Thu, 14 May 2015 16:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpHDGS_52Fur; Thu, 14 May 2015 16:29:20 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FB31B2D6C; Thu, 14 May 2015 16:29:15 -0700 (PDT)
Received: from mb-aye.local ([IPv6:2601:9:3402:7bb1:484:396b:f794:75d0]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t4ENT5hn010130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 May 2015 23:29:05 GMT (envelope-from joelja@bogus.com)
To: "Black, David" <david.black@emc.com>, "muthu.arul@gmail.com" <muthu.arul@gmail.com>, "dwing@cisco.com" <dwing@cisco.com>, "rmohanr@cisco.com" <rmohanr@cisco.com>, "tireddy@cisco.com" <tireddy@cisco.com>, "martin.thomson@gmail.com" <martin.thomson@gmail.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>
references: <CE03DB3D7B45C245BCA0D2432779493649720F@MX104CL02.corp.emc.com>
From: joel jaeggli <joelja@bogus.com>
message-id: <55552FC0.8080103@bogus.com>
Date: Thu, 14 May 2015 16:29:04 -0700
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0
mime-version: 1.0
in-reply-to: <CE03DB3D7B45C245BCA0D2432779493649720F@MX104CL02.corp.emc.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="aH6uxfXwQVrMMUimi4RILx4SRcNtnS5vl"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/j8cQOyCFqeP6uJ-QlmGrMfGSaYY>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 May 2015 23:29:25 -0000

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.
> 
> [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
> david.black@emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> 
>