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

[Jamal Hadi Salim <[e-mail]>]

Hi Tobias,

On Tue, Aug 5, 2014 at 7:13 AM, Tobias Gondrom
<[e-mail]> 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