Re: [secdir] Secdir review of draft-ietf-forces-packet-parallelization@tools.ietf.org

"Haleplidis Evangelos" <ehalep@ece.upatras.gr> Wed, 01 October 2014 11:15 UTC

Return-Path: <ehalep@ece.upatras.gr>
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 A76961A0311 for <secdir@ietfa.amsl.com>; Wed, 1 Oct 2014 04:15:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.385
X-Spam-Level:
X-Spam-Status: No, score=-0.385 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786] 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 xrBpwC2nohsi for <secdir@ietfa.amsl.com>; Wed, 1 Oct 2014 04:15:52 -0700 (PDT)
Received: from mailgate.ece.upatras.gr (mailgate1.ece.upatras.gr [150.140.189.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 193491A0317 for <secdir@ietf.org>; Wed, 1 Oct 2014 04:15:52 -0700 (PDT)
Received: from EhalepXPS (150.140.254.158) by mailgate1 (Axigen) with ESMTPA id 09D069; Wed, 1 Oct 2014 14:21:01 +0300
From: "Haleplidis Evangelos" <ehalep@ece.upatras.gr>
To: =?UTF-8?Q?'Magnus_Nystr=C3=B6m'?= <magnusn@gmail.com>, <secdir@ietf.org>, <draft-ietf-forces-packet-parallelization@tools.ietf.org>
References: <CADajj4Y2Po_JGmr2-V+U5RoaMALk8hD8M4rJ_VLQ4xTXj-pX4A@mail.gmail.com>
In-Reply-To: <CADajj4Y2Po_JGmr2-V+U5RoaMALk8hD8M4rJ_VLQ4xTXj-pX4A@mail.gmail.com>
Date: Wed, 1 Oct 2014 14:15:49 +0300
Message-ID: <007501cfdd69$0e9a94f0$2bcfbed0$@upatras.gr>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01CFDD82.33E7CCF0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac/ceDwguAVmNCrpQn+S2bgV0oToZQA8AxWA
Content-Language: el
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/2BqWowVBWhtbKwB4b32Xiq57lNw
Subject: Re: [secdir] Secdir review of draft-ietf-forces-packet-parallelization@tools.ietf.org
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: <http://www.ietf.org/mail-archive/web/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: Wed, 01 Oct 2014 11:15:55 -0000

Greetings Magnus,

 

Having discussed the issue with Joel, in order to clarify the text you pointed out, we opted to replace the problematic sentence from:

“However as parallezation tasks have security issues, a designer or an implementer must take into account any security considerations that regards packet parallelization.”

To:

“This document does not attempt to analyze the presence or possibility of security interactions created by allowing parallel operations on packets.  Any such issues, if they exist, are for the designers of the particular data path, not the general mechanism.”

 

This way, we clearly state (the previous sentence didn’t manage to convey that meaning) that security considerations are for implementers and not for the general mechanisms we specify in the draft.

 

Does this resolve your comment?

 

Regards,

Evangelos.

 

From: Magnus Nyström [mailto:magnusn@gmail.com] 
Sent: Tuesday, September 30, 2014 9:26 AM
To: secdir@ietf.org; draft-ietf-forces-packet-parallelization@tools.ietf.org
Subject: Secdir review of draft-ietf-forces-packet-parallelization@tools.ietf.org

 

 

 

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.

 

This document describes how ForCES can model a network device's parallelization datapath to support parallel packet processing in the ForCES model. The document is intended to be published as an Experimental RFC.

 

Since the document does not change the ForCES model or the ForCES protocol, I agree with the Security Consideration section's statement that there's no impact on the security considerations for them. However, the document then goes on to state "However as parallezation [sic] tasks have security issues, a designer or an implementer must take into account any security considerations that regards packet parallelization." I don't know specifically what such security issues are in the context of parallel ForCES packet processing, and it seems that it would be good to include at least some example of them and how implementers should take them into account.


-- Magnus