[secdir] secdir review of draft-ietf-6man-udpzero

Samuel Weiler <weiler@watson.org> Wed, 10 October 2012 22:28 UTC

Return-Path: <weiler@watson.org>
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 088BC21F86BE; Wed, 10 Oct 2012 15:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.221
X-Spam-Level:
X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpf406CoEeGn; Wed, 10 Oct 2012 15:28:17 -0700 (PDT)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6D75B21F8652; Wed, 10 Oct 2012 15:28:17 -0700 (PDT)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.5/8.14.5) with ESMTP id q9AMSG0e033491; Wed, 10 Oct 2012 18:28:16 -0400 (EDT) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.5/8.14.5/Submit) with ESMTP id q9AMSF16033483; Wed, 10 Oct 2012 18:28:15 -0400 (EDT) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Wed, 10 Oct 2012 18:28:15 -0400 (EDT)
From: Samuel Weiler <weiler@watson.org>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-6man-udpzero.all@tools.ietf.org
Message-ID: <alpine.BSF.2.00.1210101820020.26455@fledge.watson.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Wed, 10 Oct 2012 18:28:16 -0400 (EDT)
Subject: [secdir] secdir review of draft-ietf-6man-udpzero
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: Wed, 10 Oct 2012 22:28:18 -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.

This is a design doc examining the merits of allowing UDP with zero 
checksums in IPv6.

This whole doc is about some very subtle stuff (at least to me), and I 
wonder, given its revision history, how well cooked and well reviewed 
it is.  The security considerations section is this doc is 
distressingly short and offers tantalizing hints of amusing attacks: 
"These checks are also desirable to ensure packet counters correctly 
log actual activity, and can be used to detect unusual behaviours."

It was reassuring to read the security considerations section of the 
related doc draft-ietf-6man-udpchecksums, which I'll include here:

    It requires less work to generate zero-checksum attack packets than
    ones with full UDP checksums.  However, this does not lead to any
    significant new vulnerabilities as checksums are not a security
    measure and can be easily generated by any attacker, as properly
    configured tunnels should check the validity of the inner packet and
    perform any needed security checks, regardless of the checksum
    status, and finally as most attacks are generated from compromised
    hosts which automatically create checksummed packets (in other words,
    it would generally be more, not less, effort for most attackers to
    generate zero UDP checksums on the host).

Given the above, I'm not really worried about "security" concerns, but 
I still encourage the ADs to pay close attention to the substance of 
the doc.  Pay particular attention to section 5, which talks about 
requirements that a spec "should consider adding".

Suggestion for the authors:

Section 5.1 number 3: rather than "A port for which zero-checksum has 
been enabled must not log the datagram" how about "...is not required 
to log..."?  (Compare to the parallel section in udbchecksums: "of 
course, there might be other reasons to log such packets".)

-- Sam