Re: [P2PSIP] Review of DRR and RPR documents

"Roni Even" <ron.even.tlv@gmail.com> Sat, 30 March 2013 07:46 UTC

Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874B421F8B98 for <p2psip@ietfa.amsl.com>; Sat, 30 Mar 2013 00:46:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.071
X-Spam-Level:
X-Spam-Status: No, score=-1.071 tagged_above=-999 required=5 tests=[AWL=-2.527, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, J_CHICKENPOX_31=0.6, RCVD_IN_PBL=0.905, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6-+POwoRCXS for <p2psip@ietfa.amsl.com>; Sat, 30 Mar 2013 00:46:39 -0700 (PDT)
Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED9421F8B61 for <p2psip@ietf.org>; Sat, 30 Mar 2013 00:46:39 -0700 (PDT)
Received: by mail-ea0-f181.google.com with SMTP id z10so438413ead.26 for <p2psip@ietf.org>; Sat, 30 Mar 2013 00:46:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=TAMPWowPspN1oQtkvbKV72QMF0xDBVruBMgfRpCnSXo=; b=MFmJGhdOZdBPlh3XrwCUKf6hSqqsuqwrH769KmDO8YqSQy2bmIynwi9ARTmBlxZUg3 sRXvpNDSsrIPvkPh5PXbrqqZ8v4BZH+Er44/2HcCs64TYJntAqqYEBSRfxPBh/vFFG1P PhoUUVQ231ePPrGhUVgvEYa83CmyrsVdoKOc8ro1a3v4zGjevhY/jU0qaNBq/euSQg28 cBVyb1EryMuwbmK7Zy0ZqBKgY653WUDu2e3kEPz0OEKeMiAYl1EUFAwKDPbBsxSJX4Pf h+3EA/mVGdzokpQI5jvUqcXwCyV8DR9yWkigRrqHm2YWsFWDzHfUyW70yL6GMF3ZTnVV Oe5w==
X-Received: by 10.14.202.71 with SMTP id c47mr15437097eeo.39.1364629598621; Sat, 30 Mar 2013 00:46:38 -0700 (PDT)
Received: from RoniE ([109.65.179.201]) by mx.google.com with ESMTPS id ca4sm8238205eeb.15.2013.03.30.00.46.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 30 Mar 2013 00:46:37 -0700 (PDT)
From: Roni Even <ron.even.tlv@gmail.com>
To: cjbc@it.uc3m.es, p2psip@ietf.org
References: <1358855465.4174.24.camel@acorde.it.uc3m.es>
In-Reply-To: <1358855465.4174.24.camel@acorde.it.uc3m.es>
Date: Sat, 30 Mar 2013 10:46:06 +0300
Message-ID: <058001ce2d1a$a9012ff0$fb038fd0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
thread-index: AQJJctlInCoLwT4KekX9uZ6cgNVklpfGUuyw
Content-Language: en-us
Cc: draft-ietf-p2psip-drr@tools.ietf.org, draft-ietf-p2psip-rpr@tools.ietf.org
Subject: Re: [P2PSIP] Review of DRR and RPR documents
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Mar 2013 07:46:40 -0000

Hi Carlos,
The current text in the security section of both drafts is

"As a routing alternative, the security part of RPR conforms to section 13.6 in based draft[I-D.ietf-p2psip-base] which describes routing security."

I saw you comment "I think this sections has to be extended. It is not clear to me how the proposed approach conforms to -base security without providing more details. How DoS attachs would be avoided for example, by trying to forge the destination address".

I am not sure what we can add here. The security section of the base draft starts with an overview that references RFC5765.  DRR and RPR are only adding  routing options.
DRR provides a direct path back to the source and as such reduce the problem on malicious nodes on the route to affect the route back. The digital signatures defined in the based draft protects against changes of the forwarding header. 


RPR  as specified in the draft (section3.2) is using a trusted node close to the initiating node, using a trusted nodes is recommended as a security policy.  We can look at RPR as DRR in the direction toward the destination and since it is not an arbitrary node in the middle but one that should be trusted (managed network, bootstrap peers or configured relay) and using the based security recommendation will suffice.


We can try to add more text based on the above observation

for DRR

"As a routing alternative, the security part of DRR conforms to section 13 with emphasis one section 13.6 in based draft[I-D.ietf-p2psip-base] which describes routing security. The DRR routing option provide the information about the route back to the source. According to section 13 of the base drat the forwarding header MUST be digitally signed protecting the DRR routing information."

For RPR
 
"As a routing alternative, the security part of RPR conforms to section 13 with emphasis one section 13.6 in based draft[I-D.ietf-p2psip-base] which describes routing security. RPR behave like a DRR requesting node towards the destination node. The RPR relay node is not an arbitrary node but should be a trusted one  (managed network, bootstrap peers or configured relay) which will make it less of a risk as outlined in section13 of the based draft."

Thanks
Roni Even


-----Original Message-----
From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of Carlos Jes?s Bernardos Cano
Sent: 22 January, 2013 1:51 PM
To: p2psip@ietf.org
Cc: draft-ietf-p2psip-drr@tools.ietf.org; draft-ietf-p2psip-rpr@tools.ietf.org
Subject: [P2PSIP] Review of DRR and RPR documents

Hi,

As agreed during the last meeting, I've performed a review of draft-ietf-p2psip-drr and draft-ietf-p2psip-rpr documents, prior to shipping them to the IESG for publication. My reviews are attached to this e-mail (I added comments to the PDF version of each draft, hope this is fine).

I'd like authors to go through the comments before sending the documents to the IESG. There might be some issues that need to be brought to the WG for discussion.

I'd also like to ask the WG for opinion on one particular aspect. I'm wondering if it would be better to merge both documents into a single one. Currently, both documents make quite a lot of cross-references, but still there is duplicate text in both of them, so I'd be more in favor of merging (personal opinion). Please, comment on this on the mailing list.

Thanks,

Carlos