2. Security

This chapter provide 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 user’s name 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.

7210 SAS supports the following security features:

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

The following figure shows end-user access requests sent to a RADIUS server. After validating the user names and passwords, the RADIUS server returns an access-accept message to the users on ALA-1 and ALA-2. The user name and password from ALA-3 could not be authenticated, thus access was denied.

Figure 1:  RADIUS requests and responses 

2.1.1. Authentication

Authentication validates a user name 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. It is recommended that the same user databases be maintained for RADIUS servers in order 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 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 router.

2.1.1.1. Local authentication

Local authentication uses user names and passwords to authenticate login attempts. The user names 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 user names 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:

  1. RADIUS operator management
  2. RADIUS authentication for Enhanced Subscriber Management
  3. RADIUS accounting for Enhanced Subscriber Management
  4. RADIUS PE-discovery

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

The RADIUS server selection algorithm can work in two 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 is Up and a valid response is received within a timeout period that is configurable by the retry parameter on the RADIUS policy level.

A server is treated as not-reachable when the operational state is Down and the following occurs:

  1. a timeout
    If a number of consecutive timeouts are encountered for a specific server. This number is configurable by the retry parameter at the RADIUS policy level.
  2. a send failed
    If a packet cannot be sent to the RADIUS server because the forwarding path towards the RADIUS server is broken (for example, the route is not available or the interface is shut down), no retry mechanism is invoked and the next server in line is immediately 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 have been sent to the server, it is not certain yet whether the server is actually reachable).

2.1.1.2.1.4. Application-specific behavior

2.1.1.2.1.4.1. 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 user name. 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.

2.1.1.2.1.4.2. RADIUS authentication

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.

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

2.1.1.2.1.4.4. RADIUS PE-discovery

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.

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 given 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.1.4. Password hashing

Note:

This feature is supported on all 7210 SAS platforms as described in this document, except the 7210 SAS-D.

The 7210 SAS supports two algorithms for user password hashing: bcrypt, which is the default algorithm, and PBKDF2. The PBKDF2 algorithm can use SHA2 (SHA-256) for hashing.

The password hashing algorithm can be configured using the configure system security password hashing command. The configured algorithm hashes all user passwords.

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

  1. The node checks the stored password and notes its hash algorithm.
  2. The password entered by the user is hashed with the noted algorithm, and the node compares the hash with the stored user password hash.
  3. If the entered and stored passwords are the same, and if the hash algorithm of the stored user password is different from the hash algorithm of the system password, the user is prompted to enter a new password two 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 the admin save command. If the admin save command is not executed, on the next reboot the hash algorithm of the stored user password might be different from 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 this 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.

2.1.2. Authorization

The 7210 SAS supports local, RADIUS, and TACACS+ authorization to control the actions of specific users by applying a profile based on user name and password configurations once network access is granted. The profiles are configured locally as well as VSAS on the RADIUS server. See Vendor-specific attributes (VSAS).

Once 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:

  1. download the user profile to the router
  2. 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 lists the following scenarios:

  1. Remote (RADIUS) authorization cannot be performed if authentication is done locally (on the router).
  2. 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. User names can be configured on the RADIUS server. User names 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 five).

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

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

2.1.3.2. TACACS+ accounting

The 7210 SAS 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. For example, 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.

The following table 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 if 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’s 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 user name 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 user name 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.

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

  1. In-band traffic extracted from the 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. anti-spoofing, uRPF (supported only on the 7210 SAS-K 3SFP+ 8C)
    1. CPM features:
      1. centralized CPU protection
  2. out-of-band and in-band traffic:
    1. 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 that allows traffic from trusted IP subnets for protocols and ports actively used in the router and explicitly drops other traffic.

The following table 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 that is ingressing the router and is sent to the CPM.

Note:

Out-of-band management ports are not supported on the 7210 SAS platforms as described in this guide.

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

SAS-Dxp

SAS-K 2F2C2T

SAS-K 2F6C4T

SAS-K 3SFP+ 8C

In-band

In-band

In-band

In-band

In-band

BFD application

3784

UDP

BFD control 1 hop BFD

✓

✓

3785

UDP

BFD echo

✓

✓

4784

UDP

BFD control multi-hop

✓

