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

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Mon, 3 Feb 2014 13:32:39 +0000

On Feb 3, 2014, at 2:06 PM, Roni Even <[email-masked]> wrote:

Hi Roni,

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

So what happens if a relay has reached that maximum? Doesn't that mean that the relay has become effectively unusable? But since my SPOF comment doesn't seem to hold this is not much of an issue.

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

ah ok, the sentence "If peer A knows it is behind a NAT or NATs, and knows one or more
   relay peers with whom they have a prior connections, peer A can try
   RPR. " in 3.1 threw me off. I missed that there was in any case an established connection from A to B. So if I now understand correctly, you are dealing with a case in which SRR is in any case also always possible? 

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

I think that is useful

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

ok

> 
> BTW: Sorry for not responding earlier bur this was probably since the email
> sent to [email-masked] so it did not reach us.

arghhh, I need to say sorry here, I clearly was a bit too hasty with my copy/paste of the draft name!

Klaas

> 
> Roni Even
> 
> ________________________________________
> From: Klaas Wierenga (kwiereng) [[email-masked]]
> Sent: Thursday, January 30, 2014 11:19 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> 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
> --
>

---

From: Roni Even <[email-masked]>
Date: Mon, 3 Feb 2014 13:06:58 +0000

Hi,
Thanks for the comments.

Roni Even

Hi,

--
Hi,

Cheers,

Klaas Wierenga
--

---

From: "Klaas Wierenga (kwiereng)" <[email-masked]>
Date: Thu, 6 Feb 2014 15:34:12 +0000

Perfect!

Sent from my iPhone

> On 6 feb. 2014, at 10:09, "Roni Even" <[email-masked]> wrote:
> 
> Hi Klaas,
> We will add the sentence to the security section and can take out the
> trusted.
> Thanks
> Roni
> 
>> -----Original Message-----
>> From: Klaas Wierenga (kwiereng) [mailto:[email-masked]]
>> Sent: 03 February, 2014 3:33 PM
>> To: Roni Even
>> Cc: [email-masked]; [email-masked];
> [email-masked];
>> [email-masked]
>> Subject: Re: Secdir review of draft-ietf-p2psip-rpr-11
>> 
>> 
>>> 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.
>> 
>> So what happens if a relay has reached that maximum? Doesn't that mean
> that
>> the relay has become effectively unusable? But since my SPOF comment
>> doesn't seem to hold this is not much of an issue.
>> 
>>> 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.
>> 
>> ah ok, the sentence "If peer A knows it is behind a NAT or NATs, and knows
> one
>> or more
>>   RPR. " in 3.1 threw me off. I missed that there was in any case an
> established
>> connection from A to B. So if I now understand correctly, you are dealing
> with a
>> case in which SRR is in any case also always possible?
>> 
>>> 
>>> 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)
>> 
>> I think that is useful
>> 
>>> 
>>> As for being trusted, I think you are right, the relay need to comply
>>> with the security specifications in RFC6490.
>> 
>> ok
>> 
>>> 
>>> BTW: Sorry for not responding earlier bur this was probably since the
>>> email sent to [email-masked] so it did not
> reach us.
>> 
>>> 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
>>> --
>

---

From: "Roni Even" <[email-masked]>
Date: Thu, 6 Feb 2014 11:09:03 +0200

Hi Klaas,

[email-masked];
that
one
established
with a
reach us.
the
so I'll
ongoing
directors.
security
single
DoS
peers that
relays it
relay,
the
peer in the
the