2. Security

This chapter provides information to configure security parameters.

2.1. Authentication, Authorization, and Accounting

This chapter describes authentication, authorization, and accounting (AAA) used to monitor and control network access on 7210 SAS routers. Network security is based on a multi-step process. The first step, authentication, validates a username and password. The second step is authorization, which allows the user to access and execute commands at various command levels based on profiles assigned to the user.

Another step, accounting, keeps track of the activity of a user who has accessed the network. The type of accounting information recorded can include a history of the commands executed, the amount of time spent in the session, the services accessed, and the data transfer size during the session. The accounting data can then be used to analyze trends, and also for billing and auditing purposes.

You can configure 7210 SAS routers to use local, Remote Authentication Dial In User Service (RADIUS), or Terminal Access Controller Access Control System Plus (TACACS+) security to validate users who attempt to access the router by console, Telnet, or FTP. You can select the authentication order which determines the authentication method to try first, second, and third.

The 7210 SAS supports the following security features:

RADIUS can be used for authentication, authorization, and accounting.
TACACS+ can be used for authentication, authorization, and accounting.
Local security can be implemented for authentication and authorization.

Figure 1 shows how end user access-requests are sent to a RADIUS server. After validating the usernames and passwords, the RADIUS server returns an access-accept message to the users on ALA-1 and ALA-2. The username and password from ALA-3 could not be authenticated, therefore access was denied.

Figure 1: RADIUS Requests and Responses

2.1.1. Authentication

Authentication validates a username and password combination when a user attempts to log in.

When a user attempts to log in through the console, Telnet, SSH, SCP, or FTP, the 7210 SAS client sends an access request to a RADIUS, TACACS+, or local database.

Transactions between the client and a RADIUS server are authenticated through the use of a shared secret. The secret is never transmitted over the network. User passwords are sent encrypted between the client and RADIUS server which prevents someone snooping on an insecure network to learn password information.

If the RADIUS server does not respond within a specified time, the router issues the access request to the next configured servers. Each RADIUS server must be configured identically to guarantee consistent results.

If any RADIUS server rejects the authentication request, it sends an access reject message to the router. In this case, no access request is issued to any other RADIUS servers. However, if other authentication methods such as TACACS+ and/or local are configured, then these methods are attempted. If no other authentication methods are configured, or all methods reject the authentication request, then access is denied.

For the RADIUS server selection, round-robin is used if multiple RADIUS servers are configured. Although, if the first alive server in the list cannot find a user-name, the router does not query the next server in the RADIUS server list and denies the access request. It may get authenticated on the next login attempt if the next selected RADIUS server has the appropriate user-name. Nokia recommends that the same user databases be maintained for RADIUS servers to avoid inconsistent behavior.

The user login is successful when the RADIUS server accepts the authentication request and responds to the router with an access accept message.

Implementing authentication without authorization for the 7210 SAS-Series routers does not require the configuration of VSAs (Vendor Specific Attributes) on the RADIUS server. However, users, user access permissions, and command authorization profiles must be configured on each router.

Any combination of the following authentication methods can be configured to control network access from a 7210 SAS-Series router.

2.1.1.1. Local Authentication

Local authentication uses usernames and passwords to authenticate login attempts. The usernames and passwords 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 disabled. Local authentication is restored when the other authentication methods are disabled. Local authentication is attempted if the other authentication methods fail and local is included in the authentication order password parameters.

Locally, you can configure usernames and password management information. This is referred to as local authentication. Remote security servers such as RADIUS or TACACS+, are not enabled.

2.1.1.2. RADIUS 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 you 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.

2.1.1.2.1. RADIUS Server Selection

The RADIUS server selection algorithm is used by different applications:

RADIUS operator management
RADIUS authentication for Enhanced Subscriber Management
RADIUS accounting for Enhanced Subscriber Management
RADIUS PE-discovery

In all these applications, up to 5 RADIUS servers pools (per RADIUS policy, if used) can be configured.

The RADIUS server selection algorithm can work in 2 modes, either Direct mode or Round-robin mode.

2.1.1.2.1.1. Direct Mode

The first server is used as the primary server. If this server is unreachable, the next server, based on the server index, of the server pool is used. This continues until either all servers in the pool have been tried or an answer is received.

If a server is unreachable, it will not be used again by the RADIUS application for the next 30 seconds to allow the server to recover from its unreachable state. After 30 seconds the unreachable server is available again for the RADIUS application. If in these 30 seconds the RADIUS application receives a valid response for a previously sent RADIUS packet on that unreachable server, the server will be available for the RADIUS application again, immediately after reception of that response.

2.1.1.2.1.2. Round-Robin Mode

The RADIUS application sends the next RADIUS packet to the next server in the server pool. The same server non-reachability behavior is valid as in the Direct mode.

2.1.1.2.1.3. Server Reachability Detection

A server is reachable, when the operational state UP, when a valid response is received within a timeout period which is configurable by the retry parameter on the RADIUS policy level.

