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

"Klaas Wierenga (kwiereng)" <kwiereng@cisco.com> Thu, 30 January 2014 09:19 UTC

Return-Path: <kwiereng@cisco.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 1702B1A0417; Thu, 30 Jan 2014 01:19:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.036
X-Spam-Level:
X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 Wl99s1LPIYDf; Thu, 30 Jan 2014 01:19:56 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7003F1A03E9; Thu, 30 Jan 2014 01:19:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1733; q=dns/txt; s=iport; t=1391073595; x=1392283195; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=AOZO14KwyJF4vFT7YW55YkQnd81tpHJJxbIZlgqK+1w=; b=Dv937Mfln4lASrjnZIpTiMRUD+mz7zuM0hHsDDNCwgezUF5rix8YNMOX mfsg+tOTLCQtvAcHUJpEAOCRG5+k/G+hgOTDZumasMQkxEKWpiSa+smiY 8hz9rXfF6tQLdAY+OkbjHNyuTfnwrOjeJlqchdenXGqGv1trW/OD9AL1Z 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhgFAJwY6lKtJXHB/2dsb2JhbABZgww4V7xPT4EFFnSCLDo/EgE+QicEDg6HfA3LSheOJwcBAU8CgymBFASYKJIfgy2BaAkXIg
X-IronPort-AV: E=Sophos;i="4.95,748,1384300800"; d="scan'208";a="297696675"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 30 Jan 2014 09:19:54 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0U9Jr9S003931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jan 2014 09:19:53 GMT
Received: from xmb-aln-x12.cisco.com ([169.254.7.104]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Thu, 30 Jan 2014 03:19:52 -0600
From: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>
To: "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: AQHPHZxuadjFPudg1EiEZvef0HUYVg==
Date: Thu, 30 Jan 2014 09:19:52 +0000
Message-ID: <521F1B37-7D82-485C-AA8F-624695BC5797@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.103.205]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2C2742D2AAC06E419AB37639AAEB848D@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: [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: Thu, 30 Jan 2014 09:19:58 -0000

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