NIST SPECIAL PUBLICATION 1800-15D
Securing Small-Business and Home Internet of Things (IoT) Devices:
Mitigating Network-Based Attacks Using Manufacturer Usage Description (MUD)
Volume D:
Functional Demonstration Results
Mudumbai Ranganathan
NIST
Steve Johnson
Ashnwini Kadam
Craig Pratt
Darshak Thakore
CableLabs
Eliot Lear
Cisco
William C. Barker
Dakota Consulting
Adnan Baykal
Global Cyber Alliance
Drew Cohen
Kevin Yeich
MasterPeace Solutions, Ltd.
Yemi Fashina
Parisa Grayeli
Joshua Harrington
Joshua Klosterman
Blaine Mulugeta
Susan Symington
The MITRE Corporation
May 2021
FINAL
This publication is available free of charge from:
https://doi.org/10.6028/NIST.SP.1800-15
Draft versions of this publication is available free of charge from: https://www.nccoe.nist.gov/library/securing-small-business-and-home-internet-things-iot-devices-mitigating-network-based
DISCLAIMER
Certain commercial entities, equipment, products, or materials may be identified by name or company logo or other insignia in order to acknowledge their participation in this collaboration or to describe an experimental procedure or concept adequately. Such identification is not intended to imply special status or relationship with NIST or recommendation or endorsement by NIST or NCCoE; neither is it intended to imply that the entities, equipment, products, or materials are necessarily the best available for the purpose.
National Institute of Standards and Technology Special Publication 1800-15D, Natl. Inst. Stand. Technol. Spec. Publ. 1800-15D, 438 pages, (May 2021), CODEN: NSPUE2
FEEDBACK
As a private-public partnership, we are always seeking feedback on our practice guides. We are particularly interested in seeing how businesses apply NCCoE reference designs in the real world. If you have implemented the reference design, or have questions about applying it in your environment, please email us at mitigating-iot-ddos-nccoe@nist.gov.
All comments are subject to release under the Freedom of Information Act.
NATIONAL CYBERSECURITY CENTER OF EXCELLENCE
The National Cybersecurity Center of Excellence (NCCoE), a part of the National Institute of Standards and Technology (NIST), is a collaborative hub where industry organizations, government agencies, and academic institutions work together to address businesses’ most pressing cybersecurity issues. This public-private partnership enables the creation of practical cybersecurity solutions for specific industries, as well as for broad, cross-sector technology challenges. Through consortia under Cooperative Research and Development Agreements (CRADAs), including technology partners—from Fortune 50 market leaders to smaller companies specializing in information technology security—the NCCoE applies standards and best practices to develop modular, adaptable example cybersecurity solutions using commercially available technology. The NCCoE documents these example solutions in the NIST Special Publication 1800 series, which maps capabilities to the NIST Cybersecurity Framework and details the steps needed for another entity to re-create the example solution. The NCCoE was established in 2012 by NIST in partnership with the State of Maryland and Montgomery County, Maryland.
NIST CYBERSECURITY PRACTICE GUIDES
NIST Cybersecurity Practice Guides (Special Publication 1800 series) target specific cybersecurity challenges in the public and private sectors. They are practical, user-friendly guides that facilitate the adoption of standards-based approaches to cybersecurity. They show members of the information security community how to implement example solutions that help them align with relevant standards and best practices, and provide users with the materials lists, configuration files, and other information they need to implement a similar approach.
The documents in this series describe example implementations of cybersecurity practices that businesses and other organizations may voluntarily adopt. These documents do not describe regulations or mandatory practices, nor do they carry statutory authority.
ABSTRACT
The goal of the Internet Engineering Task Force’s Manufacturer Usage Description (MUD) specification is for Internet of Things (IoT) devices to behave as intended by the manufacturers of the devices. MUD provides a standard way for manufacturers to indicate the network communications that a device requires to perform its intended function. When MUD is used, the network will automatically permit the IoT device to send and receive only the traffic it requires to perform as intended, and the network will prohibit all other communication with the device, thereby increasing the device’s resilience to network-based attacks. In this project, the NCCoE demonstrated the ability to ensure that when an IoT device connects to a home or small-business network, MUD can automatically permit the device to send and receive only the traffic it requires to perform its intended function. This NIST Cybersecurity Practice Guide explains how MUD protocols and tools can reduce the vulnerability of IoT devices to botnets and other network-based threats as well as reduce the potential for harm from exploited IoT devices. It also shows IoT device developers and manufacturers, network equipment developers and manufacturers, and service providers who employ MUD-capable components how to integrate and use MUD to satisfy IoT users’ security requirements.
KEYWORDS
access control; bootstrapping; botnets; firewall rules; flow rules; Internet of Things (IoT); Manufacturer Usage Description (MUD); network segmentation; onboarding; router; server; software update server; threat signaling; Wi-Fi Easy Connect.
DOCUMENT CONVENTIONS
The terms “shall” and “shall not” indicate requirements to be followed strictly to conform to the publication and from which no deviation is permitted.
The terms “should” and “should not” indicate that, among several possibilities, one is recommended as particularly suitable without mentioning or excluding others or that a certain course of action is preferred but not necessarily required or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited.
The terms “may” and “need not” indicate a course of action permissible within the limits of the publication.
The terms “can” and “cannot” indicate a possibility and capability, whether material, physical, or causal.
Acronyms used in figures can be found in the Acronyms appendix.
ACKNOWLEDGMENTS
We are grateful to the following individuals for their generous contributions of expertise and time.
Name |
Organization |
|---|---|
Allaukik Abhishek |
Arm |
Michael Bartling |
Arm |
Tao Wan |
CableLabs |
Russ Gyurek |
Cisco |
Peter Romness |
Cisco |
Rob Cantu |
CTIA |
Katherine Gronberg |
Forescout |
Rae’-Mar Horne |
MasterPeace Solutions, Ltd. |
Nate Lesser |
MasterPeace Solutions, Ltd. |
Tom Martz |
MasterPeace Solutions, Ltd. |
Daniel Weller |
MasterPeace Solutions, Ltd. |
Nancy Correll |
The MITRE Corporation |
Sallie Edwards |
The MITRE Corporation |
Drew Keller |
The MITRE Corporation |
Sarah Kinling |
The MITRE Corporation |
Karri Meldorf |
The MITRE Corporation |
Mary Raguso |
The MITRE Corporation |
Allen Tan |
The MITRE Corporation |
Mo Alhroub |
Molex |
Bill Haag |
National Institute of Standards and Technology |
Paul Watrobski |
National Institute of Standards and Technology |
Bryan Dubois |
Patton Electronics |
Stephen Ochs |
Patton Electronics |
Karen Scarfone |
Scarfone Cybersecurity |
Matt Boucher |
Symantec A Division of Broadcom |
Petros Efstathopoulos |
Symantec A Division of Broadcom |
Bruce McCorkendale |
Symantec A Division of Broadcom |
Susanta Nanda |
Symantec A Division of Broadcom |
Yun Shen |
Symantec A Division of Broadcom |
Pierre-Antoine Vervier |
Symantec A Division of Broadcom |
John Bambenek |
ThreatSTOP |
Russ Housley |
Vigil Security |
The Technology Partners/Collaborators who participated in this project submitted their capabilities in response to a notice in the Federal Register. Respondents with relevant capabilities or product components were invited to sign a Cooperative Research and Development Agreement (CRADA) with NIST, allowing them to participate in a consortium to build these example solutions. We worked with:
Technology Partner/Collaborator |
Build Involvement |
|---|---|
Subject matter expertise |
|
Micronets Gateway Micronets cloud infrastructure Prototype IoT devices–Raspberry Pi with Wi-Fi Easy Connect support Micronets mobile application |
|
Cisco Catalyst 3850-S MUD manager |
|
Subject matter expertise |
|
Private Transport Layer Security certificate Premium Certificate |
|
Forescout appliance–VCT-R Enterprise manager–VCEM-05 |
|
Quad9 threat agent and Quad 9 MUD manager (integrated in Yikes! router) Quad9 domain name system Quad9 threat application programming interface ThreatSTOP threat MUD file server |
|
Yikes! router Yikes! cloud Yikes! mobile application |
|
Molex light-emitting diode light bar Molex Power over Ethernet Gateway |
|
Subject matter expertise |
|
Subject matter expertise |
List of Tables
Table 2‑1: MUD Use Case Functional Requirements
Table 2‑10: Test Case IoT-9-v4
Table 2‑11: Test Case IoT-10-v4
Table 2‑12: Test Case IoT-11-v4
Table 2‑13: Non-MUD-Related Functional Capabilities Demonstrated
Table 2‑14: Exercise CnMUD-13-v4
Table 3‑1: MUD Use Case Functional Requirements
Table 3‑10: Test Case IoT-9-v4
Table 3‑11: Test Case IoT-10-v4
Table 3‑12: Test Case IoT-11-v4
Table 3‑13: Non-MUD-Related Functional Capabilities Demonstrated
Table 3‑14: Exercise YnMUD-1-v4
Table 3‑15: Exercise YnMUD-2-v4
Table 3‑16: Exercise YnMUD-3-v4
Table 3‑17: Exercise YnMUD-4-v4
Table 3‑18: Exercise YnMUD-5-v4
Table 3‑19: Exercise YnMUD-6-v4
Table 3‑20: Exercise YnMUD-7-v4
Table 4‑1: MUD Use Case Functional Requirements
Table 4‑9: Test Case IoT-10-v4
Table 4‑10: Test Case IoT-11-v4
Table 4‑11: Non-MUD-Related Functional Capabilities Demonstrated
Table 5‑1: MUD Use Case Functional Requirements
Table 5‑9: Test Case IoT-10-v4
Table 5‑10: Test Case IoT-11-v4
1 Introduction¶
This document, Functional Demonstration Results, reports the results of the functional evaluation and demonstration of Builds 1, 2, 3, and 4. For each of these builds, we defined a list of requirements unique to that build and then developed a set of test cases to verify that the build meets those requirements. The requirements, test cases, and test results for each of these four builds are documented below.
1.1 How to Use this Guide¶
This National Institute of Standards and Technology (NIST) Cybersecurity Practice Guide demonstrates a standards-based reference design for mitigating network-based attacks by securing home and small-business Internet of Things (IoT) devices. The reference design is modular, and it can be deployed in whole or in part. This practice guide provides users with the information they need to replicate four example Manufacturer Usage Description (MUD)-based implementations of this reference design. These example implementations are referred to as Builds, and this volume describes in detail how to reproduce each one.
This guide contains four volumes:
NIST SP 1800-15A: Executive Summary – why we wrote this guide, the challenge we address, why it could be important to your organization, and our approach to solving this challenge
NIST SP 1800-15B: Approach, Architecture, and Security Characteristics – what we built and why, including the risk analysis performed, and the security control map
NIST SP 1800-15C: How-To Guides – instructions for building the example implementations including all the security relevant details that would allow you to replicate all or parts of this project
NIST SP 1800-15D: Functional Demonstration Results – documents the functional demonstration results for the four implementations of the MUD-based reference solution (you are here)
Depending on your role in your organization, you might use this guide in different ways:
Business decision makers, including chief security and technology officers, will be interested in the Executive Summary, NIST SP 1800-15A, which describes the following topics:
challenges that enterprises face in trying to mitigate network-based attacks by securing home and small-business IoT devices
example solutions built at the National Cybersecurity Center of Excellence (NCCoE)
benefits of adopting the example solutions
Technology or security program managers who are concerned with how to identify, understand, assess, and mitigate risk will be interested in NIST SP 1800-15B, which describes what we did and why. The following sections will be of particular interest:
Section 3.4, Risk Assessment, describes the risk analysis we performed.
Section 5.2, Security Control Map, maps the security characteristics of these example solutions to cybersecurity standards and best practices.
You might share the Executive Summary, NIST SP 1800-15A, with your leadership team members to help them understand the importance of adopting a standards-based solution for mitigating network-based attacks by securing home and small-business IoT devices.
IT professionals who want to implement an approach like this will find this whole practice guide useful. You can use this How-To portion of the guide, NIST SP 1800-15C, to replicate all or parts of one or all four builds created in our lab. This How-To portion of the guide provides specific product installation, configuration, and integration instructions for implementing the example solutions. We do not re-create the product manufacturers’ documentation, which is generally widely available. Rather, we show how we incorporated the products together in our environment to create an example solution.
This guide assumes that IT professionals have experience implementing security products within the enterprise. While we have used a suite of products to address this challenge, this guide does not endorse these particular products. Your organization can adopt one of these solutions or one that adheres to these guidelines in whole, or you can use this guide as a starting point for tailoring and implementing parts of a MUD-based solution. Your organization’s security experts should identify the products that will best integrate with your existing tools and IT system infrastructure. We hope that you will seek products that are congruent with applicable standards and best practices. NIST SP 1800-15B lists the products that we used in each build and maps them to the cybersecurity controls provided by this reference solution.
A NIST Cybersecurity Practice Guide does not describe “the” solution, but a possible solution. In the case of this guide, it describes four possible solutions. Comments, suggestions, and success stories will improve subsequent versions of this guide. Please contribute your thoughts to mitigating-iot-ddos-nccoe@nist.gov.
1.2 Functional Demonstration Overview¶
Functional demonstrations were conducted for four implementations of the reference design. These implementations are referred to as builds:
Build 1 uses equipment from Cisco Systems and Forescout. The Cisco MUD Manager is used to provide support for MUD, and the Forescout Virtual Appliances and Enterprise Manager are used to perform non-MUD-related device discovery on the network.
Build 2 uses equipment from MasterPeace Solutions Ltd., Global Cyber Alliance (GCA), and ThreatSTOP. The MasterPeace Solutions Yikes! router, cloud service, and mobile application are used to support MUD, as well as to perform device discovery on the network and to apply additional traffic rules to both MUD-capable and non-MUD-capable devices based on device manufacturer and model. The GCA Quad9 DNS Service and the ThreatSTOP Threat MUD File Server are used to support threat signaling.
Build 3 uses equipment from CableLabs. CableLabs Micronets (e.g., Micronets Gateway, Micronets Manager, Micronets mobile phone application, and related service provider cloud-based infrastructure) supports MUD and implements the Wi-Fi Alliance’s Wi-Fi Easy Connect protocol to securely onboard devices to the network. It also uses software-defined networking to create separate trust zones (e.g., network segments) called “micronets” to which devices are assigned according to their intended network function.
Build 4 uses software developed at the NIST Advanced Networking Technologies Laboratory. This software serves as a working prototype for demonstrating the feasibility and scalability characteristics of the MUD Request for Comments (RFC).
For a more comprehensive description of each build and a detailed explanation of each build’s architecture and technologies, refer to NIST SP 1800-15B.
1.3 Functional Demonstration Activities¶
All builds were tested to determine the extent to which they correctly implement basic functionality defined within the MUD RFC. Builds 1, 2, and 3 were also subjected to additional exercises that were designed to demonstrate non-MUD-related capabilities. These additional exercises were demonstrative rather than evaluative. They did not verify the build’s behavior for conformance to a standard or specification; they were designed to demonstrate advertised capabilities of the builds related to their ability to increase device and network security in ways that are independent of the MUD RFC. These additional capabilities may provide security for both non-MUD-capable and MUD-capable devices. Examples of this type of capability are device discovery, identification and classification, support for threat signaling, and secure, automated onboarding of devices using the Wi-Fi Easy Connect protocol.
1.4 Assumptions¶
The physical architecture of each build as deployed in the NCCoE laboratory environment is depicted and described in NIST SP 1800-15B. Tests for each build were run on the lab architecture documented in NIST SP 1800-15B. Prior to testing each build, all communication paths to the IoT devices on the network were open and could potentially be used to attack systems on the internet. For traffic to be sent between IoT devices, it was required to pass through the router/switch that served as the policy enforcement point (PEP) for the MUD rules.
In the lab setup for each build, the following hosts and web servers were required to be set up and available to support the tests defined below. On the local network where the IoT devices are located, hosts with the following names must exist and be reachable from an IoT device that is plugged into the local network:
unnamed-host (i.e., a local host that is not from the same manufacturer as the IoT device in question and whose MUD Uniform Resource Locator [URL] is not explicitly mentioned in the MUD file of the IoT device as denoting a class of devices with which the IoT device is permitted to communicate. For example, if device A’s MUD file says that it may communicate locally with devices that have MUD URLs www.zzz.com and www.xxx.com, then a local host that has a MUD file of www.qqq.com could be unnamed-host.)
anyhost-to (i.e., a local host to which the IoT device in question is permitted to initiate communications but not vice versa)
anyhost-from (i.e., a local host that is permitted to initiate communication to the IoT device but not vice versa)
same-manufacturer-host (i.e., a local host that is from the same manufacturer as the IoT device in question. For example, if device A’s MUD file is found at URL www.aaa.com and device B’s MUD file is also found at URL www.aaa.com, then device B could be same-manufacturer-host.)
On the internet (i.e., outside the local network), the following web servers must be set up and reachable from an IoT device that is plugged into the local network:
https://yes-permit-to.com (i.e., an internet location to which the IoT device in question is permitted to initiate communications but not vice versa)
https://yes-permit-from.com (i.e., an internet location that is permitted to initiate communications to the IoT device but not vice versa)
https://unnamed.com (i.e., an internet location with which the IoT device is not permitted to communicate)
We also defined several MUD files for each build (provided in each build section below) that were used to evaluate specific capabilities.
1.5 Document Conventions¶
For each build, a set of requirements and a corresponding set of functional test cases were defined to verify that the build meets a specific set of requirements that are unique to that build. For evaluating MUD-related capabilities, these requirements are closely aligned to the order of operations in the Manufacturer Usage Description Specification (RFC 8520). However, even for MUD-specific tests, there are tests that are applicable to some builds but not to others, depending on how any given build is implemented.
For each build, the MUD-related requirements for that build are listed in a table. Each of these requirements is associated with two separate tests, one using Internet Protocol version 4 (IPv4) and one using IPv6. At the time of testing, however, IPv6 functionality was not fully supported by any of the builds and so was not evaluated. The names of the tests in which each requirement is tested are listed in the rightmost column of the requirements table for each build. Tests that end with the suffix “v4” are those in which IPv4 addressing is used; tests that end with the suffix “v6” are those in which IPv6 addressing is used. Only the IPv4 versions of each test are listed explicitly in this document. For each test that has both an IPv4 and an IPv6 version, the IPv4 version of the test, IoT-n-v4, is identical to the IPv6 version of the test, IoT-n-v6, except:
IoT-n-v6 devices are configured to use IPv6, whereas IoT-n-v4 devices are configured to use IPv4.
IoT-n-v6 devices are configured to use Dynamic Host Configuration Protocol version 6 (DHCPv6), whereas IoT-n-v4 devices are configured to use DHCPv4.
The IoT-n-v6 DHCPv6 message that is emitted includes the MUD URL option that uses Internet Assigned Numbers Authority (IANA) code 112, whereas the IoT-n-v4 DHCPv4 message that is emitted includes the MUD URL option that uses IANA code 161.
Each test consists of multiple fields that collectively identify the goal of the test, the specifics required to implement the test, and how to assess the results of the test. Table 1‑1 describes all test fields.
Table 1‑1: Test Case Fields
Test Case Field |
Description |
|---|---|
Parent Requirement |
Identifies the top-level requirement or the series of top-level requirements leading to the testable requirement |
Testable Requirement |
Guides the definition of the remainder of the test case fields, and specifies the capability to be evaluated |
Description |
Describes the objective of the test case |
Associated Test Case(s) |
In some instances, a test case may be based on the outcome of (an)other test case(s). For example, analysis-based test cases produce a result that is verifiable through various means (e.g., log entries, reports, and alerts). |
Associated Cybersecurity Framework Subcategory(ies) |
Lists the Cybersecurity Framework Subcategories addressed by the test case |
IoT Device(s) Under Test |
Text identifying which IoT device is being connected to the network in this test |
MUD File(s) Used |
Name of MUD file(s) used |
Preconditions |
Starting state of the test case. Preconditions indicate various starting-state items, such as a specific capability configuration required or specific protocol and content. |
Procedure |
Step-by-step actions required to implement the test case. A procedure may consist of a single sequence of steps or multiple sequences of steps (with delineation) to indicate variations in the test procedure. |
Expected Results |
Expected results for each variation in the test procedure |
Actual Results |
Observed results |
Overall Results |
Overall result of the test as pass/fail |
Each test case is presented in the format described in Table 1‑1.
1.6 Document Organization¶
The remainder of this document describes the evaluation and demonstration activities that were performed for Builds 1, 2, 3, and 4. Each build has a section devoted to it, with that section being divided into subsections that describe the evaluation of MUD-related capabilities and the demonstration of non-MUD-related capabilities (if applicable). The MUD files used for each build are also provided.
Acronyms used in this document can be found in the Acronyms appendix in NIST SP 1800-15B.
1.7 Typographic Conventions¶
The following table presents typographic conventions used in this document.
Typeface/ Symbol |
Meaning |
Example |
|---|---|---|
Italics |
file names and path names; references to documents that are not hyperlinks; new terms; and placeholders |
For language use and style guidance, see the NCCoE Style Guide. |
Bold |
names of menus, options, command buttons, and fields |
Choose File > Edit. |
Monospace |
command-line input, onscreen computer output, sample code examples, and status codes |
|
Monospace (block) |
multi-line input, on-screen computer output, sample code examples, status codes |
% mkdir -v nccoe_projects
mkdir: created directory 'nccoe_projects'
|
blue text |
link to other parts of the document, a web URL, or an email address |
All publications from NIST’s NCCoE are available at https://www.nccoe.nist.gov. |
2 Build 1¶
Build 1 uses equipment from Cisco Systems and Forescout. The Cisco MUD Manager is used to support MUD and the Forescout Virtual Appliances, and Enterprise Manager is used to perform non-MUD-related device discovery on the network.
2.1 Evaluation of MUD-Related Capabilities¶
The functional evaluation that was conducted to verify that Build 1 conforms to the MUD specification was based on the Build 1-specific requirements defined in Table 2‑1.
2.1.1 Requirements¶
Table 2‑1: MUD Use Case Functional Requirements
Capability Requirement (CR-ID) |
Parent Requirement |
Subrequirement 1 |
Subrequirement 2 |
Test Case |
|---|---|---|---|---|
CR-1 |
The IoT DDoS example implementation shall include a mechanism for associating a device with a MUD file URL (e.g., by having the MUD-enabled IoT device emit a MUD file URL via DHCP, Link Layer Discovery Protocol [LLDP], or X.509 or by using some other mechanism to enable the network to associate a device with a MUD file URL). |
IoT-1-v4,
IoT-1-v6,
IoT-11-v4,
IoT-11-v6
|
||
CR-1.a |
Upon initialization, the MUD-enabled IoT device shall broadcast a DHCP message on the network, including at most one MUD URL, in hypertext transfer protocol secure (https) scheme, within the DHCP transaction. |
IoT-1-v4,
IoT-1-v6,
IoT-11-v4,
IoT-11-v6
|
||
CR-1.a.1 |
The DHCP server shall be able to receive DHCPv4 DISCOVER and REQUEST with IANA code 161 (OPTION_MUD_ URL_V4) from the MUD-enabled IoT device. |
IoT-1-v4,
IoT-11-v4
|
||
CR-1.a.2 |
The DHCP server shall be able to receive DHCPv6 Solicit and Request with IANA code 112 (OPTION_MUD_ URL_V6) from the MUD-enabled IoT device. |
IoT-1-v6,
IoT-11-v6
|
||
CR-1.b |
Upon initialization, the MUD-enabled IoT device shall emit the MUD URL as an LLDP extension. |
IoT-1-v4,
IoT-1-v6,
IoT-11-v4,
IoT-11-v6
|
||
CR-1.b.1 |
The network service shall be able to process the MUD URL that is received as an LLDP extension. |
IoT-1-v4,
IoT-1-v6,
IoT-11-v4,
IoT-11-v6
|
||
CR-2 |
The IoT DDoS example implementation shall include the capability for the MUD URL to be provided to a MUD manager. |
IoT-1-v4,
IoT-1-v6
|
||
CR-2.a |
The DHCP server shall assign an IP address lease to the MUD-enabled IoT device. |
IoT-1-v4,
IoT-1-v6
|
||
CR-2.a.1 |
The MUD-enabled IoT device shall receive the IP address. |
IoT-1-v4,
IoT-1-v6
|
||
CR-2.b |
The DHCP server shall receive the DHCP message and extract the MUD URL, which is then passed to the MUD manager. |
IoT-1-v4,
IoT-1-v6
|
||
CR-2.b.1 |
The MUD manager shall receive the MUD URL. |
IoT-1-v4,
IoT-1-v6
|
||
CR-3 |
The IoT DDoS example implementation shall include a MUD manager that can request a MUD file and signature from a MUD file server. |
IoT-1-v4,
IoT-1-v6
|
||
CR-3.a |
The MUD manager shall use the GET method (RFC 7231) to request MUD and signature files (per RFC 7230) from the MUD file server and can validate the MUD file server’s Transport Layer Security (TLS) certificate by using the rules in RFC 2818. |
IoT-1-v4,
IoT-1-v6
|
||
CR-3.a.1 |
The MUD file server shall receive the https request from the MUD manager. |
IoT-1-v4,
IoT-1-v6
|
||
CR-3.b |
The MUD manager shall use the GET method (RFC 7231) to request MUD and signature files (per RFC 7230) from the MUD file server, but it cannot validate the MUD file server’s TLS certificate by using the rules in RFC 2818. |
IoT-2-v4,
IoT-2-v6
|
||
CR-3.b.1 |
The MUD manager shall drop the connection to the MUD file server. |
IoT-2-v4,
IoT-2-v6
|
||
CR-3.b.2 |
The MUD manager shall send locally defined policy to the router or switch that handles whether to allow or block traffic to and from the MUD-enabled IoT device. |
IoT-2-v4,
IoT-2-v6
|
||
CR-4 |
The IoT DDoS example implementation shall include a MUD file server that can serve a MUD file and signature to the MUD manager. |
IoT-1-v4,
IoT-1-v6
|
||
CR-4.a |
The MUD file server shall serve the file and signature to the MUD manager, and the MUD manager shall check to determine whether the certificate used to sign the MUD file (signed using distinguished encoding rules [DER]-encoded Cryptographic Message Syntax [CMS] [RFC 5652]) was valid at the time of signing, i.e., the certificate had not expired. |
IoT-1-v4,
IoT-1-v6
|
||
CR-4.b |
The MUD file server shall serve the file and signature to the MUD manager, and the MUD manager shall check to determine whether the certificate used to sign the MUD file was valid at the time of signing, i.e., the certificate had already expired when it was used to sign the MUD file. |
IoT-3-v4,
IoT-3-v6
|
||
CR-4.b.1 |
The MUD manager shall cease to process the MUD file. |
IoT-3-v4,
IoT-3-v6
|
||
CR-4.b.2 |
The MUD manager shall send locally defined policy to the router or switch that handles whether to allow or block traffic to and from the MUD-enabled IoT device. |
IoT-3-v4,
IoT-3-v6
|
||
CR-5 |
The IoT DDoS example implementation shall include a MUD manager that can translate local network configurations based on the MUD file. |
IoT-1-v4,
IoT-1-v6
|
||
CR-5.a |
The MUD manager shall successfully validate the signature of the MUD file. |
IoT-1-v4,
IoT-1-v6
|
||
CR-5.a.1 |
The MUD manager, after validation of the MUD file signature, shall check for an existing MUD file and translate abstractions in the MUD file to router or switch configurations. |
IoT-1-v4,
IoT-1-v6
|
||
CR-5.a.2 |
The MUD manager shall cache this newly received MUD file. |
IoT-10-v4,
IoT-10-v6
|
||
CR-5.b |
The MUD manager shall attempt to validate the signature of the MUD file, but the signature validation fails (even though the certificate that had been used to create the signature had not been expired at the time of signing, i.e., the signature is invalid for a different reason). |
IoT-4-v4,
IoT-4-v6
|
||
CR-5.b.1 |
The MUD manager shall cease processing the MUD file. |
IoT-4-v4,
IoT-4-v6
|
||
CR-5.b.2 |
The MUD manager shall send locally defined policy to the router or switch that handles whether to allow or block traffic to and from the MUD-enabled IoT device. |
IoT-4-v4,
IoT-4-v6
|
||
CR-6 |
The IoT DDoS example implementation shall include a MUD manager that can configure the MUD PEP, i.e., the router or switch nearest the MUD-enabled IoT device that emitted the URL. |
IoT-1-v4,
IoT-1-v6
|
||
CR-6.a |
The MUD manager shall install a router configuration on the router or switch nearest the MUD-enabled IoT device that emitted the URL. |
IoT-1-v4,
IoT-1-v6
|
||
CR-6.a.1 |
The router or switch shall have been configured to enforce the route filter sent by the MUD manager. |
IoT-1-v4,
IoT-1-v6
|
||
CR-7 |
The IoT DDoS example implementation shall allow the MUD-enabled IoT device to communicate with approved internet services in the MUD file. |
IoT-5-v4,
IoT-5-v6
|
||
CR-7.a |
The MUD-enabled IoT device shall attempt to initiate outbound traffic to approved internet services. |
IoT-5-v4,
IoT-5-v6
|
||
CR-7.a.1 |
The router or switch shall receive the attempt and shall allow it to pass based on the filters from the MUD file. |
IoT-5-v4,
IoT-5-v6
|
||
CR-7.b |
An approved internet service shall attempt to initiate a connection to the MUD-enabled IoT device. |
IoT-5-v4,
IoT-5-v6
|
||
CR-7.b.1 |
The router or switch shall receive the attempt and shall allow it to pass based on the filters from the MUD file. |
IoT-5-v4,
IoT-5-v6
|
||
CR-8 |
The IoT DDoS example implementation shall deny communications from a MUD-enabled IoT device to unapproved internet services (i.e., services that are denied by virtue of not being explicitly approved). |
IoT-5-v4,
IoT-5-v6
|
||
CR-8.a |
The MUD-enabled IoT device shall attempt to initiate outbound traffic to unapproved (implicitly denied) internet services. |
IoT-5-v4,
IoT-5-v6
|
||
CR-8.a.1 |
The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. |
IoT-5-v4,
IoT-5-v6
|
||
CR-8.b |
An unapproved (implicitly denied) internet service shall attempt to initiate a connection to the MUD-enabled IoT device. |
IoT-5-v4,
IoT-5-v6
|
||
CR-8.b.1 |
The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. |
IoT-5-v4,
IoT-5-v6
|
||
CR-8.c |
The MUD-enabled IoT device shall initiate communications to an internet service that is approved to initiate communications with the MUD-enabled device but not approved to receive communications initiated by the MUD-enabled device. |
IoT-5-v4,
IoT-5-v6
|
||
CR-8.c.1 |
The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. |
IoT-5-v4,
IoT-5-v6
|
||
CR-8.d |
An internet service shall initiate communications to a MUD-enabled device that is approved to initiate communications with the internet service but that is not approved to receive communications initiated by the internet service. |
IoT-5-v4,
IoT-5-v6
|
||
CR-8.d.1 |
The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. |
IoT-5-v4,
IoT-5-v6
|
||
CR-9 |
The IoT DDoS example implementation shall allow the MUD-enabled IoT device to communicate laterally with devices that are approved in the MUD file. |
IoT-6-v4,
IoT-6-v6
|
||
CR-9.a |
The MUD-enabled IoT device shall attempt to initiate lateral traffic to approved devices. |
IoT-6-v4,
IoT-6-v6
|
||
CR-9.a.1 |
The router or switch shall receive the attempt and shall allow it to pass based on the filters from the MUD file. |
IoT-6-v4,
IoT-6-v6
|
||
CR-9.b |
An approved device shall attempt to initiate a lateral connection to the MUD-enabled IoT device. |
IoT-6-v4,
IoT-6-v6
|
||
CR-9.b.1 |
The router or switch shall receive the attempt and shall allow it to pass based on the filters from the MUD file. |
IoT-6-v4,
IoT-6-v6
|
||
CR-10 |
The IoT DDoS example implementation shall deny lateral communications from a MUD-enabled IoT device to devices that are not approved in the MUD file (i.e., devices that are implicitly denied by virtue of not being explicitly approved). |
IoT-6-v4,
IoT-6-v6
|
||
CR-10.a |
The MUD-enabled IoT device shall attempt to initiate lateral traffic to unapproved (implicitly denied) devices. |
IoT-6-v4,
IoT-6-v6
|
||
CR-10.a.1 |
The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. |
IoT-6-v4,
IoT-6-v6
|
||
CR-10.b |
An unapproved (implicitly denied) device shall attempt to initiate a lateral connection to the MUD-enabled IoT device. |
IoT-6-v4,
IoT-6-v6
|
||
CR-10.b.1 |
The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. |
IoT-6-v4,
IoT-6-v6
|
||
CR-11 |
If the IoT DDoS example implementation is such that its DHCP server does not act as a MUD manager and it forwards a MUD URL to a MUD manager, the DHCP server must notify the MUD manager of any corresponding change to the DHCP state of the MUD-enabled IoT device, and the MUD manager should remove the implemented policy configuration in the router/switch pertaining to that MUD-enabled IoT device. |
IoT-7-v4,
IoT-7-v6
|
||
CR-11.a |
The MUD-enabled IoT device shall explicitly release the IP address lease (i.e., it sends a DHCP release message to the DHCP server). |
IoT-7-v4,
IoT-7-v6
|
||
CR-11.a.1 |
The DHCP server shall notify the MUD manager that the device’s IP address lease has been released. |
IoT-7-v4,
IoT-7-v6
|
||
CR-11.a.2 |
The MUD manager should remove all policies associated with the disconnected IoT device that had been configured on the MUD PEP router/switch. |
IoT-7-v4,
IoT-7-v6
|
||
CR-11.b |
The MUD-enabled IoT device’s IP address lease shall expire. |
IoT-8-v4,
IoT-8-v6
|
||
CR-11.b.1 |
The DHCP server shall notify the MUD manager that the device’s IP address lease has expired. |
IoT-8-v4,
IoT-8-v6
|
||
CR-11.b.2 |
The MUD manager should remove all policies associated with the affected IoT device that had been configured on the MUD PEP router/switch. |
IoT-8-v4,
IoT-8-v6
|
||
CR-12 |
The IoT DDoS example implementation shall include a MUD manager that uses a cached MUD file rather than retrieve a new one if the cache-validity time period has not yet elapsed for the MUD file indicated by the MUD URL. The MUD manager should fetch a new MUD file if the cache-validity time period has already elapsed. |
IoT-10-v4,
IoT-10-v6
|
||
CR-12.a |
The MUD manager shall check if the file associated with the MUD URL is present in its cache and shall determine that it is. |
IoT-10-v4,
IoT-10-v6
|
||
CR-12.a.1 |
The MUD manager shall check whether the amount of time that has elapsed since the cached file was retrieved is less than or equal to the number of hours in the cache-validity value for this MUD file. If so, the MUD manager shall apply the contents of the cached MUD file. |
IoT-10-v4,
IoT-10-v6
|
||
CR-12.a.2 |
The MUD manager shall check whether the amount of time that has elapsed since the cached file was retrieved is greater than the number of hours in the cache-validity value for this MUD file. If so, the MUD manager may (but does not have to) fetch a new file by using the MUD URL received. |
IoT-10-v4,
IoT-10-v6
|
||
CR-13 |
The IoT DDoS example implementation shall ensure that for each rule in a MUD file that pertains to an external domain, the MUD PEP router/switch will get configured with all possible instantiations of that rule, insofar as each instantiation contains one of the IP addresses to which the domain in that MUD file rule may be resolved when queried by the MUD PEP router/switch. |
IoT-9-v4,
IoT-9-v6
|
||
CR-13.a |
The MUD file for a device shall contain a rule involving a domain that can resolve to multiple IP addresses when queried by the MUD PEP router/switch. An access control list (ACL) for permitting access to each of those IP addresses will be inserted into the MUD PEP router/switch for the device in question, and the device will be permitted to communicate with all of those IP addresses. |
IoT-9-v4,
IoT-9-v6
|
||
CR-13.a.1 |
IPv4 addressing is used on the network. |
IoT-9-v4
|
||
CR-13.a.2 |
IPv6 addressing is used on the network. |
IoT-9-v6
|
2.1.2 Test Cases¶
This section contains the test cases that were used to verify that Build 1 met the requirements listed in Table 2‑1.
2.1.2.1 Test Case IoT-1-v4¶
Table 2‑2: Test Case IoT-1-v4
Test Case Field |
Description |
|---|---|
Parent Requirements |
(CR-1) The IoT DDoS example implementation shall include a mechanism for associating a device with a MUD file URL (e.g., by having the MUD-enabled IoT device emit a MUD file URL via DHCP, Link Layer Discovery Protocol [LLDP], or X.509 or by using some other mechanism to enable the network to associate a device with a MUD file URL). (CR-2) The IoT DDoS example implementation shall include the capability for the MUD URL to be provided to a MUD manager. (CR-3) The IoT DDoS example implementation shall include a MUD manager that can request a MUD file and signature from a MUD file server. (CR-4) The IoT DDoS example implementation shall include a MUD file server that can serve a MUD file and signature to the MUD manager. (CR-5) The IoT DDoS example implementation shall include a MUD manager that can translate local network configurations based on the MUD file. (CR-6) The IoT DDoS example implementation shall include a MUD manager that can configure the router or switch nearest the MUD-enabled IoT device that emitted the URL. |
Testable Requirements |
(CR-1.a) Upon initialization, the MUD-enabled IoT device shall broadcast a DHCP message on the network, including at most one MUD URL, in https scheme, within the DHCP transaction. (CR-1.a.1) The DHCP server shall be able to receive DHCPv4 DISCOVER and REQUEST with IANA code 161 (OPTION_MUD_URL_V4) from the MUD-enabled IoT device. (Note: Test IoT-1-v6 does not test this requirement; instead, it tests CR-1.a.2, which pertains to DHCPv6 rather than DHCPv4.) OR (CR-1.b) Upon initialization, the MUD-enabled IoT device shall emit the MUD URL as an LLDP extension. (CR-1.b.1) The network service shall be able to process the MUD URL that is received as an LLDP extension. (CR-2.a) The DHCP server shall assign an IP address lease to the MUD-enabled IoT device. (CR-2.a.1) The MUD-enabled IoT device shall receive the IP address. (CR-2.b) The DHCP server shall receive the DHCP message and extract the MUD URL, which is then passed to the MUD manager. (CR-2.b.1) The MUD manager shall receive the MUD URL. (CR-3.a) The MUD manager shall use the “GET” method (RFC 7231) to request MUD and signature files (per RFC 7230) from the MUD file server and can validate the MUD file server’s TLS certificate by using the rules in RFC 2818. (CR-3.a.1) The MUD file server shall receive the https request from the MUD manager. (CR-4.a) The MUD file server shall serve the file and signature to the MUD manager, and the MUD manager shall check to determine whether the certificate used to sign the MUD file (signed using DER-encoded CMS [RFC 5652]) was valid at the time of signing, i.e., the certificate had not expired. (CR-5.a) The MUD manager shall successfully validate the signature of the MUD file. (CR-5.a.1) The MUD manager, after validation of the MUD file signature, shall check for an existing MUD file and translate abstractions in the MUD file to router or switch configurations. (CR-6.a) The MUD manager shall install a router configuration on the router or switch nearest the MUD-enabled IoT device that emitted the URL. (CR-6.a.1) The router or switch shall have been configured to enforce the route filter sent by the MUD manager. |
Description |
Shows that, upon connection to the network, a MUD-enabled IoT device used in the IoT DDoS example implementation has its MUD PEP router/switch automatically configured to enforce the route filtering that is described in the device’s MUD file, assuming the MUD file has a valid signature and is served from a MUD file server that has a valid TLS certificate |
Associated Test Case(s) |
N/A |
Associated
Cybersecurity
Framework
Subcategory(ies)
|
ID.AM-1, ID.AM-2, ID.AM-3, PR.DS-5, DE.AE-1, PR.AC-4, PR.AC-5, PR.IP-1, PR.IP-3, PR.PT-3, PR.DS-2 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
ciscopi2.json |
Preconditions |
|
Procedure |
Verify that the MUD PEP router/switch for the IoT device to be used in the test does not yet have any configuration settings installed with respect to the IoT device being used in the test. Also verify that the MUD file of the IoT device to be used is not currently cached at the MUD manager. Power on the IoT device and connect it to the test network. This should set in motion the following series of steps, which should occur automatically:
|
Expected Results |
The MUD PEP router/switch for the IoT device has had its configuration changed, i.e., it has been configured to enforce the policies specified in the IoT device’s MUD file. The expected configuration should resemble the following details: Extended IP access list mud-81726-v4fr.in
10 permit tcp any host 192.168.4.7 eq www ack syn
20 permit tcp any host 192.168.10.104 eq www
30 permit tcp any host 192.168.10.105 eq www
50 permit tcp any 192.168.10.0 0.0.0.255 eq www
60 permit tcp any 192.168.13.0 0.0.0.255 eq www
70 permit tcp any 192.168.14.0 0.0.0.255 eq www
80 permit tcp any eq 22 any
81 permit udp any eq bootpc any eq bootps
82 permit udp any any eq domain
83 deny ip any any
All protocol exchanges described in steps 1–7 above are expected to occur and can be viewed via Wireshark if desired. If the router/switch does not get configured in accordance with the MUD file, each exchange of DHCP and MUD-related protocol traffic should be viewed on the network via Wireshark to determine which transactions did not proceed as expected, and the observed and absent protocol exchanges should be described here. |
Actual Results |
Dynamic access-session on switch: Build1# sh access-session int g1/0/15 det**
Interface: GigabitEthernet1/0/15
IIF-ID: 0x1B6BCEA5
MAC Address: b827.ebeb.6c8b
IPv6 Address: Unknown
IPv4 Address: 192.168.13.9
User-Name: b827ebeb6c8b
Status: Authorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: both
Session timeout: N/A
Common Session ID: C0A80A02000000A6A9828F06
Acct Session ID: 0x0000003b
Handle: 0x2200009c
Current Policy: mud-mab-test
Server Policies:
ACS ACL: mud-81726-v4fr.in
Vlan Group: Vlan: 3
Method status list:
Method State
mab Authc Success
access-list on switch: Build1# sh access-list mud-81726-v4fr.in
Extended IP access list mud-81726-v4fr.in
10 permit tcp any host 192.168.4.7 eq www ack syn
20 permit tcp any host 192.168.10.104 eq www
30 permit tcp any host 192.168.10.105 eq www
50 permit tcp any 192.168.10.0 0.0.0.255 eq www
60 permit tcp any 192.168.13.0 0.0.0.255 eq www
70 permit tcp any 192.168.14.0 0.0.0.255 eq www
80 permit tcp any eq 22 any
81 permit udp any eq bootpc any eq bootps
82 permit udp any any eq domain
83 deny ip any any
|
Overall Results |
Pass |
Test case IoT-1-v6 is identical to test case IoT-1-v4 except that IoT-1-v6 tests requirement CR-1.a.2, whereas IoT-1-v4 tests requirement CR-1.a.1. Hence, as explained above, test case IoT-1-v6 uses IPv6, DHCPv6, and IANA code 112 instead of using IPv4, DHCPv4, and IANA code 161.
2.1.2.2 Test Case IoT-2-v4¶
Table 2‑3: Test Case IoT-2-v4
Test Case Field |
Description |
|---|---|
Parent Requirement |
(CR-3) The IoT DDoS example implementation shall include a MUD manager that can request a MUD file and signature from a MUD file server. |
Testable requirement |
(CR-3.b) The MUD manager shall use the GET method (RFC 7231) to request MUD and signature files (per RFC 7230) from the MUD file server, but it cannot validate the MUD file server’s TLS certificate by using the rules in RFC 2818. (CR-3.b.1) The MUD manager shall drop the connection to the MUD file server. (CR-3.b.2) The MUD manager shall send locally defined policy to the router or switch that handles whether to allow or block traffic to and from the MUD-enabled IoT device. |
Description |
Shows that if a MUD manager is not able to validate the TLS certificate of a MUD file server when trying to retrieve the MUD file for a specific IoT device, the MUD manager will drop the connection to the MUD file server and configure the router/switch according to locally defined policy regarding whether to allow or block traffic to the IoT device in question |
Associated Test Case(s) |
IoT-11-v4 (for the v6 version of this test, IoT-11-v6) |
Associated Cybersecurity Framework Subcategory(ies) |
PR.AC-7 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
ciscopi2.json |
Preconditions |
|
Procedure |
Verify that the MUD PEP router/switch for the IoT device to be used in the test does not yet have any configuration settings installed with respect to the IoT device being used in the test. Power on the IoT device and connect it to the test network. This should set in motion the following series of steps, which should occur automatically:
|
Expected Results |
The MUD PEP router/switch for the IoT device has had its configuration changed, i.e., it has been configured to local policy for communication to/from the IoT device. |
Actual Results |
***MUDC [STATUS][send_mudfs_request:2005]-->
Request URI <\https://mudfileserver/ciscopi2> </home/mudtester/ca.cert.pem>
* Trying 192.168.4.5...
* TCP_NODELAY set
* Connected to mudfileserver (192.168.4.5) port 443 (#0)
* found 1 certificate in /home/mudtester/ca.cert.pem
* found 400 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
* server certificate verification failed. CAfile:
/home/mudtester/ca.cert.pem CRLfile: none
* stopped the pause stream!
* Closing connection 0
***MUDC [ERROR][fetch_file:182]--> curl_easy_perform() failed: Peer
certificate cannot be authenticated with given CA certificates
***MUDC [INFO][send_mudfs_request:2019]--> Unable to reach MUD fileserver to
fetch MUD file. Will try to append .json
* Trying 192.168.4.5...
* TCP_NODELAY set
* Connected to mudfileserver (192.168.4.5) port 443 (#0)
* found 1 certificate in /home/mudtester/ca.cert.pem
* found 400 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
* server certificate verification failed. CAfile:
/home/mudtester/ca.cert.pem CRLfile: none
* stopped the pause stream!
* Closing connection 0
***MUDC [ERROR][fetch_file:182]--> curl_easy_perform() failed: Peer
certificate cannot be authenticated with given CA certificates
***MUDC [ERROR][send_mudfs_request:2027]--> Unable to reach MUD fileserver
to fetch .json file
***MUDC [INFO][mudc_construct_head:135]--> status_code: 204, content_len:
14, extra_headers: (null)
***MUDC [INFO][mudc_construct_head:152]--> HTTP header: HTTP/1.1 204 No
Content
Content-Length: 14
***MUDC [INFO][send_error_result:176]--> error from FS
***MUDC [ERROR][send_mudfs_request:2170]--> mudfs_conn failed
Build1#sho access-session int g1018 det
Interface GigabitEthernet1018
IIF-ID 0x181835C2
MAC Address b827.eba7.0533
IPv6 Address Unknown
IPv4 Address 192.168.10.106
User-Name b827eba70533
Status Authorized
Domain DATA
Oper host mode multi-auth
Oper control dir both
Session timeout NA
Common Session ID C0A80A02000000CCBDB267F8
Acct Session ID 0x00000046
Handle 0x100000c2
Current Policy mud-mab-test
Server Policies
Method status list
Method State
mab Authc Success
|
Overall Results |
Pass |
As explained above, test IoT-2-v6 is identical to test IoT-2-v4 except that it uses IPv6, DHCPv6, and IANA code 112 instead of using IPv4, DHCPv4, and IANA code 161.
2.1.2.3 Test Case IoT-3-v4¶
Table 2‑4: Test Case IoT-3-v4
Test Case Field |
Description |
|---|---|
Parent Requirement |
(CR-4) The IoT DDoS example implementation shall include a MUD file server that can serve a MUD file and signature to the MUD manager. |
Testable Requirement |
(CR-4.b) The MUD file server shall serve the file and signature to the MUD manager, and the MUD manager shall check to determine whether the certificate used to sign the MUD file was valid at the time of signing, i.e., the certificate had already expired when it was used to sign the MUD file. (CR-4.b.1) The MUD manager shall cease to process the MUD file. (CR-4.b.2) The MUD manager shall send locally defined policy to the router or switch that handles whether to allow or block traffic to and from the MUD-enabled IoT device. |
Description |
Shows that if a MUD file server serves a MUD file with a signature that was created with an expired certificate, the MUD manager will cease processing the MUD file |
Associated Test Case(s) |
IoT-11-v4 (for the v6 version of this test, IoT-11-v6) |
Associated Cybersecurity Framework Subcategory(ies) |
PR.DS‐6 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
expiredcerttest.json |
Preconditions |
|
Procedure |
Verify that the MUD PEP router/switch for the IoT device to be used in the test does not yet have any configuration settings installed with respect to the IoT device being used in the test. Power on the IoT device and connect it to the test network. This should set in motion the following series of steps, which should occur automatically:
|
Expected Results |
The MUD PEP router/switch for the IoT device has had its configuration changed, i.e., it has been configured to deny all communication to and from the IoT device. The expected configuration should resemble the details below. Expecting a show access session without a MUD file as seen below: Build1#show access-session int g1018 det
Interface GigabitEthernet1018
IIF-ID 0x181835C2
MAC Address b827.eba7.0533
IPv6 Address Unknown
IPv4 Address 192.168.10.106
User-Name b827eba70533
Status Authorized
Domain DATA
Oper control dir both
Session timeout NA
Common Session ID C0A80A02000000CCBDB267F8
Acct Session ID 0x00000046
Handle 0x100000c2
Current Policy mud-mab-test
Server Policies
Method status list
Method State
mab Authc Success
|
Actual Results |
***MUDC [INFO][verify_mud_content:1594]--> BIO_reset <1>
***MUDC [ERROR][verify_mud_content:1604]--> Verification Failure
139713269933824:error:2E099064:CMS
routines:cms_signerinfo_verify_cert:certificate verify
error:../crypto/cms/cms_smime.c:253:Verify error: certificate has
expired
***MUDC [INFO][send_mudfs_request:2092]--> Verification failed. Manufacturer
Index <0>
***MUDC [INFO][mudc_construct_head:135]--> status_code: 401, content_len:
19, extra_headers: (null)
***MUDC [INFO][mudc_construct_head:152]--> HTTP header: HTTP/1.1 401
Unauthorized
Content-Length: 19
***MUDC [INFO][send_error_result:176]--> Verification failed
***MUDC [ERROR][send_mudfs_request:2170]--> mudfs_conn failed
Build1#sho access-session int g1018 det
Interface GigabitEthernet1018
IIF-ID 0x181835C2
MAC Address b827.eba7.0533
IPv6 Address Unknown
IPv4 Address 192.168.10.106
User-Name b827eba70533
Status Authorized
Domain DATA
Oper host mode multi-auth
Oper control dir both
Session timeout NA
Common Session ID C0A80A02000000CCBDB267F8
Acct Session ID 0x00000046
Handle 0x100000c2
Current Policy mud-mab-test
Server Policies
Method status list
Method State
mab Authc Success
|
Overall Results |
Pass |
As explained above, test IoT-3-v6 is identical to test IoT-3-v4 except that it uses IPv6, DHCPv6, and IANA code 112 instead of using IPv4, DHCPv4, and IANA code 161.
2.1.2.4 Test Case IoT-4-v4¶
Table 2‑5: Test Case IoT-4-v4
Test Case Field |
Description |
|---|---|
Parent Requirement |
(CR-5) The IoT DDoS example implementation shall include a MUD manager that can translate local network configurations based on the MUD file. |
Testable Requirement |
(CR-5.b) The MUD manager shall attempt to validate the signature of the MUD file, but the signature validation fails (even though the certificate that had been used to create the signature had not been expired at the time of signing, i.e., the signature is invalid for a different reason). (CR-5.b.1) The MUD manager shall cease processing the MUD file. (CR-5.b.2) The MUD manager shall send locally defined policy to the router or switch that handles whether to allow or block traffic to and from the MUD-enabled IoT device. |
Description |
Shows that if the MUD manager determines that the signature on the MUD file it receives from the MUD file server is invalid, it will cease processing the MUD file and configure the router/switch according to locally defined policy regarding whether to allow or block traffic to the IoT device in question |
Associated Test Case(s) |
IoT-11-v4 (for the v6 version of this test, IoT-11-v6) |
Associated Cybersecurity Framework Subcategory(ies) |
PR.DS‐6 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
ciscop2.json |
Preconditions |
|
Procedure |
Verify that the MUD PEP router/switch for the IoT device to be used in the test does not yet have any configuration settings installed with respect to the IoT device being used in the test. Power on the IoT device and connect it to the test network. This should set in motion the following series of steps, which should occur automatically:
|
Expected Results |
The MUD PEP router/switch for the IoT device has had its configuration changed, i.e., it has been configured to deny all communication to/from the IoT device. The expected configuration should resemble the following details. Expecting a show access session without a MUD file as seen below: Build1#sho access-session int g1018 det
Interface GigabitEthernet1018
IIF-ID 0x181835C2
MAC Address b827.eba7.0533
IPv6 Address Unknown
IPv4 Address 192.168.10.106
User-Name b827eba70533
Status Authorized
Domain DATA
Oper host mode multi-auth
Oper control dir both
Session timeout NA
Common Session ID C0A80A02000000CCBDB267F8
Acct Session ID 0x00000046
Handle 0x100000c2
Current Policy mud-mab-test
Server Policies
Method status list
Method State
mab Authc Success
|
Actual Results |
> GET /ciscopi2.json HTTP/1.1
Host: mudfileserver
Accept: */*
[Omitted for brevity] ***MUDC [STATUS][send_mudfs_request:2060]-->
Request signature URI <\https://mudfileserver/ciscopi2.p7s>
</home/mudtester/mud-intermediate.pem>
* Trying 192.168.4.5...
* TCP_NODELAY set
* Connected to mudfileserver (192.168.4.5) port 443 (#0)
* found 1 certificate in /home/mudtester/mud-intermediate.pem
* found 400 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: mudfileserver (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: C=US,ST=Maryland,L=Rockville,O=National Cybersecurity Center
of Excellence - NIST,CN=mudfileserver
* start date: Fri, 05 Oct 2018 00:00:00 GMT
* expire date: Wed, 13 Oct 2021 12:00:00 GMT
* issuer: C=US,O=DigiCert Inc,CN=DigiCert Test SHA2 Intermediate CA-1
* compression: NULL
* ALPN, server did not agree to a protocol
> GET /ciscopi2.p7s HTTP/1.1
Host: mudfileserver
Accept: */*
[Omitted for brevity] ***MUDC [INFO][send_mudfs_request:2080]--> MUD signature file successfully
retrieved
***MUDC [DEBUG][verify_mud_content:1543]--> MUD signature file (length 4680)
[shortened logs]
***MUDC [INFO][verify_mud_content:1594]--> BIO_reset <1>
***MUDC [ERROR][verify_mud_content:1604]--> **Verification Failure**
140561528563456:error:2E09A09E:CMS
routines:CMS_SignerInfo_verify_content:verification
failure:../crypto/cms/cms_sd.c:819:
140561528563456:error:2E09D06D:CMS routines:CMS_verify:content verify
error:../crypto/cms/cms_smime.c:393:
***MUDC [INFO][send_mudfs_request:2092]--> **Verification failed.
Manufacturer Index <0>**
***MUDC [INFO][mudc_construct_head:135]--> status_code: 401, content_len:
19, extra_headers: (null)
***MUDC [INFO][mudc_construct_head:152]--> HTTP header: HTTP/1.1 401
Unauthorized
Content-Length: 19
***MUDC [INFO][send_error_result:176]--> Verification failed
***MUDC [ERROR][send_mudfs_request:2170]--> mudfs_conn failed
Switch access-session: Build1#sho access-session int g1/0/18 det
Interface: GigabitEthernet1/0/18
IIF-ID: 0x11C404C6
MAC Address: b827.eba7.0533
IPv6 Address: Unknown
IPv4 Address: 192.168.10.106
User-Name: b827eba70533
Status: Authorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: both
Session timeout: N/A
Common Session ID: C0A80A02000000CDBDB68A30
Acct Session ID: 0x00000047
Handle: 0x690000c3
Current Policy: mud-mab-test
Server Policies:
Method status list:
Method State
mab Authc Success
|
Overall Results |
Pass |
As explained above, test IoT-4-v6 is identical to test IoT-4-v4 except that it uses IPv6, DHCPv6, and IANA code 112 instead of using IPv4, DHCPv4, and IANA code 161.
2.1.2.5 Test Case IoT-5-v4¶
Table 2‑6: Test Case IoT-5-v4
Test Case Field |
Description |
|---|---|
Parent Requirement |
(CR-7) The IoT DDoS example implementation shall allow the MUD-enabled IoT device to communicate with approved internet services in the MUD file. (CR-8) The IoT DDoS example implementation shall deny communications from a MUD-enabled IoT device to unapproved internet services (i.e., services that are implicitly denied by virtue of not being explicitly approved). |
Testable Requirement |
(CR-7.a) The MUD-enabled IoT device shall attempt to initiate outbound traffic to approved internet services. (CR-7.a.1) The router or switch shall receive the attempt and shall allow it to pass based on the filters from the MUD file. (CR-7.b) An approved internet service shall attempt to initiate a connection to the MUD-enabled IoT device. (CR-7.b.1) The router or switch shall receive the attempt and shall allow it to pass based on the filters from the MUD file. (CR-8.a) The MUD-enabled IoT device shall attempt to initiate outbound traffic to unapproved (implicitly denied) internet services. (CR-8.a.1) The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. (CR-8.b) An unapproved (implicitly denied) internet service shall attempt to initiate a connection to the MUD-enabled IoT device. (CR-8.b.1) The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. (CR-8.c) The MUD-enabled IoT device shall initiate communications to an internet service that is approved to initiate communications with the MUD-enabled device but not approved to receive communications initiated by the MUD-enabled device. (CR-8.c.1) The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. (CR-8.d) An internet service shall initiate communications to a MUD-enabled device that is approved to initiate communications with the internet service but that is not approved to receive communications initiated by the internet service. (CR-8.d.1) The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. |
Description |
Shows that, upon connection to the network, a MUD-enabled IoT device used in the IoT DDoS example implementation has its MUD PEP router/switch automatically configured to enforce the route filtering that is described in the device’s MUD file with respect to communication with internet services. Further shows that the policies that are configured on the MUD PEP router/switch with respect to communication with internet services will be enforced as expected, with communications that are configured as denied being blocked, and communications that are configured as permitted being allowed. |
Associated Test Case(s) |
IoT-1-v4 (for the v6 version of this test, IoT-1-v6) |
Associated Cybersecurity Framework Subcategory(ies) |
ID.AM-3, PR.DS-5, PR.IP-1, PR.PT-3 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
ciscopi2.json |
Preconditions |
Test IoT-1-v4 (or IoT-1-v6) has run successfully, meaning that the MUD PEP router/switch has been configured to enforce the following policies for the IoT device in question (as defined in the MUD file in Section 2.1.3):
|
Procedure |
Note: Procedure steps with strike-through were not tested in this phase because ingress dynamic access control lists (DACLs) are not supported in this implementation.
|
Expected Results |
Each of the results that is listed as needing to be verified in procedure steps above occurs as expected. |
Actual Results |
Procedure 2: Connection to update server successfully initiated by IoT device: pi@raspberrypi:~ $ wget http://www.updateserver.com/
--2018-12-13 21:28:00-- http://www.updateserver.com/
Resolving www.updateserver.com (www.updateserver.com)... 192.168.4.7
Connecting to www.updateserver.com
(www.updateserver.com)|192.168.4.7|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10918 (11K) [text/html]
Saving to: ‘index.html.2’
index.html.2 100%[===================>] 10.66K --.-KB/s in 0s
2018-12-13 21:28:00 (30.6 MB/s) - ‘index.html.2’ saved [10918/10918]
Procedure 3: Update server failed to connect to IoT device: iot@update-server:~$ wget http://192.168.13.9
--2018-12-13 21:49:36-- http://192.168.13.9/
Connecting to 192.168.13.9:80... failed: Connection timed out.
Retrying.
Procedure 6: IoT device failed to connect to unapproved server: pi@raspberrypi:~ $ wget http://192.168.4.105
--2018-12-14 16:42:36-- http://192.168.4.105/
Connecting to 192.168.4.105:80... failed: Connection timed out.
Retrying.
Procedure 7: Unapproved server attempts to connect to IoT device: [mud@unapprovedserver ~]$ wget http://192.168.13.14
--2018-12-14 13:03:32-- http://192.168.13.14/
Connecting to 192.168.13.14:80... failed: Connection timed out.
Retrying.
|
Overall Results |
Pass (for testable procedures—as stated, ingress cannot be tested) |
As explained above, test IoT-5-v6 is identical to test IoT-5-v4 except that it uses IPv6, DHCPv6, and IANA code 112 instead of using IPv4, DHCPv4, and IANA code 161.
2.1.2.6 Test Case IoT-6-v4¶
Table 2‑7: Test Case IoT-6-v4
Test Case Field |
Description |
|---|---|
Parent Requirement |
(CR-9) The IoT DDoS example implementation shall allow the MUD-enabled IoT device to communicate laterally with devices that are approved in the MUD file. (CR-10) The IoT DDoS example implementation shall deny latterly communications from a MUD-enabled IoT device to devices that are not approved in the MUD file (i.e., devices that are implicitly denied by virtue of not being explicitly approved). |
Testable Requirement |
(CR-9.a) The MUD-enabled IoT device shall attempt to initiate lateral traffic to approved devices. (CR-9.a.1) The router or switch shall receive the attempt and shall allow it to pass based on the filters from the MUD file. (CR-9.b) An approved device shall attempt to initiate a lateral connection to the MUD-enabled IoT device. (CR-9.b.1) The router or switch shall receive the attempt and shall allow it to pass based on the filters from the MUD file. (CR-10.a) The MUD-enabled IoT device shall attempt to initiate lateral traffic to unapproved (implicitly denied) devices. (CR-10.a.1) The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. (CR-10.b) An unapproved (implicitly denied) device shall attempt to inititate a lateral connection to the MUD-enabled IoT device. (CR-10.b.1) The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. |
Description |
Shows that, upon connection to the network, a MUD-enabled IoT device used in the IoT DDoS example implementation has its MUD PEP router/switch automatically configured to enforce the route filtering that is described in the device’s MUD file with respect to communication with lateral devices. Further shows that the policies that are configured on the MUD PEP router/switch with respect to communication with lateral devices will be enforced as expected, with communications that are configured as denied being blocked, and communications that are configured as permitted being allowed. |
Associated Test Case(s) |
IoT-1-v4 (for the v6 version of this test, IoT-1-v6) |
Associated Cybersecurity Framework Subcategory(ies) |
ID.AM-3, PR.DS-5, PR.AC-5, PR.IP-1, PR.PT-3, PR.IP-3, PR.DS-3 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
ciscopi2.json |
Preconditions |
Test IoT-1-v4 (or IoT-1-v6) has run successfully, meaning that the MUD PEP router/switch has been configured to enforce the following policies for the IoT device in question with respect to local communications (as defined in the MUD files in Section 2.1.3):
|
Procedure |
Note: Procedure steps with strike-through were not tested in this phase because ingress DACLs are not supported in this implementation.
|
Expected Results |
Each of the results that is listed as needing to be verified in the procedure steps above occurs as expected. |
Actual Results |
The numbering in this section correlates with the procedure steps above:
|
Overall Results |
Pass (for testable procedures—as stated, ingress cannot be tested) |
As explained above, test IoT-6-v6 is identical to test IoT-6-v4 except that it uses IPv6, DHCPv6, and IANA code 112 instead of using IPv4, DHCPv4, and IANA code 161.
2.1.2.7 Test Case IoT-7-v4¶
Table 2‑8: Test Case IoT-7-v4
Test Case Field |
Description |
|---|---|
Parent Requirement |
(CR-11) If the IoT DDoS example implementation is such that its DHCP server does not act as a MUD manager and it forwards a MUD URL to a MUD manager, the DHCP server must notify the MUD manager of any corresponding change to the DHCP state of the MUD-enabled IoT device, and the MUD manager should remove the implemented policy configuration in the router/switch pertaining to that MUD-enabled IoT device. |
Testable Requirement |
(CR-11.a) The MUD-enabled IoT device shall explicitly release the IP address lease (i.e., it sends a DHCP release message to the DHCP server). (CR-11.a.1) The DHCP server shall notify the MUD manager that the device’s IP address lease has been released. (CR-11.a.2) The MUD manager should remove all policies associated with the disconnected IoT device that had been configured on the MUD PEP router/switch. |
Description |
Shows that when a MUD-enabled IoT device explicitly releases its IP address lease, the MUD-related configuration for that IoT device will be removed from its MUD PEP router/switch |
Associated Test Case(s) |
IoT-1-v4 (or IoT-1-v6 when IPv6 addressing is used) |
Associated Cybersecurity Framework Subcategory(ies) |
PR.IP-3, PR.DS-3 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
ciscopi2.json |
Preconditions |
Test IoT-1-v4 (or IoT-1-v6) has run successfully, meaning that the MUD PEP router/switch has been configured to enforce the policies defined in the MUD file in Section 2.1.3 for the IoT device in question. |
Procedure |
|
Expected Results |
All of the configuration rules listed above have been removed from the MUD PEP router/switch for the IoT device in question. |
Actual Results |
Procedure 1: Build1# sh access-session int g1/0/15 det
Interface: GigabitEthernet1/0/15
IIF-ID: 0x1B6BCEA5
MAC Address: b827.ebeb.6c8b
IPv6 Address: Unknown
IPv4 Address: 192.168.13.17
User-Name: b827ebeb6c8b
Status: Authorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: both
Session timeout: N/A
Common Session ID: C0A80A0200000A6A9828F06
Acct Session ID: 0x0000003b
Handle: 0x2200009c
Current Policy: mud-mab-test
Server Policies:
ACS ACL: mud-81726-v4fr.in
Vlan Group: Vlan: 3
Method status list:
Method State
mab Authc Success
Procedure 2: pi@raspberrypi:~ $ sudo dhclient -v -r
Build1# sh access-session int g1/0/15 det
Interface: GigabitEthernet1/0/15
IIF-ID: 0x1B6BCEA5
MAC Address: b827.ebeb.6c8b
IPv6 Address: Unknown
IPv4 Address: Unknown
User-Name: b827ebeb6c8b
Status: Authorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: both
Session timeout: N/A
Common Session ID: C0A80A0200000A6A9828F06
Acct Session ID: 0x0000003b
Handle: 0x2200009c
Current Policy: mud-mab-test
Server Policies:
ACS ACL: mud-81726-v4fr.in
Vlan Group: Vlan: 3
Method status list:
Method State
mab Authc Success
|
Overall Results |
Failed |
As explained above, test IoT-7-v6 is identical to test IoT-7-v4 except that it uses IPv6, DHCPv6, and IANA code 112 instead of using IPv4, DHCPv4, and IANA code 161.
2.1.2.8 Test Case IoT-8-v4¶
Table 2‑9: Test Case IoT-8-v4
Test Case Field |
Description |
|---|---|
Parent Requirement |
(CR-11) If the IoT DDoS example implementation is such that its DHCP server does not act as a MUD manager and it forwards a MUD URL to a MUD manager, the DHCP server must notify the MUD manager of any corresponding change to the DHCP state of the MUD-enabled IoT device, and the MUD manager should remove the implemented policy configuration in the router/switch pertaining to that MUD-enabled IoT device. |
Testable Requirement |
(CR-11.b) The MUD-enabled IoT device’s IP address lease shall expire. (CR-11.b.1) The DHCP server shall notify the MUD manager that the device’s IP address lease has expired. (CR-11.b.2) The MUD manager should remove all policies associated with the affected IoT device that had been configured on the MUD PEP router/switch. |
Description |
Shows that when a MUD-enabled IoT device’s IP address lease expires, the MUD-related configuration for that IoT device will be removed from its MUD PEP router/switch |
Associated Test Case(s) |
IoT-1-v4 (or IoT-1-v6 when IPv6 addressing is used) |
Associated Cybersecurity Framework Subcategory(ies) |
PR.IP-3, PR.DS-3 |
IoT Device(s) Under Test |
TBD (Not testable in Build 1) |
MUD File(s) Used |
TBD (Not testable in Build 1) |
Preconditions |
Test IoT-1-v4 (or IoT-1-v6) has run successfully, meaning that the MUD PEP router/switch has been configured to enforce the policies defined in the MUD file in Section 2.1.3 for the IoT device in question. |
Procedure |
|
Expected Results |
Once 10 minutes have elapsed after disconnecting the IoT device from the network, all of the configuration rules listed above have been removed from the MUD PEP router/switch for the IoT device in question. |
Actual Results |
TBD (Not testable in Build 1) |
Overall Results |
TBD (Not testable in Build 1) |
As explained above, test IoT-8-v6 is identical to test IoT-8-v4 except that it uses IPv6, DHCPv6, and IANA code 112 instead of using IPv4, DHCPv4, and IANA code 161.
2.1.2.9 Test Case IoT-9-v4¶
Table 2‑10: Test Case IoT-9-v4
Test Case Field |
Description |
|---|---|
Parent Requirements |
(CR-13) The IoT DDoS example implementation shall ensure that for each rule in a MUD file that pertains to an external domain, the MUD PEP router/switch will get configured with all possible instantiations of that rule, insofar as each instantiation contains one of the IP addresses to which the domain in that MUD file rule may be resolved when queried by the MUD PEP router/switch. |
Testable Requirements |
(CR-13.a) The MUD file for a device shall contain a rule involving an external domain that can resolve to multiple IP addresses when queried by the MUD PEP router/switch. An ACL for permitting access to each of those IP addresses will be inserted into the MUD PEP router/switch for the device in question, and the device will be permitted to communicate with all of those IP addresses. |
Description |
Shows that if a domain in a MUD file rule resolves to multiple IP addresses when the address resolution is queried by the network gateway, then
|
Associated Test Case(s) |
N/A |
Associated Cybersecurity Framework Subcategory(ies) |
ID.AM-1, ID.AM-2, ID.AM-3, PR.DS-5, DE.AE-1, PR.AC-4, PR.AC-5, PR.IP-1, PR.IP-3, PR.DS-2 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
dnstest.json |
Preconditions |
|
Procedure |
|
Expected Results |
The MUD PEP router/switch for the IoT device has had its configuration changed, i.e., it has been configured to permit the IoT device to send data to IP addresses x1.x1.x1.x1, y1.y1.y1.y1, and z1.z1.z1.z1. The IoT device is permitted to send data to each of the update servers at these addresses. |
Actual Results |
Procedures 1–2: Completed; excluded for brevity Procedure 3: MUD MANAGER: ***MUDC [INFO][fetch_uri_from_macaddr:2166]--> =============
Returning URI: https://mudfileserver/dnstest.json
***MUDC [INFO][handle_get_aclname:3149]--> Found URI
https://mudfileserver/dnstest.json for MAC address
b827ebcf7b81
***MUDC [INFO][validate_muduri:3009]--> uri:
https://mudfileserver/dnstest.jsonhttps://mudfileserver/dnstest.json
***MUDC [INFO][validate_muduri:3035]--> ip: mudfileserver,
filename: dnstest.json
***MUDC [INFO][handle_get_aclname:3194]--> Got URL from
message <https://mudfileserver/dnstest.json>
***MUDC [INFO][query_policies_by_uri:1873]--> found the record <{ "_id" : {
"$oid" : "5d51d0eb0ff2eb76576ee38b" }, "DACL_Name" :
"ACS:CiscoSecure-Defined-ACL=mud-77797-v4fr.in", "DACL" :
"[\"ip:inacl#10=permit tcp any host 192.168.4.7 range 80 80 syn ack\",
\"ip:inacl#20=permit tcp any host 192.168.4.78 range 80 80 syn ack\",
\"ip:inacl#30=permit tcp any host 192.168.4.77 range 80 80 syn ack\",
\"ip:inacl#40=permit tcp any eq 22 any\", \"ip:inacl#41=permit udp any eq
68 any eq 67\", \"ip:inacl#42=permit udp any any eq 53\",
\"ip:inacl#43=deny ip any any\"]", "URI" :
"https://mudfileserver/dnstest.json" }>
***MUDC [INFO][query_policies_by_uri:1915]--> Response <{
"Cisco-AVPair": ["ACS:CiscoSecure-Defined-ACL=mud-77797-v4fr.in"]
}>
***MUDC [INFO][mudc_construct_head:63]--> status_code: 200, content_len: 70,
extra_headers: Content-Type: application/aclname
***MUDC [INFO][mudc_construct_head:80]--> HTTP header: HTTP/1.1 200 OK
Content-Type: application/aclname
Content-Length: 70
***MUDC [INFO][query_policies_by_uri:1918]--> {
"Cisco-AVPair": ["ACS:CiscoSecure-Defined-ACL=mud-77797-v4fr.in"]
}
***MUDC [INFO][handle_get_aclname:3204]--> Got ACLs from the MUD URL
Switch/PEP: Build1# show access-lists
Extended IP access list mud-77797-v4fr.in
10 permit tcp any host 192.168.4.7 eq www ack syn
20 permit tcp any host 192.168.4.78 eq www ack syn
30 permit tcp any host 192.168.4.77 eq www ack syn
40 permit tcp any eq 22 any
41 permit udp any eq bootpc any eq bootps
42 permit udp any any eq domain
43 deny ip any any
Procedure 4:
|
Overall Results |
Pass |
Test Case IoT-9-v6 is identical to test case IoT-9-v4 except that IoT-9-v6 uses IPv6 addresses rather than IPv4 addresses.
2.1.2.10 Test Case IoT-10-v4¶
Table 2‑11: Test Case IoT-10-v4
Test Case Field |
Description |
|---|---|
Parent Requirements |
(CR-12) The IoT DDoS example implementation shall include a MUD manager that uses a cached MUD file rather than retrieve a new one if the cache-validity time period has not yet elapsed for the MUD file indicated by the MUD URL. The MUD manager should fetch a new MUD file if the cache-validity time period has already elapsed. |
Testable Requirements |
(CR-12.a) The MUD manager shall check if the file associated with the MUD URL is present in its cache and shall determine that it is. (CR-12.a.1) The MUD manager shall check whether the amount of time that has elapsed since the cached file was retrieved is less than or equal to the number of hours in the cache-validity value for this MUD file. If so, the MUD manager shall apply the contents of the cached MUD file. (CR-12.a.2) The MUD manager shall check whether the amount of time that has elapsed since the cached file was retrieved is greater than the number of hours in the cache-validity value for this MUD file. If so, the MUD manager may (but does not have to) fetch a new file by using the MUD URL received. |
Description |
Shows that, upon connection to the network, a MUD-enabled IoT device used in the IoT DDoS example implementation has its MUD PEP router/switch automatically configured to enforce the route filtering that is described in the cached MUD file for that device’s MUD URL, assuming that the amount of time that has elapsed since the cached MUD file was retrieved is less than or equal to the number of hours in the file’s cache-validity value. If the cache validity has expired for the respective file, the MUD manager should fetch a new MUD file from the MUD file server. |
Associated Test Case(s) |
N/A |
Associated Cybersecurity Framework Subcategory(ies) |
ID.AM-1, ID.AM-2, ID.AM-3, PR.DS-5, DE.AE-1, PR.AC-4, PR.AC-5, PR.IP-1, PR.IP-3, PR.DS-2, PR.PT-3 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
Ciscopi2.json |
Preconditions |
|
Procedure |
Verify that the MUD PEP router/switch for the IoT device to be used in the test does not yet have any configuration settings installed with respect to the IoT device being used in the test.
|
Expected Results |
The MUD PEP router/switch for the IoT device has had its configuration changed, i.e., it has been configured to enforce the policies specified in the IoT device’s MUD file. The expected configuration should resemble the following. Cache is valid (the MUD manager does NOT retrieve the MUD file from the MUD file server): Extended IP access list mud-81726-v4fr.in
10 permit tcp any host 192.168.4.7 eq www ack syn
20 permit tcp any host 192.168.10.104 eq www
30 permit tcp any host 192.168.10.105 eq www
50 permit tcp any 192.168.10.0 0.0.0.255 eq www
60 permit tcp any 192.168.13.0 0.0.0.255 eq www
70 permit tcp any 192.168.14.0 0.0.0.255 eq www
80 permit tcp any eq 22 any
81 permit udp any eq bootpc any eq bootps
82 permit udp any any eq domain
83 deny ip any any
Cache is valid (the MUD manager does NOT retrieve the MUD file from the MUD file server): Extended IP access list mud-81726-v4fr.in
10 permit tcp any host 192.168.4.7 eq www ack syn
20 permit tcp any host 192.168.10.104 eq www
30 permit tcp any host 192.168.10.105 eq www
50 permit tcp any 192.168.10.0 0.0.0.255 eq www
60 permit tcp any 192.168.13.0 0.0.0.255 eq www
70 permit tcp any 192.168.14.0 0.0.0.255 eq www
80 permit tcp any eq 22 any
81 permit udp any eq bootpc any eq bootps
82 permit udp any any eq domain
83 deny ip any any
Cache is not valid (the MUD manager does retrieve the MUD file from the MUD file server): Extended IP access list mud-81726-v4fr.in
10 permit tcp any host 192.168.4.7 eq www ack syn
20 permit tcp any host 192.168.10.104 eq www
30 permit tcp any host 192.168.10.105 eq www
50 permit tcp any 192.168.10.0 0.0.0.255 eq www
60 permit tcp any 192.168.13.0 0.0.0.255 eq www
70 permit tcp any 192.168.14.0 0.0.0.255 eq www
80 permit tcp any eq 22 any
81 permit udp any eq bootpc any eq bootps
82 permit udp any any eq domain
83 deny ip any any
All protocol exchanges described in steps 1–9 above are expected to occur and can be viewed via Wireshark if desired. If the router/switch does not get configured in accordance with the MUD file, each exchange of DHCP and MUD-related protocol traffic should be viewed on the network via Wireshark to determine which transactions did not proceed as expected, and the observed and absent protocol exchanges should be described here. |
Actual Results |
MUD manager logs for valid cache: **MUDC [INFO][mudc_print_request_info:2185]--> print parsed HTTP request
header info
***MUDC [INFO][mudc_print_request_info:2186]--> request method: POST
***MUDC [INFO][mudc_print_request_info:2187]--> request uri: /getaclname
***MUDC [INFO][mudc_print_request_info:2188]--> local uri: /getaclname
***MUDC [INFO][mudc_print_request_info:2189]--> http version: 1.1
***MUDC [INFO][mudc_print_request_info:2190]--> query string: (null)
***MUDC [INFO][mudc_print_request_info:2191]--> content_length: 27
***MUDC [INFO][mudc_print_request_info:2192]--> remote ip addr: 0xe7719c38
***MUDC [INFO][mudc_print_request_info:2193]--> remote port: 49344
***MUDC [INFO][mudc_print_request_info:2194]--> remote_user: (null)
***MUDC [INFO][mudc_print_request_info:2195]--> is ssl: 0
***MUDC [INFO][mudc_print_request_info:2199]--> header(0): name: <Host>,
value: <127.0.0.1:8000>
***MUDC [INFO][mudc_print_request_info:2199]--> header(1): name:
<User-Agent>, value: <FreeRADIUS 3.0.17>
***MUDC [INFO][mudc_print_request_info:2199]--> header(2): name: <Accept>,
value: <*/*>
***MUDC [INFO][mudc_print_request_info:2199]--> header(3): name:
<Content-Type>, value: <application/json>
***MUDC [INFO][mudc_print_request_info:2199]--> header(4): name:
<X-FreeRADIUS-Section>, value: <authorize>
***MUDC [INFO][mudc_print_request_info:2199]--> header(5): name:
<X-FreeRADIUS-Server>, value: <default>
***MUDC [INFO][mudc_print_request_info:2199]--> header(6): name:
<Content-Length>, value: <27>
***MUDC [INFO][handle_get_aclname:2506]--> Mac address <b827ebeb6c8b>
***MUDC [INFO][fetch_uri_from_macaddr:1702]--> found the fields <{ "_id" : {
"$oid" : "5c182c7edb40218cde918776" }, "URI" :
"https://mudfileserver/ciscopi2" }>
***MUDC [INFO][fetch_uri_from_macaddr:1711]--> =============
Returning URI: https://mudfileserver/ciscopi2
***MUDC [INFO][handle_get_aclname:2513]--> Found URI
https://mudfileserver/ciscopi2 for MAC address b827ebeb6c8b
***MUDC [INFO][validate_muduri:2373]--> uri:
https://mudfileserver/ciscopi2
***MUDC [INFO][validate_muduri:2399]--> ip: mudfileserver,
filename: ciscopi2
***MUDC [INFO][handle_get_aclname:2558]--> Got URL from message
<https://mudfileserver/ciscopi2>
***MUDC [INFO][query_policies_by_uri:1419]--> found the record <{ "_id" : {
"$oid" : "5c182d9cdb40218cde91884a" }, "DACL_Name" :
"ACS:CiscoSecure-Defined-ACL=mud-81726-v4fr.in", "DACL" :
"[\"ip:inacl#10=permit tcp any host 192.168.4.7 range 80 80 syn ack\",
\"ip:inacl#20=permit tcp any host 192.168.10.104 range 80 80\",
\"ip:inacl#30=permit tcp any host 192.168.10.105 range 80 80\",
\"ip:inacl#40=permit tcp any host 192.168.10.104 range 80 80\",
\"ip:inacl#50=permit tcp any 192.168.10.0 0.0.0.255 range 80 80\",
\"ip:inacl#60=permit tcp any 192.168.13.0 0.0.0.255 range 80 80\",
\"ip:inacl#70=permit tcp any 192.168.14.0 0.0.0.255 range 80 80\",
\"ip:inacl#80=permit tcp any eq 22 any\", \\"ip:inacl#81=permit udp any eq
68 any eq 67\", \"ip:inacl#82=permit udp any any eq 53\",
\"ip:inacl#83=deny ip any any\"]", "URI" :
"https://mudfileserver/ciscopi2", "VLAN" : 3 }>
***MUDC [INFO][query_policies_by_uri:1461]--> Response <{
"Cisco-AVPair": ["ACS:CiscoSecure-Defined-ACL=mud-81726-v4fr.in"],
"Tunnel-Type": "VLAN",
"Tunnel-Medium-Type": "IEEE-802",
"Tunnel-Private-Group-Id": 3
}>
***MUDC [INFO][mudc_construct_head:135]--> status_code: 200, content_len:
160, extra_headers: Content-Type: application/aclname
***MUDC [INFO][mudc_construct_head:152]--> HTTP header: HTTP/1.1 200 OK
Content-Type: application/aclname
Content-Length: 160
***MUDC [INFO][query_policies_by_uri:1464]--> {
"Cisco-AVPair": ["ACS:CiscoSecure-Defined-ACL=mud-81726-v4fr.in"],
"Tunnel-Type": "VLAN",
"Tunnel-Medium-Type": "IEEE-802",
"Tunnel-Private-Group-Id": 3
}
***MUDC [INFO][handle_get_aclname:2568]--> Got ACLs from the MUD URL
MUD manager logs for expired cache: ***MUDC [INFO][mudc_print_request_info:2185]--> print parsed HTTP request
header info
***MUDC [INFO][mudc_print_request_info:2186]--> request method: POST
***MUDC [INFO][mudc_print_request_info:2187]--> request uri: /getaclname
***MUDC [INFO][mudc_print_request_info:2188]--> local uri: /getaclname
***MUDC [INFO][mudc_print_request_info:2189]--> http version: 1.1
***MUDC [INFO][mudc_print_request_info:2190]--> query string: (null)
***MUDC [INFO][handle_get_aclname:2506]--> Mac address <b827ebeb6c8b>
***MUDC [INFO][fetch_uri_from_macaddr:1702]--> found the fields <{ "_id" : {
"$oid" : "5c182c7edb40218cde918776" }, "URI" :
"https://mudfileserver/ciscopi2" }>
***MUDC [INFO][fetch_uri_from_macaddr:1711]--> ============= Returning
URI: https://mudfileserver/ciscopi2
***MUDC [INFO][handle_get_aclname:2513]--> Found URI
https://mudfileserver/ciscopi2 for MAC address b827ebeb6c8b
***MUDC [INFO][validate_muduri:2373]--> uri: https://mudfileserver/ciscopi2
***MUDC [INFO][validate_muduri:2399]--> ip: mudfileserver, filename:
ciscopi2
***MUDC [INFO][handle_get_aclname:2558]--> Got URL from message
<https://mudfileserver/ciscopi2>
***MUDC [INFO][query_policies_by_uri:1399]--> Cache has expired
[Omitted for brevity] ***MUDC [STATUS][send_mudfs_request:2005]-->
Request URI <https://mudfileserver/ciscopi2>
</home/mudtester/mud-intermediate.pem>
* Trying 192.168.4.5...
* TCP_NODELAY set
* Connected to mudfileserver (192.168.4.5) port 443 (#0)
* found 1 certificate in /home/mudtester/mud-intermediate.pem
* found 400 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: mudfileserver (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: C=US,ST=Maryland,L=Rockville,O=National Cybersecurity Center
of Excellence - NIST,CN=mudfileserver
* start date: Fri, 05 Oct 2018 00:00:00 GMT
* expire date: Wed, 13 Oct 2021 12:00:00 GMT
* issuer: C=US,O=DigiCert Inc,CN=DigiCert Test SHA2 Intermediate CA-1
* compression: NULL
* ALPN, server did not agree to a protocol
> GET /ciscopi2 HTTP/1.1
Host: mudfileserver
Accept: */*
[Omitted for brevity] |
Overall Results |
Pass |
Test case IoT-10-v6 is identical to test case IoT-10-v4 except that IoT-10-v6 tests requirement CR-1.a.2, whereas IoT-10-v4 tests requirement CR-1.a.1. Hence, as explained above, test IoT-10-v6 uses IPv6, DHCPv6, and IANA code 112 instead of using IPv4, DHCPv4, and IANA code 161.
2.1.2.11 Test Case IoT-11-v4¶
Table 2‑12: Test Case IoT-11-v4
Test Case Field |
Description |
|---|---|
Parent Requirements |
(CR-1) The IoT DDoS example implementation shall include a mechanism for associating a device with a MUD file URL (e.g., by having the MUD-enabled IoT device emit a MUD file URL via DHCP, Link Layer Discovery Protocol [LLDP], or X.509 or by using some other mechanism to enable the network to associate a device with a MUD file URL). |
Testable Requirements |
(CR-1.a) Upon initialization, the MUD-enabled IoT device shall broadcast a DHCP message on the network, including at most one MUD URL, in https scheme, within the DHCP transaction. (CR-1.a.1) The DHCP server shall be able to receive DHCPv4 DISCOVER and REQUEST with IANA code 161 (OPTION_MUD_URL_V4) from the MUD-enabled IoT device. OR (CR-1.b) Upon initialization, the MUD-enabled IoT device shall emit the MUD URL as an LLDP extension. (CR-1.b.1) The network service shall be able to process the MUD URL that is received as an LLDP extension. |
Description |
Shows that the IoT DDoS example implementation includes IoT devices that can emit a MUD URL via DHCP or LLDP |
Associated Test Case(s) |
N/A |
Associated Cybersecurity Framework Subcategory(ies) |
ID.AM-1 |
IoT Device(s) Under Test |
Raspberry Pi, Molex light engine, u-blox C027-G35 |
MUD File(s) Used |
Ciscopi2.json, molex.json, ublox.json |
Preconditions |
Device has been developed to emit a MUD URL in a DHCP transaction |
Procedure |
|
Expected Results |
DHCP transaction with MUD option 161 or LLDP TLV MUD extension enabled and MUD URL included |
Actual Results |
Raspberry Pi (using DHCPv4):
u-blox C027-G35 (using DHCPv4):
Molex light engine (using LLDP):
|
Overall Results |
Pass |
2.1.3 MUD Files¶
This section contains the MUD files that were used in the Build 1 functional demonstration.
2.1.3.1 Ciscopi2.json¶
The complete Ciscopi2.json MUD file has been linked to this document. To access this MUD file please click the link below.
2.1.3.2 expiredcerttest.json¶
The complete expiredcerttest.json MUD file has been linked to this document. To access this MUD file please click the link below.
2.1.3.3 molex.json¶
The complete molex.json MUD file has been linked to this document. To access this MUD file please click the link below.
2.1.3.4 ublox.json¶
The complete ublox.json MUD file has been linked to this document. To access this MUD file please click the link below.
2.1.3.5 dnstest.json¶
The complete dnstest.json MUD file has been linked to this document. To access this MUD file please click the link below.
2.2 Demonstration of Non-MUD-Related Capabilities¶
In addition to supporting MUD, Build 1 supports capabilities with respect to device discovery, attribute identification, and monitoring. Table 2‑13 lists the non-MUD-related capabilities that were demonstrated for Build 1. We use the letter “C” as a prefix for these functional capability identifiers in the table below because these capabilities are specific to Build 1, which uses Cisco equipment.
2.2.2 Exercises to Demonstrate the Above Non-MUD-Related Capabilities¶
This section contains the exercises that were performed to verify that Build 1 supports the non-MUD-related capabilities listed in Table 2‑13.
2.2.2.1 Exercise CnMUD-13-v4¶
Table 2‑14: Exercise CnMUD-13-v4
Test Case Field |
Description |
|---|---|
Parent Requirements |
(C-1) The IoT DDoS example implementation shall include a visibility component that can detect, identify, categorize, and monitor the status of IoT devices that are on the network. |
Testable Requirements |
(C-1.a) The visibility component shall detect and identify the attributes and category of a newly connected IoT device. (C-1.a.1) The visibility component shall monitor the status of the IoT device (e.g., notice if the device goes offline). |
Description |
Shows that the IoT DDoS example implementation includes a visibility component that can perform the following actions. Upon connection of a live IoT device to the network, the device will be detected; identified in terms of attributes such as its IP address, operating system (OS), and device type; and continuously monitored as long as it remains live on the network. If the device becomes disconnected or turns off, this change of status will also be detected. |
Associated Test Case(s) |
N/A |
Associated Cybersecurity Framework Subcategory(ies) |
ID.AM-1, ID.AM-2, ID.AM-3, DE.AE-1, DE.CM-1 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
Not applicable for this test |
Preconditions |
The visibility component is up and running and attached to the network. |
Procedure |
|
Expected Results |
All expectations as enumerated in items 2, 4, 6, and 8 above are observed. |
Actual Results |
At Power-On: pi@raspberrypi:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.10.101 netmask 255.255.255.0 broadcast 192.168.10.255
ether b8:27:eb:eb:6c:8b txqueuelen 1000 (Ethernet)
RX packets 9193 bytes 8208593 (7.8 MiB)
RX errors 0 dropped 5 overruns 0 frame 0
TX packets 7210 bytes 822414 (803.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 16 bytes 1467 (1.4 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 16 bytes 1467 (1.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Screenshot from Forescout: IoT device status is indicated by green or gray light shown in the screen capture
Categorizing IoT Device: We tested this function with a connected light bulb. See the example screenshots below.
|
Overall Results |
Pass |
Test case CnMUD-13-v6 is identical to test case CnMUD-13-v4 except that test case CnMUD-13-v6 uses IPv6 and DHCPv6 instead of using IPv4 and DHCPv4.
3 Build 2¶
Build 2 uses equipment from MasterPeace Solutions Ltd., GCA, and ThreatSTOP. The MasterPeace Solutions Yikes! router, cloud service, and mobile application are used to support MUD as well as to perform device discovery on the network and to apply additional traffic rules to both MUD-capable and non-MUD-capable devices based on device manufacturer and model. The GCA Quad9 DNS Service and the ThreatSTOP Threat MUD File Server are used to support threat signaling.
3.1 Evaluation of MUD-Related Capabilities¶
The functional evaluation that was conducted to verify that Build 2 conforms to the MUD specification was based on the Build 2-specific requirements listed in Table 3‑1.
3.1.1 Requirements¶
Table 3‑1: MUD Use Case Functional Requirements
Capability Requirement (CR-ID) |
Parent Requirement |
Subrequirement 1 |
Subrequirement 2 |
Test Case |
|---|---|---|---|---|
CR-1 |
The IoT DDoS example implementation shall include a mechanism for associating a device with a MUD file URL (e.g., by having the MUD-enabled IoT device emit a MUD file URL via DHCP, LLDP, or X.509 or by using some other mechanism to enable the network to associate a device with a MUD file URL). |
IoT-1-v4,
IoT-1-v6,
IoT-11-v4,
IoT-11-v6
|
||
CR-1.a |
Upon initialization, the MUD-enabled IoT device shall broadcast a DHCP message on the network, including at most one MUD URL, in https scheme, within the DHCP transaction. |
IoT-1-v4,
IoT-1-v6,
IoT-11-v4,
IoT-11-v6
|
||
CR-1.a.1 |
The DHCP server shall be able to receive DHCPv4 DISCOVER and REQUEST with IANA code 161 (OPTION_MUD_ URL_V4) from the MUD-enabled IoT device. |
IoT-1-v4,
IoT-11-v4
|
||
CR-1.a.2 |
The DHCP server shall be able to receive DHCPv6 Solicit and Request with IANA code 112 (OPTION_MUD_ URL_V6) from the MUD-enabled IoT device. |
IoT-1-v6,
IoT-11-v6
|
||
CR-2 |
The IoT DDoS example implementation shall include the capability for the MUD URL to be provided to a MUD manager. |
IoT-1-v4,
IoT-1-v6
|
||
CR-2.a |
The DHCP server shall assign an IP address lease to the MUD-enabled IoT device. |
IoT-1-v4,
IoT-1-v6
|
||
CR-2.a.1 |
The MUD-enabled IoT device shall receive the IP address. |
IoT-1-v4,
IoT-1-v6
|
||
CR-2.b |
The DHCP server shall receive the DHCP message and extract the MUD URL, which is then passed to the MUD manager. |
IoT-1-v4,
IoT-1-v6
|
||
CR-2.b.1 |
The MUD manager shall receive the MUD URL. |
IoT-1-v4,
IoT-1-v6
|
||
CR-3 |
The IoT DDoS example implementation shall include a MUD manager that can request a MUD file and signature from a MUD file server. |
IoT-1-v4,
IoT-1-v6
|
||
CR-3.a |
The MUD manager shall use the GET method (RFC 7231) to request MUD and signature files (per RFC 7230) from the MUD file server and can validate the MUD file server’s TLS certificate by using the rules in RFC 2818. |
IoT-1-v4,
IoT-1-v6
|
||
CR-3.a.1 |
The MUD file server shall receive the https request from the MUD manager. |
IoT-1-v4,
IoT-1-v6
|
||
CR-3.b |
The MUD manager shall use the GET method (RFC 7231) to request MUD and signature files (per RFC 7230) from the MUD file server, but it cannot validate the MUD file server’s TLS certificate by using the rules in RFC 2818. |
IoT-2-v4,
IoT-2-v6
|
||
CR-3.b.1 |
The MUD manager shall drop the connection to the MUD file server. |
IoT-2-v4,
IoT-2-v6
|
||
CR-3.b.2 |
The MUD manager shall send locally defined policy to the router or switch that handles whether to allow or block traffic to and from the MUD-enabled IoT device. |
IoT-2-v4,
IoT-2-v6
|
||
CR-4 |
The IoT DDoS example implementation shall include a MUD file server that can serve a MUD file and signature to the MUD manager. |
IoT-1-v4,
IoT-1-v6
|
||
CR-4.a |
The MUD file server shall serve the file and signature to the MUD manager, and the MUD manager shall check to determine whether the certificate used to sign the MUD file (signed using DER-encoded CMS [RFC 5652]) was valid at the time of signing, i.e., the certificate had not expired. |
IoT-1-v4,
IoT-1-v6
|
||
CR-4.b |
The MUD file server shall serve the file and signature to the MUD manager, and the MUD manager shall check to determine whether the certificate used to sign the MUD file was valid at the time of signing, i.e., the certificate had already expired when it was used to sign the MUD file. |
IoT-3-v4,
IoT-3-v6
|
||
CR-4.b.1 |
The MUD manager shall cease to process the MUD file. |
IoT-3-v4,
IoT-3-v6
|
||
CR-4.b.2 |
The MUD manager shall send locally defined policy to the router or switch that handles whether to allow or block traffic to and from the MUD-enabled IoT device. |
IoT-3-v4,
IoT-3-v6
|
||
CR-5 |
The IoT DDoS example implementation shall include a MUD manager that can translate local network configurations based on the MUD file. |
IoT-1-v4,
IoT-1-v6
|
||
CR-5.a |
The MUD manager shall successfully validate the signature of the MUD file. |
IoT-1-v4,
IoT-1-v6
|
||
CR-5.a.1 |
The MUD manager, after validation of the MUD file signature, shall check for an existing MUD file and translate abstractions in the MUD file to router or switch configurations. |
IoT-1-v4,
IoT-1-v6
|
||
CR-5.a.2 |
The MUD manager shall cache this newly received MUD file. |
IoT-10-v4,
IoT-10-v6
|
||
CR-5.b |
The MUD manager shall attempt to validate the signature of the MUD file, but the signature validation fails (even though the certificate that had been used to create the signature had not been expired at the time of signing, i.e., the signature is invalid for a different reason). |
IoT-4-v4,
IoT-4-v6
|
||
CR-5.b.1 |
The MUD manager shall cease processing the MUD file. |
IoT-4-v4,
IoT-4-v6
|
||
CR-5.b.2 |
The MUD manager shall send locally defined policy to the router or switch that handles whether to allow or block traffic to and from the MUD-enabled IoT device. |
IoT-4-v4,
IoT-4-v6
|
||
CR-6 |
The IoT DDoS example implementation shall include a MUD manager that can configure the MUD PEP, i.e., the router or switch nearest the MUD-enabled IoT device that emitted the URL. |
IoT-1-v4,
IoT-1-v6
|
||
CR-6.a |
The MUD manager shall install a router configuration on the router or switch nearest the MUD-enabled IoT device that emitted the URL. |
IoT-1-v4,
IoT-1-v6
|
||
CR-6.a.1 |
The router or switch shall have been configured to enforce the route filter sent by the MUD manager. |
IoT-1-v4,
IoT-1-v6
|
||
CR-7 |
The IoT DDoS example implementation shall allow the MUD-enabled IoT device to communicate with approved internet services in the MUD file. |
IoT-5-v4,
IoT-5-v6
|
||
CR-7.a |
The MUD-enabled IoT device shall attempt to initiate outbound traffic to approved internet services. |
IoT-5-v4,
IoT-5-v6
|
||
CR-7.a.1 |
The router or switch shall receive the attempt and shall allow it to pass based on the filters from the MUD file. |
IoT-5-v4,
IoT-5-v6
|
||
CR-7.b |
An approved internet service shall attempt to initiate a connection to the MUD-enabled IoT device. |
IoT-5-v4,
IoT-5-v6
|
||
CR-7.b.1 |
The router or switch shall receive the attempt and shall allow it to pass based on the filters from the MUD file. |
IoT-5-v4,
IoT-5-v6
|
||
CR-8 |
The IoT DDoS example implementation shall deny communications from a MUD-enabled IoT device to unapproved internet services (i.e., services that are denied by virtue of not being explicitly approved). |
IoT-5-v4,
IoT-5-v6
|
||
CR-8.a |
The MUD-enabled IoT device shall attempt to initiate outbound traffic to unapproved (implicitly denied) internet services. |
IoT-5-v4,
IoT-5-v6
|
||
CR-8.a.1 |
The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. |
IoT-5-v4,
IoT-5-v6
|
||
CR-8.b |
An unapproved (implicitly denied) internet service shall attempt to initiate a connection to the MUD-enabled IoT device. |
IoT-5-v4,
IoT-5-v6
|
||
CR-8.b.1 |
The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. |
IoT-5-v4,
IoT-5-v6
|
||
CR-8.c |
The MUD-enabled IoT device shall initiate communications to an internet service that is approved to initiate communications with the MUD-enabled device but not approved to receive communications initiated by the MUD-enabled device. |
IoT-5-v4,
IoT-5-v6
|
||
CR-8.c.1 |
The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. |
IoT-5-v4,
IoT-5-v6
|
||
CR-8.d |
An internet service shall initiate communications to a MUD-enabled device that is approved to initiate communications with the internet service but that is not approved to receive communications initiated by the internet service. |
IoT-5-v4,
IoT-5-v6
|
||
CR-8.d.1 |
The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. |
IoT-5-v4,
IoT-5-v6
|
||
CR-9 |
The IoT DDoS example implementation shall allow the MUD-enabled IoT device to communicate laterally with devices that are approved in the MUD file. |
IoT-6-v4,
IoT-6-v6
|
||
CR-9.a |
The MUD-enabled IoT device shall attempt to initiate lateral traffic to approved devices. |
IoT-6-v4,
IoT-6-v6
|
||
CR-9.a.1 |
The router or switch shall receive the attempt and shall allow it to pass based on the filters from the MUD file. |
IoT-6-v4,
IoT-6-v6
|
||
CR-9.b |
An approved device shall attempt to initiate a lateral connection to the MUD-enabled IoT device. |
IoT-6-v4,
IoT-6-v6
|
||
CR-9.b.1 |
The router or switch shall receive the attempt and shall allow it to pass based on the filters from the MUD file. |
IoT-6-v4,
IoT-6-v6
|
||
CR-10 |
The IoT DDoS example implementation shall deny lateral communications from a MUD-enabled IoT device to devices that are not approved in the MUD file (i.e., devices that are implicitly denied by virtue of not being explicitly approved). |
IoT-6-v4,
IoT-6-v6
|
||
CR-10.a |
The MUD-enabled IoT device shall attempt to initiate lateral traffic to unapproved (implicitly denied) devices. |
IoT-6-v4,
IoT-6-v6
|
||
CR-10.a.1 |
The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. |
IoT-6-v4,
IoT-6-v6
|
||
CR-10.b |
An unapproved (implicitly denied) device shall attempt to initiate a lateral connection to the MUD-enabled IoT device. |
IoT-6-v4,
IoT-6-v6
|
||
CR-10.b.1 |
The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. |
IoT-6-v4,
IoT-6-v6
|
||
CR-11 |
If the IoT DDoS example implementation is such that its DHCP server does not act as a MUD manager and it forwards a MUD URL to a MUD manager, the DHCP server must notify the MUD manager of any corresponding change to the DHCP state of the MUD-enabled IoT device, and the MUD manager should remove the implemented policy configuration in the router/switch pertaining to that MUD-enabled IoT device. |
IoT-7-v4,
IoT-7-v6
|
||
CR-11.a |
The MUD-enabled IoT device shall explicitly release the IP address lease (i.e., it sends a DHCP release message to the DHCP server). |
IoT-7-v4,
IoT-7-v6
|
||
CR-11.a.1 |
The DHCP server shall notify the MUD manager that the device’s IP address lease has been released. |
IoT-7-v4,
IoT-7-v6
|
||
CR-11.a.2 |
The MUD manager should remove all policies associated with the disconnected IoT device that had been configured on the MUD PEP router/switch. |
IoT-7-v4,
IoT-7-v6
|
||
CR-11.b |
The MUD-enabled IoT device’s IP address lease shall expire. |
IoT-8-v4,
IoT-8-v6
|
||
CR-11.b.1 |
The DHCP server shall notify the MUD manager that the device’s IP address lease has expired. |
IoT-8-v4,
IoT-8-v6
|
||
CR-11.b.2 |
The MUD manager should remove all policies associated with the affected IoT device that had been configured on the MUD PEP router/switch. |
IoT-8-v4,
IoT-8-v6
|
||
CR-12 |
The IoT DDoS example implementation shall include a MUD manager that uses a cached MUD file rather than retrieve a new one if the cache-validity time period has not yet elapsed for the MUD file indicated by the MUD URL. The MUD manager should fetch a new MUD file if the cache-validity time period has already elapsed. |
IoT-10-v4,
IoT-10-v6
|
||
CR-12.a |
The MUD manager shall check if the file associated with the MUD URL is present in its cache and shall determine that it is. |
IoT-10-v4,
IoT-10-v6
|
||
CR-12.a.1 |
The MUD manager shall check whether the amount of time that has elapsed since the cached file was retrieved is less than or equal to the number of hours in the cache-validity value for this MUD file. If so, the MUD manager shall apply the contents of the cached MUD file. |
IoT-10-v4,
IoT-10-v6
|
||
CR-12.a.2 |
The MUD manager shall check whether the amount of time that has elapsed since the cached file was retrieved is greater than the number of hours in the cache-validity value for this MUD file. If so, the MUD manager may (but does not have to) fetch a new file by using the MUD URL received. |
IoT-10-v4,
IoT-10-v6
|
||
CR-13 |
The IoT DDoS example implementation shall ensure that for each rule in a MUD file that pertains to an external domain, the MUD PEP router/switch will get configured with all possible instantiations of that rule, insofar as each instantiation contains one of the IP addresses to which the domain in that MUD file rule may be resolved when queried by the MUD PEP router/switch. |
IoT-9-v4,
IoT-9-v6
|
||
CR-13.a |
The MUD file for a device shall contain a rule involving a domain that can resolve to multiple IP addresses when queried by the MUD PEP router/switch. An ACL for permitting access to each of those IP addresses will be inserted into the MUD PEP router/switch for the device in question, and the device will be permitted to communicate with all of those IP addresses. |
IoT-9-v4,
IoT-9-v6
|
||
CR-13.a.1 |
IPv4 addressing is used on the network. |
IoT-9-v4
|
||
CR-13.a.2 |
IPv6 addressing is used on the network. |
IoT-9-v6
|
3.1.2 Test Cases¶
3.1.2.1 Test Case IoT-1-v4¶
This section contains the test cases that were used to verify that Build 2 met the requirements listed in Table 3‑1.
Table 3‑2: Test Case IoT-1-v4
Test Case Field |
Description |
|---|---|
Parent Requirements |
(CR-1) The IoT DDoS example implementation shall include a mechanism for associating a device with a MUD file URL (e.g., by having the MUD-enabled IoT device emit a MUD file URL via DHCP, LLDP, or X.509 or by using some other mechanism to enable the network to associate a device with a MUD file URL). (CR-2) The IoT DDoS example implementation shall include the capability for the MUD URL to be provided to a MUD manager. (CR-3) The IoT DDoS example implementation shall include a MUD manager that can request a MUD file and signature from a MUD file server. (CR-4) The IoT DDoS example implementation shall include a MUD file server that can serve a MUD file and signature to the MUD manager. (CR-5) The IoT DDoS example implementation shall include a MUD manager that can translate local network configurations based on the MUD file. (CR-6) The IoT DDoS example implementation shall include a MUD manager that can configure the router or switch nearest the MUD-enabled IoT device that emitted the URL. |
Testable Requirements |
(CR-1.a) Upon initialization, the MUD-enabled IoT device shall broadcast a DHCP message on the network, including at most one MUD URL, in https scheme, within the DHCP transaction. (CR-1.a.1) The DHCP server shall be able to receive DHCPv4 DISCOVER and/or REQUEST with IANA code 161 (OPTION_MUD_URL_V4) from the MUD-enabled IoT device. (Note: Test IoT-1-v6 does not test this requirement; instead, it tests CR-1.a.2, which pertains to DHCPv6 rather than DHCPv4.) (CR-2.a) The DHCP server shall assign an IP address lease to the MUD-enabled IoT device. (CR-2.a.1) The MUD-enabled IoT device shall receive the IP address. (CR-2.b) The DHCP server shall receive the DHCP message and extract the MUD URL, which is then passed to the MUD manager. (CR-2.b.1) The MUD manager shall receive the MUD URL. (CR-3.a) The MUD manager shall use the GET method (RFC 7231) to request MUD and signature files (per RFC 7230) from the MUD file server and can validate the MUD file server’s TLS certificate by using the rules in RFC 2818. (CR-3.a.1) The MUD file server shall receive the https request from the MUD manager. (CR-4.a) The MUD file server shall serve the file and signature to the MUD manager, and the MUD manager shall check to determine whether the certificate used to sign the MUD file (signed using DER-encoded CMS [RFC 5652]) was valid at the time of signing, i.e., the certificate had not expired. (CR-5.a) The MUD manager shall successfully validate the signature of the MUD file. (CR-5.a.1) The MUD manager, after validation of the MUD file signature, shall check for an existing MUD file and translate abstractions in the MUD file to router or switch configurations. (CR-6.a) The MUD manager shall install a router configuration on the router or switch nearest the MUD-enabled IoT device that emitted the URL. (CR-6.a.1) The router or switch shall have been configured to enforce the route filter sent by the MUD manager. |
Description |
Shows that, upon connection to the network, a MUD-enabled IoT device used in the IoT DDoS example implementation has its MUD PEP router/switch automatically configured to enforce the route filtering that is described in the device’s MUD file, assuming the MUD file has a valid signature and is served from a MUD file server that has a valid TLS certificate |
Associated Test Case(s) |
N/A |
Associated Cybersecurity Framework Subcategory(ies) |
ID.AM-1, ID.AM-2, ID.AM-3, PR.DS-5, DE.AE-1, PR.AC-4, PR.AC-5, PR.IP-1, PR.IP-3, PR.PT-3, PR.DS-2 |
IoT Device(s) Under Test |
Raspberry Pi (1) |
MUD File(s) Used |
Yikesmain.json |
Preconditions |
|
Procedure |
Verify that the MUD PEP router/switch for the IoT device to be used in the test does not yet have any configuration settings installed with respect to the IoT device being used in the test. Also verify that the MUD file of the IoT device to be used is not currently cached at the MUD manager. Power on the IoT device and connect it to the test network. This should set in motion the following series of steps, which should occur automatically:
|
Expected Results |
The MUD PEP router/switch for the IoT device has had its configuration changed, i.e., it has been configured to enforce the policies specified in the IoT device’s MUD file. The expected configuration should resemble the following: config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl0-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
option dest_ip 198.71.233.87
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl0-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 198.71.233.87
option dest_ip 192.168.20.222
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl1-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
option dest_ip 192.168.4.7
option dest_port 80:80
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl1-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 192.168.4.7
option dest_ip 192.168.20.222
option dest_port 80:80
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl2-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
option dest_ip 99.84.216.69
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl2-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
option dest_ip 99.84.216.65
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl2-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
option dest_ip 99.84.216.79
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl2-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
option dest_ip 99.84.216.27
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl2-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 99.84.216.27
option dest_ip 192.168.20.222
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl2-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 99.84.216.79
option dest_ip 192.168.20.222
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl2-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 99.84.216.65
option dest_ip 192.168.20.222
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl2-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 99.84.216.69
option dest_ip 192.168.20.222
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_ent0-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
option dest_ip 172.217.164.132
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_ent0-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
option dest_ip 0.0.0.0
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_ent0-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 172.217.164.132
option dest_ip 192.168.20.222
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_ent0-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 0.0.0.0
option dest_ip 192.168.20.222
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_loc0-frdev'
option target ACCEPT
option src lan
option dest lan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_loc0-todev'
option target ACCEPT
option src lan
option dest lan
option proto tcp
option family ipv4
option src_ip any
option dest_ip 192.168.20.222
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_man0-frdev-SM'
option target ACCEPT
option src lan
option dest lan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
option ipset www_gmail_com-SMTD
option dest_port 80:80
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_man0-todev-SM'
option target ACCEPT
option src lan
option dest lan
option proto tcp
option family ipv4
option ipset www_gmail_com-SMFD
option dest_ip 192.168.20.222
option dest_port 80:80
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_myctl0-frdev'
option target ACCEPT
option src lan
option dest wan
option proto all
option family ipv4
option src_ip 192.168.20.222
option dest_ip 192.168.20.101
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_myctl0-todev'
option target ACCEPT
option src wan
option dest lan
option proto all
option family ipv4
option src_ip 192.168.20.101
option dest_ip 192.168.20.222
config rule
option enabled '1'
option name
'mud_192.168.20.222_main-pi-Build2_myman0-frdev-SM'
option target ACCEPT
option src lan
option dest lan
option proto udp
option family ipv4
option src_ip 192.168.20.222
option ipset mudfiles_nist_getyikes_com-SMTD
config rule
option enabled '1'
option name
'mud_192.168.20.222_main-pi-Build2_myman0-todev-SM'
option target ACCEPT
option src lan
option dest lan
option proto udp
option family ipv4
option ipset mudfiles_nist_getyikes_com-SMFD
option dest_ip 192.168.20.222
config rule
option enabled '1'
option name
'mud_192.168.20.222_main-pi-Build2_REJECT-ALL-LOCAL-FROM'
option target REJECT
option src lan
option dest lan
option proto all
option family ipv4
option src_ip 192.168.20.222
config rule
option enabled '1'
option name
'mud_192.168.20.222_main-pi-Build2_REJECT-ALL-LOCAL-TO'
option target REJECT
option src lan
option dest lan
option proto all
option family ipv4
option src_ip any
option dest_ip 192.168.20.222
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_REJECT-ALL'
option target REJECT
option src lan
option dest wan
option proto all
option family ipv4
option src_ip 192.168.20.222
# OSMUD end
All protocol exchanges described in steps 1–7 above are expected to occur and can be viewed via Wireshark if desired. If the router/switch does not get configured in accordance with the MUD file, each exchange of DHCP and MUD-related protocol traffic should be viewed on the network via Wireshark to determine which transactions did not proceed as expected, and the observed and absent protocol exchanges should be described here. |
Actual Results |
Procedures 1–3: pi@main-pi-Build2:~$ sudo dhclient -v -i eth0
sudo: unable to resolve host main-pi-Build2: Connection refused
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
RTNETLINK answers: Operation not possible due to RF-kill
Listening on LPF/wlan0/b8:27:eb:be:39:de
Sending on LPF/wlan0/b8:27:eb:be:39:de
Listening on LPF/eth0/b8:27:eb:eb:6c:8b
Sending on LPF/eth0/b8:27:eb:eb:6c:8b
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
DHCPREQUEST of 192.168.20.222 on eth0 to 255.255.255.255 port 67
DHCPOFFER of 192.168.20.222 from 192.168.20.1
DHCPACK of 192.168.20.222 from 192.168.20.1
Too few arguments.
Too few arguments.
bound to 192.168.20.222 -- renewal in 1800 seconds.
Procedures 4–5: dhcpmasq.txt 2019-07-15T20:27:57Z|OLD|Wired|DHCP|-|MUD|-|-|ba:47:a1:7d:60:44|192.168.20.14
8||
2019-07-15T20:28:01Z|OLD|NIST
5|DHCP|-|MUD|-|-|18:b4:30:50:98:38|192.168.20.203||
2019-07-15T20:28:08Z|OLD|NIST
2.4|DHCP|-|MUD|-|-|d0:73:d5:28:08:2a|192.168.20.202||
2019-07-15T20:28:11Z|OLD|Wired|DHCP|-|MUD|-|-|b8:27:eb:95:55:fe|192.168.20.23
2|raspberrypi|
**2019-07-15T20:28:31Z|NEW|Wired|DHCP|1,28,2,3,15,6,119,12,44,47,26,121,42|MU
D| https://mudfiles.nist.getyikes.com/yikesmain.json|-|b8:27:eb:eb:6c:8b|
192.168.20.222|main-pi-Build2|
2019-07-15T20:28:42Z|NEW|NIST
5|DHCP|1,28,2,121,15,6,12,40,41,42,26,119,3,121,249,33,252,42|MUD|-|-|80:00:0
b:ef:81:70|192.168.20.238||
Procedure 6: MUD MANAGER: 2019-07-15 20:28:32
DEBUG::GENERAL::2019-07-15T20:28:31Z|NEW|Wired|DHCP|1,28,2,3,15,6,119,12,44,4
7,26,121,42|MUD| https://mudfiles.nist.getyikes.com/yikesmain.json|-|b8:2
7:eb:eb:6c:8b|192.168.20.222|main-pi-Build2|
2019-07-15 20:28:32 DEBUG::GENERAL::Executing on dhcpmasq info
2019-07-15 20:28:32 INFO::GENERAL::NEW Device Action: IP: 192.168.20.222,
MAC: b8:27:eb:eb:6c:8b
2019-07-15 20:28:32 DEBUG::COMMUNICATION::curl_easy_perform() doing it
now....
2019-07-15 20:28:32
DEBUG::COMMUNICATION::https://mudfiles.nist.getyikes.com/yikesmain.json
2019-07-15 20:28:32 DEBUG::COMMUNICATION::Found HTTPS
2019-07-15 20:28:32 DEBUG::COMMUNICATION::in write data
2019-07-15 20:28:32 DEBUG::COMMUNICATION::curl_easy_perform() success
2019-07-15 20:28:32 DEBUG::COMMUNICATION::MUD File Server returned success
state.
2019-07-15 20:28:32 DEBUG::COMMUNICATION::curl_easy_perform() doing it
now....
2019-07-15 20:28:32
DEBUG::COMMUNICATION::https://mudfiles.nist.getyikes.com/yikesmain.p7s
2019-07-15 20:28:32 DEBUG::COMMUNICATION::Found HTTPS
2019-07-15 20:28:32 DEBUG::COMMUNICATION::in write data
**2019-07-15 20:28:32 DEBUG::COMMUNICATION::curl_easy_perform() success
2019-07-15 20:28:32 DEBUG::COMMUNICATION::MUD File Server returned success
state.
2019-07-15 20:28:32 DEBUG::MUD_FILE_OPERATIONS::IN ****NEW**** MUD and
SIG FILE RETRIEVED!!!
2019-07-15 20:28:32 DEBUG::GENERAL::IN ****NEW****
validateMudFileWithSig()
2019-07-15 20:28:32 DEBUG::GENERAL::openssl cms -verify -in
/etc/osmud/state/mudfiles/yikesmain.p7s -inform DER -content
/etc/osmud/state/mudfiles/yikesmain.json -purpose any > /dev/null
2019-07-15 20:28:32 DEBUG::GENERAL::IN ****NEW****
executeMudWithDhcpContext()
2019-07-15 20:28:32 DEBUG::GENERAL::/etc/osmud/create_mud_db_entry.sh -d
/etc/osmud/state/mudfiles/mudStateFile.txt -i 192.168.20.222 -m
b8:27:eb:eb:6c:8b -c main-pi-Build2 -u
https://mudfiles.nist.getyikes.com/yikesmain.json -f
/etc/osmud/state/mudfiles/yikesmain.json
2019-07-15 20:28:32 DEBUG::GENERAL::rm -f /tmp/osmud/*
2019-07-15 20:28:32 DEBUG::GENERAL::cp /etc/osmud/state/ipSets/*
/tmp/osmud
2019-07-15 20:28:32 WARNING::DEVICE_INTERFACE::The URL in the MUD file does
not match the URL used to download the MUD FILE
2019-07-15 20:28:32 DEBUG::GENERAL::/etc/osmud/remove_ip_fw_rule.sh -i
192.168.20.222 -m b8:27:eb:eb:6c:8b -d /tmp/osmud
2019-07-15 20:28:32 DEBUG::GENERAL::/etc/osmud/remove_from_ipset.sh -d
/tmp/osmud -i 192.168.20.222
2019-07-15 20:28:32 DEBUG::GENERAL::/etc/osmud/add_to_ipset.sh -d
/tmp/osmud -a mudfiles.nist.getyikes.com -n SM -i 192.168.20.222 -c
main-pi-Build2
2019-07-15 20:28:32 INFO::DEVICE_INTERFACE::Processing ACL-DNS \*from\* ace
rule.
2019-07-15 20:28:32 DEBUG::GENERAL::Starting DNS lookup
2019-07-15 20:28:32 DEBUG::GENERAL::www.osmud.org
2019-07-15 20:28:32 DEBUG::GENERAL::198.71.233.87
2019-07-15 20:28:32 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan
-d wan -i 192.168.20.222 -a any -j 198.71.233.87 -b 443:443 -p tcp -n
cl0-frdev -t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r
192.168.20.222
2019-07-15 20:28:32 INFO::DEVICE_INTERFACE::Processing ACL-DNS \*from\* ace
rule.
2019-07-15 20:28:32 DEBUG::GENERAL::Starting DNS lookup
2019-07-15 20:28:32 DEBUG::GENERAL::us.dlink.com
2019-07-15 20:28:32 DEBUG::GENERAL::192.168.4.7
2019-07-15 20:28:32 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan
-d wan -i 192.168.20.222 -a any -j 192.168.4.7 -b 80:80 -p tcp -n cl1-frdev
-t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r 192.168.20.222
2019-07-15 20:28:32 INFO::DEVICE_INTERFACE::Processing ACL-DNS \*from\* ace
rule.
2019-07-15 20:28:32 DEBUG::GENERAL::Starting DNS lookup
2019-07-15 20:28:32 DEBUG::GENERAL::www.trytechy.com
2019-07-15 20:28:32 DEBUG::GENERAL::99.84.216.69
2019-07-15 20:28:32 DEBUG::GENERAL::99.84.216.65
2019-07-15 20:28:32 DEBUG::GENERAL::99.84.216.79
2019-07-15 20:28:32 DEBUG::GENERAL::99.84.216.27
2019-07-15 20:28:32 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan
-d wan -i 192.168.20.222 -a any -j 99.84.216.69 -b 443:443 -p tcp -n
cl2-frdev -t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r
192.168.20.222
2019-07-15 20:28:32 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan
-d wan -i 192.168.20.222 -a any -j 99.84.216.65 -b 443:443 -p tcp -n
cl2-frdev -t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r
192.168.20.222
2019-07-15 20:28:32 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan
-d wan -i 192.168.20.222 -a any -j 99.84.216.79 -b 443:443 -p tcp -n
cl2-frdev -t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r
192.168.20.222
2019-07-15 20:28:32 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan
-d wan -i 192.168.20.222 -a any -j 99.84.216.27 -b 443:443 -p tcp -n
cl2-frdev -t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r
192.168.20.222
2019-07-15 20:28:32 WARNING::DEVICE_INTERFACE::Processing CONTROLLER
\*from\* ace rule.
2019-07-15 20:28:32 DEBUG::GENERAL::Starting DNS lookup
2019-07-15 20:28:32 DEBUG::GENERAL::www.google.com
2019-07-15 20:28:32 DEBUG::GENERAL::172.217.164.132
2019-07-15 20:28:32 DEBUG::GENERAL::0.0.0.0
2019-07-15 20:28:32 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan
-d wan -i 192.168.20.222 -a any -j 172.217.164.132 -b 443:443 -p tcp -n
ent0-frdev -t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r
192.168.20.222
2019-07-15 20:28:32 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan
-d wan -i 192.168.20.222 -a any -j 0.0.0.0 -b 443:443 -p tcp -n ent0-frdev
-t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r 192.168.20.222
2019-07-15 20:28:32 WARNING::DEVICE_INTERFACE::Processing MY_CONTROLLER
\*from\* ace rule.
2019-07-15 20:28:32 DEBUG::GENERAL::Starting DNS lookup
2019-07-15 20:28:32 DEBUG::GENERAL::yikes.example.com
2019-07-15 20:28:32 DEBUG::GENERAL::192.168.20.101
2019-07-15 20:28:32 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan
-d wan -i 192.168.20.222 -a any -j 192.168.20.101 -b any -p all -n
myctl0-frdev -t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r
192.168.20.222
2019-07-15 20:28:32 INFO::DEVICE_INTERFACE::Processing LOCAL_NETWORK \*to\*
ace rule.
2019-07-15 20:28:32 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan
-d lan -i 192.168.20.222 -a any -j any -b any -p tcp -n loc0-frdev -t
ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r 192.168.20.222
2019-07-15 20:28:32 INFO::DEVICE_INTERFACE::Processing MANUFACTURER
\*from\* ace rule.
2019-07-15 20:28:32 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan
-d lan -i 192.168.20.222 -a any -e www.gmail.com-SMTD -b 80:80 -p tcp -n
man0-frdev-SM -t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r
192.168.20.222
2019-07-15 20:28:32 INFO::DEVICE_INTERFACE::Processing SAME_MANUFACTURER
\*from\* THING ace rule.
2019-07-15 20:28:32 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan
-d lan -i 192.168.20.222 -a any -e mudfiles.nist.getyikes.com-SMTD -b any
-p udp -n myman0-frdev-SM -t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud
-r 192.168.20.222
2019-07-15 20:28:32 INFO::DEVICE_INTERFACE::Successfully installed
fromAccess rule.
2019-07-15 20:28:32 INFO::DEVICE_INTERFACE::Processing DNS-ACL \*to\* ace
rule.
2019-07-15 20:28:32 DEBUG::GENERAL::Starting DNS lookup
2019-07-15 20:28:32 DEBUG::GENERAL::www.osmud.org
2019-07-15 20:28:32 DEBUG::GENERAL::198.71.233.87
2019-07-15 20:28:32 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s wan
-d lan -i 198.71.233.87 -a any -j 192.168.20.222 -b 443:443 -p tcp -n
cl0-todev -t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r
192.168.20.222
2019-07-15 20:28:32 INFO::DEVICE_INTERFACE::Processing DNS-ACL \*to\* ace
rule.
2019-07-15 20:28:32 DEBUG::GENERAL::Starting DNS lookup
2019-07-15 20:28:32 DEBUG::GENERAL::us.dlink.com
2019-07-15 20:28:32 DEBUG::GENERAL::192.168.4.7
2019-07-15 20:28:32 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s wan
-d lan -i 192.168.4.7 -a any -j 192.168.20.222 -b 80:80 -p tcp -n cl1-todev
-t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r 192.168.20.222
2019-07-15 20:28:32 INFO::DEVICE_INTERFACE::Processing DNS-ACL \*to\* ace
rule.
2019-07-15 20:28:32 DEBUG::GENERAL::Starting DNS lookup
2019-07-15 20:28:32 DEBUG::GENERAL::www.trytechy.com
2019-07-15 20:28:33 DEBUG::GENERAL::99.84.216.27
2019-07-15 20:28:33 DEBUG::GENERAL::99.84.216.79
2019-07-15 20:28:33 DEBUG::GENERAL::99.84.216.65
2019-07-15 20:28:33 DEBUG::GENERAL::99.84.216.69
2019-07-15 20:28:33 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s wan
-d lan -i 99.84.216.27 -a any -j 192.168.20.222 -b 443:443 -p tcp -n
cl2-todev -t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r
192.168.20.222
2019-07-15 20:28:33 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s wan
-d lan -i 99.84.216.79 -a any -j 192.168.20.222 -b 443:443 -p tcp -n
cl2-todev -t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r
192.168.20.222
2019-07-15 20:28:33 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s wan
-d lan -i 99.84.216.65 -a any -j 192.168.20.222 -b 443:443 -p tcp -n
cl2-todev -t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r
192.168.20.222
2019-07-15 20:28:33 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s wan
- d lan -i 99.84.216.69 -a any -j 192.168.20.222 -b 443:443 -p tcp -n
c l2-todev -t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r
1 92.168.20.222
2019-07-15 20:28:33 WARNING::DEVICE_INTERFACE::Processing CONTROLLER \*to\*
ac e rule.
2019-07-15 20:28:33 DEBUG::GENERAL::Starting DNS lookup
2019-07-15 20:28:33 DEBUG::GENERAL::www.google.com
2019-07-15 20:28:33 DEBUG::GENERAL::172.217.164.132
2019-07-15 20:28:33 DEBUG::GENERAL::0.0.0.0
2019-07-15 20:28:33 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s wan
-d lan -i 172.217.164.132 -a any -j 192.168.20.222 -b 443:443 -p tcp -n
ent0-todev -t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r
192.168.20.222
2019-07-15 20:28:33 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s wan
-d lan -i 0.0.0.0 -a any -j 192.168.20.222 -b 443:443 -p tcp -n ent0-todev
-t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r 192.168.20.222
2019-07-15 20:28:33 WARNING::DEVICE_INTERFACE::Processing MY_CONTROLLER
\*to\* ace rule.
2019-07-15 20:28:33 DEBUG::GENERAL::Starting DNS lookup
2019-07-15 20:28:33 DEBUG::GENERAL::yikes.example.com
2019-07-15 20:28:33 DEBUG::GENERAL::192.168.20.101
2019-07-15 20:28:33 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s wan
-d lan -i 192.168.20.101 -a any -j 192.168.20.222 -b any -p all -n
myctl0-todev -t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r
192.168.20.222
2019-07-15 20:28:33 INFO::DEVICE_INTERFACE::Processing LOCAL_NETWORK \*to\*
ace rule.
2019-07-15 20:28:33 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan
-d lan -i any -a any -j 192.168.20.222 -b any -p tcp -n loc0-todev -t
ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r 192.168.20.222
2019-07-15 20:28:33 INFO::DEVICE_INTERFACE::Processing (TBD) MANUFACTURER
\*to\* ace rule.
2019-07-15 20:28:33 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan
-d lan -j 192.168.20.222 -a any -e www.gmail.com-SMFD -b 80:80 -p tcp -n
man0-todev-SM -t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r
192.168.20.222
2019-07-15 20:28:33 INFO::DEVICE_INTERFACE::Processing SAME_MANUFACTURER
\*to\* THING ace rule.
2019-07-15 20:28:33 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan
-d lan -j 192.168.20.222 -a any -e mudfiles.nist.getyikes.com-SMFD -b any
-p udp -n myman0-todev-SM -t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud
-r 192.168.20.222
2019-07-15 20:28:33 INFO::DEVICE_INTERFACE::Successfully installed toAccess
rule.
2019-07-15 20:28:33 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan
-d wan -i 192.168.20.222 -a any -j any -b any -p all -n REJECT-ALL -t
REJECT -f all -c main-pi-Build2 -k /tmp/osmud -r 192.168.20.222
2019-07-15 20:28:33 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan
-d lan -i 192.168.20.222 -a any -j any -b any -p all -n
REJECT-ALL-LOCAL-FROM -t REJECT -f all -c main-pi-Build2 -k /tmp/osmud -r
192.168.20.222
2019-07-15 20:28:33 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan
-d lan -i any -a any -j 192.168.20.222 -b any -p all -n REJECT-ALL-LOCAL-TO
-t REJECT -f all -c main-pi-Build2 -k /tmp/osmud -r 192.168.20.222
2019-07-15 20:28:33 DEBUG::GENERAL::/etc/osmud/commit_ip_fw_rules.sh -d
/etc/osmud/state/ipSets -t /tmp/osmud
2019-07-15 20:28:33 DEBUG::GENERAL:: Success returned from for
transaction
Procedure 7: Router/PEP: config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl0-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
option dest_ip 198.71.233.87
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl0-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 198.71.233.87
option dest_ip 192.168.20.222
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl1-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
option dest_ip 192.168.4.7
option dest_port 80:80
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl1-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 192.168.4.7
option dest_ip 192.168.20.222
option dest_port 80:80
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl2-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
option dest_ip 99.84.216.69
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl2-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
option dest_ip 99.84.216.65
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl2-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
option dest_ip 99.84.216.79
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl2-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
option dest_ip 99.84.216.27
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl2-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 99.84.216.27
option dest_ip 192.168.20.222
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl2-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 99.84.216.79
option dest_ip 192.168.20.222
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl2-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 99.84.216.65
option dest_ip 192.168.20.222
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl2-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 99.84.216.69
option dest_ip 192.168.20.222
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_ent0-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
option dest_ip 172.217.164.132
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_ent0-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
option dest_ip 0.0.0.0
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_ent0-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 172.217.164.132
option dest_ip 192.168.20.222
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_ent0-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 0.0.0.0
option dest_ip 192.168.20.222
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_loc0-frdev'
option target ACCEPT
option src lan
option dest lan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_loc0-todev'
option target ACCEPT
option src lan
option dest lan
option proto tcp
option family ipv4
option src_ip any
option dest_ip 192.168.20.222
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_man0-frdev-SM'
option target ACCEPT
option src lan
option dest lan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
option ipset www_gmail_com-SMTD
option dest_port 80:80
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_man0-todev-SM'
option target ACCEPT
option src lan
option dest lan
option proto tcp
option family ipv4
option ipset www_gmail_com-SMFD
option dest_ip 192.168.20.222
option dest_port 80:80
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_myctl0-frdev'
option target ACCEPT
option src lan
option dest wan
option proto all
option family ipv4
option src_ip 192.168.20.222
option dest_ip 192.168.20.101
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_myctl0-todev'
option target ACCEPT
option src wan
option dest lan
option proto all
option family ipv4
option src_ip 192.168.20.101
option dest_ip 192.168.20.222
config rule
option enabled '1'
option name
'mud_192.168.20.222_main-pi-Build2_myman0-frdev-SM'
option target ACCEPT
option src lan
option dest lan
option proto udp
option family ipv4
option src_ip 192.168.20.222
option ipset mudfiles_nist_getyikes_com-SMTD
config rule
option enabled '1'
option name
'mud_192.168.20.222_main-pi-Build2_myman0-todev-SM'
option target ACCEPT
option src lan
option dest lan
option proto udp
option family ipv4
option ipset mudfiles_nist_getyikes_com-SMFD
option dest_ip 192.168.20.222
config rule
option enabled '1'
option name
'mud_192.168.20.222_main-pi-Build2_REJECT-ALL-LOCAL-FROM'
option target REJECT
option src lan
option dest lan
option proto all
option family ipv4
option src_ip 192.168.20.222
config rule
option enabled '1'
option name
'mud_192.168.20.222_main-pi-Build2_REJECT-ALL-LOCAL-TO'
option target REJECT
option src lan
option dest lan
option proto all
option family ipv4
option src_ip any
option dest_ip 192.168.20.222
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_REJECT-ALL'
option target REJECT
option src lan
option dest wan
option proto all
option family ipv4
option src_ip 192.168.20.222
# OSMUD end
|
Overall Results |
Pass |
Test case IoT-1-v6 is identical to test case IoT-1-v4 except that IoT-1-v6 tests requirement CR-1.a.2, whereas IoT-1-v4 tests requirement CR-1.a.1. Hence, as explained above, test IoT-1-v6 uses IPv6, DHCPv6, and IANA code 112 instead of using IPv4, DHCPv4, and IANA code 161.
3.1.2.2 Test Case IoT-2-v4¶
Table 3‑3: Test Case IoT-2-v4
Test Case Field |
Description |
|---|---|
Parent Requirement |
(CR-3) The IoT DDoS example implementation shall include a MUD manager that can request a MUD file and signature from a MUD file server. |
Testable Requirement |
(CR-3.b) The MUD manager shall use the GET method (RFC 7231) to request MUD and signature files (per RFC 7230) from the MUD file server, but it cannot validate the MUD file server’s TLS certificate by using the rules in RFC 2818. (CR-3.b.1) The MUD manager shall drop the connection to the MUD file server. (CR-3.b.2) The MUD manager shall send locally defined policy to the router or switch that handles whether to allow or block traffic to and from the MUD-enabled IoT device. |
Description |
Shows that if a MUD manager cannot validate the TLS certificate of a MUD file server when trying to retrieve the MUD file for a specific IoT device, the MUD manager will drop the connection to the MUD file server and configure the router/switch according to locally defined policy regarding whether to allow or block traffic to the IoT device in question |
Associated Test Case(s) |
IoT-11-v4 (for the v6 version of this test, IoT-11-v6) |
Associated Cybersecurity Framework Subcategory(ies) |
PR.AC-7 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
Yikesmain.json, yikesmantest.json |
Preconditions |
|
Procedure |
Verify that the MUD PEP router/switch for the IoT device to be used in the test does not yet have any configuration settings installed with respect to the IoT device being used in the test. Power on the IoT device and connect it to the test network. This should set in motion the following series of steps, which should occur automatically:
|
Expected Results |
The MUD PEP router/switch for the IoT device has had its configuration changed, i.e., it has been configured to local policy for communication to/from the IoT device. |
Actual Results |
Procedures 1–4: pi@main-pi-Build2:~$ sudo dhclient -v -i eth0
sudo: unable to resolve host main-pi-Build2: Connection refused
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
RTNETLINK answers: Operation not possible due to RF-kill
Listening on LPF/wlan0/b8:27:eb:be:39:de
Sending on LPF/wlan0/b8:27:eb:be:39:de
Listening on LPF/eth0/b8:27:eb:eb:6c:8b
Sending on LPF/eth0/b8:27:eb:eb:6c:8b
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
DHCPREQUEST of 192.168.20.224 on eth0 to 255.255.255.255 port 67
DHCPOFFER of 192.168.20.224 from 192.168.20.1
DHCPACK of 192.168.20.224 from 192.168.20.1
Too few arguments.
Too few arguments.
bound to 192.168.20.224 -- renewal in 1800 seconds\ .
Procedure 5: dhcpmasq.txt 2019-07-15T20:27:57Z|OLD|Wired|DHCP|-|MUD|-|-|ba:47:a1:7d:60:44|192.168.20.14
8||
2019-07-15T20:28:01Z|OLD|NIST
5|DHCP|-|MUD|-|-|18:b4:30:50:98:38|192.168.20.203||
2019-07-15T20:28:08Z|OLD|NIST
2.4|DHCP|-|MUD|-|-|d0:73:d5:28:08:2a|192.168.20.202||
2019-07-15T20:28:11Z|OLD|Wired|DHCP|-|MUD|-|-|b8:27:eb:95:55:fe|192.168.20.23
2|raspberrypi|
2019-07-15T20:28:31Z|NEW|Wired|DHCP|1,28,2,3,15,6,119,12,44,47,26,121,42|MU
D| https://mudfiles.nist.getyikes.com/yikesmain.json|-|b8:27:eb:eb:6c:8b|
192.168.20.224|main-pi-Build2|
2019-07-15T20:28:42Z|NEW|NIST
5|DHCP|1,28,2,121,15,6,12,40,41,42,26,119,3,121,249,33,252,42|MUD|-|-|80:00:0
b:ef:81:70|192.168.20.238||
Procedure 6: MUD Manager: 2019-06-18 13:59:50 INFO::GENERAL::NEW Device Action: IP: 192.168.20.224,
MAC: b8:27:eb:eb:6c:8b
2019-06-18 13:59:50 ERROR::COMMUNICATION::curl_easy_getinfo(curl,
CURLINFO_RESPONSE_CODE -- http-code: 0
2019-06-18 13:59:50 WARNING::COMMUNICATION:: Comm error with a
mud-file-server. Retrying transaction...
2019-06-18 13:59:50 INFO::GENERAL::NEW Device Action: IP: 192.168.20.224,
MAC: b8:27:eb:eb:6c:8b
2019-06-18 13:59:51 ERROR::COMMUNICATION::curl_easy_getinfo(curl,
CURLINFO_RESPONSE_CODE -- http-code: 0
2019-06-18 13:59:51 ERROR::GENERAL::Comm error with mud-file-server. Aborting
transaction after second attempt and quarantine device.
Procedure 7: Router/PEP: # OSMUD start
#
# DO NOT EDIT THESE LINES. OSMUD WILL REPLACE WITH ITS CONFIGURATION
#
config ipset
option enabled 1
option name mudfiles_nist_getyikes_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external mudfiles_nist_getyikes_com-SM
config ipset
option enabled 1
option name mudfiles_nist_getyikes_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external mudfiles_nist_getyikes_com-SM
config ipset
option enabled 1
option name mudfileserver-SMTD
option match dest_ip
option storage hash
option family ipv4
option external mudfileserver-SM
config ipset
option enabled 1
option name mudfileserver-SMFD
option match src_ip
option storage hash
option family ipv4
option external mudfileserver-SM
config ipset
option enabled 1
option name www_facebook_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external www_facebook_com-SM
config ipset
option enabled 1
option name www_facebook_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external www_facebook_com-SM
config ipset
option enabled 1
option name www_gmail_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external www_gmail_com-SM
config ipset
option enabled 1
option name www_gmail_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external www_gmail_com-SM
config rule
option enabled '1'
option name 'mud_192.168.20.197_same-manufacture-pi_cl0-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.197
option dest_ip 198.71.233.87
config rule
option enabled '1'
option name 'mud_192.168.20.197_same-manufacture-pi_cl0-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 198.71.233.87
option dest_ip 192.168.20.197
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_myman0-frdev-SM'
option target ACCEPT
option src lan
option dest lan
option proto tcp
option family ipv4
option src_ip 192.168.20.197
option ipset www_facebook_com-SMTD
option dest_port 80:80
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_myman0-todev-SM'
option target ACCEPT
option src lan
option dest lan
option proto tcp
option family ipv4
option ipset www_facebook_com-SMFD
option dest_ip 192.168.20.197
option dest_port 80:80
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_REJECT-ALL-LOCAL-FROM'
option target REJECT
option src lan
option dest lan
option proto all
option family ipv4
option src_ip 192.168.20.197
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_REJECT-ALL-LOCAL-TO'
option target REJECT
option src lan
option dest lan
option proto all
option family ipv4
option src_ip any
option dest_ip 192.168.20.197
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_REJECT-ALL'
option target REJECT
option src lan
option dest wan
option proto all
option family ipv4
option src_ip 192.168.20.197
# OSMUD end
|
Overall Results |
Pass |
As explained above, test IoT-2-v6 is identical to test IoT-2-v4 except that it uses IPv6, DHCPv6, and IANA code 112 instead of using IPv4, DHCPv4, and IANA code 161.
3.1.2.3 Test Case IoT-3-v4¶
Table 3‑4: Test Case IoT-3-v4
Test Case Field |
Description |
|---|---|
Parent Requirement |
(CR-4) The IoT DDoS example implementation shall include a MUD file server that can serve a MUD file and signature to the MUD manager. |
Testable Requirement |
(CR-4.b) The MUD file server shall serve the file and signature to the MUD manager, and the MUD manager shall check to determine whether the certificate used to sign the MUD file was valid at the time of signing, i.e., the certificate had already expired when it was used to sign the MUD file. (CR-4.b.1) The MUD manager shall cease to process the MUD file. (CR-4.b.2) The MUD manager shall send locally defined policy to the router or switch that handles whether to allow or block traffic to and from the MUD-enabled IoT device. |
Description |
Shows that if a MUD file server serves a MUD file with a signature that was created with an expired certificate, the MUD manager will cease processing the MUD file |
Associated Test Case(s) |
IoT-11-v4 (for the v6 version of this test, IoT-11-v6) |
Associated Cybersecurity Framework Subcategory(ies) |
PR.DS‐6 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
ExpiredCertTest.json |
Preconditions |
|
Procedure |
Verify that the MUD PEP router/switch for the IoT device to be used in the test does not yet have any configuration settings installed with respect to the IoT device being used in the test. Power on the IoT device and connect it to the test network. This should set in motion the following series of steps, which should occur automatically:
|
Expected Results |
The MUD PEP router/switch for the IoT device has had its configuration changed, i.e., it has been configured to deny all communication to and from the IoT device. The expected configuration should resemble the following. Expecting a show access session without a MUD file as seen below: # OSMUD start
#
# DO NOT EDIT THESE LINES. OSMUD WILL REPLACE WITH ITS CONFIGURATION
#
config ipset
option enabled 1
option name mudfiles_nist_getyikes_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external mudfiles_nist_getyikes_com-SM
config ipset
option enabled 1
option name mudfiles_nist_getyikes_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external mudfiles_nist_getyikes_com-SM
config ipset
option enabled 1
option name mudfileserver-SMTD
option match dest_ip
option storage hash
option family ipv4
option external mudfileserver-SM
config ipset
option enabled 1
option name mudfileserver-SMFD
option match src_ip
option storage hash
option family ipv4
option external mudfileserver-SM
config ipset
option enabled 1
option name www_facebook_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external www_facebook_com-SM
config ipset
option enabled 1
option name www_facebook_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external www_facebook_com-SM
config ipset
option enabled 1
option name www_gmail_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external www_gmail_com-SM
config ipset
option enabled 1
option name www_gmail_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external www_gmail_com-SM
# OSMUD end
|
Actual Results |
Procedures 1–4: pi@main-pi-Build2:~$ sudo dhclient -v -i eth0
sudo: unable to resolve host main-pi-Build2: Connection refused
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
RTNETLINK answers: Operation not possible due to RF-kill
Listening on LPF/wlan0/b8:27:eb:be:39:de
Sending on LPF/wlan0/b8:27:eb:be:39:de
Listening on LPF/eth0/b8:27:eb:eb:6c:8b
Sending on LPF/eth0/b8:27:eb:eb:6c:8b
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
DHCPREQUEST of 192.168.20.226 on eth0 to 255.255.255.255 port 67
DHCPOFFER of 192.168.20.226 from 192.168.20.1
DHCPACK of 192.168.20.226 from 192.168.20.1
Too few arguments.
Too few arguments.
bound to 192.168.20.226 -- renewal in 1800 seconds.
Procedure 5: dhcpmasq.txt 2019-07-11T18:03:00Z|OLD|Wired|DHCP|-|MUD|-|-|ba:47:a1:7d:41:bb|192.168.20.16
0||
2019-07-11T18:03:05Z|OLD|NIST
5|DHCP|-|MUD|-|-|18:b4:30:50:E2:01|192.168.20.143||
2019-07-11T18:03:12Z|DEL|Wired|DHCP|-|MUD|-|
|b8:27:eb:95:55:fe|192.168.20.233|raspberrypi|
2019-07-11T18:03:25Z|NEW|Wired|DHCP|1,28,2,3,15,6,119,12,44,47,26,121,42|
MUD|https://mudfiles.nist.getyikes.com/ExpiredCertTest.json|-|b8:27:eb:eb:6c:
8b|192.168.20.226|main-pi-Build2|
Procedure 7: MUD Manager: 2019-07-11 18:03:26
DEBUG::GENERAL::2019-07-11T18:03:25Z|NEW|Wired|DHCP|1,28,2,3,15,6,119,12,
44,47,26,121,42|MUD|https://mudfiles.nist.getyikes.com/ExpiredCertTest.json|-
|b8:27:eb:eb:6c:8b|192.168.20.226|main-pi-Build2|
2019-07-11 18:03:26 DEBUG::GENERAL::Executing on dhcpmasq info
2019-07-11 18:03:26 INFO::GENERAL::NEW Device Action: IP: 192.168.20.226,
MAC: b8:27:eb:eb:6c:8b
2019-07-11 18:03:26 DEBUG::COMMUNICATION::curl_easy_perform() doing it
now....
2019-07-11 18:03:26
DEBUG::COMMUNICATION::https://mudfiles.nist.getyikes.com/ExpiredCertTest.json
2019-07-11 18:03:26 DEBUG::COMMUNICATION::Found HTTPS
2019-07-11 18:03:26 DEBUG::COMMUNICATION::in write data
2019-07-11 18:03:26 DEBUG::COMMUNICATION::curl_easy_perform() success
2019-07-11 18:03:26 DEBUG::COMMUNICATION::MUD File Server returned success
state.
2019-07-11 18:03:26 DEBUG::COMMUNICATION::curl_easy_perform() doing it
now....
2019-07-11 18:03:26
DEBUG::COMMUNICATION::https://mudfiles.nist.getyikes.com/ExpiredCertTest.p7s
2019-07-11 18:03:26 DEBUG::COMMUNICATION::Found HTTPS
2019-07-11 18:03:27 DEBUG::COMMUNICATION::in write data
2019-07-11 18:03:27 DEBUG::COMMUNICATION::curl_easy_perform() success
2019-07-11 18:03:27 DEBUG::COMMUNICATION::MUD File Server returned success
state.
2019-07-11 18:03:27 DEBUG::MUD_FILE_OPERATIONS::IN ****NEW**** MUD and SIG
FILE RETRIEVED!!!
2019-07-11 18:03:27 DEBUG::GENERAL::IN ****NEW**** validateMudFileWithSig()
2019-07-11 18:03:27 DEBUG::GENERAL::openssl cms -verify -in
/etc/osmud/state/mudfiles/ExpiredCertTest.p7s -inform DER -content
/etc/osmud/state/mudfiles/ExpiredCertTest.json -purpose any > /dev/null
2019-07-11 18:03:27 ERROR::DEVICE_INTERFACE::openssl cms -verify -in
/etc/osmud/state/mudfiles/ExpiredCertTest.p7s -inform DER -content
/etc/osmud/state/mudfiles/ExpiredCertTest.json -purpose any > /dev/null
2019-07-11 18:03:27 ERROR::MUD_FILE_OPERATIONS::Could not validate the MUD
File signature using openssl cms verify. Abort mud file processing and
quarantine device.
2019-07-11 18:03:27 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan -d
wan -i 192.168.20.226 -a any -j any -b any -p all -n REJECT-ALL -t ACCEPT -f
all -c main-pi-Build2 -k /tmp/osmud -r 192.168.20.226
2019-07-11 18:03:27 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan -d
lan -i 192.168.20.226 -a any -j any -b any -p all -n REJECT-ALL-LOCAL-FROM -t
ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r 192.168.20.226
2019-07-11 18:03:27 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan -d
lan -i any -a any -j 192.168.20.226 -b any -p all -n REJECT-ALL-LOCAL-TO -t
ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r 192.168.20.226
Router/PEP: # OSMUD start
#
# DO NOT EDIT THESE LINES. OSMUD WILL REPLACE WITH ITS CONFIGURATION
#
config ipset
option enabled 1
option name mudfiles_nist_getyikes_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external mudfiles_nist_getyikes_com-SM
config ipset
option enabled 1
option name mudfiles_nist_getyikes_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external mudfiles_nist_getyikes_com-SM
config ipset
option enabled 1
option name mudfileserver-SMTD
option match dest_ip
option storage hash
option family ipv4
option external mudfileserver-SM
config ipset
option enabled 1
option name mudfileserver-SMFD
option match src_ip
option storage hash
option family ipv4
option external mudfileserver-SM
config ipset
option enabled 1
option name www_facebook_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external www_facebook_com-SM
config ipset
option enabled 1
option name www_facebook_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external www_facebook_com-SM
config ipset
option enabled 1
option name www_gmail_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external www_gmail_com-SM
config ipset
option enabled 1
option name www_gmail_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external www_gmail_com-SM
config rule
option enabled '1'
option name 'mud_192.168.20.197_same-manufacture-pi_cl0-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.197
option dest_ip 198.71.233.87
config rule
option enabled '1'
option name 'mud_192.168.20.197_same-manufacture-pi_cl0-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 198.71.233.87
option dest_ip 192.168.20.197
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_myman0-frdev-SM'
option target ACCEPT
option src lan
option dest lan
option proto tcp
option family ipv4
option src_ip 192.168.20.197
option ipset www_facebook_com-SMTD
option dest_port 80:80
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_myman0-todev-SM'
option target ACCEPT
option src lan
option dest lan
option proto tcp
option family ipv4
option ipset www_facebook_com-SMFD
option dest_ip 192.168.20.197
option dest_port 80:80
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_REJECT-ALL-LOCAL-FROM'
option target REJECT
option src lan
option dest lan
option proto all
option family ipv4
option src_ip 192.168.20.197
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_REJECT-ALL-LOCAL-TO'
option target REJECT
option src lan
option dest lan
option proto all
option family ipv4
option src_ip any
option dest_ip 192.168.20.197
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_REJECT-ALL'
option target REJECT
option src lan
option dest wan
option proto all
option family ipv4
option src_ip 192.168.20.197
# OSMUD end
|
Overall Results |
Pass |
As explained above, test IoT-3-v6 is identical to test IoT-3-v4 except that it uses IPv6, DHCPv6, and IANA code 112 instead of using IPv4, DHCPv4, and IANA code 161.
3.1.2.4 Test Case IoT-4-v4¶
Table 3‑5: Test Case IoT-4-v4
Test Case Field |
Description |
|---|---|
Parent Requirement |
(CR-5) The IoT DDoS example implementation shall include a MUD manager that can translate local network configurations based on the MUD file. |
Testable Requirement |
(CR-5.b) The MUD manager shall attempt to validate the signature of the MUD file, but the signature validation fails (even though the certificate that had been used to create the signature had not been expired at the time of signing, i.e., the signature is invalid for a different reason). (CR-5.b.1) The MUD manager shall cease processing the MUD file. (CR-5.b.2) The MUD manager shall send locally defined policy to the router or switch that handles whether to allow or block traffic to and from the MUD-enabled IoT device. |
Description |
Shows that if the MUD manager determines that the signature on the MUD file it receives from the MUD file server is invalid, it will cease processing the MUD file and configure the router/switch according to locally defined policy regarding whether to allow or block traffic to the IoT device in question |
Associated Test Case(s) |
IoT-11-v4 (for the v6 version of this test, IoT-11-v6) |
Associated Cybersecurity Framework Subcategory(ies) |
PR.DS‐6 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
cr-5b.json |
Preconditions |
|
Procedure |
Verify that the MUD PEP router/switch for the IoT device to be used in the test does not yet have any configuration settings installed with respect to the IoT device being used in the test. Power on the IoT device and connect it to the test network. This should set in motion the following series of steps, which should occur automatically:
|
Expected Results |
The MUD PEP router/switch for the IoT device has had its configuration changed, i.e., it has been configured to deny all communication to/from the IoT device. The expected configuration should resemble the following: Expecting a show access session without a MUD file as seen below: # OSMUD start
#
# DO NOT EDIT THESE LINES. OSMUD WILL REPLACE WITH ITS CONFIGURATION
#
config ipset
option enabled 1
option name mudfiles_nist_getyikes_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external mudfiles_nist_getyikes_com-SM
config ipset
option enabled 1
option name mudfiles_nist_getyikes_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external mudfiles_nist_getyikes_com-SM
config ipset
option enabled 1
option name mudfileserver-SMTD
option match dest_ip
option storage hash
option family ipv4
option external mudfileserver-SM
config ipset
option enabled 1
option name mudfileserver-SMFD
option match src_ip
option storage hash
option family ipv4
option external mudfileserver-SM
config ipset
option enabled 1
option name www_facebook_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external www_facebook_com-SM
config ipset
option enabled 1
option name www_facebook_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external www_facebook_com-SM
config ipset
option enabled 1
option name www_gmail_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external www_gmail_com-SM
config ipset
option enabled 1
option name www_gmail_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external www_gmail_com-SM
# OSMUD end
|
Actual Results |
Procedures 1-5: Excluded for sake of length. Procedure 6: MUD MANAGER: 2019-07-11 18:10:30
DEBUG::GENERAL::2019-07-11T18:10:24Z|NEW|Wired|DHCP|1,28,2,3,15,6,119,12,
44,47,26,121,42|MUD|https://mudfiles.nist.getyikes.com/cr-5b.json|-|b8:27:eb:
eb:6c:8b|192.168.20.226|main-pi-Build2|
2019-07-11 18:10:30 DEBUG::GENERAL::Executing on dhcpmasq info
2019-07-11 18:10:30 INFO::GENERAL::NEW Device Action: IP: 192.168.20.226,
MAC: b8:27:eb:eb:6c:8b
2019-07-11 18:10:30 DEBUG::COMMUNICATION::curl_easy_perform() doing it
now....
2019-07-11 18:10:30
DEBUG::COMMUNICATION::https://mudfiles.nist.getyikes.com/cr-5b.json
2019-07-11 18:10:30 DEBUG::COMMUNICATION::Found HTTPS
2019-07-11 18:10:31 DEBUG::COMMUNICATION::in write data
2019-07-11 18:10:31 DEBUG::COMMUNICATION::curl_easy_perform() success
2019-07-11 18:10:31 DEBUG::COMMUNICATION::MUD File Server returned success
state.
2019-07-11 18:10:31 DEBUG::COMMUNICATION::curl_easy_perform() doing it
now....
2019-07-11 18:10:31
DEBUG::COMMUNICATION::https://mudfiles.nist.getyikes.com/cr-5b.p7s
2019-07-11 18:10:31 DEBUG::COMMUNICATION::Found HTTPS
2019-07-11 18:10:31 DEBUG::COMMUNICATION::in write data
2019-07-11 18:10:31 DEBUG::COMMUNICATION::curl_easy_perform() success
2019-07-11 18:10:31 DEBUG::COMMUNICATION::MUD File Server returned success
state.
2019-07-11 18:10:31 DEBUG::MUD_FILE_OPERATIONS::IN ****NEW**** MUD and SIG
FILE RETRIEVED!!!
2019-07-11 18:10:31 DEBUG::GENERAL::IN ****NEW**** validateMudFileWithSig()
2019-07-11 18:10:31 DEBUG::GENERAL::openssl cms -verify -in
/etc/osmud/state/mudfiles/cr-5b.p7s -inform DER -content
/etc/osmud/state/mudfiles/cr-5b.json -purpose any > /dev/null
2019-07-11 18:10:31 ERROR::DEVICE_INTERFACE::openssl cms -verify -in
/etc/osmud/state/mudfiles/cr-5b.p7s -inform DER -content
/etc/osmud/state/mudfiles/cr-5b.json -purpose any > /dev/null
**2019-07-11 18:10:31 ERROR::MUD_FILE_OPERATIONS::Could not validate the MUD
File signature using openssl cms verify. Abort mud file processing and
quarantine device.**
2019-07-11 18:10:31 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan -d
wan -i 192.168.20.226 -a any -j any -b any -p all -n REJECT-ALL -t ACCEPT -f
all -c main-pi-Build2 -k /tmp/osmud -r 192.168.20.226
2019-07-11 18:10:31 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan -d
lan -i 192.168.20.226 -a any -j any -b any -p all -n REJECT-ALL-LOCAL-FROM -t
ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r 192.168.20.226
2019-07-11 18:10:31 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan -d
lan -i any -a any -j 192.168.20.226 -b any -p all -n REJECT-ALL-LOCAL-TO -t
ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r 192.168.20.226
Procedure 7: Router/PEP: # OSMUD start
#
# DO NOT EDIT THESE LINES. OSMUD WILL REPLACE WITH ITS CONFIGURATION
#
config ipset
option enabled 1
option name mudfiles_nist_getyikes_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external mudfiles_nist_getyikes_com-SM
config ipset
option enabled 1
option name mudfiles_nist_getyikes_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external mudfiles_nist_getyikes_com-SM
config ipset
option enabled 1
option name mudfileserver-SMTD
option match dest_ip
option storage hash
option family ipv4
option external mudfileserver-SM
config ipset
option enabled 1
option name mudfileserver-SMFD
option match src_ip
option storage hash
option family ipv4
option external mudfileserver-SM
config ipset
option enabled 1
option name www_facebook_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external www_facebook_com-SM
config ipset
option enabled 1
option name www_facebook_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external www_facebook_com-SM
config ipset
option enabled 1
option name www_gmail_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external www_gmail_com-SM
config ipset
option enabled 1
option name www_gmail_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external www_gmail_com-SM
config rule
option enabled '1'
option name 'mud_192.168.20.197_same-manufacture-pi_cl0-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.197
option dest_ip 198.71.233.87
config rule
option enabled '1'
option name 'mud_192.168.20.197_same-manufacture-pi_cl0-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 198.71.233.87
option dest_ip 192.168.20.197
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_myman0-frdev-SM'
option target ACCEPT
option src lan
option dest lan
option proto tcp
option family ipv4
option src_ip 192.168.20.197
option ipset www_facebook_com-SMTD
option dest_port 80:80
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_myman0-todev-SM'
option target ACCEPT
option src lan
option dest lan
option proto tcp
option family ipv4
option ipset www_facebook_com-SMFD
option dest_ip 192.168.20.197
option dest_port 80:80
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_REJECT-ALL-LOCAL-FROM'
option target REJECT
option src lan
option dest lan
option proto all
option family ipv4
option src_ip 192.168.20.197
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_REJECT-ALL-LOCAL-TO'
option target REJECT
option src lan
option dest lan
option proto all
option family ipv4
option src_ip any
option dest_ip 192.168.20.197
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_REJECT-ALL'
option target REJECT
option src lan
option dest wan
option proto all
option family ipv4
option src_ip 192.168.20.197
# OSMUD end
|
Overall Results |
Pass |
As explained above, test IoT-4-v6 is identical to test IoT-4-v4 except that it uses IPv6, DHCPv6, and IANA code 112 instead of using IPv4, DHCPv4, and IANA code 161.
3.1.2.5 Test Case IoT-5-v4¶
Table 3‑6: Test Case IoT-5-v4
Test Case Field |
Description |
|---|---|
Parent Requirement |
(CR-7) The IoT DDoS example implementation shall allow the MUD-enabled IoT device to communicate with approved internet services in the MUD file. (CR-8) The IoT DDoS example implementation shall deny communications from a MUD-enabled IoT device to unapproved internet services (i.e., services that are implicitly denied by virtue of not being explicitly approved). |
Testable Requirement |
(CR-7.a) The MUD-enabled IoT device shall attempt to initiate outbound traffic to approved internet services. (CR-7.a.1) The router or switch shall receive the attempt and shall allow it to pass based on the filters from the MUD file. (CR-7.b) An approved internet service shall attempt to initiate connection to the MUD-enabled IoT device. (CR-7.b.1) The router or switch shall receive the attempt and shall allow it to pass based on the filters from the MUD file. (CR-8.a) The MUD-enabled IoT device shall attempt to initiate outbound traffic to unapproved (implicitly denied) internet services. (CR-8.a.1) The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. (CR-8.b) An unapproved (implicitly denied) internet service shall attempt to initiate a connection to the MUD-enabled IoT device. (CR-8.b.1) The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. (CR-8.c) The MUD-enabled IoT device shall initiate communications to an internet service that is approved to initiate communications with the MUD-enabled device but not approved to receive communications initiated by the MUD-enabled device. (CR-8.c.1) The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. (CR-8.d) An internet service shall initiate communications to a MUD-enabled device that is approved to initiate communications with the internet service but that is not approved to receive communications initiated by the internet service. (CR-8.d.1) The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. |
Description |
Shows that, upon connection to the network, a MUD-enabled IoT device used in the IoT DDoS example implementation has its MUD PEP router/switch automatically configured to enforce the route filtering that is described in the device’s MUD file with respect to communication with internet services. Further shows that the policies that are configured on the MUD PEP router/switch with respect to communication with internet services will be enforced as expected, with communications that are configured as denied being blocked and communications that are configured as permitted being allowed. |
Associated Test Case(s) |
IoT-1-v4 (for the v6 version of this test, IoT-1-v6) |
Associated Cybersecurity Framework Subcategory(ies) |
ID.AM-3, PR.DS-5, PR.IP-1, PR.PT-3 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
Yikesmain.json |
Preconditions |
Test IoT-1-v4 (or IoT-1-v6) has run successfully, meaning that the MUD PEP router/switch has been configured to enforce the following policies for the IoT device in question (as defined in the MUD file in Section 3.1.3): Note: Procedure steps with strike-through were not tested due to network address translation (NAT).
|
Procedure |
Note: Procedure steps with strike-through were not tested due to NAT.
|
Expected Results |
Each of the results that is listed as needing to be verified in procedure steps above occurs as expected. |
Actual Results |
Procedure 1: Excluded for length’s sake Procedure 2: https://www.google.com (approved): --2019-07-11 18:23:38-- https://www.google.com/
Resolving www.google.com (www.google.com)... 172.217.164.132,
2607:f8b0:4004:814::2004
Connecting to www.google.com (www.google.com)|172.217.164.132|:443...
connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html.6’
0K .......... . 15.7M=0.001s
2019-07-11 18:23:38 (15.7 MB/s) - ‘index.html.6’ saved [11449]
https://www.osmud.org (approved): --2019-07-11 18:23:04-- https://www.osmud.org/
Resolving www.osmud.org (www.osmud.org)... 198.71.233.87
Connecting to www.osmud.org (www.osmud.org)|198.71.233.87|:443...
connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://osmud.org/ [following]
--2019-07-11 18:23:04-- https://osmud.org/
Resolving osmud.org (osmud.org)... 198.71.233.87
Connecting to osmud.org (osmud.org)|198.71.233.87|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html.4’
0K .......... .......... .... 3.40M=0.007s
2019-07-11 18:23:05 (3.40 MB/s) - ‘index.html.4’ saved [24697]
https://www.trytechy.com (approved): --2019-07-11 18:23:24-- https://www.trytechy.com/
Resolving www.trytechy.com (www.trytechy.com)... 99.84.181.77, 99.84.181.123,
99.84.181.11, ...
Connecting to www.trytechy.com (www.trytechy.com)|99.84.181.77|:443...
connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html.5’
0K .......... ...... 13.1M=0.001s
2019-07-11 18:23:24 (13.1 MB/s) - ‘index.html.5’ saved [16529]
Procedure 6: https://www.facebook.com (unapproved): --2019-07-11 18:23:55-- https://www.facebook.com/
Resolving www.facebook.com (www.facebook.com)... 31.13.71.36,
2a03:2880:f103:83:face:b00c:0:25de
Connecting to www.facebook.com (www.facebook.com)|31.13.71.36|:443...
failed: Connection refused.
Connecting to www.facebook.com
(www.facebook.com)|2a03:2880:f103:83:face:b00c:0:25de|:443... failed: Network
is unreachable.
https://www.twitter.com (unapproved): --2019-07-11 18:24:07-- https://www.twitter.com/
Resolving www.twitter.com (www.twitter.com)... 104.244.42.1, 104.244.42.65
Connecting to www.twitter.com (www.twitter.com)|104.244.42.1|:443...
failed: Connection refused.
Connecting to www.twitter.com (www.twitter.com)|104.244.42.65|:443... failed:
Connection refused.
|
Overall Results |
Pass (for testable procedures, ingress cannot be tested due to NAT) |
As explained above, test IoT-5-v6 is identical to test IoT-5-v4 except that it uses IPv6, DHCPv6, and IANA code 112 instead of using IPv4, DHCPv4, and IANA code 161.
3.1.2.6 Test Case IoT-6-v4¶
Table 3‑7: Test Case IoT-6-v4
Test Case Field |
Description |
|---|---|
Parent Requirement |
(CR-9) The IoT DDoS example implementation shall allow the MUD-enabled IoT device to communicate laterally with devices that are approved in the MUD file. (CR-10) The IoT DDoS example implementation shall deny lateral communications from a MUD-enabled IoT device to devices that are not approved in the MUD file (i.e., devices that are implicitly denied by virtue of not being explicitly approved). |
Testable Requirement |
(CR-9.a) The MUD-enabled IoT device shall attempt to initiate lateral traffic to approved devices. (CR-9.a.1) The router or switch shall receive the attempt and shall allow it to pass based on the filters from the MUD file. (CR-9.b) An approved device shall attempt to initiate a lateral connection to the MUD-enabled IoT device. (CR-9.b.1) The router or switch shall receive the attempt and shall allow it to pass based on the filters from the MUD file. (CR-10.a) The MUD-enabled IoT device shall attempt to initiate lateral traffic to unapproved (implicitly denied) devices. (CR-10.a.1) The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. (CR-10.b) An unapproved (implicitly denied) device shall attempt to initiate a lateral connection to the MUD-enabled IoT device. (CR-10.b.1) The router or switch shall receive the attempt and shall deny it based on the filters from the MUD file. |
Description |
Shows that, upon connection to the network, a MUD-enabled IoT device used in the IoT DDoS example implementation has its MUD PEP router/switch automatically configured to enforce the route filtering that is described in the device’s MUD file with respect to communication with lateral devices. Further shows that the policies that are configured on the MUD PEP router/switch with respect to communication with lateral devices will be enforced as expected, with communications that are configured as denied being blocked and communications that are configured as permitted being allowed. |
Associated Test Case(s) |
IoT-1-v4 (for the v6 version of this test, IoT-1-v6) |
Associated Cybersecurity Framework Subcategory(ies) |
ID.AM-3, PR.DS-5, PR.AC-5, PR.IP-1, PR.PT-3, PR.IP-3, PR.DS-3 |
IoT Device(s) Under Test |
Raspberry Pi (3) |
MUD File(s) Used |
Fe-localnetwork.json, Fe-my-controller.json, Fe-controller.json, Fe-manufacturer1.json, Fe-manufacturer2.json, Fe-samemanufacturer.json, Fe-localnetwork-to2.json, Fe-localnetwork-from2.json, Fe-samemanufacturer-from2.json, Fe-samemanufacturer-to2.json |
Preconditions |
Test IoT-1-v4 (or IoT-1-v6) has run successfully, meaning that the MUD PEP router/switch has been configured to enforce the following policies for the IoT device in question with respect to local communications (as defined in the MUD files in Section 3.1.3):
|
Procedure |
|
Expected Results |
Each of the results that is listed as needing to be verified in the procedure steps above occurs as expected. |
Actual Results |
Local-Network:
Controller:
My Controller:
Manufacturer:
Same Manufacturer:
|
Overall Results |
Pass |
As explained above, test IoT-6-v6 is identical to test IoT-6-v4 except that it uses IPv6, DHCPv6, and IANA code 112 instead of using IPv4, DHCPv4, and IANA code 161.
3.1.2.7 Test Case IoT-7-v4¶
Table 3‑8: Test Case IoT-7-v4
Test Case Field |
Description |
|---|---|
Parent Requirement |
(CR-11) If the IoT DDoS example implementation is such that its DHCP server does not act as a MUD manager and it forwards a MUD URL to a MUD manager, the DHCP server must notify the MUD manager of any corresponding change to the DHCP state of the MUD-enabled IoT device, and the MUD manager should remove the implemented policy configuration in the router/switch pertaining to that MUD-enabled IoT device. |
Testable Requirement |
(CR-11.a) The MUD-enabled IoT device shall explicitly release the IP address lease (i.e., it sends a DHCP release message to the DHCP server). (CR-11.a.1) The DHCP server shall notify the MUD manager that the device’s IP address lease has been released. (CR-11.a.2) The MUD manager should remove all policies associated with the disconnected IoT device that had been configured on the MUD PEP router/switch. |
Description |
Shows that when a MUD-enabled IoT device explicitly releases its IP address lease, the MUD-related configuration for that IoT device will be removed from its MUD PEP router/switch |
Associated Test Case(s) |
IoT-1-v4 (or IoT-1-v6 when IPv6 addressing is used) |
Associated Cybersecurity Framework Subcategory(ies) |
PR.IP-3, PR.DS-3 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
Fe-samemanufacturer.json |
Preconditions |
Test IoT-1-v4 (or IoT-1-v6) has run successfully, meaning that the MUD PEP router/switch has been configured to enforce the policies defined in the MUD file in for the IoT device in question. |
Procedure |
|
Expected Results |
All of the configuration rules listed above have been removed from the MUD PEP router/switch for the IoT device in question. |
Actual Results |
Procedure 2: pi@main-pi-Build2:~ $ sudo dhclient -r
Procedure 3: MUD Manager:
2019-07-11 18:57:30
DEBUG::GENERAL::2019-07-11T18:57:29Z|DEL|Wired|DHCP|-|MUD|-|-|b8:27:eb:eb
:6c:8b|192.168.20.226|main-pi-Build2|
2019-07-11 18:57:30 DEBUG::GENERAL::Executing on dhcpmasq info
2019-07-11 18:57:30 INFO::GENERAL::DEL Device Action: IP: 192.168.20.226,
MAC: b8:27:eb:eb:6c:8b
2019-07-11 18:57:30 DEBUG::GENERAL::/etc/osmud/find_device_in_db.sh -d
/etc/osmud/state/mudfiles/mudStateFile.txt -m b8:27:eb:eb:6c:8b -i
192.168.20.226 -s /etc/osmud/state/ipSets -a DELETE -u NONE
2019-07-11 18:57:30 DEBUG::GENERAL::Return: 4864.
2019-07-11 18:57:30 DEBUG::GENERAL::FinalReturn: 19.
2019-07-11 18:57:30 ERROR::DEVICE_INTERFACE::FinalReturn: 19.
2019-07-11 18:57:30 DEBUG::CONTROLLER::MUD Controller: A delete event
associated with a MUD file is being processed. IP: 192.168.20.226.
2019-07-11 18:57:30 DEBUG::GENERAL::rm -f /tmp/osmud/
2019-07-11 18:57:30 DEBUG::GENERAL::cp /etc/osmud/state/ipSets/
/tmp/osmud
2019-07-11 18:57:30 DEBUG::GENERAL::/etc/osmud/remove_ip_fw_rule.sh -i
192.168.20.226 -m b8:27:eb:eb:6c:8b -d /tmp/osmud
2019-07-11 18:57:30 DEBUG::GENERAL::/etc/osmud/remove_from_ipset.sh -d
/tmp/osmud -i 192.168.20.226
2019-07-11 18:57:30 DEBUG::GENERAL::/etc/osmud/commit_ip_fw_rules.sh -d
/etc/osmud/state/ipSets -t /tmp/osmud
2019-07-11 18:57:30 DEBUG::GENERAL::/etc/osmud/remove_mud_db_entry.sh -d
/etc/osmud/state/mudfiles/mudStateFile.txt -i 192.168.20.226 -m
b8:27:eb:eb:6c:8b
2019-07-11 18:57:30 DEBUG::GENERAL::Success returned from for transaction
Procedure 4: ROUTER/PEP:
# OSMUD start
#
# DO NOT EDIT THESE LINES. OSMUD WILL REPLACE WITH ITS CONFIGURATION
#
config ipset
option enabled 1
option name mudfiles_nist_getyikes_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external mudfiles_nist_getyikes_com-SM
config ipset
option enabled 1
option name mudfiles_nist_getyikes_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external mudfiles_nist_getyikes_com-SM
config ipset
option enabled 1
option name mudfileserver-SMTD
option match dest_ip
option storage hash
option family ipv4
option external mudfileserver-SM
config ipset
option enabled 1
option name mudfileserver-SMFD
option match src_ip
option storage hash
option family ipv4
option external mudfileserver-SM
config ipset
option enabled 1
option name www_facebook_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external www_facebook_com-SM
config ipset
option enabled 1
option name www_facebook_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external www_facebook_com-SM
config ipset
option enabled 1
option name www_gmail_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external www_gmail_com-SM
config ipset
option enabled 1
option name www_gmail_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external www_gmail_com-SM
config rule
option enabled '1'
option name 'mud_192.168.20.197_same-manufacture-pi_cl0-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.197
option dest_ip 198.71.233.87
config rule
option enabled '1'
option name 'mud_192.168.20.197_same-manufacture-pi_cl0-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 198.71.233.87
option dest_ip 192.168.20.197
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_myman0-frdev-SM'
option target ACCEPT
option src lan
option dest lan
option proto tcp
option family ipv4
option src_ip 192.168.20.197
option ipset www_facebook_com-SMTD
option dest_port 80:80
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_myman0-todev-SM'
option target ACCEPT
option src lan
option dest lan
option proto tcp
option family ipv4
option ipset www_facebook_com-SMFD
option dest_ip 192.168.20.197
option dest_port 80:80
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_REJECT-ALL-LOCAL-FROM'
option target REJECT
option src lan
option dest lan
option proto all
option family ipv4
option src_ip 192.168.20.197
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_REJECT-ALL-LOCAL-TO'
option target REJECT
option src lan
option dest lan
option proto all
option family ipv4
option src_ip any
option dest_ip 192.168.20.197
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_REJECT-ALL'
option target REJECT
option src lan
option dest wan
option proto all
option family ipv4
option src_ip 192.168.20.197
# OSMUD end
|
Overall Results |
Pass |
As explained above, test IoT-7-v6 is identical to test IoT-7-v4 except that it uses IPv6, DHCPv6, and IANA code 112 instead of using IPv4, DHCPv4, and IANA code 161.
3.1.2.8 Test Case IoT-8-v4¶
Table 3‑9: Test Case IoT-8-v4
Test Case Field |
Description |
|---|---|
Parent Requirement |
(CR-11) If the IoT DDoS example implementation is such that its DHCP server does not act as a MUD manager and it forwards a MUD URL to a MUD manager, the DHCP server must notify the MUD manager of any corresponding change to the DHCP state of the MUD-enabled IoT device, and the MUD manager should remove the implemented policy configuration in the router/switch pertaining to that MUD-enabled IoT device. |
Testable Requirement |
(CR-11.b) The MUD-enabled IoT device’s IP address lease shall expire. (CR-11.b.1) The DHCP server shall notify the MUD manager that the device’s IP address lease has expired. (CR-11.b.2) The MUD manager should remove all policies associated with the affected IoT device that had been configured on the MUD PEP router/switch. |
Description |
Shows that when a MUD-enabled IoT device’s IP address lease expires, the MUD-related configuration for that IoT device will be removed from its MUD PEP router/switch |
Associated Test Case(s) |
IoT-1-v4 (or IoT-1-v6 when IPv6 addressing is used) |
Associated Cybersecurity Framework Subcategory(ies) |
PR.IP-3, PR.DS-3 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
Fe-manufacturer1.json |
Preconditions |
Test IoT-1-v4 (or IoT-1-v6) has run successfully, meaning that the MUD PEP router/switch has been configured to enforce the policies defined in the MUD file in Section 3.1.3 for the IoT device in question. |
Procedure |
|
Expected Results |
Once 60 minutes have elapsed after disconnecting the IoT device from the network, all of the configuration rules listed above have been removed from the MUD PEP router/switch for the IoT device in question. |
Actual Results |
Procedures 1–4: Completed; excluded for brevity Procedure 5: 1. MUD MANAGER: 2019-07-12 17:34:49
DEBUG::GENERAL::2019-07-12T17:34:49Z|DEL|Wired|DHCP|-|MUD|-|-
|b8:27:eb:a2:88:f3|192.168.20.184|manufacturer-pi|
2019-07-12 17:34:49 DEBUG::GENERAL::Executing on dhcpmasq info
2019-07-12 17:34:49 INFO::GENERAL::DEL Device Action: IP: 192.168.20.184,
MAC: b8:27:eb:a2:88:f3
2019-07-12 17:34:49 DEBUG::GENERAL::/etc/osmud/find_device_in_db.sh -d
/etc/osmud/state/mudfiles/mudStateFile.txt -m b8:27:eb:a2:88:f3 -i
192.168.20.184 -s /etc/osmud/state/ipSets -a DELETE -u NONE
2019-07-12 17:34:49 DEBUG::GENERAL::Return: 3328.
2019-07-12 17:34:49 DEBUG::GENERAL::FinalReturn: 13.
2019-07-12 17:34:49 ERROR::DEVICE_INTERFACE::FinalReturn: 13.
2019-07-12 17:34:49 DEBUG::CONTROLLER::MUD Controller: A delete event
associated with a MUD file is being processed. IP:
192.168.20.184. 2019-07-12 17:34:49 DEBUG::GENERAL::rm -f /tmp/osmud/*
2019-07-12 17:34:49 DEBUG::GENERAL::cp /etc/osmud/state/ipSets/*
/tmp/osmud
2019-07-12 17:34:49
DEBUG::GENERAL::/etc/osmud/\ **remove \_ip_fw_rule.sh -i 192.168.20.184
-m b8:27:eb:a2:88:f3 -d /tmp/osmud
2019-07-12 17:34:49
DEBUG::GENERAL::/etc/osmud/\ **remove \_from_ipset.sh -d /tmp/osmud -i
192.168.20.184
2019-07-12 17:34:49 DEBUG::GENERAL::/etc/osmud/commit_ip_fw_rules.sh -d
/etc/osmud/state/ipSets -t /tmp/osmud
2019-07-12 17:34:50
DEBUG::GENERAL::/etc/osmud/\ **remove \_mud_db_entry.sh -d
/etc/osmud/state/mudfiles/mudStateFile.txt -i 192.168.20.184 -m
b8:27:eb:a2:88:f3
2019-07-12 17:34:50 DEBUG::GENERAL::Success returned from for
transaction
2. Router/PEP: # OSMUD start
#
# DO NOT EDIT THESE LINES. OSMUD WILL REPLACE WITH ITS CONFIGURATION
#
config ipset
option enabled 1
option name mudfiles_nist_getyikes_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external mudfiles_nist_getyikes_com-SM
config ipset
option enabled 1
option name mudfiles_nist_getyikes_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external mudfiles_nist_getyikes_com-SM
config ipset
option enabled 1
option name mudfileserver-SMTD
option match dest_ip
option storage hash
option family ipv4
option external mudfileserver-SM
config ipset
option enabled 1
option name mudfileserver-SMFD
option match src_ip
option storage hash
option family ipv4
option external mudfileserver-SM
config ipset
option enabled 1
option name www_facebook_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external www_facebook_com-SM
config ipset
option enabled 1
option name www_facebook_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external www_facebook_com-SM
config ipset
option enabled 1
option name www_gmail_com-SMTD
option match dest_ip
option storage hash
option family ipv4
option external www_gmail_com-SM
config ipset
option enabled 1
option name www_gmail_com-SMFD
option match src_ip
option storage hash
option family ipv4
option external www_gmail_com-SM
config rule
option enabled '1'
option name 'mud_192.168.20.197_same-manufacture-pi_cl0-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.197
option dest_ip 198.71.233.87
config rule
option enabled '1'
option name 'mud_192.168.20.197_same-manufacture-pi_cl0-todev'
option target ACCEPT
option src wan
option dest lan
option proto tcp
option family ipv4
option src_ip 198.71.233.87
option dest_ip 192.168.20.197
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_myman0-frdev-SM'
option target ACCEPT
option src lan
option dest lan
option proto tcp
option family ipv4
option src_ip 192.168.20.197
option ipset www_facebook_com-SMTD
option dest_port 80:80
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_myman0-todev-SM'
option target ACCEPT
option src lan
option dest lan
option proto tcp
option family ipv4
option ipset www_facebook_com-SMFD
option dest_ip 192.168.20.197
option dest_port 80:80
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_REJECT-ALL-LOCAL-FROM'
option target REJECT
option src lan
option dest lan
option proto all
option family ipv4
option src_ip 192.168.20.197
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_REJECT-ALL-LOCAL-TO'
option target REJECT
option src lan
option dest lan
option proto all
option family ipv4
option src_ip any
option dest_ip 192.168.20.197
config rule
option enabled '1'
option name
'mud_192.168.20.197_same-manufacture-pi_REJECT-ALL'
option target REJECT
option src lan
option dest wan
option proto all
option family ipv4
option src_ip 192.168.20.197
# OSMUD end
|
Overall Results |
Pass |
As explained above, test IoT-8-v6 is identical to test IoT-8-v4 except that it uses IPv6, DHCPv6, and IANA code 112 instead of using IPv4, DHCPv4, and IANA code 161.
3.1.2.9 Test Case IoT-9-v4¶
Table 3‑10: Test Case IoT-9-v4
Test Case Field |
Description |
|---|---|
Parent Requirements |
(CR-13) The IoT DDoS example implementation shall ensure that for each rule in a MUD file that pertains to an external domain, the MUD PEP router/switch will get configured with all possible instantiations of that rule, insofar as each instantiation contains one of the IP addresses to which the domain in that MUD file rule may be resolved when queried by the MUD PEP router/switch. |
Testable Requirements |
(CR-13.a) The MUD file for a device shall contain a rule involving an external domain that can resolve to multiple IP addresses when queried by the MUD PEP router/switch. An ACL for permitting access to each of those IP addresses will be inserted into the MUD PEP router/switch for the device in question, and the device will be permitted to communicate with all of those IP addresses. |
Description |
Shows that if a domain in a MUD file rule resolves to multiple IP addresses when the address resolution is queried by the network gateway, then
|
Associated Test Case(s) |
N/A |
Associated Cybersecurity Framework Subcategory(ies) |
ID.AM-1, ID.AM-2, ID.AM-3, PR.DS-5, DE.AE-1, PR.AC-4, PR.AC-5, PR.IP-1, PR.IP-3, PR.DS-2 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
Yikesmain.json |
Preconditions |
|
Procedure |
|
Expected Results |
The MUD PEP router/switch for the IoT device has had its configuration changed, i.e., it has been configured to permit the IoT device to send data to IP addresses x1.x1.x1.x1, y1.y1.y1.y1, and z1.z1.z1.z1. The IoT device is permitted to send data to each of the update servers at these addresses. |
Actual Results |
Procedures 1–2: Completed; excluded for brevity Procedure 3: MUD MANAGER: 2019-07-15 20:28:32
DEBUG::GENERAL::2019-07-15T20:28:31Z|NEW|Wired|DHCP|1,28,2,3,15,6,119,12,44
,47,26,121,42|MUD|https://mudfiles.nist.getyikes.com/yikesmain.json|-
|b8:27:eb:eb:6c:8b|192.168.20.222|main-pi-Build2|
__
2019-07-15 20:28:32 DEBUG::GENERAL::Executing on dhcpmasq info
2019-07-15 20:28:32 INFO::GENERAL::NEW Device Action: IP: 192.168.20.222,
MAC: b8:27:eb:eb:6c:8b
2019-07-15 20:28:32 DEBUG::COMMUNICATION::curl_easy_perform() doing it
now....
2019-07-15 20:28:32
DEBUG::COMMUNICATION::https://mudfiles.nist.getyikes.com/yikesmain.json
2019-07-15 20:28:32 DEBUG::COMMUNICATION::Found HTTPS
2019-07-15 20:28:32 DEBUG::COMMUNICATION::in write data
2019-07-15 20:28:32 DEBUG::COMMUNICATION::curl_easy_perform() success
2019-07-15 20:28:32 DEBUG::COMMUNICATION::MUD File Server returned success
state.
2019-07-15 20:28:32 DEBUG::COMMUNICATION::curl_easy_perform() doing it
now....
2019-07-15 20:28:32
DEBUG::COMMUNICATION::https://mudfiles.nist.getyikes.com/yikesmain.p7s
2019-07-15 20:28:32 DEBUG::COMMUNICATION::Found HTTPS
2019-07-15 20:28:32 DEBUG::COMMUNICATION::in write data
2019-07-15 20:28:32 DEBUG::COMMUNICATION::curl_easy_perform() success
2019-07-15 20:28:32 DEBUG::COMMUNICATION::MUD File Server returned success
state.
2019-07-15 20:28:32 DEBUG::MUD_FILE_OPERATIONS::IN ****NEW**** MUD and
SIG FILE RETRIEVED!!!
2019-07-15 20:28:32 DEBUG::GENERAL::IN ****NEW****
validateMudFileWithSig()
2019-07-15 20:28:32 DEBUG::GENERAL::openssl cms -verify -in
/etc/osmud/state/mudfiles/yikesmain.p7s -inform DER -content
/etc/osmud/state/mudfiles/yikesmain.json -purpose any > /dev/null
2019-07-15 20:28:32 DEBUG::GENERAL::IN ****NEW****
executeMudWithDhcpContext()
2019-07-15 20:28:32 DEBUG::GENERAL::/etc/osmud/create_mud_db_entry.sh -d
/etc/osmud/state/mudfiles/mudStateFile.txt -i 192.168.20.222 -m
b8:27:eb:eb:6c:8b -c main-pi-Build2 -u
https://mudfiles.nist.getyikes.com/yikesmain.json -f
/etc/osmud/state/mudfiles/yikesmain.json
[Logs omitted for brevity] 2019-07-15 20:28:32 DEBUG::GENERAL:: www.updateserver.com
2019-07-15 20:28:33 DEBUG::GENERAL::192.168.20.4
2019-07-15 20:28:33 DEBUG::GENERAL::192.168.20.238
2019-07-15 20:28:33 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan -d
wan -i 192.168.20.222 -a any -j 192.168.20.4 -b 443:443 -p tcp -n cl2-frdev
-t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r 192.168.20.222
2019-07-15 20:28:33 DEBUG::GENERAL::/etc/osmud/create_ip_fw_rule.sh -s lan
-d wan -i 192.168.20.222 -a any -j 192.168.20.238 -b 443:443 -p tcp -n
cl2-frdev -t ACCEPT -f all -c main-pi-Build2 -k /tmp/osmud -r
192.168.20.222
[Logs omitted for brevity] 2019-07-15 20:28:33 DEBUG::GENERAL:: Success returned from for
transaction
Router/PEP: config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl2-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
option dest_ip 192.168.20.4
option dest_port 443:443
config rule
option enabled '1'
option name 'mud_192.168.20.222_main-pi-Build2_cl2-frdev'
option target ACCEPT
option src lan
option dest wan
option proto tcp
option family ipv4
option src_ip 192.168.20.222
option dest_ip 192.168.20.238
option dest_port 443:443
Procedure 4:
|
Overall Results |
Pass |
Test case IoT-9-v6 is identical to test case IoT-9-v4 except that IoT-9-v6 uses IPv6 addresses rather than IPv4 addresses.
3.1.2.10 Test Case IoT-10-v4¶
Table 3‑11: Test Case IoT-10-v4
Test Case Field |
Description |
|---|---|
Parent Requirements |
(CR-12) The IoT DDoS example implementation shall include a MUD manager that uses a cached MUD file rather than retrieve a new one if the cache-validity time period has not yet elapsed for the MUD file indicated by the MUD URL. The MUD manager should fetch a new MUD file if the cache-validity time period has already elapsed. |
Testable Requirements |
(CR-12.a) The MUD manager shall check if the file associated with the MUD URL is present in its cache and shall determine that it is. (CR-12.a.1) The MUD manager shall check whether the amount of time that has elapsed since the cached file was retrieved is less than or equal to the number of hours in the cache-validity value for this MUD file. If so, the MUD manager shall apply the contents of the cached MUD file. (CR-12.a.2) The MUD manager shall check whether the amount of time that has elapsed since the cached file was retrieved is greater than the number of hours in the cache-validity value for this MUD file. If so, the MUD manager may (but does not have to) fetch a new file by using the MUD URL received. |
Description |
Shows that, upon connection to the network, a MUD-enabled IoT device used in the IoT DDoS example implementation has its MUD PEP router/switch automatically configured to enforce the route filtering that is described in the cached MUD file for that device’s MUD URL, assuming that the amount of time that has elapsed since the cached MUD file was retrieved is less than or equal to the number of hours in the file’s cache-validity value. If the cache validity has expired for the respective file, the MUD manager should fetch a new MUD file from the MUD file server. |
Associated Test Case(s) |
N/A |
Associated Cybersecurity Framework Subcategory(ies) |
ID.AM-1, ID.AM-2, ID.AM-3, PR.DS-5, DE.AE-1, PR.AC-4, PR.AC-5, PR.IP-1, PR.IP-3, PR.DS-2, PR.PT-3 |
IoT Device(s) Under Test |
To be determined (TBD) (Not testable in Build 2’s preproduction of Yikes!) |
MUD File(s) Used |
TBD (Not testable in Build 2’s preproduction of Yikes!) |
Preconditions |
|
Procedure |
Verify that the MUD PEP router/switch for the IoT device to be used in the test does not yet have any configuration settings installed with respect to the IoT device being used in the test.
|
Expected Results |
The MUD PEP router/switch for the IoT device has had its configuration changed, i.e., it has been configured to enforce the policies specified in the IoT device’s MUD file. The expected configuration should resemble the following. Cache is valid (the MUD manager does NOT retrieve the MUD file from the MUD file server): TBD (Not testable in Build 2’s preproduction of Yikes!) Cache is not valid (the MUD manager does retrieve the MUD file from the MUD file server): TBD (Not testable in Build 2’s preproduction of Yikes!) All protocol exchanges described in steps 1–9 above are expected to occur and can be viewed via Wireshark if desired. If the router/switch does not get configured in accordance with the MUD file, each exchange of DHCP and MUD-related protocol traffic should be viewed on the network via Wireshark to determine which transactions did not proceed as expected, and the observed and absent protocol exchanges should be described here. |
Actual Results |
TBD (Not testable in Build 2’s preproduction of Yikes!) |
Overall Results |
TBD (Not testable in Build 2’s preproduction of Yikes!) |
Test case IoT-10-v6 is identical to test case IoT-10-v4 except that IoT-10-v6 tests requirement CR-1.a.2, whereas IoT-10-v4 tests requirement CR-1.a.1. Hence, as explained above, test IoT-10-v6 uses IPv6, DHCPv6, and IANA code 112 instead of using IPv4, DHCPv4, and IANA code 161.
3.1.2.11 Test Case IoT-11-v4¶
Table 3‑12: Test Case IoT-11-v4
Test Case Field |
Description |
|---|---|
Parent Requirements |
(CR-1) The IoT DDoS example implementation shall include a mechanism for associating a device with a MUD file URL (e.g., by having the MUD-enabled IoT device emit a MUD file URL via DHCP, LLDP, or X.509 or by using some other mechanism to enable the network to associate a device with a MUD file URL). |
Testable Requirements |
(CR-1.a) Upon initialization, the MUD-enabled IoT device shall broadcast a DHCP message on the network, including at most one MUD URL, in https scheme, within the DHCP transaction. (CR-1.a.1) The DHCP server shall be able to receive DHCPv4 DISCOVER and REQUEST with IANA code 161 (OPTION_MUD_URL_V4) from the MUD-enabled IoT device. |
Description |
Shows that the IoT DDoS example implementation includes IoT devices that can emit a MUD URL via DHCP |
Associated Test Case(s) |
N/A |
Associated Cybersecurity Framework Subcategory(ies) |
ID.AM-1 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
Yikesmain.json |
Preconditions |
Device has been developed to emit MUD URL in DHCP transaction |
Procedure |
|
Expected Results |
DHCP transaction with MUD option 161 enabled and MUD URL included |
Actual Results |
MUD option included in DHCP transaction: |
Overall Results |
Pass |
3.1.3 MUD Files¶
This section contains the MUD files that were used in the Build 2 functional demonstration.
3.1.3.1 Fe-controller.json¶
The complete Fe-controller.json MUD file has been linked to this document. To access this MUD file please click the link below.
3.1.3.2 Fe-localnetwork-from2.json¶
The complete Fe-localnetwork-from2.json MUD file has been linked to this document. To access this MUD file please click the link below.
3.1.3.3 Fe-localnetwork-to2.json¶
The complete fe-localnetwork-to2.json MUD file has been linked to this document. To access this MUD file please click the link below.
3.1.3.4 Fe-manufacturer1.json¶
The complete Fe-manufacturer1.json MUD file has been linked to this document. To access this MUD file please click the link below.
3.1.3.5 Fe-manufacturer2.json¶
The complete Fe-manufacturer2.json MUD file has been linked to this document. To access this MUD file please click the link below.
3.1.3.6 Fe-mycontroller.json¶
The complete Fe-mycontroller.json MUD file has been linked to this document. To access this MUD file please click the link below.
3.1.3.7 Fe-samemanufacturer-from2.json¶
The complete Fe-samemanufacturer-from2.json MUD file has been linked to this document. To access this MUD file please click the link below.
3.1.3.8 Fe-samemanufacturer-to2.json¶
The complete Fe-samemanufacturer-to2.json MUD file has been linked to this document. To access this MUD file please click the link below.
3.1.3.9 Yikesmain.json¶
The complete Yikesmain.json MUD file has been linked to this document. To access this MUD file please click the link below.
3.2 Demonstration of Non-MUD-Related Capabilities¶
In addition to supporting MUD, Build 2 supports capabilities with respect to device discovery, identification, categorization, and application of traffic rules based on device make and model. Table 2‑13 lists the non-MUD-related capabilities that were demonstrated for Build 2. Before examining these capabilities, however, it is instructive to define terminology and provide an overview of Build 2’s non-MUD-related capabilities.
3.2.1 Terminology¶
The terminology that is used to describe non-MUD capabilities is not standardized. To avoid confusion, we offer the following definitions for use in this section:
Device discovery—detection that a device is on the network
Device identity—an identifier that a build assigns to the device and uses to keep track of the device. In Build 2, when a device is discovered, it is assigned a unique identity.
Device identification—determination of the device’s make (i.e., manufacturer) and model. In Build 2, each make and model combination may be associated with internet traffic rules that, if present, will be applied to all devices having that same make and model.
Category—a predefined class to which devices are assigned based on their make and model. Each category is associated with traffic rules (for both local traffic and internet traffic) that will be applied to all devices in that category.
Device categorization—determination of which of the build’s predefined categories to which to assign the device. The device’s make and model determine its category, e.g., if the device is determined to be a Samsung Galaxy S8, it is placed in the phone category.
Traffic policy—a set of traffic rules that may be associated with a category of devices or a set of devices having the same make and model; the traffic policy determines to what other local devices and remote domains these devices are permitted to initiate communication.
3.2.2 General Overview of Build 2’s Non-MUD Functionality¶
Once Build 2 discovers a device on the network, it applies the following non-MUD capabilities to it:
automatic (if possible) identification of the device’s make (i.e., manufacturer) and model
categorization of the device based on its make and model
association of the device category with a traffic policy that indicates what communication devices in that category are permitted to initiate. This policy consists of rules that apply to both local and internet communications. The rules in this policy can be viewed using the Yikes! User Interface (UI). By selecting the specific category (e.g., “cellphone” or “computer”) on the UI Categories page, one can see two categories of rules, Local Network and Internet:
Internet rules that may be set to either
Allow All Internet Traffic, which indicates that all devices in this category are permitted to initiate communications to all internet domains
or
IoT Specific Sites, which indicates that there may be additional rules configured on the router that apply to specific makes and models of devices in this category and that restrict the internet sites to which those devices are permitted to initiate communications. (These per-make-and-model rules are stored in the cloud and viewed using the Yikes! UI. The IoT Devices tab displays the list of domain names to which communications may be initiated. For this version of the Yikes! cloud, these rules were set manually based on Build 2 test cases.)
Local Network rules that may be set to either
Allow All, which, if set, indicates that devices in this category are permitted to initiate communications to all other devices on the local network
or
any combination of other categories (cell phones, printers, tablets, printers, etc.) These indicate the other categories of devices on the local network to which devices in this category are permitted to initiate communications.
3.2.4 Exercises to Demonstrate the Above Non-MUD-Related Capabilities¶
This section contains the exercises that were performed to verify that Build 2 supports the non-MUD-related capabilities listed in Table 3‑13.
To support these tests, the following domains must be available on the internet (i.e., outside the local network):
www.google.com
www.osmud.org
www.trytechy.com
3.2.4.1 Exercise YnMUD-1-v4¶
Table 3‑14: Exercise YnMUD-1-v4
Exercise Field |
Description |
||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Parent Capability |
(Y-1) Device Identification–The device is detected, and its make and model are identified upon connection to the network. (Y-2) Device Categorization–The device is correctly categorized according to its type (e.g., phone, printer, computer, watch) upon connection to the network. |
||||||||||||||||||||||||||||||
Subrequirement(s) of Parent Capability to be Demonstrated |
(Y-1.a) The non-MUD-capable device’s make and model are correctly
identified based on some combination of information such as the device’s
MAC address, DHCP header information, and lookup in repositories.
(Y-2.a) The non-MUD-capable device is correctly categorized based on its
make and model. The device make and model were determined using some
combination of MAC address, DHCP header information, and lookup in
repositories.
(Y-1.b) The non-MUD-capable device’s make and model cannot be identified.
(Y-2.b) The make and model of the non-MUD-capable device cannot be
determined. The non-MUD-capable device is designated as uncategorized.
|
||||||||||||||||||||||||||||||
Description |
Verify that upon detection, when possible, the make (i.e., manufacturer) and model of a non-MUD-capable device are identified correctly based on some combination of its MAC address, DHCP header information, and lookup through the Yikes! cloud service; the device is assigned to the correct category; and it is assigned a unique identity. In addition, verify that a non-MUD-capable device whose make and model cannot be determined will be assigned to the “uncategorized” category. |
||||||||||||||||||||||||||||||
Associated Exercises |
N/A |
||||||||||||||||||||||||||||||
Associated Cybersecurity Framework Subcategory(ies) |
ID.AM-1, ID.AM-2, ID.AM-3, DE.AE-1, DE.CM-1 |
||||||||||||||||||||||||||||||
IoT Device(s) Used |
|
||||||||||||||||||||||||||||||
Policy Used |
N/A |
||||||||||||||||||||||||||||||
Preconditions |
The Yikes! router is installed on the local network and connected to the internet. The Yikes! account is set up and available to the user at https://nist.getyikes.com. The IoT devices listed above are available to be connected to the local network. |
||||||||||||||||||||||||||||||
Procedure |
|
||||||||||||||||||||||||||||||
Demonstrated Results |
Access the Yikes! UI, go to the Devices page, click the ALL tab, and verify that the following information is present, showing that each device has been given a unique identifier (not necessarily ID_X), has had its make and model correctly identified (if possible), and has been categorized appropriately: Procedures 1–2:
Procedures 3–4:
|
Exercise YnMUD-1-v6 is identical to exercise YnMUD-1-v4 except that it uses IPv6 instead of IPv4.
3.2.4.2 Exercise YnMUD-2-v4¶
Table 3‑15: Exercise YnMUD-2-v4
Exercise Field |
Description |
||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Parent Capability |
(Y-1) Device Identification–The device is detected, and its make and model are identified upon connection to the network. (Y-2) Device Categorization–The device is correctly categorized according to its type (e.g., phone, printer, computer, watch) upon connection to the network. |
||||||||||||||||||||||||||||||
Subrequirement(s) of Parent Capability to Be Demonstrated |
(Y-1.c) The non-MUD-capable device’s make and model can be assigned manually. (Y-2.c) The non-MUD-capable device’s category can be assigned manually. |
||||||||||||||||||||||||||||||
Description |
Verify that a non-MUD-capable device can have its make, model, or category assigned manually. |
||||||||||||||||||||||||||||||
Associated Exercises |
YnMUD-1-v4 |
||||||||||||||||||||||||||||||
Associated Cybersecurity Framework Subcategory(ies) |
ID.AM-1, ID.AM-3 |
||||||||||||||||||||||||||||||
IoT Device(s) Used |
Same as for exercise YnMUD-1-v4 |
||||||||||||||||||||||||||||||
Policy Used |
N/A |
||||||||||||||||||||||||||||||
Preconditions |
Same as for exercise YnMUD-1-v4 |
||||||||||||||||||||||||||||||
Procedure |
|
||||||||||||||||||||||||||||||
Demonstrated Results |
Access the Yikes! UI, go to the Device tab, and verify that the following information is present: Procedure 1: Completed; excluded for brevity Procedures 2–3:
Procedure 4:
|
Exercise YnMUD-2-v6 is identical to exercise YnMUD-2-v4 except that it uses IPv6 instead of IPv4.
3.2.4.3 Exercise YnMUD-3-v4¶
Table 3‑16: Exercise YnMUD-3-v4
Exercise Field |
Description |
|---|---|
Parent Capability |
(Y-3) Rules regarding initiation of (south-north) communications to internet sites by the non-MUD-capable device are enforced according to rules associated with the device’s category and, possibly, its make and model. |
Subrequirement(s) of Parent Capability to Be Demonstrated |
(Y-3.a) The device’s category has the Allow All Internet Traffic rule set (i.e., the IoT Specific Sites rule is not set). The device will be permitted to connect to any internet location. (Y-3.b) The device’s category has the IoT Specific Sites rule set, indicating that there may be rules associated with specific makes and models of devices in this category that further restrict the internet locations to which those devices are able to initiate communications. (Y-3.b.1) There are (south to north) rules associated with the device’s make and model, so the device will be allowed to initiate communications with the internet sites permitted by those rules but prohibited from initiating communications to all other internet sites. (Y-3.b.2) There are no (south to north) rules associated with a device’s make and model, so that device will be allowed to initiate communications with all internet sites. |
Description |
Verify that once a device has been categorized, the device will be able to initiate communications to internet sites as constrained by any south-to-north rules that may be in place on the router that pertain to the device’s make and model. In particular:
|
Associated Exercises |
N/A |
Associated Cybersecurity Framework Subcategory(ies) |
ID.AM-3, ID.AM-4, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-5 |
IoT Device(s) Used |
|
Policy Used |
In the Yikes! UI, the Smart Appliances and Cell Phone internet rule is set to IoT Specific Sites. On the router, one ACL rule applies to the Raspberry Pi that permits it to visit www.getyikes.com and www.osmud.org, but there are no device-specific rules that apply to cell phones. On the router, there are no rules that apply to iPhone 7 devices. In the Yikes! UI, the Computer internet rule is set to Allow All Internet Traffic rather than to IoT Specific Sites. |
Preconditions |
The Smart Appliance, Cell Phone, and Computer category rules in the Yikes! UI and the ACL rules on the router are configured as described in the policy row above. (The presence of the Smart Appliances, Cell Phone, and Computer category rules can be verified by accessing the Yikes! UI. Using the UI, we should also be able to see the fully qualified domain names [FQDNs] of the sites that the rules permit each make and model of connected appliance and cell phone to access if any exist. The presence of the ACL rules can be verified only by logging in to the router.) |
Procedure |
|
Demonstrated Results |
Cell phone access is permitted and prohibited as expected in the procedure steps above. Computer access is permitted as expected. Procedure 1: Computers
Cell Phones
Smart Appliances
Procedure 2:
Procedure 3: Smart Appliance Yikes! approved communication: pi@yikes-iot-sites:~ $ wget https://osmud.org
--2019-07-29 10:28:56-- https://osmud.org/
Resolving osmud.org (osmud.org)... 198.71.233.87
Connecting to osmud.org (osmud.org)|198.71.233.87|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html.1’
index.html.1 [ <=> ] 24.12K --.-KB/s in 0.02s
2019-07-29 10:28:58 (1.30 MB/s) - ‘index.html.1’ saved [24697]
pi@yikes-iot-sites:~ $ wget https://getyikes.com
--2019-07-29 10:29:05-- https://getyikes.com/
Resolving getyikes.com (getyikes.com)... 54.213.16.153
Connecting to getyikes.com (getyikes.com)|54.213.16.153|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 15759 (15K) [text/html]
Saving to: ‘index.html.2’
index.html.2 100%[===================>] 15.39K --.-KB/s in 0.1s
2019-07-29 10:29:06 (119 KB/s) - ‘index.html.2’ saved [15759/15759]
Yikes! unapproved communication: pi@yikes-iot-sites:~ $ wget https://www.google.com
--2019-07-29 10:29:29-- https://www.google.com/
Resolving www.google.com (www.google.com)... 74.125.136.99,
74.125.136.103, 74.125.136.106, ...
Connecting to www.google.com (www.google.com)|74.125.136.99|:443...
failed: Connection refused.
Connecting to www.google.com (www.google.com)|74.125.136.103|:443...
failed: Connection refused.
Connecting to www.google.com (www.google.com)|74.125.136.106|:443...
failed: Connection refused.
Connecting to www.google.com (www.google.com)|74.125.136.147|:443...
failed: Connection refused.
Connecting to www.google.com (www.google.com)|74.125.136.105|:443...
failed: Connection refused.
Connecting to www.google.com (www.google.com)|74.125.136.104|:443...
failed: Connection refused.
Connecting to www.google.com
(www.google.com)|2607:f8b0:4002:c06::6a|:443... failed: Network is
unreachable.
Procedure 4: Cell Phone
Procedure 5: Computers [mud@localhost ~]$ wget `www.google.com <http://www.google.com>`__
--2019-07-23 14:47:52-- http://www.google.com/
Resolving `www.google.com <http://www.google.com>`__
(`www.google.com <http://www.google.com>`__)... 172.217.164.68,
2607:f8b0:4002:c08::67
Connecting to `www.google.com <http://www.google.com>`__
(`www.google.com <http://www.google.com>`__)|172.217.164.68|:80...
connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html.13’
[ <=> ] 11,492 --.-K/s in
0.005s
2019-07-23 14:47:53 (2.30 MB/s) - ‘index.html.13’ saved [11492]
[mud@localhost ~]$ wget `osmud.org <http://osmud.org>`__
--2019-07-23 14:48:11-- http://osmud.org/
Resolving `osmud.org <http://osmud.org>`__
(`osmud.org <http://osmud.org>`__)... 198.71.233.87
Connecting to `osmud.org <http://osmud.org>`__
(`osmud.org <http://osmud.org>`__)|198.71.233.87|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://osmud.org/ [following]
--2019-07-23 14:48:11-- https://osmud.org/
Connecting to `osmud.org <http://osmud.org>`__
(`osmud.org <http://osmud.org>`__)|198.71.233.87|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html.14’
[ <=> ] 24,697 --.-K/s in
0.009s
2019-07-23 14:48:11 (2.73 MB/s) - ‘index.html.14’ saved [24697]
[mud@localhost ~]$ wget `getyikes.com <http://getyikes.com>`__
--2019-07-23 14:48:36-- http://getyikes.com/
Resolving `getyikes.com <http://getyikes.com>`__
(`getyikes.com <http://getyikes.com>`__)... 54.213.16.153
Connecting to `getyikes.com <http://getyikes.com>`__
(`getyikes.com <http://getyikes.com>`__)|54.213.16.153|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://getyikes.com/ [following]
--2019-07-23 14:48:36-- https://getyikes.com/
Connecting to `getyikes.com <http://getyikes.com>`__
(`getyikes.com <http://getyikes.com>`__)|54.213.16.153|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 15759 (15K) [text/html]
Saving to: ‘index.html.15’
100%[======================================>] 15,759 --.-K/s in
0.09s
2019-07-23 14:48:37 (180 KB/s) - ‘index.html.15’ saved [15759/15759]
|
As explained above, exercise YnMUD-3-v6 is identical to exercise YnMUD-3-v4 except that it uses IPv6 instead of IPv4.
3.2.4.4 Exercise YnMUD-4-v4¶
Table 3‑17: Exercise YnMUD-4-v4
Exercise Field |
Description |
|---|---|
Parent Capability |
(Y-4) Lateral (east-west) communications of the non-MUD-capable device to other devices on the local network are enforced according to the policy associated with the device’s category. |
Subrequirement(s) of Parent Capability to Be Demonstrated |
(Y-4.a) A rule associated with the device’s category permits the device to initiate communications with local devices in category X, but there is no such rule that permits the device to initiate communications with local devices in category Y. (Y-4.a.1) The device will be allowed to initiate communications to any local device that is in category X. (Y-4.a.2) The device will be prohibited from initiating communications to any local device that is in category Y. |
Description |
Verify that once a device has been identified and categorized, the communications that it initiates to other devices on the local network will be restricted according to the local network (east-west) rules in place for the device’s category. |
Associated Exercises |
YnMUD-1-v4 |
Associated Cybersecurity Framework Subcategory(ies) |
ID.AM-3, ID.AM-4, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-5 |
IoT Device(s) Used |
Same as for exercise YnMUD-1-v4 |
Policy Used |
In the Yikes! UI:
|
Preconditions |
Same as for exercise YnMUD-1-v4. In addition, the device category rules are as described in the policy row above (the presence of these rules can be verified by accessing the Yikes! UI). Add several devices to the Printer and Laptop categories. |
Procedure |
|
Demonstrated Results |
When using the scanning software on the phone and laptop, only the devices that we expected to see in the procedural steps above could be seen. Procedure 1: Completed; excluded for brevity Procedure 2:
Procedure 3:
Procedure 4:
Procedure 5: pi@my-controller-pi:~ $ wget 192.168.20.238
--2019-07-24 18:13:12-- http://192.168.20.238/
Connecting to 192.168.20.238:80... failed: Connection refused.
Procedure 6: Laptop to printer [mud@localhost ~]$ wget 192.168.20.232
--2019-07-24 13:44:14-- http://192.168.20.232/
Connecting to 192.168.20.232:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 277
Saving to: ‘index.html.17’
100%[======================================>] 277 --.-K/s in 0s
2019-07-24 13:44:14 (39.8 MB/s) - ‘index.html.17’ saved [277/277]
Laptop to Pi categorized as printer [mud@localhost ~]$ wget 192.168.20.117
--2019-07-24 14:03:29-- http://192.168.20.117/
Connecting to 192.168.20.117:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10701 (10K) [text/html]
Saving to: ‘index.html.18’
100%[======================================>] 10,701 --.-K/s in
0.001s
2019-07-24 14:03:29 (8.95 MB/s) - ‘index.html.18’ saved [10701/10701]
|
As explained above, exercise YnMUD-4-v6 is identical to exercise YnMUD-4-v4 except that it uses IPv6 instead of IPv4.
3.2.4.5 Exercise YnMUD-5-v4¶
Table 3‑18: Exercise YnMUD-5-v4
Exercise Field |
Description |
|---|---|
Parent Capability |
(Y-5) In response to threat information, all devices on the local network are prohibited from visiting specific domains and IP addresses. |
Subrequirement(s) of Parent Capability to Be Demonstrated |
(Y-5.a) Threat intelligence indicates a specific internet domain that should not be trusted. Devices are prohibited from initiating communications to the internet domain listed in the threat intelligence. In addition, they are prohibited from initiating communications to any other domains and IP addresses that are associated with the same threat campaign as this domain. |
Description |
Verify that when threat signaling information indicates that a specific domain is not safe, all devices on the local network will be restricted from initiating communications to that domain as well as to all other domains and IP addresses that are associated with the same threat campaign as this domain. |
Associated Exercises |
YnMUD-3-v4 |
Associated Cybersecurity Framework Subcategory(ies) |
ID.RA-2, ID.RA-3, PR.AC-3, PR.AC-4, PR.AC-5 |
IoT Device(s) Used |
Use the same non-MUD-capable devices as for exercise YnMUD-3-v4:
|
Policy Used |
Use the same (non-MUD) Yikes! router policy as for exercise YnMUD-3-v4, specifically: In the Yikes! UI, the Computer internet rule is set to Allow All Internet Traffic rather than to IoT Specific Sites. |
Preconditions |
Threat signaling is enabled. Threat signaling intelligence indicates that internet domain www.dangerousSite.org is dangerous and devices shall be prohibited from visiting it. It also associates www.dangerousSite1.org with the same threat campaign as www.dangerousSite.org, and these domains are associated with IP addresses XX.XX.XX.XX and YY.YY.YY.YY. In addition, the other preconditions are the same as for exercise YnMUD-3-v4, specifically: The Computer category internet rule in the Yikes! UI is set to Allow All Internet Traffic rather than to IoT Specific Sites. Therefore, the ACL rules on the router are configured to permit the laptop to send traffic to any site. |
Procedure |
|
Demonstrated Results |
With threat signaling enabled, the laptop is prohibited from initiating communications to domains flagged by threat signaling. Procedure 1: config defaults
option syn_flood 1
option input ACCEPT
option output ACCEPT
option forward REJECT
# Uncomment this line to disable ipv6 rules
# option disable_ipv6 1
config zone
option name lan
list network 'lan'
option input ACCEPT
option output ACCEPT
option log '1'
config zone
option name wan
list network 'wan'
list network 'wan6'
option input REJECT
option output ACCEPT
option forward REJECT
option masq 1
option mtu_fix 1
option log '1'
config forwarding
option src lan
option dest wan
# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
option name Allow-DHCP-Renew
option src wan
option proto udp
option dest_port 68
option target ACCEPT
option family ipv4
# Allow IPv4 ping
config rule
option name Allow-Ping
option src wan
option proto icmp
option icmp_type echo-request
option family ipv4
option target ACCEPT
config rule
option name Allow-IGMP
option src wan
option proto igmp
option family ipv4
option target ACCEPT
# Allow DHCPv6 replies
# see https://dev.openwrt.org/ticket/10381
config rule
option name Allow-DHCPv6
option src wan
option proto udp
option src_ip fc00::/6
option dest_ip fc00::/6
option dest_port 546
option family ipv6
option target ACCEPT
config rule
option name Allow-MLD
option src wan
option proto icmp
option src_ip fe80::/10
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family ipv6
option target ACCEPT
# Allow essential incoming IPv6 ICMP traffic
config rule
option name Allow-ICMPv6-Input
option src wan
option proto icmp
list icmp_type echo-request
list icmp_type echo-reply
list icmp_type destination-unreachable
list icmp_type packet-too-big
list icmp_type time-exceeded
list icmp_type bad-header
list icmp_type unknown-header-type
list icmp_type router-solicitation
list icmp_type neighbour-solicitation
list icmp_type router-advertisement
list icmp_type neighbour-advertisement
option limit 1000/sec
option family ipv6
option target ACCEPT
# Allow essential forwarded IPv6 ICMP traffic
config rule
option name Allow-ICMPv6-Forward
option src wan
option dest *
option proto icmp
list icmp_type echo-request
list icmp_type echo-reply
list icmp_type destination-unreachable
list icmp_type packet-too-big
list icmp_type time-exceeded
list icmp_type bad-header
list icmp_type unknown-header-type
option limit 1000/sec
option family ipv6
option target ACCEPT
config rule
option name Allow-IPSec-ESP
option src wan
option dest lan
option proto esp
option target ACCEPT
config rule
option name Allow-ISAKMP
option src wan
option dest lan
option dest_port 500
option proto udp
option target ACCEPT
# include a file with users custom iptables rules
config include
option path /etc/firewall.user
### EXAMPLE CONFIG SECTIONS
[Omitted for brevity] config rule
option enabled '1'
option target 'ACCEPT'
option src 'wan'
option proto 'tcp'
option dest_port '80'
option name 'AllowYikesAdminRemoteWeb'
config rule
option enabled '1'
option target 'ACCEPT'
option src 'wan'
option proto 'tcp'
option dest_port '22'
option name 'AllowYikesAdminRemoteSsh'
#
# Base OpenWRT firewall rules to force the local router to be the only DNS
server allowed.
# Note: This needs /etc/config/dhcp update to added the router IP
address as the primary DNS server
# See dhcp.q9sample.conf for an example of this configuration
#
config rule
option target 'ACCEPT'
option dest_port '53'
option name 'Quad9 DNS Allow'
option src 'lan'
option dest_ip '9.9.9.9'
option proto 'tcp udp'
option dest 'wan'
option family 'ipv4'
config rule
option enabled '1'
option src 'lan'
option name 'DNS BLOCK OTHER SERVERS'
option dest_port '53'
option target 'REJECT'
option proto 'tcp udp'
option dest 'wan'
# OSMUD start
#
# DO NOT EDIT THESE LINES. OSMUD WILL REPLACE WITH ITS CONFIGURATION
#
[Omitted for brevity] # OSMUD end
# AYIKES start
#
# DO NOT EDIT THESE LINES. AYIKES WILL REPLACE WITH ITS CONFIGURATION
#
# Begin YIKES ipset firewall declarations
[Omitted for brevity] Procedure 2: --2019-07-24 10:50:53-- http://www.google.com/
Resolving www.google.com (www.google.com)... 172.217.164.132,
2607:f8b0:4004:815::2004
Connecting to www.google.com (www.google.com)|172.217.164.132|:80...
connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html’
0K .......... . 45.5M=0s
2019-07-24 10:50:53 (45.5 MB/s) - ‘index.html’ saved [11462]
--2019-07-24 10:55:51-- https://osmud.org/
Resolving osmud.org (osmud.org)... 198.71.233.87
Connecting to osmud.org (osmud.org)|198.71.233.87|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html’
0K .......... .......... .... 2.58M=0.009s
2019-07-24 10:55:51 (2.58 MB/s) - ‘index.html’ saved [24697]
Procedures 3–4: $ ping www.dangerousSite.org
ping: cannot resolve www.dangerousSite.org: Unknown host
$ ping www.dangerousSite.org
PING www.dangerousSite.org(127.0.0.1): 56 data bytes
64 bytes from: icmp_seq=0 ttl=64 time=0.049 ms
64 bytes from: icmp_seq=1 ttl=64 time=0.073 ms
64 bytes from: icmp_seq=2 ttl=64 time=0.082 ms
64 bytes from: icmp_seq=3 ttl=64 time=0.139 ms
64 bytes from: icmp_seq=4 ttl=64 time=0.079 ms
64 bytes from: icmp_seq=5 ttl=64 time=0.072 ms
64 bytes from: icmp_seq=6 ttl=64 time=0.123 ms
64 bytes from: icmp_seq=7 ttl=64 time=0.073 ms
ç64 bytes from: icmp_seq=8 ttl=64 time=0.066 ms
^C
--- www.dangerousSite.org ping statistics ---
9 packets transmitted, 9 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.049/0.084/0.139/0.027 ms
$ ping www.dangerousSite1.org
ping: cannot resolve www.dangerousSite1.org: Unknown host
$ ping www.dangerousSite1.org
PING www.dangerousSite1.org (127.0.0.1): 56 data bytes
64 bytes from: icmp_seq=0 ttl=64 time=0.052 ms
64 bytes from: icmp_seq=1 ttl=64 time=0.073 ms
64 bytes from: icmp_seq=2 ttl=64 time=0.109 ms
64 bytes from: icmp_seq=3 ttl=64 time=0.064 ms
64 bytes from: icmp_seq=4 ttl=64 time=0.089 ms
^C
--- www.dangerousSite1.org ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.052/0.077/0.109/0.022 ms
Procedure 5: # Q9THREATRULES start
#
# DO NOT EDIT THESE LINES. Q9THRT WILL REPLACE WITH ITS CONFIGURATION
#
config ipset
option enabled 1
option name Q9TS-joyheat_comFD
option match dest_ip
option storage hash
option family ipv4
option external Q9TS-joyheat_comFD
config ipset
option enabled 1
option name Q9TS-joyheat_comTD
option match src_ip
option storage hash
option family ipv4
option external Q9TS-joyheat_comTD
config rule
option enabled '1'
option name 'Q9TS-joyheat_comFD'
option target REJECT
option src lan
option dest wan
option proto all
option family ipv4
option ipset Q9TS-joyheat_comFD
option src_ip any
config rule
option enabled '1'
option name 'Q9TS-joyheat_comTD'
option target REJECT
option src wan
option dest lan
option proto all
option family ipv4
option ipset Q9TS-joyheat_comTD
option dest_ip any
# Q9THREATRULES end
|
As explained above, exercise YnMUD-5-v6 is identical to exercise YnMUD-5-v4 except that it uses IPv6 instead of IPv4.
3.2.4.6 Exercise YnMUD-6-v4¶
Table 3‑19: Exercise YnMUD-6-v4
Exercise Field |
Description |
|---|---|
Parent Capability |
(Y-5) In response to threat information, all devices on the local network are prohibited from visiting specific domains and IP addresses. |
Subrequirement(s) of Parent Capability to Be Demonstrated |
(Y-5.b) Threat intelligence indicates a specific IP address that should not be trusted. Devices are prohibited from initiating communications to the IP address listed in the threat intelligence. In addition, they are prohibited from initiating communications to any other IP addresses and domains that are associated with the same threat campaign as this IP address. |
Description |
Verify that when threat signaling information indicates that a specific IP address (as opposed to domain) is not safe, all devices on the local network will be restricted from initiating communications to that IP address as well as to all other IP addresses and domains that are associated with the same threat campaign as this IP address. |
Associated Exercises |
YnMUD-3-v4 |
Associated Cybersecurity Framework Subcategory(ies) |
ID.RA-2, ID.RA-3, PR.AC-3, PR.AC-4, PR.AC-5 |
IoT Device(s) Used |
Use the same non-MUD-capable devices as for exercise YnMUD-3-v4:
|
Policy Used |
Use the same (non-MUD) Yikes! router policy as for exercise YnMUD-3-v4, specifically: In the Yikes! UI, the Computer internet rule is set to Allow All Internet Traffic rather than to IoT Specific Sites. |
Preconditions |
Threat signaling is enabled. Threat signaling intelligence indicates that IP address XX.XX.XX.XX is dangerous, and devices shall be prohibited from visiting it. It also associates IP address YY.YY.YY.YY with the same threat campaign as IP address XX.XX.XX.XX and these IP addresses are associated with domains www.dangerousSite.org and www.dangerousSite1.org. In addition, the other preconditions are the same as for exercise YnMUD-3-v4, specifically: The Computer category internet rule in the Yikes! UI is set to Allow All Internet Traffic rather than to IoT Specific Sites. Therefore, the firewall rules on the router are configured to permit the laptop to send traffic to any site. |
Procedure |
|
Demonstrated Results |
With threat signaling enabled, the laptop is prohibited from initiating communications to IP addresses flagged by threat signaling intelligence. Procedures 1–3: Completed; excluded for brevity Procedure 4: Laptop ping www.dangerousSite.org NCCoEs-MBP:results nccoe$ ping www.dangerousSite.org
PING www.dangerousSite.org (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.039 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.136 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.063 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.141 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.071 ms
^C
--- www.dangerousSite.org ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.039/0.090/0.141/0.041 ms
NCCoEs-MBP:results nccoe$
NCCoEs-MBP:results nccoe$ ping 192.60.252.130
PING 192.60.252.130 (192.60.252.130): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
^C
--- 192.60.252.130 ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss
NCCoEs-MBP:results nccoe$
Procedure 5: # Q9THREATRULES start
#
# DO NOT EDIT THESE LINES. Q9THRT WILL REPLACE WITH ITS CONFIGURATION
#
config ipset
option enabled 1
option name Q9TS-joyheat_comFD
option match dest_ip
option storage hash
option family ipv4
option external Q9TS-joyheat_comFD
config ipset
option enabled 1
option name Q9TS-joyheat_comTD
option match src_ip
option storage hash
option family ipv4
option external Q9TS-joyheat_comTD
config rule
option enabled '1'
option name 'Q9TS-joyheat_comFD'
option target REJECT
option src lan
option dest wan
option proto all
option family ipv4
option ipset Q9TS-joyheat_comFD
option src_ip any
config rule
option enabled '1'
option name 'Q9TS-joyheat_comTD'
option target REJECT
option src wan
option dest lan
option proto all
option family ipv4
option ipset Q9TS-joyheat_comTD
option dest_ip any
# Q9THREATRULES end
# OSMUD start
|
As explained above, exercise YnMUD-6-v6 is identical to exercise YnMUD-6-v4 except that it uses IPv6 instead of IPv4.
3.2.4.7 Exercise YnMUD-7-v4¶
Table 3‑20: Exercise YnMUD-7-v4
Exercise Field |
Description |
|---|---|
Parent Capability |
(Y-5) In response to threat information, all devices on the local network are prohibited from visiting specific domains and IP addresses. |
Subrequirement(s) of Parent Capability to Be Demonstrated |
(Y-5.c) Threat intelligence was received more than 24 hours prior, indicating domains and IP addresses that should not be trusted, and those domains and IP addresses were blocked by ACLs installed on the router. After 24 hours, these ACLs have been removed from the router. |
Description |
Verify that 24 or more hours after ACLs have been installed on the router as a result of threat signaling intelligence, those ACLs will be removed. |
Associated Exercises |
YnMUD-5-v4 and YnMUD-6-v4 |
Associated Cybersecurity Framework Subcategory(ies) |
ID.RA-2, ID.RA-3, PR.AC-3, PR.AC-4, PR.AC-5 |
IoT Device(s) Used |
Same as for tests YnMUD-5-v4 and YnMUD-6-v4 |
Policy Used |
Same as the policy used for tests YnMUD-3-v4, YnMUD-5-v4, and YnMUD-6-v4 |
Preconditions |
Threat signaling is enabled. Threat signaling intelligence indicates that www.dangerousSite.org, www.dangerousSite1.org, and IP addresses XX.XX.XX.XX and YY.YY.YY.YY are dangerous, and devices shall be prohibited from visiting them. |
Procedure |
Run test YnMUD-5-v4 and verify that the laptop is not permitted to access www.dangerousSite.org, www.dangerousSite1.org, and IP addresses XX.XX.XX.XX and YY.YY.YY.YY. Log on to the router and verify that ACLs have been installed on it prohibiting communication with www.dangerousSite.org, www.dangerousSite1.org, and IP addresses XX.XX.XX.XX and YY.YY.YY.YY. Let 24 hours elapse. Log on to the router and verify that the ACLs that had prohibited communication with www.dangerousSite.org, www.dangerousSite1.org, and IP addresses XX.XX.XX.XX and YY.YY.YY.YY are no longer there. |
Demonstrated Results |
ACL rules that had been installed as a result of threat signaling intelligence were removed after 24 hours. Procedure 1: Completed; see YnMUD-6-v4 Procedure 2: # Q9THREATRULES start
#
# DO NOT EDIT THESE LINES. Q9THRT WILL REPLACE WITH ITS CONFIGURATION
#
config ipset
option enabled 1
option name Q9TS-joyheat_comFD
option match dest_ip
option storage hash
option family ipv4
option external Q9TS-joyheat_comFD
config ipset
option enabled 1
option name Q9TS-joyheat_comTD
option match src_ip
option storage hash
option family ipv4
option external Q9TS-joyheat_comTD
config rule
option enabled '1'
option name 'Q9TS-joyheat_comFD'
option target REJECT
option src lan
option dest wan
option proto all
option family ipv4
option ipset Q9TS-joyheat_comFD
option src_ip any
config rule
option enabled '1'
option name 'Q9TS-joyheat_comTD'
option target REJECT
option src wan
option dest lan
option proto all
option family ipv4
option ipset Q9TS-joyheat_comTD
option dest_ip any
# Q9THREATRULES end
# OSMUD start
Procedure 4: root@OpenWrt:~# cat /etc/config/firewall
config defaults
option syn_flood 1
option input ACCEPT
option output ACCEPT
option forward REJECT
# Uncomment this line to disable ipv6 rules
# option disable_ipv6 1
config zone
option name lan
list network 'lan'
option input ACCEPT
option output ACCEPT
option log '1'
config zone
option name wan
list network 'wan6'
option input REJECT
option output ACCEPT
option forward REJECT
option masq 1
option mtu_fix 1
option log '1'
config forwarding
option src lan
option dest wan
# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
option name Allow-DHCP-Renew
option src wan
option proto udp
option dest_port 68
option target ACCEPT
option family ipv4
# Allow IPv4 ping
config rule
option name Allow-Ping
option src wan
option proto icmp
option icmp_type echo-request
option family ipv4
option target ACCEPT
config rule
option name Allow-IGMP
option src wan
option proto igmp
option family ipv4
option target ACCEPT
[Omitted for brevity] # Q9THREATRULES start
#
# DO NOT EDIT THESE LINES. Q9THRT WILL REPLACE WITH ITS CONFIGURATION**
#
# Q9THREATRULES end**
# OSMUD start
#
# DO NOT EDIT THESE LINES. OSMUD WILL REPLACE WITH ITS CONFIGURATION
#
[Omitted for brevity] # OSMUD end
# AYIKES start
#
# DO NOT EDIT THESE LINES. AYIKES WILL REPLACE WITH ITS CONFIGURATION
#
# Begin YIKES ipset firewall declarations
[Omitted for brevity] # AYIKES end
|
As explained above, exercise YnMUD-7-v6 is identical to exercise YnMUD-7-v4 except that it uses IPv6 instead of IPv4.
4 Build 3¶
Build 3 uses equipment and cloud resources from CableLabs. The CableLabs Micronets Gateway on the local network; a cloud-based micro-services layer that hosts various Micronets services (e.g., software-defined networking [SDN] controller, Micronets Manager, MUD manager, configuration micro-service, identity server [optional], and DHCP/DNS configuration services) and a mobile application are used to perform IoT device onboarding via the Wi-Fi Easy Connect protocol and to manage and enforce trust domains on the local network, as well as support MUD. (Note that another name for the Wi-Fi Easy Connect protocol is Device Provisioning Protocol [DPP]. Throughout the remainder of this document, we use the term DPP for conciseness.)
4.1 Evaluation of MUD-Related Capabilities¶
The functional evaluation that was conducted to verify that Build 3 conforms to the MUD specification was based on the Build-3-specific requirements listed in Table 4‑1.
4.1.1 Requirements¶
Table 4‑1: MUD Use Case Functional Requirements
Capability Requirement (CR)-ID |
Parent Requirement |
Subrequirement 1 |
Subrequirement 2 |
Test Case |
|---|---|---|---|---|
CR-1 |
The IoT DDoS example implementation shall include a mechanism for associating a device with a MUD file (e.g., by having the MUD-enabled IoT device emit a MUD file URL via DHCP, LLDP, or X.509 or by using some other mechanism to enable the network to associate a device with a MUD file). |
IoT-1-v4, IoT-11-v4 |
||
CR-1.a |
The device’s MUD file is located by using two items in the device’s bootstrapping information (which is encoded in its QR code): the information element and the public bootstrapping key. |
IoT-1-v4, IoT-11-v4 |
||
CR-1.a.1 |
The information element identifies a device vendor, and each vendor is assumed to have a well-known location for serving MUD files, so this element identifies the location of the device’s MUD file server. The public bootstrapping key of the device identifies the device’s MUD file. |
IoT-1-v4, IoT-11-v4 |
||
CR-2 |
The IoT DDoS example implementation shall include the capability for the MUD URL to be provided to a MUD manager. |
IoT-1-v4 |
||
CR-2.a |
The device bootstrapping information shall be sent to the DPP configurator as part of the device DPP onboarding request. |
IoT-1-v4 |
||
CR-2.a.1 |
The bootstrapping information (and, in particular, the information element and public bootstrapping key) are received at the DPP configurator. |
IoT-1-v4 |
||
CR-2.b |
The DPP configurator shall use the bootstrapping information to look up the MUD URL and send it to the MUD manager. |
IoT-1-v4 |
||
CR-2.b.1 |
The MUD manager shall receive the MUD URL. |
IoT-1-v4 |
||
CR-3 |
The IoT DDoS example implementation shall include a MUD manager that can request a MUD file and signature from a MUD file server. |
IoT-1-v4 |
||
CR-3.a |
The MUD manager shall use the GET method (RFC 7231) to request MUD and signature files (per RFC 7230) from the MUD file server and can validate the MUD file server’s TLS certificate by using the rules in RFC 2818. |
IoT-1-v4 |
||
CR-3.a.1 |
The MUD file server shall receive the https request from the MUD manager. |
IoT-1-v4 |
||
CR-3.b |
The MUD manager shall use the GET method (RFC 7231) to request MUD and signature files (per RFC 7230) from the MUD file server, but it cannot validate the MUD file server’s TLS certificate by using the rules in RFC 2818. |
IoT-2-v4 |
||
CR-3.b.1 |
The MUD manager shall drop the connection to the MUD file server. |
IoT-2-v4 |
||
CR-3.b.2 |
The MUD manager shall send locally defined policy to the gateway that handles whether to allow or block traffic to and from the MUD-enabled IoT device. |
IoT-2-v4 |
||
CR-4 |
The IoT DDoS example implementation shall include a MUD file server that can serve a MUD file and signature to the MUD manager. |
IoT-1-v4 |
||
CR-4.a |
The MUD file server shall serve the file and signature to the MUD manager, and the MUD manager shall check to determine whether the certificate used to sign the MUD file (signed using DER-encoded CMS [RFC 5652]) was valid at the time of signing, i.e., the certificate had not expired. |
IoT-1-v4 |
||
CR-4.b |
The MUD file server shall serve the file and signature to the MUD manager, and the MUD manager shall check to determine whether the certificate used to sign the MUD file was valid at the time of signing, i.e., the certificate had already expired when it was used to sign the MUD file. |
IoT-3-v4 |
||
CR-4.b.1 |
The MUD manager will not complete processing the MUD file. (The MUD file rules will not be applied.) |
IoT-3-v4 |
||
CR-4.b.2 |
The MUD manager shall apply locally defined policy to the gateway that handles whether to allow or block traffic to and from the MUD-enabled IoT device. |
IoT-3-v4 |
||
CR-5 |
The IoT DDoS example implementation shall include a MUD manager that can translate local network configurations based on the MUD file. |
IoT-1-v4 |
||
CR-5.a |
The MUD manager shall successfully validate the signature of the MUD file. |
IoT-1-v4 |
||
CR-5.a.1 |
The MUD manager, after validation of the MUD file signature, shall check for an existing MUD file and translate abstractions in the MUD file to gateway configurations. |
IoT-1-v4 |
||
CR-5.a.2 |
The MUD manager shall cache this newly received MUD file. |
IoT-10-v4 |
||
CR-5.b |
The MUD manager shall attempt to validate the signature of the MUD file, but the signature validation fails (even though the certificate that had been used to create the signature had not been expired at the time of signing, i.e., the signature is invalid for a different reason). |
IoT-4-v4 |
||
CR-5.b.1 |
The MUD manager shall cease processing the MUD file. |
IoT-4-v4 |
||
CR-5.b.2 |
The MUD manager shall send locally defined policy to the gateway that handles whether to allow or block traffic to and from the MUD-enabled IoT device. |
IoT-4-v4 |
||
CR-6 |
The IoT DDoS example implementation shall include a MUD manager that can configure the Micronets Gateway with ACLs that enforce the MUD file rules. |
IoT-1-v4 |
||
CR-6.a |
The MUD manager shall install ACLs on the Micronets Gateway. |
IoT-1-v4 |
||
CR-6.a.1 |
The gateway shall have been configured to enforce the route filter sent by the MUD manager. |
IoT-1-v4 |
||
CR-7 |
The IoT DDoS example implementation shall allow the MUD-enabled IoT device to communicate with approved internet services in the MUD file. |
IoT-5-v4 |
||
CR-7.a |
The MUD-enabled IoT device shall attempt to initiate outbound traffic to approved internet services. |
IoT-5-v4 |
||
CR-7.a.1 |
The gateway shall receive the attempt and shall allow the traffic to pass based on the filters from the MUD file. |
IoT-5-v4 |
||
CR-7.b |
An approved internet service shall attempt to initiate a connection to the MUD-enabled IoT device. |
IoT-5-v4 |
||
CR-7.b.1 |
The gateway shall receive the attempt and shall allow it to pass based on the filters from the MUD file. |
IoT-5-v4 |
||
CR-8 |
The IoT DDoS example implementation shall deny communications from a MUD-enabled IoT device to unapproved internet services (i.e., services that are denied by virtue of not being explicitly approved). |
IoT-5-v4 |
||
CR-8.a |
The MUD-enabled IoT device shall attempt to initiate outbound traffic to unapproved (implicitly denied) internet services. |
IoT-5-v4 |
||
CR-8.a.1 |
The gateway shall receive the attempt and shall deny it based on the filters from the MUD file. |
IoT-5-v4 |
||
CR-8.b |
An unapproved (implicitly denied) internet service shall attempt to initiate a connection to the MUD-enabled IoT device. |
IoT-5-v4 |
||
CR-8.b.1 |
The gateway shall receive the attempt and shall deny it based on the filters from the MUD file. |
IoT-5-v4 |
||
CR-8.c |
The MUD-enabled IoT device shall initiate communications to an internet service that is approved to initiate communications with the MUD-enabled device but not approved to receive communications initiated by the MUD-enabled device. |
IoT-5-v4 |
||
CR-8.c.1 |
The gateway shall receive the attempt and shall deny it based on the filters from the MUD file. |
IoT-5-v4 |
||
CR-8.d |
An internet service shall initiate communications to a MUD-enabled device that is approved to initiate communications with the internet service but that is not approved to receive communications initiated by the internet service. |
IoT-5-v4 |
||
CR-8.d.1 |
The gateway shall receive the attempt and shall deny it based on the filters from the MUD file. |
IoT-5-v4 |
||
CR-9 |
The IoT DDoS example implementation shall allow the MUD-enabled IoT device to communicate laterally with devices that are approved in the MUD file. |
IoT-6-v4 |
||
CR-9.a |
The MUD-enabled IoT device shall attempt to initiate lateral traffic to approved devices. |
IoT-6-v4 |
||
CR-9.a.1 |
The gateway shall receive the attempt and shall allow it to pass based on the filters from the MUD file. |
IoT-6-v4 |
||
CR-9.b |
An approved device shall attempt to initiate a lateral connection to the MUD-enabled IoT device. |
IoT-6-v4 |
||
CR-9.b.1 |
The gateway shall receive the attempt and shall allow it to pass based on the filters from the MUD file. |
IoT-6-v4 |
||
CR-10 |
The IoT DDoS example implementation shall deny lateral communications from a MUD-enabled IoT device to devices that are not approved in the MUD file (i.e., devices that are implicitly denied by virtue of not being explicitly approved). (Note that this assumes that when devices are onboarded, they are placed in separate micronets from other local devices with which they are not permitted to communicate. In practice, it means that for testing purposes, each device must be assigned to its own separate micronet.) |
IoT-6-v4 |
||
CR-10.a |
The MUD-enabled IoT device shall attempt to initiate lateral traffic to unapproved (implicitly denied) devices. |
IoT-6-v4 |
||
CR-10.a.1 |
The gateway shall receive the attempt and shall deny it based on the filters from the MUD file. |
IoT-6-v4 |
||
CR-10.b |
An unapproved (implicitly denied) device shall attempt to initiate a lateral connection to the MUD-enabled IoT device. |
IoT-6-v4 |
||
CR-10.b.1 |
The gateway shall receive the attempt and shall deny it based on the filters from the MUD file. |
IoT-6-v4 |
||
CR-11 |
If the IoT DDoS example implementation is designed such that its DHCP server does not act as a MUD manager and it forwards a MUD URL to a MUD manager, the DHCP server must notify the MUD manager of any corresponding change to the DHCP state of the MUD-enabled IoT device, and the MUD manager should remove the implemented policy configuration in the router/switch pertaining to that MUD-enabled IoT device. |
No test needed because the DHCP server does not forward the MUD URL to the MUD manager. |
||
CR-11.a |
The MUD-enabled IoT device shall explicitly release the IP address lease (i.e., it sends a DHCP release message to the DHCP server). |
N/A |
||
CR-11.a.1 |
The DHCP server shall notify the MUD manager that the device’s IP address lease has been released. |
N/A |
||
CR-11.a.2 |
The MUD manager should remove all policies associated with the disconnected IoT device that had been configured on the MUD PEP router/switch. |
N/A |
||
CR-11.b |
The MUD-enabled IoT device’s IP address lease shall expire. |
N/A |
||
CR-11.b.1 |
The DHCP server shall notify the MUD manager that the device’s IP address lease has expired. |
N/A |
||
CR-11.b.2 |
The MUD manager should remove all policies associated with the affected IoT device that had been configured on the MUD PEP router/switch. |
N/A |
||
CR-12 |
The IoT DDoS example implementation shall include a MUD manager that uses a cached MUD file rather than retrieve a new one if the cache-validity time period has not yet elapsed for the MUD file indicated by the MUD URL. The MUD manager should fetch a new MUD file if the cache-validity time period has already elapsed. |
IoT-10-v4 |
||
CR-12.a |
The MUD manager shall check if the file associated with the MUD URL is present in its cache and shall determine that it is. |
IoT-10-v4 |
||
CR-12.a.1 |
The MUD manager shall check whether the amount of time that has elapsed since the cached file was retrieved is less than or equal to the number of hours in the cache-validity value for this MUD file. If so, the MUD manager shall apply the contents of the cached MUD file. |
IoT-10-v4 |
||
CR-12.a.2 |
The MUD manager shall check whether the amount of time that has elapsed since the cached file was retrieved is greater than the number of hours in the cache-validity value for this MUD file. If so, the MUD manager may (but does not have to) fetch a new file by using the MUD URL received. |
IoT-10-v4 |
||
CR-13 |
The IoT DDoS example implementation shall ensure that for each rule in a MUD file that pertains to an external domain, the gateway will be configured with all possible instantiations of that rule, insofar as each instantiation contains one of the IP addresses to which the domain in that MUD file rule may be resolved when queried by the gateway. |
IoT-9-v4 |
||
CR-13.a |
The MUD file for a device shall contain a rule involving a domain that can resolve to multiple IP addresses when queried by the gateway. Flow rules for permitting access to each of those IP addresses will be inserted into the gateway for the device in question, and the device will be permitted to communicate with all of those IP addresses. |
IoT-9-v4 |
||
CR-13.a.1 |
IPv4 addressing is used on the network. |
IoT-9-v4 |
4.1.2 Test Cases¶
This section contains the test cases that were used to verify that Build 3 met the requirements listed in Table 4‑1.
4.1.2.1 Test Case IoT-1-v4¶
Table 4‑2: Test Case IoT-1-v4
Test Case Field |
Description |
|---|---|
Parent Requirements |
(CR-1) The IoT DDoS example implementation shall include a mechanism for associating a device with a MUD file URL (e.g., by having the MUD-enabled IoT device emit a MUD file URL via DHCP, LLDP, or X.509 or by using some other mechanism to enable the network to associate a device with a MUD file URL). (CR-2) The IoT DDoS example implementation shall include the capability for the MUD URL to be provided to a MUD manager. (CR-3) The IoT DDoS example implementation shall include a MUD manager that can request a MUD file and signature from a MUD file server. (CR-4) The IoT DDoS example implementation shall include a MUD file server that can serve a MUD file and signature to the MUD manager. (CR-5) The IoT DDoS example implementation shall include a MUD manager that can translate local network configurations based on the MUD file. (CR-6) The IoT DDoS example implementation shall include a MUD manager that can configure the Micronets Gateway with ACLs that enforce the MUD file rules. |
Testable Requirements |
(CR-1.a) The device’s MUD file is located by using two items in the device’s bootstrapping information (which is encoded in its QR code): the information element and the public bootstrapping key. (CR-1.a.1) The information element identifies a device vendor, and each vendor is assumed to have a well-known location for serving MUD files, so this element identifies the location of the device’s MUD file server. The public bootstrapping key of the device identifies the device’s MUD file. (CR-2.a) The device bootstrapping information shall be sent to the DPP configurator as part of the device DPP onboarding request. (CR-2.a.1) The bootstrapping information (and in particular the information element and public bootstrapping key) are received at the DPP configurator. (CR-2.b) The DPP configurator shall use the bootstrapping information to look up the MUD URL and send it to the MUD manager. (CR-2.b.1) The MUD manager shall receive the MUD URL. (CR-3.a) The MUD manager shall use the GET method (RFC 7231) to request MUD and signature files (per RFC 7230) from the MUD file server and can validate the MUD file server’s TLS certificate by using the rules in RFC 2818. (CR-3.a.1) The MUD file server shall receive the https request from the MUD manager. (CR-4.a) The MUD file server shall serve the file and signature to the MUD manager, and the MUD manager shall check to determine whether the certificate used to sign the MUD file (signed using DER-encoded CMS [RFC 5652]) was valid at the time of signing, i.e., the certificate had not expired. (CR-5.a) The MUD manager shall successfully validate the signature of the MUD file. (CR-5.a.1) The MUD manager, after validation of the MUD file signature, shall check for an existing MUD file and translate abstractions in the MUD file to gateway configurations. (CR-6.a) The MUD manager shall install ACLs on the Micronets Gateway. (CR-6.a.1) The gateway shall have been configured to enforce the route filter sent by the MUD manager. |
Description |
Shows that when a device that has a MUD file is onboarded to the network using DPP and that device’s bootstrapping information includes an information element value to indicate the location of the device’s manufacturer and a public bootstrapping key to indicate the device’s MUD file, the device will have its gateway automatically configured to enforce the route filtering that is described in the device’s MUD file, assuming the MUD file has a valid signature and is served from a MUD file server that has a valid TLS certificate. |
Associated Test Case(s) |
N/A |
Associated Cybersecurity Framework Subcategory(ies) |
ID.AM-1, ID.AM-2, ID.AM-3, PR.DS-5, DE.AE-1, PR.AC-4, PR.AC-5, PR.IP-1, PR.IP-3, PR.PT-3, PR.DS-2 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
nist-model-fe_northsouth.json |
Preconditions |
|
Procedure |
Verify that the gateway for the IoT device to be used in the test does not yet have any configuration settings installed with respect to the IoT device being used in the test. Also verify that the MUD file of the IoT device to be used is not currently cached at the MUD manager.
|
Expected Results |
The gateway has had its configuration changed, i.e., it has been configured to enforce the policies specified in the IoT device’s MUD file. ACLs are installed on the gateway to reflect MUD filtering rules. |
Actual Results |
Onboarding: Step 1–sign in to application:
Step 2–click READY TO SCAN on mobile application:
Step 3—click plus button on IoT device UI:
Step 4–QR code appears on IoT device UI:
Step 5–scan QR code from mobile application:
Step 6–input device information and click ONBOARD:
Step 7–device receives IP address:
Verify appropriate micronet created: {
"_id": "5ee7bf78ab3e8358c185e759",
"id": "subscriber-001",
"name": "Subscriber 001",
"ssid": "micronets-gw",
"gatewayId": "micronets-gw",
"micronets": [
{
"name": "Generic",
"class": "Generic",
"micronet-subnet-id": "Generic",
"trunk-gateway-port": "2",
"trunk-gateway-ip": "10.36.32.124",
"dhcp-server-port": "LOCAL",
"dhcp-zone": "10.135.1.0/24",
"ovs-bridge-name": "brmn001",
"ovs-manager-ip": "10.36.32.124",
"micronet-subnet": "10.135.1.0/24",
"micronet-gateway-ip": "10.135.1.1",
"connected-devices": [
{
"device-mac": "00:C0:CA:97:D1:1F",
"device-name": "Pi1-nm1",
"device-id": "463165abc19725aefffc39def13ce09b17167fba",
"device-openflow-port": "2",
"device-ip": "10.135.1.2"
}
],
"micronet-id": "2316794860"
}
],
"createdAt": "2020-06-15T18:35:36.968Z",
"updatedAt": "2020-06-16T18:04:06.636Z",
"__v": 0
}
View flow rules: Every 2.0s: sudo ovs-ofctl dump-flows brmn001 --names |
/opt/micronets-gw/bin/format-ofctl-dump
Tue Jun 16 15:23:00 2020
table=0 priority=500 n_packets=0
dl_dst=01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0 actions=drop
table=0 priority=500 n_packets=0
dl_src=01:00:00:00:00:00/01:00:00:00:00:00 actions=drop
table=0 priority=500 n_packets=0 icmp icmp_code=1 actions=drop
table=0 priority=450 n_packets=643 in_port=LOCAL actions=resubmit( 200)
table=0 priority=400 n_packets=1218
in_port="wlp2s0.2486" actions=resubmit( 100)
table=0 priority=400 n_packets=18 in_port=wlp2s0 actions=resubmit( 100)
table=0 priority=0 n_packets=2 actions=output:diagout1
table=100 priority=910 n_packets=0 ct_state=+rel+trk udp actions=LOCAL
table=100 priority=910 n_packets=1 ct_state=+est+trk udp actions=LOCAL
table=100 priority=910 n_packets=490 ct_state=-trk udp actions=ct(table=100)
table=100 priority=905 n_packets=0 ct_state=+est+trk tcp actions=LOCAL
table=100 priority=905 n_packets=0 ct_state=+rel+trk tcp actions=LOCAL
table=100 priority=905 n_packets=0 ct_state=-trk tcp actions=ct(table=100)
table=100 priority=900 n_packets=18 dl_type=0x888e actions=resubmit( 120)
table=100 priority=850 n_packets=137 ip
in_port="wlp2s0.2486" dl_src=00:c0:ca:97:d1:1f nw_dst=10.135.1.1 actions=resubmit( 120)
table=100 priority=815 n_packets=0 in_port="wlp2s0.2486"
dl_src=00:c0:ca:97:d1:1f dl_type=0x888e actions=resubmit( 120)
table=100 priority=815 n_packets=0 udp
in_port="wlp2s0.2486" dl_src=00:c0:ca:97:d1:1f tp_dst=67 actions=resubmit( 120)
table=100 priority=815 n_packets=352 arp
in_port="wlp2s0.2486" dl_src=00:c0:ca:97:d1:1f actions=resubmit( 120)
table=100 priority=810 n_packets=0 ip
in_port="wlp2s0.2486" dl_src=00:c0:ca:97:d1:1f nw_dst=10.135.1.1 actions=resubmit( 120)
table=100 priority=810 n_packets=0 ip
in_port="wlp2s0.2486" dl_src=00:c0:ca:97:d1:1f nw_dst=104.237.132.42 actions=resubmit( 120)
table=100 priority=810 n_packets=0 ip
in_port="wlp2s0.2486" dl_src=00:c0:ca:97:d1:1f nw_dst=198.71.233.87 actions=resubmit( 120)
table=100 priority=805 n_packets=103
in_port="wlp2s0.2486" dl_src=00:c0:ca:97:d1:1f actions=output:diagout1
table=100 priority=800 n_packets=0
in_port="wlp2s0.2486" dl_src=00:c0:ca:97:d1:1f actions=resubmit( 110)
table=100 priority=460 n_packets=0 in_port=wlp2s0
dl_type=0x888e actions=resubmit( 120)
table=100 priority=0 n_packets=0 actions=output:diagout1
[Omitted for length] Micronets Gateway and Micronets Manager logs verifying onboarding:
|
Overall Results |
Pass |
IPv6 is not supported in this implementation.
4.1.2.2 Test Case IoT-2-v4¶
Table 4‑3: Test Case IoT-2-v4
Test Case Field |
Description |
|---|---|
Parent Requirement |
(CR-3) The IoT DDoS example implementation shall include a MUD manager that can request a MUD file and signature from a MUD file server. |
Testable Requirement |
(CR-3.b) The MUD manager shall use the GET method (RFC 7231) to request MUD and signature files (per RFC 7230) from the MUD file server, but it cannot validate the MUD file server’s TLS certificate by using the rules in RFC 2818. (CR-3.b.1) The MUD manager shall drop the connection to the MUD file server. (CR-3.b.2) The MUD manager shall send locally defined policy to the gateway that handles whether to allow or block traffic to and from the MUD-enabled IoT device. |
Description |
Shows that if a MUD manager cannot validate the TLS certificate of a MUD file server when trying to retrieve the MUD file for a specific IoT device, the MUD manager will drop the connection to the MUD file server and configure the gateway according to locally defined policy regarding whether to allow or block traffic to the IoT device in question. |
Associated Test Case(s) |
IoT-11-v4 |
Associated Cybersecurity Framework Subcategory(ies) |
PR.AC-7 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
nist-model-fe_northsouth.json |
Preconditions |
|
Procedure |
Verify that the gateway for the IoT device to be used in the test does not yet have any configuration settings installed with respect to the IoT device being used in the test. Also verify that the MUD file of the IoT device to be used is not currently cached at the MUD manager.
|
Expected Results |
The gateway has had its configuration changed, i.e., it has been configured to permit the device to connect to the network and communicate without any MUD-based restrictions. |
Actual Results |
2020-02-20 14:54:42,699 micronets-mud-manager: INFO getMudInfo called
with: {'url':
'https://nccoe-mud-server.micronets.in/micronets-mud/nist-model-fe_sameman
ufacturer-to.json'}
2020-02-20 14:54:42,700 micronets-mud-manager: INFO getMUDFile:
url: https://nccoe-mud-server.micronets.in/micronets-mud/nist-model-fe_sam
emanufacturer-to.json
2020-02-20 14:54:42,703 micronets-mud-manager: INFO getMUDFile: mud
filepath for https://nccoe-mud-server.micronets.in/micronets-mud/nist-mod
el-fe_samemanufacturer-to.json:
/mud-cache-dir/nccoe-mud-server.micronets.in_micronets-mud_nist-model-fe_s
amemanufacturer-to.json...
2020-02-20 14:54:42,705 micronets-mud-manager: INFO getMUDFile:
RETRIEVING https://nccoe-mud-server.micronets.in/micronets-mud/nist-model-
fe_samemanufacturer-to.json
[2020-02-20 14:54:42,760] ERROR in app: Exception on request POST
/getMudInfo
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed
(_ssl.c:852)
|
Overall Results |
Pass |
IPv6 is not supported in this implementation.
4.1.2.3 Test Case IoT-3-v4¶
Table 4‑4: Test Case IoT-3-v4
Test Case Field |
Description |
|---|---|
Parent Requirement |
(CR-4) The IoT DDoS example implementation shall include a MUD file server that can serve a MUD file and signature to the MUD manager. |
Testable Requirement |
(CR-4.b) The MUD file server shall serve the file and signature to the MUD manager, and the MUD manager shall check to determine whether the certificate used to sign the MUD file was valid at the time of signing. It shall determine that the certificate had already expired when it was used to sign the MUD file. (CR-4.b.1) The MUD manager shall cease to process the MUD file. (CR-4.b.2) The MUD manager shall send locally defined policy to the gateway that handles whether to allow or block traffic to and from the MUD-enabled IoT device. |
Description |
Shows that if a MUD file server serves a MUD file with a signature that was created with an expired certificate, the MUD manager will cease processing the MUD file. |
Associated Test Case(s) |
IoT-11-v4 |
Associated Cybersecurity Framework Subcategory(ies) |
PR.DS-6 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
nist-model-fe_expiredcert.json |
Preconditions |
|
Procedure |
Verify that the gateway does not yet have any configuration settings installed with respect to the IoT device being used in the test. Verify that the gateway for the IoT device to be used in the test does not yet have any configuration settings installed with respect to the IoT device being used in the test. Also verify that the MUD file of the IoT device to be used is not currently cached at the MUD manager.
|
Expected Results |
The gateway has had its configuration changed, i.e., it has been configured to permit the device to connect to the network and communicate without any MUD-based restrictions. |
Actual Results |
Onboarding occurs as executed in Test Case IoT-1-v4. MUD manager logs: 2020-06-01T19:21:35.145932392Z [2020-06-01 19:21:35,145] 172.17.0.1:57652
POST /getMudInfo 1.0 500 62 4622
2020-06-01T19:21:35.151372716Z 2020-06-01 19:21:35,145 quart.serving: INFO
172.17.0.1:57652 POST /getMudInfo 1.0 500 62 4622
2020-06-01T19:27:14.779094064Z 2020-06-01 19:27:14,778 micronets-mud-manager:
INFO getMudInfo called with: {'url':
'https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_expiredcert.json'}
2020-06-01T19:27:14.779344473Z 2020-06-01 19:27:14,779 micronets-mud-manager:
INFO getMUDFile: url:
https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_expiredcert.json
2020-06-01T19:27:14.779669434Z 2020-06-01 19:27:14,779 micronets-mud-manager:
INFO getMUDFile: mud filepath for
https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_expiredcert.json:
/mud-cache-dir/nccoe-server2.micronets.net_micronets-mud_nist-model-fe_expiredcert.json...
2020-06-01T19:27:14.779893264Z 2020-06-01 19:27:14,779 micronets-mud-manager:
INFO getMUDFile: RETRIEVING
https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_expiredcert.json
2020-06-01T19:27:14.812317780Z 2020-06-01 19:27:14,811 micronets-mud-manager:
DEBUG Saved MUD
https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_expiredcert.json
to
/mud-cache-dir/nccoe-server2.micronets.net_micronets-mud_nist-model-fe_expiredcert.json
2020-06-01T19:27:14.812567930Z 2020-06-01 19:27:14,812 micronets-mud-manager:
INFO Attempting to retrieve MUD signature from
https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_expiredcert.p7s
2020-06-01T19:27:14.819022355Z 2020-06-01 19:27:14,818 micronets-mud-manager:
INFO Successfully retrieved MUD signature
https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_expiredcert.p7s
2020-06-01T19:27:14.819639326Z 2020-06-01 19:27:14,819 micronets-mud-manager:
INFO Saved MUD signature from
https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_expiredcert.p7s
to
/mud-cache-dir/nccoe-server2.micronets.net_micronets-mud_nist-model-fe_expiredcert.p7s
2020-06-01T19:27:14.827058362Z 2020-06-01 19:27:14,826 micronets-mud-manager:
DEBUG Signature validation command returned status 4 (Verification failure)
2020-06-01T19:27:14.827369362Z 2020-06-01 19:27:14,827 micronets-mud-manager:
INFO MUD signature validation FAILURE (MUD file
/mud-cache-dir/nccoe-server2.micronets.net_micronets-mud_nist-model-fe_expiredcert.json,
sig file
/mud-cache-dir/nccoe-server2.micronets.net_micronets-mud_nist-model-fe_expiredcert.p7s)
2020-06-01T19:27:14.827576822Z 2020-06-01 19:27:14,827 micronets-mud-manager:
INFO Signature failure details:
2020-06-01T19:27:14.827595112Z 140195888018560:error:2E099064:CMS
routines:cms_signerinfo_verify_cert:certificate verify
error:../crypto/cms/cms_smime.c:253:Verify error: certificate has
expired
2020-06-01T19:27:14.827599552Z
2020-06-01T19:27:14.830093744Z 2020-06-01 19:27:14,829 micronets-mud-manager:
INFO Returning status 400 for POST request for /getMudInfo:
https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_expiredcert.json
failed signature validation (via
https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_expiredcert.p7s):
Verification failure
2020-06-01T19:27:14.839997072Z [2020-06-01 19:27:14,839] 172.17.0.1:57716
POST /getMudInfo 1.0 400 248 61267
2020-06-01T19:27:14.840225902Z 2020-06-01 19:27:14,839 quart.serving: INFO
172.17.0.1:57716 POST /getMudInfo 1.0 400 248 61267
|
Overall Results |
Pass |
IPv6 is not supported in this implementation.
4.1.2.4 Test Case IoT-4-v4¶
Table 4‑5: Test Case IoT-4-v4
Test Case Field |
Description |
|---|---|
Parent Requirement |
(CR-5) The IoT DDoS example implementation shall include a MUD manager that can translate local network configurations based on the MUD file. |
Testable Requirement |
(CR-5.b) The MUD manager shall attempt to validate the signature of the MUD file, but the signature validation fails (even though the certificate that had been used to create the signature had not been expired at the time of signing, i.e., the signature is invalid for a different reason). (CR-5.b.1) The MUD manager shall cease processing the MUD file. (CR-5.b.2) The MUD manager shall send locally defined policy to the gateway that handles whether to allow or block traffic to and from the MUD-enabled IoT device. |
Description |
Shows that if the MUD manager determines that the signature on the MUD file it receives from the MUD file server is invalid, it will cease processing the MUD file and configure the gateway according to locally defined policy regarding whether to allow or block traffic to the IoT device in question. |
Associated Test Case(s) |
IoT-11-v4 |
Associated Cybersecurity Framework Subcategory(ies) |
PR.DS-6 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
nist-model-fe_invalidsig.json |
Preconditions |
|
Procedure |
Verify that the gateway does not yet have any configuration settings installed with respect to the IoT device being used in the test. Verify that the gateway for the IoT device to be used in the test does not yet have any configuration settings installed with respect to the IoT device being used in the test. Also verify that the MUD file of the IoT device to be used is not currently cached at the MUD manager.
|
Expected Results |
The gateway has had its configuration changed, i.e., it has been configured to permit the device to connect to the network and communicate without any MUD-based restrictions. |
Actual Results |
Onboarding occurs as executed in Test Case IoT-1-v4. MUD manager logs: 2020-06-01T19:39:06.642029549Z 2020-06-01 19:39:06,641 micronets-mud-manager:
INFO getMudInfo called with: {'url':
'https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_invalidsig
.json'}
2020-06-01T19:39:06.642269829Z 2020-06-01 19:39:06,642 micronets-mud-manager:
INFO getMUDFile: url:
https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_invalidsig.js
on
2020-06-01T19:39:06.642629430Z 2020-06-01 19:39:06,642 micronets-mud-manager:
INFO getMUDFile: mud filepath for
https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_invalidsig.js
on:
/mud-cache-dir/nccoe-server2.micronets.net_micronets-mud_nist-model-fe_invali
dsig.json...
2020-06-01T19:39:06.642873149Z 2020-06-01 19:39:06,642 micronets-mud-manager:
INFO getMUDFile: RETRIEVING
https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_invalidsig.js
on
2020-06-01T19:39:06.649721996Z 2020-06-01 19:39:06,649 micronets-mud-manager:
DEBUG Saved MUD
https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_invalidsig.js
on
to
/mud-cache-dir/nccoe-server2.micronets.net_micronets-mud_nist-model-fe_invali
dsig.json
2020-06-01T19:39:06.649979886Z 2020-06-01 19:39:06,649 micronets-mud-manager:
INFO Attempting to retrieve MUD signature from
https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_invalidsig.p7
s
2020-06-01T19:39:06.655804960Z 2020-06-01 19:39:06,655 micronets-mud-manager:
INFO Successfully retrieved MUD signature
https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_invalidsig.p7
s
2020-06-01T19:39:06.656470161Z 2020-06-01 19:39:06,656 micronets-mud-manager:
INFO Saved MUD signature from
https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_invalidsig.p7
s
to
/mud-cache-dir/nccoe-server2.micronets.net_micronets-mud_nist-model-fe_invali
dsig.p7s
2020-06-01T19:39:06.663617138Z 2020-06-01 19:39:06,663 micronets-mud-manager:
DEBUG Signature validation command returned status 4 (Verification failure)
2020-06-01T19:39:06.663920888Z 2020-06-01 19:39:06,663 micronets-mud-manager:
INFO MUD signature validation FAILURE (MUD file
/mud-cache-dir/nccoe-server2.micronets.net_micronets-mud_nist-model-fe_invali
dsig.json,
sig file
/mud-cache-dir/nccoe-server2.micronets.net_micronets-mud_nist-model-fe_invali
dsig.p7s)
2020-06-01T19:39:06.664095668Z 2020-06-01 19:39:06,663 micronets-mud-manager:
INFO Signature failure details:
2020-06-01T19:39:06.664105068Z 139636532962432:error:2E09A09E:CMS
routines:CMS_SignerInfo_verify_content:verification
failure:../crypto/cms/cms_sd.c:848:
2020-06-01T19:39:06.664108968Z 139636532962432:error:2E09D06D:CMS
routines:CMS_verify:content verify error:../crypto/cms/cms_smime.c:393:
2020-06-01T19:39:06.664112498Z
2020-06-01T19:39:06.664799219Z 2020-06-01 19:39:06,664 micronets-mud-manager:
INFO Returning status 400 for POST request for /getMudInfo:
https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_invalidsig.js
on
failed signature validation (via
https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_invalidsig.p7
s):
Verification failure
2020-06-01T19:39:06.674001717Z [2020-06-01 19:39:06,673] 172.17.0.1:57802
POST /getMudInfo 1.0 400 246 32530
2020-06-01T19:39:06.674199247Z 2020-06-01 19:39:06,673 quart.serving: INFO
172.17.0.1:57802 POST /getMudInfo 1.0 400 246 32530
|
Overall Results |
Pass |
IPv6 is not supported in this implementation.
4.1.2.5 Test Case IoT-5-v4¶
Table 4‑6: Test Case IoT-5-v4
Test Case Field |
Description |
|---|---|
Parent Requirement |
(CR-7) The IoT DDoS example implementation shall allow the MUD-enabled IoT device to communicate with approved internet services in the MUD file. (CR-8) The IoT DDoS example implementation shall deny communications from a MUD-enabled IoT device to unapproved internet services (i.e., services that are implicitly denied by virtue of not being explicitly approved). |
Testable Requirement |
(CR-7.a) The MUD-enabled IoT device shall attempt to initiate outbound traffic to approved internet services. (CR-7.a.1) The gateway shall receive the attempt and shall allow it to pass based on the filters from the MUD file. (CR-7.b) An approved internet service shall attempt to initiate a connection to the MUD-enabled IoT device. (CR-7.b.1) The gateway shall receive the attempt and shall allow it to pass based on the filters from the MUD file. (CR-8.a) The MUD-enabled IoT device shall attempt to initiate outbound traffic to unapproved (implicitly denied) internet services. (CR-8.a.1) The gateway shall receive the attempt and shall deny it based on the filters from the MUD file. (CR-8.b) An unapproved (implicitly denied) internet service shall attempt to initiate a connection to the MUD-enabled IoT device. (CR-8.b.1) The gateway shall receive the attempt and shall deny it based on the filters from the MUD file. (CR-8.c) The MUD-enabled IoT device shall initiate communications to an internet service that is approved to initiate communications with the MUD-enabled device but not approved to receive communications initiated by the MUD-enabled device. (CR-8.c.1) The gateway shall receive the attempt and shall deny it based on the filters from the MUD file. (CR-8.d) An internet service shall initiate communications to a MUD-enabled device that is approved to initiate communications with the internet service but that is not approved to receive communications initiated by the internet service. (CR-8.d.1) The gateway shall receive the attempt and shall deny it based on the filters from the MUD file. |
Description |
Shows that, upon connection to the network, a MUD-enabled IoT device used in the IoT DDoS example implementation has a gateway that is configured to enforce the route filtering that is described in the device’s MUD file with respect to communication with internet services. Further, it shows that the policies that are configured on the gateway with respect to communication with internet services will be enforced as expected, with communications that are configured as denied being blocked and communications that are configured as permitted being allowed. |
Associated Test Case(s) |
IoT-1-v4 |
Associated Cybersecurity Framework Subcategory(ies) |
ID.AM-3, PR.DS-5, PR.IP-1, PR.PT-3 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
nist-model-fe_northsouth.json |
Preconditions |
Test IoT-1-v4 has run successfully, meaning that the gateway has been configured to enforce the following policies for the IoT device in question (as defined in the MUD file in Section 4.1.3.): Note: Preconditions with strike-through are not applicable due to NAT.
|
Procedure |
Note: Procedure steps with strike-through were not tested due to NAT. As stipulated in the preconditions, just before this test, test IoT-1-v4 must have been run successfully.
|
Expected Results |
Each of the results that is listed as needing to be verified in procedure steps above occurs as expected. |
Actual Results |
Flow rules: Every 2.0s: sudo ovs-ofctl dump-flows brmn001 --names |
/opt/micronets-gw/bin/format-ofctl-dump Tue Jun 2 11:17:06 2020
table=0 priority=500 n_packets=0 dl_dst=01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0
actions=drop
table=0 priority=500 n_packets=0 dl_src=01:00:00:00:00:00/01:00:00:00:00:00
actions=drop
table=0 priority=500 n_packets=0 icmp icmp_code=1 actions=drop
table=0 priority=450 n_packets=7 in_port=LOCAL actions=resubmit( 200)
table=0 priority=400 n_packets=2 in_port=wlp2s0 actions=resubmit( 100)
table=0 priority=400 n_packets=33 in_port="wlp2s0.1861" actions=resubmit(100)
table=0 priority=0 n_packets=0 actions=output:diagout1
table=100 priority=910 n_packets=0 ct_state=+est+trk udp actions=LOCAL
table=100 priority=910 n_packets=0 ct_state=+rel+trk udp actions=LOCAL
table=100 priority=910 n_packets=9 ct_state=-trk udp actions=ct(table=100)
table=100 priority=905 n_packets=0 ct_state=+est+trk tcp actions=LOCAL
table=100 priority=905 n_packets=0 ct_state=+rel+trk tcp actions=LOCAL
table=100 priority=905 n_packets=0 ct_state=-trk tcp actions=ct(table=100)
table=100 priority=900 n_packets=2 dl_type=0x888e actions=resubmit( 120)
table=100 priority=850 n_packets=1 ip in_port="wlp2s0.1861"
dl_src=00:c0:ca:98:42:37 nw_dst=10.135.1.1 actions=resubmit( 120)
table=100 priority=815 n_packets=0 in_port="wlp2s0.1861"
dl_src=00:c0:ca:98:42:37 dl_type=0x888e actions=resubmit( 120)
table=100 priority=815 n_packets=10 arp in_port="wlp2s0.1861"
dl_src=00:c0:ca:98:42:37 actions=resubmit( 120)
table=100 priority=815 n_packets=2 udp in_port="wlp2s0.1861"
dl_src=00:c0:ca:98:42:37 tp_dst=67 actions=resubmit( 120)
table=100 priority=810 n_packets=0 ip in_port="wlp2s0.1861"
dl_src=00:c0:ca:98:42:37 nw_dst=10.135.1.1 actions=resubmit( 120)
table=100 priority=810 n_packets=0 ip in_port="wlp2s0.1861"
dl_src=00:c0:ca:98:42:37 nw_dst=52.89.85.207 actions=resubmit( 120)
table=100 priority=810 n_packets=0 ip in_port="wlp2s0.1861"
dl_src=00:c0:ca:98:42:37 nw_dst=54.191.221.118 actions=resubmit( 120)
table=100 priority=810 n_packets=0 ip in_port="wlp2s0.1861"
dl_src=00:c0:ca:98:42:37 nw_dst=54.201.49.86 actions=resubmit( 120)
table=100 priority=805 n_packets=20 in_port="wlp2s0.1861"
dl_src=00:c0:ca:98:42:37 actions=output:diagout1
table=100 priority=800 n_packets=0 in_port="wlp2s0.1861"
dl_src=00:c0:ca:98:42:37 actions=resubmit( 110)
table=100 priority=460 n_packets=0 in_port=wlp2s0 dl_type=0x888e
actions=resubmit( 120)
table=100 priority=0 n_packets=0 actions=output:diagout1
Procedure 2: pi@raspberrypi:~ $ wget https://www.cablelabs.com
--2020-06-02 09:19:56-- https://www.cablelabs.com/
Resolving www.cablelabs.com (www.cablelabs.com)... 52.89.85.207,
54.201.49.86, 54.191.221.118, ...
Connecting to www.cablelabs.com (www.cablelabs.com)|52.89.85.207|:443...
connected.
Procedure 6: pi@raspberrypi:~ $ wget https://www.facebook.com
--2020-06-02 09:55:06-- https://www.facebook.com/
Resolving www.facebook.com (www.facebook.com)... 31.13.66.35,
2a03:2880:f103:83:face:b00c:0:25de
Connecting to www.facebook.com (www.facebook.com)|31.13.66.35|:443... failed:
Connection timed out.
Connecting to www.facebook.com
(www.facebook.com)|2a03:2880:f103:83:face:b00c:0:25de|:443... failed: Network
is unreachable.
Procedure 7: $ ssh pi@10.135.1.2
ssh: connect to host 10.135.1.2 port 22: Operation timed out
|
Overall Results |
Pass |
IPv6 is not supported in this implementation.
4.1.2.6 Test Case IoT-6-v4¶
Table 4‑7: Test Case IoT-6-v4
Test Case Field |
Description |
|---|---|
Parent Requirement |
(CR-9) The IoT DDoS example implementation shall allow the MUD-enabled IoT device to communicate laterally with devices that are approved in the MUD file. (CR-10) The IoT DDoS example implementation shall deny lateral communications from a MUD-enabled IoT device to devices that are not approved in the MUD file (i.e., devices that are implicitly denied by virtue of not being explicitly approved). |
Testable Requirement |
(CR-9.a) The MUD-enabled IoT device shall attempt to initiate lateral traffic to approved devices. (CR-9.a.1) The gateway shall receive the attempt and shall allow it to pass based on the filters from the MUD file. (CR-9.b) An approved device shall attempt to initiate a lateral connection to the MUD-enabled IoT device. (CR-9.b.1) The gateway shall receive the attempt and shall allow it to pass based on the filters from the MUD file. (CR-10.a) The MUD-enabled IoT device shall attempt to initiate lateral traffic to unapproved (implicitly denied) devices. (CR-10.a.1) The gateway shall receive the attempt and shall deny it based on the filters from the MUD file. (CR-10.b) An unapproved (implicitly denied) device shall attempt to initiate a lateral connection to the MUD-enabled IoT device. (CR-10.b.1) The gateway shall receive the attempt and shall deny it based on the filters from the MUD file. |
Description |
Shows that, upon connection to the network, a MUD-enabled IoT device used in the IoT DDoS example implementation has its gateway automatically configured to enforce the route filtering that is described in the device’s MUD file with respect to communication with lateral devices. Further, it shows that the policies that are configured on the gateway with respect to communication with lateral devices will be enforced as expected, with communications that are configured as denied being blocked and communications that are configured as permitted being allowed. |
Associated Test Case(s) |
IoT-1-v4 |
Associated Cybersecurity Framework Subcategory(ies) |
ID.AM-3, PR.DS-5, PR.AC-5, PR.IP-1, PR.PT-3, PR.IP-3, PR.DS-3 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
nist-model-fe_controller_anyport.json, nist-model-fe_localnetwork_anyport.json, nist-model-fe_manufacturer1.json, nist-model-fe_manufacturer2.json, nist-model-fe_manufacturer-from.json, nist-model-fe_manufacturer-to.json, nist-model-fe_mycontroller.json, nist-model-fe_samemanufacturer.json, nist-model-fe_samemanufacturer-from.json, nist-model-fe_samemanufacturer-to.json |
Preconditions |
|
Procedure |
Note: Procedure steps with strike-through were not tested in this phase because ingress DACLs are not supported in this implementation. As stipulated in the preconditions, just before this test, test IoT-1-v4 must have been run successfully to onboard the other local devices. Note that when each device is onboarded, the user performing the onboarding must assign each device to its own separate micronet. Local-network (ingress): Initiate communications to the IoT device from anyhost-from for specific permitted service, and verify that this traffic is received at the IoT device.
|
Expected Results |
Each of the results that is listed as needing to be verified in the procedure steps above occurs as expected. |
Actual Results |
The numbering in this section correlates with the procedure steps above:
|
Overall Results |
Partial Pass. The gateway was configured to enforce all route filtering that is described in the device’s MUD file with respect to communication with lateral devices, with the exception of MUD rules that pertain to specific ports. At the time of this functional demonstration, Micronets did not yet support port-level flow rules. Therefore, the implementation we tested was not able to enforce any port-specific route filtering that is described in the device’s MUD file with respect to communication with lateral devices. If a MUD file rule permitted the device to communicate with a lateral host using only a specific port or ports, the Micronets implementation was observed to incorrectly permit the device to communicate to all ports of that permitted host, even though that communication should have been restricted to using only the specific port or ports specified in the MUD file. |
IPv6 is not supported in this implementation.
4.1.2.7 Test Case IoT-9-v4¶
Table 4‑8: Test Case IoT-9-v4
Test Case Field |
Description |
|---|---|
Parent Requirements |
(CR-13) The IoT DDoS example implementation shall ensure that for each rule in a MUD file that pertains to an external domain, the gateway will be configured with all possible instantiations of that rule, insofar as each instantiation contains one of the IP addresses to which the domain in that MUD file rule may be resolved when queried by the gateway. |
Testable Requirements |
(CR-13.a) The MUD file for a device shall contain a rule involving a domain that can resolve to multiple IP addresses when queried by the gateway. Flow rules for permitting access to each of those IP addresses will be inserted into the gateway for the device in question, and the device will be permitted to communicate with all of those IP addresses. |
Description |
Shows that if a domain in a MUD file rule resolves to multiple IP addresses when the address resolution is requested by the gateway, then
|
Associated Test Case(s) |
N/A |
Associated Cybersecurity Framework Subcatego-ry(ies) |
ID.AM-1, ID.AM-2, ID.AM-3, PR.DS-5, DE.AE-1, PR.AC-4, PR.AC-5, PR.IP-1, PR.IP-3, PR.DS-2 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
nist-model-fe_northsouth.json |
Preconditions |
|
Procedure |
|
Expected Results |
The gateway has had its configuration changed, i.e., it has been configured with ACLs that permit the IoT device to send data to multiple IP addresses (i.e., x1.x1.x1.x1, y1.y1.y1.y1, and z1.z1.z1.z1). The IoT device is permitted to send data to each of the servers at these addresses. |
Actual Results |
Flow rules: Every 2.0s: sudo ovs-ofctl dump-flows brmn001 --names |
/opt/micronets-gw/bin/format-ofctl-dump
Tue Jun 2 11:17:06 2020
table=0 priority=500 n_packets=0
dl_dst=01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0 actions=drop
table=0 priority=500 n_packets=0
dl_src=01:00:00:00:00:00/01:00:00:00:00:00 actions=drop
table=0 priority=500 n_packets=0 icmp icmp_code=1 ac-
tions=drop
table=0 priority=450 n_packets=7 in_port=LOCAL ac-
tions=resubmit( 200)
table=0 priority=400 n_packets=2 in_port=wlp2s0 ac-
tions=resubmit( 100)
table=0 priority=400 n_packets=33
in_port="wlp2s0.1861" actions=resubmit( 100)
table=0 priority=0 n_packets=0 actions=output:di-
agout1
table=100 priority=910 n_packets=0 ct_state=+est+trk
udp actions=LOCAL
table=100 priority=910 n_packets=0 ct_state=+rel+trk
udp actions=LOCAL
table=100 priority=910 n_packets=9 ct_state=-trk udp
actions=ct(table=100)
table=100 priority=905 n_packets=0 ct_state=+est+trk
tcp actions=LOCAL
table=100 priority=905 n_packets=0 ct_state=+rel+trk
tcp actions=LOCAL
table=100 priority=905 n_packets=0 ct_state=-trk tcp
actions=ct(table=100)
table=100 priority=900 n_packets=2 dl_type=0x888e ac-
tions=resubmit( 120)
table=100 priority=850 n_packets=1 ip
in_port="wlp2s0.1861" dl_src=00:c0:ca:98:42:37
nw_dst=10.135.1.1 actions=resubmit( 120)
table=100 priority=815 n_packets=0
in_port="wlp2s0.1861" dl_src=00:c0:ca:98:42:37
dl_type=0x888e actions=resubmit( 120)
table=100 priority=815 n_packets=10 arp
in_port="wlp2s0.1861" dl_src=00:c0:ca:98:42:37 actions=re-
submit( 120)
table=100 priority=815 n_packets=2 udp
in_port="wlp2s0.1861" dl_src=00:c0:ca:98:42:37 tp_dst=67 ac-
tions=resubmit( 120)
table=100 priority=810 n_packets=0 ip
in_port="wlp2s0.1861" dl_src=00:c0:ca:98:42:37
nw_dst=10.135.1.1 actions=resubmit( 120)
table=100 priority=810 n_packets=0 ip
in_port="wlp2s0.1861" dl_src=00:c0:ca:98:42:37
nw_dst=52.89.85.207 actions=resubmit( 120)
table=100 priority=810 n_packets=0 ip
in_port="wlp2s0.1861" dl_src=00:c0:ca:98:42:37
nw_dst=54.191.221.118 actions=resubmit( 120)
table=100 priority=810 n_packets=0 ip
in_port="wlp2s0.1861" dl_src=00:c0:ca:98:42:37
nw_dst=54.201.49.86 actions=resubmit( 120)
table=100 priority=805 n_packets=20
in_port="wlp2s0.1861" dl_src=00:c0:ca:98:42:37 actions=out-
put:diagout1
table=100 priority=800 n_packets=0
in_port="wlp2s0.1861" dl_src=00:c0:ca:98:42:37 actions=re-
submit( 110)
table=100 priority=460 n_packets=0 in_port=wlp2s0
dl_type=0x888e actions=resubmit( 120)
table=100 priority=0 n_packets=0 actions=output:di-
agout1
[Remaining flow rules omitted for brevity] All IP communication attempts: pi@raspberrypi:~ $ wget 52.89.85.207
--2020-06-02 10:10:18-- http://52.89.85.207/
Connecting to 52.89.85.207:80... connected.
HTTP request sent, awaiting response... 301 Moved Perma-
nently
Location: https://52.89.85.207:443/ [following]
--2020-06-02 10:10:18-- https://52.89.85.207/
Connecting to 52.89.85.207:443... connected.
pi@raspberrypi:~ $ wget 54.201.49.86
--2020-06-02 10:10:39-- http://54.201.49.86/
Connecting to 54.201.49.86:80... connected.
HTTP request sent, awaiting response... 301 Moved Perma-
nently
Location: https://54.201.49.86:443/ [following]
--2020-06-02 10:10:39-- https://54.201.49.86/
Connecting to 54.201.49.86:443... connected.
pi@raspberrypi:~ $ wget 54.191.221.118
--2020-06-02 10:10:46-- http://54.191.221.118/
Connecting to 54.191.221.118:80... connected.
HTTP request sent, awaiting response... 301 Moved Perma-
nently
Location: https://54.191.221.118:443/ [following]
--2020-06-02 10:10:47-- https://54.191.221.118/
Connecting to 54.191.221.118:443... connected.
|
Overall Result |
Pass |
IPv6 is not supported in this implementation.
4.1.2.8 Test Case IoT-10-v4¶
Table 4‑9: Test Case IoT-10-v4
Test Case Field |
Description |
|---|---|
Parent Requirements |
(CR-12) The IoT DDoS example implementation shall include a MUD manager that uses a cached MUD file rather than retrieve a new one if the cache-validity time period has not yet elapsed for the MUD file indicated by the MUD URL. The MUD manager should fetch a new MUD file if the cache-validity time period has already elapsed. |
Testable Requirements |
(CR-12.a) The MUD manager shall check if the file associated with the MUD URL is present in its cache and shall determine that it is. (CR-12.a.1) The MUD manager shall check whether the amount of time that has elapsed since the cached file was retrieved is less than or equal to the number of hours in the cache-validity value for this MUD file. If so, the MUD manager shall apply the contents of the cached MUD file. (CR-12.a.2) The MUD manager shall check whether the amount of time that has elapsed since the cached file was retrieved is greater than the number of hours in the cache-validity value for this MUD file. If so, the MUD manager may (but does not have to) fetch a new file by using the MUD URL received. |
Description |
Shows that, upon connection of a MUD-enabled IoT device, the gateway has already been configured to enforce the route filtering that is described in the cached MUD file for that device’s MUD URL, assuming that the amount of time that has elapsed since the cached MUD file was retrieved is less than or equal to the number of hours in the file’s cache-validity value. If the cache validity has expired for the respective file, the MUD manager should fetch a new MUD file from the MUD file server. |
Associated Test Case(s) |
N/A |
Associated Cybersecurity Framework Subcategory(ies) |
ID.AM-1, ID.AM-2, ID.AM-3, PR.DS-5, DE.AE-1, PR.AC-4, PR.AC-5, PR.IP-1, PR.IP-3, PR.DS-2, PR.PT-3 |
IoT Device(s) Under Test |
Raspberry Pi |
MUD File(s) Used |
nist-model-fe_mycontroller.json |
Preconditions |
|
Procedure |
Verify that the gateway does not yet have any configuration settings installed with respect to the IoT device being used in the test.
|
Expected Results |
The gateway has had its configuration changed, i.e., it has been configured to enforce the policies specified in the IoT device’s MUD file. The expected configuration should resemble the following details: Cache is valid (the MUD manager does NOT retrieve the MUD file from the MUD file server): Observing the MUD file server logs, notice that only one https Get method request for a MUD file goes out to the MUD file server. Within the next 24 hours, any additional devices onboarded using the same MUD file will not result in the MUD manager sending an https Get method request to the MUD file server to fetch a new MUD file. Cache is not valid (the MUD manager does retrieve the MUD file from the MUD file server): Observing the MUD file server logs, notice that the MUD manager fetches a new copy of the MUD file and signature when the cache does not contain the MUD file of interest. |
Actual Results |
IoT device initial onboarding event (no cache): 2020-06-11T19:37:17.244916385Z 2020-06-11 19:37:17,240 quart.serving: INFO
172.17.0.1:36502 POST /getFlowRules 1.0 200 322 8936
2020-06-11T19:45:43.446237642Z 2020-06-11 19:45:43,445 micronets-mud-manager:
INFO getMudInfo called with: {'url':
'https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_mycontroller
.json'}
2020-06-11T19:45:43.446488467Z 2020-06-11 19:45:43,446 micronets-mud-manager:
INFO getMUDFile: url:
https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_mycontroller.
json
2020-06-11T19:45:43.446804181Z 2020-06-11 19:45:43,446 micronets-mud-manager:
INFO getMUDFile: mud filepath for
https://nccoe-server2.micronets.net/micronets-mud/nist-model-fe_mycontroller.
json:
/mud-cache-dir/nccoe-server2.micronets.net_micronets-mud_nist-model-fe_mycont
roller.json...
2020-06-11T19:45:43.447009066Z 2020-06-11 19:45:43,446 micronets-mud-manager:
INFO getMUDFile: RETRIEVING
https://nccoe-server2.micronets.net/micronets-mud/\ nist-model-fe_mycontrol
ler.json
2020-06-11T19:45:43.518411072Z 2020-06-11 19 |