A server is treated as not-reachable, when the operational state down, when the following occurs:

A timeout — If a number of consecutive timeouts are encountered for a specific server. This number is configurable by the retry parameter on RADIUS policy level.
A send failed — If a packet cannot be sent to the RADIUS server because the forwarding path toward the RADIUS server is broken (for example, the route is not available, the is interface shutdown, etc.), then, no retry mechanism is invoked and immediately, the next server in line is used.

A server that is down can only be used again by the RADIUS algorithm after 30 seconds, unless, during these 30 seconds a valid RADIUS reply is received for that server. Then, the server is immediately marked UP again.

The operational state of a server can also be “unknown” if the RADIUS application is not aware of the state of the RADIUS server (for example, if the server was previously down but no requests had been sent to the server, therefore, it is not certain yet whether the server is actually reachable).

2.1.1.2.1.4. Application Specific Behavior

Operator Management

The server access mode is fixed to Round-Robin (Direct cannot be configured for operator management). A health-check function is available for operator management, which can optionally be disabled. The health-check polls the server once every 10 seconds with an improbable username. If the server does not respond to this health-check, it will be marked down.

If the first server in the list cannot find a user, the next server in the RADIUS server list is not queried and access is denied. If multiple RADIUS servers are used, it is assumed they all have the same user database.

RADIUS Authentication

RADIUS Accounting

The RADIUS accounting application will try to send all the concerned packets of a subscriber host to the same server. If that server is down, then the packet is sent to the next server and, from that moment on, the RADIUS application uses that server to send its packets for that subscriber host.

RADIUS PE-Discovery

The RADIUS PE-discovery application makes use of a 10 second time period instead of the generic 30 seconds and uses a fixed consecutive timeout value of 2 (see Server Reachability Detection).

As long as the Session-Timeout (attribute in the RADIUS user file) is specified, it is used for the polling interval. Otherwise, the configured polling interval will be used (60 seconds by default).

2.1.1.3. TACACS+ Authentication

Terminal Access Controller Access Control System, commonly referred to as TACACS is an authentication protocol that allows a remote access server to forward a user's log on 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+ uses Transmission Control Protocol (TCP) and RADIUS uses the User Datagram Protocol (UDP). TACACS+ is popular as TCP is thought to be a more reliable protocol. RADIUS combines authentication and authorization. TACACS+ separates these operations.

2.1.2. Authorization

The OS support local, RADIUS, and TACACS+ authorization to control the actions of specific users by applying a profile based on username and password configurations when network access is granted. The profiles are configured locally as well as VSAs on the RADIUS server. See Vendor-Specific Attributes (VSAs).

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.

Table 5 describes 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.

Table 5: Supported Authorization Configurations

User Type	RADIUS Supplied Profile
Configured user	Not Supported
RADIUS server configured user	Supported
TACACS+ server configured user	Not Supported

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.

2.1.2.1. Local Authorization

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 (RADIUS authorization). Local authorization is restored when RADIUS authorization is disabled.

You must configure profile and user access information locally.

2.1.2.2. RADIUS Authorization

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.

2.1.2.3. TACACS+ Authorization

Like RADIUS authorization, TACACS+ grants or denies access permissions for a router. The TACACS+ server sends a response based on the username and password.

TACACS+ separates the authentication, authorization, and accounting function. RADIUS combines the authentication and authorization functions.

2.1.3. Accounting

When enabled, RADIUS accounting sends command line accounting from the router to the RADIUS server. The router sends accounting records using UDP packets at port 1813 (decimal).

The router issues an accounting request packet for each event requiring the activity to be recorded by the RADIUS server. The RADIUS server acknowledges each accounting request by sending an accounting response after it has processed the accounting request. 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.

2.1.3.1. RADIUS Accounting

Accounting tracks user activity to a specified host. When RADIUS accounting is enabled, the server is responsible for receiving accounting requests and returning a response to the client 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.

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

2.1.3.2. TACACS+ Accounting

The OS allows you 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.

2.2. Security Controls

You can configure routers to use RADIUS, TACACS+, and local authentication to validate users requesting access to the network. The order in which password authentication is processed among RADIUS, TACACS+ and local passwords can be specifically configured. That is, the authentication order can be configured to process authorization through TACACS+ first, then RADIUS for authentication and accounting. Local access can be specified next in the authentication order in the event that the RADIUS and TACACS+ servers are not operational.

Table 6 lists the types of security supported by each protocol.

Table 6: Security Methods Capabilities

Method	Authentication	Authorization	Accounting*
Local	Y	Y	N
TACACS+	Y	Y	Y
RADIUS	Y	Y	Y
* Local commands always perform account logging using the config log command.

2.2.1. When a Server Does Not Respond

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 not performed. If a server is down, it will not be contacted for 5 minutes. If a login is attempted after 5 minutes, then the server is contacted again. When a server does not respond with the health check feature enabled, 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, implying a lower indexed server is not available. If a response from the server is received, no other server is queried.

2.2.2. Access Request Flow

