Security

Local authentication uses PKI or usernames and passwords as authentication credentials to authenticate login attempts. The authentication credentials are local to each router, not to user profiles.

By default, local authentication is enabled. When one or more of the other security methods are enabled, local authentication is used in case it is configured as first method in the authentication order, or if other authentication methods are configured before local in the authentication order and fail.

Locally, usernames, public keys, and password management information can be configured. This is referred to as local authentication.

RADIUS is a client/server security protocol and software that enables remote access servers to communicate with a central server to authenticate dial-in users and authorize access to the requested system or service.

RADIUS allows administrators to maintain user profiles in a shared central database and provides better security, allowing a company to set up a policy that can be applied at a single administered network point.

Terminal Access Controller Access-Control System Plus (TACACS+) is an authentication protocol that allows a remote access server to forward a user login password to an authentication server, to determine whether access is allowed to a system. In contrast to RADIUS, which combines authentication and authorization, TACACS+ separates these operations.

Lightweight Directory Access Protocol (LDAP) can provide authentication, authorization, accounting (AAA) functionality, and can allow users to access the full virtualized data center and networking devices. SR OS currently supports LDAP provision of a centralized authentication method with public key management. The authentication method is based on SSH public keys or keyboard authentication (username, password).

Administrators can access networking devices with one private key; public keys are usually saved locally on the SSH server. Proper key management is not feasible with locally-saved public keys on network devices or on virtual machines, as this would result in hundreds of public keys distributed on all devices. LDAPv3 provides a centralized key management system that allows for secure creation and distribution of public keys in the network. Public keys can be remotely saved on the LDAP server, which makes key management much easier, as shown in Key management.

The administrator starts an SSH session through an SSH client using their private key. The SSH client for the authentication method sends a signature created with the user’s private key to the router. The router authenticates the signature using the user’s public key and gives access to the user. To access the public key, the router looks up the public key stored on the LDAP server and the public key stored locally. The order in which the public keys are looked up is defined by the authentication order. Communication between the router and the LDAP server should be secured with LDAP over SSL/TLS (LDAPS). After successfully opening a secured connection, LDAP returns a set of public keys that can be used by the router to verify the signature.

LDAP is integrated into the SR OS as an AAA protocol alongside existing AAA protocols, such as RADIUS and TACACS+. The AAA framework provides tools and mechanisms (such as method lists, server groups, and generic attribute lists) that enable an abstract and uniform interface to AAA clients, irrespective of the actual protocol used for communication with the AAA server.

The authentication functions are:

• public key authentication

  The client tries to SSH to the SR OS using public keys.

  Public keys can be stored locally or on the LDAP server and retrieved as needed to authenticate the user.

• password authentication (keyboard interactive)

  The LDAP server can be used for user authentication using keyboard interactive, as with simple username and password authentication.

SR OS supports two algorithms for user password hashing: bcrypt, which is the default algorithm, and PBKDF2. The PBKDF2 algorithm can use SHA2 (SHA-256) or SHA3 (SHA-512) for hashing.

Use the following command to configure the algorithm to hash all user passwords:

• MD-CLI

  configure system security user-params local-user password hashing

• classic CLI

  configure system security password hashing

When password hashing is configured, the following sequence of steps occurs at login:

1. The node checks the stored password and notes its hash algorithm.

2. The password entered by the user is hashed with the noted algorithm, and the node compares the hash with the stored user password hash.

3. If the entered and stored passwords are the same, and if the hash algorithm of the stored user password is different than the hash algorithm of the system password, the user is prompted to enter a new password two times to ensure the passwords match. The node stores this new password in the RAM, not in the system configuration file.

   To store the new password in the configuration file, an admin user must perform an admin save command. If the admin save command is not executed, on the next reboot the hash algorithm of the stored user password may be different than the system hash and the user must go through this process again from step 2.

After an upgrade to a software load that supports PBKDF2, the default password continues to be stored using the bcrypt algorithm. The following example describes the procedure to change the algorithm. In the example, the algorithm is changed to PBKDF2 and "User_name" can be any user.

1. User_name logs in and runs the hashing command to change the algorithm.

2. To save the algorithm change, an admin user performs an admin save command.

3. To store User_name’s password using PBKDF2, the admin user changes User_name’s password.

   From this point onward, any new user passwords or changes to existing user passwords are stored using PBKDF2.

Local authorization uses user profiles and user access information after a user is authenticated. The profiles and user access information specifies the actions the user is allowed to perform.

For more information, see Configuring local command authorization profiles.

RADIUS authorization grants or denies access permissions for a user. Permissions include the use of FTP, Telnet, SSH (SCP and SFTP), and console access. When granting Telnet, SSH (SCP and SFTP), and console access to the router, authorization can be used to limit user access to the CLI commands and files.

When a user has been authenticated using RADIUS (or another method), the router can be configured to perform authorization. The RADIUS server can be used to:

• download the user command authorization profile to the router

• send the profile name that the router should apply to the user (these profiles must be created on each router)

If RADIUS authentication is successful and no authorization is configured for the user on the RADIUS server, local (router) authorization is attempted, if configured using the authentication-order command.

When authorization is configured and profiles are downloaded to the router from the RADIUS server, the profiles are considered temporary configurations and are not saved when the user session terminates.

The temporary profiles are only downloaded if the user authenticates via RADIUS. RADIUS-based authorization is not supported for users who authenticate locally or via TACACS+.

The following table lists the supported authorization configurations.

When using authorization, maintaining a user database on the router is not required. Usernames can be configured on the RADIUS server. Usernames are temporary and are not saved in the configuration when the user session terminates. Temporary user login names and their associated passwords are not saved as part of the configuration.

TACACS+ command authorization operates in the following ways:

• All users who authenticate via TACACS+ use single common access controls and an authorization profile that is configured locally on the router. The use-default-template command must be enabled.

• Optionally, all commands that users attempt are sent to the TACACS+ server for authorization when the authorization command is enabled.

• Optionally, local priv-lvl-map configuration maps the privilege level provided by the TACACS+ server to locally configured command authorization profiles when the use-priv-lvl command is enabled.

• Optionally, Vendor-Specific Attributes (VSAs) defined on the TACACS+ server control file access. All other access controls are configured locally in the default user template.

To use a single common default command authorization profile to control command authorization for TACACS+ users, the TACACS+ default user template must be enabled and configured with a valid local profile. The local profile is then used for command authorization. TACACS+ authorization must be disabled.

Use the following commands to configure a single common local command profile called "default" for command authorization for all TACACS+ users:

• MD-CLI

  configure system security aaa remote-servers tacplus use-default-template
  configure system security aaa user-template user-template-name tacplus-default profile "default"
  delete configure system security aaa remote-servers tacplus authorization

• classic CLI

  configure system security tacplus use-default-template
  configure system security user-template tacplus_default profile "default"
  configure system security tacplus no authorization

When the authorization command is enabled without the use-priv-lvl command, each CLI command the user issues is sent to the TACACS+ server for authorization. The authorization request that SR OS sends contains the first word of the CLI command as the value for the TACACS+ cmd and all the following words as a cmd-arg. Quoted values are expanded so that the quotation marks are stripped off and the enclosed values are seen as one cmd or cmd-arg.

When the use-priv-lvl command is configured, the router maps the privilege level returned by the TACACS+ server to a local profile as configured under the priv-lvl-map command. Command authorization then uses the local profile. If the TACACS+ server does not return a privilege level, the router uses the local profile configured in the user-template for command authorization.

