Re: [secdir] SecDir review of draft-ietf-p2psip-service-discovery-14

Jouni Mäenpää <> Thu, 07 August 2014 12:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D2A2D1B278D; Thu, 7 Aug 2014 05:33:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_19=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L6xKZLw8Sduf; Thu, 7 Aug 2014 05:33:44 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C066E1B278A; Thu, 7 Aug 2014 05:33:43 -0700 (PDT)
X-AuditID: c1b4fb3a-f79da6d0000008c7-db-53e372252e8e
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 84.AB.02247.52273E35; Thu, 7 Aug 2014 14:33:41 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Thu, 7 Aug 2014 14:33:41 +0200
From: Jouni Mäenpää <>
To: Alexey Melnikov <>, "" <>, "" <>, "" <>
Thread-Topic: SecDir review of draft-ietf-p2psip-service-discovery-14
Thread-Index: AQHPsiuMYv+juuCA2UmiRnXpK3H7mZvFEa+A
Date: Thu, 07 Aug 2014 12:33:40 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvja5q0eNgg+Xz1CxmrC6yuHZvNaPF jD8TmS0+LHzI4sDisWTJTyaPU82GHl8uf2YLYI7isklJzcksSy3St0vgyniz/RljwRaJimnH +lkbGHcLdzFyckgImEhcWbKHDcIWk7hwbz2QzcUhJHCUUeLU5gcsEM4iRom9a3YxglSxCbhL HL75kxUkISLwjlHi6eUeJpCEsICLxLt/01hBbBEBV4n/fZ3MXYwcQLaRxKNtnCBhFgEViZ5r G9lBbF4BX4lVkzpYQGwhAQ2JvpWLGUHKOQU0JbomaIGEGYEO+n5qDdh0ZgFxiVtP5jNBHCog sWTPeWYIW1Ti5eN/rBC2osTHV/sYIer1JG5MncIGYWtLLFv4mhliraDEyZlPWCYwis5CMnYW kpZZSFpmIWlZwMiyilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwgg5u+W21g/Hgc8dDjAIc jEo8vAlLHwULsSaWFVfmHmKU5mBREuddeG5esJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG tYWzJbeHLiifWeraY/TwtMzuV3fmhpgGTivf6C6YsDLp/426nObtf648mXLgCPO2uomMbz58 eSB736Cv6JsFy+K95zia24463J9woUQgpHTH6qMex9b5q2peObHi42OhWxvWXzm84iDjkhKF qc/+XDuuqdWaut5sVX1Q1Bklloecl7Ssrl+qMFFiKc5INNRiLipOBADt8nFogQIAAA==
Subject: Re: [secdir] SecDir review of draft-ietf-p2psip-service-discovery-14
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: Thu, 07 Aug 2014 12:33:46 -0000


Thanks for the comments! Please find my answers inline below.


> -----Original Message-----
> From: Alexey Melnikov []
> Sent: 7. elokuuta 2014 13:34
> To:;;
> Subject: SecDir review of draft-ietf-p2psip-service-discovery-14
> Hi,
> 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.
> I believe this document is "ready with issues."
> REsource LOcation and Discovery (RELOAD) does not define a generic service
> discovery mechanism as a part of the base protocol.  This document defines
> how the Recursive Distributed Rendezvous (ReDiR) service discovery
> mechanism used in OpenDHT can be applied to RELOAD overlays to provide a
> generic service discovery mechanism.
> The Security Considerations section points to the Security Considerations
> section of RFC 6940, which is quite extensive and relevant.
> The document also defines a new access control policy called NODE-ID-MATCH.
> As only nodes that own service discovery information can update it, it looks like
> there are no additional security issue raised beyond what is already covered in
> RFC 6940. As the information is public, I can't think of any privacy concerns.
> While I was able to follow the document, I think it lacks attention to details
> which are not obvious for somebody not following the technology.
> Minor issues that should be easy to fix:
>   On page 4: H(x) - missing reference to SHA-1. Any specific properties required
> from H(x)?

I will add a reference to SHA-1. The requirements are the same as in the RELOAD base specification (RFC 6940).

>   Namespace - missing reference to UTF-8.

Ok, I'll add that reference as well.

>   On page 6: H() with multiple arguments is not defined, especially if they can
> be both strings and integers (what byte order)? b' is not defined. Typo in the
> description?

I will clarify this in the next revision of the draft. H(namespace,level,j) refers to taking a hash over a concatenated string consisting of the namespace (string), level in the ReDiR tree (integer), and the node location j (integer). 

Related to byte order, would it be sufficient/correct to say that it is big-endian? 

And you are right, b'  was not defined in the draft. It refers to the number of the interval within a given tree node at a given level in the ReDiR tree.

> In 4.2 I read "the mode of those depths". Can you explain what this means? Or
> is this a typo?

Mode (statistics) refers to the value that appears most often in a set of data. I will add also this definition to the next revision of the draft.