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

Jamal Hadi Salim <> Tue, 05 August 2014 10:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DC28F1B298C for <>; Tue, 5 Aug 2014 03:49:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WjzPuyjf6Stb for <>; Tue, 5 Aug 2014 03:49:45 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 133D51B2988 for <>; Tue, 5 Aug 2014 03:49:40 -0700 (PDT)
Received: by with SMTP id hq11so1114549vcb.2 for <>; Tue, 05 Aug 2014 03:49:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id yp8mr310450vdc.83.1407235780128; Tue, 05 Aug 2014 03:49:40 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 5 Aug 2014 03:49:20 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Jamal Hadi Salim <>
Date: Tue, 05 Aug 2014 06:49:20 -0400
Message-ID: <>
To: Tobias Gondrom <>
Content-Type: text/plain; charset="UTF-8"
X-Mailman-Approved-At: Wed, 06 Aug 2014 08:39:26 -0700
Cc:, The IESG <>,
Subject: Re: [secdir] secdir review of draft-ietf-forces-protoextension-04
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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
<> 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 last paragraph:
> s/writting/writing


> Questions:
> 1. section 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
> 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

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.


[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