Last Call Review of draft-ietf-p2psip-rpr-10

Request Review of draft-ietf-p2psip-rpr
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-09-30
Requested 2013-09-19
Authors Ning Zong, XingFeng Jiang, Roni Even, Yunfei Zhang
Draft last updated 2013-09-26
Completed reviews Genart Last Call review of -10 by Dan Romascanu (diff)
Genart Telechat review of -11 by Dan Romascanu
Opsdir Early review of -11 by Carlos Pignataro
Secdir Telechat review of -11 by Klaas Wierenga
Secdir Last Call review of -10 by Klaas Wierenga (diff)
Assignment Reviewer Klaas Wierenga
State Completed
Review review-ietf-p2psip-rpr-10-secdir-lc-wierenga-2013-09-26
Reviewed rev. 10 (document currently at 11)
Review result Has Issues
Review completed: 2013-09-26



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


Klaas Wierenga




 Message signed with OpenPGP using GPGMail