Re: [secdir] secdir review of draft-ietf-ippm-checksum-trailer
Tal Mizrahi <talmi@marvell.com> Sun, 15 November 2015 10:17 UTC
Return-Path: <talmi@marvell.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7C81B2CEE; Sun, 15 Nov 2015 02:17:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Level:
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiwNBci34xKr; Sun, 15 Nov 2015 02:17:54 -0800 (PST)
Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB35A1B2C99; Sun, 15 Nov 2015 02:17:54 -0800 (PST)
Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id tAFAF1Qn003630; Sun, 15 Nov 2015 02:17:54 -0800
Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0a-0016f401.pphosted.com with ESMTP id 1y636msqam-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 15 Nov 2015 02:17:54 -0800
Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Sun, 15 Nov 2015 12:17:50 +0200
Received: from IL-EXCH01.marvell.com ([fe80::41:1c9f:8611:3a4a]) by IL-EXCH01.marvell.com ([fe80::41:1c9f:8611:3a4a%20]) with mapi id 15.00.1044.021; Sun, 15 Nov 2015 12:17:50 +0200
From: Tal Mizrahi <talmi@marvell.com>
To: "Salz, Rich" <rsalz@akamai.com>, "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/cdxrnsTAStIfvg
Date: Sun, 15 Nov 2015 10:17:49 +0000
Message-ID: <1c72beca2b5c4c308cbf7ab9215bdd33@IL-EXCH01.marvell.com>
References: <a14ff97da2274a8ea127570a6ce43365@ustx2ex-dag1mb3.msg.corp.akamai.com>
In-Reply-To: <a14ff97da2274a8ea127570a6ce43365@ustx2ex-dag1mb3.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.4.102.210]
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-15_08:, , 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-1511150192
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/_YQipY6TqhZBlIo-0v_dUNpGQwU>
Subject: Re: [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: Sun, 15 Nov 2015 10:17:56 -0000
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. Thanks, Tal. >-----Original Message----- >From: Salz, Rich [mailto:rsalz@akamai.com] >Sent: Thursday, October 22, 2015 6:07 PM >To: draft-ietf-ippm-checksum-trailer.all@ietf.org; iesg@ietf.org; >secdir@ietf.org >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 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 >