Hi,
Thanks for the review. Please see inline <RR>.
On 2018-07-03, 4:21 PM, "Benjamin Kaduk" <ka...@mit.edu> wrote:
Benjamin Kaduk has entered the following ballot position for
draft-ietf-bfd-yang-16: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Section 2.1 describes a scheme wherein an IGP may generate events that
cause BFD sessions to be created/destroyed; this effectively is proxying
commands from IGP over the local BFD API, which brings the authentication
and authorization of the IGP into scope, even if the local BFD
configuration access is authenticated. (That is, the proxying component is
always authenticated, but now bears responsibility for performing
authentication/authorization/sanity checks on commands before proxying
them.) Since IGP security is a topic for elsewhere, the changes to this
document seem scoped to documenting the requirements on the IGP/local proxy
for these checks, and arguably for only allowing authenticated IGP events
to create authenticated BFD sessions (though arguably not as well, for the
latter, since this is a YANG model document and not an architecture
document).
<RR> I am not 100% sure I understand the point being made. Is it a question of
underlying the importance of having the IGPs authenticated since the IGPs can
create/destroy BFD sessions via the local API?
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
I'm not very familiar with YANG notifications; is there a risk that they
can be abused as a DoS attack vector on the notification recipient by an
attacker (e.g., by causing a flapping series of state transition events or
by creating/destroying many sessions)?
<RR> To do that an attacker would need to e.g. access the local device or the
directly connected devices to cause those BFD state transitions.
Regarding the Security Considerations:
It's unclear whether local-multiplier, the various intervals, and
authentication are the only nodes that merit mention for every
per-forwarding-path-type module. For example, source/destination addresses
could be modified to direct traffic at unwitting recipients, and the
key-chain and meticulous settings also seem security-related.
Similarly, read-only access to the discriminators (and
key-chain/authentication information) could make it easier for an attacker
to spoof traffic.
<RR> Good point. I will add those nodes.
Regards,
Reshad.
