[secdir] SecDir Review of draft-ietf-rtcweb-stun-consent-freshness-14

<Steve.Hanna@infineon.com> Tue, 09 June 2015 13:51 UTC

Return-Path: <steve.hanna@infineon.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id CFE301B2C4C; Tue, 9 Jun 2015 06:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 1IwZ0w0yk_jJ; Tue, 9 Jun 2015 06:51:41 -0700 (PDT)
Received: from smtp2.infineon.com (smtp2.infineon.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8045F1B2C5E; Tue, 9 Jun 2015 06:50:41 -0700 (PDT)
X-SBRS: None
Received: from unknown (HELO mucxv001.muc.infineon.com) ([]) by smtp2.infineon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jun 2015 15:50:41 +0200
Received: from MUCSE607.infineon.com (mucltm.muc.infineon.com []) by mucxv001.muc.infineon.com (Postfix) with ESMTPS; Tue, 9 Jun 2015 15:50:39 +0200 (CEST)
Received: from MUCSE613.infineon.com ( by MUCSE607.infineon.com ( with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 9 Jun 2015 15:50:38 +0200
Received: from MUCSE609.infineon.com ( by MUCSE613.infineon.com ( with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 9 Jun 2015 15:50:38 +0200
Received: from MUCSE609.infineon.com ([]) by MUCSE609.infineon.com ([]) with mapi id 15.00.0995.032; Tue, 9 Jun 2015 15:50:38 +0200
From: <Steve.Hanna@infineon.com>
To: <secdir@ietf.org>, <iesg@ietf.org>, <draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org>
Thread-Topic: SecDir Review of draft-ietf-rtcweb-stun-consent-freshness-14
Thread-Index: AdCiuP9HBMF1kiH7Sn2XX8QyBIo+fw==
Date: Tue, 9 Jun 2015 13:50:37 +0000
Message-ID: <e1b271d6e9004407b21a15a34a5f9229@MUCSE609.infineon.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0A98_01D0A299.B98CE8E0"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/KzeHfDeJatweymSpr4xGym_6TMY>
Subject: [secdir] SecDir Review of draft-ietf-rtcweb-stun-consent-freshness-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2015 13:51:45 -0000

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.


In my view, this document is Ready with Issues.


The purpose of the document is to reduce flooding attacks by defining a
standard method for WebRTC endpoints to obtain "consent to send" before
sending traffic to another endpoint and continuously while sending. I have a
few questions:


1)      Will misbehaving or malicious endpoints obey this? If not, what's
the point? If only a few polite endpoints go to the trouble of obtaining
consent to send, I don't see how this will solve anything.


2)      Section 5.1 says "An endpoint MUST NOT send data other than the
messages used to establish consent unless the receiving endpoint has
consented to receive data." This seems to be a long way from the present
reality. How many applications implement this requirement? Or will this
feature somehow be built into the OS?


3)      The document says that "Consent expires after 30 seconds." And
"Implementations SHOULD set a default interval of 5 seconds" for
retransmitting STUN binding requests (requests for consent). If I understand
this correctly, every pair of endpoints with an active connection will now
exchange STUN binding request and response pairs in each direction every
five seconds. That works out to about one packet per second transit for
every connection. That seems like a lot of overhead. Is the benefit


Other than these issues, the document seems ready.