Re: [secdir] Secdir review of draft-ietf-p2psip-rpr-11

Roni Even <roni.even@mail01.huawei.com> Mon, 03 February 2014 14:07 UTC

Return-Path: <roni.even@mail01.huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72AF1A01F5; Mon, 3 Feb 2014 06:07:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.896
X-Spam-Level:
X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBvkz7P5edsD; Mon, 3 Feb 2014 06:07:07 -0800 (PST)
Received: from hwsga02-in.huaweimarine.com (unknown [58.251.153.224]) by ietfa.amsl.com (Postfix) with ESMTP id 7111B1AD8F0; Mon, 3 Feb 2014 05:07:10 -0800 (PST)
Received: from 172.24.1.80 (EHLO szxpml204-edg.exmail.huawei.com) ([172.24.1.80]) by szxrg12-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVH69315; Mon, 03 Feb 2014 21:07:03 +0800 (CST)
Received: from SZXPML404-HUB.exmail.huawei.com (10.82.67.165) by szxpml204-edg.exmail.huawei.com (172.24.2.15) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Feb 2014 21:06:34 +0800
Received: from SZXPML507-MBX.exmail.huawei.com ([169.254.2.88]) by szxpml404-hub.exmail.huawei.com ([10.82.67.165]) with mapi id 14.03.0158.001; Mon, 3 Feb 2014 21:06:59 +0800
From: Roni Even <roni.even@mail01.huawei.com>
To: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>, "draft-ietf-p2psip-rpr.all@tools.ietf.org" <draft-ietf-p2psip-rpr.all@tools.ietf.org>
Thread-Topic: Secdir review of draft-ietf-p2psip-rpr-11
Thread-Index: AQHPHZxuadjFPudg1EiEZvef0HUYVpqjhjwQ
Date: Mon, 3 Feb 2014 13:06:58 +0000
Message-ID: <760B7D45D1EFF74988DBF5C2122830C23E54F3CF@szxpml507-mbx.exmail.huawei.com>
References: <521F1B37-7D82-485C-AA8F-624695BC5797@cisco.com>
In-Reply-To: <521F1B37-7D82-485C-AA8F-624695BC5797@cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.24.1.60]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Mon, 03 Feb 2014 06:08:28 -0800
Cc: "ron.even.tlv@gmail.com" <ron.even.tlv@gmail.com>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-p2psip-rpr-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: Mon, 03 Feb 2014 14:07:10 -0000

Hi,
Thanks for the comments.
In order to use a relay, the peer need to learn who is the relevant relay as
described in section 3.1 and 3.2 so they are not arbitrary peers,
furthermore section 4.1 says that a relay can limit the number of
connections.
The relay is used for the response path. The source establish a connection
to a relay known to him and if succeed send the information in the outgoing
message. The response should come from the target peer.

So the general security in RFC6490 will work. The relay is not a point of
failure since this is an optional mechanism and if the communication fails
the routing will fall back to SRR.

We can add some sentence in the security section about the relay limiting
the number of connections and maybe about verifying that the connection
request for the response is from the destination peer in the outgoing
message if the relay will keep state (not recommended)

As for being trusted, I think you are right, the relay need to comply with
the security specifications in RFC6490.

BTW: Sorry for not responding earlier bur this was probably since the email
sent to draft-ietf-p2psip-rpr-10.all@tools.ietf.org so it did not reach us.

Roni Even

________________________________________
From: Klaas Wierenga (kwiereng) [kwiereng@cisco.com]
Sent: Thursday, January 30, 2014 11:19 AM
To: draft-ietf-p2psip-rpr.all@tools.ietf.org
Cc: secdir@ietf.org; iesg@ietf.org
Subject: Secdir review of draft-ietf-p2psip-rpr-11

Hi,

I reviewed earlier version 10 (http://www.ietf.org/mail-archive/web/secdir/current/msg04256.html), I didn't get any response and the security considerations don't seem to address what I wrote at that time, so I'll repeat:

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

This document defines an optional extension to RELOAD to support Relay Peer Routing (RPR) mode (as opposed to Symmetric Recursive Routing (SRR). The document is straightforward and clear, but with respect to the security considerations a few comments:

- I am surprised that there is no discussion on the relay peer being the single (or few) point of failure,  and thus becoming an interesting target for DoS attacks: the relay peer acts as a hub for all traffic coming from the peers that have it as their relay. Especially when there is a limited number of relays it becomes attractive to bring the relay down.

- The other thing I wonder about is why there is the need to trust the relay, why is this different from the DRR case (apart from the observation in my previous comment)? It seems that the system would work just fine without the explicit trust in the relay peer, in fact, the way I understand it every peer in the overlay can in principle act as a relay peer (I imagine a scenario where the relay peer acts as the "established connection").

Cheers,

Klaas Wierenga
--