Authorization profiles can be configured to match commands in either classic CLI or MD-CLI format. Depending on the configuration, a match may succeed. Each entry in a profile can be formatted for the classic CLI or the MD-CLI.

Authorization checks are not performed by default for telemetry data. All configuration and state elements are available to authenticated telemetry subscriptions, with the exception of LI (Lawful Intercept) configuration and state elements, which are authorized separately based on the LI authorization configuration. Use the following command to control telemetry data authorization:

• MD-CLI

  configure system security aaa management-interface output-authorization telemetry-data

• classic CLI

  configure system security managment-interface output-authorization telemetry-data

The following table shows authorization and match hit based on the entry format configuration. This is true whether authorization is done using local user profiles or using an AAA server like TACACS+ or RADIUS.

The following table lists the authorization support using a local profile or an AAA server.

Accounting can be configured independently from RADIUS authorization and RADIUS authentication.

When enabled, RADIUS accounting sends command line accounting from the router to the RADIUS server on UDP port 1813 or TCP port 2083 with TLS. The server receives accounting requests and returns a response to the router indicating that it has successfully received the request. Each command issued on the router generates a record sent to the RADIUS server. The record identifies the user who issued the command and the timestamp. If no response is received in the time defined in the timeout parameter, the accounting request must be retransmitted until the configured retry count is exhausted. A trap is issued to alert the NMS (or trap receiver) that the server is unresponsive. The router issues the accounting request to the next configured RADIUS server (up to 5).

User passwords and authentication keys of any type are never transmitted as part of the accounting request.

The SR OS allows the administrator to configure the type of accounting record packet that is to be sent to the TACACS+ server when specified events occur on the device. The accounting record-type command option indicates whether TACACS+ accounting start and stop packets will be sent or just stop packets be sent. Start/stop messages are only sent for individual commands, not for the session.

The router checks the configuration to see if TACACS+ accounting is required for the particular event when:

• a user logs in to request access to the network using Telnet or SSH

• a user enters a command for which accounting command options are configured

• a system event occurs, such as a reboot or a configuration file reload

If TACACS+ accounting is required, then, depending on the accounting record type specified, the device sends a start packet to the TACACS+ accounting server that contains information about the event.

The TACACS+ accounting server acknowledges the start packet and records information about the event. When the event ends, the device sends a stop packet. The stop packet is acknowledged by the TACACS+ accounting server.

In addition to RADIUS and TACACS+ accounting, SR OS supports a set of log events dedicated to command accounting.

For the following log events related to command accounting, see the SR OS Log Events Guide:

• cli_user_io

• snmp_user_set

• cli_config_io

• cli_unauth_user_io

• cli_unauth_config_io

• md_cli_io

• md_cli_unauth_io

• netconf_auth

• netconf_unauth

• grpc_auth

• grpc_unauth

A trap is issued if a RADIUS server is unresponsive. An alarm is raised if RADIUS is enabled with at least one RADIUS server and no response is received to either accounting or user access requests from any server.

Periodic checks to determine whether the primary server is responsive again are performed. If a server is down, it will not be contacted for 5 minutes. If a login is attempted after 5 minutes, the server is contacted again. If a server has the health-check feature enabled and is unresponsive, the server status is checked every 30 seconds. Health check is enabled by default. When a service response is restored from at least one server, the alarm condition is cleared. Alarms are raised and cleared on the Nokia Fault Manager or other third-party fault management servers.

The servers are accessed in order from lowest to highest specified index (from 1 to 5) for authentication requests until a response from a server is received. A higher indexed server is only queried if no response is received from a lower indexed server. If a response from the server is received, no other server is queried.

Use the commands in the following context to define the authentication and authorization order shown in Security flow.

• MD-CLI

  configure system security user-params authentication-order

• classic CLI

  configure system security password authentication-order

The order is determined by specifying the sequence in which an authentication or authorization method is attempted when the exit-on-reject command option is disabled.

Authentication and authorization method flow

Security flow shows an example that uses the order of RADIUS, then TACACS+, and finally, local. A request is sent to RADIUS server 1. If there is no response from the server, the request is sent to the next RADIUS server and so on, until the last RADIUS server is attempted (RADIUS server 5). If server 5 does not respond, the request is sent to TACACS+ server 1. If there is no response from that server, the request is sent to the next TACACS+ server, and so on.

If a request is sent to an active RADIUS server and the username and password are not recognized, access is denied and the next method is attempted, in this case, the TACACS+ server. The process continues until the request is either permitted, denied, or each server is queried. Finally, if the request is denied by the active TACACS+ server, the local method is attempted. This is the last chance for the access request to be permitted.

Use the commands in the following context to configure the three different CPM filter policies: ip-filter, ipv6-filter, and mac-filter.

configure system security cpm-filter

The following are the CPM filter packet match rules:

• Each CPM filter policy is an ordered list of entries. Entries must be sequenced correctly from the most explicit to the least explicit.

• If multiple match criteria are specified in a single CPM filter policy entry, all criteria must be met for the packet to be considered a match against that policy entry (logical AND).

• Any match criteria not explicitly defined is ignored during a match.

• A CPM filter policy entry defined without any match criteria is inactive.

• A CPM filter policy entry with match criteria defined, but no action configured, inherits the default action defined at the cpm-filter level.

• The cpm-filter default-action applies to IPv4, IPv6, or MAC CPM filters that are in an administratively enabled state.

• When mac-filter, ip-filter, and ipv6-filter are applied to a specific packet, the mac-filter is applied first.

The supported IPv4 and IPv6 match criteria types are shown in the following tables.

Basic Layer 3 match criteria lists the basic Layer 3 match criteria.

IPv4 options match criteria lists the IPv4 options match criteria.

IPv6 next-header match criteria lists the IPv6 next-header match criteria.

Upper-layer protocol match criteria lists the upper-layer protocol match criteria.

Router instance match criteria lists the router instance match criteria.

The MAC match criteria are evaluated against the Ethernet header of the Ethernet frame.

Router instance match criteria lists the router instance match criteria.

The two main CPM filter actions allow the option to accept or drop traffic.

Optionally, traffic can be sent to a user-configured hardware queue using a CPM filter. Nokia recommends this primarily for temporary debug or attack investigation activities.

For more information, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide, "Filter policy" and "Filter policy logging".

Nokia recommends using a strict CPM filter policy allowing traffic from trusted IP subnets for protocols and ports actively used in the router and to explicitly drop other traffic.

Protocols and ports identifies which ports are used by which applications in the SR OS. The source port and destination port reflect the CPM filter entry configuration for traffic ingressing the router and sent to the CPM.

Protocol protection allows traffic to be discarded for protocols not configured on the router. This helps mitigate DoS attacks by filtering invalid control traffic before it reaches the CPU. This is a feature of CPU Protection and can be enabled or disabled for the entire system.

When using the protocol-protection command, the system automatically maintains a per-interface list of configured protocols. For example, if an interface does not have IS-IS configured, then protocol protection discards any IS-IS packets received on that interface. Other protocols, such as L2TP, are controlled by the protocol protection at the VPRN service level.

Protocols controlled by the protocol-protection mechanism include:

• GTP

• IGMP

• IS-IS

• MLD

• L2TP control

• OSPFv2

• OSPFv3

• PPPoE

• PIM

• RIP

• PFCP

The following protocols are protected independently from protocol protection:

• The per-peer-queuing command protects BGP, LDP, T-LDP, MSDP, Telnet, and SSH.

