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
>