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

"Reshad Rahman (rrahman)" <> Wed, 11 July 2018 14:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C85801277CC; Wed, 11 Jul 2018 07:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 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_HIGH=-0.01, 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 d5A4eyzpj9gG; Wed, 11 Jul 2018 07:31:04 -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 8FCA4130DF2; Wed, 11 Jul 2018 07:31:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6804; q=dns/txt; s=iport; t=1531319464; x=1532529064; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4AliKpaOpb6sg26GKp5Vf1jRD5TCpbwNiH4jhH628+Q=; b=Utm+b3sFl5+mu7LoF7S6FZrC55gTDe693J2v9dHbe7jSUG7hZtclip08 gv9hK1YQ5bs32GNZoFWMf+yR7rTYUc/BNBOQ6quFEPtcgxCDqx7+bXt7v MNi5HEsE2hw6kpMa4VZt3d3nJ1Qh7NG95ixu8OlS/dLAJvOXS04fvAzH+ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.51,338,1526342400"; d="scan'208";a="419092435"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2018 14:31:03 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w6BEV3jJ002859 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Jul 2018 14:31:03 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 11 Jul 2018 09:31:03 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Wed, 11 Jul 2018 09:31:03 -0500
From: "Reshad Rahman (rrahman)" <>
To: "Acee Lindem (acee)" <>, Jeffrey Haas <>, Benjamin Kaduk <>
CC: "" <>, "" <>, The IESG <>, "" <>
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+dqWAgABNJ4CACrpYAIAAKkyAgAB3nICAAE+LgP//wqsA
Date: Wed, 11 Jul 2018 14:31:02 +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.27
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, 11 Jul 2018 14:31:08 -0000

Hi Acee,

That and a statement saying the BFD clients should be authenticated.


On 2018-07-11, 10:10 AM, "Acee Lindem (acee)" <> wrote:

    Hi Reshad, 
    Ok - so are you saying that all that is being asked for is that the NACM rules on IGP BFD configuration be at least as strict as BFD since the IGPs are instantiated BFD sessions? I'd be ok with that. 
    On 7/11/18, 9:25 AM, "Reshad Rahman (rrahman)" <> wrote:
        My read on the DISCUSS is not just wrt spoofing of BFD clients but also making sure that the proper access restriction (NACM) is used for the BFD clients. 
        I didn't interpret Benjamin's comments as requiring a security boundary between BFD clients (BGP, IPGPs) and BFD running on the same dveice, which I agree would be preposterous.
        On 2018-07-10, 10:17 PM, "Acee Lindem (acee)" <> wrote:
            On 7/10/18, 7:46 PM, "Rtg-bfd on behalf of Jeffrey Haas" < on behalf of> wrote:
                On Tue, Jul 03, 2018 at 10:56:49PM -0500, Benjamin Kaduk wrote:
                > On Wed, Jul 04, 2018 at 03:20:42AM +0000, Reshad Rahman (rrahman) wrote:
                > > <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?
                > That's the crux of the matter, yes.  Since (in this case) the IGP state
                > changes are being translated directly into BFD configuration changes,
                > the NETCONF/RESTCONF authentication is not really used.  So, any
                > authentication/authorization decisions that are made must be on the basis
                > of authentication at the IGP level.  This does not necessarily mean a hard
                > requirement for IGP authentication, though using unauthenticated IGP would
                > then be equivalent (for the purposes of this document) to allowing
                > anonymous NETCONF/RESTCONF access.
                > I'd be happy to just have a note in the security considerations that "when
                > BFD clients such as IGPs are used to modify BFD configuration, any
                > authentication and authorization for the configuration changes take place
                > in the BFD client, such as by using authenticated IGPs".  But feel free to
                > reword in a better fashion; this is really just about acknowledging the new
                > access mechanism (since the boilerplate covers SSH/TLS for
                > NETCONF/RESTCONF).
                I must admit to being somewhat perplexed by the request here.
                In the cases where BFD as a top level module is not the creator of a BFD
                session, you seem to be concerned that BFD can be used to attack a resource
                by spoofing that non-BFD client.
                While this is perhaps logically true, it also means that you have a far
                greater problem of being able to spoof the underlying BFD clients.  To give
                some real-world examples:
                - BGP typically requires explicit configuration for its endpoints.
                - Both OSPF and ISIS will require a matched speaker with acceptable
                  configuration parameters for a session to come up.
                - Static routes with BFD sessions will require explicit configuration.
                In each of these cases, a client protocol that also wants to use BFD, the
                simple spoofing of the protocol endpoints is already a massive disaster
                since it will allow injection of control plane or forwarding state into the
                device.  This is so much worse than convincing a BFD session to try to come
                up with its default one packet per mode that ... well, I'm boggled we're
                even talking about this. :-)
                My request would be that we not complicate the security considerations of
                this module for such cases.
            I agree. This is DISCUSS is just preposterous - imposing some sort of security boundary between the IGP modules and the BFD module running on the same networking device.
            Acee (LSR WG Co-Chair) 
                -- Jeff