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

"Reshad Rahman (rrahman)" <> Wed, 04 July 2018 03:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D447130E16; Tue, 3 Jul 2018 20:20:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qc-FvcpvS2_2; Tue, 3 Jul 2018 20:20:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3968B130DEB; Tue, 3 Jul 2018 20:20:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4558; q=dns/txt; s=iport; t=1530674444; x=1531884044; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WDn1QrjSikvxuZ9HtOkTHXkqMVpl4ucHS5p2G7Mfcjk=; b=QypzJEYet/6D5Xkz5t9J9GKzodJXeMdXFreVQwOUkmZvcF296pvpl4N7 4AbKR00zCnbEngK4beUoozPjTf+h0BAPfe67MtZ5sm8atERvCQ46aOTOW eYSSfP/vhRAxNecFQYmxkL7Sazg82e0Un5Rq2Atz4sGErvwdMGwPcWEN0 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.51,306,1526342400"; d="scan'208";a="422180329"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jul 2018 03:20:43 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w643Khbf006396 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 Jul 2018 03:20:43 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 3 Jul 2018 22:20:42 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Tue, 3 Jul 2018 22:20:42 -0500
From: "Reshad Rahman (rrahman)" <>
To: Benjamin Kaduk <>, The IESG <>
CC: "" <>, Jeffrey Haas <>, "" <>, "" <>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-bfd-yang-16: (with DISCUSS and COMMENT)
Thread-Index: AQHUEwtqGJqI5psVSUyofhcJ5M3R26R+dqWA
Date: Wed, 04 Jul 2018 03:20:42 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Jul 2018 03:20:47 -0000


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

On 2018-07-03, 4:21 PM, "Benjamin Kaduk" <> 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
    for more information about IESG DISCUSS and COMMENT positions.
    The document, along with other ballot positions, can be found here:
    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
<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?

    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.