Telechat Review of draft-ietf-p2psip-rpr-11
review-ietf-p2psip-rpr-11-secdir-telechat-wierenga-2014-01-30-00

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