• BFD control packets are dropped if BFD is not configured on a specific interface.

CPU protection supports the ability to explicitly limit the amount of ETH-CFM traffic that arrives at the CPU for processing. ETH-CFM packets that are redirected to the CPU by either a Management Endpoint (MEP) or a Management Intermediate Point (MIP) will be subject to the configured limit of the associated policy. Up to four CPU protection policies may include up to ten individual ETH-CFM-specific entries. The ETH-CFM entries allow the operator to apply a packet-per-second rate limit to the matching combination of level and opcode for ETH-CFM packet that are redirected to the CPU. Any ETH-CFM traffic that is redirected to the CPU by a Management Point (MP) that does not match any entries of the applied policy is still subject to the overall rate limit of the policy itself. Any ETH-CFM packets that are not redirected to the CPU are not subject to this function and are treated as transit data, subject to the applicable QoS policy.

The operator first creates a CPU policy and includes the required ETH-CFM entries. Overlap is allowed for the entries within a policy, first match logic is applied. This means ordering the entries in the correct sequence is important to ensure the correct behavior is achieved. Even though the number of ETH-CFM entries is limited to ten, the entry numbers have a valid range from 1 to 100 to allow for ample space to insert policies between one and other.

Ranges are allowed when configuring the level and the OpCode. Ranges provide the operator a simplified method for configuring multiple combinations. When more than one level or OpCode is configured in this manner the configured rate limit is applied separately to each combination of level and OpCode match criteria. For example, if the levels are configured as listed in Ranges versus levels and OpCodes, with a range of five (5) to seven (7) and the OpCode is configured for 3,5 with a rate of 1. That restricts all possible combinations on that single entry to a rate of 1 packet-per-second. In this example, six different match conditions are created.

When the policy is created, it must be applied to a SAP or binding within a service for these rates to take effect. This means the rate is on a per-SAP or per-binding basis. Only one policy may be applied to each SAP or binding. The eth-cfm-monitoring command must be configured in order for the ETH-CFM entries to be applied when the policy is applied to the SAP or binding. If this command is not configured, ETH-CFM entries in the policy are ignored. It is also possible to apply a policy to a SAP or binding by configuring the eth-cfm-monitoring command which does not have an MP. In this case, although these entries are enforced, no packets are redirected to the CPU.

By default, rates are applied on a per-peer basis. This means each individual peer is subject to the rate. Use the aggregate command to apply the rate to all peers. MIPs, for example, only respond to loopback messages and linktrace messages. These are typically on-demand functions and per-peer rate limiting is not required, making the aggregate function more appealing.

The eth-cfm-monitoring and mac-monitoring commands are mutually exclusive and cannot be configured on the same SAP or binding. The mac-monitoring command is used in combination with the traditional CPU protection and is not specific to ETH-CFM rate limiting feature described here.

When an MP is configured on a SAP or binding within a service which allows an external source to communicate with that MP, for example a User to Network Interface (UNI), eth-cfm-monitoring command with the aggregate command should be configured on all SAPs or bindings to provide the highest level of rate control.

The following example shows a policy configuration and the application of that policy to a SAP in a VPLS service configured with an MP. Policy 1 entry 10 limits all ETH-CFM traffic redirected to the CPU for all possible combinations to 1 packet-per-second. Policy 1 entry 20 limits all possible combinations to a rate of zero, dropping all request which match any combination. If entry 20 did not exist then only rate limiting of the entry 10 matches would occur and any other ETH-CFM packets redirected to the CPU would not be bound by a CPU protection rate.

[ex:/configure system security cpu-protection policy 1 eth-cfm]
A:admin@node-2# info
    entry 10 {
        pir 1
        level start 5 end 7 { }
        opcode start 3 end 3 { }
        opcode start 5 end 5 { }
    }
    entry 20 {
        pir 0
        level start 0 end 7 { }
        opcode start 0 end 255 { }
    }

[ex:/configure service vpls "10"]
A:admin@node-2# info
    sap 1/1/4:100 {
        admin-state enable
        cpu-protection {
            policy-id 1
            eth-cfm-monitoring {
                aggregate
            }
        }
        eth-cfm {
            mip primary-vlan none {
            }
        }
    }

A:node-2>config>sys>security>cpu-protection#
  policy 1 
    eth-cfm
      entry 10 level 5-7 opcode 3,5 rate 1
      entry 20 level 0-7 opcode 0-255 rate 0

A:node-2>config>service>vpls#
  sap 1/1/4:100
    cpu-protection 1 eth-cfm-monitoring aggregate
    eth-cfm 
      mip
    no shutdown

CPU protection provides a granular method to control which ETH-CFM packets are processed. As indicated in CPU protection extensions for ETH-CFM, a unique rate can be applied to ETH-CFM packets classifying on specific MD-level and a specific OpCode and applied to both ingress (down MEP and ingress MIP) and egress (up MEP and egress MIP) extraction. This function is to protect the CPU on extraction when a Management Point (MP) is configured.

It is also important to protect the ETH-CFM architecture deployed in the service provider network. This protection scheme varies from CPU protection. This model is used to prevent ETH-CFM frames at the service provider MD-levels from gaining access to the network even when extraction is not in place. ETH-CFM squelching drops all ETH-CFM packets at or below the configured MD-level. The ETH-CFM squelch feature is supported at ingress only.

ETH-CFM hierarchical model shows a typical ETH-CFM hierarchical model with a subscriber ME (6), test ME (5), EVC ME (4) and an operator ME (2). This model provides the necessary transparency at each level of the architecture. For security reasons, it may be necessary to prevent errant levels from entering the service provider network at the UNI, ENNI, or other untrusted interconnection points. Configuring squelching at level four on both UNI-N interconnection ensures that ETH-CFM packets matching the SAP or binding delimited configuration will silently discard ETH-CFM packets at ingress.

Squelching configuration uses a single MD-level (0 to 7) to silently drop all ETH-CFM packets matching the SAP or binding delimited configuration at or below the specified MD-level. In ETH-CFM hierarchical model, a squelch level is configured at MD-level 4. This means the configuration will silently discard MD-levels 0,1,2,3 and 4, assuming there is a SAP or binding match.

The operator is able to configure down MEPs and ingress MIPs that conflict with the squelched levels. This means that any existing MEP or MIP processing ingress CFM packets on a SAP or binding where a squelching policy is configured will be interrupted as soon as this command is entered into the configuration. These MPs are not able to receive any ingress ETH-CFM frames because squelching is processed before ETH-CFM extraction.

CPU protection extensions for ETH-CFM are still required in the model above because the subscriber ME (6) and the test ME (5) are entering the network across an untrusted connection, the UNI. ETH-CFM squelching and CPU protection for ETH-CFM can be configured on the same SAP or binding. Squelching is processed followed by CPU protection for ETH-CFM.

MPs configured to support primary VLANs are not subjected to the squelch function. Primary VLAN-based MPs, supported only on Ethernet SAPs, are extractions that take into consideration an additional VLAN beyond the SAP configuration.

The difference in the two protection mechanisms is shown in the CPU protection and squelching. CPU protection is used to control access to the CPU resources when processing is required. Squelching is required when the operator is protecting the ETH-CFM architecture from external sources.

show service service-id all
show service sap-using eth-cfm squelch-ingress-levels
show service sdp-using eth-cfm squelch-ingress-levels

