Re: [sacm] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 31 March 2017 22:30 UTC

Return-Path: <evoit@cisco.com>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF40F126DCA; Fri, 31 Mar 2017 15:30:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 940bh4kTDmyQ; Fri, 31 Mar 2017 15:30:20 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 034BA124217; Fri, 31 Mar 2017 15:30:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19613; q=dns/txt; s=iport; t=1490999419; x=1492209019; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7wxMQWivaC05J4CoJSQp3a/2s4VZdrYsseKXlN32Seo=; b=KZCNZ6aHuLUc3/SIJYtM6MDH7b+GStxp6tBVCiEnFd/1sGd95I3yWlc8 Js8QBsTJGBIJjzdCNNRhSmLE+EvV8pnSIeKV+/Yg7a3SGjXe07TzoqrJi 61YA2hnImMkrHPFukkKn3MvV4Os1RNGvxH1OpSR4DXNX58RHuKCzY5NLu c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AWAQBB2N5Y/5FdJa1dGQEBAQEBAQEBAQEBBwEBAQEBgm49KWGBCweNbZFViBqNN4IOHwEMgkCCbEoCg0k/GAECAQEBAQEBAWsohRUBAQEBAgEBASs7BgsFCwIBCBEEAQEBDBsHIQYLFAkIAQEEAQ0FCBOILYEtAw0IDq9BhywNgyQBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZOhG+CUUaBc4UvBZwvOwGGfIcbhC+CBokFhjiKdoh6AR84gQVbFUGGWXWIToENAQEB
X-IronPort-AV: E=Sophos;i="5.36,254,1486425600"; d="scan'208,217";a="216950536"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Mar 2017 22:30:18 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v2VMUIhm028690 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Mar 2017 22:30:18 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 31 Mar 2017 18:30:17 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Fri, 31 Mar 2017 18:30:17 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: "Waltermire, David A. (Fed)" <david.waltermire@nist.gov>, Mahesh Jethanandani <mjethanandani@gmail.com>
CC: "mile@ietf.org" <mile@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, "sacm@ietf.org" <sacm@ietf.org>
Thread-Topic: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT
Thread-Index: AdKmf/vNEHSnQfeERo2ni5F63VlU8gDGe7oAAAEA4X8AAQkXsAApvTOAAAkfouA=
Date: Fri, 31 Mar 2017 22:30:17 +0000
Message-ID: <20f788b0479b41fd8db957f78dc983aa@XCH-RTP-013.cisco.com>
References: <MWHPR09MB1440B3D5C3C983216D0BCB74F0300@MWHPR09MB1440.namprd09.prod.outlook.com>, <19D82D4B-0810-47EF-93CE-92539D64358D@gmail.com> <A406F4455056956FC17A5EEB332131B682A83BF7@unknown> <9ab236e3d421458e81f35534d2e13aaf@XCH-RTP-013.cisco.com> <MWHPR09MB1440A5DDCAC838605469B044F0370@MWHPR09MB1440.namprd09.prod.outlook.com>
In-Reply-To: <MWHPR09MB1440A5DDCAC838605469B044F0370@MWHPR09MB1440.namprd09.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.226]
Content-Type: multipart/alternative; boundary="_000_20f788b0479b41fd8db957f78dc983aaXCHRTP013ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/2XbU-SuTWfirWVS79q2jdoStJjA>
Subject: Re: [sacm] [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Mar 2017 22:30:23 -0000

For experimentation, OpenDaylight has YANG Push code for the both subscriber and publisher.  I can work with you offline to help define a viable testbed.

Eric

From: Waltermire, David A,  March 31, 2017 5:17 PM

Eric,

We have considered YANG Push as part of PANIC. I have read the draft and I attended your presentation during NETCONF. I think Yang Push is something we should consider as part of the PANIC solution. Do you have an implementation of YANG Push that can be experimented with?

Regards,
Dave

From: Eric Voit (evoit) [mailto:evoit@cisco.com]
Sent: Thursday, March 30, 2017 6:27 PM
To: Waltermire, David A. (Fed) <david.waltermire@nist.gov<mailto:david.waltermire@nist.gov>>; Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>
Cc: mile@ietf.org<mailto:mile@ietf.org>; netconf@ietf.org<mailto:netconf@ietf.org>; netmod@ietf.org<mailto:netmod@ietf.org>; sacm@ietf.org<mailto:sacm@ietf.org>
Subject: RE: [Netconf] PANIC Bar BoF Wednesday @ 6:30pm CDT

Hi David,

I know it is early, but for the secure communication part, have you considered using the YANG Push<https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/?include_text=1> work being developed in the NETCONF WG?

With this approach, you can subscribe to state changes within a device's YANG models.  These could be PANIC developed YANG models,  existing YANG models such as IETF-System, IETF-keychain, or some combination.   Then if a hacker inserts new hardware, changes software versions, adds keys, adds users, etc. that state change can be securely pushed to a subscribing where it can be determined whether the change was expected/desired.

Eric
________________________________
On: 30 March 2017 16:09, "Mahesh Jethanandani" <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>> wrote:
David,

> On Mar 26, 2017, at 5:34 PM, Waltermire, David A. (Fed) <david.waltermire@nist.gov<mailto:david.waltermire@nist.gov>> wrote:
>
>
> The US Government has been working within the IETF SACM work group to standardize the collection of endpoint configuration and other posture information from enterprise endpoints. Collecting this information is critical to support automation of common network security tasks, including asset, software, vulnerability, and configuration management. Thus far, our efforts have focused primarily on standards to collect information in support of asset, software and vulnerability management use cases, and has worked with other IETF members to determine what data would need to be to be collected, and how that data would be securely communicated across the network. Through such exchanges an organization can know what client endpoints are connected to their network, and if they are vulnerable to attack.
>
> Given the proliferation of attacks against network infrastructure devices, it is clear that the next step in our enterprise security automation effort must be to enable standardized reporting of similar information from network infrastructure devices. With the growing number of Yang models and increased adoption of NETCONF, RESTCONF, and related protocol work, the time is right to work out how these standards can be used to measure the health of network devices. This information will, as in our efforts in SACM for client devices, support asset, software, vulnerability, and configuration management use cases. Standards-based reporting of this information from network infrastructure devices will help network defenders protect against known attacks, and provide the necessary knowledge to detect and mitigate future attacks.
>
> We would like to start a discussion about how to leverage the existing IETF network management protocols to best address security automation for network infrastructure devices. We would like your ideas on how to best pursue this work, and your insights into network infrastructure security problems that will impact our networks in the future. We are holding a side meeting at IETF 98 on Wednesday, March 29th at 6:30pm CDT to start a discussion about how to move forward. We will be meeting in Vevey 4 at the IETF meeting venue.

Maybe this was discussed in the BoF ...

The best way to have a discussion would be to present the proposal in the form of a draft in the NETCONF WG.

>
> Here is a summary of the meeting details:
>
> PANIC (Posture Assessment through Network Information Collection) Bar BoF
> Wednesday, March 29th, 2017 @ 6:30pm CDT
> Swissotel Conference Center - Vevey 4
>
> We look forward to working with you, and hope to see you in Chicago at the PANIC Bar BoF.
>
> Regards,
> Dave
>
> David Waltermire
> Information Technology Laboratory | Computer Security Division
> National Institute of Standards and Technology
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org<mailto:Netconf@ietf.org>
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>