In Figure 2, the authentication process is defined in the config>system>security> password context. The authentication order is determined by specifying the sequence in which password authentication is attempted among RADIUS, TACACS+, and local passwords. This example uses the authentication order of RADIUS, then TACACS+, and finally, local. An access request is sent to RADIUS server 1. One of two scenarios can occur. If there is no response from the server, the request is passed to the next RADIUS server with the next lowest index (RADIUS server 2) and so on, until the last RADIUS server is attempted (RADIUS server 5). If server 5 does not respond, the request is passed to the TACACS+ server 1. If there is no response from that server, the request is passed to the next TACACS+ server with the next lowest index (TACACS+ server 2) and so on.

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

Figure 2: Security Flow

2.3. Control and Management Traffic Protection

7210 SAS platforms support an extensive set of configurable mechanisms to protect the CPU from being flooded with control or management traffic.

These protection mechanisms are a set of configurable hardware-based filters, classification, queuing, and rate-limiting functions that drop unwanted traffic before it reaches the control processor.

In-band traffic extracted from line cards to the control processing module (CPM) on chassis-based systems, or extracted from front-panel ports on fixed form-factor devices:
1. Line card or fixed form-factor platform features:
  1. ACLs filters: IPv4, IPv6, and MAC
  2. Distributed CPU protection (supported only on the 7210 SAS-R6 and 7210 SAS-R12)
1. CPM features:
  1. Centralized CPU protection
Out-band and in-band traffic: management access filters

2.3.1. CPM Management Access Filters

CPM traffic is extracted from the data plane and sent to the CPM for processing. Packets from all network and access ports can be filtered using management access filters, which use CPU resources. Packets originating from a management Ethernet port can also be filtered using management access filters.

2.3.1.1. CPM Protocols and Ports

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

Table 7 identifies the protocols and TCP/UDP ports used per application on 7210 SAS platforms. The source port and destination port reflect the CPM management access filter entry configuration for traffic ingressing the router and sent to the CPM.

Table 7: Protocols and TCP/UDP Ports Used by Applications on 7210 SAS Platforms

TCP/UDP Port Number

IP Protocol

Application Description

Protocols and Ports Available for In-band and Out-of-band Management on 7210 SAS Platforms

Source

Destination

SAS-M

(Network Mode)

SAS-M

(Access-uplink Mode)

SAS-T

(Network Mode)

SAS-T

(Access-uplink Mode)

SAS-Mxp

SAS-R6 and SAS-R12

SAS-Sx/S 1/10GE and

SAS-Sx 10/100GE

In-band

Out-of-band

In-band

Out-of-band

In-band

Out-of-band

In-band

Out-of-band

In-band

Out-of-band

In-band

Out-of-band

In-band

Out-of-band

FTP Application

TCP

FTP server data and active FTP client

✓

TCP

FTP server control

✓

TCP

FTP client data

✓

TCP

FTP client control

✓

SSH Application

TCP

SSH server and terminated TCP session

✓

TCP

SSH client and responses for initiated TCP sessions

✓

TELNET Application

TCP

TELNET server

✓

TACACS Application

TCP

TACACS client and responses for initiated TCP sessions

✓

DNS Application

UDP

DNS Client

✓

DHCPv4 Application

UDP

DHCPv4: relay agent to server; server to relay agent; relay agent to relay agent

✓

UDP

DHCPv4: client to relay agent; client to server

✓

UDP

DHCPv4: relay agent to server; relay agent to client

✓

NTP Application

123

UDP

NTP server

✓

123

UDP

NTP client

✓

SNMP Application

161

UDP

SNMP server; SET and GET commands

✓

BGP Application

179

TCP

BGP: server terminated TCP sessions

✓

179

TCP

BGP: client responses for initiated TCP session

✓

PTP Application

319

UDP

1588 PTP event

✓

320

UDP

1588 PTP general

✓

RIP Application

520

UDP

RIP (only on SAS-Mxp)

✓

LDP Application

646

UDP

LDP hello adjacency

✓

646

TCP

LDP/T-LDP: terminated TCP sessions

✓

646

TCP

LDP/T-LDP: responses for initiated TCP sessions

✓

NETCOMF Application

830

TCP

NETCONF

✓

TWAMP Application

862

TCP

TWAMP control: terminated TCP session

✓

ANY

UDP

TWAMP test

✓

862

64364-64373

UDP

TWAMP light (per router instance)

✓

MC-APS Application

1025

UDP

Multi-chassis LAG

✓

RADIUS Application

1812

UDP

Radius authentication

✓

1813

UDP

Radius accounting

✓

PIM Application

3232

UDP

PIM MDT

✓

OAM Application

3503

UDP

LSP ping

✓

33408-33535

UDP

OAM traceroute

✓

BFD Application

3784

UDP

BFD control 1 hop BFD

✓

3785

UDP

BFD echo

✓

4784

UDP

BFD control multi-hop

✓

PCEP Application

4189

TCP

Path Computation Element Protocol (PCEP)

