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

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

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?

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