[secdir] secdir review of draft-ietf-p2psip-self-tuning-11

Tobias Gondrom <tobias.gondrom@gondrom.org> Sat, 31 May 2014 12:46 UTC

Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id A640D1A08A9; Sat, 31 May 2014 05:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.651
X-Spam-Status: No, score=-102.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JbGYJ_bf5F6O; Sat, 31 May 2014 05:46:34 -0700 (PDT)
Received: from www.gondrom.org (www.gondrom.org []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30FE81A089D; Sat, 31 May 2014 05:46:34 -0700 (PDT)
X-No-Relay: not in my network
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=MLlO6FktzCepJ7bsvYlsV/oriw50lusI9TtlEHs9DR/7gqUmaHFTksqcRTDu72MMyCHxMB0lCepWRHQEWd1mir94Mz3xqskwRVpyn3yPQFReDk41sLPymuIsFmDkpsP04eCdmSPUVo9uMU4pvq6xqRF1FsZY57bSlMZvn/B/wLE=; h=X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:X-Forwarded-Message-Id:Content-Type;
X-No-Relay: not in my network
X-No-Relay: not in my network
Received: from [] (5ec20a52.skybroadband.com []) by www.gondrom.org (Postfix) with ESMTPSA id B3A3715390020; Sat, 31 May 2014 14:46:27 +0200 (CEST)
Message-ID: <5389CF23.8020007@gondrom.org>
Date: Sat, 31 May 2014 13:46:27 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: draft-ietf-p2psip-self-tuning.all@tools.ietf.org
References: <53823E4A.6080106@gondrom.org>
In-Reply-To: <53823E4A.6080106@gondrom.org>
X-Enigmail-Version: 1.6
X-Forwarded-Message-Id: <53823E4A.6080106@gondrom.org>
Content-Type: multipart/alternative; boundary="------------020701090105030408020801"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/MoMos2kO9oj_AeKQVVmW0qddJsU
Cc: iesg@ietf.org, secdir@ietf.org
Subject: [secdir] secdir review of draft-ietf-p2psip-self-tuning-11
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: Sat, 31 May 2014 12:46:36 -0000

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.

The draft is standards track and describes how the default topology
plugin of RELOAD can be extended to support self-tuning, that is, to
adapt to changing operating conditions such as churn and network size.
It extends the mandatory-to-implement chord-reload algorithm by making
it self-tuning.

The document appears ready for publication.

With one note for the IESG: This security review did only consider this
specification, but did not verify the scientific data and research that
lead to this algorithm.

The Security Consideration Section 8 seems appropriate for the draft. It
also refers to the security considerations of RFC6940 (RELOAD Base). 

One personal question to the authors:
In section 8 and 6.5, you introduce the concept of "the statistical
mechanisms applied in Section 6.5 (i.e., the use of 75th percentiles) to
process the shared estimates a peer obtains help ensuring that estimates
that are clearly different from..."
How did you determine the value of 75th percentile? Is this based on
research or experience or derived from some other estimates? Is this
choice influenced by number of peers or churn in certain environments.

Thank you and best regards.