✓

BGP application

179

TCP

BGP: server terminated TCP sessions

✓

✓

179

TCP

BGP: client responses for initiated TCP session

✓

✓

DHCPv4 application

67

67

UDP

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

✓

✓

✓

✓

✓

68

67

UDP

DHCPv4: client to relay agent; client to server

✓

✓

✓

✓

✓

67

68

UDP

DHCPv4: relay agent to server; relay agent to client

✓

✓

✓

✓

✓

DHCPv6 application

546

547

UDP

DHCPv6: client to server; client to relay agent

✓

✓

547

546

UDP

DHCPv6: server to relay agent; relay agent to server; relay agent to relay agent

✓

✓

DNS application

53

UDP

DNS Client

✓

✓

✓

✓

✓

FTP application

20

TCP

FTP server data and active FTP client

✓

✓

✓

✓

✓

21

TCP

FTP server control

✓

✓

✓

✓

✓

20

TCP

FTP client data

✓

✓

✓

✓

✓

21

TCP

FTP client control

✓

✓

✓

✓

✓

GRE application

N/A

N/A

GRE

GRE

✓

✓

ICMP application

N/A

N/A

ICMP

ICMP

✓

✓

✓

✓

✓

IGMP application

N/A

N/A

IGMP

IGMP

✓

✓

✓

✓

✓

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

✓

✓

MC-APS application

1025

UDP

Multi-chassis LAG

✓

✓

MCS application

45067

TCP

Multi-chassis synchronization: terminated TCP session

✓

✓

45067

TCP

Multi-chassis synchronization: responses for initiated TCP session

✓

✓

NETCONF application

830

TCP

NETCONF

✓

✓

NTP application

123

UDP

NTP server

✓

✓

✓

✓

✓

123

UDP

NTP client

✓

✓

✓

✓

✓

OAM application

3503

UDP

LSP ping

✓

✓

33408 to 33535

UDP

OAM traceroute

✓

✓

OSPF application

N/A

N/A

OSPF

OSPF

✓

✓

PCEP application

4189

TCP

Path Computation Element Protocol (PCEP)

✓

✓

PIM application

3232

UDP

PIM MDT

✓

✓

N/A

N/A

PIM

PIM

✓

✓

PTP application

319

UDP

1588 PTP event

✓

✓

✓

✓

✓

320

UDP

1588 PTP general

✓

✓

✓

✓

✓

RADIUS application

1812

UDP

Radius authentication

✓

✓

✓

✓

✓

1813

UDP

Radius accounting

✓

✓

✓

✓

✓

RSVP application

N/A

N/A

RSVP

RSVP

✓

✓

SNMP application

161

UDP

SNMP server; SET and GET commands

✓

✓

✓

✓

✓

SSH application

22

TCP

SSH server and terminated TCP session

✓

✓

✓

✓

✓

22

TCP

SSH client and responses for initiated TCP sessions

✓

✓

✓

✓

✓

TACACS application

49

TCP

TACACS client and responses for initiated TCP sessions

✓

✓

✓

✓

✓

TELNET application

23

TCP

TELNET server

✓

✓

✓

✓

✓

TWAMP application

862

TCP

TWAMP control: terminated TCP session

✓

✓

✓

✓

✓

Any

UDP

TWAMP test

✓

✓

✓

✓

✓

1 to 65535

UDP

TWAMP light (per router instance)

✓

✓

✓

✓

VRRP application

N/A

N/A

VRRP

VRRP

✓

✓

2.3.2. Management Access Filter

Note:

IPv6 Management Access Filters (MAFs) are not supported on the 7210 SAS-K 2F1C2T.

MAFs 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:

  1. Each MAF policy is an ordered list of entries; therefore, entries must be sequenced correctly from the most to the least explicit.
  2. 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).
  3. Any match criteria not explicitly defined is ignored during a match.
  4. A MAF filter policy entry defined without a match criteria is inactive.
  5. A MAF filter policy entry with match criteria defined but no action configured inherits the default action defined at the management-access-filter level.
  6. 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

The following table 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 packets.

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 the 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. Centralized CPU protection

The 7210 SAS provides rate limiting mechanisms to protect the CPM/CFM processing resources of the router. Centralized CPU protection is 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.

