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

Tal Mizrahi <talmi@marvell.com> Thu, 19 November 2015 11:16 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 9D7931A004E; Thu, 19 Nov 2015 03:16:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.263
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er-yk1ebyYF7; Thu, 19 Nov 2015 03:16:11 -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 6F4ED1A0015; Thu, 19 Nov 2015 03:16:11 -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 tAJBFC6o018176; Thu, 19 Nov 2015 03:16:10 -0800
Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0a-0016f401.pphosted.com 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 IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 19 Nov 2015 13:16:07 +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; Thu, 19 Nov 2015 13:16:06 +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/cdxrnsTAStIfvgAMsx31A=
Date: Thu, 19 Nov 2015 11:16:05 +0000
Message-ID: <7593cabdf3a6477ca5dbe14f160bfe13@IL-EXCH01.marvell.com>
References: <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: [199.203.130.14]
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: <http://mailarchive.ietf.org/arch/msg/secdir/99Hbg5-pW9jFarL4lV_Re3KCGeo>
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: 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.
https://tools.ietf.org/html/draft-ietf-ippm-checksum-trailer-05


Please let me know if there are further comments.

Thanks,
Tal.

>-----Original Message-----
>From: Tal Mizrahi
>Sent: Sunday, November 15, 2015 12:18 PM
>To: 'Salz, Rich'; draft-ietf-ippm-checksum-trailer.all@ietf.org; iesg@ietf.org;
>secdir@ietf.org
>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.
>
>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
>>