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

"Roni Even" <ron.even.tlv@gmail.com> Thu, 06 February 2014 09:09 UTC

Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B70D1A00A3; Thu, 6 Feb 2014 01:09:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gF1U92bJvpx; Thu, 6 Feb 2014 01:09:15 -0800 (PST)
Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 03C3E1A01FB; Thu, 6 Feb 2014 01:09:14 -0800 (PST)
Received: by mail-ea0-f174.google.com with SMTP id b10so742974eae.19 for <multiple recipients>; Thu, 06 Feb 2014 01:09:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=AyyRiyFnJe9NOYgu2stfuIhnhOh15nuMN+q9/Z+n+js=; b=h8/95moC9+6tFhsSJWL1gBUUxdE+02SXfY++9xfsiiS9xEcFnpP6Ky6GLIzTQMRQEs +GNuFSG1PMm1gVNmg8fSVT7+OWmSyMGKqPiR9b0eHKGvyqxsaIVReGe3zmkCVtMDOQlR qgXrDMEutReOiBs9DRpKRtyRZoGF0dJsxlAlO/BQO5ptlAp3GYZPlIhcTX5uTWd9n77H vLX5nNJSuN9Xy9oGwmkSPPVr2jey9JgWODDs1rMSQeAAMBx6L0h3j5G0kLNu6kjX3112 gSvdkmEoTN+O/mK6G4dGx2G4AhttoirevicONxu+PtL/mMRX82kkLY0sdmxKYqOlxFP+ TNiA==
X-Received: by 10.14.210.130 with SMTP id u2mr4746673eeo.108.1391677753563; Thu, 06 Feb 2014 01:09:13 -0800 (PST)
Received: from RoniE (bzq-79-177-0-245.red.bezeqint.net. [79.177.0.245]) by mx.google.com with ESMTPSA id u6sm1121347eep.11.2014.02.06.01.09.09 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 06 Feb 2014 01:09:12 -0800 (PST)
From: Roni Even <ron.even.tlv@gmail.com>
To: "'Klaas Wierenga (kwiereng)'" <kwiereng@cisco.com>, 'Roni Even' <roni.even@mail01.huawei.com>
References: <521F1B37-7D82-485C-AA8F-624695BC5797@cisco.com> <760B7D45D1EFF74988DBF5C2122830C23E54F3CF@szxpml507-mbx.exmail.huawei.com> <9FF8C147-4F05-4A56-B36A-615858D46882@cisco.com>
In-Reply-To: <9FF8C147-4F05-4A56-B36A-615858D46882@cisco.com>
Date: Thu, 06 Feb 2014 11:09:03 +0200
Message-ID: <05bb01cf231b$19a7a4e0$4cf6eea0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJF/Ua/hsN4gdd2jLS/6a+vCQ3VggJl8p41Anh73vaZk0fmgA==
Content-Language: en-us
X-Mailman-Approved-At: Fri, 07 Feb 2014 10:21:18 -0800
Cc: iesg@ietf.org, draft-ietf-p2psip-rpr.all@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-p2psip-rpr-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 06 Feb 2014 09:09:19 -0000

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:kwiereng@cisco.com]
> Sent: 03 February, 2014 3:33 PM
> To: Roni Even
> Cc: draft-ietf-p2psip-rpr.all@tools.ietf.org; secdir@ietf.org;
iesg@ietf.org;
> ron.even.tlv@gmail.com
> Subject: Re: Secdir review of draft-ietf-p2psip-rpr-11
> 
> 
> On Feb 3, 2014, at 2:06 PM, Roni Even <roni.even@mail01.huawei.com> 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 draft-ietf-p2psip-rpr-10.all@tools.ietf.org 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) [kwiereng@cisco.com]
> > Sent: Thursday, January 30, 2014 11:19 AM
> > To: draft-ietf-p2psip-rpr.all@tools.ietf.org
> > Cc: secdir@ietf.org; iesg@ietf.org
> > 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
> > --
> >