✓

MCS Application

45067

TCP

Multi-chassis synchronization: terminated TCP session

✓

45067

TCP

Multi-chassis synchronization: responses for initiated TCP session

✓

GRE Application

N/A

GRE

✓

ICMP Application

N/A

ICMP

✓

IGMP Application

N/A

IGMP

✓

OSPF Application

N/A

OSPF

✓

PIM Application

N/A

PIM

✓

RSVP Application

N/A

RSVP

✓

VRRP Application

N/A

VRRP

✓

2.3.2. Management Access Filter

Management Access Filters (MAF) are software-based filters used to restrict traffic extracted from the data plane and restrict traffic from the management port to the CPU.

2.3.2.1. MAF Packet Match

Two different management-access-filter policies can be configured: ip-filter and ipv6-filter.

The following are the 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 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 defined without a match criteria is inactive.
A MAF filter policy entry with match criteria defined but no action configured inherits the default action defined at the management-access-filter level.
The management-access-filter default-action applies individually per IPv4 or IPv6 filter policies that are in a no shutdown state.

2.3.2.2. MAF IPv4/IPv6 Filter Entry Match Criteria

Table 8 lists the supported IPv4 and IPv6 match criteria.

Table 8: IPv4 and IPv6 Match Criteria

Criteria	Description
dst-port	Matches the specified port value against the destination port number of the UDP or TCP packet header.
flow-label	Matches the IPv6 flow label.
fragment	Matches fragmented or non-fragmented IP packet.
next-header	Matches the specified upper-layer protocol (such as TCP, UDP, or IGMPv6) against the next-header field of the IPv6 packet header. "*" can be used to specify a TCP or UDP upper-layer protocol match (logical OR). Next-header matching also allows matching on presence of a subset of IPv6 extension headers. See Management Access Filter Commands for details about which extension header match is supported.
l4-source-port	Matches the specified port value against the L4 source port number of the UDP or TCP packet header.
protocol	Matches the specified protocol against the Protocol field in the IPv4 packet header (for example, TCP, UDP, or IGMP) of the outer IPv4. "*" can be used to specify TCP or UDP upper-layer protocol match (logical OR).
router	Matches the router instance that packets are ingressing from for this filter entry.
src-ip	Matches the specified source IPv4 or IPv6 address prefix and mask against the source IPv4 or IPv6 address field in the IP packet header.
src-port	Matches packets that are ingressing from this port.

2.3.2.3. MAF Policy Action

MAFs allow actions to permit or deny (or use the deny-host-unreachable response for IP filters) traffic.

2.3.2.4. MAF Policy Statistics and Logging

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

2.4. CPU Protection Modes

The 7210 SAS provides several rate limiting mechanisms to protect the CPM/CFM processing resources of the router:

Centralized CPU Protection: a centralized rate-limiting function that operates on the CPM to limit traffic destined to the CPUs. The CPU protection mechanism is not user-configurable. It is supported on all 7210 SAS platforms.
For historical reasons, the term “centralized CPU protection” is called “CPU protection” in this user guide.
Distributed CPU Protection (DCP): a control traffic rate-limiting protection mechanism for the CPM and CFM that operates on line cards. See DCP for more information about the DCP mechanism.

2.4.1. Centralized CPU Protection

The CPU protection mechanism protects the CPU from a DoS attack by limiting the amount of ingress port traffic destined for the CPM to be processed by its CPU. On the 7210 SAS, a set of dedicated policers are used to limit the amount of traffic to the software-defined rate (the rate is not user-configurable) before the packets are queued to the CPU queues. A strict policy scheduler schedules packets from the CPU queues. A CPU queue traffic shaper, configured to a predefined rate by software, is used to limit the amount of traffic for a protocol or group of protocols using the CPU queue. In most cases, access interfaces and network uplinks do not share the policers and CPU queues used to manage the amount of traffic sent to the CPM. Access interfaces (typically used to deliver customer services) use a dedicated set of policers and CPU queues; a separate set is used for network facing ports (that is, network ports, hybrid ports, and access-uplink ports). The policer rate and CPU queue rates used for CPU protection are not user-configurable.

2.4.2. DCP

DCP provides a powerful per-protocol-per-object rate-limiting function for control protocol traffic that is extracted from the data path and sent to the CPM. See DCP Applicability for a list of applicable objects. The DCP function is implemented on the router for granular control.

DCP provides the following policers to configure policies that are applied to objects (for example, SAPs).

Enforcement Policers — An instance of a policer that is policing a flow of packets comprised of a single protocol arriving on a single object (for example, SAP). Enforcement policers perform a configurable action, such as a discard, on packets that exceed the configured rate parameters. There is one type of enforcement policer supported on the 7210 SAS-R6 and 7210 SAS-R12:
1. static policers, which are always instantiated if configured

Figure 3 shows per-SAP per-protocol static rate limiting with DCP.

Figure 3: Per-SAP Per-Protocol Static Rate Limiting with DCP

Note:

