Re: [secdir] secdir review of draft-ietf-forces-protoextension-04
Jamal Hadi Salim <hadi@mojatatu.com> Tue, 05 August 2014 13:22 UTC
Return-Path: <hadi@mojatatu.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 D223D1B2790 for <secdir@ietfa.amsl.com>; Tue, 5 Aug 2014 06:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 g09fqEMwvydR for <secdir@ietfa.amsl.com>; Tue, 5 Aug 2014 06:22:08 -0700 (PDT)
Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 604D21B27A2 for <secdir@ietf.org>; Tue, 5 Aug 2014 06:22:08 -0700 (PDT)
Received: by mail-vc0-f182.google.com with SMTP id hy4so1438184vcb.13 for <secdir@ietf.org>; Tue, 05 Aug 2014 06:22:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IIWNOM3VQYHMqShO60/LwLppTE0Q9y744k4n8CWJzfA=; b=N/Aw5feStcuUlhf/eUG9UpDPppuGi2Rioe+CJqASM0t0CtNM4mEqeTfaLkOrHU53b5 r7YAntISEd0XEtVCCLtuFyC2kYcbDeMNszRpYappDO6HCXbMkMcGhXxlgVCRz57hCtY7 E08fKe0AdTh3DjvE2UJ5wfTOL0M6XQDzeR3VqRyMqXN1zxlDmf159wk5wgU7pULzKbKD Mywv/ZGFBqoLY0KDzhp8QMbY1Sq+ZqxakV8oSXu56EyxZh58+F+ihQO5b9Z0XjtxhnS7 YZz2P4UlM66XsAvXRhcZU1upIodQ6yUsLTx76sWncnSlcr1dwIzTnLPJDANphMsRA730 f0Yg==
X-Gm-Message-State: ALoCoQnns3dyUvh2jZ/L8E73s6nAf7++vrfByZPVzb+vB+jbnSJkM7yuVcvplomyZll012vUVXvz
X-Received: by 10.220.122.132 with SMTP id l4mr3289928vcr.41.1407244927396; Tue, 05 Aug 2014 06:22:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.208.107 with HTTP; Tue, 5 Aug 2014 06:21:47 -0700 (PDT)
In-Reply-To: <53E0D7FB.7050603@gondrom.org>
References: <53E00686.7030909@gondrom.org> <CAAFAkD_4pRyet+KJyVRfcoPyae5UJPuufTw4a=VNid19eOiX+w@mail.gmail.com> <53E0BC74.8090804@gondrom.org> <CAAFAkD-XUdFhU_61eDOAig7PzOmXV6akdEsZXUA4FPAiMCMd1w@mail.gmail.com> <53E0D7FB.7050603@gondrom.org>
From: Jamal Hadi Salim <hadi@mojatatu.com>
Date: Tue, 05 Aug 2014 09:21:47 -0400
Message-ID: <CAAFAkD8GFRsXA=KZ+Mn8eqGJCzLs8CUbk9=ye1sukJLj3675pg@mail.gmail.com>
To: Tobias Gondrom <tobias.gondrom@gondrom.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8W-MCKKluyETHeR88qts3FIAbEg
X-Mailman-Approved-At: Wed, 06 Aug 2014 08:39:27 -0700
Cc: draft-ietf-forces-protoextension.all@tools.ietf.org, The IESG <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:22:14 -0000
Thanks Tobias. I will make the changes we discussed - wait for other reviews and amalgamate. The AD should be able to decide if we need a revised publication. cheers, jamal On Tue, Aug 5, 2014 at 9:11 AM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote: > 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