1. Golden Security Configuration#

1.1 Objective#

In this activity, you'll design an abstract intent-type for NSP used to apply node-level security configuration to all your networking devices. The general approach taken is different from NSP's product intent-types. The intent-type defined uses minimal input to apply security configuration to a device. The mapping logic is adjustable, so the same intent-type can be used across different router families and even different network operating systems.

The intent-type boilerplate is provided. You will be expected to make modifications by adding attributes or support for another NOS. To do this, the idea will be to first become acquainted with the base version of the intent-type, to then modify it for SR OS, make sure everything behaves as expected and finally to make it work in a similar way for SRLinux.

1.2 Tasks#

You should read these tasks from top-to-bottom before beginning the activity.

It is tempting to skip ahead but tasks may require you to have completed previous tasks before tackling them.

1.2.1 Task 0: Install VS Code and NSP Intent Manager extension#

For this activity, having VS Code with the NSP Intent Manager extension installed is essential. If you cannot install 3^rd party software on your laptop, don't worry you can just use your web-browser and connect to code-server.

Installation Steps:

1. Download and install Visual Studio Code.
2. Install the vsCode extension for Intent Manager.
3. Configure the vsCode extension to authenticate against the SReXperts NSP at nsp.srexperts.net using the credentials (username/password) provided to you.

1.2.2 Task 1: Create your own Golden Security Config intent-type#

Add a folder to your VS Code workspace to store intent-types. Open the context-menu for this folder, and select Create intent-type. Provide a unique name like security-config-group02, provide the author name and choose the device security template. Please adjust the name with the group, that has been assigned to you during the hackathon. A new folder called security-config-group02_v1 will be created. The folder contains the complete intent-type, while the context menu has the option to Upload intent-type to the connected NSP system.

Take yourself some time to study the intent-type folder and file structure and content. The intent-type follows a decomposed design, minimizing the touch-points to adjust the behavior. In consequence, most of the JavaScript code-base is static, and must not be changed by the intent developer.

The most important concept here are mappers, that can be found in intent-type-resources/mappers. Those are templates (using Apache FreeMarker) to translate the intent-model into the device model.

Explore what is contained in the mapper!

1.2.3 Task 2: Create/Deploy intents from WebUI#

• Create an intent for PE1, but don't deploy it yet to the network
• Run an audit to understand, which configuration would be rolled out
• Synchronize the intent to the network and check if the device config was updated
• Feel free to modify the device configuration via CLI and run audit/sync operations again

1.2.4 Task 3: Extend the intent-type with something small#

In this task, we explore how to add additional configuration to your intent-type to extend the coverage. The idea with this type of intent is that model-driven node configuration can be easily reused to populate the intent-type. This is exactly what we will try to do for model-driven SR OS nodes in this task.

Change your intent-type in such a way that it creates an additional entry 50 in the management-access-filter that explicitly accepts SNMP Traps (UDP 162 as both destination and source port). The resulting configuration in SR OS should be

configure {
    system {
        security {
            management-access-filter {
                ip-filter {
                    default-action accept
                    entry 50 {
                        match {
                            dst-port {
                                port 162
                            }
                            src-port {
                                port 162
                            }
                        }
                    }
                }
            }
        }
    }
}

    ...
    {
        "entry-id": 40,
        ...
    },
    {
        "entry-id": 50,
        "description": "Allow SNMP",
        "action": "accept",
        "match": {
            "protocol": "udp",
            "src-port": {
                "port": 162
            },
            "dst-port": {
                "port": 162
            },
            "mgmt-port": {
                "cpm": [null]
            }
        }
    },
    {
        "entry-id": 100,
        ...
    }
    ...

After making your changes in the intent-type, trigger an Audit of the intent from the WebUI. What result do you expect?

Synchronize either PE1, make sure that your changes in the intent-type are propagated correctly and verify the result on the node CLI.

1.2.5 Task 4: Extend the intent-type with something big#

For the previous task, a simple copy-and-paste of what was already in the intent with minor modifications was all that was needed to get the desired result. Kudos to you if you used a different approach already. In either case, a different approach will be required for this task.

The modification required in this task isn't based on existing content of the intent-type, rather requiring entirely new sections to be added to the SR OS.ftl file.

For this task, add basic cpm-filter functionality to your intent. This configuration is to be added (although feel free to add more of your own!)

configure {
    system {
        security {
            cpm-filter {
                default-action accept
                ip-filter {
                    entry 10 {
                        match {
                            protocol icmp
                        }
                        action {
                            accept
                        }
                    }
                    entry 20 {
                        match {
                            protocol tcp-udp
                        }
                        action {
                            accept
                        }
                    }
                }
            }
        }
    }
}

To help you with this task, rely on info json and pwc model-path from the SR OS MD-CLI or use the Model Driven Configurator to see what payloads it sends to approximate what you will need to add to SR OS.ftl.

Notice the presence of merge and replace operations in SR OS.ftl. The merging operation will add your configuration to the specified context and leave the existing configuration intact. Replacing the context will replace the existing context with your payload.

Using what you've seen so far, audit and synchronize the intents with your changes. Try to avoid locking yourself (or NSP) out of the router. Asking for help in case something unexpected happens is encouraged.

Enable the update-fault-tolerance configuration in the global BGP context to bring the configuration in line with Nokia's recommendation and once again align the router configuration.

1.2.6 Task 5: Extend the intent-type for SR Linux#

Completing this lab requires a magnum opus of sorts. If you've made it this far that means you are well-versed in SR OS as well as the intent principles we are using here. This intent-type is designed to allow simple onboarding of different NOSes. Having SR Linux available in the topology we would be amiss if we do not add coverage for it to our intent-type. As before, open your intent-type. In line with SR OS.ftl, it stands to reason that we will need a similar file for SR Linux. That might be SRL.ftl or SRLinux.ftl or SR Linux.ftl.

In the NSP WebUI or vsCode check for intent-type resources. There is a JavaScript file in the common directory called IntentHandler.mjs, which implements a class called IntentHandler. One method of this class is called getTemplateName which maps the device family to a template name.

Once you've determined the filename to use, create it as an empty file next to SR OS.ftl. A suggested SR Linux configuration to add (but, as before, feel free to use your own) is:

acl {
    acl-filter cpm type ipv4 {
        entry 470 {
            match {
                ipv4 {
                    protocol tcp
                }
                transport {
                    destination-port {
                        value 2200
                    }
                }
            }
        }
    }
    acl-filter cpm type ipv6 {
        entry 520 {
            match {
                ipv4 {
                    protocol tcp
                }
                transport {
                    destination-port {
                        value 2200
                    }
                }
            }
        }
    }
}
system {
    ssh-server mgmt {
        rate-limit 10
    }
    ftp-server {
        network-instance default {
            admin-state disable
        }
        network-instance mgmt {
            admin-state disable
        }
    }
}

Use what you've learned and populate SRLinux.ftl so this configuration will be applied. The first pointer to take into account here is that the equivalent of info json for SR Linux is info | as json, and this output modifier can be used in general. The second pointer is that the Model Driven Configurator knows which namespaces (or prefixes) to use, and this information is also freely available online.

Once complete, deploy the intent and confirm the changes are applied successfully.