Re: [P2PSIP] Review of DRR and RPR documents

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Wed, 10 April 2013 01:01 UTC

Return-Path: <cjbc@it.uc3m.es>
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 1944021F9412 for <p2psip@ietfa.amsl.com>; Tue, 9 Apr 2013 18:01:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level:
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 vrY4ys6jtwJe for <p2psip@ietfa.amsl.com>; Tue, 9 Apr 2013 18:01:08 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 2005A21F9416 for <p2psip@ietf.org>; Tue, 9 Apr 2013 18:01:07 -0700 (PDT)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 25AB8CD547E; Wed, 10 Apr 2013 03:00:53 +0200 (CEST)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from [192.168.1.3] (82.158.126.26.dyn.user.ono.com [82.158.126.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 06DC6CD5448; Wed, 10 Apr 2013 03:00:41 +0200 (CEST)
Message-ID: <1365555640.4323.19.camel@acorde.it.uc3m.es>
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: Roni Even <ron.even.tlv@gmail.com>
Date: Wed, 10 Apr 2013 03:00:40 +0200
In-Reply-To: <058001ce2d1a$a9012ff0$fb038fd0$@gmail.com>
References: <1358855465.4174.24.camel@acorde.it.uc3m.es> <058001ce2d1a$a9012ff0$fb038fd0$@gmail.com>
Organization: Universidad Carlos III de Madrid
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.4.4-2
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19786.003
X-TM-AS-Result: No--43.558-7.0-31-1
X-imss-scan-details: No--43.558-7.0-31-1
Cc: draft-ietf-p2psip-rpr@tools.ietf.org, draft-ietf-p2psip-drr@tools.ietf.org, p2psip@ietf.org
Subject: Re: [P2PSIP] Review of DRR and RPR documents
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: cjbc@it.uc3m.es
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: Wed, 10 Apr 2013 01:01:09 -0000

Hi Roni,

Sorry for my late reply.

I think I'm fine with your proposed text. I've seen that you have
updated DRR. Nnce you update RPR draft, I'll review both documents again
and post any further comments that I have (if any), as part of my
shepherd review.

Thanks,

Carlos

On Sat, 2013-03-30 at 10:46 +0300, Roni Even wrote:
> 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
>