[secdir] secdir review of draft-ietf-ippm-checksum-trailer

"Salz, Rich" <rsalz@akamai.com> Thu, 22 October 2015 15:07 UTC

Return-Path: <rsalz@akamai.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 A87B01A898D; Thu, 22 Oct 2015 08:07:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 tbUHC6GHLRQE; Thu, 22 Oct 2015 08:07:52 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3F8B01A887B; Thu, 22 Oct 2015 08:07:31 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain []) by postfix.imss70 (Postfix) with ESMTP id C5C17496C30; Thu, 22 Oct 2015 15:07:30 +0000 (GMT)
Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com []) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id B0192496C21; Thu, 22 Oct 2015 15:07:30 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1445526450; bh=yp5IAVHnVW8VMoqGMs7DgGRKy2rbDeqJGkTbTczD2Ys=; l=1492; h=From:To:Date:From; b=YTD/2/itMG+31KSwcb+uDYTR41264Zp+Faq51Hf22zDyex9/CfpKrk9ABLXOuc8nL T9MHewGpZMSaEVyrO2vK7REV6uidkGT6Gfli5yAyV/BkZCt+yJXlHsgbqs5T4i3OSM R7NNtFw/xfaFz6dsXtU/BdEWcOF5OWz2D8B1Zjn0=
Received: from email.msg.corp.akamai.com (ustx2ex-cas1.msg.corp.akamai.com []) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id AE1171E08C; Thu, 22 Oct 2015 15:07:30 +0000 (GMT)
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ( by ustx2ex-dag1mb1.msg.corp.akamai.com ( with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 22 Oct 2015 10:07:30 -0500
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([]) with mapi id 15.00.1076.000; Thu, 22 Oct 2015 10:07:29 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: "draft-ietf-ippm-checksum-trailer.all@ietf.org" <draft-ietf-ippm-checksum-trailer.all@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: secdir review of draft-ietf-ippm-checksum-trailer
Thread-Index: AdEM2iPxQdxYCi6cQbaim/cdxrnsTA==
Date: Thu, 22 Oct 2015 15:07:29 +0000
Message-ID: <a14ff97da2274a8ea127570a6ce43365@ustx2ex-dag1mb3.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/luxHySidy8dwhWm-6gkOTGmDpsc>
Subject: [secdir] secdir review of draft-ietf-ippm-checksum-trailer
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: <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: Thu, 22 Oct 2015 15:07:56 -0000

[ My first review; please let me know if anything's wrong]

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 nits; suggested clarification of Figure 1, below.

This document a mechanism for an intermediary to use space in a padding area to counteract the effect of a prior intermediary adding a high-accuracy timestamp into a UDP packet. The technique is used elsewhere (draft-ietf-ntp-checksum-trailer and IEEE1588) and dates back to RFC 1624 from 1994. The mechanism is better than the current approach, which zero's out the checksum and makes any checksum impossible.

The document and its security considerations are seem thorough, discussing the impact on encrypted packets, the general idea of an MITM modifying packets, and so on.

I think Figure 1 could be improved by showing how and/or where the checksum trailer is applied inside the "enabled Node" box.  Is it a separate node, or is it all a single flow within a node before the packet is put onto the IP Network "cloud"?  Also, the art of the cloud is commendable :)

Senior Architect, Akamai Technologies
IM: richsalz@jabber.at Twitter: RichSalz