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

["Klaas Wierenga (kwiereng)" <[e-mail]>]

Perfect!

Sent from my iPhone

> On 6 feb. 2014, at 10:09, "Roni Even" <[e-mail]> 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:[e-mail]]
>> Sent: 03 February, 2014 3:33 PM
>> To: Roni Even
>> Cc: [e-mail]; [e-mail];
> [e-mail];
>> [e-mail]
>> Subject: Re: Secdir review of draft-ietf-p2psip-rpr-11
>> 
>> 
>> On Feb 3, 2014, at 2:06 PM, Roni Even <[e-mail]> 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 [e-mail] 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) [[e-mail]]
>>> Sent: Thursday, January 30, 2014 11:19 AM
>>> To: [e-mail]
>>> Cc: [e-mail]; [e-mail]
>>> 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
>>> --
>