When it is configured on a node, 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 pre-defined 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).

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 discussed 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 in order 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:

  1. 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.
  2. 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:
    1. The authentication-order parameters configured on the router must include the local keyword.
    2. The user name may or may not be configured on the router.
    3. The user must be authenticated by the RADIUS server

Up to eight 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 above mentioned conditions are not met, then access to the router is denied and a failed login event/trap is written to the security log.

  1. 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.
  2. timetra-cmd <match-string>
    Configures a command or command subtree as the scope for the match condition.
  3. The command and all subordinate commands in subordinate command levels are specified.
  4. Configure from most specific to least specific. The 7210 SAS implementation exits on the first match, subordinate levels cannot be modified with subsequent action commands. Subordinate level VSAS must be entered prior to this entry to be effective.
  5. All commands at and below the hierarchy level of the matched command are subject to the timetra-action VSA.
  6. 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:

  1. timetra-action <deny | permit>
    Causes the permit or deny action to be applied to all match strings specified since the last timetra-action VSA.
  2. 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:).
  3. 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.
  4. 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:

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

If all conditions listed above 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. User (VSA) configuration example

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. ruser1’s 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

This sections describes security features supported on the 7210 SAS.

2.6.1. Security algorithms

Note:

This section applies only to the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C.

The following table lists the security algorithms supported per protocol.

Table 9:    Security algorithm support per protocol

Protocol

Clear

text

MD5

HMAC-

MD5

HMAC-

SHA1-96

HMAC-

SHA1

HMAC-

SHA256

AES-128-

CMAC-96

OSPF

✓

✓

✓

✓

✓

IS-IS

✓

✓

✓

✓

RSVP

✓

✓

✓

BGP

✓

✓

LDP

✓

✓

✓

2.6.2. 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 supports Secure Shell (SSH) Version 2 (SSH2). SSH1 and SSH2 are different protocols and encrypt at different parts of the packets. SSH1 uses a 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.

Note:

  1. SSH for IPv4 is supported on all platforms as described in this document.
  2. SSH for IPv6 is supported on all platforms as described in this document, except the 7210 SAS-K 2F1C2T.

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.3. SSH PKI authentication

Note:

This feature is supported on all 7210 SAS platforms as described in this document, except the 7210 SAS-D.

The SSH server supports a public key authentication provided that 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:

  1. A user typically reuses the same password with multiple servers. If the password is compromised, the user must reconfigure the password on all affected servers.
  2. A password is not transmitted between the client and server using PKI. Instead the sensitive information (the private key) is kept on the client. Consequently, the password is less likely to be compromised.

The 7210 SAS supports server-side SSHv2 public key authentication, but does not include a key-generation utility.

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 only local authentication. PKI authentication is not supported on TACACS+ or RADIUS.

2.6.3.1. User public key generation

Before SSH can be used with PKI, the client must generate a public/private key pair. This is typically supported by the SSH client software. For example, PuTTY supports a utility called PuTTYGen that generates key pairs.

The 7210 SAS currently supports only Rivest, Shamir, and Adleman (RSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) user public keys.

If the SSH client software uses PuTTY, it must first generate a key pair using PuTTYGen. The client sets the key type to SSH-2 RSA and configures the number of bits to be used for the key. The client can also configure a passphrase to store the key locally in encrypted form. If the passphrase is configured, it acts as a password that the client must enter to use the private key. If a passphrase is not configured, the private key is stored in plain text locally.

Next, use the config>system>security>user>public-keys command to configure the public key for the client (the public key is obtained as part of the key pair). On the 7210 SAS, the user can program the public key using CLI commands (accessed through Telnet/SSH) or SNMP.

Note:

The preceding process to generate a key pair is an example only. This process is not executed on a 7210 SAS node, but on a third-party node acting as the SSH client or any other node.

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

  1. client list
  2. server list

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

  1. mac 200 name hmac-sha2-512
  2. mac 210 name hmac-sha2-256
  3. mac 215 name hmac-sha1
  4. mac 220 name hmac-sha1-96
  5. mac 225 name hmac-md5
  6. mac 230 name hmac-ripemd160
  7. mac 235 name hmac-ripemd160-openssh-com
  8. 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.5. 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:

  1. cipher 200 name 3des
  2. cipher 205 name blowfish
  3. cipher 210 name des

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

  1. cipher 200 name 3des
  2. cipher 205 name blowfish

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

  1. cipher 190 name aes256-ctr
  2. cipher 192 name aes192-ctr
  3. cipher 194 name aes128-ctr
  4. cipher 200 name aes128-cbc
  5. cipher 205 name 3des-cbc
  6. cipher 210 name blowfish-cbc
  7. cipher 215 name cast128-cbc
  8. cipher 220 name arcfour
  9. cipher 225 name aes192-cbc
  10. cipher 230 name aes256-cbc
  11. 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]
 <cipher-name>        : aes128-ctr|aes192-ctr|aes256-ctr|des|3des|blowfish|
                        3des-cbc|blowfish-cbc|cast128-cbc|arcfour|aes128-cbc|
                        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]
 <cipher-name>        : aes128-ctr|aes192-ctr|aes256-ctr|des|3des|blowfish|
                        3des-cbc|blowfish-cbc|cast128-cbc|arcfour|aes128-cbc|
                        aes192-cbc|aes256-cbc|rijndael-cbc

2.6.6. KEX client and server list

Note:

This feature is supported on all 7210 SAS as described in this document, except the 7210 SAS-D.

The 7210 SAS supports key exchange (KEX) client and server lists. The user can add or remove the KEX client or server algorithms that the SSH application negotiates using an SSHv2 phase one handshake. The KEX list is an index list with the lower index having higher preference in the SSH negotiation. The lowest indexed algorithm in the list is negotiated first in SSH and is at the top of the negotiation list to the peer.

By default, the KEX list is empty and a hard-coded list that includes all supported algorithms in the following preference order is used:

  1. kex 200 name diffie-hellman-group16-sha512
  2. kex 210 name diffie-hellman-group14-sha256
  3. kex 215 name diffie-hellman-group14-sha1
  4. kex 220 name diffie-hellman-group-exchange-sha1
  5. kex 225 name diffie-hellman-group1-sha1

As soon as the user configures the KEX list, the 7210 SAS starts using the algorithms from the user-defined KEX list instead of the hard-coded list. To revert to the hard-coded list, the user must remove all configured KEX indexes until the list is empty.

Use the following CLI to configure the cipher or MAC server and client lists.

configure system security ssh server-kex-list kex
   kex <index> name <kex-name>
   no kex <index>
 
configure system security ssh client-kex-list kex
   kex <index> name <kex-name>
   no kex <index>
 
<index>              : [1..255]
<kex-name>           : diffie-hellman-group14-sha1| diffie-hellman-group14-sha256|
                       diffie-hellman-group16-sha512|diffie-hellman-group-exchange-
                       sha1| diffie-hellman-group1-sha1

2.6.7. Exponential login back-off

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.

See Configuring login controls for more information. The related commands are described in Login, Telnet, SSH and FTP commands.

2.6.8. User lockout

When a user exceeds the maximum number of attempts allowed (the default is three 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.9. Encryption

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

  1. 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.
  2. 3DES is a more secure version of the DES protocol.

2.6.10. 802.1x network access control

The 7210 SAS supports network access control of client devices (PCs, STBs, and so on.) 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.11. 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 normally 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.11.1. Packet formats

The following figure shows the TCP Enhanced Authentication Option packet format.

Figure 3:  Packet format 

Option Syntax

  1. Kind: 8 bits
    The Kind field identifies the TCP Enhanced Authentication Option. This value will be assigned by IANA.
  2. 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.
  3. 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.
  4. K-Bit: 1 bit
    This bit is reserved for future enhancement. Its value MUST be equal to zero.
  5. Alg ID: 6 bits
    The Alg ID field identifies the MAC algorithm.
  6. Res: 2 bits
    These bits are reserved. They MUST be set to zero.
  7. Key ID: 6 bits
    The Key ID field identifies the key that was used to generate the message digest.
  8. 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.11.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. The keys can be assigned to both sides of an LDP peer.The individual keys in a keychain have a begin-time and end-time indicating when to use this key.

These fields map to the CLI tree as described in the following figure.

Table 10:  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 caveats.

2.7.1. General

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