CPU policers and CPU queues on CPM and IMM are shown only for some protocols. on the 7210 SAS, all control traffic to the CPU is rate-limited using a policer per protocol or group of protocols. The CPU queues are further shaped to the system-defined rate. There are different policers and queues used for access ports and network ports to ensure that customer traffic does not affect critical network traffic. The rates for these CPU policers and queues are not configurable by the user.

2.4.2.1. DCP Applicability

By default, the system does not associate a DCP policy with a SAP. The user must configure an explicit policy to enable DCP for a SAP for a supported protocol. Allocate resources for the DCP policy from the ingress internal TCAM resource pool by using the configure>system>resource-profile>ingress-internal-tcam>cpu-protection command. See the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Basic System Configuration Guide for more information about this command.

The DCP functionality is not enabled on the service objects by default. Use the dist-cpu-protection command in the config>service context to enable the DCP functionality on service objects. The no form of the command disables the DCP functionality on service objects.

DCP policies can be applied to the following types of objects:

IES SAP
VPRN SAP
RVPLS SAP

For RVPLS, DCP rate-limits the packets arriving at the CPU, but for flooded traffic, ingress QoS or ACLs must be used.

Control packets that are extracted in an IES or a VPRN service, where the packets arrived into the node over a VPLS SAP (that is, R-VPLS scenario), will use the DCP policy and policer instances associated with the VPLS SAP. In this case, a DCP policy created for VPLS SAPs, for VPLSs that have a Layer 3 interface bound to them (R-VPLS), may have protocols such as ARP configured in the policy.

2.4.2.2. Log Events, Statistics, Status and SNMP Support

Log events are supported for DCP to warn against potential attacks or misconfigurations, and to tune DCP settings. DCP throttles the rate of DCP events to avoid event floods when multiple parallel attacks or problems occur in the system.

Most DCP log events can be enabled or disabled both individually at the DCP policy level (in the DCP policy configuration), and globally in the system (in log event control).

In the case where the DCP log event indicates a SAP that is an MSAP, the operator can identify the subscribers on a specific MSAP by using the show service active-subscriber command and filtering (“| match”) on the MSAP string.

The DCP statistics and status is available via the following:

SNMP
For detailed information, see the tables and NOTIFICATION-TYPE objects in the following MIBs where “Dcp” or “DCpuProt” occurs in the applicable object name:
1. TIMETRA-CHASSIS-MIB
2. TIMETRA-SAP-MIB
3. TIMETRA-VRTR-MIB
4. TIMETRA-SECURITY-MIB
CLI
Use the show log event-control | match Dcp command to display the log events in the CLI.
In the case where the DCP log event indicates a SAP that is an MSAP, the operator can identify the subscribers on a specific MSAP by using the show service active-subscriber command and filtering (“| match”) on the MSAP string.

2.4.2.3. DCP Policer Resource Management

CAM and meter resources from the CPU protection pool are allocated for the DCP policer by using the configure>system>resource-profile>ingress-internal-tcam>cpu-protection command. Resources from this pool (also called a slice) are also used to identify protocol packets that need to be rate-limited and have used a policer or meter to the configured rate before being queued to the CPU queues. Two CAM entries with a single policer is used for every protocol configured in the DCP policy. The 7210 SAS does not support sharing of a policer among protocols. All protocols configured to use a policer are allocated an independent instance of the policer and are policed to the configured rate. See the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Basic System Configuration Guide for information about resource allocation using the cpu-protection CLI command.

2.4.2.4. Operational Guidelines

This section describes the operational guidelines to leverage distributed CPU protection.

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.
During normal operation, Nokia recommends that log events for state policers should be configured using the log-events command without the optional verbose keyword. Use the verbose keyword selectively during debugging, testing, tuning, and investigation.
Every protocol configured to use a policer is allocated an independent policer instance to rate-limit that protocol. A single policer cannot be shared across multiple protocols. For example, if a single policer is configured in the service and there are four protocols configured to use it, four policer instances are allocated (that is, eight CAM entries are used for identifying the protocol and four meters are allocated).
The rates enforced by centralized CPU protection are also enforced for protocols configured for DCP. That is, DCP allows users to enforce rates per service object to be below the system-defined rate of the centralized CPU protection. Therefore, it prevents customer traffic from affecting other customer traffic.

2.5. Vendor-Specific Attributes (VSAs)

The 7210 SAS supports the configuration of Nokia-specific RADIUS attributes. These attributes are known as vendor-specific attributes (VSAs) and are described in RFC 2138. VSAs must be configured when RADIUS authorization is enabled. It is up to the vendor to specify the format of their VSA. The attribute-specific field is dependent on the vendor's definition of that attribute. The Nokia defined attributes are encapsulated in a RADIUS vendor-specific attribute with the vendor ID field set to 6527, the vendor ID number.

The PE-record entry is required to support the RADIUS Discovery for Layer 2 VPN feature. A PE-record is only relevant if the RADIUS Discovery feature is used, not for the standard RADIUS setup.

