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

Tal Mizrahi <> Thu, 19 November 2015 11:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9D7931A004E; Thu, 19 Nov 2015 03:16:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.263
X-Spam-Status: No, score=-1.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, KHOP_DYNAMIC=1.004, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id er-yk1ebyYF7; Thu, 19 Nov 2015 03:16:11 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F4ED1A0015; Thu, 19 Nov 2015 03:16:11 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id tAJBFC6o018176; Thu, 19 Nov 2015 03:16:10 -0800
Received: from ([]) by with ESMTP id 1y9bbj8a1y-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Nov 2015 03:16:10 -0800
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 19 Nov 2015 13:16:07 +0200
Received: from ([fe80::41:1c9f:8611:3a4a]) by ([fe80::41:1c9f:8611:3a4a%20]) with mapi id 15.00.1044.021; Thu, 19 Nov 2015 13:16:06 +0200
From: Tal Mizrahi <>
To: "Salz, Rich" <>, "" <>, "" <>, "" <>
Thread-Topic: secdir review of draft-ietf-ippm-checksum-trailer
Thread-Index: AdEM2iPxQdxYCi6cQbaim/cdxrnsTAStIfvgAMsx31A=
Date: Thu, 19 Nov 2015 11:16:05 +0000
Message-ID: <>
References: <>
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
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-11-19_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1511190200
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-ippm-checksum-trailer
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Nov 2015 11:16:12 -0000

Hi Rich,

The issue you raised was addressed in the current version of the draft (Figure 1), which was posted this week.

Please let me know if there are further comments.


>-----Original Message-----
>From: Tal Mizrahi
>Sent: Sunday, November 15, 2015 12:18 PM
>To: 'Salz, Rich';;;
>Subject: RE: secdir review of draft-ietf-ippm-checksum-trailer
>Hi Rich,
>Thanks for the comments.
>> 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"?
>It is meant to the latter, i.e., a single flow within a node. I will clarify this in
>the next version of the draft.
>>-----Original Message-----
>>From: Salz, Rich []
>>Sent: Thursday, October 22, 2015 6:07 PM
>>Subject: secdir review of draft-ietf-ippm-checksum-trailer
>>[ 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
>>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: Twitter: RichSalz