[secdir] SecDir review of draft-ietf-6man-udpchecksums-04

"Waltermire, David A." <david.waltermire@nist.gov> Sat, 29 September 2012 22:33 UTC

Return-Path: <david.waltermire@nist.gov>
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 1AF7521F85C7; Sat, 29 Sep 2012 15:33:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.894
X-Spam-Status: No, score=-5.894 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8Ayib25CN66U; Sat, 29 Sep 2012 15:33:14 -0700 (PDT)
Received: from wsget1.nist.gov (wsget1.nist.gov []) by ietfa.amsl.com (Postfix) with ESMTP id 514E021F85AF; Sat, 29 Sep 2012 15:33:13 -0700 (PDT)
Received: from WSXGHUB2.xchange.nist.gov ( by wsget1.nist.gov ( with Microsoft SMTP Server (TLS) id 14.1.379.0; Sat, 29 Sep 2012 18:32:29 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([]) with mapi; Sat, 29 Sep 2012 18:30:51 -0400
From: "Waltermire, David A." <david.waltermire@nist.gov>
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-6man-udpchecksums-04.all@tools.ietf.org" <draft-ietf-6man-udpchecksums-04.all@tools.ietf.org>
Date: Sat, 29 Sep 2012 18:27:07 -0400
Thread-Topic: SecDir review of draft-ietf-6man-udpchecksums-04
Thread-Index: Ac2ejfe/nVclsdjNT6GW9xQZ5WazMQ==
Message-ID: <D7A0423E5E193F40BE6E94126930C4930BA8C79AFB@MBCLUSTER.xchange.nist.gov>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: [secdir] SecDir review of draft-ietf-6man-udpchecksums-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, 29 Sep 2012 22:33:15 -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 document provides an update to IPv6 (RFC2460) providing requirements for using a performance optimization for use cases where a UDP-based tunneling protocol is used, where the inner protocol includes a checksum.  In this case the outer UDP checksum can be assigned a zero value to avoid the computational cost of checksum calculation and verification.

In general I found this draft to be very clear on the protocol implications.  The security considerations section addresses the fact that no new vulnerabilities have been added as the result of these changes. In general this document is ready with one suggestion and a couple minor nits.

My only concern is around clearly communicating to application developers what the security risks are.  According to Section 4, paragraph 4, bullet 4, if the packet is corrupted and sent to the wrong endpoint, but the same tunneling protocol is used with a matching context, then the packet should be decapsulated and forwarded.  It is the application developers responsibility to verify and discard the data if needed.  It looks like this situation could be used to craft datagrams for use in a denial of service attack, by flooding an application with junk datagrams or worse yet could be used to affect the application state (according to I-D.ietf-6man-udpzero examples).  It is also looks like it is possible to achieve this using a crafted datagram with a valid checksum.  It might be good to include text warning application developers about this possible situation in the security considerations section.  The warning could reference any other appropriate documents describing possible scenarios or any guidance related to addressing this issue.
Additional editorial nits:

- In the last sentence of the abstract "defines" should be "define"
- One other NIT in draft-ietf-6man-udpzero-06, section-5.1, item 5: in the last sentence "mechanisms" should be "mechanism".

David Waltermire