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

[Tobias Gondrom <[e-mail]>]

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.

Answers inline.


On 05/08/14 11:49, Jamal Hadi Salim wrote:
> Hi Tobias,
>
> Thank you for the review. Comments in line.
>
> On Mon, Aug 4, 2014 at 6:17 PM, Tobias Gondrom
> <[e-mail]> 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?

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.

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?


>
>> 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.

Ok.

>
>> 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?

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. 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?


>
>> 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.

Cheers, Tobias


>
> 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
>>