=========================================================================
ETH-CFM Squelching
=========================================================================
PortId             SvcId      Squelch Level
-------------------------------------------------------------------------
6/1/1:100.*        1          0 1 2 3 4 5 6 7
lag-1:100.*        1          0 1 2 3 4 
6/1/1:200.*        2          0 1 2 
lag-1:200.*        2          0 1 2 3 4 5 
-------------------------------------------------------------------------
Number of SAPs: 4
------------------------------------------------------------------------- 

=========================================================================
ETH-CFM Squelching
=========================================================================
 SdpId              SvcId       Type Far End             Squelch Level 
-------------------------------------------------------------------------
12345:4000000000   2147483650   Spok 10.1.1.1            0 1 2 3 4   
=========================================================================  

The rate-limits are configured in the DCP policy using either static or dynamic policers and the action for the exceed-action policer command for non-conforming packets can be set to discard, low-priority, or none.

[ex:/configure system security dist-cpu-protection]
A:admin@node-2# info
    policy "_default-access-policy" {
        protocol all-unspecified {
            enforcement {
                static {
                    policer-name "access"
                }
            }
        }
        static-policer "access" {
            exceed-action {
                action discard
            }
            rate {
                packets {
                    limit 6000
                    within 1
                }
            }
        }
    }
    policy "_default-network-policy" {
        protocol all-unspecified {
            enforcement {
                static {
                    policer-name "network"
                }
            }
        }
        protocol bgp {
            enforcement {
                static {
                    policer-name "null"
                }
            }
        }
        protocol ldp {
            enforcement {
                static {
                    policer-name "null"
                }
            }
        }
        static-policer "network" {
            exceed-action {
                action low-priority
            }
            rate {
                packets {
                    limit 3000
                    within 1
                }
            }
        }
        static-policer "null" {
        }
    }

A:node-2>config>sys>security>dist-cpu-protection# info
------------------------------------------------
                policy "_default-access-policy" create
                    static-policer "access" create
                        rate packets 6000 within 1
                        exceed-action discard
                    exit
                    protocol all-unspecified create
                        enforcement static "access"
                    exit
                exit
                policy "_default-network-policy" create
                    static-policer "null" create
                    exit
                    static-policer "network" create
                        rate packets 3000 within 1
                        exceed-action low-priority
                    exit
                    protocol all-unspecified create
                        enforcement static "network"
                    exit
                    protocol bgp create
                        enforcement static "null"
                    exit
                    protocol ldp create
                        enforcement static "null"
                    exit
                exit
----------------------------------------------

configure card fp ingress dist-cpu-protection dynamic-enforcement-policer-pool

[ex:/configure system security dist-cpu-protection]
A:admin@node-2# info
    policy "dynamic-policy-example" {
        description "Dynamic policing policy"
        protocol arp {
            enforcement {
                dynamic {
                    mon-policer-name "local-mon"
                }
            }
            dynamic-parameters {
                exceed-action {
                    action discard
                }
                rate {
                    packets {
                        limit 20
                        within 10
                    }
                }
            }
        }
        protocol icmp {
            dynamic-parameters {
                exceed-action {
                    action discard
                }
                rate {
                    packets {
                        limit 20
                        within 10
                    }
                }
            }
        }
        protocol igmp {
            enforcement {
                dynamic {
                    mon-policer-name "local-mon"
                }
            }
            dynamic-parameters {
                exceed-action {
                    action discard
                }
                rate {
                    packets {
                        limit 20
                        within 10
                    }
                }
            }
        }
        protocol all-unspecified {
            enforcement {
                dynamic {
                    mon-policer-name "local-mon"
                }
            }
            dynamic-parameters {
                exceed-action {
                    action discard
                }
                rate {
                    packets {
                        limit 100
                        within 10
                    }
                }
            }
        }
        local-monitoring-policer "local-mon" {
            description "Monitor for arp, icmp, igmp, and all-unspecified"
            rate {
                packets {
                    limit 100
                    within 10
                }
            }
        }
    }

A:node-2>config>sys>security>dist-cpu-protection# info
------------------------------------------------
                policy "dynamic-policy-example" create
                    description "Dynamic policing policy"
                    local-monitoring-policer "local-mon" create
                        description "Monitor for arp, icmp, igmp and all-unspecified"
                        rate packets 100 within 10
                    exit
                    protocol arp create
                        enforcement dynamic "local-mon"
                        dynamic-parameters
                            rate packets 20 within 10
                            exceed-action discard
                        exit
                    exit
                    protocol icmp create
                        enforcement dynamic "local-mon"
                        dynamic-parameters
                            rate packets 20 within 10
                            exceed-action discard
                        exit
                    exit
                    protocol igmp create
                        enforcement dynamic "local-mon"
                        dynamic-parameters
                            rate packets 20 within 10
                            exceed-action discard
                        exit
                    exit
                    protocol all-unspecified create
                        enforcement dynamic "local-mon"
                        dynamic-parameters
                            rate packets 100 within 10
                            exceed-action discard
                        exit
                    exit
                exit
----------------------------------------------

For the access interface, most types of SAPs on Layer 2 and Layer 3 services are supported including capture SAPs, SAPs on pseudowires, B-VPLS SAPs, and VPLS template SAPs, but are not applicable to Epipe template SAPs and video ISA SAPs.

Control packets that are extracted in a VPRN service, where the packets arrived into the node through a VPLS SAP (that is, R-VPLS scenario), use the DCP policy and policer instances associated with the VPLS SAP. For VPLSs that have a Layer 3 interface bound to them, (R-VPLS), protocols such as OSPF and ARP may be configured in the DCP policy.

Control traffic that arrives on a network interface, but inside a tunnel (for example, SDP, LSP, PW) and logically terminates on a service (that is, traffic that is logically extracted by the service instead of the network interface layer itself) bypass the DCP function. The control packets are not subject to the DCP policy that is assigned to the network interface on which the packets arrived. This helps to avoid customer traffic in a service from impacting other services or the operator's infrastructure.

Log events are supported for DCP to alert the operator to potential attacks or misconfigurations. DCP throttles the rate of events to avoid event floods when multiple parallel attacks or problems. You can enable or disable log events individually at the DCP policy level, as well as globally in the system. Use the commands in the following context to enable logs globally:

• MD-CLI

  configure log log-events

• classic CLI

  configure log event-control

Use the following command to display the additional statistics for the packet exceed count and policer state.

show router interface dist-cpu-protection

Use tools commands, such as the following, to identify interface violators.

tools dump security dist-cpu-protection violators

For SNMP support, see the tables and MIB objects with ‟Dcp” or ‟DCpuProt” in their name. These can be found in the following MIBs:

• TIMETRA-CHASSIS-MIB

• TIMETRA-SECURITY-MIB

• TIMETRA-SAP-MIB

• TIMETRA-VRTR-MIB

The policer instances are a limited hardware resource on a specific forwarding plane. DCP policers (static, dynamic, local-monitor) are consumed from the overall forwarding plane policer resources (from the ingress resources if ingress and egress are partitioned). Each per-protocol policer instantiated reduces the number of FP child policers available for other purposes.

When DCP is configured with dynamic enforcement, then the operator must set aside a pool of policers that can be instantiated as dynamic enforcement policers. The number of policers reserved for this function are configurable per card or FP. The policers in this pool are not available for other purposes (normal SLA enforcement).

