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.

Remote Authentication Dial-In User Service (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 (TACACS) is an authentication protocol that allows a remote access server to forward a user's login password to an authentication server to determine whether access can be allowed to a specific system. TACACS is an encryption protocol and therefore less secure than the later Terminal Access Controller Access Control System Plus (TACACS+) and RADIUS protocols.

TACACS+ and RADIUS have largely replaced earlier protocols in the newer or recently updated networks. TACACS+, which uses Transmission Control Protocol (TCP), is popular because TCP is thought to be a more reliable protocol. RADIUS 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 opening successfully 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 multiple algorithms for user password hashing, including bcrypt 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 the 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 2 times to ensure password 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, then 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.

4. 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 can and cannot perform.

By default, local authorization is enabled. Local authorization is disabled only when a different remote authorization method is configured, such as TACACS+ or RADIUS authorization and local is removed from the authorization order.

RADIUS authorization grants or denies access permissions for a router. Permissions include the use of FTP, Telnet, SSH (SCP), and console access. When granting Telnet, SSH (SCP) and console access to the router, authorization can be used to limit what CLI commands the user is allowed to issue and which file systems the user is allowed or denied access.

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 profile to the router

• send the profile name that the node should apply to the router

Profiles consist of a suite of commands that the user is allowed or not allowed to execute. When a user issues a command, the authorization server looks at the command and the user information and compares it with the commands in the profile. If the user is authorized to issue the command, the command is executed. If the user is not authorized to issue the command, then the command is not executed.

Profiles must be created on each router and should be identical for consistent results. If the profile is not present, then access is denied.

Supported authorization configurations displays the following scenarios:

• Remote (RADIUS) authorization cannot be performed if authentication is done locally (on the router).

• The reverse scenario is supported if RADIUS authentication is successful and no authorization is configured for the user on the RADIUS server, then local (router) authorization is attempted, if configured in the authorization order.

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.

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 one of three ways:

• all users who authenticate via TACACS+ can use a single common default command authorization profile that is configured on the SR OS

• each command attempted by a user is sent to the TACACS+ server for authorization

• operator can configure local profiles and map tacplus priv-lvl based authorization to those profiles (the use-priv-lvl option)

To use a single common default command authorization profile to control command authorization for TACACS+ users, you can enable the tacplus default user template and configure the tacplus default option for the user template to point to a valid local profile. You must also disable tacplus authorization. Use the following commands to configure a single common default command profile for user authorization:

• MD-CLI

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

• classic CLI

  configure system security tacplus use-default-template
  configure system security user-template tacplus_default
  configure system security tacplus authorization

If the default template is not being used for TACACS+ authorization and the tacplus authorization command is enabled without the use-priv-lvl option, each CLI command issued by an operator is sent to the TACACS+ server for authorization. The authorization request sent by the SR OS contains the first word of the CLI command as the value for the TACACS+ cmd and all following words become a cmd-arg. Quoted values are expanded so that the quotation marks are stripped off and the enclosed value are seen as one cmd or cmd-arg.

When the authorization use-priv-lvl command is used, the router maps the priv-lvl 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 priv-lvl, and the tacplus use-default-template command is enabled, the router uses the local profile configured in the tacplus default for command authorization.

Authorization profiles can be configured in any format. Depending on the configuration, a match may be hit. Each entry in a profile can be formatted for the classic CLI or the MD-CLI. Nokia recommends creating separate profiles for each interface type.

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

Authorization and match hit based on entry format 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.

Authorization support 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 parameter indicates whether TACACS+ accounting start and stop packets be sent or just stop packets be sent. Start/stop messages are only sent for individual commands, not for the session.

When a user logs in to request access to the network using Telnet or SSH, or a user enters a command for which accounting parameters are configured, or a system event occurs, such as a reboot or a configuration file reload, the router checks the configuration to see if TACACS+ accounting is required for the particular event.

If TACACS+ accounting is required, then, depending on the accounting record type specified, sends a start packet to the TACACS+ accounting server which 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

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 CPM filter packet match rules are listed below.

• 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.

IPv4 and IPv6 match criteria 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 allow permit or deny traffic configuration (or use deny-host-unreachable response for IP filters).

permit

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

The SSH server also supports a public key authentication as long as the server has been previously configured to know the client's public key.

Using Public Key authentication (also known as Public Key Infrastructure - PKI) can be more secure than the existing username and password method because of the following reasons.

• A user typically re-uses 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 (the private key) is kept on the client. Therefore the password is less likely to be compromised.

SR OS supports server-side SSHv2 public key authentication 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 does 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 HMAC algorithms on top of the configurable MAC list (for example, lowest index in the list) in the order to be negotiated first between the client and server. The first algorithm in the list that is supported by both the client and the server is the one that is agreed upon.

There are two configurable MAC lists:

• server list

• client list

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

• mac 200 name hmac-sha2-512

• mac 210 name hmac-sha2-256

• mac 215 name hmac-sha1

• mac 220 name hmac-sha1-96

• mac 225 name hmac-md5

• mac 240 name hmac-md5-96

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

By default the KEX list is empty and this hard-coded list with all supported algorithms and the following preference is used:

• 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, the SR OS starts using the user-defined KEX list instead of the hard-coded list.

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

• MD-CLI

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

• 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.

This feature introduces symmetric key rollover on SSH client or server. The following are triggers for symmetric key rollover and negotiation:

• the negotiation of the key base on a configured time period

• the negotiation of the key base on a configured data transmission size

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

SR OS supports cipher client and server lists. The user can add or remove the needed SSH cipher client and server algorithms to be negotiated. The list is an index list with the lower index having higher preference in the SSH negotiation. The lowest index 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.

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.

configure system security ssh version

configure system security ssh client-cipher-list protocol-version
configure system security ssh server-cipher-list protocol-version

configure system security ssh client-cipher-list protocol-version 2
configure system security ssh server-cipher-list protocol-version 2

configure system security ssh client-mac-list
configure system security ssh server-mac-list

Option Syntax:

• Kind: 8 bits

  The Kind field identifies the TCP Enhanced Authentication Option. This value is assigned by IANA.

• Length: 8 bits

  The Length field specifies the length of the TCP Enhanced Authentication Option, 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 is 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. They 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 need not be restricted to, a MAC. The length and format of the Authentication Data Field can be derived from the Alg ID.

• The Authentication for TCP-based Routing and Management Protocols draft provides and overview of the TCP Enhanced Authentication Option. The details of this feature are described in draft-bonica-tcp-auth-04.txt.

The keychain mechanism allows for the creation of keys used to authenticate protocol communications. Each keychain entry defines the authentication attributes to be used in authenticating protocol messages from remote peers or neighbors, and it 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 OSPF, IS-IS, BGP, LDP, and RSVP-TE.

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

• key identifier

• authentication algorithm

• authentication key

• direction

• start time

In addition, additional attributes can be optionally specified, including:

• end time

• tolerance

Keychain mapping shows the mapping between these attributes and the CLI command to set them.

Security algorithm support per protocol lists the authentication algorithms that can be used in association with specific routing protocols.

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 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 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 user configuration to another user configuration.

• MD-CLI
  Note: In the MD-CLI, the copy command is a global command.

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

• 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 username to user username 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$YlCd8TWpvgpFpm92lf2ZY.gb4lejb96GZocMJ0/JhwUnhP7BQZ06e"
        access {
            snmp true
        }
        console {
            cannot-change-password true
            member ["default"]
        }
        snmp {
            group "testgroup"
        }
    }
    user "user2" {
        password "$2y$10$m.xtXmULRSHf4svGAj.p..wlXHMhWj/fF1jsF0p0beSOSmx8J9Vfa"
        access {
            snmp true
        }
        console {
            new-password-at-login true
            member ["default"]
        }
        snmp {
            group "testgroup"
        }
    }
