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

"Acee Lindem (acee)" <> Wed, 11 July 2018 02:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A072130DFB; Tue, 10 Jul 2018 19:17:49 -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_MED=-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 7RkR8jFgsxkL; Tue, 10 Jul 2018 19:17:47 -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 9279A130DCD; Tue, 10 Jul 2018 19:17:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4304; q=dns/txt; s=iport; t=1531275467; x=1532485067; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BmGW/LPiv9iyEfi12b7k1VhHuAWAWusYN5HLW4G5dnE=; b=UAMMRQHMJiSF/va+1MKHgRsKVevZXu8Cq3pqyVvyfZqmjAEhAm/XiFJI /xkbmicWoIrO6j9DGaIBhFt1MzzUjZdZtGsmclfHyR7Nkwaf2fpgJIUhH NoRes6LLWkdQt9zBDeR2smh81UZ4EOr7CwV/W8TxKvND5dZzVS05sbX85 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.51,336,1526342400"; d="scan'208";a="419977220"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jul 2018 02:17:46 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w6B2HkIx019212 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Jul 2018 02:17:46 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 10 Jul 2018 22:17:45 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Tue, 10 Jul 2018 22:17:45 -0400
From: "Acee Lindem (acee)" <>
To: Jeffrey Haas <>, Benjamin Kaduk <>
CC: "Reshad Rahman (rrahman)" <>, "" <>, "" <>, 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: AQHUEwtvzGLzonHmCkqL7Dn2J0VQzKR+qPEAgAAKF4CACrpYAP//5z6A
Date: Wed, 11 Jul 2018 02:17:45 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
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 02:17:50 -0000

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