[secdir] Secdir review of draft-ietf-tsvwg-rlc-fec-scheme

Alan DeKok <aland@deployingradius.com> Tue, 18 September 2018 14:08 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6625D130EED; Tue, 18 Sep 2018 07:08:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 7oQNO8ySRLxF; Tue, 18 Sep 2018 07:08:08 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC76130E3C; Tue, 18 Sep 2018 07:08:04 -0700 (PDT)
Received: from [192.168.20.160] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [173.32.191.82]) by mail.networkradius.com (Postfix) with ESMTPSA id 893061CB; Tue, 18 Sep 2018 14:08:03 +0000 (UTC)
From: Alan DeKok <aland@deployingradius.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: <AC5F299B-4787-40E4-8E8C-8051E0761416@deployingradius.com>
Date: Tue, 18 Sep 2018 10:08:02 -0400
Cc: draft-ietf-tsvwg-rlc-fec-scheme.all@ietf.org
To: secdir@ietf.org
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/mYjbfWMkXg19NE3KM5DlWv731Jo>
Subject: [secdir] Secdir review of draft-ietf-tsvwg-rlc-fec-scheme
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 18 Sep 2018 14:08:14 -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.

The summary of the review is read with nits

  The document seems to clearly describe what it's doing and why. 

  One nit I have is the formulae in the document, e.g.:

   dw_max_size = (max_lat * br_out * cr) / (8 * E)

  My concern here is about numerical overflow, which could lead to improper calculations and security problems.

  Experience has shown that naive implementations will just do the calculations no matter what the inputs.  Garbage inputs then lead to garbage outputs, and we have problems.

  It would be good to:

* state the limits on each of the variables, so that implementations can know that values *outside* of these limits are erroneous, and should be ignored

* state the minimum size of each of the above variables.  e.g. "dw_max_size" is likely not going to be an 8-bit integer.  So what data types are sufficient to perform the calculations correctly?

  This information may be in another document, but it wasn't clear on cursory inspection.

3.1.2:

   Another approach consists in using ADU timing information (e.g.,
   using the timestamp field of an RTP packet header

  What happens if the timestamp is outside of reasonable bounds?  There could be a recommendation that only timestamps within a certain window are used.

  e.g. an adversary sends timestamps which are unreasonable, and a naive implementation could use those, and engage in integer overflow, etc.

  Section 8 describes protections against many adversarial attacks, which is good.

  I would suggest adding a sub-section of Section 8, discussion computation / numerical issues, as discussed above.  

  Other than that, the document looks fine.