Re: [secdir] secdir review of draft-ietf-forces-protoextension-04

Jamal Hadi Salim <hadi@mojatatu.com> Tue, 05 August 2014 10:49 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 DC28F1B298C for <secdir@ietfa.amsl.com>; Tue, 5 Aug 2014 03:49:49 -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 WjzPuyjf6Stb for <secdir@ietfa.amsl.com>; Tue, 5 Aug 2014 03:49:45 -0700 (PDT)
Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 133D51B2988 for <secdir@ietf.org>; Tue, 5 Aug 2014 03:49:40 -0700 (PDT)
Received: by mail-vc0-f171.google.com with SMTP id hq11so1114549vcb.2 for <secdir@ietf.org>; Tue, 05 Aug 2014 03:49:40 -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=Avlqf72FhNja0q+E/FpM33R0U9nGLFDSm7sbRWk4awc=; b=OSeBQQriojIkuJ/zV4kdUZY1FjqQW74ddr+51F2dscFHyXUXW46PC94Tq4OxBG3xIa gZ9aGTh08TxlXXSgj69xtiDIJfAr/+lDK4tapWz4LroUYEakIptOlK+/ijUGssaVWbT7 onB0tYQnPJfQfdxZAztsd5hVXbI2e1B+nFRXoqe3va+N1gOepWoBBBQyYihG4TR6l0uM kpyK7KGhgVeVTE7eZwXUga0EbMhQhx8SiMU6ZeFqYfyGmQicmXJOoQ4B6TtK4vBs3o/l CmNt0qqoIWXadMIzsHwOUUo4oUPaeItr0QKbaazFzFYjWmiDA02SY7FstTPOFEtx/u68 5dLQ==
X-Gm-Message-State: ALoCoQmT6rfGAg8YHCIMgVAbYAWzsQlRQQa944PmoMhetVTtyZPIixC2SI79m624YxJr4eJmSJF2
X-Received: by 10.52.248.232 with SMTP id yp8mr310450vdc.83.1407235780128; Tue, 05 Aug 2014 03:49:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.208.107 with HTTP; Tue, 5 Aug 2014 03:49:20 -0700 (PDT)
In-Reply-To: <53E00686.7030909@gondrom.org>
References: <53E00686.7030909@gondrom.org>
From: Jamal Hadi Salim <hadi@mojatatu.com>
Date: Tue, 5 Aug 2014 06:49:20 -0400
Message-ID: <CAAFAkD_4pRyet+KJyVRfcoPyae5UJPuufTw4a=VNid19eOiX+w@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/GTufGQM8ybHRgSZPq2eohd1M_PE
X-Mailman-Approved-At: Wed, 06 Aug 2014 08:39:26 -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 10:49:50 -0000

Hi Tobias,

Thank you for the review. Comments in line.

On Mon, Aug 4, 2014 at 6:17 PM, Tobias Gondrom
<tobias.gondrom@gondrom.org>; wrote:
> 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.
>
> The draft is standards track and describes a few extensions to ease
> programmability and to improve wire efficiency of some transactions. It adds
> extensions to the ForCES Protocol RFC5810 and RFC7121.
>
> The document appears mostly ready for publication.
>
> The security considerations section (section 6) only refers to RFC 5810.
>
>
> 1 Nits and 3 Questions regarding the security section below:
>
> Nits:
> - section 3.2.3.1. last paragraph:
> s/writting/writing
>

Fixed.

> Questions:
> 1. section 3.2.3.1. last paragraph:
> "On an FE which supports both RESULT-TLVs and EXTENDEDRESULT-TLVs, a
>    master CE can turn on support for extended results by setting the
>    value to 2 in which case the FE MUST switch over to sending only
>    EXTENDEDRESULT-TLVs."
>
> Not sure about the full network topology, but could that enable a master CE
> to effectively make the replies of a FE unreadable to other old-version CEs
> (which can only understand RESULT-TLVs) by switching on the "only" new
> EXTENDEDRESULT-TLVs?
>

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?

> 2. with the New Codes in section 3.2.1. :
> do any of the new more detailed error codes (e.g. "E_EMPTY |  Table is
> empty") pose a risk of data leakage of information detail that was not
> intended to be disclosed in that detail in the original RFC 5810?
>

There is no new information per-se being sent. Implementations sent back
different things like E_NOT_FOUND or E_INVALID_PATH etc before this
and it was left up to the controller to interpret i.e  no explicit coherency
for what ended up being a common use case. Therefore E_EMPTY is
providing a little more clarity.

> 3. section 3.1.:
> Could the new "TABLERANGE-TLV", which requires significantly more computing
> on the receiver per request from the sender, enable an attacker for a type
> of Denial of Service attack scenario?
>

Note: it is the controller that would be doing this. If your brain wants
to attack your legs by punching them endlessly, not sure what those
legs could do;->
(cant run unless brain tells you to). i.e there is explicit, unquestionable
trust of the controller. If the controller is compromised, then we are
talking about
a different ballgame altogether (and nothing we can do here resolves that).

I am not sure i agree on the "significant compute" statement[1].
You are right however that a not so good implementation doing the filtering
at the source would suffer because it has to check for index validity.
An implementation can reject table range requests by issuing a
response of E_INVALID_TFLAGS (section 3.1)
Probably we need to add a small discussion to describe this scenario as another
one that would neccessitate the issuing of E_INVALID_TFLAGS?

>
> NOTE: though I reviewed the ID, I did not validate the XML structure in
> appendix A.
>

At least one other person (the shepherd) has taken of this, so no worries.

Thanks again for taking the time to review.

cheers,
jamal

[1] The filter essentially does a table dump,
checks what the index is and adds it to the response if it matches.


> Thank you and best regards.
>
> Tobias
>