Re: [secdir] Secdir review of

<> Wed, 01 October 2014 14:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 841541ACE31 for <>; Wed, 1 Oct 2014 07:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.018
X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f4kJDR42scx4 for <>; Wed, 1 Oct 2014 07:43:41 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DB8C1ACE2F for <>; Wed, 1 Oct 2014 07:43:39 -0700 (PDT)
Received: by with SMTP id y10so362968pdj.9 for <>; Wed, 01 Oct 2014 07:43:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:mime-version:from:to:subject:importance:date:in-reply-to :references:content-type; bh=QbZaYHKj6a7Uu219jmtjNx5fwVGCm9qhNiwhMFJhRQ0=; b=i0BVZ3wV4kOjQHY9J7P6WpARpqPxfBLGAO399knqVjtbDyuZTtL9D5gwGwKXnjy2CU LItOPMYUNAITvdugdl3X8Lqo/s7efbihwq8uuJFBLDqxdEo3jU+WC7RzbN/Z0FkAcl9+ cUxGXH1lINpDpfGIuSLSY3cKxraOD1/SjgAtKpmAGMZHJOJ1YTwYK5MXdZVH3bZdlVzs 6hGx9dl82RJrjCJSz2mKRuPciuAEx68dakLDQzljNEhZT1n65L5dgQcvXAuAoU/6k5ka SPqT22PSdvIaOFsRg6XGFj2onl6s2Gb6Ku5o5A+EOtjnHsBjAOzIpXVcHyqD2y885P6R KG4Q==
X-Received: by with SMTP id hb6mr79504995pac.72.1412174619199; Wed, 01 Oct 2014 07:43:39 -0700 (PDT)
Received: from ( []) by with ESMTPSA id d5sm1217150pbu.45.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Oct 2014 07:43:38 -0700 (PDT)
Message-ID: <>
MIME-Version: 1.0
From: <>
To: =?utf-8?Q?Haleplidis_Evangelos?= <>, "=?utf-8?Q?" <>, "=?utf-8?Q?" <>
Importance: Normal
Date: Wed, 1 Oct 2014 14:41:15 +0000
In-Reply-To: <007501cfdd69$0e9a94f0$2bcfbed0$>
References: <>, <007501cfdd69$0e9a94f0$2bcfbed0$>
Content-Type: multipart/alternative; boundary="_C0FEC277-57D8-437B-9599-2E8F2D4442B3_"
Subject: Re: [secdir] =?utf-8?q?Secdir_review_of_draft-ietf-forces-packet-para?= =?utf-8?q?llelization=40tools=2Eietf=2Eorg?=
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: Wed, 01 Oct 2014 14:43:43 -0000

Thanks Evangelos,

That sounds good with me as long as it is the case that ForCES packet parallelization in itself doesn’t present new security issues. If however there are known such issues then I think the draft should describe them.


Sent from Windows Mail

From: Haleplidis Evangelos
Sent: ‎Wednesday‎, ‎1‎ ‎October‎, ‎2014 ‎04‎:‎15
To: Magnus Nyström,,

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.”


“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?





From: Magnus Nyström [] 
Sent: Tuesday, September 30, 2014 9:26 AM
Subject: Secdir review of




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