IETF Logo Mail Archive

Re: Secdir last call review of draft-ietf-bfd-yang-09

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Fri, 02 February 2018 03:01 UTC

Return-Path: <rrahman@cisco.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AC112EB14; Thu, 1 Feb 2018 19:01:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Level:
X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLlgia-NglUX; Thu, 1 Feb 2018 19:01:27 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1241205D3; Thu, 1 Feb 2018 19:01:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2176; q=dns/txt; s=iport; t=1517540487; x=1518750087; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PjdUJsdvrppO/MzFX/scYaIzh2h2A5syxBVwtowbPFI=; b=g6WtkVe1rCx7kgxyI+ZgFj06QM6xiv+jpYysmoEY/gEcvQkj+7u4pbAJ t1gLb9PpNzK9/Ifc4ho1hGlGDzTtoZYQlzFlJvJW2DZv8JM/s7/7bCVsM lVbihQDUDaih35d0dgYzyJe8zcyX/DpoSjuxfUpmEOQq9SPK4O2NNpfEp U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DfAADx03Na/4MNJK1dGQEBAQEBAQEBAQEBAQcBAQEBAYNCgVsoCoNWiiSOLYFbl2+CFwqFOwIaghdUGAEBAQEBAQEBAmsohSQGIxFFEAIBCBoCJgICAjAVEAIEAQ0FijWuFoInimMBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQ+DWoIVgVeCEQyCeYMvBIFvF4MAMYI0AQSkIwKVbJQxlz8CERkBgTsBHzmBUHAVZwGBf4JQBRyCBniKVYEXAQEB
X-IronPort-AV: E=Sophos;i="5.46,445,1511827200"; d="scan'208";a="350742710"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2018 03:01:26 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w1231QZc023796 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Feb 2018 03:01:26 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 1 Feb 2018 21:01:25 -0600
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1320.000; Thu, 1 Feb 2018 21:01:25 -0600
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Christian Huitema <huitema@huitema.net>, "secdir@ietf.org" <secdir@ietf.org>
CC: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-yang.all@ietf.org" <draft-ietf-bfd-yang.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: Secdir last call review of draft-ietf-bfd-yang-09
Thread-Topic: Secdir last call review of draft-ietf-bfd-yang-09
Thread-Index: AQHTm62AiPKYaoJtDUuDmicV6NCuCqOQ0XOA
Date: Fri, 02 Feb 2018 03:01:25 +0000
Message-ID: <A20F64E6-9511-4CFB-94ED-9E3E802762E3@cisco.com>
References: <151752475872.25625.14658191049524252377@ietfa.amsl.com>
In-Reply-To: <151752475872.25625.14658191049524252377@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.27.0.171010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.240.20]
Content-Type: text/plain; charset="utf-8"
Content-ID: <7A0A92C08043014887BC38C356C8EE9C@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/GaXbPibirsx0K8BuYiCZgVpzam8>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Feb 2018 03:01:29 -0000

Christian, thank you for the review.

Regarding the concern expressed below, the alarm is issued at the other end via the Notifications (section 2.3).

Regards,
Reshad.


On 2018-02-01, 5:39 PM, "Christian Huitema" <huitema@huitema.net> wrote:

    Reviewer: Christian Huitema
    Review result: Has Nits
    
    BFD, defined in RFC5880, is a protocol intended to detect faults in the
    bidirectional path between two forwarding engines, including interfaces, data
    link(s), and to the extent possible the forwarding engines themselves, with
    potentially very low latency. The Yang module defined in this draft enables
    management of this protocol, such as toggling parameters or receiving
    notifications.
    
    As stated in the security section, the module is "to be accessed via the
    NETCONF protocol [RFC6241]", and as such its security is pretty much tied to
    that of NETCONF.
    
    My only nit comes from reading section 6.8.16 of RFC 5880, about
    "Administrative Control". This points to an obvious issue when the
    administrator of a router disables BFD on a particular link, either by mistake
    or by malice. This will make future failures harder to notify, and can affect
    operation of the network. Nothing much can be done about that on the node
    itself, but I would expect that disabling BFD would raise some kind of alarm at
    the other end of the link. I did not understand how that alarm is described in
    the Yang module, but that may be because I am not all that familiar with Yang.

v2.23.0 | Report a Bug | By Email