Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)

["Reshad Rahman (rrahman)" <[e-mail]>]

Hi,

Thanks for the review. Please see inline <RR>.


On 2018-07-03, 4:21 PM, "Benjamin Kaduk" <[e-mail]> 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.