Static enforcement policers and local monitoring policers use policers from the normal or global policer pool on the card or FP. After a static policer is configured in a DCP policy and it is referenced by a protocol in the policy, this policer will be instantiated for each object (SAP or network interface) that is created and references the policy. If there is no policer free on the associated card or FP, then the object will not be created. Similarly, for local monitors, after a local monitoring policer is configured and referenced by a protocol, then this policer will be instantiated for each object that is created and references the policy. If there is no policer free, then the object will not be created.

Dynamic enforcement policers are allocated as needed (when the local monitor detects nonconformance) from the reserved dynamic enforcement policer pool.

When a DCP policy is applied to an object on a LAG, then a set of policers is allocated on each FP (on each line card that contains a member of the LAG). The LAG mode is ignored and the policers are always shared by all ports in the LAG on that forwarding plane on the SAP or interface. In other words, with link-mode lag a set of DCP policers are not allocated per-port in the LAG on the SAP.

To support large scale operation of DCP, and also to avoid overload conditions, a polling process is used to monitor state changes in the policers. This means there can be a delay between when an event occurs in the data plane and when the relevant state change or event notification occurs toward an operator, but in the meantime the policers are still operating and protecting the control plane.

The following points offer various optional guidelines that may help an operator decide how to leverage Distributed CPU Protection:

• The rates in a policy assigned to a capture SAP should be higher than those assigned to MSAPs that will contain a single subscriber. The rates for the capture sap policy should allow for a burst of MSAP setups.

• To completely block a set of specific protocols on a specific SAP, create a single static policer with a rate of 0 and map the protocols to that policer. Dynamic policers and local monitors cannot be used to simultaneously allow some protocols but block others (the non-zero rates in the monitor would allow all protocols slip through at a low rate).

• During normal operation it is recommended to configure ‟log-events” (no verbose keyword) for all static policers, in the dynamic parameters of all protocols and for all local monitoring policers. The verbose keyword can be used selectively during debug, testing, tuning, and investigations.

• Packet-based rate limiting is generally recommended for low-rate subscriber-based protocols whereas kb/s rate limiting is recommended for higher rate infrastructure protocols (such as BGP).

• It is recommended to configure an exceed-action of low-priority for routing and infrastructure protocols. Marked packets are more likely to be discarded if there is congestion in the control plane of the router, but will get processed if there is no contention for CPU resources allowing for a work-conserving behavior in the CPM.

• To assign a different distributed CPU protection policy to a specific MSAP instance or to all MSAPs for a specific MSAP policy, assign the new policy and then use one of the following tools commands:

  tools perform subscriber-mgmt eval-msap policy policy-name
  tools perform subscriber-mgmt eval-msap msap sap-id 

  Note: The new dist-cpu-protection policy is also assigned to new MSAPs.

• Use the following command if needed to determine which subscriber is on a specific MSAP and then filter (‟| match”) on the MSAP string.

  show service active-subs

• If protocol is trusted, and using the ‟all-unspecified” protocol is not required, then avoid referencing this protocol in the policy configuration.

• If a protocol is trusted, but the all-unspecified bucket is required, there are two options:

  • Avoid creating a protocol so that it is treated as part of the all-unspecified bucket (but account for the packets from X in the all-unspecified rate and local-mon rate).

  • Create this protocol and configure it to bypass.

You can configure three different management-access filter policies: IP filter, IPv6 filter, and MAC filter. Each policy is an ordered list of entries. For this reason, you must sequence the entries correctly from the most to the least explicit.

Management Access filter (MAF) packet match rules:

• Each MAF policy is an ordered list of entries, therefore entries must be sequenced correctly from the most to the least explicit.

• If multiple match criteria are specified in a single MAF filter policy entry, all criteria must be met for the packet to be considered a match against that policy entry (logical AND).

• Any match criteria not explicitly defined is ignored during a match.

• A MAF filter policy entry with match criteria defined, but no action configured, inherits the default action.

• The default action for the management-access-filter filter entry applies individually per IPv4, IPv6, or MAC CPM filter policies that are in an enabled state.

• When both mac-filter and ip-filter or ipv6-filter are applied to a specific packet, the mac-filter is applied first.

The following table lists the supported IPv4 and IPv6 match criteria.

Router instance match criteria describes the supported MAC match criteria. The criteria are evaluated against the Ethernet header of the Ethernet frame.

Management-access filter policies support the following traffic configuration actions:

• MD-CLI

  Supported actions are ignore-match, accept, drop, and reject.

• classic CLI

  Supported actions are permit, deny, and deny-host-unreachable.

Management access filter match count can be displayed using show commands. Logging is recorded in the system security logs.

The SSH server can support a public key authentication (also known as Public Key Infrastructure (PKI)), if the server was previously configured to know the client's public key.

Using PKI can be more secure than the existing username and password method for the following reasons.

• A user will typically reuse the same password with multiple servers. If the password is compromised, the user must reconfigure the password on all affected servers.

• A password is not transmitted between the client and server using PKI. Instead the sensitive information (private key) is kept on the client. Consequently, the password is less likely to be compromised.

SR OS supports server-sider SSHv2 PKI but does not include a key-generation utility.

Support for PKI should be configured in the system-level configuration, where one or more public keys may be bound to a username. This configuration will not affect any other system security or login functions.

PKI has preference over password or keyboard authentication. PKI is supported using local authentication and using an AAA server with LDAP only. PKI authentication is not supported on TACACS+ or RADIUS, and users with public keys always use local authentication only.

SR OS supports opening up to five channels per SSH connection. SSH channels can be used when an SSH connection has authenticated a user and a channel is opened for configuration while another channel is required to retrieve state information, such as collecting configurations or show command output. In this case, some network managers attempt to set up an additional channel in the existing SSH connection.

Opening a new channel inside an existing authenticated SSH connection mitigates the additional time and memory requirements for establishing a new SSH session. This mitigation is useful when, for example, multiple RPCs from different network manager users to the same device are executed at the same time.

SR OS supports a configurable server and client MAC list for SSHv2. This allows the user to add or remove MAC algorithms from the list. The user can program the strong Hash-based Message Authentication Code (HMAC) algorithms on top of the configurable MAC list (for example, lowest index in the list) to define the list order presented during algorithm negotiation between the client and server. The first algorithm supported by both the client and the server is selected.

There are two configurable MAC lists:

• server list

• client list

The default MAC list includes all supported algorithms in the following preference order:

1. mac 200 name hmac-sha2-512

2. mac 210 name hmac-sha2-256

3. mac 215 name hmac-sha1

4. mac 220 name hmac-sha1-96

5. mac 225 name hmac-md5

6. mac 240 name hmac-md5-96

SR OS supports the KEX client and server lists. The user can add or remove the needed KEX client or server algorithms to be negotiated using an SSHv2 phase one handshake. The list is an index list, with the lower index having a higher preference in the SSH negotiation. That is, the lowest indexed algorithm in the list is negotiated first in SSH and is at the top of the negotiation list to the peer.

When no KEX list entries are explicitly configured, the system behaves as if the following list is configured:

• kex 200 name diffie-hellman-group16-sha512
• kex 210 name diffie-hellman-group14-sha256
• kex 215 name diffie-hellman-group14-sha1
• kex 220 name diffie-hellman-group-exchange-sha1
• kex 225 name diffie-hellman-group1-sha1

As soon as an algorithm is configured in the KEX list, SR OS starts using the user-defined KEX list instead of the hard-coded list.

To go back to the hard-coded list, remove all configured KEX indexes until the list is empty. Use the following commands inline with the cipher, MAC server, or client lists:

