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

"Klaas Wierenga (kwiereng)" <kwiereng@cisco.com> Thu, 06 February 2014 15:34 UTC

Return-Path: <kwiereng@cisco.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 7BC2F1A0203; Thu, 6 Feb 2014 07:34:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.036
X-Spam-Level:
X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 ckRHscp5_CoD; Thu, 6 Feb 2014 07:34:16 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A0EDE1A013D; Thu, 6 Feb 2014 07:34:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5065; q=dns/txt; s=iport; t=1391700856; x=1392910456; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bXYRTZTyPK20Ku/lMPLqDQbXaGwNo0Op2Eearsm5J90=; b=ZRs9vBp/s9hng96qYIYVewAD/23rThT4Y/0SRDPST7jihdNRWg8kRWdx mieaxNNX0BA03nlUW8mSwvtR5FgXC/edWkT1KeuQKRDhQ8XZ8cfgEqvae vwutQXUAO+Oz4O8jUgy+4VAAK34XKfYhzgdHb/da+M9mkXAallwgqZYVh I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AskFAJWq81KtJV2Z/2dsb2JhbABZgw44T71SgQwWAXSDfQEBAQMBOj8FBwQCAQgOAwQBAQEeCQchERQJCAIEDgUJh2cDCQgIvh0NiQwXjH+BMQoBBQIBHDMHBoMdgRMBA5QzgXiBa4xaA4U3gyuBaAEf
X-IronPort-AV: E=Sophos;i="4.95,793,1384300800"; d="scan'208";a="299304202"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 06 Feb 2014 15:34:14 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s16FYEVF025294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 15:34:14 GMT
Received: from xmb-aln-x12.cisco.com ([169.254.7.181]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 09:34:13 -0600
From: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>
To: Roni Even <ron.even.tlv@gmail.com>
Thread-Topic: Secdir review of draft-ietf-p2psip-rpr-11
Thread-Index: AQHPHZxuadjFPudg1EiEZvef0HUYVpqjhjwQgABr8ICABG1ZgIAABwij
Date: Thu, 6 Feb 2014 15:34:12 +0000
Message-ID: <8CFAB866-CCD6-4570-A20C-68F0076853BE@cisco.com>
References: <521F1B37-7D82-485C-AA8F-624695BC5797@cisco.com> <760B7D45D1EFF74988DBF5C2122830C23E54F3CF@szxpml507-mbx.exmail.huawei.com> <9FF8C147-4F05-4A56-B36A-615858D46882@cisco.com>, <05bb01cf231b$19a7a4e0$4cf6eea0$@gmail.com>
In-Reply-To: <05bb01cf231b$19a7a4e0$4cf6eea0$@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Roni Even <roni.even@mail01.huawei.com>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-p2psip-rpr.all@tools.ietf.org" <draft-ietf-p2psip-rpr.all@tools.ietf.org>, "secdir@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 15:34:18 -0000

Perfect!

Sent from my iPhone

> On 6 feb. 2014, at 10:09, "Roni Even" <ron.even.tlv@gmail.com>; 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: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
>>> --
>