...

A:node-2>config>system>security>user# info
----------------------------------------------
user "userA"
password "$2y$10$pFoehOg/tCbBMPDJ/kqpu.8af0AoVGY2xsR7WFqyn5fVTnwRzGmOK"
     access snmp
     console
          cannot-change-password 
     exit
     snmp
         group "testgroup"
     exit
exit
----------------------------------------------
A:node-2>config>system>security>user# info
----------------------------------------------
user "userB" password ""
     access snmp
     console
          new-password-at-login
     exit
     snmp
          group "testgroup"
     exit
exit
---------------------------------------------

Use the copy and to commands to copy a profile configuration to another profile configuration.

• MD-CLI
  Note: In the MD-CLI, the copy command is a global command.

  configure system security aaa local-profiles copy profile user-profile-name to profile user-profile-name

• classic CLI

  configure system security copy profile source-profile-name to destination-profile-name

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.

The system IP address must also be configured for the RADIUS client to work. For more information, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide, "Configuring a System Interface".

Use the commands in the following context to enable the RADIUS server on the 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, you must first enable RADIUS authentication. See Configuring RADIUS authentication.

In addition to the local configuration requirements, configure VSAs on the RADIUS server. See Vendor-specific attributes.

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 CLI 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

You can use TACACS+ authentication on the router. Use the commands in the following context to configure one or more TACACS+ servers on the network:

• 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"
----------------------------------------------

For TACACS+ authorization to function, you must first enable TACACS+ authentication. See Enabling TACACS+ servers with authentication.

Use the command in the following context to configure TACACS+ authorization on the local router:

• MD-CLI

  configure system security aaa remote-servers tacplus authorization

• classic CLI

  configure system security tacplus authorization

Use the following command to configure TACACS+ accounting on the local router:

• MD-CLI

  configure system security aaa remote-servers tacplus accounting

• classic CLI

  configure system security tacplus accounting

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
...
----------------------------------------------