• MD-CLI

  delete /configure system security ssh client-kex-list-v2
  delete /configure system security ssh server-kex-list-v2

• classic CLI

  configure system security ssh client-kex-list kex 
  configure system security ssh client-kex-list no kex
  configure system security ssh server-kex-list kex
  configure system security ssh server-kex-list no kex

SR OS supports periodic rollover of the SSH symmetric key. Symmetric key rollover is important in long SSH sessions. Symmetric key rollover ensures that the encryption channel between the client and server is not jeopardized by an external hacker that is trying to break the encryption via a brute force attack.

For extra security, the key re-exchange is enabled by default under SR OS.

SR OS supports cipher client and server lists. The user can add or remove the needed SSH cipher client or server algorithms from the negotiation list. The list is indexed with lower indexed algorithms having higher preference in the SSH negotiation. The lowest indexed algorithm in the list is negotiated first in SSH and is on top of the negotiation list to the peer.

The default server and client lists for SSHv2 include all supported algorithms with the following preference:

• cipher 190 name aes256-ctr

• cipher 192 name aes192-ctr

• cipher 194 name aes128-ctr

• cipher 200 name aes128-cbc

• cipher 205 name 3des-cbc

• cipher 225 name aes192-cbc

• cipher 230 name aes256-cbc

The SSH session closes automatically when the channel opened last in the session is closed.

The SSH keepalive intervals are disabled on SR OS, which means the following:

• The SR OS SSH server does not close the session when the client SSH keepalive intervals time out.
• The client SSH keepalive intervals cannot be used to keep the connection to the SR OS server open.

Support for SSH version 1 (SSHv1) has been removed from SR OS. The following considerations apply when upgrading from a pre-22.10 release.

An In-Service Software Upgrade (ISSU) conversion must be performed to filter previously existing ciphers and set the SSH version to 2. The customers using version 1 are switched to version 2 with default ciphers and HMAC algorithms. The default cipher set is auto-created.

The details of TCP-AO are described in the Authentication for TCP-based Routing and Management Protocols draft-bonica-tcp-auth-04.txt.

The following figure shows the packet format.

The following list describes the preceding fields:

• Kind (8 bits)

  The Kind field identifies the TCP-AO. This value is assigned by the Internet Assigned Numbers Authority (IANA).

• Length (8 bits)

  The Length field specifies the length of the TCP-AO, in octets. This count includes two octets representing the Kind and Length fields.

  The valid range for this field is from 4 to 40 octets, inclusive.

  For all algorithms specified in this memo, the value will be 16 octets.

• T-bit (1 bit)

  The T-bit specifies whether TCP options were omitted from the TCP header for the purpose of MAC calculation. A value of 1 indicates that all TCP options other than the Extended Authentication Option were omitted. A value of 0 indicates that TCP options were included.

  The default value is 0.

• K-bit (1 bit)

  This bit is reserved for future enhancement. Its value must be equal to zero.

• Alg ID (6 bits)

  The Alg ID field identifies the MAC algorithm.

• Res (2 bits)

  These bits are reserved and must be set to zero.

• Key ID (6 bits)

  The Key ID field identifies the key that was used to generate the message digest.

• Authentication Data (variable length)

  The Authentication Data field contains data that is used to authenticate the TCP segment. This data includes, but is not restricted to, a MAC. The length and format of the Authentication Data Field can be derived from the Alg ID.

The TCP-AO uses keychains that are associated with every protected TCP connection. The keychain concept is supported by the BGP, LDP, OSPF, IS-IS, and RSVP-TE protocols.

The keychain mechanism enables the creation of keys used to authenticate protocol communications. Each keychain entry defines the authentication attributes used in authenticating protocol messages from remote peers or neighbors. The configuration must include at least one key entry to be valid. Through the use of the keychain mechanism, authentication keys can be changed without affecting the state of the associated protocol adjacencies for BGP, LDP, OSPF, IS-IS, and RSVP-TE.

Each key within a keychain must include the following attributes for the authentication of protocol messages:

• key identifier – unique identifier, expressed as a decimal integer

• authentication algorithm – see Security algorithm support per protocol

• authentication key – key used by the authentication algorithm to authenticate packets

• direction – packet stream direction in which the key is applied (receive direction, send direction, or both)

• begin time – time at which a new authentication key can be used

Optionally, each key can include the following attributes:

• end time – time at which the authentication key becomes inactive (applies to received packets only)

• tolerance – period in which both old and new authentication key values can overlap and both keys are allowed on received packets (applies to received packets only)

The following table shows the mapping between these attributes and the CLI command to set them.

configure system security keychains keychain bidirectional entry
configure system security keychains keychain receive entry
configure system security keychains keychain send entry

configure system security keychain direction bi entry
configure system security keychain direction uni receive entry
configure system security keychain direction uni send entry

configure system security keychains keychain bidirectional entry algorithm
configure system security keychains keychain receive entry algorithm
configure system security keychains keychain send entry algorithm

configure system security keychain direction bi entry key algorithm
configure system security keychain direction uni receive entry key algorithm
configure system security keychain direction uni send entry key algorithm

configure system security keychains keychain bidirectional entry
configure system security keychains keychain receive entry 
configure system security keychains keychain send entry

configure system security keychain direction bi entry
configure system security keychain direction uni receive entry
configure system security keychain direction uni send entry

configure system security keychains keychain bidirectional entry begin-time
configure system security keychains keychain send entry begin-time

configure system security keychain direction bi entry begin-time
configure system security keychain direction uni send entry begin-time

configure system security keychains keychain bidirectional entry begin-time
configure system security keychains keychain bidirectional entry tolerance
configure system security keychains keychain receive entry begin-time
configure system security keychains keychain receive entry tolerance

configure system security keychain direction bi entry begin-time
configure system security keychain direction bi entry tolerance
configure system security keychain direction uni receive entry begin-time
configure system security keychain direction uni receive entry tolerance

configure system security keychains keychain receive entry end-time

configure system security keychain direction uni receive entry end-time

The following table lists the authentication algorithms that can be used in association with specific routing protocols.

Consider the following keychain configuration guidelines and behaviors:

• Use either the authentication-key command or the authentication-keychain command in the MD-CLI (auth-keychain command in the classic CLI) with the protocols. Both commands cannot be supported at the same time. If both commands are configured, the system applies the authentication-keychain configuration in the MD‑CLI (auth-keychain configuration in the classic CLI) and ignores the authentication-key command.

• A keychain cannot be referenced by a protocol until it has been configured.

• If a keychain is referenced by a protocol, the keychain cannot be deleted.

• If multiple keys in a keychain are valid at the same time, the newest key (key with the most current begin-time) is used.

• If a protocol sends a packet that is configured to use a keychain, the most current key from that keychain is used.

• If a protocol receives a packet that is configured to use a keychain, the current key set is returned to authenticate the received packet.

  • The key set includes the currently active keys (based on the current system time) and the begin or end time associated with each key in the specified keychain.

  • If a tolerance value is set for a key, the key is returned as part of the key set if the current time is within the begin time of the key, plus or minus the tolerance value. For example, if the begin-time is 12:00 p.m. and the tolerance is 600 seconds, the new key is included from 11:55 a.m. and the key to be replaced is included until 12:05 p.m.

• The end-time and tolerance command options apply only to received packets. Transmitted packets always use the newest key, regardless of the tolerance value.

• If a keychain exists but there are no active key entries with an authentication type that matches the type supported by the protocol, inbound protocol packets are not authenticated and are discarded, and no outbound protocol packets are sent.