The following RADIUS vendor-specific attributes (VSAs) are supported by Nokia.

timetra-access <ftp> <console> <both> — This is a mandatory command that must be configured. This command specifies if the user has FTP and /or console (serial port, Telnet, and SSH) access.
timetra-profile <profile-name> — When configuring this VSA for a user, it is assumed that the user profiles are configured on the local router and the following applies for local and remote authentication:

The authentication-order parameters configured on the router must include the local keyword.

The username may or may not be configured on the router.

The user must be authenticated by the RADIUS server

Up to 8 valid profiles can exist on the router for a user. The sequence in which the profiles are specified is relevant. The most explicit matching criteria must be ordered first. The process stops when the first complete match is found.

If all the preceding conditions are not met, then access to the router is denied and a failed login event/trap is written to the security log.

timetra-default-action <permit-all|deny-all|none> — This is a mandatory command that must be configured even if the timetra-cmd VSA is not used. This command specifies the default action when the user has entered a command and no entry configured in the timetra-cmd VSA for the user resulted in a match condition.

timetra-cmd <match-string> — Configures a command or command subtree as the scope for the match condition.
The command and all subordinate commands in subordinate command levels are specified.
Configure from most specific to least specific. The system exits on the first match; subordinate levels cannot be modified with subsequent action commands. Subordinate level VSAs must be entered before this entry to be effective.
All commands at and below the hierarchy level of the matched command are subject to the timetra-action VSA.
Multiple match-strings can be entered in a single timetra-cmd VSA. Match strings must be semicolon (;) separated (maximum string length is 254 characters).

One or more timetra-cmd VSAs can be entered followed by a single timetra-action VSA.

timetra-action <deny|permit> — Causes the permit or deny action to be applied to all match strings specified since the last timetra-action VSA.
timetra-home-directory <home-directory string> — Specifies the home directory that applies for the FTP and CLI user. If this VSA is not configured, the home directory is Compact Flash slot 1 (cf1:).
timetra-restrict-to-home-directory <true|false> — Specifies if user access is limited to their home directory (and directories and files subordinate to their home directory). If this VSA is not configured the user is allowed to access the entire file system.
timetra-login-exec <login-exec-string> — Specifies the login exec file that is executed when the user login is successful. If this VSA is not configured no login exec file is applied.

If no VSAs are configured for a user, then the following applies:

The password authentication-order command on the router must include local.
The username must be configured on the router.
The user must be successfully be authenticated by the RADIUS server
A valid profile must exist on the router for this user.

If all of the preceding conditions are not met, then access to the router is denied and a failed login event/trap is written to the security log.

The complete list of TiMetra VSAs is available on a file included on the compact flash shipped with the image.

2.5.1. Sample User (VSA) Configuration

The following example displays a user-specific VSA configuration. This configuration shows attributes for users named ruser1 and ruser2.

The following example shows that user ruser1 is granted console access. The ruser1 home directory is in compact flash slot 3 and is limited to the home directory. The default action permits all packets when matching conditions are not met. The timetra-cmd parameters allow or deny the user to use the tools;telnet;configure system security commands. Matching strings specified in the timetra-action command are denied for this user since the timetra-action is deny.

The user ruser2 is granted FTP access.The default action denies all packets when matching conditions are not met. The timetra-cmd parameters allow the user to use the configure, show, and debug commands. Matching strings specified in the timetra-action command are permitted for this user.

users.timetra

ruser1 Auth-Type := System, Password == "ruser1"

Service-Type = Login-User,

Idle-Timeout = 600,

Timetra-Access = console,

Timetra-Home-Directory = cf1:

Timetra-Restrict-To-Home = true

Timetra-Default-Action = permit-all,

Timetra-Cmd = "tools;telnet;configure system security",

Timetra-Action = deny

ruser2 Auth-Type := System, Password == "ruser2"

Service-Type = Login-User,

Idle-Timeout = 600,

Timetra-Access = ftp

Timetra-Default-Action = deny-all,

Timetra-Cmd = "configure",

Timetra-Cmd = "show",

Timetra-Action = permit,

Timetra-Cmd = "debug",

Timetra-Action = permit,

2.6. Other Security Features

2.6.1. Secure Shell (SSH)

Secure Shell Version 1 (SSH) is a protocol that provides a secure, encrypted Telnet-like connection to a router. A connection is always initiated by the client (the user). Authentication takes places by one of the configured authentication methods (local, RADIUS, or TACACS+). With authentication and encryption, SSH allows for a secure connection over an insecure network.

The 7210 SAS allows a user to configure Secure Shell (SSH) Version 2 (SSH2). SSH1 and SSH2 are different protocols and encrypt at different parts of the packets. SSH1 uses server as well as host keys to authenticate systems whereas SSH2 only uses host keys. SSH2 does not use the same networking implementation that SSH1 does and is considered a more secure, efficient, and portable version of SSH.

