[secdir] Review of draft-trammell-ipfix-tcpcontrolbits-revision-04

Simon Josefsson <simon@josefsson.org> Sat, 02 November 2013 21:40 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0A87911E8243; Sat, 2 Nov 2013 14:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.549
X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id V1I5L+2O13+T; Sat, 2 Nov 2013 14:40:21 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id CD45011E811D; Sat, 2 Nov 2013 14:40:20 -0700 (PDT)
Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se []) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id rA2LeFiM024475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 2 Nov 2013 22:40:17 +0100
Date: Sat, 02 Nov 2013 22:40:14 +0100
From: Simon Josefsson <simon@josefsson.org>
To: secdir@ietf.org, draft-trammell-ipfix-tcpcontrolbits-revision.all@tools.ietf.org, iesg@ietf.org
Message-ID: <20131102224014.1aca13bf@latte.josefsson.org>
X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se
X-Virus-Status: Clean
Subject: [secdir] Review of draft-trammell-ipfix-tcpcontrolbits-revision-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: Sat, 02 Nov 2013 21:40:25 -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.

Summary: This is an informational document fixing what appears as a bug
in the IPFIX IANA registry that was introduced in RFC 5102.  The error
was that RFC 5102 used the wrong size for TCP header field, and did not
include three TCP header flags defined after RFC793 (but long before
RFC 5102).  It also changes the semantics to be future proof in case
new TCP header flags are used.

From a security review point of view, I see no significant issues with
this document.

While reading the document, I noticed a couple of things.


* The document says that processes that can't observe the ECN Nonce
  Sum (NS) bit or Future Use bits "should" export the 8-byte value as
  the old 8-bit value.  I believe RFC 2119 terms is warranted here, as
  it appears to influence bytes-on-the-wire.  Is this SHOULD or MUST?


* If the above SHOULD/MUST is honored, some information will be
  potentially be lost.  Consider a process that can observe the CWR/ECE
  bits but not the NS or Future Use bits.  That process would export
  the tcpControlBits as a 8-bit value.  However, earlier specifications
  said that CWR/ECE bits must be zero even if observed. This means that
  instead of being able to trust the CWR/ECE bit values, those fields
  are unreliable.  If instead a 16-bit value is always sent, the CWR/ECE
  bits will be reliable.

  However, it may be that this aspect is entirely theoretical, and that
  all implementations that support CWR/ECE also support NS or Future Use

* The document says "Octets 12 and 13" throughout, however if I'm
  counting the TCP header octets properly, it should be "Octets 13 and
  14".  I call the first octet octet 1 rather than 0, maybe that was
  the origin of the +-1 issue.  Whenever you start counting on 0 rather
  than 1, I think that should be spelled out; it might make things more
  clear to spell that out regardless.

* The acronym IE is not spelled out.

  length), the corresponding bits in this IE must be exported as
  length), the corresponding bits in this Information Element (IE) must
  be exported as

* The Security Considerations section could mention that this document
  changes the size of the tcpControlBits IE from unsigned8 to
  unsigned16, which is probably about the only thing you would want to
  consider when studying the security aspect of this document.

* In section 2 there is one sentence:

      The values of each bit are shown below, per the definition of the
      bits in the TCP header [RFC0793]:

  That isn't really correct, since what is shown below the text above is
  not consistent with RFC793 alone.  I would instead say:

      The values of each bit are shown below, per the definition of the
      bits in the TCP header [RFC0793][RFC3168][RFC3540]:

* The IANA-IPFIX reference looks bad in section 6.2.