• If a keychain exists but the last key entry has expired, a log entry is raised indicating that all keychain entries have expired.

• Special cases:
  • The OSPF and RSVP-TE protocols continue to authenticate inbound and outbound traffic using the last valid authentication key.
  • The IS-IS protocol does not revert to an unauthenticated state and requires that the old key is not used; therefore, when the last key has expired, all traffic is discarded.

Hash and hash2 use the AES-256 algorithm for all interfaces. However, hash2 uses module-specific text to make the hash unique per module or protocol. For example, BGP uses a different pre-pending text than IGP. This pre-pending text is appended to the key and then hashed using hash2.

In the classic CLI, hash has been changed to AES-256. Upgrade from DES to AES-256 is allowed and loading a config file in classic CLI with DES to a new software that supports AES-256 is also allowed.

The DES and the DES key should only be used for decryption of the old password to obtain clear text and the password should then be rehashed using AES-256. The few characters of the old hashed phrase are used to determine that the phrase is hashed using DES.

The cleartext option for the write algorithm displays the hash in clear text in the config file, info, info detail, and so on.

In addition to matching on command keywords, command authorization profiles allow matching on the values of command elements.

configure system security aaa local-profiles profile "service-ops" entry 10 match "configure service vprn <55>"

configure system security profile "service-ops" entry 10 match "configure service vprn <55>"

[ex:/configure system security aaa local-profiles profile "default"]
A:admin@node-2# info
    entry 10 {
        match "show router <22> route-table"
        action permit
    }
    entry 20 {
        match "configure service vprn <22>"
        action read-only
    }
    entry 30 {
        match "show service id <22>"
        action permit
    }
    entry 40 {
        match "configure router interface <system>"
        action deny
    }

A:node-2>config>system>security>profile# info
                entry 10
                    match "show router <22> route-table "
                    action permit
                exit
                entry 20
                    match "configure service vprn <22>"
                    action read-only
                exit
                entry 30
                    match "show service id <22>"
                    action permit
                exit
                entry 40
                    match "configure router interface <system>"
                    action deny
                exit

In addition to matching on specific values in command authorization profiles (see Matching on values in command authorization rules), wildcard matching is supported for matching against values in the following commands, when these commands are executed in the classic CLI engine:

• oam commands
• ping
• traceroute
• mtrace

For example, use the following command for wildcard matching on a value <.*>.

match "oam ancp subscriber <.*> loopback"

Wildcard value matching is particularly useful when you want to match on a string that contains multiple values, but you only want a specific match on one of the values. The following example shows a command authorization profile with a list of all the permitted IP addresses for ping in router 10.

match ping <10.0.0.1> router <10>
action permit
match ping <10.0.0.2> router <10>
action permit

match ping <.*> router <10> 
action permit

match ping <.*> router <.*> 
action permit

SR OS has the capability to manage Telnet/SSH sessions per user and at a higher level per system. At the system level, the user can configure a CLI-session group for different customer priorities. The cli-session-group command is a container that sets the maximum number of CLI sessions for a class of customers, with a unique session limit for each customer. For example, as shown in Classic CLI session groups for customer classes, ‟Gold” category customers can have a CLI-session group that allows them more Telnet/SSH sessions compared to ‟Silver” category customers.

The configured cli-session-group can be assigned to user profiles. Each user profile can be configured with its own max SSH/Telnet session and is policed/restricted by the higher order cli-session-group that is assigned to it.

As shown in Hierarchy of classic CLI session group profiles, the final picture is a hierarchical configuration with top-level cli-session-groups that control each customer’s total number of SSH or Telnet sessions and the user-profile for each user for that customer.

Every profile subtracts one from its corresponding maximum session when a Telnet or SSH session is established in the following cases:

• where multiple profiles are configured under a user

• where multiple profiles arrive from different AAA servers (Local Profile, RADIUS Profile or TACACS Profile)

The first profile to run out of corresponding max-session limits future Telnet or SSH sessions. In other words, while each profile for the user can have its independent max-session, only the lowest one is honored. If the profile with the lowest max-session is removed, the next lower profile max-session is honored and so on. All profiles for a user are updated when a Telnet or SSH session is established.

For information about login control, see Configuring login controls.

Use the commands ssh-max-sessions, telnet-max-sessions, combined-max-sessions, and cli-session-group in the following context to configure CLI session resources:

• MD-CLI

  configure system security aaa local-profiles profile

• classic CLI

  configure system security profile

Use the following command to copy a local user to another local user.

• MD-CLI

  configure system security user-params local-user
  copy user user-name to user user-name

• classic CLI
  Note: If the destination profile or user already exists, you must specify the overwrite option to avoid an error.

  configure system security copy user user-name to user user-name overwrite

The cannot-change-password option is not replicated when you perform a copy user command. The following example shows the new-password-at-login option is created instead.

[ex:/configure system security user-params local-user]
A:admin@node-2# info
...
    }
    user "user1" {
        password "$2y$10$TQrZlpBDra86.qoexZUzQeBXDY1FcdDhGWdD9lLxMuFyPVSm0OGy6"
        access {
            snmp true
        }
        console {
            cannot-change-password true
            member ["default"]
        }
        snmp {
            group "testgroup"
        }
    }
    user "user2" {
        password "$2y$10$TQrZlpBDra86.qoexZUzQeBXDY1FcdDhGWdD9lLxMuFyPVSm0OGy6"
        access {
            snmp true
        }
        console {
            new-password-at-login true
            member ["default"]
        }
        snmp {
            group "testgroup"
        }
    }
...

A:node-2>config>system>security>user# info
----------------------------------------------
user "user1"
password "$2y$10$TQrZlpBDra86.qoexZUzQeBXDY1FcdDhGWdD9lLxMuFyPVSm0OGy6"
     access snmp
     console
          cannot-change-password 
     exit
     snmp
         group "testgroup"
     exit
exit
----------------------------------------------
A:node-2>config>system>security>user# info
----------------------------------------------
user "user2" password "$2y$10$TQrZlpBDra86.qoexZUzQeBXDY1FcdDhGWdD9lLxMuFyPVSm0OGy6"
     access snmp
     console
          new-password-at-login
     exit
     snmp
          group "testgroup"
     exit
exit
---------------------------------------------

RADIUS is disabled by default and must be explicitly enabled. The RADIUS server commands add the RADIUS server. The mandatory configurations to enable the RADIUS server on the local router include the server index, IP address, and secret key. The index determines the sequence in which the servers are queried for authentication requests. In addition, configure the port, and retry and timeout intervals. The other configuration aspects are optional.

Configure the system IP address in order for the RADIUS client to work. For more information, see "Configuring a system interface" in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide.

Use the commands in the following context to configure RADIUS authentication on a local router:

• MD-CLI

  configure system security aaa remote-servers radius

• classic-CLI

  configure system security radius

[ex:/configure system security aaa remote-servers radius]
A:admin@node-2# info
    server-retry 5
    server-timeout 5
    server 1 {
        address 10.10.10.103
        secret "G08OmFGXGZjnMgeFRMlrNp8Odc0s hash2"
    }
    server 2 {
        address 10.10.0.1
        secret "YDA64iuZiGG847KPM+7Bvuj3waIn hash2"
    }
    server 3 {
        address 10.10.0.2
        secret "/WGgOvT3fYcPwh4F5+gGeOVvlfw1 hash2"
    }
    server 4 {
        address 10.10.0.3
        secret "pOYk1obgPtJ2fAq9hcFEJp5tlxKa hash2"
    }