SSH runs on top of a transport layer (like TCP or IP), and provides authentication and encryption capabilities. SSH supports remote login to another computer over a network, remote command execution, and file relocation from one host to another.

The 7210 SAS has a global SSH server process to support inbound SSH and SCP sessions initiated by external SSH or SCP client applications. The SSH server supports SSHv1. Note that this server process is separate from the SSH and SCP client commands on the routers which initiate outbound SSH and SCP sessions.

Inbound SSH sessions are counted as inbound telnet sessions for the purposes of the maximum number of inbound sessions specified by Login Control. Inbound SCP sessions are counted as inbound ftp sessions by Login Control.

When SSH server is enabled, an SSH security key is generated. The key is only valid until either the node is restarted or the SSH server is stopped and restarted (unless the preserve-key option is configured for SSH). The key size is non-configurable and set at 1024 bits. When the server is enabled, both inbound SSH and SCP sessions will be accepted provided the session is properly authenticated.

When the global SSH server process is disabled, no inbound SSH or SCP sessions will be accepted.

When using SCP to copy files from an external device to the file system, the SCP server will accept either forward slash (“/”) or backslash (“\”) characters to delimit directory and/or filenames. Similarly, the SCP client application can use either slash or backslash characters, but not all SCP clients treat backslash characters as equivalent to slash characters. In particular, UNIX systems will often times interpret the backslash character as an “escape” character which does not get transmitted to the SCP server. For example, a destination directory specified as “cf1:\dir1\file1” will be transmitted to the SCP server as “cf1:dir1file1” where the backslash escape characters are stripped by the SCP client system before transmission. On systems where the client treats the backslash like an “escape” character, a double backslash “\\” or the forward slash “/” can typically be used to properly delimit directories and the filename.

2.6.2. MAC Client and Server List

The 7210 SAS supports a configurable client and server MAC list for SSHv2, which allows the user to add or remove Message Authentication Code (MAC) algorithms from the list. The user can program the strong Hashed Message Authentication Code (HMAC) algorithms on top of the configurable MAC list (for example, lowest index in the list) 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:

client list
server list

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

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 230 name hmac-ripemd160
mac 235 name hmac-ripemd160-openssh-com
mac 240 name hmac-md5-96

Note:

The configurable MAC list is only supported for SSHv2 and not for SSHv1. SSHv1 only supports 32-bit CRC.

2.6.3. Cipher Client and Server List

The 7210 SAS supports cipher client and server lists. The user can add or remove the desired 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 connections and is on top of the negotiation list to the peer.

There is a separate cipher list for SSHv1 and SSHv2 for both client and server.

The default client cipher list for SSHv1 includes all supported algorithms in the following preference order:

cipher 200 name 3des
cipher 205 name blowfish
cipher 210 name des

The default server cipher list for SSHv1 includes algorithms in the following preference order:

cipher 200 name 3des
cipher 205 name blowfish

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

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 210 name blowfish-cbc
cipher 215 name cast128-cbc
cipher 220 name arcfour
cipher 225 name aes192-cbc
cipher 230 name aes256-cbc
cipher 235 name rijndael-cbc

Use the following CLI to configure the client and server cipher list.

configure system security ssh client-cipher-list

client-cipher-list protocol-version <version>

<version> : [1..2]

configure system security ssh client-cipher-list cipher

cipher <index> name <cipher-name>

no cipher <index>

<index> : [1..255]

aes192-cbc|aes256-cbc|rijndael-cbc

configure system security ssh server-cipher-list

server-cipher-list protocol-version <version>

<version> : [1..2]

configure system security ssh server-cipher-list cipher

no cipher <index>

cipher <index> name <cipher-name>

<index> : [1..255]

aes192-cbc|aes256-cbc|rijndael-cbc

2.6.4. Exponential Login Backoff

A malicious user may attempt to gain CLI access by means of a dictionary attack, in which a script is used to attempt automatic logins as an “admin” user and a dictionary list is used to test all possible passwords. By using the exponential-backoff feature in the config>system>login-control context, the 7210 SAS increases the delay between login attempts exponentially to mitigate attacks.

When a user attempts to log into a router using a Telnet or an SSH session, the system allows a limited number of attempts to enter the correct password. The interval between the unsuccessful attempts change after each try (1, 2, and 4 seconds). If user lockout is configured on the system, the user will be locked out when the number of unsuccessful attempts is exceeded.

However, if lockout is not configured, three password entry attempts are allowed in the first session after the first failure, at fixed 1, 2 and 4 second intervals, and then the session terminates. Users do not have an unlimited number of login attempts per session. After each failed password attempt, the wait period becomes longer until the maximum number of attempts is reached.

The 7210 SAS terminates after four unsuccessful attempts. A wait period is never longer than 4 seconds. The periods are fixed and restart in subsequent sessions.

The config system login-control [no] exponential-backoff command works in conjunction with the config system security password attempts command, which is also a system wide configuration.

For example:

*A:ALA-48>config>system# security password attempts

- attempts <count> [time <minutes1>] [lockout <minutes2>]

