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

"Klaas Wierenga (kwiereng)" <kwiereng@cisco.com> Wed, 25 September 2013 11:04 UTC

Return-Path: <kwiereng@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5DC21F9FAE; Wed, 25 Sep 2013 04:04:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 65AqJb9QTdWe; Wed, 25 Sep 2013 04:04:49 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF5B21E804C; Wed, 25 Sep 2013 04:04:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2170; q=dns/txt; s=iport; t=1380107087; x=1381316687; h=from:to:subject:date:message-id:mime-version; bh=FpkZSj+P/Pl7P/p3U/IjNyIEuCyaJ+Zy6dtq/JP/Ui0=; b=F9oXqW8J7TggPjNwIAGzMbEHxPm97OuI5WB5AvBtWRhSmNE7KMEvLNfU trAselng0br459xwmAfYFfUl775wxRrkZoPqaWvF5Rt+a+X00WozZSsu5 ThM28foUB81r6G4i+nEJIvXE2GyMZWhIwZGQdaOMfSrP+hjvlza2yBotj 4=;
X-Files: signature.asc : 203
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhEFAMLCQlKtJXG8/2dsb2JhbABbgweBCsBFgR4WdIInAQSBCwEqVicEARoGh3i8EY4SgQ6DVYEAA5AmgS+YHoMkgWhC
X-IronPort-AV: E=Sophos; i="4.90,977,1371081600"; d="asc'?scan'208"; a="264263040"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 25 Sep 2013 11:04:46 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8PB4kwj029834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Sep 2013 11:04:46 GMT
Received: from xmb-aln-x12.cisco.com ([169.254.7.246]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 06:04:46 -0500
From: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>
To: "draft-ietf-p2psip-rpr-10.all@tools.ietf.org" <draft-ietf-p2psip-rpr-10.all@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>
Thread-Topic: Secdir review of draft-ietf-p2psip-rpr-10
Thread-Index: AQHOud8L86vfRBD7dEabVZIus9pGkA==
Date: Wed, 25 Sep 2013 11:04:45 +0000
Message-ID: <7E1636E02F313F4BA69A428B314B77C709FDEF46@xmb-aln-x12.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.105.222]
Content-Type: multipart/signed; boundary="Apple-Mail=_9EA7185B-471B-4F30-9A51-49A5EC982895"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Subject: [secdir] Secdir review of draft-ietf-p2psip-rpr-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 25 Sep 2013 11:04:55 -0000

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