A:node-2>config>system>security# info
----------------------------------------------
             retry 5
             timeout 5
             server 1 address 10.10.10.103 secret "test1"
             server 2 address 10.10.0.1 secret "test2"
             server 3 address 10.10.0.2 secret "test3"
             server 4 address 10.10.0.3 secret "test4"
...
----------------------------------------

For RADIUS authorization to function, enable RADIUS authentication. See Configuring RADIUS authentication.

In addition to the local configuration requirements, configure VSAs on the RADIUS server. See RADIUS VSAs.

Use the following command to configure RADIUS authorization on the local router:

• MD-CLI

  configure system security aaa remote-servers radius authorization

• classic CLI

  configure system security radius authorization

Use the following command to configure RADIUS accounting on the local router:

• MD-CLI

  configure system security aaa remote-servers radius accounting

• classic CLI

  configure system security radius accounting

To use TACACS+ authentication on the router, configure one or more TACACS+ servers on the network using the following command:

• MD-CLI

  configure system security aaa remote-servers tacplus server

• classic CLI

  configure system security tacplus server

The following example shows a TACACS+ configuration with authentication.

[ex:/configure system security aaa remote-servers tacplus]
A:admin@node-2# info
    server-timeout 5
    server 1 {
        address 10.10.0.5
        secret "G08OmFGXGZjnMgeFRMlrNn1Ak0Vj hash2"
    }
    server 2 {
        address 10.10.0.6
        secret "YDA64iuZiGG847KPM+7BvsC4f/EL hash2"
    
    server 3 {
        address 10.10.0.7
        secret "/WGgOvT3fYcPwh4F5+gGeBToxeh5 hash2"
    }
    server 4 {
        address 10.10.0.8
        secret "pOYk1obgPtJ2fAq9hcFEJtCZ/Qj/ hash2"
    }
    server 5 {
        address 10.10.0.9
        secret "oUDAwe2i3vK4MDY7o2KqTdr3cfHp hash2"
    }

A:node-2>config>system>security>tacplus# info
----------------------------------------------
          timeout 5
          server 1 address 10.10.0.5 secret "test1"
          server 2 address 10.10.0.6 secret "test2"
          server 3 address 10.10.0.7 secret "test3"
          server 4 address 10.10.0.8 secret "test4"
          server 5 address 10.10.0.9 secret "test5"
----------------------------------------------

Enable TACACS+ authentication for TACACS+ authorization to function. See Enabling TACACS+ servers with authentication.

LDAP is disabled by default and must be explicitly enabled. To use LDAP authentication on the router:

• Configure one or more LDAP servers on the network.
• Ensure that TLS certificates and clients are also configured; see TLS for information about TLS configuration in the SR OS.

Use the commands in the following context to configure LDAP:

• MD-CLI

  configure system security aaa remote-servers ldap

• classic CLI

  configure system security ldap

The following example shows the LDAP authentication configuration. See LDAP authentication for more information about the use of LDAP authentication in the SR OS.

[ex:/configure system security aaa remote-servers ldap]
A:admin@node-2# info
    admin-state enable
    public-key-authentication true
    server 1 {
        admin-state enable
        server-name "active-server"
        tls-profile "server-1-profile"
        address 10.1.1.1 {
        }
        bind-authentication {
            root-dn "cn=administrator,cn=users,dc=nacblr2,dc=example,dc=com password"
        }
        search {
            base-dn "dc=sns,dc=example,dc=com"
        }
    }
[ex:/configure system security tls]
A:admin@node-2# info
    client-tls-profile "server-1-profile" {
        admin-state enable
        cipher-list "to-active-server"
        trust-anchor-profile "server-1-ca"
    }

A:node-2>config>system>security>ldap# info
----------------------------------------------
    public-key-authentication
    server 1 create
        address 10.1.1.1
        bind-authentication "cn=administrator,cn=users,dc=nacblr2,dc=example,dc=com
          password"
        ldap-server "active-server"
        search "dc=sns,dc=example,dc=com"
        tls-profile "server-1-profile"
        no shutdown
    exit
    no shutdown
----------------------------------------------
A:node-2>config>system>security>tls# info
----------------------------------------------
    client-tls-profile "server-1-profile" create
        cipher-list "to-active-server"
        trust-anchor-profile ‟server-1-ca‟
    no shutdown
    exit

You can configure up to five redundant LDAP servers. The following examples show configuration of two servers. Server 1 is active and server 5 is backup.

[ex:/configure system security aaa remote-servers ldap]
A:admin@node-2# info
    public-key-authentication true
    server 1 {
        server-name "active-server"
        tls-profile "server-1-profile"
        address 10.1.1.1 {
        }
    }
[ex:/configure system security tls]
A:admin@node-2# info
    client-tls-profile "server-1-profile" {
        admin-state enable
        cert-profile "client-cert-profile"
        cipher-list "to-active-server"
        trust-anchor-profile "server-1-ca"
    }

[ex:/configure system security aaa remote-servers ldap]
A:admin@node-2# info
    public-key-authentication true
    server 5 {
        server-name "backup-server-5"
        tls-profile "server-5-profile"
        address 10.5.5.1 {
        }
[ex:/configure system security tls]
A:admin@node-2# info
    client-tls-profile "server-5-profile" {
        admin-state enable
        cert-profile "client-cert-profile"
        cipher-list "to-backup-server 5"
        trust-anchor-profile "server-5-ca"
        }
   }

A:node-2>config>system>security>ldap# info
    public-key-authentication
    server 1 create
        address 10.1.1.1
        ldap-server ‟active-server”
        tls-profile ‟server-1-profile”

A:node-2>config>system>security>tls# info
    client-tls-profile ‟server-1-profile” create
        cert-profile ‟client-cert-profile”
        cipher-list ‟to-active-server”
        trust-anchor-profile ‟server-1-ca”
        no shutdown
    exit 

A:node-2>config>system>security>ldap# info
    public-key-authentication
    server 5 create
        address 10.5.5.1
        ldap-server ‟backup-server-5”
        tls-profile ‟server-5-profile”

A:node-2>config>system>security>tls# info
    client-tls-profile ‟server-5-profile” create
        cert-profile ‟client-cert-profile”
        cipher-list ‟to-backup-server-5”
        trust-anchor-profile ‟server-5-ca”
        no shutdown
    exit 

Configure login control for console, Telnet, and FTP sessions. The following example shows a login control configuration.

[ex:/configure system]
A:admin@node-2# info
    login-control {
        exponential-backoff false
        idle-timeout 1440
        motd {
            text "Notice to all users: Software upgrade scheduled 3/2 1:00 AM"
        }
        pre-login-message {
            message "Property of Service Routing Inc. Unauthorized access prohibited."
        }
        ftp {
            inbound-max-sessions 5
        }
        telnet {
            inbound-max-sessions 7
            outbound-max-sessions 2
        }
    }

A:node-2>config>system# info
----------------------------------------------
...
        login-control
            ftp
                inbound-max-sessions 5
            exit
            telnet
                inbound-max-sessions 7
                outbound-max-sessions 2
            exit
            idle-timeout 1440
            pre-login-message "Property of Service Routing Inc. Unauthorized access
                               prohibited."
            motd text "Notice to all users: Software upgrade scheduled 3/2 1:00 AM"'
        exit
        no exponential-backoff
...
----------------------------------------------