- no attempts

<count> : [1..64]

<minutes1> : [0..60]

<minutes2> : [0..1440]

Exponential backoff applies to any user and by any login method such as console, SSH and Telnet.

Refer to Configuring Login Controls. The commands are described in Login, Telnet, SSH and FTP Commands.

2.6.5. User Lockout

When a user exceeds the maximum number of attempts allowed (the default is 3 attempts) during a certain period of time (the default is 5 minutes) the account used during those attempts will be locked out for a preconfigured lock-out period (the default is 10 minutes).

An security event log will be generated as soon as a user account has exceeded the number of allowed attempts and the show>system>security>user command can be used to display the total number of failed attempts per user.

The account will be automatically re-enabled as soon as the lock-out period has expired.

2.6.6. Encryption

Data Encryption Standard (DES) and Triple DES (3DES) are supported for encryption.

DES is a widely-used method of data encryption using a private (secret) key. Both the sender and the receiver must know and use the same private key.
3DES is a more secure version of the DES protocol.

2.6.7. 802.1x Network Access Control

The 7210 SAS supports network access control of client devices (PCs, STBs, etc.) on an Ethernet network using the IEEE. 802.1x standard. 802.1x is known as Extensible Authentication Protocol (EAP) over a LAN network or EAPOL.

2.6.8. TCP Enhanced Authentication Option

The TCP Enhanced Authentication Option, currently covered in draft-bonica-tcp-auth-05.txt, Authentication for TCP-based Routing and Management Protocols, extends the previous MD5 authentication option to include the ability to change keys without tearing down the session, and allows for stronger authentication algorithms to be used.

The TCP Enhanced Authentication Option is a TCP extension that enhances security for BGP, LDP and other TCP-based protocols. This includes the ability to change keys in a BGP or LDP session seamlessly without tearing down the session. It is intended for applications where secure administrative access to both the end-points of the TCP connection is available.

TCP peers can use this extension to authenticate messages passed between one another. This strategy improves upon current practice, which is described in RFC 2385, Protection of BGP Sessions via the TCP MD5 Signature Option. Using this new strategy, TCP peers can update authentication keys during the lifetime of a TCP connection. TCP peers can also use stronger authentication algorithms to authenticate routing messages.

2.6.8.1. Packet Formats

Figure 4 shows the packet format for the Enhanced Authentication Option.

Figure 4: Packet Formats

Option Syntax

Kind: 8 bits
The Kind field identifies the TCP Enhanced Authentication Option. This value will be 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 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. 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.

2.6.8.2. Keychain

A keychain is a set of up to 64 keys, where each key is {A[i], K[i], V[i], S[i], T[i], S'[i], T'[i]} as described in draft-bonica-tcp-auth-05.txt, Authentication for TCP-based Routing and Management Protocols. They keys can be assigned to both sides of a LDP peer.The individual keys in a keychain have a begin- and end-time indicating when to use this key.

These fields map to the CLI tree as described in Table 9.

Table 9: Keychain Mapping

Field	Definition	CLI
i	The key identifier expressed as an integer (0...63)	config>system>security>keychain>direction>bi>entry config>system>security>keychain>direction>uni>receive>entry config>system>security>keychain>direction>uni>send>entry
A[i]	Authentication algorithm to use with key[i]	config>system>security>keychain>direction>bi>entry with algorithm algorithm parameter. config>system>security>keychain>direction>uni>receive>entry with algorithm algorithm parameter. config>system>security>keychain>direction>uni>send>entry with algorithm algorithm parameter.
K[i]	Shared secret to use with key[i].	config>system>security>keychain>direction>uni>receive>entry with shared secret parameter config>system>security>keychain>direction>uni>send>entry with shared secret parameter config>system>security>keychain>direction>bi>entry with shared secret parameter
V[i]	A vector that determines whether the key[i] is to be used to generate MACs for inbound segments, outbound segments, or both.	config>system>security>keychain>direction
S[i]	Start time from which key[i] can be used by sending TCPs.	config>system>security>keychain>direction>bi>entry>begin-time config>system>security>keychain>direction>uni>send>entry >begin-time
T[i]	End time after which key[i] cannot be used by sending TCPs.	Inferred by the begin-time of the next key (youngest key rule).
S'[i]	Start time from which key[i] can be used by receiving TCPs.	config>system>security>keychain>direction>bi>entry>begin-time config>system>security>keychain>direction>bi>entry>tolerance config>system>security>keychain>direction>uni>receive>entry >begin-time config>system>security>keychain>direction>uni>receive>entry >tolerance
T'[i]	End time after which key[i] cannot be used by receiving TCPs	config>system>security>keychain>direction>uni>receive>entry>end-time

2.7. Configuration Notes

This section describes security configuration guidelines and caveats.

2.7.1. General

If a RADIUS or a TACACS+ server is not configured, then password, profiles, and user access information must be configured on each router in the domain.
If a RADIUS authorization is enabled, then VSAs must be configured on the RADIUS server.