Re: [secdir] secdir review of draft-ietf-forces-protoextension-04
Tobias Gondrom <tobias.gondrom@gondrom.org> Tue, 05 August 2014 13:11 UTC
Return-Path: <tobias.gondrom@gondrom.org>
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 6047E1B278B; Tue, 5 Aug 2014 06:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.002
X-Spam-Level:
X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 PYVv5VuXbaRH; Tue, 5 Aug 2014 06:11:30 -0700 (PDT)
Received: from www.gondrom.org (www.gondrom.org [91.250.114.153]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4DC61B278E; Tue, 5 Aug 2014 06:11:26 -0700 (PDT)
X-No-Relay: not in my network
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=2rf3/v/gKsrHpchGItCvSVEle3lkNV4+dz8yAHdayQcnRJhj8gaImqfGBThjP3oDAapgCNtt8kqNtORg2/wCWaHF3fRkV5A+y3zEp4nDJjx8+nOQEf4tCh8qfOBu8kyDijaAlKhookL5oc0uUG53jhK7OQmcVHC2ZIKGuGUZ3nc=; h=X-No-Relay:X-No-Relay:X-No-Relay:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding;
X-No-Relay: not in my network
X-No-Relay: not in my network
X-No-Relay: not in my network
Received: from [192.168.0.6] (5ec20b19.skybroadband.com [94.194.11.25]) by www.gondrom.org (Postfix) with ESMTPSA id 4E5941539000F; Tue, 5 Aug 2014 15:11:24 +0200 (CEST)
Message-ID: <53E0D7FB.7050603@gondrom.org>
Date: Tue, 05 Aug 2014 14:11:23 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: hadi@mojatatu.com
References: <53E00686.7030909@gondrom.org> <CAAFAkD_4pRyet+KJyVRfcoPyae5UJPuufTw4a=VNid19eOiX+w@mail.gmail.com> <53E0BC74.8090804@gondrom.org> <CAAFAkD-XUdFhU_61eDOAig7PzOmXV6akdEsZXUA4FPAiMCMd1w@mail.gmail.com>
In-Reply-To: <CAAFAkD-XUdFhU_61eDOAig7PzOmXV6akdEsZXUA4FPAiMCMd1w@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/KTGpWeqCvU8jx0Y6QuGLpdw_SHE
Cc: draft-ietf-forces-protoextension.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-forces-protoextension-04
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: Tue, 05 Aug 2014 13:11:38 -0000
Thanks for your response. Thank you. I think my concerns have been heard and leave it to you whether you want to amend text in some places or not. Best wishes, Tobias On 05/08/14 13:55, Jamal Hadi Salim wrote: > Hi Tobias, > > On Tue, Aug 5, 2014 at 7:13 AM, Tobias Gondrom > <tobias.gondrom@gondrom.org> wrote: >> Hi Jamal, >> >> thanks for the fast reply. >> And thank you for taking the time to answer my questions. >> >> Please see my answers only as my personal comments and I am no expert in >> the forces spec. So I might very well be wrong. >> > No worries, an extra pair of eyes with a different view always provides a > perspective we may have overlooked. > >>> Hrm. In a cluster of CEs where you have new + older CEs, yes - that is possible. >>> Caveat: The CEs are spec-ed to talk to each other on CE-CE plane. I would expect >>> what you described to be a "buggy" decision by the master CE. >>> Would text that describes this as a faulty setup be reasonable to add >>> to cover this? >> Yes. That might be a useful point. >> But please see my review questions only as personal comment. I would not >> want to make suggestions that go against the WG views. >> > Ok, will find a spot to discuss this. > >> Small add-on question: >> Not sure whether there are potentially two scenarios here: >> 1. the first as you described might be a "buggy" decision by a master CE >> to switching on the "only" new >> EXTENDEDRESULT-TLVs and by that switching off the old codes for the >> other old CEs. >> 2. wondering whether there might be a second scenario where a malicious >> person would intentionally try to insert one new CE and switch the FEs >> to EXTENDEDRESULT-TLVs to "blind" an existing "old" CE network to some >> of the error codes? >> > An arbitrary CE should not be able to join a cluster or win an election for > mastership without authentication and authorization. > i.e this is all covered by the trust issue i described earlier. > The FE has explicit trust with the CE. If that trust is compromised, security > breach is not limited to just this one issue. > The reason i described the other scenario as buggy is the CEs should be > able to coordinate amongst themselves if they have discrepancies > (although it is outside scope of ForCES to describe how that is achieved) > >> Yes. I understand. >> My concern is the following: AFAIK (and I might very well be wrong) so >> far the protocol mostly required many requests to receive the data from >> the FEs. Which is inefficient, but equally put symmetric compute >> resource requirements on both points (CE and FE). Aka, you would see a >> many requests to put a FE to work. With the new "TABLERANGE-TLV", it >> seems I can send one request which will trigger more computing activity >> on the FE. > Note that a single request to get many (possible) responses back already > exists *today*. Example, I can send one message to dump 10M table rows. > Nothing new there. ForCES says to restrict the transaction pipeline window size > (default of 1) so you cant send 10000 of those - and if you could, > then such requests > which will cause problems of starving other possible transactions because you > are hogging both bandwidth and cpu at the FE . It is likely a buggy > control application to do this. But these are *trusted* apps - they are just > bad code as opposed to malice and the transaction windowing should minimize > damage. > In our implementation (and specified in RFC 5811) we would lower the priority > of these dump responses in a work conserving way > if there are other high prio requests (like a SET for example). > > A simplistic approach to retrieve a table range would be to get all the 10M > table rows and then do the filtering to select 2000 rows in the controller. > This uses more bandwidth and possibly more CPU on the FE (slave) since it > has to dump *all* rows. > What you describe as "more computing activity" boils down to running the filter > i described above at the FE device instead of the controller. > In my experience this hasnt been an issue - but i am willing to be cautious. > >> So yes, you are right with your analogy between brain and >> legs and the trust relationship to the controller. However, before, your >> "brain" could send one command at a time to the legs, now it could send >> a whole marching program to the legs with one single request. And send >> multiple such requests in succession. Could that pose risks for denial >> of service (accidental or malicious) that might not have been >> anticipated in RFC5810? >> > Not any more than they do today. i.e Malice is solved by the general security > infrastructure; if a CE can get into the cluster, be authenticated and vetted as > legit, wins an election and starts telling the FE what to do, then we have > a bigger problem. > OTOH, bugs may exist and we gotta protect against those. > > Thanks again for taking the time. > > cheers, > jamal
- [secdir] secdir review of draft-ietf-forces-proto… Tobias Gondrom
- Re: [secdir] secdir review of draft-ietf-forces-p… Tobias Gondrom
- Re: [secdir] secdir review of draft-ietf-forces-p… Tobias Gondrom
- Re: [secdir] secdir review of draft-ietf-forces-p… Jamal Hadi Salim
- Re: [secdir] secdir review of draft-ietf-forces-p… Jamal Hadi Salim
- Re: [secdir] secdir review of draft-ietf-forces-p… Jamal Hadi Salim
- [secdir] secdir review of draft-ietf-mpls-ipv6-on… Tobias Gondrom
- Re: [secdir] secdir review of draft-ietf-mpls-ipv… Carlos Pignataro (cpignata)
- Re: [secdir] secdir review of draft-ietf-mpls-ipv… Tobias Gondrom
- Re: [secdir] secdir review of draft-ietf-mpls-ipv… Carlos Pignataro (cpignata)
- Re: [secdir] secdir review of draft-ietf-mpls-ipv… Tobias Gondrom