Configuring portal authentication

HP A8800 Routers
Security
Configuration Guide
Part number: 5998-1747
Software version: A8800-CMW520-R3627
Document version: 6W102-20130906
Legal and notice information
© Copyright 2011-2013 Hewlett-Packard Development Company, L.P.
No part of this documentation may be reproduced or transmitted in any form or by any means without
prior written consent of Hewlett-Packard Development Company, L.P.
The information contained herein is subject to change without notice.
HEWLETT-PACKARD COMPANY MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS
MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not be liable for errors contained
herein or for incidental or consequential damages in connection with the furnishing, performance, or
use of this material.
The only warranties for HP products and services are set forth in the express warranty statements
accompanying such products and services. Nothing herein should be construed as constituting an
additional warranty. HP shall not be liable for technical or editorial errors or omissions contained
herein.
Contents
Security overview ························································································································································· 1 Network security threats ··················································································································································· 1 Network security services ················································································································································· 1 Network security technologies ········································································································································· 2 Identity authentication ·············································································································································· 2 Access security·························································································································································· 2 Data security ····························································································································································· 3 Firewall and connection control······························································································································3 Attack detection and protection ······························································································································ 4 Other security technologies ····································································································································· 4 Configuring AAA ························································································································································· 1 AAA overview ··································································································································································· 1 RADIUS ······································································································································································ 2 HWTACACS ····························································································································································· 7 Domain-based user management ··························································································································· 9 AAA for MPLS L3VPNs ········································································································································· 10 Protocols and standards ······································································································································· 11 RADIUS attributes ·················································································································································· 11 FIPS compliance ····························································································································································· 14 AAA configuration considerations and task list ·········································································································· 14 Configuring AAA schemes ············································································································································ 16 Configuring local users ········································································································································· 16 Configuring RADIUS schemes ······························································································································ 21 Configuring HWTACACS schemes ····················································································································· 33 Configuring AAA methods for ISP domains ················································································································ 39 Configuration prerequisites ·································································································································· 40 Creating an ISP domain ······································································································································· 40 Configuring ISP domain attributes ······················································································································· 41 Configuring AAA authentication methods for an ISP domain ·········································································· 42 Configuring AAA authorization methods for an ISP domain ··········································································· 44 Configuring AAA accounting methods for an ISP domain ··············································································· 45 Tearing down user connections ···································································································································· 47 Displaying and maintaining AAA ································································································································ 47 AAA configuration examples ········································································································································ 48 RADIUS authentication/authorization for Telnet/SSH users ············································································· 48 Local authentication/authorization for FTP/Telnet users ··················································································· 51 AAA for PPP users by an HWTACACS server ··································································································· 52 Network requirements ··········································································································································· 52 RADIUS level switching authentication for Telnet users ····················································································· 54 AAA for portal users by a RADIUS server ·········································································································· 58 Troubleshooting AAA ···················································································································································· 66 Troubleshooting RADIUS······································································································································· 66 Troubleshooting HWTACACS······························································································································ 67 802.1X overview ······················································································································································· 68 802.1X architecture ······················································································································································· 68 Controlled/uncontrolled port and port authorization status ······················································································ 68 802.1X-related protocols ·············································································································································· 69 Packet formats ························································································································································ 70 i
EAP over RADIUS ·················································································································································· 71 Initiating 802.1X authentication ··································································································································· 71 802.1X client as the initiator································································································································ 71 Access device as the initiator ······························································································································· 72 802.1X authentication procedures ······························································································································ 72 Comparing EAP relay and EAP termination ······································································································· 73 EAP relay ································································································································································ 73 EAP termination ····················································································································································· 75 Configuring 802.1X ·················································································································································· 77 HP implementation of 802.1X ······································································································································ 77 Access control methods ········································································································································ 77 Using 802.1X authentication with other features ······························································································ 77 Configuration prerequisites ··········································································································································· 82 802.1X configuration task list······································································································································· 82 Enabling 802.1X ···························································································································································· 82 Enabling EAP relay or EAP termination ······················································································································· 83 Setting the port authorization state ······························································································································ 84 Specifying an access control method ·························································································································· 84 Setting the maximum number of concurrent 802.1X users on a port ······································································· 85 Setting the maximum number of authentication request attempts ············································································· 85 Setting the 802.1X authentication timeout timers ······································································································· 85 Configuring the online user handshake function ········································································································ 86 Configuration guidelines ······································································································································ 86 Configuration procedure ······································································································································ 86 Enabling the proxy detection function ························································································································· 87 Prerequisites ··························································································································································· 87 Configuration procedure ······································································································································ 87 Configuring the authentication trigger function ·········································································································· 88 Configuration guidelines ······································································································································ 88 Configuration procedure ······································································································································ 88 Specifying a mandatory authentication domain on a port························································································ 89 Configuring the quiet timer ··········································································································································· 89 Enabling the periodic online user re-authentication function····················································································· 89 Configuring an 802.1X guest VLAN ··························································································································· 90 Configuration guidelines ······································································································································ 90 Configuration prerequisites ·································································································································· 91 Configuration procedure ······································································································································ 91 Configuring an Auth-Fail VLAN ···································································································································· 91 Configuration guidelines ······································································································································ 91 Configuration prerequisites ·································································································································· 91 Configuration procedure ······································································································································ 92 Configuring an 802.1X critical VLAN ················································································································ 92 Specifying supported domain name delimiters··········································································································· 93 Referencing a COPS scheme ········································································································································ 93 Displaying and maintaining 802.1X ··························································································································· 94 802.1X authentication configuration example ··········································································································· 94 Network requirements ··········································································································································· 94 Configuration procedure ······································································································································ 95 Verifying the configuration ··································································································································· 96 802.1X guest VLAN and VLAN assignment configuration example ········································································ 96 Network requirements ··········································································································································· 96 Configuration procedure ······································································································································ 97 Verifying the configuration ··································································································································· 99 ii
Configuring MAC authentication ··························································································································· 100 MAC authentication overview ···································································································································· 100 User account policies ·········································································································································· 100 Authentication methods······································································································································· 100 MAC authentication timers ································································································································· 101 Using MAC authentication with VLAN assignment ·································································································· 101 MAC authentication configuration task list ··············································································································· 101 Basic configuration for MAC authentication ············································································································· 102 Configuration prerequisites ································································································································ 102 Configuration procedure ···································································································································· 102 Specifying an authentication domain for MAC authentication users ····································································· 103 Displaying and maintaining MAC authentication ···································································································· 104 MAC authentication configuration examples ············································································································ 104 Local MAC authentication configuration example··························································································· 104 RADIUS-based MAC authentication configuration example··········································································· 106 Configuring portal authentication ·························································································································· 108 Overview······································································································································································· 108 Extended portal functions ··································································································································· 108 Portal system components ··································································································································· 108 Portal authentication modes ······························································································································· 110 Portal authentication process ····························································································································· 111 Portal authentication across VPNs ····················································································································· 112 Portal configuration task list ········································································································································ 113 Basic portal configuration ··········································································································································· 114 Configuration prerequisites ································································································································ 114 Specifying a portal server for portal authentication ························································································ 114 Enabling portal authentication ··························································································································· 115 Controlling access of portal users ······························································································································ 116 Configuring a portal-free rule····························································································································· 116 Configuring an authentication subnet ··············································································································· 116 Setting the maximum number of online portal users ························································································ 117 Specifying an authentication domain for portal users ····················································································· 117 Specifying NAS-Port-Type for an interface ················································································································ 118 Specifying a source IP address for outgoing portal packets ··················································································· 118 Specifying an auto redirection URL for authenticated portal users ········································································· 119 Configuring portal detection functions ······················································································································· 119 Configuring the portal server detection function ······························································································ 119 Configuring portal user information synchronization ······················································································ 121 Logging out portal users ·············································································································································· 122 Displaying and maintaining portal ···························································································································· 122 Portal configuration examples ···································································································································· 123 Configuring re-DHCP portal authentication ······································································································ 123 Configuring cross-subnet portal authentication ································································································ 125 Configuring re-DHCP portal authentication with extended functions ···························································· 127 Configuring cross-subnet portal authentication with extended functions······················································· 129 Configuring portal server detection and portal user information synchronization ······································· 131 Cross-subnet portal authentication across VPNs ······························································································ 137 Troubleshooting portal ················································································································································· 139 Inconsistent keys on the router (access device) and the portal server ··························································· 139 Incorrect server port number on the router (access device) ············································································ 140 Configuring password control ································································································································ 141 Overview······································································································································································· 141 FIPS compliance ··························································································································································· 143 iii
Password control configuration task list ····················································································································· 143 Configuring password control ···································································································································· 144 Enabling password control ································································································································· 144 Setting global password control parameters ···································································································· 145 Setting user group password control parameters ···························································································· 146 Setting local user password control parameters ······························································································ 146 Setting super password control parameters ····································································································· 147 Setting a local user password in interactive mode ·························································································· 148 Displaying and maintaining password control ········································································································· 148 Password control configuration example ·················································································································· 149 Managing public keys ············································································································································ 152 Overview······································································································································································· 152 FIPS compliance ··························································································································································· 152 Public key configuration task list································································································································· 153 Configuring a local asymmetric key pair on the local device················································································· 153 Creating a local asymmetric key pair ··············································································································· 153 Displaying or exporting the local host public key ··························································································· 154 Destroying a local asymmetric key pair ············································································································ 155 Specifying the peer public key on the local device·································································································· 155 Displaying and maintaining public keys ··················································································································· 156 Public key configuration examples ····························································································································· 157 Manually specifying the peer public key on the local router ········································································· 157 Importing a public key from a public key file··································································································· 159 Configuring IPsec ···················································································································································· 162 Overview······································································································································································· 162 Basic concepts ····················································································································································· 162 IPsec for IPv6 routing protocols ·························································································································· 164 Protocols and standards ····································································································································· 165 FIPS compliance ··························································································································································· 165 Implementing IPsec ······················································································································································· 165 Implementing ACL-based IPsec ··································································································································· 165 Feature restrictions and guidelines ···················································································································· 165 ACL-based IPsec configuration task list ············································································································· 166 Configuring an ACL ············································································································································ 166 Configuring an IPsec transform set ···················································································································· 167 Configuring an IPsec policy ······························································································································· 169 Applying an IPsec policy group to an interface ······························································································· 173 Configuring the IPsec session idle timeout ········································································································ 174 Enabling ACL checking for de-encapsulated IPsec packets ············································································ 174 Configuring the IPsec anti-replay function ········································································································ 174 Configuring packet information pre-extraction ································································································ 175 Enabling invalid SPI recovery ···························································································································· 176 Configuring IPsec for IPv6 routing protocols ············································································································· 176 Displaying and maintaining IPsec ······························································································································ 177 IPsec configuration examples······································································································································ 177 Configuring a manual mode IPsec tunnel for IPv4 packets ············································································ 177 Configuring an IKE-based IPsec tunnel for IPv4 packets ················································································· 180 Configuring IPsec for RIPng ································································································································ 182 Configuring IKE ······················································································································································· 186 Overview······································································································································································· 186 IKE security mechanism······································································································································· 186 IKE operation ······················································································································································· 187 IKE functions ························································································································································· 187 iv
Relationship between IKE and IPsec ·················································································································· 188 Protocols and standards ····································································································································· 188 Configuration task list for IKE ····································································································································· 188 Configuring a name for the local security gateway ································································································· 189 Configuring an IKE proposal ······································································································································ 189 Configuring an IKE peer·············································································································································· 190 Setting keepalive timers ··············································································································································· 192 Setting the NAT keepalive timer ································································································································· 193 Configuring a DPD detector ········································································································································ 193 Disabling next payload field checking ······················································································································ 194 Displaying and maintaining IKE ································································································································· 194 IKE configuration examples ········································································································································ 194 Configuring main mode IKE with pre-shared key authentication ··································································· 194 Troubleshooting IKE ····················································································································································· 197 Invalid user ID ······················································································································································ 197 Proposal mismatch ·············································································································································· 197 Failing to establish an IPsec tunnel ···················································································································· 198 ACL configuration error ······································································································································ 198 Configuring SSH ····················································································································································· 199 Overview······································································································································································· 199 How SSH works ··················································································································································· 199 SSH authentication ·············································································································································· 200 SSH support for MPLS L3VPN ···························································································································· 201 FIPS compliance ··························································································································································· 201 Configuring the device as an SSH server·················································································································· 202 SSH server configuration task list ······················································································································ 202 Generating local DSA or RSA key pairs ··········································································································· 202 Enabling the SSH server function······················································································································· 203 Enabling the SFTP server function ······················································································································ 203 Configuring the user interfaces for SSH clients ································································································ 203 Configuring a client's host public key ··············································································································· 204 Configuring an SSH user ···································································································································· 205 Setting the SSH management parameters ········································································································ 206 Configuring the device as an Stelnet client ··············································································································· 207 Stelnet client configuration task list ···················································································································· 207 Specifying a source IP address or source interface for the Stelnet client ······················································ 208 Enabling/disabling first-time authentication ····································································································· 208 Establishing a connection to an Stelnet server ································································································· 209 Configuring the device as an SFTP client ·················································································································· 209 SFTP client configuration task list ······················································································································· 209 Specifying a source IP address or source interface for the SFTP client ························································· 210 Establishing a connection to an SFTP server ···································································································· 210 Working with SFTP directories ··························································································································· 211 Working with SFTP files ······································································································································ 212 Displaying help information ······························································································································· 212 Terminating the connection with the SFTP server ····························································································· 213 Configuring the device as an SCP client ··················································································································· 213 SCP client configuration task list ························································································································ 213 Transferring files with an SCP server ················································································································· 213 Displaying and maintaining SSH ······························································································································· 214 Stelnet configuration examples ··································································································································· 215 When the router acts as an Stelnet server for password authentication ······················································· 215 When the router acts as an Stelnet server for publickey authentication ······················································· 217 When the router acts as an Stelnet client for password authentication ························································ 222 v
When the router acts as an Stelnet client for publickey authentication ························································· 225 SFTP configuration examples ······································································································································ 227 When the router acts as an SFTP server for password authentication ·························································· 227 When the router acts as an SFTP client for publickey authentication ···························································· 229 SCP configuration examples ······································································································································· 233 File transfer with password authentication ······································································································· 233 Configuring packet-filter firewall ···························································································································· 235 Overview······································································································································································· 235 Configuring packet filtering ········································································································································ 235 Configuring port mapping ·········································································································································· 236 Displaying packet filter information ··························································································································· 237 Packet-filter firewall configuration example··············································································································· 237 Configuring ALG ····················································································································································· 239 ALG overview ······························································································································································· 239 Enabling ALG ······························································································································································· 240 Configuring a port mapping ······································································································································· 241 Displaying ALG ···························································································································································· 241 ALG configuration examples ······································································································································ 241 FTP ALG configuration example ························································································································ 241 SIP/H.323 ALG configuration example ··········································································································· 242 NBT ALG configuration example ······················································································································· 243 Managing sessions ················································································································································· 245 Overview······································································································································································· 245 Session management principle ·························································································································· 245 Session management implementation ··············································································································· 245 Session management configuration task list·············································································································· 246 Setting session aging times based on protocol state ······················································································· 246 Configuring session aging times based on application layer protocol type ················································ 246 Enabling checksum verification·························································································································· 247 Specifying persistent sessions ···························································································································· 247 Clearing sessions manually ································································································································ 248 Configuring session logging ······································································································································· 248 Enabling session logging ···································································································································· 248 Setting the session logging threshold ················································································································ 248 Configuring session log export ·························································································································· 249 Displaying and maintaining session management ··································································································· 249 Configuring TCP and ICMP attack protection ······································································································· 251 Overview······································································································································································· 251 Enabling the SYN Cookie feature ······························································································································ 251 Enabling protection against Naptha attacks ············································································································· 252 Displaying and maintaining TCP and ICMP attack protection ················································································ 252 Configuring IP source guard ·································································································································· 254 Overview······································································································································································· 254 Dynamic IP source guard entries ································································································································ 254 Enabling IPv4 source guard on a port ······················································································································· 255 Displaying IP source guard ········································································································································· 255 IP source guard configuration example ····················································································································· 256 Troubleshooting IP source guard ································································································································ 257 Configuring ARP attack protection························································································································· 258 Overview······································································································································································· 258 ARP attack protection configuration task list ············································································································· 258 vi
Configuring ARP defense against IP packet attacks ································································································· 259 Introduction ·························································································································································· 259 Configuring ARP source suppression ················································································································ 259 Enabling ARP blackhole routing ························································································································ 259 Displaying and maintaining ARP defense against IP packet attacks ····························································· 260 Configuring source MAC-based ARP attack detection ···························································································· 260 Introduction ·························································································································································· 260 Configuration procedure ···································································································································· 260 Displaying and maintaining source MAC-based ARP attack detection························································· 261 Configuring ARP packet source MAC consistency check ························································································ 261 Configuring ARP active acknowledgement ··············································································································· 262 Introduction ·························································································································································· 262 Configuration procedure ···································································································································· 262 Configuring ARP strict active acknowledgement ······································································································ 262 Configuring authorized ARP ······································································································································· 263 Introduction ·························································································································································· 263 Configuration procedure ···································································································································· 263 Authorized ARP configuration example (on a DHCP server) ·········································································· 263 Authorized ARP configuration example (on a DHCP relay agent) ································································ 264 Configuring URPF ···················································································································································· 267 Overview······································································································································································· 267 URPF check modes ·············································································································································· 267 URPF features ······················································································································································· 267 URPF operation ···················································································································································· 267 Network application ··········································································································································· 269 Configuring URPF ························································································································································· 269 Configuration restrictions and guidelines: ········································································································ 269 Configuration procedure ···································································································································· 270 URPF configuration example ······································································································································· 270 Configuring COPS ·················································································································································· 272 Overview······································································································································································· 272 COPS characteristics··········································································································································· 272 COPS interaction ················································································································································· 272 COPS applications ·············································································································································· 273 Protocols and standards ····································································································································· 274 COPS configuration task list ······································································································································· 274 Setting the COPS client ID··········································································································································· 275 Configuring a COPS scheme ······································································································································ 275 Creating a COPS scheme ·································································································································· 275 Specifying a PDP ················································································································································· 276 Setting the COPS response timeout time ··········································································································· 276 Setting the reconnection attempt interval ·········································································································· 276 Setting the shared key for COPS packet exchange························································································· 277 Displaying and maintaining COPS ···························································································································· 277 COPS configuration example ····································································································································· 277 Troubleshooting COPS ················································································································································ 280 A COPS connection cannot be established after the COPS scheme is referenced······································ 280 Configuring FIPS······················································································································································ 281 Overview······································································································································································· 281 FIPS self-tests ································································································································································· 281 Power-up self-tests ················································································································································ 281 Conditional self-tests ············································································································································ 281 Triggering self-tests ·············································································································································· 282 vii
Configuring FIPS mode ················································································································································ 282 Enabling FIPS mode ············································································································································ 282 Displaying and maintaining FIPS ······························································································································· 283 FIPS configuration example········································································································································· 283 Configuring PKI ······················································································································································· 285 Overview······································································································································································· 285 PKI terminology ···················································································································································· 285 PKI architecture ···················································································································································· 286 PKI applications ··················································································································································· 286 PKI operation ······················································································································································· 287 PKI configuration task list ············································································································································ 287 Configuring an entity DN ············································································································································ 288 Configuring a PKI domain··········································································································································· 289 Submitting a PKI certificate request ···························································································································· 290 Submitting a certificate request in auto mode ·································································································· 291 Submitting a certificate request in manual mode ····························································································· 291 Retrieving a certificate manually ································································································································ 292 Verifying PKI certificate ··············································································································································· 293 Verifying certificates with CRL checking ··········································································································· 293 Verifying certificates without CRL checking ······································································································ 294 Destroying a local RSA or ECDSA key pair ·············································································································· 294 Deleting a certificate ···················································································································································· 294 Configuring an access control policy ························································································································ 295 Displaying and maintaining PKI ································································································································· 295 PKI configuration examples ········································································································································· 296 Certificate request from an RSA Keon CA server ···························································································· 296 Certificate request from a Windows 2003 CA server ···················································································· 299 Troubleshooting PKI ····················································································································································· 302 CA certificate cannot be retrieved····················································································································· 302 Local certificate cannot be retrieved ················································································································· 303 CRLs cannot be retrieved ···································································································································· 303 Support and other resources ·································································································································· 305 Contacting HP ······························································································································································ 305 Subscription service ············································································································································ 305 Related information ······················································································································································ 305 Documents ···························································································································································· 305 Websites······························································································································································· 305 Conventions ·································································································································································· 306 Index ········································································································································································ 308 viii
Security overview
Network security threats are happened or potential threats to data confidentiality, data integrity, data
availability or authorized usage of some resource in a network system. Network security services provide
solutions to solve or reduce those threats to different extents.
Network security threats
•
Information disclosure—Information is leaked to an unauthorized person or entity.
•
Data integrity damage—Data integrity is damaged by unauthorized modification or malicious
destruction.
•
Denial of service—Makes information or other network resources unavailable to their intended
users.
•
Unauthorized usage—Resources are used by unauthorized persons or in unauthorized ways.
Network security services
One security service is implemented by one or more network security technologies. One technology can
implement multiple services. A safe network needs the following services:
•
Identity authentication—Identifies users and determines if a user is valid. Typical ways include
AAA-based username plus password authentication, and PKI digital certificate-based
authentication.
•
Access security—Controls behaviors in which a user accesses network resources based on the
identity authentication result to prevent unauthorized access and usage of the network resources.
Major access security protocols include 802.1X, MAC authentication, and portal authentication,
which work together with AAA to implement user identity authentication.
•
Data security—Encrypts and decrypts data during data transmission and storage. Typical
encryption mechanisms include symmetric encryption and asymmetric encryption, and their
common applications are IPsec and SSH. IPsec secures IP communications. SSH protects data
transfer based on TCP.
•
Firewall—A highly effective network security model to block unauthorized Internet access to a
protected network. Major firewall implementations are ACL based packet filter and ALG.
•
Attack detection and protection—Identifies attacks by inspecting network traffic behaviors or
application layer protocol packet contents. According to the inspection result, it takes measures to
deal with the attacks or would-be attacks at the data link layer, network layer, or application layer.
Measures include TCP and ICMP attack protection, ARP attack protection, and IP source guard.
1
Network security technologies
Identity authentication
AAA
AAA provides a uniform framework for implementing network access management. It provides the
following security functions:
•
Authentication—Identifies network users and determines whether the user is valid.
•
Authorization—Grants user rights and controls user access to resources and services. For example,
a user who has successfully logged in to the device can be granted read and print permissions to
the files on the device.
•
Accounting—Records all network service usage information, including the service type, start time,
and traffic. The accounting function provides information required for charging, and allows for user
behavior auditing.
AAA can be implemented through multiple protocols, such as RADIUS and HWTACACS. RADIUS is
most often used.
PKI
PKI uses a general security infrastructure to provide information security through public key technologies.
PKI employs the digital certificate mechanism to manage the public keys. The digital certificate
mechanism binds public keys to their owners, helping distribute public keys in large networks securely.
With digital certificates, the PKI system provides network communication, e-commerce, and
e-Government with security services.
HP's PKI system provides digital certificate management for IPsec.
Access security
802.1X
802.1X is a port-based network access control protocol for securing wireless LANs (WLANs), and it has
also been widely used on Ethernet networks for access control. 802.1X controls network access by
authenticating the devices connected to 802.1X-enabled LAN ports.
MAC authentication
MAC authentication controls network access by authenticating source MAC addresses on a port. It does
not require client software and users do not need to enter a username and password for network access.
The device initiates a MAC authentication process when it detects an unknown source MAC address on
a MAC authentication enabled port. If the MAC address passes authentication, the user can access
authorized network resources.
Portal authentication
Portal authentication, also called "Web authentication," controls user access at the access layer and
other data entrance that needs protection. It does not require client software to authenticate users. Users
only need to enter a username and a password on the webpage for authentication.
2
With portal authentication, an access device redirects all unauthenticated users to a specific webpage,
and users can freely access resources on the webpage. However, to access other resources on the
Internet, a user must pass portal authentication on the portal authentication page.
Data security
Managing public keys
Public key configuration enables you to manage the local asymmetric key pairs (such as creating and
destroying a local asymmetric key pair, displaying or exporting the local host public key), and configure
the peer host public keys on the local device.
IPsec
IPsec is a security framework for securing IP communications. It is a Layer 3 VPN technology mainly for
data encryption and data origin authentication.
SSH
SSH is a network security protocol implementing secure remote login and file transfer over an insecure
network. Using encryption and authentication, SSH protects devices against attacks such as IP spoofing
and plaintext password interception.
Firewall and connection control
ACL based packet-filter
An ACL packet-filter implements IP packet specific filtering.
Before forwarding an IP packet, the device obtains the following header information:
•
Number of the upper layer protocol carried by the IP layer
•
Source address
•
Destination address
•
Source port number
•
Destination port number
The device compares the head information against the preset ACL rules and processes (discards or
forwards) the packet based on the comparison result.
ALG
ALG processes payload information for application layer packets. Workig with NAT, ALG implements
address translation in packet payloads.
Session management
Session management is a common feature designed to implement session-based services such as NAT.
Session management tracks the connection status by inspecting the transport layer protocol (TCP or UDP)
information, and regards packet exchanges at transport layer as sessions, performing unified status
maintenance and management of all connections.
The session management function only implements connection status tracking. It does not block potential
attack packets.
3
Attack detection and protection
ARP attack protection
Although ARP is easy to implement, it provides no security mechanism and is vulnerable to network
attacks. An attacker can exploit ARP vulnerabilities to attack network devices. HP has provided a
comprehensive and effective solution against common ARP attacks, such as user and gateway spoofing
attacks and flood attacks.
IP source guard
IP source guard uses binding entries to improve port security by blocking illegal packets. For example, it
can prevent illegal hosts from using a valid IP address to access the network. It is applied on an interface
connected to the user side.
IP source guard can filter packets according to the packet source IP address, source MAC address, and
VLAN ID. An IP source guard entry can be statically configured or dynamically added through DHCP or
ND.
URPF
URPF protects a network against source address spoofing attacks, such as DoS and DDoS attacks.
TCP and ICMP attack protection
Attackers can attack the device during the process of TCP connection establishment or by sending a large
number of ICMP fragments. To prevent such attacks, the device provides the following features:
•
SYN Cookie
•
Protection against Naptha attacks
•
Disabling ICMP fragment forwarding
Other security technologies
The device also provides other network security technologies to implement a multifunctional and full
range of security protection for users.
COPS
COPS is a simple query and response application layer protocol that can be used to exchange policy
information between a policy server and its clients. COPS is also a service-oriented network
management protocol, and performs policy-based admission control over a variety of network
applications. HP devices can act as clients to interact with the remote policy server and implement
policy-based admission control over 802.1X services.
Password control
Password control is a set of functions for enhancing the local password security. It controls user login
passwords, super passwords, and user login status based on predefined policies. Those policies include
minimum password length, minimum password update interval, password aging, and early notice on
pending password expiration.
FIPS
The FIPS 140-2, developed by the NIST of the United States, specifies the security requirements for
cryptographic modules. FIPS 140-2 defines four levels of security, simply named "Level 1" to "Level 4"
from low to high, and is applicable to various application scenarios for cryptographic modules. The
4
device supports Level 2. When the device that supports FIPS operates in FIPS 140-2 mode, the system
applies a higher security requirement, and checks whether the cryptographic module runs correctly.
5
Configuring AAA
AAA overview
Authentication, Authorization, and Accounting (AAA) provides a uniform framework for implementing
network access management. It provides the following security functions:
•
Authentication—Identifies users and determines whether a user is valid.
•
Authorization—Grants different users different rights and controls their access to resources and
services. For example, a user who has successfully logged in to the router can be granted read and
print permissions to the files on the router.
•
Accounting—Records all network service usage information of users, including the service type,
start time, and traffic. The accounting function not only provides the information required for
charging, but also allows for network security surveillance.
AAA usually uses a client/server model. The client runs on the network access server (NAS), which is
also referred to as the access device. The server maintains user information centrally. In an AAA network,
a NAS is a server for users but a client for the AAA servers, as shown in Figure 1.
Figure 1 Network diagram
When a user tries to log in to the NAS, use network resources, or access other networks, the NAS
authenticates the user. The NAS can transparently pass the user’s authentication, authorization, and
accounting information to the servers. The RADIUS and HWTACACS protocols define how a NAS and
a remote server exchange user information between them.
In the network shown in Figure 1, there is a RADIUS server and an HWTACACS server. You can choose
different servers for different security functions. For example, you can use the HWTACACS server for
authentication and authorization, and the RADIUS server for accounting.
You can use AAA to provide only one or two security functions, if desired. For example, if your company
only wants employees to be authenticated before they access specific resources, configure an
authentication server only. If network usage information is expected to be recorded, configure an
accounting server.
1
AAA can be implemented through multiple protocols. The router supports using RADIUS and
HWTACACS. RADIUS is often used in practice.
RADIUS
Remote Authentication Dial-In User Service (RADIUS) is a distributed information interaction protocol that
uses a client/server model. It can protect networks against unauthorized access and is often used in
network environments where both high security and remote user access are required.
RADIUS uses UDP as the transport protocol. It uses UDP port 1812 for authentication and UDP port 1813
for accounting.
RADIUS was originally designed for dial-in user access. With the addition of new access methods,
RADIUS has been extended to support additional access methods, for example, Ethernet and ADSL.
RADIUS provides access authentication and authorization services, and its accounting function collects
and records network resource usage information.
Client/server model
The RADIUS client runs on the NASs located throughout the network. It passes user information to
designated RADIUS servers and acts on the responses (for example, rejects or accepts user access
requests).
The RADIUS server runs on the computer or workstation at the network center and maintains information
related to user authentication and network service access. It listens to connection requests, authenticates
users, and returns user access control information (for example, rejecting or accepting the user access
request) to the clients.
In general, the RADIUS server maintains the following databases: Users, Clients, and Dictionary, as
shown in Figure 2.
Figure 2 RADIUS server components
RADIUS servers
Users
Clients
Dictionary
•
Users—Stores user information such as the usernames, passwords, applied protocols, and IP
addresses.
•
Clients—Stores information about RADIUS clients, such as shared keys and IP addresses.
•
Dictionary—Stores RADIUS protocol attributes and their values.
Security and authentication mechanisms
Information exchanged between a RADIUS client and the RADIUS server is authenticated with a shared
key, which is never transmitted over the network. This enhances the information exchange security. In
addition, to prevent user passwords from being intercepted on insecure networks, RADIUS encrypts
passwords before transmitting them.
A RADIUS server supports multiple user authentication methods, such as the Password Authentication
Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP) of the Point-to-Point Protocol
(PPP). Moreover, a RADIUS server can act as the client of another AAA server to provide authentication
proxy services.
2
RADIUS basic message exchange process
Figure 3 illustrates the interaction of the host, the RADIUS client, and the RADIUS server.
Figure 3 RADIUS basic message exchange process
RADIUS operates in the following manner:
1.
The host initiates a connection request that carries the user’s username and password to the
RADIUS client.
2.
Having received the username and password, the RADIUS client sends an authentication request
(Access-Request) to the RADIUS server, with the user password encrypted by using the
Message-Digest 5 (MD5) algorithm and the shared key.
3.
The RADIUS server authenticates the username and password. If the authentication succeeds, the
server sends back an Access-Accept message containing the user’s authorization information. If
the authentication fails, the server returns an Access-Reject message.
4.
The RADIUS client permits or denies the user according to the returned authentication result. If it
permits the user, it sends a start-accounting request (Accounting-Request) to the RADIUS server.
5.
The RADIUS server returns a start-accounting response (Accounting-Response) and starts
accounting.
6.
The user accesses the network resources.
7.
The host requests the RADIUS client to tear down the connection and the RADIUS client sends a
stop-accounting request (Accounting-Request) to the RADIUS server.
8.
The RADIUS server returns a stop-accounting response (Accounting-Response) and stops
accounting for the user.
RADIUS packet format
RADIUS uses UDP to transmit messages. It ensures the smooth message exchange between the RADIUS
server and the client through a series of mechanisms, including: the timer management mechanism,
retransmission mechanism, and slave server mechanism. Figure 4 shows the RADIUS packet format.
3
Figure 4 RADIUS packet format
Descriptions of the fields are as follows:
The Code field (1 byte long) indicates the type of the RADIUS packet. Table 1 gives the possible
values and their meanings.
•
Table 1 Main values of the Code field
Code
Packet type
Description
1
Access-Request
From the client to the server. A packet of this type carries user information
for the server to authenticate the user. It must contain the User-Name
attribute and can optionally contain the attributes of NAS-IP-Address,
User-Password, and NAS-Port.
2
Access-Accept
From the server to the client. If all the attribute values carried in the
Access-Request are acceptable, that is, the authentication succeeds, the
server sends an Access-Accept response.
3
Access-Reject
From the server to the client. If any attribute value carried in the
Access-Request is unacceptable, the server rejects the user and sends an
Access-Reject response.
4
Accounting-Request
From the client to the server. A packet of this type carries user information
for the server to start or stop accounting for the user. The Acct-Status-Type
attribute in the packet indicates whether to start or stop the accounting.
5
Accounting-Response
From the server to the client. The server sends a packet of this type to
notify the client that it has received the Accounting-Request and has
correctly recorded the accounting information.
•
The Identifier field (1 byte long) is used to match request packets and response packets and to detect
duplicate request packets. Request and response packets of the same type have the same identifier.
•
The Length field (2 bytes long) indicates the length of the entire packet, including the Code,
Identifier, Length, Authenticator, and Attribute fields. Bytes beyond the length are considered
padding and are neglected upon reception. If the length of a received packet is less than this length,
the packet is dropped. The value of the field is in the range 20 to 4096.
•
The Authenticator field (16 bytes long) is used to authenticate replies from the RADIUS server and to
encrypt user passwords. There are two types of authenticators: request authenticator and response
authenticator.
•
The Attributes field (variable in length) carries the specific authentication, authorization, and
accounting information that defines the configuration details of the request or response. This field
may contain multiple attributes, each with three sub-fields:
4
{
{
{
Type—(1 byte long) Type of the attribute. It is in the range 1 to 255. Commonly used attributes
for RADIUS authentication, authorization and accounting are listed in Table 2.
Length—(1 byte long) Length of the attribute in bytes, including the Type, Length, and Value
fields.
Value—(Up to 253 bytes) Value of the attribute. Its format and content depend on the Type and
Length fields.
Table 2 RADIUS attributes
No.
Attribute
No.
Attribute
1
User-Name
45
Acct-Authentic
2
User-Password
46
Acct-Session-Time
3
CHAP-Password
47
Acct-Input-Packets
4
NAS-IP-Address
48
Acct-Output-Packets
5
NAS-Port
49
Acct-Terminate-Cause
6
Service-Type
50
Acct-Multi-Session-Id
7
Framed-Protocol
51
Acct-Link-Count
8
Framed-IP-Address
52
Acct-Input-Gigawords
9
Framed-IP-Netmask
53
Acct-Output-Gigawords
10
Framed-Routing
54
(unassigned)
11
Filter-ID
55
Event-Timestamp
12
Framed-MTU
56-59
(unassigned)
13
Framed-Compression
60
CHAP-Challenge
14
Login-IP-Host
61
NAS-Port-Type
15
Login-Service
62
Port-Limit
16
Login-TCP-Port
63
Login-LAT-Port
17
(unassigned)
64
Tunnel-Type
18
Reply-Message
65
Tunnel-Medium-Type
19
Callback-Number
66
Tunnel-Client-Endpoint
20
Callback-ID
67
Tunnel-Server-Endpoint
21
(unassigned)
68
Acct-Tunnel-Connection
22
Framed-Route
69
Tunnel-Password
23
Framed-IPX-Network
70
ARAP-Password
24
State
71
ARAP-Features
25
Class
72
ARAP-Zone-Access
26
Vendor-Specific
73
ARAP-Security
27
Session-Timeout
74
ARAP-Security-Data
28
Idle-Timeout
75
Password-Retry
29
Termination-Action
76
Prompt
5
No.
Attribute
No.
Attribute
30
Called-Station-Id
77
Connect-Info
31
Calling-Station-Id
78
Configuration-Token
32
NAS-Identifier
79
EAP-Message
33
Proxy-State
80
Message-Authenticator
34
Login-LAT-Service
81
Tunnel-Private-Group-id
35
Login-LAT-Node
82
Tunnel-Assignment-id
36
Login-LAT-Group
83
Tunnel-Preference
37
Framed-AppleTalk-Link
84
ARAP-Challenge-Response
38
Framed-AppleTalk-Network
85
Acct-Interim-Interval
39
Framed-AppleTalk-Zone
86
Acct-Tunnel-Packets-Lost
40
Acct-Status-Type
87
NAS-Port-Id
41
Acct-Delay-Time
88
Framed-Pool
42
Acct-Input-Octets
89
(unassigned)
43
Acct-Output-Octets
90
Tunnel-Client-Auth-id
44
Acct-Session-Id
91
Tunnel-Server-Auth-id
NOTE:
• The attribute types listed in Table 2 are defined in RFC 2865, RFC 2866, RFC 2867, and RFC 2868.
• For more information about commonly used standard RADIUS attributes, see "Commonly used
standard RADIUS attributes."
Extended RADIUS attributes
The RADIUS protocol features excellent extensibility. Attribute 26 (Vendor-Specific), an attribute defined
by RFC 2865, allows a vendor to define extended attributes to implement functions that the standard
RADIUS protocol does not provide.
A vendor can encapsulate multiple sub-attributes in the type-length-value (TLV) format in RADIUS packets
for extension of applications. As shown in Figure 5, a sub-attribute encapsulated in Attribute 26 consists
of the following parts:
•
Vendor-ID—ID of the vendor. Its most significant byte is 0, and the other three bytes contains a code
that is compliant to RFC 1700. The vendor ID of HP is 25506. For more information about the
proprietary RADIUS sub-attributes of HP, see "HP proprietary RADIUS sub-attributes."
•
Vendor-Type—Type of the sub-attribute.
•
Vendor-Length—Length of the sub-attribute.
•
Vendor-Data—Contents of the sub-attribute.
6
Figure 5 Segment of a RADIUS packet containing an extended attribute
0
7
Type
23
15
Length
31
Vendor-ID
Vendor-ID (continued)
Vendor-Type
Vendor-Length
Vendor-Data
(Specified attribute value……)
……
HWTACACS
HW Terminal Access Controller Access Control System (HWTACACS) is an enhanced security protocol
based on TACACS (RFC 1492). Similar to RADIUS, it uses a client/server model for information
exchange between the NAS and the HWTACACS server.
HWTACACS is mainly used to provide AAA services for Point-to-Point Protocol (PPP) users, Virtual Private
Dial-up Network (VPDN) users, and terminal users. In a typical HWTACACS application, some terminal
users need to log in to the router for operations. Working as the HWTACACS client, the NAS sends the
username and password of a user to the HWTACACS sever for authentication. After passing
authentication and being authorized, the user logs in to the router and performs operations, and the
HWTACACS server records the operations that the user performs.
Differences between HWTACACS and RADIUS
HWTACACS and RADIUS both provide authentication, authorization, and accounting services. They
have many features in common, like using a client/server model, using shared keys for user information
security, and providing flexibility and extensibility. HWTACACS and RADIUS do have differences, as
listed in Table 3.
Table 3 Primary differences between HWTACACS and RADIUS
HWTACACS
RADIUS
Uses TCP, providing more reliable network
transmission.
Uses UDP, providing higher transport efficiency.
Encrypts the entire packet except for the HWTACACS
header.
Encrypts only the user password field in an
authentication packet.
Protocol packets are complicated and authorization is
independent of authentication. Authentication and
authorization can be deployed on different
HWTACACS servers.
Protocol packets are simple and the authorization
process is combined with the authentication process.
Supports authorization of configuration commands.
Which commands a user can use depends on both the
user level and AAA authorization. A user can use only
commands that are not only of, or lower than, the user
level but also authorized by the HWTACACS server.
Does not support authorization of configuration
commands. Which commands a user can use
depends on the level of the user and a user can use all
the commands of, or lower than, the user level.
HWTACACS basic message exchange process
The following example describes how HWTACACS performs authentication, authorization, and
accounting for a Telnet user.
7
Figure 6 HWTACACS basic message exchange process for a Telnet user
HWTACACS operates in the following manner:
1.
A Telnet user sends an access request to the HWTACACS client.
2.
Upon receiving the request, the HWTACACS client sends a start-authentication packet to the
HWTACACS server.
3.
The HWTACACS server sends back an authentication response to request the username.
4.
Upon receiving the response, the HWTACACS client asks the user for the username.
5.
The user enters the username.
6.
After receiving the username from the user, the HWTACACS client sends the server a
continue-authentication packet that carries the username.
7.
The HWTACACS server sends back an authentication response, requesting the login password.
8.
Upon receipt of the response, the HWTACACS client asks the user for the login password.
9.
The user enters the password.
8
10. After receiving the login password, the HWTACACS client sends the HWTACACS server a
continue-authentication packet that carries the login password.
11. The HWTACACS server sends back an authentication response to indicate that the user has
passed authentication.
12. The HWTACACS client sends the user authorization request packet to the HWTACACS server.
13. The HWTACACS server sends back the authorization response, indicating that the user is now
authorized.
14. Knowing that the user is now authorized, the HWTACACS client pushes its configuration interface
to the user.
15. The HWTACACS client sends a start-accounting request to the HWTACACS server.
16. The HWTACACS server sends back an accounting response, indicating that it has received the
start-accounting request.
17. The user logs off.
18. The HWTACACS client sends a stop-accounting request to the HWTACACS server.
19. The HWTACACS server sends back a stop-accounting response, indicating that the
stop-accounting request has been received.
Domain-based user management
A NAS manages users based on Internet service provider (ISP) domains. An ISP domain has a collection
of users.
On a NAS, each user belongs to one ISP domain. A NAS determines the ISP domain a user belongs to
by the username entered by the user at login, as shown in Figure 7.
Figure 7 Determining the ISP domain of a user by the username
NAS
A user enters the username in
the form of
userid@domain-name
or userid
Username carries
@domain-name?
Yes
Use domain domain-name
to authenticate the user
No
Use the default domain to
authenticate the user
The authentication, authorization, and accounting of a user depends on the AAA methods configured for
the domain to which the user belongs. If no specific AAA methods are configured for the domain, the
default methods are used. By default, a domain uses local authentication, local authorization, and local
accounting.
AAA allows you to manage users based on their access types:
•
LAN users—Users on a LAN who must pass 802.1X or MAC address authentication to access the
network.
•
Login users—Users who want to log in to the router, including SSH users, Telnet users, Web users,
FTP users, and terminal users.
9
•
Portal users—Users who must pass portal authentication to access the network.
•
PPP users—Users who access through PPP.
In addition, AAA provides the following services for login users to enhance the router’s security:
•
Command authorization—Enables the NAS to defer to the authorization server to determine
whether a command entered by a login user is permitted for the user, making sure that login users
execute only commands they are authorized to execute. For more information about command
authorization, see Fundamentals Configuration Guide.
•
Command accounting—Allows the accounting server to record all commands executed on the
router or all authorized commands successfully executed. For more information about command
accounting, see Fundamentals Configuration Guide.
•
Level switching authentication—Allows the authentication server to authenticate users who perform
privilege level switching. As long as passing level switching authentication, users can switch their
user privilege levels, without logging out and disconnecting current connections. For more
information about user privilege level switching, see Fundamentals Configuration Guide.
You can configure different authentication, authorization, and accounting methods for different users in
a domain. For more information about the configuration, see "Configuring AAA methods for ISP
domains."
AAA for MPLS L3VPNs
In an MPLS L3VPN scenario where clients in different VPNs are centrally authenticated, you can deploy
AAA across VPNs to enable forwarding RADIUS and HWTACACS packets across MPLS VPNs. With the
AAA across VPNs feature, the PE at the left side of the MPLS backbone serves as a NAS and
transparently delivers the AAA packets of private users in VPN 1 and VPN 2 to the AAA servers in VPN
3 for centralized authentication, as shown in Figure 8. Authentication packets of private users in different
VPNs do not affect each other.
Figure 8 AAA support for VPNs network diagram
VPN 1
CE
VPN 3
NAS
RADIUS
server
MPLS backbone
Host
PE
PE
VPN 2
Host
CE
P
HWTACACS
server
CE
NOTE:
Together with the AAA across MPLS L3VPNs feature, you can implement portal authentication across
MPLS L3VPNs on MCEs. For more information about MCE, see MPLS Configuration Guide.
10
Protocols and standards
The protocols and standards related to AAA, RADIUS, and HWTACACS include:
•
RFC 2865, Remote Authentication Dial In User Service (RADIUS)
•
RFC 2866, RADIUS Accounting
•
RFC 2867, RADIUS Accounting Modifications for Tunnel Protocol Support
•
RFC 2868, RADIUS Attributes for Tunnel Protocol Support
•
RFC 2869, RADIUS Extensions
•
RFC 1492, An Access Control Protocol, Sometimes Called TACACS
RADIUS attributes
Commonly used standard RADIUS attributes
No.
Attribute
Description
1
User-Name
Name of the user to be authenticated.
2
User-Password
User password for PAP authentication, present only in Access-Request
packets in PAP authentication mode.
3
CHAP-Password
Digest of the user password for CHAP authentication, present only in
Access-Request packets in CHAP authentication mode.
4
NAS-IP-Address
IP address for the server to identify a client. Usually, a client is identified by
the IP address of the access interface of the NAS, namely the NAS IP
address. This attribute is present in only Access-Request packets.
5
NAS-Port
Physical port of the NAS that the user accesses.
6
Service-Type
Type of service that the user has requested or type of service to be provided.
7
Framed-Protocol
Encapsulation protocol for framed access.
8
Framed-IP-Address
IP address assigned to the user.
11
Filter-ID
Name of the filter list.
12
Framed-MTU
Maximum transmission unit (MTU) for the data link between the user and
NAS. For example, with 802.1X EAP authentication, NAS uses this
attribute to notify the server of the MTU for EAP packets, so as to avoid
oversized EAP packets.
14
Login-IP-Host
IP address of the NAS interface that the user accesses.
15
Login-Service
Type of the service that the user uses for login.
18
Reply-Message
Text to be displayed to the user, which can be used by the server to indicate,
for example, the reason of the authentication failure.
26
Vendor-Specific
Vendor specific attribute. A packet can contain one or more such
proprietary attributes, each of which can contain one or more
sub-attributes.
27
Session-Timeout
Maximum duration of service to be provided to the user before termination
of the session.
28
Idle-Timeout
Maximum idle time permitted for the user before termination of the session.
11
No.
Attribute
Description
31
Calling-Station-Id
Identification of the user that the NAS sends to the server. For the LAN
access service provided by an HP device, this attribute carries the MAC
address of the user in the format HHHH-HHHH-HHHH.
32
NAS-Identifier
Identification that the NAS uses for indicating itself.
Type of the Accounting-Request packet. Possible values are as follows:
40
Acct-Status-Type
•
•
•
•
•
1—Start.
2—Stop.
3—Interim-Update.
4—Reset-Charge.
7—Accounting-On. (Defined in 3GPP, the 3rd Generation Partnership
Project.)
• 8—Accounting-Off. (Defined in 3GPP.)
• 9 to 14—Reserved for tunnel accounting.
• 15—Reserved for failed.
Authentication method used by the user. Possible values are as follows:
45
Acct-Authentic
60
CHAP-Challenge
• 1—RADIUS.
• 2—Local.
• 3—Remote.
CHAP challenge generated by the NAS for MD5 calculation during CHAP
authentication.
Type of the physical port of the NAS that is authenticating the user. Possible
values are as follows:
61
NAS-Port-Type
•
•
•
•
•
15—Ethernet.
16—Any type of ADSL.
17—Cable (with cable for cable TV).
201—VLAN.
202—ATM.
If the port is an ATM or Ethernet one and VLANs are implemented on it, the
value of this attribute is 201.
79
EAP-Message
Used for encapsulating EAP packets to allow the NAS to authenticate dial-in
users through EAP without having to understand the EAP protocol.
80
Message-Authenticator
Used for authentication and checking of authentication packets to prevent
spoofing Access-Requests. This attribute is used when RADIUS supports EAP
authentication.
87
NAS-Port-Id
String for describing the port of the NAS that is authenticating the user.
HP proprietary RADIUS sub-attributes
No.
Sub-attribute
Description
1
Input-Peak-Rate
Peak rate in the direction from the user to the NAS, in bps.
2
Input-Average-Rate
Average rate in the direction from the user to the NAS, in bps.
3
Input-Basic-Rate
Basic rate in the direction from the user to the NAS, in bps.
4
Output-Peak-Rate
Peak rate in the direction from the NAS to the user, in bps.
12
No.
Sub-attribute
Description
5
Output-Average-Rate
Average rate in the direction from the NAS to the user, in bps.
6
Output-Basic-Rate
Basic rate in the direction from the NAS to the user, in bps.
15
Remanent_Volume
Remaining, available total traffic of the connection, in different units for
different server types.
Operation for the session, used for session control. It can be:
20
24
Command
Control_Identifier
•
•
•
•
•
1—Trigger-Request.
2—Terminate-Request.
3—SetPolicy.
4—Result.
5—PortalClear.
Identification for retransmitted packets. For retransmitted packets of the
same session, this attribute must take the same value. For retransmitted
packets of different sessions, this attribute may take the same value. The
client response of a retransmitted packet must also carry this attribute and
the value of the attribute must be the same.
For Accounting-Request packets of the start, stop, and interim update
types, the Control-Identifier attribute is ineffective.
25
Result_Code
Result of the Trigger-Request or SetPolicy operation. A value of zero
means the operation succeeded. Any other value means the operation
failed.
26
Connect_ID
Index of the user connection.
28
Ftp_Directory
For an FTP user, when the RADIUS client acts as the FTP server, this
attribute is used to set the FTP directory on the RADIUS client.
29
Exec_Privilege
Priority of the EXEC user.
59
NAS_Startup_Timestamp
Startup time of the NAS in seconds, which is represented by the time
elapsed after 00:00:00 on Jan. 1, 1970 (UTC).
60
Ip_Host_Addr
User IP address and MAC address carried in authentication and
accounting requests, in the format A.B.C.D hh:hh:hh:hh:hh:hh. A space
is required between the IP address and the MAC address.
61
User_Notify
Information to be transparently sent from the server to the client.
User_HeartBeat
Hash value assigned after an 802.1X user passes authentication, which
is a 32-byte string. This attribute is stored in the user list on the device and
is used for verifying the handshake messages from the 802.1X user. This
attribute exists in only Access-Accept and Accounting-Request packets.
140
User_Group
User groups assigned after the SSL VPN user passes authentication. A
user may belong to more than one user group. In this case, the user
groups are delimited by semi-colons. This attribute is used for
cooperation with the SSL VPN device.
141
Security_Level
Security level assigned after the SSL VPN user passes security
authentication.
201
Input-Interval-Octets
Bytes input within a real-time accounting interval.
202
Output-Interval-Octets
Bytes output within a real-time accounting interval.
203
Input-Interval-Packets
Packets input within an accounting interval, in the unit set on the device.
Working directory of the FTP user.
62
13
No.
Sub-attribute
Description
204
Output-Interval-Packets
Packets output within an accounting interval, in the unit set on the device.
205
Input-Interval-Gigawords
Result of bytes input within an accounting interval divided by 4G bytes.
206
Output-Interval-Gigawords
Result of bytes output within an accounting interval divided by 4G bytes.
207
Backup-NAS-IP
Backup source IP address for sending RADIUS packets.
255
Product_ID
Product name.
FIPS compliance
The router supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for features,
commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and non-FIPS mode.
AAA configuration considerations and task list
To configure AAA, you must complete these tasks on the NAS:
1.
Configure the required AAA schemes.
{
{
2.
Local authentication—Configure local users and related attributes, including the usernames
and passwords of the users to be authenticated.
Remote authentication—Configure the required RADIUS and HWTACACS schemes. You must
configure user attributes on the servers accordingly.
Configure AAA methods for the users’ ISP domains.
{
{
{
Authentication method—No authentication (none), local authentication (local), or remote
authentication (scheme)
Authorization method—No authorization (none), local authorization (local), or remote
authorization (scheme)
Accounting method—No accounting (none), local accounting (local), or remote accounting
(scheme)
Figure 9 illustrates the configuration procedure.
14
Figure 9 AAA configuration procedure
Local AAA
Configure AAA methods
Configure local users and related
attributes
None
Authentication method
No AAA
local (the default)
scheme
+
Create an ISP domain
and enter its view
None
Authorization method
local (the default)
scheme
+
Configure the RADIUS and
HWTACACS schemes to be
referenced
None
Accounting method
local (the default)
scheme
Remote AAA
Task
Remarks
Configuring local users
Configuring AAA
schemes
Configuring RADIUS schemes
Configuring HWTACACS schemes
Configuring AAA
methods for ISP domains
Required.
Complete at least one task.
Creating an ISP domain
Required.
Configuring ISP domain attributes
Optional.
Configuring AAA authentication methods for
an ISP domain
Configuring AAA authorization methods for an
ISP domain
Required.
Complete at least one task.
Configuring AAA accounting methods for an
ISP domain
Tearing down user connections
Optional.
NOTE:
To control access of login users by using AAA methods, you must configure the login authentication mode
for the user interfaces as scheme. For more information about the configuration command, see
Fundamentals Command Reference.
15
Configuring AAA schemes
Configuring local users
To implement local user authentication, authorization, and accounting, you must create local users and
configure user attributes on the router. The local users and attributes are stored in the router's local user
database. A local user is uniquely identified by a username. Configurable local user attributes are as
follows:
•
Service type:
The types of the services that the user can use. Local authentication checks the service types of a
local user. If none of the service types is available, the user cannot pass authentication.
Service types include FTP, LAN access, Portal, PPP, SSH, Telnet, Terminal, and Web. FTP and
Telnet service types are not supported in FIPS mode.
•
User state:
Indicates whether or not a local user can request network services. There are two user states: active
and blocked. A user in active state can request network services, but a user in blocked state
cannot.
•
Maximum number of users using the same local user account:
Indicates how many users can use the same local user account for local authentication.
•
Validity time and expiration time:
Indicates the validity time and expiration time of a local user account. A user must use a local user
account that valid to pass local authentication. For temporary network access requirements, you
can create a guest account and specify a validity time and an expiration time for the account to
control the validity of the account.
•
User group:
Each local user belongs to a local user group and bears all attributes of the group, such as the
password control attributes and authorization attributes. For more information about local user
group, see "Configuring user group attributes."
•
Password control attributes:
Password control attributes help you control the security of local users' passwords. Password
control attributes include password aging time, minimum password length, and password
composition policy.
You can configure a password control attribute in system view, user group view, or local user view,
making the attribute effective for all local users, all local users in a group, or only the local user. A
password control attribute with a smaller effective range has a higher priority. For more
information about password management and global password configuration, see "Configuring
password control."
•
Binding attributes:
Binding attributes are used for controlling the scope of users. They are checked during local
authentication of a user. If the attributes of a user do not match the binding attributes configured for
the local user account, the user cannot pass authentication. Binding attributes include the ISDN
calling number, IP address, access port, MAC address, and native VLAN. For more information
about binding attributes, see "Configuring local user attributes." Be cautious when deciding which
binding attributes to configure for a local user.
16
Authorization attributes:
•
Authorization attributes indicate the rights that a user has after passing local authentication.
Authorization attributes include the ACL, PPP callback number, idle cut function, user level, user
role, VLAN, and FTP/SFTP work directory. For more information about authorization attributes,
see "Configuring local user attributes."
Every configurable authorization attribute has its definite application environments and purposes.
When you configure authorization attributes for a local user, consider which attributes are needed
and which are not. For example, for PPP users, you do not need to configure the work directory
attribute.
You can configure an authorization attribute in user group view or local user view, making the
attribute effective for all local users in the group or for only the local user. The setting of an
authorization attribute in local user view takes precedence over that in user group view.
Local user configuration task list
Task
Remarks
Configuring local user attributes
Required
Configuring user group attributes
Optional
Displaying and maintaining local users and local user groups
Optional
Configuring local user attributes
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Add a local user and enter
local user view.
local-user user-name
No local user exists by default.
Optional.
3.
Configure a password for the
local user.
password [ [ hash ] { cipher |
simple } password ]
A local user with no password
configured directly passes
authentication after providing the
valid local username and attributes.
To enhance security, configure a
password for each local user.
Parameters including hash, cipher,
simple, and password are not
supported in FIPS mode.
4.
Specify the service types for
the local user.
service-type { ftp | lan-access |
{ ssh | telnet | terminal } * | portal
| ppp | web }
By default, no service is authorized
to a local user.
The ftp and telnet keywords are not
supported in FIPS mode.
Optional.
5.
Place the local user to the
state of active or blocked.
state { active | block }
17
When created, a local user is in
active state by default, and the user
can request network services.
Step
Command
Remarks
Optional.
6.
Set the maximum number of
concurrent users of the local
user account.
access-limit max-user-number
By default, there is no limit to the
maximum number of concurrent
users of a local user account.
The limit is effective only for local
accounting, and is not effective for
FTP users.
Optional.
• Set the password aging time:
password-control aging
aging-time
7.
Configure the password
control attributes for the local
user.
• Set the minimum password
length:
password-control length length
• Configure the password
composition policy:
password-control composition
type-number type-number
[ type-length type-length ]
8.
Configure the binding
attributes for the local user.
bind-attribute { call-number
call-number [ : subcall-number ] |
ip ip-address | location port
slot-number subslot-number
port-number | mac mac-address |
vlan vlan-id } *
18
By default, the local user uses
password control attributes of the
user group to which the local user
belongs, and uses the global
setting for any password control
attribute that is not configured in the
user group. The global settings in
non-FIPS mode include a 90-day
password aging time, a minimum
password length of 10 characters,
and at least one password
composition type and at least one
character required for each
password composition type. The
global settings in FIPS mode
include a 90-day password aging
time, a minimum password length
of 10 characters, and four
password composition types and at
least one character required for
each password composition type.
Optional.
By default, no binding attribute is
configured for a local user.
Step
Command
Remarks
Optional.
By default, no authorization
attribute is configured for a local
user.
The router does not support the
user-profile keyword.
authorization-attribute { acl
acl-number | callback-number
9.
Configure the authorization
attributes for the local user.
callback-number | idle-cut minute
| level level | user-profile
profile-name | user-role { guest |
guest-manager | security-audit } |
vlan vlan-id | work-directory
directory-name } *
For PPP users, only acl,
callback-number, and idle-cut are
supported.
For LAN and portal users, only acl,
idle-cut, and vlan are supported.
For SSH, terminal, and Web users,
only level is supported.
For FTP users, only level and
work-directory are supported.
For Telnet users, only level and
user-role is supported.
For other types of local users, no
binding attribute is supported.
10. Set the validity time of the
local user.
validity-date time
11. Set the expiration time of the
local user.
expiration-date time
12. Assign the local user to a user
group.
group group-name
Optional.
Not set by default.
Optional.
Not set by default.
Optional.
By default, a local user belongs to
the default user group system.
NOTE:
• When the password control feature is globally enabled by using the password-control enable
command, local user passwords are not displayed.
• The access-limit command configured for a local user takes effect only in the case of local accounting.
• If the user interface authentication mode (set by the authentication-mode command in user interface
view) is AAA (scheme), which commands a login user can use after login depends on the privilege level
authorized to the user. If the user interface authentication mode is password (password) or no
authentication (none), which commands a login user can use after login depends on the level
configured for the user interface (set by the user privilege level command in user interface view). For an
SSH user using public key authentication, which commands are available depends on the level
configured for the user interface. For more information about user interface authentication mode and
user interface command level, see Fundamentals Configuration Guide.
Configuring user group attributes
User groups simplify local user configuration and management. A user group comprises a group of local
users and has a set of local user attributes. You can configure local user attributes for a user group to
implement centralized user attributes management for the local users in the group. Configurable user
attributes include password control attributes and authorization attributes.
19
By default, every newly added local user belongs to the system default user group system and bears all
attributes of the group. To change the user group to which a local user belongs, use the user-group
command in local user view.
To configure attributes for a user group:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a user group and
enter user group view.
user-group group-name
N/A
Optional.
• Set the password aging time:
password-control aging aging-time
• Set the minimum password length:
3.
Configure password control
attributes for the user group.
password-control length length
• Configure the password
composition policy:
password-control composition
type-number type-number
[ type-length type-length ]
authorization-attribute { acl acl-number
| callback-number
4.
Configure the authorization
attributes for the user group.
callback-number | idle-cut minute |
level level | user-profile profile-name |
vlan vlan-id | work-directory
directory-name } *
By default, the user group uses
global settings. The global
settings in non-FIPS mode
include a 90-day password
aging time, a minimum
password length of 10
characters, and at least one
password composition type
and at least one character
required for each password
composition type. The global
settings in FIPS mode include a
90-day password aging time, a
minimum password length of
10 characters, and four
password composition types
and at least one character
required for each password
composition type.
Optional.
By default, no authorization
attribute is configured for a user
group.
The router does not support the
user-profile keyword.
Optional.
5.
Set the guest attribute for the
user group.
group-attribute allow-guest
20
By default, the guest attribute is
not set for a user group, and
guest users created by a guest
manager through the Web
interface cannot join the group.
Displaying and maintaining local users and local user groups
Task
Command
Display local user information.
display local-user [ idle-cut { disable |
enable } | service-type { ftp |
lan-access | portal | ppp | ssh | telnet
| terminal | web } | state { active |
block } | user-name user-name | vlan
vlan-id ] [ slot slot-number ] [ | { begin |
exclude | include } regular-expression ]
Display the user group configuration
information.
display user-group [ group-name ] [ |
{ begin | exclude | include }
regular-expression ]
Remarks
Available in any view.
The ftp and telnet
keywords are not
supported in FIPS mode.
Available in any view.
Configuring RADIUS schemes
A RADIUS scheme specifies the RADIUS servers that the router can cooperate with and defines a set of
parameters that the router uses to exchange information with the RADIUS servers. There may be
authentication/authorization servers and accounting servers, or primary servers and secondary servers.
The parameters mainly include the IP addresses of the servers, the shared keys, and the RADIUS server
type.
RADIUS scheme configuration task list
Task
Remarks
Creating a RADIUS scheme
Required
Specifying the RADIUS authentication/authorization servers
Required
Specifying the RADIUS accounting servers and the relevant parameters
Optional
Specifying the shared keys for RADIUS packets
Optional
Specifying a VPN for the scheme
Optional
Setting the supported RADIUS server type
Optional
Setting the maximum number of RADIUS request transmission attempts
Optional
Setting the status of RADIUS servers
Optional
Setting the username format and traffic statistics units
Optional
Specifying the source IP address for outgoing RADIUS packets
Optional
Setting RADIUS timers
Optional
Configuring RADIUS accounting-on
Optional
Configuring the IP address of the security policy server
Optional
Configuring interpretation of RADIUS class attribute as CAR parameters
Optional
Enabling the trap function for RADIUS
Optional
Enabling the RADIUS client service
Optional
Displaying and maintaining RADIUS
Optional
21
Creating a RADIUS scheme
Before performing other RADIUS configurations, follow these steps to create a RADIUS scheme and enter
RADIUS scheme view:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a RADIUS scheme and
enter RADIUS scheme view.
radius scheme
radius-scheme-name
No RADIUS scheme exists by
default.
NOTE:
A RADIUS scheme can be referenced by multiple ISP domains at the same time.
Specifying the RADIUS authentication/authorization servers
In RADIUS, user authorization information is piggybacked in authentication responses sent to RADIUS
clients. It is neither allowed nor needed to specify a separate RADIUS authorization server.
You can specify one primary authentication/authorization server and up to 16 secondary
authentication/authorization servers for a RADIUS scheme. When the primary server is not available, a
secondary server is used. In a scenario where redundancy is not required, specify only the primary
server.
A RADIUS authentication/authorization server can function as the primary authentication/authorization
server for one scheme and the secondary authentication/authorization server for another scheme at the
same time.
You can enable the server status detection feature. With the feature, the router periodically sends an
authentication request to check whether or not the target RADIUS authentication/authorization server is
reachable. If yes, the router sets the status of the server to active. If not, the router sets the status of the
server to block. This feature can promptly notify authentication modules of latest server status information.
For example, server status detection can work with the 802.1X critical VLAN feature, so that the router
can trigger 802.1X authentication for users in the critical VLAN immediately on detection of a reachable
RADIUS authentication/authorization server.
To specify RADIUS authentication/authorization servers for a RADIUS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme radius-scheme-name
N/A
22
Step
Command
Remarks
• Specify the primary RADIUS
3.
Specify RADIUS
authentication/authorization
servers.
authentication/authorization server:
primary authentication { ip-address
| ipv6 ipv6-address } [ port-number
| key [ cipher | simple ] key | probe
username name [ interval interval ]
| vpn-instance vpn-instance-name ]
*
• Specify a secondary RADIUS
authentication/authorization server:
secondary authentication
{ ip-address | ipv6 ipv6-address }
[ port-number | key [ cipher |
simple ] key | probe username
name [ interval interval ] |
vpn-instance vpn-instance-name ] *
Configure at least one
command.
No
authentication/authorization
server is specified by default.
NOTE:
• The IP addresses of the primary and secondary authentication/authorization servers for a scheme must
be different from each other. Otherwise, the configuration fails.
• All servers for authentication/authorization and accounting, primary or secondary, must use IP
addresses of the same IP version.
• You can specify a RADIUS authentication/authorization server as the primary
authentication/authorization server for one scheme and as the secondary authentication/authorization
server for another scheme at the same time.
Specifying the RADIUS accounting servers and the relevant parameters
You can specify one primary accounting server and up to 16 secondary accounting servers for a RADIUS
scheme. When the primary server is not available, a secondary server is used. When redundancy is not
required, specify only the primary server. A RADIUS accounting server can function as the primary
accounting server for one scheme and the secondary accounting server for another scheme at the same
time.
When the router receives a connection teardown request from a host or a connection teardown
notification from an administrator, it sends a stop-accounting request to the accounting server. By setting
the maximum number of real-time accounting attempts for a scheme, you make the router disconnect
users for whom no accounting response is received before the number of accounting attempts reaches
the limit. You can enable buffering of non-responded stop-accounting requests to allow the router to
buffer and resend a stop-accounting request until it receives a response or the number of stop-accounting
attempts reaches the upper limit, the router discards the buffered request.
To specify RADIUS accounting servers and set relevant parameters for a scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme radius-scheme-name
N/A
23
Step
Command
Remarks
• Specify the primary RADIUS
3.
Specify RADIUS accounting
servers.
accounting server:
primary accounting { ip-address |
ipv6 ipv6-address } [ port-number |
key [ cipher | simple ] key |
vpn-instance vpn-instance-name ] *
• Specify a secondary RADIUS
accounting server:
secondary accounting { ip-address |
ipv6 ipv6-address } [ port-number |
key [ cipher | simple ] key |
vpn-instance vpn-instance-name ] *
4.
5.
6.
Set the maximum number of
real-time accounting attempts.
retry realtime-accounting retry-times
Enable buffering of
stop-accounting requests to
which no responses are
received.
stop-accounting-buffer enable
Set the maximum number of
stop-accounting attempts.
retry stop-accounting retry-times
Configure at least one
command.
No accounting server is
specified by default.
Optional.
The default setting is 5.
Optional.
Enabled by default.
Optional.
The default setting is 500.
NOTE:
• The IP addresses of the primary and secondary accounting servers must be different from each other.
Otherwise, the configuration fails.
• All servers for authentication/authorization and accounting, primary or secondary, must use IP
addresses of the same IP version.
• If you delete an accounting server that is serving users, the router can no longer send real-time
accounting requests and stop-accounting requests for the users to that server, or buffer the
stop-accounting requests.
• You can specify a RADIUS accounting server as the primary accounting server for one scheme and as
the secondary accounting server for another scheme at the same time.
• RADIUS does not support accounting for FTP users.
Specifying the shared keys for RADIUS packets
The RADIUS client and RADIUS server use the MD5 algorithm to encrypt packets exchanged between
them and use shared keys to verify the packets. They must use the same shared key for the same type of
packets.
A shared key configured in this task is for all servers of the same type (accounting or authentication) in
the scheme, and has a lower priority than a shared key configured individually for a RADIUS server.
To specify shared keys for RADIUS packets:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme
radius-scheme-name
N/A
24
Step
Specify a shared key for
RADIUS
authentication/authorization
or accounting packets.
3.
Command
Remarks
key { accounting | authentication }
[ cipher | simple ] key
No shared key is specified by
default.
NOTE:
A shared key configured on the router must be the same as that configured on the RADIUS server.
Specifying a VPN for the scheme
After you specify a VPN for a RADIUS scheme, all the authentication/authorization/accounting servers
specified for the scheme belong to the VPN. However, if you also specify a VPN when specifying a server
for the scheme, the server belongs to the specified VPN.
To specify a VPN for a RADIUS scheme:
Step
Command
1.
Enter system view.
system-view
2.
Enter RADIUS scheme view.
radius scheme radius-scheme-name
3.
Specify a VPN for the RADIUS scheme.
vpn-instance vpn-instance-name
Setting the supported RADIUS server type
The supported RADIUS server type determines the type of the RADIUS protocol that the router uses to
communicate with the RADIUS server. It can be standard or extended:
•
Standard—Uses the standard RADIUS protocol, compliant to RFC 2865 and RFC 2866 or later.
•
Extended—Uses the proprietary RADIUS protocol of HP.
When the RADIUS server runs on IMC, you must set the RADIUS server type to extended. When the
RADIUS server runs third-party RADIUS server software, either RADIUS server type applies. For the router
to function as a RADIUS server to authenticate login users, you must set the RADIUS server type to
standard.
To set the RADIUS server type:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme radius-scheme-name
N/A
3.
Set the RADIUS server type.
server-type { extended | standard }
Optional.
The default RADIUS server type
is standard.
NOTE:
Changing the RADIUS server type restores the unit for data flows and that for the packets sent to the
RADIUS server to the defaults.
25
Setting the maximum number of RADIUS request transmission attempts
Because RADIUS uses UDP packets to transfer data, the communication process is not reliable. RADIUS
uses a retransmission mechanism to improve the reliability. If a NAS sends a RADIUS request to a
RADIUS server but receives no response after the response timeout timer (defined by the timer
response-timeout command) expires, it retransmits the request. If the number of transmission attempts
exceeds the specified limit but it still receives no response, it tries to communicate with other RADIUS
servers in active state. If no other servers are in active state at the time, it considers the authentication or
accounting attempt a failure. For more information about RADIUS server states, see "Setting the status of
RADIUS servers."
To set the maximum number of RADIUS request transmission attempts for a scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme radius-scheme-name
N/A
3.
Set the maximum number of RADIUS
request transmission attempts.
retry retry-times
Optional.
The default setting is 3.
NOTE:
• The maximum number of transmission attempts of RADIUS packets multiplied by the RADIUS server
response timeout period cannot be greater than 75 seconds.
• For more information about the RADIUS server response timeout period, see "Setting RADIUS timers"
Setting the status of RADIUS servers
By setting the status of RADIUS servers to blocked or active, you can control which servers the router
communicates with for authentication, authorization, and accounting, or turns to when the current servers
are no longer available. In practice, you can specify one primary RADIUS server and multiple secondary
RADIUS servers, with the secondary servers functioning as the backup of the primary servers. Generally,
the router chooses servers based on these rules:
•
When the primary server is in active state, the router communicates with the primary server. If the
primary server fails, the router changes the server's status to blocked and starts a quiet timer for the
server, and tries to communicate with a secondary server in active state (a secondary server
configured earlier has a higher priority). If the secondary server is unreachable, the router changes
the server's status to blocked, starts a quiet timer for the server, and continues to check the next
secondary server in active state. This search process continues until the router finds an available
secondary server or has checked all secondary servers in active state. If the quiet timer of a server
expires or an authentication or accounting response is received from the server, the status of the
server changes back to active automatically, but the router does not check the server again during
the authentication or accounting process. If no server is found reachable during one search process,
the router considers the authentication or accounting attempt a failure.
•
Once the accounting process of a user starts, the router keeps sending the user's real-time
accounting requests and stop-accounting requests to the same accounting server. If you remove the
accounting server, real-time accounting requests and stop-accounting requests for the user are no
longer delivered to the server.
•
If you remove an authentication or accounting server in use, the communication of the router with
the server soon times out, and the router looks for a server in active state from scratch by checking
any primary server first and then the secondary servers in the order they are configured.
26
•
When the primary server and secondary servers are all in blocked state, the router communicates
with the primary server. If the primary server is available, its status changes to active. Otherwise, its
status remains to be blocked.
•
If one server is in active state and all the others are in blocked state, the router only tries to
communicate with the server in active state, even if the server is unavailable.
•
After receiving an authentication/accounting response from a server, the router changes the status
of the server identified by the source IP address of the response to active if the current status of the
server is blocked.
The router does not change the status of an unreachable authentication or accounting server if the quiet
timer of the servers is set to 0. Instead, the router keeps the server status as active and sends
authentication or accounting packets to another server in active state, so that subsequent authentication
or accounting packets can still be sent to the server. For more information about the quiet timer, see
"Setting RADIUS timers"
By default, the router sets the status of all RADIUS servers to active. In some cases, however, you can
change the status of a server. For example, if a server fails, you can change the status of the server to
blocked to avoid communication with the server.
To set the status of RADIUS servers in a RADIUS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme radius-scheme-name
N/A
• Set the status of the primary RADIUS
authentication/authorization server:
state primary authentication { active |
block }
• Set the status of the primary RADIUS
accounting server:
state primary accounting { active | block }
3.
Set the status of RADIUS
servers.
• Set the status of a secondary RADIUS
authentication/authorization server:
state secondary authentication [ ip
ipv4-address | ipv6 ipv6-address ] { active
| block }
Optional.
The default setting is
active for every server
specified in the RADIUS
scheme.
• Set the status of a secondary RADIUS
accounting server:
state secondary accounting [ ip
ipv4-address | ipv6 ipv6-address ] { active
| block }
NOTE:
• The server status set by the state command cannot be saved to the configuration file. After the router
restarts, the status of each server is restored to active.
• To display the states of the servers, use the display radius scheme command.
Setting the username format and traffic statistics units
A username is usually in the format of userid@isp-name, where isp-name represents the name of the ISP
domain to which the user belongs and is used by the router to determine which users belong to which ISP
domains. However, some earlier RADIUS servers cannot recognize usernames that contain an ISP
27
domain name. In this case, the router must remove the domain name of each username before sending
the username. You can set the username format on the router for this purpose.
The router periodically sends accounting updates to RADIUS accounting servers to report the traffic
statistics of online users. For accurate traffic statistics, make sure the unit for data flows and that for
packets on the router are consistent with those on the RADIUS server.
To set the username format and the traffic statistics units for a RADIUS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme radius-scheme-name
N/A
3.
Set the format for usernames
sent to the RADIUS servers.
user-name-format { keep-original |
with-domain | without-domain }
4.
Specify the unit for data flows
or packets sent to the RADIUS
servers.
data-flow-format { data { byte |
giga-byte | kilo-byte | mega-byte }
| packet { giga-packet | kilo-packet
| mega-packet | one-packet } }*
Optional.
By default, the ISP domain name
is included in a username.
Optional.
The default unit is byte for data
flows and one-packet for data
packets.
NOTE:
• If a RADIUS scheme defines that the username is sent without the ISP domain name, do not apply the
RADIUS scheme to more than one ISP domain. Otherwise, users using the same username but in
different ISP domains are considered the same user.
• For level switching authentication, the user-name-format keep-original and user-name-format
without-domain commands produce the same results. They make sure usernames sent to the RADIUS
server carry no ISP domain name.
Specifying the source IP address for outgoing RADIUS packets
The source IP address of RADIUS packets that a NAS sends must match the IP address of the NAS
configured on the RADIUS server. A RADIUS server identifies a NAS by its IP address. Upon receiving a
RADIUS packet, a RADIUS server checks whether the source IP address of the packet is the IP address of
any managed NAS. If yes, the server processes the packet. If not, the server drops the packet.
Usually, the source address of outgoing RADIUS packets can be the IP address of the NAS's any
interface that can communicate with the RADIUS server. In some special scenarios, however, you must
change the source IP address. For example, if a Network Address Translation (NAT) device is present
between the NAS and the RADIUS server, the source IP address of outgoing RADIUS packets must be a
public IP address of the NAS. If the NAS is configured with the Virtual Router Redundancy Protocol (VRRP)
for stateful failover, the source IP address of outgoing RADIUS packets can be the virtual IP address of the
VRRP group to which the uplink belongs.
You can specify a source IP address for outgoing RADIUS packets in RADIUS scheme view for a specific
RADIUS scheme, or in system view for all RADIUS schemes whose servers are in a VPN or the public
network. Before sending a RADIUS packet, a NAS selects a source IP address in this order:
1.
The source IP address specified for the RADIUS scheme.
2.
The source IP address specified in system view for the VPN or public network, depending on where
the RADIUS server resides.
3.
The IP address of the outbound interface specified by the route.
28
To specify a source IP address for all RADIUS schemes in a VPN or the public network:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify a source IP address
for outgoing RADIUS packets.
radius nas-ip { ip-address | ipv6
ipv6-address } [ vpn-instance
vpn-instance-name ]
By default, the IP address of the
outbound interface is used as the
source IP address.
To specify a source IP address for a specific RADIUS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme
radius-scheme-name
N/A
3.
Specify a source IP address
for outgoing RADIUS packets.
nas-ip { ip-address | ipv6
ipv6-address }
By default, the IP address of the
outbound interface is used as the
source IP address.
Setting RADIUS timers
The router uses the following types of timers to control the communication with a RADIUS server:
•
Server response timeout timer (response-timeout)—Defines the RADIUS request retransmission
interval. After sending a RADIUS request (authentication/authorization or accounting request), the
router starts this timer. If the router receives no response from the RADIUS server before this timer
expires, it resends the request.
•
Server quiet timer (quiet)—Defines the duration to keep an unreachable server in blocked state. If
a server is not reachable, the router changes the server's status to blocked, starts this timer for the
server, and tries to communicate with another server in active state. After this timer expires, the
router changes the status of the server back to active.
•
Real-time accounting timer (realtime-accounting)—Defines the interval at which the router sends
real-time accounting packets to the RADIUS accounting server for online users. To implement
real-time accounting, the router must periodically send real-time accounting packets to the
accounting server for online users.
To set timers for controlling communication with RADIUS servers:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme radius-scheme-name
N/A
Optional.
3.
Set the RADIUS server
response timeout timer.
timer response-timeout seconds
4.
Set the quiet timer for the
servers.
timer quiet minutes
The default RADIUS server
response timeout timer is 3
seconds.
Optional.
29
The default quiet timer is 5
minutes.
Step
5.
Command
Set the real-time accounting
timer.
Remarks
Optional.
timer realtime-accounting minutes
The default real-time accounting
timer is 12 minutes.
NOTE:
• For a type of users, the maximum number of transmission attempts multiplied by the RADIUS server
response timeout period must be less than the client connection timeout time and must not exceed 75
seconds. Otherwise, stop-accounting messages cannot be buffered, and the primary/secondary server
switchover cannot take place. For example, the product of the two parameters must be less than 10
seconds for voice users, and less than 30 seconds for Telnet users because the client connection timeout
period for voice users is 10 seconds and that for Telnet users is 30 seconds.
• When you configure the maximum number of RADIUS packet transmission attempts and the RADIUS
server response timeout period, take the number of secondary servers into account. If the retransmission
process takes too much time, the client connection in the access module may be timed out while the
router is trying to find an available server.
• When a number of secondary servers are configured, the client connections of access modules that
have a short client connection timeout period may still be timed out during initial authentication or
accounting, even if the packet transmission attempt limit and server response timeout period are
configured with small values. In this case, the next authentication or accounting attempt may succeed
because the router has set the state of the unreachable servers to blocked and the time for finding a
reachable server is shortened.
• Make sure the server quiet timer is set correctly. Too short a quiet timer may result in frequent
authentication or accounting failures because the router keeps trying to communicate with an
unreachable server that is in active state.
• For more information about the maximum number of RADIUS packet transmission attempts, see
"Setting the maximum number of RADIUS request transmission attempts."
Configuring RADIUS accounting-on
The accounting-on feature enables a router to send accounting-on packets to the RADIUS server after it
reboots, making the server log out users who logged in through the router before the reboot. Without this
feature, users who were online before the reboot cannot re-log in after the reboot, because the RADIUS
server considers they are already online.
If a router sends an accounting-on packet to the RADIUS server but receives no response, it resends the
packet to the server at a particular interval for a specified number of times.
To configure the accounting-on feature for a RADIUS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme
radius-scheme-name
N/A
3.
Enable accounting-on and
configure parameters.
accounting-on enable [ interval
seconds | send send-times ] *
Disabled by default.
30
The default interval is 3 seconds
and the default number of
send-times is 5.
NOTE:
The accounting-on feature requires the cooperation of the HP IMC network management system.
Configuring the IP address of the security policy server
The core of the HP EAD solution is integration and cooperation, and the security policy server is the
management and control center. Using a collection of software, the security policy server provides
functions such as user management, security policy management, security status assessment, security
cooperation control, and security event audit.
The NAS checks the validity of received control packets and accepts only control packets from known
servers. To use a security policy server that is independent of the AAA servers, you must configure the IP
address of the security policy server on the NAS. To implement all EAD functions, configure both the IP
address of the IMC security policy server and that of the IMC Platform on the NAS.
To configure the IP address of the security policy server for a scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme radius-scheme-name
N/A
3.
Configure the IP address of
the security policy server.
security-policy-server ip-address
Not configured by default.
NOTE:
You can specify up to eight security policy servers for a RADIUS scheme.
Configuring interpretation of RADIUS class attribute as CAR parameters
According to RFC 2865, a RADIUS server assigns the RADIUS class attribute (attribute 25) to a RADIUS
client. However, the RFC only requires the RADIUS client to send the attribute to the accounting server on
an "as is" basis, but does not require the RADIUS client to interpret the attribute. Some RADIUS servers
use the class attribute to deliver the assigned committed access rate (CAR) parameters. In this case, the
router must interpret the attribute as the CAR parameters to implement user-based traffic monitoring and
controlling.
To configure a router to interpret the RADIUS class attribute as CAR parameters:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter RADIUS scheme view.
radius scheme radius-scheme-name
N/A
3.
Interpret the class attribute
as CAR parameters.
attribute 25 car
By default, RADIUS attribute 25 is
not interpreted as CAR parameters.
Enabling the trap function for RADIUS
With the trap function, a NAS sends a trap message when either of the following events occurs:
•
The status of a RADIUS server changes. If a NAS receives no response to an accounting or
authentication request before the specified maximum number of RADIUS request transmission
attempts is exceeded, it considers the server unreachable, sets the status of the server to block and
sends a trap message. If the NAS receives a response from a RADIUS server that it considers
31
unreachable, the NAS considers that the RADIUS server is reachable again, sets the status of the
server to active, and sends a trap message.
The ratio of the number of failed transmission attempts to the total number of authentication request
transmission attempts reaches the threshold. This threshold ranges from 1% to 100% and defaults to
30%. This threshold can only be configured through the MIB.
•
The failure ratio is generally small. If a trap message is triggered because the failure ratio is higher than
the threshold, troubleshoot the configuration on and the communication between the NAS and the
RADIUS server.
To enable the trap function for RADIUS:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the trap function for
RADIUS.
radius trap { accounting-server-down
| authentication-error-threshold |
authentication-server-down }
Disabled by default.
Enabling the RADIUS client service
To receive and send RADIUS packets, enable the RADIUS client service on the device. If RADIUS is not
required, disable the RADIUS client service to avoid attacks that exploit RADIUS packets.
To enable the RADIUS client service:
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Enable the RADIUS client
service.
radius client enable
Optional.
Enabled by default.
Displaying and maintaining RADIUS
Task
Command
Remarks
Display the configuration information
of a specified RADIUS scheme or all
RADIUS schemes.
display radius scheme
[ radius-scheme-name ] [ slot
slot-number ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display the statistics for RADIUS
packets.
display radius statistics [ slot
slot-number ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display information about buffered
stop-accounting requests for which no
responses have been received.
display stop-accounting-buffer
{ radius-scheme radius-scheme-name |
session-id session-id | time-range
start-time stop-time | user-name
user-name } [ slot slot-number ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Clear RADIUS statistics.
reset radius statistics [ slot slot-number ]
Available in user view.
32
Task
Command
Remarks
Clear the buffered stop-accounting
requests for which no responses have
been receive.
reset stop-accounting-buffer
{ radius-scheme radius-scheme-name |
session-id session-id | time-range
start-time stop-time | user-name
user-name } [ slot slot-number ]
Available in user view.
Configuring HWTACACS schemes
You cannot remove the HWTACACS schemes in use or change the IP addresses of the HWTACACS
servers in use.
HWTACACS configuration task list
Task
Remarks
Creating an HWTACACS scheme
Required
Specifying the HWTACACS authentication servers
Required
Specifying the HWTACACS authorization servers
Optional
Specifying the HWTACACS accounting servers and the relevant
parameters
Optional
Specifying the shared keys for HWTACACS packets
Required
Specifying a VPN for the scheme
Optional
Setting the username format and traffic statistics units
Optional
Specifying a source IP address for outgoing HWTACACS packets
Optional
Setting HWTACACS timers
Optional
Displaying and maintaining HWTACACS
Optional
Creating an HWTACACS scheme
The HWTACACS protocol is configured on a per scheme basis. Before performing other HWTACACS
configurations, follow these steps to create an HWTACACS scheme and enter HWTACACS scheme
view:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an HWTACACS
scheme and enter
HWTACACS scheme view.
hwtacacs scheme
hwtacacs-scheme-name
No HWTACACS scheme exists by
default.
NOTE:
• Up to 16 HWTACACS schemes can be configured.
• A scheme can be deleted only when it is not referenced.
33
Specifying the HWTACACS authentication servers
You can specify one primary authentication server and up to one secondary authentication server for an
HWTACACS scheme. When the primary server is not available, the secondary server is used. In a
scenario where redundancy is not required, specify only the primary server.
To specify HWTACACS authentication servers for an HWTACACS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter HWTACACS scheme
view.
hwtacacs scheme
hwtacacs-scheme-name
N/A
• Specify the primary HWTACACS
3.
Specify HWTACACS
authentication servers.
authentication server:
primary authentication ip-address
[ port-number | vpn-instance
vpn-instance-name ] *
• Specify the secondary HWTACACS
authentication server:
secondary authentication
ip-address [ port-number |
vpn-instance vpn-instance-name ] *
Configure at least one
command.
No authentication server is
specified by default.
NOTE:
• An HWTACACS server can function as the primary authentication server of one scheme and as the
secondary authentication server of another scheme at the same time.
• The IP addresses of the primary and secondary authentication servers cannot be the same. Otherwise,
the configuration fails.
• You can remove an authentication server only when no active TCP connection for sending authentication
packets is using it.
Specifying the HWTACACS authorization servers
You can specify one primary authorization server and up to one secondary authorization server for an
HWTACACS scheme. When the primary server is not available, the secondary server is used. In a
scenario where redundancy is not required, specify only the primary server.
To specify HWTACACS authorization servers for an HWTACACS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter HWTACACS scheme
view.
hwtacacs scheme hwtacacs-scheme-name
N/A
34
Step
Command
Remarks
• Specify the primary HWTACACS
3.
Specify HWTACACS
authorization servers.
authorization server:
primary authorization ip-address
[ port-number | vpn-instance
vpn-instance-name ] *
• Specify the secondary HWTACACS
authorization server:
secondary authorization ip-address
[ port-number | vpn-instance
vpn-instance-name ] *
Configure at least one
command.
No authorization server is
specified by default.
NOTE:
• An HWTACACS server can function as the primary authorization server of one scheme and as the
secondary authorization server of another scheme at the same time.
• The IP addresses of the primary and secondary authorization servers cannot be the same. Otherwise,
the configuration fails.
• You can remove an authorization server only when no active TCP connection for sending authorization
packets is using it.
Specifying the HWTACACS accounting servers and the relevant parameters
You can specify one primary accounting server and up to one secondary accounting server for an
HWTACACS scheme. When the primary server is not available, the secondary server is used. In a
scenario where redundancy is not required, specify only the primary server.
When the router receives a connection teardown request from a host or a connection teardown
command from an administrator, it sends a stop-accounting request to the accounting server. You can
enable buffering of non-responded stop-accounting requests to allow the router to buffer and resend a
stop-accounting request until it receives a response or the number of stop-accounting attempts reaches
the configured limit. In the latter case, the router discards the packet.
To specify HWTACACS accounting servers and set relevant parameters for an HWTACACS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter HWTACACS scheme
view.
hwtacacs scheme
hwtacacs-scheme-name
N/A
• Specify the primary HWTACACS
3.
Specify HWTACACS
accounting servers.
accounting server:
primary accounting ip-address
[ port-number | vpn-instance
vpn-instance-name ] *
• Specify the secondary HWTACACS
accounting server:
secondary accounting ip-address
[ port-number | vpn-instance
vpn-instance-name ] *
4.
Enable the router to buffer
stop-accounting requests
getting no responses.
stop-accounting-buffer enable
35
Configure at least one
command.
No accounting server is
specified by default.
Optional.
Enabled by default.
Step
5.
Command
Set the maximum number of
stop-accounting attempts.
Remarks
retry stop-accounting retry-times
Optional.
The default setting is 100.
NOTE:
• An HWTACACS server can function as the primary accounting server of one scheme and as the
secondary accounting server of another scheme at the same time.
• The IP addresses of the primary and secondary accounting servers cannot be the same. Otherwise, the
configuration fails.
• You can remove an accounting server only when no active TCP connection for sending accounting
packets is using it.
• HWTACACS does not support accounting for FTP users.
Specifying the shared keys for HWTACACS packets
The HWTACACS client and HWTACACS server use the MD5 algorithm to encrypt packets exchanged
between them and use shared keys to verify the packets. They must use the same shared key for the same
type of packets.
To specify the shared keys for HWTACACS packets:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter HWTACACS scheme
view.
hwtacacs scheme
hwtacacs-scheme-name
N/A
3.
Specify the shared keys for
HWTACACS authentication,
authorization, and accounting
packets.
key { accounting | authentication |
authorization } [ cipher | simple ] key
No shared key is specified by
default.
NOTE:
A shared key configured on the router must be the same as that configured on the HWTACACS server.
Specifying a VPN for the scheme
After you specify a VPN for an HWTACACS scheme, all the authentication, authorization, and
accounting servers specified for the scheme belong to the VPN. However, if you also specify a VPN when
specifying a server for the scheme, the server belongs to the specific VPN.
To specify a VPN for an HWTACACS scheme:
Step
Command
1.
Enter system view.
system-view
2.
Enter HWTACACS scheme view.
hwtacacs scheme hwtacacs-scheme-name
3.
Specify a VPN for the HWTACACS scheme.
vpn-instance vpn-instance-name
36
Setting the username format and traffic statistics units
A username is usually in the format of userid@isp-name, where isp-name represents the name of the ISP
domain to which the user belongs and is used by the router to determine which users belong to which ISP
domains. However, some HWTACACS servers cannot recognize usernames that contain an ISP domain
name. In this case, the router must remove the domain name of each username before sending the
username. You can set the username format on the router for this purpose.
The router periodically sends accounting updates to HWTACACS accounting servers to report the traffic
statistics of online users. For accurate traffic statistics, make sure the unit for data flows and that for
packets on the router are consistent with those configured on the HWTACACS servers.
To set the username format and the traffic statistics units for an HWTACACS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter HWTACACS scheme
view.
hwtacacs scheme
hwtacacs-scheme-name
N/A
3.
Set the format of usernames
sent to the HWTACACS
servers.
user-name-format { keep-original |
with-domain | without-domain }
By default, the ISP domain
name is included in a
username.
4.
Specify the unit for data flows
or packets sent to the
HWTACACS servers.
data-flow-format { data { byte |
giga-byte | kilo-byte | mega-byte } |
packet { giga-packet | kilo-packet |
mega-packet | one-packet } }*
Optional.
Optional.
The default unit is byte for data
flows and one-packet for data
packets.
NOTE:
• If an HWTACACS server does not support a username with the domain name, configure the router to
remove the domain name before sending the username to the server.
• For level switching authentication, the user-name-format keep-original and user-name-format
without-domain commands produce the same results. They make sure usernames sent to the
HWTACACS server carry no ISP domain name.
Specifying a source IP address for outgoing HWTACACS packets
The source IP address of HWTACACS packets that a NAS sends must match the IP address of the NAS
configured on the HWTACACS server. An HWTACACS server identifies a NAS by IP address. Upon
receiving an HWTACACS packet, an HWTACACS server checks whether the source IP address of the
packet is the IP address of any managed NAS. If yes, the server processes the packet. If not, the server
drops the packet.
Usually, the source address of outgoing HWTACACS packets can be the IP address of the NAS's any
interface that can communicate with the HWTACACS server. In some special scenarios, however, you
must change the source IP address. For example, if a Network Address Translation (NAT) device is
present between the NAS and the HWTACACS server, the source IP address of outgoing HWTACACS
packets must be a public IP address of the NAS. If the NAS is configured with the Virtual Router
Redundancy Protocol (VRRP) for stateful failover, the source IP address of HWTACACS packets can be
the virtual IP address of the VRRP group to which the uplink belongs.
37
You can specify the source IP address for outgoing HWTACACS packets in HWTACACS scheme view for
a specific HWTACACS scheme, or in system view for all HWTACACS schemes whose servers are in a
VPN or the public network.
Before sending an HWTACACS packet, a NAS selects a source IP address in this order:
1.
The source IP address specified for the HWTACACS scheme.
2.
The source IP address specified in system view for the VPN or public network, depending on where
the HWTACACS server resides.
3.
The IP address of the outbound interface specified by the route.
To specify a source IP address for all HWTACACS schemes of a VPN or the public network:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify a source IP address
for outgoing HWTACACS
packets.
hwtacacs nas-ip ip-address
[ vpn-instance vpn-instance-name ]
By default, the IP address of the
outbound interface is used as the
source IP address.
To specify a source IP address for a specific HWTACACS scheme:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter HWTACACS scheme
view.
hwtacacs scheme
hwtacacs-scheme-name
N/A
3.
Specify a source IP address
for outgoing HWTACACS
packets.
nas-ip ip-address
By default, the IP address of the
outbound interface is used as the
source IP address.
Setting HWTACACS timers
The router uses the following timers to control the communication with an HWTACACS server:
•
Server response timeout timer (response-timeout)—Defines the HWTACACS request
retransmission interval. After sending an HWTACACS request (authentication, authorization, or
accounting request), the router starts this timer. If the router receives no response from the server
before this timer expires, it resends the request.
•
Server quiet timer (quiet)—Defines the duration to keep an unreachable server in blocked state. If
a server is not reachable, the router changes the server's status to blocked, starts this timer for the
server, and tries to communicate with another server in active state. After this timer expires, the
router changes the status of the server back to active.
•
Real-time accounting timer (realtime-accounting)—Defines the interval at which the router sends
real-time accounting updates to the HWTACACS accounting server for online users. To implement
real-time accounting, the router must send real-time accounting packets to the accounting server for
online users periodically.
To set timers for controlling communication with HWTACACS servers:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
38
Step
Command
Remarks
hwtacacs scheme
hwtacacs-scheme-name
N/A
2.
Enter HWTACACS scheme
view.
3.
Set the HWTACACS server
response timeout timer.
timer response-timeout seconds
4.
Set the quiet timer for the
primary server.
timer quiet minutes
5.
Set the real-time accounting
interval.
Optional.
The default HWTACACS server
response timeout timer is 5
seconds.
Optional.
The default quiet timer for the
primary server is 5 minutes.
Optional.
timer realtime-accounting minutes
The real-time accounting interval is
12 minutes.
NOTE:
Consider the performance of the NAS and the HWTACACS server when you set the real-time accounting
interval. A shorter interval requires higher performance.
Displaying and maintaining HWTACACS
Task
Command
Remarks
Display configuration information or
statistics of the specified or all
HWTACACS schemes.
display hwtacacs
[ hwtacacs-server-name [ statistics ] ]
[ slot slot-number ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display information about buffered
stop-accounting requests for which no
responses have been received.
display stop-accounting-buffer
hwtacacs-scheme
hwtacacs-scheme-name [ slot
slot-number ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Clear HWTACACS statistics.
reset hwtacacs statistics { accounting |
all | authentication | authorization }
[ slot slot-number ]
Available in user view.
Clear buffered stop-accounting
requests that get no responses.
reset stop-accounting-buffer
hwtacacs-scheme
hwtacacs-scheme-name [ slot
slot-number ]
Available in user view.
Configuring AAA methods for ISP domains
You configure AAA methods for an ISP domain by referencing configured AAA schemes in ISP domain
view. Each ISP domain has a set of default AAA methods, which are local authentication, local
authorization, and local accounting by default and can be customized. If you do not configure any AAA
methods for an ISP domain, the router uses the system default AAA methods for authentication,
authorization, and accounting of the users in the domain.
39
Configuration prerequisites
To use local authentication for users in an ISP domain, configure local user accounts (see "Configuring
local user attributes") on the router.
To use remote authentication, authorization, and accounting, create the required RADIUS and
HWTACACS schemes as described in "Configuring RADIUS schemes" and "Configuring HWTACACS
schemes."
Creating an ISP domain
In a networking scenario with multiple ISPs, the router may connect users of different ISPs, and users of
different ISPs may have different user attributes, such as different username and password structures,
different service types, and different rights. To manage users of different ISPs, configure ISP domains, and
configure different AAA methods and domain attributes for the ISP domains as required.
The router can accommodate up to 16 ISP domains, including the system predefined ISP domain system.
You can specify one of the ISP domains as the system default domain.
On the router, each user belongs to an ISP domain. If a user provides no ISP domain name at login, the
router considers the user belongs to the system default ISP domain.
The router chooses an authentication domain for each user in the following order:
•
Authentication domain specified for the access module
•
ISP domain in the username
•
Default ISP domain of the router
•
ISP domain specified for users with unknown domain names
If all these domains are unavailable, user authentication fails.
Support for the authentication domain configuration depends on the access module. You can specify an
authentication domain for 802.1X, portal, or MAC address authentication.
To create an ISP domain:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an ISP domain and
enter ISP domain view.
domain isp-name
N/A
3.
Return to system view.
quit
N/A
4.
Specify the default ISP
domain.
domain default enable isp-name
5.
Specify an ISP domain for
users with unknown domain
names.
Optional.
By default, the default ISP domain is the
system predefined ISP domain system.
Optional.
domain if-unknown isp-name
By default, no ISP domain is specified
for users with unknown domain names.
NOTE:
To delete the ISP domain that is functioning as the default ISP domain, you must change it to a non-default
ISP domain first by using the domain default disable command.
40
Configuring ISP domain attributes
In an ISP domain, you can configure the following attributes:
•
Domain status—By placing the ISP domain to the active or blocked state, you allow or deny
network service requests from users in the domain.
•
Maximum number of online users—The router controls the number of online users in a domain to
ensure the system performance and service reliability.
•
Idle cut—This function enables the router to check the traffic of each online user in the domain at the
idle timeout interval, and to log out any user in the domain whose traffic during the idle timeout
period is less than the specified minimum traffic.
•
Self-service server location—By using the information defined in this attribute, users can access the
self-service server to manage their own accounts and passwords.
•
IP address pool for allocating addresses to PPP users—The router assigns IP addresses in this pool
to PPP users in the domain.
An ISP domain attribute applies to all users in the domain.
To configure ISP domain attributes:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter ISP domain view.
domain isp-name
N/A
3.
Place the ISP domain to the
state of active or blocked.
state { active | block }
By default, an ISP domain is in the
active state, and users in the domain
can request network services.
4.
Specify the maximum
number of active users in the
ISP domain.
access-limit enable
max-user-number
Optional.
Optional.
No limit by default.
Optional.
Disabled by default.
5.
Configure the idle cut
function.
idle-cut enable minute [ flow ]
6.
Configure the self-service
server location function.
self-service-url enable url-string
Define an IP address pool for
allocating addresses to PPP
users.
ip pool pool-number
low-ip-address [ high-ip-address ]
7.
8.
Set the router to include the
idle cut time in the user
online time to be uploaded
to the server.
This command is effective for only
LAN users, portal users, and PPP
users.
Optional.
Disabled by default.
Optional.
By default, no IP address pool is
configured for PPP users.
Optional.
session-time include-idle-time
41
By default, the user online time
uploaded to the server excludes the
idle cut time.
NOTE:
A self-service RADIUS server, such as Intelligent Management Center (IMC), is required for the self-service
server location function to work.
Configuring AAA authentication methods for an ISP domain
In AAA, authentication, authorization, and accounting are separate processes. Authentication refers to
the interactive authentication process of username/password/user information during an access or
service request. The authentication process neither sends authorization information to a supplicant nor
triggers any accounting.
AAA supports the following authentication methods:
•
No authentication (none)—All users are trusted and no authentication is performed. Generally, do
not use this method.
•
Local authentication (local)—Authentication is performed by the NAS, which is configured with the
user information, including the usernames, passwords, and attributes. Local authentication features
high speed and low cost, but the amount of information that can be stored is limited by the size of
the storage space.
•
Remote authentication (scheme)—The NAS cooperates with a RADIUS or HWTACACS server to
authenticate users. Remote authentication features centralized information management, high
capacity, high reliability, and support for centralized authentication service for multiple NASs. You
can configure local or no authentication as the backup method to be used when the remote server
is not available. No authentication can only be configured for LAN users as the backup method of
remote authentication.
You can configure AAA authentication to work alone without authorization and accounting. By default,
an ISP domain uses the local authentication method.
Before configuring authentication methods, complete the following tasks:
•
For RADIUS or HWTACACS authentication, configure the RADIUS or HWTACACS scheme to be
referenced first. The local and none authentication methods do not require any scheme.
•
Determine the access type or service type to be configured. With AAA, you can configure an
authentication method for each access type and service type, limiting the authentication protocols
that can be used for access.
•
Determine whether to configure an authentication method for all access types or service types.
To configure AAA authentication methods for an ISP domain:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter ISP domain view.
domain isp-name
N/A
Optional.
Specify the default
authentication method for all
types of users.
authentication default
{ hwtacacs-scheme
hwtacacs-scheme-name [ local ] |
local | none | radius-scheme
radius-scheme-name [ local ] }
3.
42
The default authentication method
is local for all types of users.
The none keyword is not supported
in FIPS mode.
Step
4.
5.
Command
Specify the authentication
method for LAN users.
authentication lan-access { local |
none | radius-scheme
radius-scheme-name [ local |
none ] }
Specify the authentication
method for login users.
authentication login
{ hwtacacs-scheme
hwtacacs-scheme-name [ local ] |
local | none | radius-scheme
radius-scheme-name [ local ] }
Remarks
Optional.
The default authentication method
is used by default.
The none keyword is not supported
in FIPS mode.
Optional.
The default authentication method
is used by default.
The none keyword is not supported
in FIPS mode.
Optional.
6.
7.
8.
Specify the authentication
method for portal users.
authentication portal { local | none
| radius-scheme
radius-scheme-name [ local ] }
The default authentication method
is used by default.
Optional.
Specify the authentication
method for PPP users.
authentication ppp
{ hwtacacs-scheme
hwtacacs-scheme-name [ local ] |
local | none | radius-scheme
radius-scheme-name [ local ] }
Specify the authentication
method for privilege level
switching.
authentication super
{ hwtacacs-scheme
hwtacacs-scheme-name |
radius-scheme
radius-scheme-name }
The none keyword is not supported
in FIPS mode.
The default authentication method
is used by default.
The none keyword is not supported
in FIPS mode.
Optional.
The default authentication method
is used by default.
NOTE:
• The authentication method specified with the authentication default command is for all types of users
and has a priority lower than that for a specific access type.
• With an authentication method that references a RADIUS scheme, AAA accepts only the authentication
result from the RADIUS server. The Access-Accept message from the RADIUS server does include the
authorization information, but the authentication process ignores the information.
• If you specify the radius-scheme radius-scheme-name local or hwtacacs-scheme
hwtacacs-scheme-name local option when you configure an authentication method, local
authentication is the backup method and is used only when the remote server is not available.
• If you specify only the local or none keyword in an authentication method configuration command, the
router has no backup authentication method and performs only local authentication or does not perform
any authentication.
• If the method for level switching authentication references an HWTACACS scheme, the router uses the
login username of a user for level switching authentication of the user by default. If the method for level
switching authentication references a RADIUS scheme, the system uses the username configured for the
corresponding privilege level on the RADIUS server for level switching authentication, rather than the
login username. A username configured on the RADIUS server is in the format of $enablevel$, where
level specifies the privilege level to which the user wants to switch. For example, if user user1 of domain
aaa wants to switch the privilege level to 3, the system uses $enab3@aaa$ for authentication when the
domain name is required and uses $enab3$ for authentication when the domain name is not required.
43
Configuring AAA authorization methods for an ISP domain
In AAA, authorization is a separate process at the same level as authentication and accounting. Its
responsibility is to send authorization requests to the specified authorization servers and to send
authorization information to users after successful authorization. Authorization method configuration is
optional in AAA configuration.
AAA supports the following authorization methods:
•
No authorization (none)—The NAS performs no authorization exchange. After passing
authentication, non-login users can access the network, FTP users can access the root directory of
the NAS, and other login users have only the right of Level 0 (visiting).
•
Local authorization (local)—The NAS performs authorization according to the user attributes
configured for users.
•
Remote authorization (scheme)—The NAS cooperates with a RADIUS or HWTACACS server to
authorize users. RADIUS authorization is bound with RADIUS authentication. RADIUS authorization
can work only after RADIUS authentication is successful, and the authorization information is
carried in the Access-Accept message. HWTACACS authorization is separate from HWTACACS
authentication, and the authorization information is carried in the authorization response after
successful authentication. You can configure local authorization or no authorization as the backup
method to be used when the remote server is not available.
Before configuring authorization methods, complete the following tasks:
1.
For HWTACACS authorization, configure the HWTACACS scheme to be referenced first. For
RADIUS authorization, the RADIUS authorization scheme must be the same as the RADIUS
authentication scheme. Otherwise, it does not take effect.
2.
Determine the access type or service type to be configured. With AAA, you can configure an
authorization scheme for each access type and service type, limiting the authorization protocols
that can be used for access.
3.
Determine whether to configure an authorization method for all access types or service types.
To configure AAA authorization methods for an ISP domain:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter ISP domain view.
domain isp-name
N/A
Optional.
3.
Specify the default
authorization method for
all types of users.
authorization default { hwtacacs-scheme
hwtacacs-scheme-name [ local ] | local |
none | radius-scheme radius-scheme-name
[ local ] }
The default authorization
method is local for all types of
users.
The none keyword is not
supported in FIPS mode.
Optional.
4.
Specify the command
authorization method.
authorization command { hwtacacs-scheme
hwtacacs-scheme-name [ local | none ] |
local | none }
44
The default authorization
method is used by default.
The none keyword is not
supported in FIPS mode.
Step
Command
Remarks
Optional.
5.
6.
Specify the authorization
method for LAN users.
authorization lan-access { local | none |
radius-scheme radius-scheme-name [ local |
none ] }
Specify the authorization
method for login users.
authorization login { hwtacacs-scheme
hwtacacs-scheme-name [ local ] | local |
none | radius-scheme radius-scheme-name
[ local ] }
The default authorization
method is used by default.
The none keyword is not
supported in FIPS mode.
Optional.
The default authorization
method is used by default.
The none keyword is not
supported in FIPS mode.
Optional.
7.
8.
Specify the authorization
method for portal users.
authorization portal { local | none |
radius-scheme radius-scheme-name
[ local ] }
Specify the authorization
method for PPP users.
authorization ppp { hwtacacs-scheme
hwtacacs-scheme-name [ local ] | local |
none | radius-scheme radius-scheme-name
[ local ] }
The default authorization
method is used by default.
The none keyword is not
supported in FIPS mode.
Optional.
The default authorization
method is used by default.
The none keyword is not
supported in FIPS mode.
NOTE:
• The authorization method specified with the authorization default command is for all types of users and
has a priority lower than that for a specific access type.
• If you configure an authentication method and an authorization method that use RADIUS schemes for
an ISP domain, the RADIUS scheme for authorization must be the same as that for authentication. If the
RADIUS authorization configuration is invalid or RADIUS authorization fails, the RADIUS authentication
also fails. Whenever RADIUS authorization fails, an error message is sent to the NAS, indicating that
the server is not responding.
• If you specify the radius-scheme radius-scheme-name local or hwtacacs-scheme
hwtacacs-scheme-name [ local | none ] option when you configure an authorization method, local
authorization or no authorization is the backup method and is used only when the remote server is not
available.
• If you specify only the local or none keyword in an authorization method configuration command, the
router has no backup authorization method and performs only local authorization or does not perform
any authorization.
Configuring AAA accounting methods for an ISP domain
In AAA, accounting is a separate process at the same level as authentication and authorization. Its
responsibility is to send accounting start/update/end requests to the specified accounting server.
Accounting is not required, and therefore accounting method configuration is optional.
AAA supports the following accounting methods:
•
No accounting (none)—The system does not perform accounting for the users.
45
•
Local accounting (local)—Local accounting is implemented on the NAS. It is for counting and
controlling the number of concurrent users who use the same local user account, but does not
provide statistics for charging. The maximum number of concurrent users using the same local user
account is set by the access-limit command in local user view.
•
Remote accounting (scheme)—The NAS cooperates with a RADIUS server or HWTACACS server
for accounting of users. You can configure local or no accounting as the backup method to be used
when the remote server is not available.
By default, an ISP domain uses the local accounting method.
Before configuring accounting methods, complete the following tasks:
1.
For RADIUS or HWTACACS accounting, configure the RADIUS or HWTACACS scheme to be
referenced first. The local and none authentication methods do not require any scheme.
2.
Determine the access type or service type to be configured. With AAA, you can configure an
accounting method for each access type and service type, limiting the accounting protocols that
can be used for access.
3.
Determine whether to configure an accounting method for all access types or service types.
To configure AAA accounting methods for an ISP domain:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter ISP domain view.
domain isp-name
N/A
Optional.
Disabled by default.
3.
4.
5.
6.
7.
With the accounting optional feature,
the router allows users to use network
resources when no accounting server
is available or communication with
all accounting servers fails.
Enable the accounting
optional feature.
accounting optional
Optional.
Specify the default accounting
method for all types of users.
accounting default
{ hwtacacs-scheme
hwtacacs-scheme-name [ local ]
| local | none | radius-scheme
radius-scheme-name [ local ] }
Specify the command
accounting method.
accounting command
hwtacacs-scheme
hwtacacs-scheme-name
Optional.
Specify the accounting
method for LAN users.
accounting lan-access { local |
none | radius-scheme
radius-scheme-name [ local |
none ] }
Specify the accounting
method for login users.
accounting login
{ hwtacacs-scheme
hwtacacs-scheme-name [ local ]
| local | none | radius-scheme
radius-scheme-name [ local ] }
46
The default accounting method is
local for all types of users.
The none keyword is not supported in
FIPS mode.
The default accounting method is
used by default.
Optional.
The default accounting method is
used by default.
The none keyword is not supported in
FIPS mode.
Optional.
The default accounting method is
used by default.
The none keyword is not supported in
FIPS mode.
Step
Command
Remarks
Optional.
8.
9.
Specify the accounting
method for portal users.
accounting portal { local | none
| radius-scheme
radius-scheme-name [ local ] }
The default accounting method is
used by default.
Optional.
Specify the accounting
method for PPP users.
accounting ppp
{ hwtacacs-scheme
hwtacacs-scheme-name [ local ]
| local | none | radius-scheme
radius-scheme-name [ local ] }
The none keyword is not supported in
FIPS mode.
The default accounting method is
used by default.
The none keyword is not supported in
FIPS mode.
NOTE:
• If you configure the accounting optional command, the limit on the number of local user connections is
not effective.
• The accounting method specified with the accounting default command is for all types of users and has
a priority lower than that for a specific access type.
• If you specify the radius-scheme radius-scheme-name local or hwtacacs-scheme
hwtacacs-scheme-name local option configured when you configure an accounting method, local
accounting is the backup method and is used only when the remote server is not available.
• If you specify only the local or none keyword in an accounting method configuration command, the
router has no backup accounting method and performs only local accounting or does not perform any
accounting.
• Accounting is not supported for FTP services.
Tearing down user connections
Step
1.
2.
Command
Remarks
Enter system view.
system-view
N/A
Tear down AAA
user connections
forcibly.
cut connection { access-type { dot1x |
mac-authentication | portal } | all | domain
isp-name | interface interface-type
interface-number | ip ip-address | mac
mac-address | ucibindex ucib-index |
user-name user-name | vlan vlan-id } [ slot
slot-number ]
Applicable to only LAN access,
portal and PPP user connections.
Displaying and maintaining AAA
47
Task
Command
Remarks
Display the configuration
information of a specified ISP
domain or all ISP domains.
display domain [ isp-name ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display information about
specified or all user connections.
display connection [ access-type { dot1x |
mac-authentication | portal } | domain
isp-name | interface interface-type
interface-number | ip ip-address | mac
mac-address | ucibindex ucib-index |
user-name user-name | vlan vlan-id ] [ slot
slot-number ] [ | { begin | exclude | include }
regular-expression ]
Available in any view.
AAA configuration examples
RADIUS authentication/authorization for Telnet/SSH users
The RADIUS authentication and authorization configuration for SSH users is similar to that for Telnet users.
This example describes the configuration for Telnet users.
Network requirements
Configure IMC to act as the RADIUS server to provide authentication and authorization services for Telnet
users. Add an account on the RADIUS server, with the username hello@bbb. Set the privilege level of the
user to 3.
Set the shared keys for authentication and authorization exchanges between the router and the RADIUS
server to expert and specify the ports for authentication/authorization as 1812.
Configure the router to include domain names in usernames sent to the RADIUS server.
Figure 10 Network diagram
RADIUS server
10.1.1.1/24
GE4/1/1
192.168.1.70/24
Telnet user
192.168.1.58/24
GE4/1/2
10.1.1.2/24
Internet
Router
Configuration procedure
1.
Configure the RADIUS server (on IMC PLAT 5.0):
NOTE:
In this section, the RADIUS server runs on IMC PLAT 5.0 (E0101) and IMC UAM 5.0 (E0101).
48
# Add the router to the IMC Platform as an access device.
Log in to IMC, click the Service tab, and select User Access Manager > Access Device Management >
Access Device from the navigation tree. Then, click Add to configure an access device as follows:
a. Set the shared key for secure authentication communication to expert.
b. Set the ports for authentication to 1812.
c. Select the service type Device Management Service.
d. Select the access device type HP(General).
e. Select the access device from the device list or manually add the access device (with the IP
address 10.1.1.2).
f. Click OK.
NOTE:
The IP address of the access device specified here must be the same as the source IP address of the RADIUS
packets sent from the device, which is chosen in this order:
• The IP address specified with the nas-ip command on the device.
• The IP address specified with the radius nas-ip command on the device.
• The IP address of the outbound interface (the default).
Figure 11 Adding the router as an access device
# Add a user for device management.
Click the User tab, and select Access User View > Device Mgmt User from the navigation tree. Then, click
Add to configure a device management account as follows:
a. Enter the account name hello@bbb and specify the password.
b. Select the service type Telnet.
c. Set the EXEC privilege level to 3. This argument identifies the privilege level of the Telnet user
after login and defaults to 0.
d. Specify 10.1.1.0 to 10.1.1.255 as the IP address range of the hosts to be managed.
e. Click OK.
49
NOTE:
The IP address range must contain the IP address of the access device.
Figure 12 Adding an account for device management
2.
Configure the router:
# Configure the IP address of interface GigabitEthernet 4/1/1, through which the Telnet user
accesses the router.
<Router> system-view
[Router] interface GigabitEthernet 4/1/1
[Router-GigabitEthernet4/1/1] ip address 192.168.1.70 255.255.255.0
[Router-GigabitEthernet4/1/1] quit
# Configure the IP address of interface GigabitEthernet 4/1/2, through which the router
communicates with the server.
[Router] interface gigabitethernet 4/1/2
[Router-GigabitEthernet4/1/2] ip address 10.1.1.2 255.255.255.0
[Router-GigabitEthernet4/1/2] quit
# Enable the Telnet server on the router.
[Router] telnet server enable
# Configure the router to use AAA for Telnet users.
[Router] user-interface vty 0 4
[Router-ui-vty0-4] authentication-mode scheme
[Router-ui-vty0-4] quit
# Create RADIUS scheme rad.
50
[Router] radius scheme rad
# Specify the primary authentication server, with the IP address of 10.1.1.1, and authentication
port of 1812.
[Router-radius-rad] primary authentication 10.1.1.1 1812
# Set the shared key for authentication packets to expert.
[Router-radius-rad] key authentication expert
# Specify the service type for the RADIUS server, which must be extended when the server runs on
IMC.
[Router-radius-rad] server-type extended
# Specify the scheme to include the domain names in usernames to be sent to the RADIUS server.
[Router-radius-rad] user-name-format with-domain
[Router-radius-rad] quit
# Configure the AAA methods for domain bbb. As RADIUS authorization information is sent to the
RADIUS client in the authentication response messages, reference the same scheme for user
authentication and authorization.
[Router] domain bbb
[Router-isp-bbb] authentication login radius-scheme rad
[Router-isp-bbb] authorization login radius-scheme rad
[Router-isp-bbb] quit
Verifying the configuration
After the above configuration, the Telnet user should be able to telnet to the router, use the
configured account to enter the user interface of the router, and access all the commands of level
0 to level 3.
# Use the display connection command to view the connection information on the router.
[Router] display connection
Index=1
,Username=hello@bbb
IP=192.168.1.58
IPv6=N/A
Total 1 connection(s) matched.
Local authentication/authorization for FTP/Telnet users
The local authentication and authorization configuration for FTP users is similar to that for Telnet users.
This example describes the configuration for Telnet users.
Network requirements
As shown in Figure 13, configure the router to perform local authentication and authorization for Telnet
users.
Figure 13 Network diagram
51
Configuration procedure
# Configure the IP address of interface GigabitEthernet 4/1/1, through which the Telnet user
accesses the router.
<Router> system-view
[Router] interface GigabitEthernet 4/1/1
[Router-GigabitEthernet4/1/1] ip address 192.168.1.70 255.255.255.0
[Router-GigabitEthernet4/1/1] quit
# Enable the Telnet server on the router.
[Router] telnet server enable
# Configure the router to use AAA for Telnet users.
[Router] user-interface vty 0 4
[Router-ui-vty0-4] authentication-mode scheme
[Router-ui-vty0-4] quit
# Create local user named telnet.
[Router] local-user telnet
[Router-luser-telnet] service-type telnet
[Router-luser-telnet] password simple aabbccddee
[Router-luser-telnet] quit
# Configure the AAA schemes the ISP domain as local authentication and authorization.
[Router] domain system
[Router-isp-system] authentication login local
[Router-isp-system] authorization login local
[Router-isp-system] quit
Verifying the configuration
When telnetting to the router, a user can access the user interface of the router using username
telnet@system and correct password.
# Use the display connection command to view the connection information on Router.
[Router] display connection
Index=1
,Username=telnet@system
IP=192.168.1.58
IPv6=N/A
Total 1 connection(s) matched.
AAA for PPP users by an HWTACACS server
Network requirements
As shown in Figure 14, configure the router to use the HWTACACS server to assign IP addresses and
provide authentication, authorization, and accounting services for PPP users. Set the shared keys for
authenticating authentication, authorization, and accounting packets exchanged with the server to
expert. Configure the router to remove the domain name from a username before sending the username
to the HWTACACS server.
52
Figure 14 Network diagram
HWTACACS server
10.1.1.1/24
v
PSTN
GE3/1/1
10.1.1.2/24
S4/1/9/1:0
2.2.2.1/24
v
PPP user
Internet
Router
Configuration procedure
1.
Configure the HWTACACS server:
# On the HWTACACS server, set the shared keys for packets exchanged with the router to expert.
Add the PPP user and specify the password. (Details not shown.)
2.
Configure the router:
# Create HWTACACS scheme hwtac.
<Router> system-view
[Router] hwtacacs scheme hwtac
# Specify the primary authentication server.
[Router-hwtacacs-hwtac] primary authentication 10.1.1.1 49
# Specify the primary authorization server.
[Router-hwtacacs-hwtac] primary authorization 10.1.1.1 49
# Specify the primary accounting server.
[Router-hwtacacs-hwtac] primary accounting 10.1.1.1 49
# Set the shared keys for authenticating authentication, authorization, and accounting packets to
expert.
[Router-hwtacacs-hwtac] key authentication simple expert
[Router-hwtacacs-hwtac] key authorization simple expert
[Router-hwtacacs-hwtac] key accounting simple expert
# Specify the scheme to exclude the domain names from usernames to be sent to the HWTACACS
server.
[Router-hwtacacs-hwtac] user-name-format without-domain
[Router-hwtacacs-hwtac] quit
# Apply the AAA schemes to the domain.
[Router] domain bbb
[Router-isp-bbb] authentication ppp hwtacacs-scheme hwtac
[Router-isp-bbb] authorization ppp hwtacacs-scheme hwtac
[Router-isp-bbb] accounting ppp hwtacacs-scheme hwtac
[Router-isp-bbb] ip pool 1 200.1.1.1 200.1.1.99
[Router-isp-bbb] quit
# Configure the serial interface.
[Router] interface serial 4/1/9/1:0
[Router-Serial4/1/9/1:0] link-protocol ppp
53
[Router-Serial4/1/9/1:0] ppp authentication-mode pap domain bbb
[Router-Serial4/1/9/1:0] ip address 2.2.2.1 255.255.255.0
[Router-Serial4/1/9/1:0] remote address pool 1
[Router-Serial4/1/9/1:0] quit
# Configure the GigabitEthernet interface.
[Router] interface GigabitEthernet 3/1/1
[Router-GigabitEthernet3/1/1] ip address 10.1.1.2 255.255.255.0
Verifying the configuration
Initiate a PPP connection from the PPP client, and enter the correct username and password. You pass
authentication and the PPP client can use the IP address assigned by the router to access the network. You
can use the display connection command on the router to view information about the connection.
RADIUS level switching authentication for Telnet users
The RADIUS server in this example runs ACSv4.0.
Network requirements
As shown in Figure 15, configure the router to:
•
Use local authentication for the Telnet user and assign the privilege level of 0 to the user after the
user passes authentication.
•
Use the RADIUS server for level switching authentication of the Telnet user, and use local
authentication as the backup.
Figure 15 Network diagram
RADIUS server
10.1.1.1/24
GE4/1/1
192.168.1.70/24
Telnet user
192.168.1.58/24
GE4/1/2
10.1.1.2/24
Internet
Router
Configuration considerations
1.
2.
Configure the router to use AAA, particularly, local authentication for Telnet users.
{
Create ISP domain bbb and configure it to use local authentication for Telnet users.
{
Create a local user account, configure the password, and assign the user privilege level.
On the router, configure the authentication method for user privilege level switching.
{
{
Specify to use RADIUS authentication and, if RADIUS authentication is not available, use local
authentication for users switching from a lower level to a higher level.
Configure RADIUS scheme rad and assign an IP address to the RADIUS server. Set the shared
keys for message exchange and specify that usernames sent to the RADIUS server carry no
domain name. Configure the domain to use RADIUS scheme rad for user privilege level
switching authentication.
54
{
3.
Configure the password for local user privilege level switching authentication.
On the RADIUS server, add the username and password for user privilege level switching
authentication.
Configuration procedure
1.
Configure the router:
# Configure the IP address of GigabitEthernet 4/1/1, through which the Telnet user accesses the
router.
<Router> system-view
[Router] interface GigabitEthernet 4/1/1
[Router-GigabitEthernet4/1/1] ip address 192.168.1.70 255.255.255.0
[Router-GigabitEthernet4/1/1] quit
# Configure the IP address of GigabitEthernet 4/1/2, through which the router communicates with
the server.
[Router] interface GigabitEthernet 4/1/2
[Router-GigabitEthernet4/1/2] ip address 10.1.1.2 255.255.255.0
[Router-GigabitEthernet4/1/2] quit
# Enable the router to provide Telnet service.
[Router] telnet server enable
# Configure the router to use AAA for Telnet users.
[Router] user-interface vty 0 4
[Router-ui-vty0-4] authentication-mode scheme
[Router-ui-vty0-4] quit
# Specify to use RADIUS authentication for user privilege level switching authentication and, if
RADIUS authentication is not available, use local authentication.
[Router] super authentication-mode scheme local
# Create RADIUS scheme rad.
[Router] radius scheme rad
# Specify the IP address of the primary authentication server as 10.1.1.1, and the port for
authentication as 1812.
[Router-radius-rad] primary authentication 10.1.1.1 1812
# Set the shared key for authentication packets to expert.
[Router-radius-rad] key authentication expert
# Specify the service type of the RADIUS server as standard.
[Router-radius-rad] server-type standard
# Specify that usernames sent to the RADIUS server carry no domain name.
[Router-radius-rad] user-name-format without-domain
[Router-radius-rad] quit
# Create ISP domain bbb.
[Router] domain bbb
# Configure the AAA methods for domain bbb as local authentication.
[Router-isp-bbb] authentication login local
# Configure the domain to use the RADIUS scheme rad for user privilege level switching
authentication.
[Router-isp-bbb] authentication super radius-scheme rad
[Router-isp-bbb] quit
55
# Create a local Telnet user named test.
[Router] local-user test
[Router-luser-test] service-type telnet
[Router-luser-test] password simple aabbcc
# Configure the user level of the Telnet user after login to 0.
[Router-luser-test] authorization-attribute level 0
[Router-luser-test] quit
# Specify to use RADIUS authentication for user privilege level switching authentication and, if
RADIUS authentication is not available, use local authentication.
[Router] super authentication-mode scheme local
# Configure the password for local level switching authentication to 654321.
[Router] super password simple 654321
[Router] quit
2.
Configure the RADIUS server:
Add the username and password for user privilege level switching authentication, as shown
in Table 4.
Table 4 Add username and passwords for user privilege level switching authentication
Username
Password
Switching to level
$enab1$
pass1
1
$enab2$
pass2
2
$enab3$
pass3
3
NOTE:
A username configured on the RADIUS server is in the format of $enablevel$, where level specifies
the privilege level to which the user wants to switch.
56
Figure 16 Configuring the username for privilege level switching (take $enab1$ for example)
Figure 17 List of the usernames for privilege level switching
Verifying the configuration
After the above configuration, the Telnet user should be able to telnet to the router and use
username test@bbb and password aabbcc to enter the user interface of the router, and access all
level 0 commands.
<Router> telnet 192.168.1.70
Trying 192.168.1.70 ...
Press CTRL+K to abort
Connected to 192.168.1.70 ...
******************************************************************************
* Copyright (c) 2010-2012 Hewlett-Packard Development Company, L.P.
*
* Without the owner's prior written consent,
*
57
* no decompiling or reverse-engineering shall be allowed.
*
******************************************************************************
Login authentication
Username:test@bbb
Password:
<Router> ?
User view commands:
cluster
Run cluster command
display
Display current system information
ping
Ping function
quit
Exit from current command view
ssh2
Establish a secure shell client connection
super
Set the current user priority level
telnet
Establish one TELNET connection
tracert
Trace route function
When switching to user privilege level 3, the Telnet user only needs to enter password pass3 as
prompted.
<Router> super 3
Password:
User privilege level is 3, and only those commands can be used
whose level is equal or less than this.
Privilege note: 0-VISIT, 1-MONITOR, 2-SYSTEM, 3-MANAGE
If the RADIUS authentication is not available, the Telnet user needs to enter password 654321 as
prompted for local authentication.
<Router> super 3
Password: Å Enter the password for RADIUS privilege level switch authentication
Error: Invalid configuration or no response from the authentication server.
Info: Change authentication mode to local.
Password: Å Enter the password for local privilege level switch authentication
User privilege level is 3, and only those commands can be used
whose level is equal or less than this.
Privilege note: 0-VISIT, 1-MONITOR, 2-SYSTEM, 3-MANAGE
AAA for portal users by a RADIUS server
Network requirements
As shown in Figure 18, assign the host a public network IP address or configure the host to automatically
obtain an IP address through DHCP. Configure the router to provide direct portal authentication so that
the host can access only the portal server before passing portal authentication and can access the
Internet after passing portal authentication.
Set the shared keys for authentication and authorization exchanges between the router and the RADIUS
server to expert and specify the ports for authentication/authorization as 1812.
Configure the router to include domain names in the usernames sent to the RADIUS server.
58
Figure 18 Network diagram
Configuration procedure
1.
Configure IP addresses for the devices as shown in Figure 18, and make sure the devices can
reach each other. (Details not shown.)
2.
Configure the RADIUS server (on IMC PLAT 5.0):
NOTE:
In this section, the RADIUS server runs on IMC PLAT 5.0 (E0101), and IMC UAM 5.0 (E0101).
# Add the router to the IMC Platform as an access device.
Log in to IMC, click the Service tab, and select User Access Manager > Access Device Management >
Access Device from the navigation tree. Then, click Add to configure an access device as follows:
a. Set the shared key for secure authentication communication to expert.
b. Set the ports for authentication to 1812.
c. Select the service type LAN Access Service.
d. Select the access device type HP(General).
e. Select the access device from the device list or manually add the device with the IP address
10.1.1.2.
f. Leave the default settings for other parameters and click OK.
NOTE:
The IP address of the access device specified here must be the same as the source IP address of the RADIUS
packets sent from the router, which is chosen in this order on the router:
• The IP address specified with the nas-ip command.
• The IP address specified with the radius nas-ip command.
• The IP address of the outbound interface (the default).
59
Figure 19 Adding the router as an access device
# Add a service.
Click the Service tab, and select User Access Manager > Service Configuration from the navigation tree.
Then, click Add to configure a service as follows:
a. Add a service named Portal auth/acct, and set the service suffix to dm1, the authentication
domain for the portal user. With the service suffix configured, you must configure the access
device to send usernames that carry domain names to the RADIUS server.
b. Configure other parameters as required.
c. Click OK.
Figure 20 Adding a service
# Add a user.
Click the User tab, and select Access User View > All Access Users from the navigation tree. Then, click
Add to configure a user as follows:
a. Select the user or add a user named hello.
b. Enter the account name portal and specify the password.
c. Select the access service Portal auth/acct.
d. Configure other parameters as required and click OK.
60
Figure 21 Adding an access user account
3.
Configure the portal server (on IMC PLAT 5.0):
NOTE:
This section assumes that the RADIUS server runs on IMC PLAT 5.0 (E0101) and IMC UAM 5.0 (E0101).
# Configure the portal server.
Log in to IMC and click the Service tab. Then, select User Access Manager > Portal Service Management >
Server from the navigation tree to configure the portal server as follows:
a. Enter the URL address of the portal authentication main page, in the format
http://ip:port/portal, where ip and port are those configured during IMC UAM installation.
Usually, the default port 8080 is used.
b. Leave the default settings for other parameters and click OK.
61
Figure 22 Portal server configuration
# Configure the IP address group.
Select User Access Manager > Portal Service Management > IP Group from the navigation tree to enter
the portal IP address group configuration page. Then, click Add to configure an IP address group as
follows:
a. Enter the name Portal_user.
b. Set the start IP address to 192.168.1.1 and the end IP address to 192.168.1.255. The IP
address of Host must be within this IP address group.
c. Select the action Normal.
d. Click OK.
Figure 23 Adding an IP address group
# Add a portal device.
62
Select User Access Manager > Service Management > Device from the navigation tree to enter the portal
device configuration page. Then, click Add to configure a portal device as follow:
a. Enter the device name NAS.
b. Enter the IP address of the access interface on the device, which is 192.168.1.70.
c. Enter the key, which is portal, the same as that configured on the router.
d. Specify whether to enable IP address reallocation. Because direct portal authentication is used
in this example, select No from the Reallocate IP list.
e. Leave the default settings for other parameters and click OK.
Figure 24 Adding a portal device
# Associate the portal device with the IP address group.
In the device list on the portal device configuration page, click the icon in the Port Group Information
Management column of device NAS to enter the port group configuration page.
Figure 25 Device list
On the port group configuration page, click Add to configure a port group as follows:
63
a. Enter the port group name.
b. Select the configured IP address group. The IP address used by the user to access the network
must be within this IP address group.
c. Leave the default settings for other parameters and click OK.
Figure 26 Port group configuration
# Select User Access Manager > Service Parameters > Validate System Configuration from the
navigation tree to validate the configurations.
4.
Configure the router:
{
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<Router> system-view
[Router] radius scheme rs1
# Set the server type for the RADIUS scheme. When you use IMC, set the server type to
extended.
[Router-radius-rs1] server-type extended
# Specify the primary authentication server, and configure the keys for communication with the
servers.
[Router-radius-rs1] primary authentication 10.1.1.1
[Router-radius-rs1] primary accounting 10.1.1.1
[Router-radius-rs1] key authentication expert
[Router-radius-rs1] key accounting expert
# Specify the scheme to include the domain names in usernames to be sent to the RADIUS
server.
[Router-radius-rs1] user-name-format with-domain
[Router-radius-rs1] quit
{
Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[Router] domain dm1
# Configure the ISP domain to use RADIUS scheme rs1.
64
[Router-isp-dm1] authentication portal radius-scheme rs1
[Router-isp-dm1] authorization portal radius-scheme rs1
[Router-isp-dm1] accounting portal radius-scheme rs1
[Router-isp-dm1] quit
# Configure dm1 as the default ISP domain for all users. Then, if a user enters a username
without any ISP domain at login, the authentication methods of the default domain is used for
the user.
[Router] domain default enable dm1
{
Configure portal authentication
# Configure the portal server.
[Router] portal server newpt ip 10.1.1.1 key portal port 50100 url
http://10.1.1.1:8080/portal
# Enable portal authentication on the interface connecting the host.
[Router] interface GigabitEthernet 3/1/1
[Router–GigabitEthernet3/1/1] portal server newpt method layer3
[Router–GigabitEthernet3/1/1] quit
Verifying the configuration
The user can initiate portal authentication by using iNode client or by accessing a Web page. All the
initiated Web requests are redirected to the portal authentication page at http://10.1.1.1:8080/portal.
Before passing portal authentication, the user can access only the authentication page. After passing
portal authentication, the user can access the Internet.
# After the user passes portal authentication, view the portal user information on the router.
[Router] display portal user interface GigabitEthernet 3/1/1
Index:19
State:ONLINE
SubState:NONE
ACL:NONE
Work-mode:stand-alone
MAC
IP
Vlan
Interface
--------------------------------------------------------------------0015-e9a6-7cfe
192.168.1.58
0
GigabitEthernet 3/1/1
On interface GigabitEthernet 3/1/1:total 1 user(s) matched, 1 listed.
# View the connection information on the router.
[Router] display connection
Index=20
,Username=portal@dm1
IP=192.168.1.58
IPv6=N/A
MAC=00-15-E9-A6-7C-FE
Total 1 connection(s) matched.
65
Troubleshooting AAA
Troubleshooting RADIUS
Symptom 1
User authentication/authorization always fails.
Analysis
1.
A communication failure exists between the NAS and the RADIUS server.
2.
The username is not in the format of userid@isp-name or the ISP domain for the user authentication
is not correctly configured on the NAS.
3.
The user is not configured on the RADIUS server.
4.
The password entered by the user is incorrect.
5.
The RADIUS server and the NAS are configured with different shared key.
Solution
Check that:
1.
The NAS and the RADIUS server can ping each other.
2.
The username is in the userid@isp-name format and the ISP domain for the user authentication is
correctly configured on the NAS.
3.
The user is configured on the RADIUS server.
4.
The correct password is entered.
5.
The same shared key is configured on both the RADIUS server and the NAS.
Symptom 2
RADIUS packets cannot reach the RADIUS server.
Analysis
1.
The NAS and the RADIUS server cannot communicate with each other.
2.
The NAS is not configured with the IP address of the RADIUS server.
3.
The UDP ports for authentication/authorization and accounting are not correct.
4.
The port numbers of the RADIUS server for authentication, authorization and accounting are being
used by other applications.
Solution
Check that:
1.
The communication links between the NAS and the RADIUS server work well at both physical and
link layers.
2.
The IP address of the RADIUS server is correctly configured on the NAS.
3.
UDP ports for authentication/authorization/accounting configured on the NAS are the same as
those configured on the RADIUS server.
4.
The port numbers of the RADIUS server for authentication, authorization and accounting are
available.
66
Symptom 3
A user is authenticated and authorized, but accounting for the user is not normal.
Analysis
1.
The accounting port number is not correct.
2.
Configuration of the authentication/authorization server and the accounting server are not correct
on the NAS. For example, one server is configured on the NAS to provide all the services of
authentication/authorization and accounting, but in fact the services are provided by different
servers.
Solution
Check that:
1.
The accounting port number is correctly set.
2.
The authentication/authorization server and the accounting server are correctly configured on the
NAS.
Troubleshooting HWTACACS
Similar to RADIUS troubleshooting. See "Troubleshooting RADIUS."
67
802.1X overview
802.1X is a port-based network access control protocol initially proposed by the IEEE 802 LAN/WAN
committee for securing wireless LANs (WLANs), and it has also been widely used on Ethernet networks
for access control.
802.1X controls network access by authenticating the devices connected to 802.1X-enabled LAN ports.
802.1X architecture
802.1X operates in the client/server model. It comprises three entities: the client (the supplicant), the
network access device (the authenticator), and the authentication server.
Figure 27 802.1X architecture
•
Client—A user terminal seeking access to the LAN. It must have 802.1X software to authenticate to
the network access device.
•
Network access device—Authenticates the client to control access to the LAN. In a typical 802.1X
environment, the network access device uses an authentication server to perform authentication.
•
Authentication server—Provides authentication services for the network access device. The
authentication server authenticates 802.1X clients by using the data sent from the network access
device, and returns the authentication results to the network access device to make access decisions.
The authentication server is typically a Remote Authentication Dial-in User Service (RADIUS) server.
In a small LAN, you can use the network access device as the authentication server.
Controlled/uncontrolled port and port
authorization status
802.1X defines two logical ports for the network access port: controlled port and uncontrolled port. Any
packet arriving at the network access port is visible to both logical ports.
•
Controlled port—Allows incoming and outgoing traffic to pass through when it is in authorized state,
and denies incoming and outgoing traffic when it is in unauthorized state, as shown in Figure 28.
The controlled port is set in authorized state if the client has passed authentication, and in
unauthorized state, if the client has failed authentication.
•
Uncontrolled port—Is always open to receive and transmit EAPOL frames.
68
Figure 28 Authorization state of a controlled port
In unauthorized state, a controlled port controls traffic in one of the following ways:
•
Performs bidirectional traffic control to deny traffic to and from the client.
•
Performs unidirectional traffic control to deny traffic from the client.
The HP devices support only unidirectional traffic control.
802.1X-related protocols
802.1X uses the Extensible Authentication Protocol (EAP) to transport authentication information for the
client, the network access device, and the authentication server. EAP is an authentication framework that
uses the client/server model. It supports a variety of authentication methods, including MD5-Challenge,
EAP-Transport Layer Security (EAP-TLS), and Protected EAP (PEAP).
802.1X defines EAP over LAN (EAPOL) for passing EAP packets between the client and the network
access device over a wired or wireless LAN. Between the network access device and the authentication
server, 802.1X delivers authentication information in one of the following methods:
•
Encapsulates EAP packets in RADIUS by using EAP over RADIUS (EAPOR), as described in "EAP
relay."
•
Extracts authentication information from the EAP packets and encapsulates the information in
standard RADIUS packets, as described in "EAP termination."
69
Packet formats
EAP packet format
Figure 29 shows the EAP packet format.
Figure 29 EAP packet format
•
Code—Type of the EAP packet. Options include Request (1), Response (2), Success (3), or Failure
(4).
•
Identifier—Used for matching Responses with Requests.
•
Length—Length (in bytes) of the EAP packet, which is the sum of the Code, Identifier, Length, and
Data fields.
•
Data—Content of the EAP packet. This field appears only in a Request or Response EAP packet. The
field comprises the request type (or the response type) and the type data. Type 1 (Identify) and type
4 (MD5-challenge) are two examples for the type field.
EAPOL packet format
Figure 30 shows the EAPOL packet format.
Figure 30 EAPOL packet format
0
15
7
PAE Ethernet type
Protocol version
2
Type
Length
4
6
Packet body
N
•
PAE Ethernet type—Protocol type. It takes the value 0x888E for EAPOL.
•
Protocol version—The EAPOL protocol version used by the EAPOL packet sender.
•
Type—Type of the EAPOL packet. Table 5 lists the types of EAPOL packets that the HP
implementation of 802.1X supports.
Table 5 Types of EAPOL packets
Value
Type
Description
0x00
EAP-Packet
The client and the network access device uses EAP-Packets to transport
authentication information.
0x01
EAPOL-Start
The client sends an EAPOL-Start message to initiate 802.1X
authentication to the network access device.
70
Value
Type
Description
0x02
EAPOL-Logoff
The client sends an EAPOL-Logoff message to tell the network access
device that it is logging off.
•
Length—Data length in bytes, or length of the Packet body. If packet type is EAPOL-Start or
EAPOL-Logoff, this field is set to 0, and no Packet body field follows.
•
Packet body—Content of the packet. When the EAPOL packet type is EAP-Packet, the Packet body
field contains an EAP packet.
EAP over RADIUS
RADIUS adds two attributes, EAP-Message and Message-Authenticator, for supporting EAP
authentication. For the RADIUS packet format, see "Configuring AAA."
EAP-Message
RADIUS encapsulates EAP packets in the EAP-Message attribute, as shown in Figure 31. The Type field
takes 79, and the Value field can be up to 253 bytes. If an EAP packet is longer than 253 bytes, RADIUS
encapsulates it in multiple EAP-Message attributes.
Figure 31 EAP-Message attribute format
Message-Authenticator
RADIUS includes the Message-Authenticator attribute in all packets that have an EAP-Message attribute
to check their integrity. The packet receiver drops the packet if the calculated packet integrity checksum
is different than the Message-Authenticator attribute value. The Message-Authenticator prevents EAP
authentication packets from being tampered with during EAP authentication.
Figure 32 Message-Authenticator attribute format
Initiating 802.1X authentication
Both the 802.1X client and the access device can initiate 802.1X authentication.
802.1X client as the initiator
The client sends an EAPOL-Start packet to the access device to initiate 802.1X authentication. The
destination MAC address of the packet is the IEEE 802.1X specified multicast address
01-80-C2-00-00-03 or the broadcast MAC address. If any intermediate device between the client and
71
the authentication server does not support the multicast address, you must use an 802.1X client, the
iNode 802.1X client for example, that can send broadcast EAPOL-Start packets.
Access device as the initiator
The access device initiates authentication, if a client cannot send EAPOL-Start packets. One example is
the 802.1X client available with Windows XP.
The access device supports the following modes:
•
Multicast trigger mode—The access device multicasts Identity EAP-Request packets periodically
(every 30 seconds by default) to initiate 802.1X authentication.
•
Unicast trigger mode—Upon receiving a frame with the source MAC address not in the MAC
address table, the access device sends an Identity EAP-Request packet out of the receiving port to
the unknown MAC address. It retransmits the packet if no response has been received within a
certain time interval.
802.1X authentication procedures
802.1X provides two authentication methods: EAP relay and EAP termination. You choose either mode
depending on the support of the RADIUS server for EAP packets and EAP authentication methods.
•
EAP relay mode:
EAP relay is defined in IEEE 802.1X. In this mode, the network device uses EAPoR packets to send
authentication information to the RADIUS server, as shown in Figure 33.
Figure 33 EAP relay
In EAP relay mode, the client must use the same authentication method as the RADIUS server. On the
network access device, you only need to execute the dot1x authentication-method eap command to
enable EAP relay.
•
EAP termination mode:
In EAP termination mode, the network access device terminates the EAP packets received from the client,
encapsulates the client authentication information in standard RADIUS packets, and uses (Password
Authentication Protocol) PAP or (Password Authentication Protocol) CHAP to authenticate to the RADIUS
server, as shown in Figure 34.
Figure 34 EAP termination
72
Comparing EAP relay and EAP termination
Packet exchange method
Benefits
Limitations
• Supports various EAP
The RADIUS server must support the
EAP-Message and
Message-Authenticator attributes,
and the EAP authentication method
used by the client.
authentication methods.
EAP relay
• The configuration and processing is
simple on the network access
device.
• Supports only MD5-Challenge
EAP termination
Works with any RADIUS server that
supports PAP or CHAP authentication.
EAP authentication and the
"username + password" EAP
authentication initiated by an
iNode 802.1X client.
• The processing is complex on the
network access device.
EAP relay
Figure 35 shows the basic 802.1X authentication procedure in EAP relay mode, assuming that EAP-MD5
is used.
73
Figure 35 802.1X authentication procedure in EAP relay mode
Client
Device
Authentication server
EAPOR
EAPOL
(1) EAPOL-Start
(2) EAP-Request/Identity
(3) EAP-Response/Identity
(4) RADIUS Access-Request
(EAP-Response/Identity)
(5) RADIUS Access-Challenge
(EAP-Request/MD5 challenge)
(6) EAP-Request/MD5 challenge
(7) EAP-Response/MD5 challenge
(8) RADIUS Access-Request
(EAP-Response/MD5 challenge)
(9) RADIUS Access-Accept
(EAP-Success)
(10) EAP-Success
Port authorized
(11) EAP-Request/Identity
(12) EAP-Response/Identity
...
(13) EAPOL-Logoff
Port unauthorized
(14) EAP-Failure
1.
When a user launches the 802.1X client software and enters a registered username and password,
the 802.1X client software sends an EAPOL-Start packet to the network access device.
2.
The network access device responds with an Identity EAP-Request packet to ask for the client
username.
3.
In response to the Identity EAP-Request packet, the client sends the username in an Identity
EAP-Response packet to the network access device.
4.
The network access device relays the Identity EAP-Response packet in a RADIUS Access-Request
packet to the authentication server.
5.
The authentication server uses the identity information in the RADIUS Access-Request to search its
user database. If a matching entry is found, the server uses a randomly generated challenge
(EAP-Request/MD5 challenge) to encrypt the password in the entry, and sends the challenge in a
RADIUS Access-Challenge packet to the network access device.
6.
The network access device relays the EAP-Request/MD5 Challenge packet in a RADIUS
Access-Request packet to the client.
7.
The client uses the received challenge to encrypt the password, and sends the encrypted password
in an EAP-Response/MD5 Challenge packet to the network access device.
8.
The network access device relays the EAP-Response/MD5 Challenge packet in a RADIUS
Access-Request packet to the authentication server.
74
9.
The authentication server compares the received encrypted password with the one it generated at
step 5. If the two are identical, the authentication server considers the client valid and sends a
RADIUS Access-Accept packet to the network access device.
10. Upon receiving the RADIUS Access-Accept packet, the network access device sends an
EAP-Success packet to the client, and sets the controlled port to the authorized state so the client
can access the network.
11. After the client comes online, the network access device periodically sends handshake requests to
check whether the client is still online. By default, if two consecutive handshake attempts fail, the
device logs off the client.
12. Upon receiving a handshake request, the client returns a response. If the client fails to return a
response after a certain number of consecutive handshake attempts (two by default), the network
access device logs off the client. This handshake mechanism enables timely release of the network
resources used by 802.1X users that have abnormally gone offline.
13. The client can also send an EAPOL-Logoff packet to ask the network access device for a logoff.
14. In response to the EAPOL-Logoff packet, the network access device changes the status of the
controlled port from authorized to unauthorized and sends an EAP-Failure packet to the client.
EAP termination
Figure 36 shows the basic 802.1X authentication procedure in EAP termination mode, assuming that
CHAP authentication is used.
75
Figure 36 802.1X authentication procedure in EAP termination mode
In EAP termination mode, it is the network access device rather than the authentication server generates
an MD5 challenge for password encryption (see Step 4). The network access device then sends the MD5
challenge together with the username and encrypted password in a standard RADIUS packet to the
RADIUS server.
76
Configuring 802.1X
This chapter describes how to configure 802.1X on an HP device.
HP implementation of 802.1X
Access control methods
HP implements port-based access control as defined in the 802.1X protocol, and extends the protocol to
support MAC-based access control.
•
Port-based access control—Once an 802.1X user passes authentication on a port, any subsequent
user can access the network through the port without authentication. When the authenticated user
logs off, all other users are logged off.
•
MAC-based access control—Each user is separately authenticated on a port. When a user logs off,
no other online users are affected.
Using 802.1X authentication with other features
VLAN assignment
You can configure the authentication server to assign a VLAN for an 802.1X user that has passed
authentication. The way that the network access device handles VLANs on an 802.1X-enabled port
differs by 802.1X access control mode.
Access control
VLAN manipulation
Port-based
The device assigns the VLAN to the port as the port VLAN (PVID). The authenticated
802.1X user and all subsequent 802.1X users can access the VLAN without
authentication.
When the user logs off, the previous PVID restores, and all other online users are
logged off.
• If the port is a hybrid port with MAC-based VLAN enabled, the device maps the
MAC address of each user to the VLAN assigned by the authentication server. The
PVID of the port does not change. When a user logs off, the MAC-to-VLAN mapping
for the user is removed.
MAC-based
• If the port is an access, trunk, or MAC-based VLAN disabled hybrid port, the device
assigns the first authenticated user's VLAN to the port as the PVID. If a different
VLAN is assigned to a subsequent user, the user cannot pass the authentication. To
avoid the authentication failure of subsequent users, be sure to assign the same
VLAN to all 802.1X users on these ports.
In 802.1X authentication, a hybrid port is always assigned to a VLAN as an untagged member. After the
assignment, do not re-configure the port as a tagged member in the VLAN.
If a user has been online on a periodic re-authentication enabled port before you enable the MAC-based
VLAN function, the access device does not create a MAC-to-VLAN mapping for the user unless the user
passes re-authentication and the VLAN for the user has changed.
77
For more information about VLAN configuration and MAC-based VLAN, see Layer 2—LAN Switching
Configuration Guide.
Guest VLAN
You can configure a guest VLAN on a port to accommodate users that have not performed 802.1X
authentication, so they can access a limited set of network resources, such as a software server, to
download anti-virus software and system patches. After a user in the guest VLAN passes 802.1X
authentication, it is removed from the guest VLAN and can access authorized network resources. The
way that the network access device handles VLANs on the port differs by 802.1X access control mode.
1.
On a port that performs port-based access control
Authentication status
VLAN manipulation
No 802.1X user has
performed authentication
within 90 seconds after
802.1X is enabled
The device assigns the 802.1X guest VLAN to the port as the PVID. All 802.1X
users on this port can access only resources in the guest VLAN.
A user in the 802.1X guest
VLAN fails 802.1X
authentication
If no 802.1X guest VLAN is configured, the access device does not perform
any VLAN operation.
If an 802.1X Auth-Fail VLAN (see "Auth-Fail VLAN") is available, the device
assigns the Auth-Fail VLAN to the port as the PVID. All users on this port can
access only resources in the Auth-Fail VLAN.
If no Auth-Fail VLAN is configured, the PVID on the port is still the 802.1X
guest VLAN. All users on the port are in the guest VLAN.
• The device assigns the VLAN specified for the user to the port as the PVID
A user in the 802.1X guest
VLAN passes 802.1X
authentication
2.
and removes the port from the 802.1X guest VLAN. After the user logs off,
the user configured PVID restores.
• If the authentication server assigns no VLAN, the user-configured PVID
applies. The user and all subsequent 802.1X users are assigned to the
user-configured port VLAN. After the user logs off, the port VLAN remains
unchanged.
On a port that performs MAC-based access control
Authentication status
VLAN manipulation
A user has not passed
802.1X authentication yet
The device creates a mapping between the MAC address of the user and the
802.1X guest VLAN. The user can access resources in the guest VLAN.
A user in the 802.1X guest
VLAN fails 802.1X
authentication
A user in the 802.1X guest
VLAN passes 802.1X
authentication
If an 802.1X Auth-Fail VLAN is available, the device remaps the MAC address
of the user to the Auth-Fail VLAN. The user can access only resources in the
Auth-Fail VLAN.
If no 802.1X Auth-Fail VLAN is configured, the user is still in the 802.1X guest
VLAN.
The device remaps the MAC address of the user to the VLAN specified for the
user.
If the authentication server assigns no VLAN, the device remaps the MAC address
of the user to the initial PVID on the port.
To use the 802.1X guest VLAN function on a port that performs MAC-based access control, make sure the
port is a hybrid port and enable MAC-based VLAN on the port.
The network device assigns a hybrid port to an 802.1X guest VLAN as an untagged member.
78
For more information about VLAN configuration and MAC-based VLAN, see Layer 2—LAN Switching
Configuration Guide.
Auth-Fail VLAN
You can configure an Auth-Fail VLAN to accommodate users that have failed 802.1X authentication
because of the failure to comply with the organization security strategy, such as using a wrong password.
Users in the Auth-Fail VLAN can access a limited set of network resources, such as a software server, to
download anti-virus software and system patches.
The Auth-Fail VLAN does not accommodate 802.1X users that have failed authentication for
authentication timeouts or network connection problems. The way that the network access device
handles VLANs on the port differs by 802.1X access control mode.
1.
On a port that performs port-based access control
Authentication status
VLAN manipulation
A user fails 802.1X
authentication
The device assigns the Auth-Fail VLAN to the port as the PVID. All 802.1X
users on this port can access only resources in the Auth-Fail VLAN.
A user in the Auth-Fail VLAN
fails 802.1X re-authentication
The Auth-Fail VLAN is still the PVID on the port, and all 802.1X users on this
port are in this VLAN.
• The device assigns the VLAN specified for the user to the port as the PVID
A user passes 802.1X
authentication
and removes the port from the Auth-Fail VLAN. After the user logs off, the
user-configured PVID restores.
• If the authentication server assigns no VLAN, the initial PVID applies. The
user and all subsequent 802.1X users are assigned to the user-configured
PVID. After the user logs off, the PVID remains unchanged.
2.
On a port that performs MAC-based access control
Authentication status
VLAN manipulation
A user fails 802.1X
authentication
The device remaps the MAC address of the user to the Auth-Fail VLAN. The
user can access only resources in the Auth-Fail VLAN.
A user in the Auth-Fail VLAN
fails 802.1X re-authentication
The user is still in the Auth-Fail VLAN.
A user in the Auth-Fail VLAN
passes 802.1X authentication
The device remaps the MAC address of the user to the server-assigned VLAN.
If the authentication server assigns no VLAN, the device remaps the MAC
address of the user to the initial PVID on the port.
To perform the 802.1X Auth-Fail VLAN function on a port that performs MAC-based access control, you
must make sure the port is a hybrid port and enable MAC-based VLAN on the port.
The network device assigns a hybrid port to an 802.1X Auth-Fail VLAN as an untagged member.
For more information about VLAN configuration and MAC-based VLAN, see Layer 2—LAN Switching
Configuration Guide.
Critical VLAN
You configure an 802.1X critical VLAN on a port to accommodate 802.1X users that fail authentication
because none of the RADIUS authentication servers in their ISP domain is reachable (active). Users in the
critical VLAN can access a limit set of network resources depending on your configuration.
79
The critical VLAN feature takes effect when 802.1X authentication is performed only through RADIUS
servers. If an 802.1X user fails local authentication after RADIUS authentication, the user is not assigned
to the critical VLAN. For more information about RADIUS configuration, see "Configuring AAA."
The way that the network access device handles VLANs on an 802.1X-enabled port differs by 802.1X
access control mode.
1.
On a port that performs port-based access control
Authentication status
VLAN manipulation
A user that has not been assigned to
any VLAN fails 802.1X authentication
because all the RADIUS servers are
unreachable.
The device assigns the critical VLAN to the port as the PVID. The
802.1X user and all subsequent 802.1X users on this port can access
only resources in the critical VLAN.
A user in the 802.1X critical VLAN fails
authentication because all the RADIUS
servers are unreachable.
The critical VLAN is still the PVID of the port, and all 802.1X users on
this port are in this VLAN.
A user in the 802.1X critical VLAN fails
authentication for any other reason
than server unreachable.
If an Auth-Fail VLAN has been configured, the PVID of the port
changes to Auth-Fail VLAN ID, and all 802.1X users on this port are
moved to the Auth-Fail VLAN.
• The device assigns the VLAN specified for the user to the port as
the PVID and removes the port from the critical VLAN. After the
user logs off, the default or user-configured PVID restores.
A user in the critical VLAN passes
802.1X authentication.
• If the authentication server assigns no VLAN, the default or
A user in the 802.1X guest VLAN or the
Auth-Fail VLAN fails authentication
because all the RADIUS servers is
reachable.
The PVID of the port remains unchanged. All 802.1X users on this
port can access only resources in the guest VLAN or the Auth-Fail
VLAN.
2.
user-configured PVID applies. The user and all subsequent 802.1X
users are assigned to this port VLAN. After the user logs off, this
PVID remains unchanged.
On a port that performs MAC-based access control
Authentication status
VLAN manipulation
A user that has not been assigned to any VLAN fails
802.1X authentication because all the RADIUS
servers are unreachable.
The device maps the MAC address of the user to the
critical VLAN. The user can access only resources in the
critical VLAN.
A user in the 802.1X critical VLAN fails
authentication because all the RADIUS servers are
unreachable.
The user is still in the critical VLAN.
A user in the critical VLAN fails 802.1X
authentication for any other reason than server
unreachable.
If an Auth-Fail VLAN has been configured, the device
remaps the MAC address of the user to the Auth-Fail
VLAN ID.
80
Authentication status
VLAN manipulation
the device remaps the MAC address of the user to the
server-assigned VLAN.
A user in the critical VLAN passes 802.1X
authentication.
If the authentication server assigns no VLAN, the device
remaps the MAC address of the user to the default or
user-configured PVID on the port.
A user in the 802.1X guest VLAN or the Auth-Fail
VLAN fails authentication because all the RADIUS
server are unreachable.
The user remains in the 802.1X VLAN or the Auth-Fail
VLAN.
A user in the MAC authentication guest VLAN fails
802.1X authentication because all the 802.1X
authentication server are unreachable.
The user is removed from the MAC authentication VLAN
and mapped to the 802.1X critical VLAN.
To perform the 802.1X critical VLAN function on a port that performs MAC-based access control, you
must make sure the port is a hybrid port and enable MAC-based VLAN on the port.
The network device assigns a hybrid port to an 802.1X critical VLAN as an untagged member.
For more information about VLAN configuration and MAC-based VLAN, see Layer 2—LAN Switching
Configuration Guide.
Any of the following RADIUS authentication server changes in the ISP domain for 802.1X users on a port
can cause the users to be removed from the critical VLAN:
•
An authentication server is reconfigured, added, or removed.
•
The status of any RADIUS authentication server automatically changes to active or is
administratively set to active.
•
The RADIUS server probing function detects that a RADIUS authentication server is reachable and
sets its state to active.
You can use the dot1x critical recovery-action reinitialize command to configure the port to trigger
802.1X re-authentication when the port or an 802.1X user on the port is removed from the critical VLAN.
•
If MAC-based access control is used, the port sends a unicast Identity EAP/Request to the 802.1X
user to trigger authentication.
•
If port-based access control is used, the port sends a multicast Identity EAP/Request to the 802.1X
users to trigger authentication.
COPS
You can use a Common Open Policy Service (COPS) server to authorize 802.1X user. COPS is a
service-oriented network management protocol. It can perform policy-based admission control for a
variety of network applications.
With COPS, the network access device acts as a policy enforcement point (PEP) to establish a COPS
connection with the remote policy server, the policy decision point (PDP), and requests the remote policy
server to authorize 802.1X users, for example, assign VLANs or ACLs to 802.1X users. The remote policy
server, after receiving the request, returns the authorization information to the access device.
For more information about COPS and its applications, see "Configuring COPS."
81
Configuration prerequisites
•
Configure an ISP domain and AAA scheme (local or RADIUS authentication) for 802.1X users.
•
If RADIUS authentication is used, create user accounts on the RADIUS server.
•
If local authentication is used, create local user accounts on the access device and set the service
type to lan-access.
802.1X configuration task list
Task
Remarks
Enabling 802.1X
Required.
Enabling EAP relay or EAP termination
Optional.
Setting the port authorization state
Optional.
Specifying an access control method
Optional.
Setting the maximum number of concurrent 802.1X users on a port
Optional.
Setting the maximum number of authentication request attempts
Optional.
Setting the 802.1X authentication timeout timers
Optional.
Configuring the online user handshake function
Optional.
Enabling the proxy detection function
Optional.
Configuring the authentication trigger function
Optional.
Specifying a mandatory authentication domain on a port
Optional.
Configuring the quiet timer
Optional.
Enabling the periodic online user re-authentication function
Optional.
Configuring an 802.1X guest VLAN
Optional.
Configuring an Auth-Fail VLAN
Optional.
Configuring an 802.1X critical VLAN
Optional.
Specifying supported domain name delimiters
Optional.
Specify a COPS scheme for 802.1X.
Optional.
Enabling 802.1X
Configuration guidelines
•
802.1X is mutually exclusive with link aggregation and service loopback group configuration on a
port.
•
On an 802.1X and MAC authentication enabled port, the EAP packet from an unknown MAC
address immediately triggers 802.1X authentication, and any other type of packet from an
unknown MAC address triggers MAC authentication 30 seconds after its arrival.
82
Configuration procedure
To enable 802.1X:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable 802.1X globally.
dot1x
By default, 802.1X is disabled
globally.
• In system view:
Enable 802.1X on a port in
system or Layer 2 Ethernet
interface view.
3.
dot1x interface interface-list
• In Layer 2 Ethernet interface view:
a. interface interface-type
interface-number
By default, 802.1X is disabled
on a port.
b. dot1x
Enabling EAP relay or EAP termination
When you configure EAP relay or EAP termination, consider the following factors:
•
The support of the RADIUS server for EAP packets
•
The authentication methods supported by the 802.1X client and the RADIUS server
If the client is using only MD5-Challenge EAP authentication or the "username + password" EAP
authentication initiated by an iNode 802.1X client, you can use both EAP termination and EAP relay. To
use EAP-TL, PEAP, or any other EAP authentication methods, you must use EAP relay. When you make
your decision, see "Comparing EAP relay and EAP termination" for help.
For more information about EAP relay and EAP termination, see "802.1X authentication procedures."
To configure EAP relay or EAP termination:
Step
1.
2.
Enter system
view.
Configure EAP
relay or EAP
termination.
Command
Remarks
system-view
N/A
dot1x authentication-method
{ chap | eap | pap }
By default, the network access device performs EAP
termination and uses CHAP to communicate with the
RADIUS server.
Specify the eap keyword to enable EAP termination.
Specify the chap or pap keyword to enable
CHAP-enabled or PAP-enabled EAP relay.
NOTE:
If EAP relay mode is used, the user-name-format command configured in RADIUS scheme view does not
take effect. The access device sends the authentication data from the client to the server without any
modification. For more information about the user-name-format command, see Security Command
Reference.
83
Setting the port authorization state
The port authorization state determines whether the client is granted access to the network. You can
control the authorization state of a port by using the dot1x port-control command and the following
keywords:
•
authorized-force—Places the port in authorized state, enabling users on the port to access the
network without authentication.
•
unauthorized-force—Places the port in unauthorized state, denying any access requests from users
on the port.
•
auto—Places the port initially in unauthorized state to allow only EAPOL packets to pass, and after
a user passes authentication, sets the port in authorized state to allow access to the network. You
can use this option in most scenarios.
You can set authorization state for one port in interface view, or for multiple ports in system view. If
different authorization state is set for a port in system view and interface view, the one set later takes
effect.
To set the authorization state of a port:
Step
1.
Enter system
view.
2.
Set the port
authorization
state in system or
Layer 2 Ethernet
interface view.
Command
Remarks
system-view
N/A
• In system view:
dot1x port-control { authorized-force | auto |
unauthorized-force } [ interface interface-list ]
• In Layer 2 Ethernet interface view:
By default, auto applies.
a. interface interface-type interface-number
b. dot1x port-control { authorized-force | auto |
unauthorized-force }
Specifying an access control method
You can specify an access control method for one port in interface view, or for multiple ports in system
view. If different access control methods are specified for a port in system view and interface view, the
one specified later takes effect.
To specify the access control method:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• In system view:
2.
Specify an access control
method in system or Layer 2
Ethernet interface view.
dot1x port-method { macbased |
portbased } [ interface interface-list ]
• In Layer 2 Ethernet interface view:
a. interface interface-type
interface-number
b. dot1x port-method { macbased |
portbased }
84
By default,
MAC-based access
control applies.
NOTE:
To use both 802.1X and portal authentication on a port, you must specify MAC-based access control. For
information about portal authentication, see "Configuring portal authentication."
Setting the maximum number of concurrent 802.1X
users on a port
You can set the maximum number of concurrent 802.1X users for ports individually in interface view or in
bulk in system view. If different settings are configured for a port in both views, the setting configured later
takes effect.
To set the maximum number of concurrent 802.1X users on a port:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• In system view:
2.
Set the maximum number of
concurrent 802.1X users on a
port in system or Layer 2
Ethernet interface view.
dot1x max-user user-number [ interface
interface-list ]
• In Layer 2 Ethernet interface view:
a. interface interface-type
interface-number
By default, the maximum
number of concurrent
users on a port is 1024.
b. dot1x max-user user-number
[ interface interface-list ]
Setting the maximum number of authentication
request attempts
The network access device retransmits an authentication request if it receives no response to the request
it has sent to the client within a period of time (specified by using the dot1x timer tx-period
tx-period-value command or the dot1x timer supp-timeout supp-timeout-value command). The network
access device stops retransmitting the request, if it has made the maximum number of request
transmission attempts but still received no response.
To set the maximum number of authentication request attempts:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the maximum number of attempts for
sending an authentication request.
dot1x retry max-retry-value
The default setting is
2.
Setting the 802.1X authentication timeout timers
The network device uses the following 802.1X authentication timeout timers:
85
•
Client timeout timer—Starts when the access device sends an EAP-Request/MD5 Challenge packet
to a client. If no response is received when this timer expires, the access device retransmits the
request to the client.
•
Server timeout timer—Starts when the access device sends a RADIUS Access-Request packet to the
authentication server. If no response is received when this timer expires, the access device
retransmits the request to the server.
You can set the client timeout timer to a high value in a low-performance network, and adjust the server
timeout timer to adapt to the performance of different authentication servers. In most cases, the default
settings are sufficient.
To set the 802.1X authentication timeout timers:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the client timeout
timer.
dot1x timer supp-timeout
supp-timeout-value
The default is 30 seconds.
3.
Set the server timeout
timer.
dot1x timer server-timeout
server-timeout-value
The default is 100 seconds.
Configuring the online user handshake function
The online user handshake function checks the connectivity status of online 802.1X users. The network
access device sends handshake messages to online users at the interval specified by the dot1x timer
handshake-period command. If no response is received from an online user after the maximum number
of handshake attempts (set by the dot1x retry command) has been made, the network access device sets
the user in offline state.
If iNode clients are deployed, you can also enable the online handshake security function to check for
802.1X users that use illegal client software to bypass security inspection such as proxy detection and
dual network interface cards (NICs) detection. This function checks the authentication information in
client handshake messages. If a user fails the authentication, the network access device logs the user off.
Configuration guidelines
Follow these guidelines when you configure the online user handshake function:
•
If the network has 802.1X clients that cannot exchange handshake packets with the network access
device, disable the online user handshake function to prevent their connections from being
inappropriately torn down.
•
You must disable proxy detection before disabling the online user handshake function.
Configuration procedure
To configure the online user handshake function:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
86
Step
Command
Remarks
Optional.
2.
Set the handshake timer.
dot1x timer handshake-period
handshake-period-value
3.
Enter Layer 2 Ethernet
interface view.
interface interface-type
interface-number
4.
Enable the online handshake
function.
dot1x handshake
Enable the online handshake
security function.
dot1x handshake secure
5.
The default is 15 seconds.
N/A
Optional.
By default, the function is enabled.
Optional.
By default, the function is disabled.
Enabling the proxy detection function
The proxy detection function prevents users from using an authenticated 802.1X client as a network
access proxy to bypass monitoring and accounting. When a user is detected accessing the network
through a proxy, the network access device can send traps to the network management system or log the
user off by sending an offline message.
Prerequisites
•
Enable the online user handshake function (see "Configuring the online user handshake function").
•
Deploy iNode client software in your network.
Configuration procedure
To configure the proxy detection function:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the proxy detection
function globally.
dot1x supp-proxy-check { logoff | trap }
By default, the
function is disabled.
• In system view:
3.
Enable the proxy detection
function on one or more ports
in system or Layer 2 Ethernet
interface view.
dot1x supp-proxy-check { logoff | trap }
interface interface-list
• In Layer 2 Ethernet interface view:
a. interface interface-type
interface-number
By default, the
function is disabled.
b. dot1x supp-proxy-check { logoff |
trap }
NOTE:
If you configure the proxy detection function for a port in both system view and interface view, the setting
configured the last takes effect.
87
Configuring the authentication trigger function
The authentication trigger function enables the network access device to initiate 802.1X authentication
when 802.1X clients cannot initiate authentication.
This function provides the following types of authentication trigger:
•
Multicast trigger—Periodically multicasts Identity EAP-Request packets out of a port to detect 802.1X
clients and trigger authentication.
•
Unicast trigger—Enables the network device to initiate 802.1X authentication when it receives a
data frame from an unknown source MAC address. The device sends a unicast Identity
EAP/Request packet to the unknown source MAC address, and retransmits the packet if it has
received no response within a period of time. This process continues until the maximum number of
request attempts set with the dot1x retry command (see "Setting the maximum number of
authentication request attempts") is reached.
The identity request timeout timer sets both the identity request interval for the multicast trigger and the
identity request timeout interval for the unicast trigger.
Configuration guidelines
Follow these guidelines when you configure the authentication trigger function:
•
Enable the multicast trigger on a port when the clients attached to the port cannot send EAPOL-Start
packets to initiate 802.1X authentication.
•
Enable the unicast trigger on a port if only a few 802.1X clients are attached to the port and these
clients cannot initiate authentication.
•
To avoid duplicate authentication packets, do not enable both triggers on a port.
Configuration procedure
To configure the authentication trigger function on a port:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the username
request timeout timer.
dot1x timer tx-period
tx-period-value
Optional.
3.
Enter Layer 2 Ethernet
interface view.
interface interface-type
interface-number
4.
Enable an
authentication trigger.
dot1x { multicast-trigger |
unicast-trigger }
88
The default is 30 seconds.
N/A
Required if you want to enable the unicast trigger.
By default, the multicast trigger is enabled, and the
unicast trigger is disabled.
Specifying a mandatory authentication domain on
a port
You can place all 802.1X users in a mandatory authentication domain for authentication, authorization,
and accounting on a port. No user can use an account in any other domain to access the network
through the port. The implementation of a mandatory authentication domain enhances the flexibility of
802.1X access control deployment.
To specify a mandatory authentication domain for a port:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter Layer 2 Ethernet
interface view.
interface interface-type
interface-number
N/A
3.
Specify a mandatory 802.1X
authentication domain on the
port.
dot1x mandatory-domain
domain-name
By default, no mandatory 802.1X
authentication domain is specified.
Configuring the quiet timer
The quiet timer enables the network access device to wait a period of time before it can process any
authentication request from a client that has failed an 802.1X authentication.
You can set the quiet timer to a high value in a vulnerable network or a low value for quicker
authentication response.
To configure the quiet timer:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the quiet timer.
dot1x quiet-period
By default, the timer is disabled.
3.
Set the quiet timer.
dot1x timer quiet-period
quiet-period-value
Optional.
The default is 60 seconds.
Enabling the periodic online user re-authentication
function
Periodic online user re-authentication tracks the connection status of online users and updates the
authorization attributes assigned by the server, such as the VLAN. The re-authentication interval is user
configurable.
To enable the periodic online user re-authentication function:
89
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the periodic
re-authentication timer.
dot1x timer reauth-period
reauth-period-value
Optional.
3.
Enter Layer 2 Ethernet
interface view.
interface interface-type
interface-number
N/A
4.
Enable periodic online user
re-authentication.
dot1x re-authenticate
By default, the function is disabled.
The default is 3600 seconds.
The periodic online user re-authentication timer can also be set by the authentication server in the
session-timeout attribute. The server-assigned timer overrides the timer setting on the access device, and
enables periodic online user re-authentication, even if the function is not configured. Support for the
server assignment of re-authentication timer and the re-authentication timer configuration on the server
vary with servers.
NOTE:
• The VLAN assignment status must be consistent before and after re-authentication. If the authentication
server has assigned a VLAN before re-authentication, it must also assign a VLAN at re-authentication.
If the authentication server has assigned no VLAN before re-authentication, it must not assign one at
re-authentication. Violation of either rule can cause the user to be logged off. The VLANs assigned to an
online user before and after re-authentication can be the same or different.
• If no critical VLAN is configured, RADIUS server unreachable can cause an online user being
re-authenticated to be logged off. If a critical VLAN is configured, the user remains online and in the
original VLAN.
Configuring an 802.1X guest VLAN
Configuration guidelines
Follow these guidelines when you configure an 802.1X guest VLAN:
•
You can configure only one 802.1X guest VLAN on a port. The 802.1X guest VLANs on different
ports can be different.
•
Assign different IDs to the port VLAN, and the 802.1X guest VLAN on a port, so the port can
correctly process incoming VLAN tagged traffic.
•
Use Table 6 when configuring multiple security features on a port.
Table 6 Relationships of the 802.1X guest VLAN and other security features
Feature
Relationship description
Reference
MAC authentication guest
VLAN on a port that
performs MAC-based
access control
Only the 802.1X guest VLAN take effect. A user
that fails MAC authentication will not be assigned
to the MAC authentication guest VLAN.
See "Configuring MAC
authentication."
802.1X Auth-Fail VLAN on
a port that performs
MAC-based access control
The 802.1X Auth-Fail VLAN has a higher priority.
See "Using 802.1X
authentication with other
features."
90
Configuration prerequisites
•
Create the VLAN to be specified as the 802.1X guest VLAN.
•
If the 802.1X-enabled port performs port-based access control, enable 802.1X multicast trigger.
•
If the 802.1X-enabled port performs MAC-based access control, configure the port as a hybrid port,
enable MAC-based VLAN on the port, and assign the port to the 802.1X guest VLAN as an
untagged member. For more information about the MAC-based VLAN function, see Layer 2—LAN
Switching Configuration Guide.
Configuration procedure
To configure an 802.1X guest VLAN:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• In system view:
2.
Configure an 802.1X guest
VLAN for one or more ports in
system or Layer 2 Ethernet
interface view.
dot1x guest-vlan guest-vlan-id
[ interface interface-list ]
• In Layer 2 Ethernet interface view:
a. interface interface-type
interface-number
By default, no 802.1X guest
VLAN is configured on any
port.
b. dot1x guest-vlan guest-vlan-id
Configuring an Auth-Fail VLAN
Configuration guidelines
Follow these guidelines when configuring an 802.1X Auth-Fail VLAN:
•
Assign different IDs to the port VLAN, and the 802.1X Auth-Fail VLAN on a port, so the port can
correctly process VLAN tagged incoming traffic.
•
You can configure only one 802.1X Auth-Fail VLAN on a port. The 802.1X Auth-Fail VLANs on
different ports can be different.
•
The 802.1X Auth-Fail VLAN takes precedence over MAC authentication guest VLAN on a port that
performs MAC-based access control. For more information, see "Configuring MAC
authentication."
Configuration prerequisites
•
Create the VLAN to be specified as the 802.1X Auth-Fail VLAN.
•
If the 802.1X-enabled port performs port-based access control, enable 802.1X multicast trigger.
•
If the 802.1X-enabled port performs MAC-based access control, configure the port as a hybrid port,
enable MAC-based VLAN on the port, and assign the port to the Auth-Fail VLAN as an untagged
91
member. For more information about the MAC-based VLAN function, see Layer 2—LAN Switching
Configuration Guide.
Configuration procedure
To configure an Auth-Fail VLAN:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter Layer 2 Ethernet
interface view.
interface interface-type
interface-number
N/A
3.
Configure the Auth-Fail
VLAN on the port.
dot1x auth-fail vlan
authfail-vlan-id
By default, no Auth-Fail VLAN is configured.
Configuring an 802.1X critical VLAN
Configuration guidelines
•
Assign different IDs to the port VLAN, and the 802.1X critical VLAN on a port, so the port can
correctly process VLAN tagged incoming traffic.
•
You can configure only one 802.1X critical VLAN on a port. The 802.1X critical VLANs on different
ports can be different.
Configuration prerequisites
•
Create the VLAN to be specified as a critical VLAN.
•
If the 802.1X-enabled port performs port-based access control, enable 802.1X multicast trigger
(dot1x multicast-trigger).
•
If the 802.1X-enabled port performs MAC-based access control, configure the port as a hybrid port,
enable MAC-based VLAN on the port, and assign the port to the Auth-Fail VLAN as an untagged
member. For more information about the MAC-based VLAN function, see Layer 2—LAN Switching
Configuration Guide.
Configuration procedure
To configure an 802.1X critical VLAN:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter Layer 2 Ethernet
interface view.
interface interface-type
interface-number
N/A
3.
Configure an 802.1X critical
VLAN on the port.
dot1x critical vlan vlan-id
By default, no critical VLAN is
configured.
92
Step
Command
Configure the port to trigger
802.1X authentication on
detection of a reachable
authentication server for users
in the critical VLAN.
4.
Remarks
Optional.
dot1x critical recovery-action
reinitialize
By default, when a reachable
RADIUS server is detected, the
system removes the port or 802.1X
users from the critical VLAN
without triggering authentication.
Specifying supported domain name delimiters
By default, the access device supports the at sign (@) as the delimiter. You can also configure the access
device to accommodate 802.1X users that use other domain name delimiters.
The configurable delimiters include the at sign (@), back slash (\), and forward slash (/).
If an 802.1X username string contains multiple configured delimiters, the leftmost delimiter is the domain
name delimiter. For example, if you configure @, /, and \ as delimiters, the domain name delimiter for
the username string 123/22\@abc is the forward slash (/).
If a username string contains none of the delimiters, the access device authenticates the user in the
mandatory or default ISP domain. The access selects a domain delimiter from the delimiter set in this
order: @, /, and \.
To specify a set of domain name delimiters:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify a set of domain name
delimiters for 802.1X users.
dot1x domain-delimiter string
By default, only the at sign (@)
delimiter is supported.
NOTE:
If you configure the access device to include the domain name in the username sent to the RADIUS server,
make sure the domain delimiter in the username can be recognized by the RADIUS server. For username
format configuration, see the user-name-format command in Security Command Reference.
Referencing a COPS scheme
You can apply a COPS scheme to 802.1X, so after a user passes 802.1X authentication, the access
device can request the policy server to assign authorization information, for example, a VLAN or ACL, to
the user.
Before you reference a COPS scheme, complete the following tasks:
•
Configure the PEP ID of the device.
•
Create and configure the COPS scheme to be referenced.
For more information about COPS configuration, see "Configuring COPS."
To reference the COPS scheme:
93
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify a COPS scheme for
802.1X.
dot1x cops cops-scheme-name
By default, 802.1X references no
COPS scheme.
Displaying and maintaining 802.1X
Task
Command
Remarks
Display 802.1X session
information, statistics, or
configuration information of
specified or all ports.
display dot1x [ sessions | statistics ] [ interface
interface-list ] [ | { begin | exclude | include }
regular-expression ]
Available in any view.
Clear 802.1X statistics.
reset dot1x statistics [ interface interface-list ]
Available in user view.
802.1X authentication configuration example
Network requirements
As shown in Figure 37, the access device performs 802.1X authentication for users that connect to port
GigabitEthernet 2/1/1. Implement MAC-based access control on the port, so the logoff of one user does
not affect other online 802.1X users.
Use RADIUS servers to perform authentication, authorization, and accounting for the 802.1X users. If
RADIUS authentication fails, perform local authentication on the access device. If RADIUS accounting
fails, the access device logs the user off.
Configure the host at 10.1.1.1/24 as the primary authentication and accounting servers, and the host at
10.1.1.2/24 as the secondary authentication and accounting servers. Assign all users to the ISP domain
aabbcc.net, which accommodates up to 30 users.
Configure the shared key as name for packets between the access device and the authentication server,
and the shared key as money for packets between the access device and the accounting server.
Figure 37 Network diagram
94
Configuration procedure
NOTE:
For information about the RADIUS commands used on the access device in this example, see Security
Command Reference.
1.
Configure the 802.1X client. If iNode is used, do not select the Carry version info option in the
client configuration. (Details not shown.)
2.
Configure the RADIUS servers and add user accounts for the 802.1X users. (Details not shown.)
3.
Assign an IP address to each interface on the access device. (Details not shown.)
4.
Configure user accounts for the 802.1X users on the access device:
# Add a local user with the username localuser, and password localpass in plaintext. (Make sure
the username and password are the same as those configured on the RADIUS server.)
<Device> system-view
[Device] local-user localuser
[Device-luser-localuser] service-type lan-access
[Device-luser-localuser] password simple localpass
# Configure the idle cut function to log off any online user that has been idled for 20 minutes.
[Device-luser-localuser] authorization-attribute idle-cut 20
[Device-luser-localuser] quit
5.
Configure a RADIUS scheme:
# Create the RADIUS scheme radius1 and enter its view.
[Device] radius scheme radius1
# Specify the IP addresses of the primary authentication and accounting RADIUS servers.
[Device-radius-radius1] primary authentication 10.1.1.1
[Device-radius-radius1] primary accounting 10.1.1.1
# Configure the IP addresses of the secondary authentication and accounting RADIUS servers.
[Device-radius-radius1] secondary authentication 10.1.1.2
[Device-radius-radius1] secondary accounting 10.1.1.2
# Specify the shared key between the access device and the authentication server.
[Device-radius-radius1] key authentication name
# Specify the shared key between the access device and the accounting server.
[Device-radius-radius1] key accounting money
# Exclude the ISP domain name from the username sent to the RADIUS servers.
[Device-radius-radius1] user-name-format without-domain
[Device-radius-radius1] quit
NOTE:
The access device must use the same username format as the RADIUS server. If the RADIUS server includes
the ISP domain name in the username, so must the access device.
6.
Configure the ISP domain:
# Create the ISP domain aabbcc.net and enter its view.
[Device] domain aabbcc.net
95
# Apply the RADIUS scheme radius1 to the ISP domain, and specify local authentication as the
secondary authentication method.
[Device-isp-aabbcc.net] authentication lan-access radius-scheme radius1 local
[Device-isp-aabbcc.net] authorization lan-access radius-scheme radius1 local
[Device-isp-aabbcc.net] accounting lan-access radius-scheme radius1 local
# Set the maximum number of concurrent users in the domain to 30.
[Device-isp-aabbcc.net] access-limit enable 30
# Configure the idle cut function to log off any online domain user that has been idle for 20
minutes.
[Device-isp-aabbcc.net] idle-cut enable 20
[Device-isp-aabbcc.net] quit
# Specify aabbcc.net as the default ISP domain. If a user does not provide any ISP domain name,
it is assigned to the default ISP domain.
[Device] domain default enable aabbcc.net
7.
Configure 802.1X:
# Enable 802.1X globally.
[Device] dot1x
# Enable 802.1X on GigabitEthernet 2/1/1.
[Device] interface GigabitEthernet 2/1/1
[Device-GigabitEthernet2/1/1] dot1x
[Device-GigabitEthernet2/1/1] quit
# Enable MAC-based access control on the port. (Optional. MAC-based access control is the
default setting.)
[Device] dot1x port-method macbased interface GigabitEthernet 2/1/1
Verifying the configuration
Use the display dot1x interface GigabitEthernet 2/1/1 command to verify the 802.1X configuration.
After an 802.1X user passes RADIUS authentication, you can use the display connection command to
view the user connection information. If the user fails RADIUS authentication, local authentication is
performed.
802.1X guest VLAN and VLAN assignment
configuration example
Network requirements
See Figure 38:
•
A host is connected to port GigabitEthernet 2/1/2 of the device and must pass 802.1X
authentication to access the Internet. GigabitEthernet 2/1/2 is in VLAN 1.
•
GigabitEthernet 2/1/2 implements port-based access control.
•
GigabitEthernet 2/1/3 is in VLAN 5 and is for accessing the Internet.
•
The authentication server runs RADIUS and is in VLAN 2.
96
•
The update server in VLAN 10 is for client software download and upgrade.
If no user performs 802.1X authentication on GigabitEthernet 2/1/2 within a period of time, the device
adds GigabitEthernet 2/1/2 to its guest VLAN, VLAN 10. The host and the update server are both in
VLAN 10 and the host can access the update server and download the 802.1X client software.
After the host passes 802.1X authentication, the network access device assigns the host to VLAN 5 where
GigabitEthernet 2/1/3 is. The host can access the Internet.
Figure 38 Network diagram
Configuration procedure
NOTE:
The following configuration procedure covers most AAA/RADIUS configuration commands on the device.
The configuration on the 802.1X client and RADIUS server are not shown. For more information about
AAA/RADIUS configuration commands, see Security Command Reference.
1.
Make sure the 802.1X client can update its IP address after the access port is assigned to the guest
VLAN or a server-assigned VLAN. (Details not shown.)
2.
Configure the RADIUS server to provide authentication, authorization, and accounting services.
Configure user accounts and server-assigned VLAN, VLAN 5 in this example. (Details not shown.)
3.
Create VLANs, and assign ports to the VLANs:
<Device> system-view
[Device] vlan 1
[Device-vlan1] port GigabitEthernet 2/1/2
[Device-vlan1] quit
97
[Device] vlan 10
[Device-vlan10] port GigabitEthernet 2/1/1
[Device-vlan10] quit
[Device] vlan 2
[Device-vlan2] port GigabitEthernet 2/1/4
[Device-vlan2] quit
[Device] vlan 5
[Device-vlan5] port GigabitEthernet 2/1/3
[Device-vlan5] quit
4.
Configure a RADIUS scheme:
# Configure RADIUS scheme 2000 and enter its view.
<Device> system-view
[Device] radius scheme 2000
# Specify primary and secondary authentication and accounting servers. Set the shared key to abc
for authentication and accounting packets.
[Device-radius-2000] primary authentication 10.11.1.1 1812
[Device-radius-2000] primary accounting 10.11.1.1 1813
[Device-radius-2000] key authentication abc
[Device-radius-2000] key accounting abc
# Exclude the ISP domain name from the username sent to the RADIUS server.
[Device-radius-2000] user-name-format without-domain
[Device-radius-2000] quit
5.
Configure an ISP domain:
# Create ISP domain bbb and enter its view.
[Device] domaim bbb
# Apply RADIUS scheme 2000 to the ISP domain for authentication, authorization, and
accounting.
[Device-isp-bbb] authentication lan-access radius-scheme 2000
[Device-isp-bbb] authorization lan-access radius-scheme 2000
[Device-isp-bbb] accounting lan-access radius-scheme 2000
[Device-isp-bbb] quit
6.
Configure 802.1X:
# Enable 802.1X globally.
[Device] dot1x
# Enable 802.1X for port GigabitEthernet 2/1/2.
[Device] interface GigabitEthernet 2/1/2
[Device-GigabitEthernet2/1/2] dot1x
# Implement port-based access control on the port.
[Device-GigabitEthernet2/1/2] dot1x port-method portbased
# Set the port authorization mode to auto. This step is optional. By default, the port is in auto mode.
[Device-GigabitEthernet2/1/2] dot1x port-control auto
[Device-GigabitEthernet2/1/2] quit
# Set VLAN 10 as the 802.1X guest VLAN for port GigabitEthernet 2/1/2.
[Device] dot1x guest-vlan 10 interface GigabitEthernet 2/1/2
98
Verifying the configuration
Use the display dot1x interface GigabitEthernet 2/1/2 command to verify the 802.1X guest VLAN
configuration on GigabitEthernet 2/1/2. If no user passes authentication on the port within a specific
period of time, use the display vlan 10 command to verify whether GigabitEthernet 2/1/2 is assigned
to VLAN 10.
After a user passes authentication, you can use the display interface GigabitEthernet 2/1/2 command
to verity that port GigabitEthernet 2/1/2 has been added to VLAN 5.
99
Configuring MAC authentication
MAC authentication overview
MAC authentication controls network access by authenticating source MAC addresses on a port. It does
not require client software. A user does not need to input a username and password for network access.
The device initiates a MAC authentication process when it detects an unknown source MAC address on
a MAC authentication enabled port. If the MAC address passes authentication, the user can access
authorized network resources. If the authentication fails, the device marks the MAC address as a silent
MAC address, drops the packet, and starts a quiet timer. The device drops all subsequent packets from
the MAC address within the quiet time. This quiet mechanism avoids repeated authentication during a
short time.
NOTE:
If the MAC address that has failed authentication is a static MAC address or a MAC address that has
passed any security authentication, the device does not mark the MAC address as a silent address.
User account policies
MAC authentication supports the following user account policies:
•
One MAC-based user account for each user. The access device uses the source MAC addresses in
packets as the usernames and passwords of users for MAC authentication. This policy is suitable for
an insecure environment.
•
One shared user account for all users. You specify one username and password, which are not
necessarily a MAC address, for all MAC authentication users on the access device. This policy is
suitable for a secure environment.
Authentication methods
You can perform MAC authentication on the access device (local authentication) or through a Remote
Authentication Dial-In User Service (RADIUS) server.
Suppose a source MAC unknown packet arrives at a MAC authentication enabled port.
Local authentication approach:
•
If MAC-based accounts are used, the access device uses the source MAC address of the packet as
the username and password to search its local account database for a match.
•
If a shared account is used, the access device uses the shared account username and password to
search its local account database for a match.
RADIUS authentication approach:
•
If MAC-based accounts are used, the access device sends the source MAC address as the
username and password to the RADIUS server for authentication.
•
If a shared account is used, the access device sends the shared account username and password
to the RADIUS server for authentication.
100
For more information about configuring local authentication and RADIUS authentication, see
"Configuring AAA."
MAC authentication timers
MAC authentication uses the following timers:
•
Offline detect timer—Sets the interval that the device waits for traffic from a user before it regards
the user idle. If a user connection has been idle for two consecutive intervals, the device logs the
user out and stops accounting for the user.
•
Quiet timer—Sets the interval that the device must wait before it can perform MAC authentication
for a user that has failed MAC authentication. All packets from the MAC address are dropped
during the quiet time. This quiet mechanism prevents repeated authentication from affecting system
performance.
•
Server timeout timer—Sets the interval that the access device waits for a response from a RADIUS
server before it regards the RADIUS server unavailable. If the timer expires during MAC
authentication, the user cannot access the network.
Using MAC authentication with VLAN assignment
You can specify a VLAN in the user account for a MAC authentication user to control its access to
network resources. After the user passes MAC authentication, the authentication server, either the local
access device or a RADIUS server, assigns the VLAN to the port as the default VLAN. After the user logs
off, the initial default VLAN, or the default VLAN configured before any VLAN is assigned by the
authentication server, restores. If the authentication server assigns no VLAN, the initial default VLAN
applies.
NOTE:
• A hybrid port is always assigned to a server-assigned VLAN as an untagged member. After the
assignment, do not re-configure the port as a tagged member in the VLAN.
• If MAC-based VLAN is enabled on a hybrid port, the device maps the server-assigned VLAN to the
MAC address of the user. The default VLAN of the hybrid port does not change.
MAC authentication configuration task list
Task
Basic configuration for MAC
authentication
Remarks
Configuring MAC authentication globally
Required
Configuring MAC authentication on a port
Required
Specifying an authentication domain for MAC authentication users
101
Optional
Basic configuration for MAC authentication
Configuration prerequisites
•
Create and configure an authentication domain, also called "an ISP domain."
•
For local authentication, create local user accounts, and specify the lan-access service for the
accounts.
•
For RADIUS authentication, check that the device and the RADIUS server can reach each other, and
create user accounts on the RADIUS server.
NOTE:
If you are using MAC-based accounts, make sure that the username and password for each account is the
same as the MAC address of the MAC authentication users.
Configuration procedure
MAC authentication can take effect on a port only when it is enabled globally and on the port.
Configuring MAC authentication globally
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable MAC
authentication globally.
mac-authentication
Disabled by default.
Configure MAC
authentication timers.
mac-authentication timer
{ offline-detect offline-detect-value |
quiet quiet-value | server-timeout
server-timeout-value }
Configure the properties
of MAC authentication
user accounts.
mac-authentication user-name-format
{ fixed [ account name ] [ password
{ cipher | simple } password ] |
mac-address [ { with-hyphen |
without-hyphen } [ lowercase |
uppercase ] ] }
3.
4.
Optional.
By default, the offline detect timer is
300 seconds, the quiet timer is 60
seconds, and the server timeout
timer is 100 seconds.
Optional.
By default, the username and
password for a MAC
authentication user account must
be a MAC address in lower case,
and the MAC address is not
hyphen separated.
NOTE:
When both (and only both) 802.1X authentication and MAC authentication are enabled on a port, the
device waits for 30 seconds before performing MAC authentication for a non-802.1X user that first
accesses the network from the port.
102
Configuring MAC authentication on a port
Step
Enter system view.
1.
Command
Remarks
system-view
N/A
• In system view:
mac-authentication interface
interface-list
Enable MAC authentication.
2.
• In interface view:
a. interface interface-type
interface-number
b. mac-authentication
Set the maximum number of
concurrent MAC authentication
users allowed on a port.
3.
Use either method.
Disabled by default.
Enable MAC authentication for
ports in bulk in system view or an
individual port in interface view.
Optional.
mac-authentication max-user
user-number
By default, the port supports up
to 1024 concurrent 802.1X
users.
NOTE:
You cannot add a MAC authentication enabled port in to a link aggregation group, or enable MAC
authentication on a port already in a link aggregation group.
Specifying an authentication domain for MAC
authentication users
By default, MAC authentication users are in the system default authentication domain. To implement
different access policies for users, you can specify authentication domains for MAC authentication users
in the following ways:
•
Specify a global authentication domain in system view. This domain setting applies to all ports.
•
Specify an authentication domain for an individual port in interface view.
MAC authentication chooses an authentication domain for users on a port in this order: the port-specific
domain, the global domain, and the default domain. For more information about authentication
domains, see "Configuring AAA."
To specify an authentication domain for MAC authentication users:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• In system view:
2.
Specify an authentication
domain for MAC
authentication users.
mac-authentication domain
domain-name
• In interface view:
a. interface interface-type
interface-number
b. mac-authentication domain
domain-name
103
Use either method.
By default, the system default
authentication domain is used for
MAC authentication users.
Displaying and maintaining MAC authentication
Task
Command
Remarks
Display MAC authentication
information.
display mac-authentication
[ interface interface-list ] [ | { begin
| exclude | include }
regular-expression ]
Available in any view.
Clear MAC authentication
statistics.
reset mac-authentication statistics
[ interface interface-list ]
Available in user view.
MAC authentication configuration examples
Local MAC authentication configuration example
Network requirements
In the network in Figure 39, perform local MAC authentication on port GigabitEthernet 3/1/1 to control
Internet access. Make sure that:
•
All users belong to domain aabbcc.net.
•
Local users use their MAC address as the username and password for MAC authentication. The
MAC addresses are hyphen separated and in lower case.
•
The access device detects whether a user has gone offline every 180 seconds. When a user fails
authentication, the device does not authenticate the user within 180 seconds.
Figure 39 Network diagram
Supplicant
Authenticator
GE3/1/1
Host
IP network
Device
MAC: 00e0-fc12-3456
Configuration procedure
# Add a local user account, set both the username and password to 00-e0-fc-12-34-56, the MAC address
of the user host, and enable LAN access service for the account.
<Device> system-view
[Device] local-user 00-e0-fc-12-34-56
[Device-luser-00-e0-fc-12-34-56] password simple 00-e0-fc-12-34-56
[Device-luser-00-e0-fc-12-34-56] service-type lan-access
[Device-luser-00-e0-fc-12-34-56] quit
# Configure ISP domain aabbcc.net to perform local authentication for LAN access users.
[Device] domain aabbcc.net
[Device-isp-aabbcc.net] authentication lan-access local
[Device-isp-aabbcc.net] quit
# Enable MAC authentication globally.
104
[Device] mac-authentication
# Enable MAC authentication on port GigabitEthernet 3/1/1.
[Device] mac-authentication interface GigabitEthernet 3/1/1
# Specify the ISP domain for MAC authentication.
[Device] mac-authentication domain aabbcc.net
# Set the MAC authentication timers.
[Device] mac-authentication timer offline-detect 180
[Device] mac-authentication timer quiet 180
# Configure MAC authentication to use MAC-based accounts. The MAC address usernames and
passwords are hyphenated and in lowercase.
[Device] mac-authentication user-name-format mac-address with-hyphen lowercase
Verifying the configuration
# Display MAC authentication settings and statistics.
<Device> display mac-authentication
MAC address authentication is enabled.
User name format is MAC address in lowercase, like xx-xx-xx-xx-xx-xx
Fixed username:mac
Fixed password:not configured
Offline detect period is 180s
Quiet period is 180s.
Server response timeout value is 100s
The max allowed user number is 1024 per slot
Current user number amounts to 1
Current domain is aabbcc.net
Silent Mac User info:
MAC Addr
From Port
Port Index
Gigabitethernet3/1/1 is link-up
MAC address authentication is enabled
Authenticate success: 1, failed: 0
Max number of on-line users is 1024
Current online user number is 1
MAC Addr
Authenticate state
00e0-fc12-3456
MAC_AUTHENTICATOR_SUCCESS
AuthIndex
29
# After the user passes authentication, use the display connection command to display the online user
information.
<Device> display connection
Index=29
,Username=00-e0-fc-12-34-56@aabbcc.net
MAC=00-E0-FC-12-34-56
IP=N/A
Ipv6=N/A
Total 1 connection(s) matched.
105
RADIUS-based MAC authentication configuration example
Network requirements
As shown in Figure 40, a host connects to port GigabitEthernet 3/1/1 on the access device. The device
uses RADIUS servers for authentication, authorization, and accounting.
Perform MAC authentication on port GigabitEthernet 3/1/1 to control Internet access. Make sure that:
•
The device detects whether a user has gone offline every 180 seconds. If a user fails authentication,
the device does not authenticate the user within 180 seconds.
•
All MAC authentication users belong to ISP domain 2000 and share the user account aaa with
password 123456.
Figure 40 Network diagram
RADIUS servers
Auth:10.1.1.1
Acct:10.1.1.2
GE1/1
Host
IP network
Device
Configuration procedure
Make sure that the RADIUS server and the access device can reach each other. Create a shared account
for MAC authentication users on the RADIUS server, and set the username aaa and password 123456 for
the account.
# Configure a RADIUS scheme.
<Device> system-view
[Device] radius scheme 2000
[Device-radius-2000] primary authentication 10.1.1.1 1812
[Device-radius-2000] primary accounting 10.1.1.2 1813
[Device-radius-2000] key authentication abc
[Device-radius-2000] key accounting abc
[Device-radius-2000] user-name-format without-domain
[Device-radius-2000] quit
# Apply the RADIUS scheme to ISP domain 2000 for authentication, authorization, and accounting.
[Device] domain 2000
[Device-isp-2000] authentication default radius-scheme 2000
[Device-isp-2000] authorization default radius-scheme 2000
[Device-isp-2000] accounting default radius-scheme 2000
[Device-isp-2000] quit
# Enable MAC authentication globally.
[Device] mac-authentication
# Enable MAC authentication on port GigabitEthernet 3/1/1.
106
[Device] mac-authentication interface gigabitethernet 3/1/1
# Specify the ISP domain for MAC authentication.
[Device] mac-authentication domain 2000
# Set the MAC authentication timers.
[Device] mac-authentication timer offline-detect 180
[Device] mac-authentication timer quiet 180
# Specify username aaa and plaintext password 123456 for the account shared by MAC authentication
users.
[Device] mac-authentication user-name-format fixed account aaa password simple 1234567890
Verifying the configuration
# Display MAC authentication settings and statistics.
<Device> display mac-authentication
MAC address authentication is enabled.
User name format is fixed account
Fixed username:aaa
Fixed password: ******
Offline detect period is 180s
Quiet period is 180s.
Server response timeout value is 100s
The max allowed user number is 1024 per slot
Current user number amounts to 1
Current domain is 2000
Silent Mac User info:
MAC Addr
From Port
Port Index
Gigabitethernet3/1/1 is link-up
MAC address authentication is enabled
Authenticate success: 1, failed: 0
Max number of on-line users is 1024
Current online user number is 1
MAC Addr
00e0-fc12-3456
Authenticate state
MAC_AUTHENTICATOR_SUCCESS
AuthIndex
29
# After a user passes MAC authentication, use the display connection command to display online user
information.
<Device> display connection
Index=29
,Username=aaa@2000
MAC=00-E0-FC-12-34-56
IP=N/A
IPv6=N/A
Total 1 connection(s) matched.
107
Configuring portal authentication
Overview
Portal authentication helps control access to the Internet. It is also called "web authentication." A website
implementing portal authentication is called a portal website.
With portal authentication, an access device redirects all users to the portal authentication page. All
users can access the free services provided on the portal website; but to access the Internet, a user must
pass portal authentication.
A user can access a known portal website and enter a username and password for authentication. This
authentication mode is called active authentication. There is another authentication mode, forced
authentication, in which the access device forces a user who is trying to access the Internet through
Hypertext Transfer Protocol (HTTP) to log on to a portal website for authentication.
The portal feature provides the flexibility for Internet service providers (ISPs) to manage services. A portal
website can, for example, present advertisements and deliver community and personalized services. In
this way, broadband network providers, equipment vendors, and content service providers form an
industrial ecological system.
Extended portal functions
By forcing patching and anti-virus policies, extended portal functions help users to defend against viruses.
Portal authentication supports the following extended functions:
•
Security check—Works after identity authentication succeeds to check whether the required
anti-virus software, virus definition file, and operating system (OS) patches are installed, and
whether there is any unauthorized software installed on the user host.
•
Resource access restriction—A user passing identity authentication can access only network
resources in the quarantined area, such as the anti-virus server and the patch server. Only users
passing both identity authentication and security check can access restricted network resources.
Portal system components
A typical portal system comprises these basic components: authentication client, access device, portal
server, authentication/accounting server, and security policy server.
108
Figure 41 Portal system components
Authentication client
Authentication client
Security policy server
Access device
Portal server
Authentication/accounting
server
Authentication client
Authentication client
An authentication client is an entity seeking access to network resources. It is typically an end-user
terminal, such as a PC. A client can use a browser or a portal client software for portal authentication.
The security check for a client is implemented through the communications between the client and the
security policy server.
Access device
An access device controls user access. It can be a switch or router that provides the following three
functions:
•
Redirecting all HTTP requests from unauthenticated users to the portal server.
•
Interacting with the portal server, the security policy server, and the authentication/accounting
server for identity authentication, security check, and accounting.
•
Allowing users who have passed identity authentication and security check to access granted
Internet resources.
Portal server
A portal server listens to authentication requests from authentication clients and exchanges client
authentication information with the access device. It provides free portal services and pushes web
authentication pages to users.
Authentication/accounting server
An authentication/accounting server implements user authentication and accounting through interaction
with the access device.
Security policy server
A security policy server interacts with authentication clients and access devices for security check and
resource authorization.
The components of a portal system interact in the following procedure:
1.
When an unauthenticated user enters a website address in the browser’s address bar to access the
Internet, an HTTP request is created and sent to the access device, which redirects the HTTP request
to the portal server’s web authentication homepage. For extended portal functions, authentication
clients must run the portal client software.
109
2.
On the authentication homepage/authentication dialog box, the user enters and submits the
authentication information, which the portal server then transfers to the access device.
3.
Upon receipt of the authentication information, the access device communicates with the
authentication/accounting server for authentication and accounting.
4.
After successful authentication, the access device checks whether there is a corresponding security
policy for the user. If not, it allows the user to access the Internet. Otherwise, the client
communicates with the access device and the security policy server for security check. If the client
passes security check, the security policy server authorizes the user to access the Internet
resources.
NOTE:
• Portal authentication supports NAT traversal whether it is initiated by a web client or an iNode client.
When the portal authentication client is on a private network, but the portal server is on a public network
and the access device is enabled with NAT, network address translations performed on the access
device do not affect portal authentication. However, in such a case, HP recommends specifying a public
IP address of an interface as the source address of outgoing portal packets.
• Only a RADIUS server can serve as the remote authentication/accounting server in a portal system.
• To implement security check, the client must be the iNode client.
Portal authentication modes
The router supports Layer 3 portal authentication. You can enable Layer 3 authentication on an access
device’s Layer 3 interfaces that connect authentication clients. Portal authentication performed on a Layer
3 interface can be re-DHCP authentication or cross-subnet authentication. With re-DHCP authentication,
no Layer-3 forwarding devices exist between the authentication client and the access device. With
cross-subnet authentication, Layer-3 forwarding devices may exist between the authentication client and
the access device.
Re-DHCP authentication
Before authentication, a user gets a private IP address through DHCP and can access only the portal
server and predefined free websites. After passing authentication, the user is allocated a public IP
address and can access the network resources. No public IP address is allocated to those who fail
authentication. This solves the IP address planning and allocation problem and can be useful. For
example, a service provider can allocate public IP addresses to broadband users only when they access
networks beyond the residential community network.
Cross-subnet authentication
Before authentication, a user manually configures a public IP address or directly obtains a public IP
address through DHCP, and can access only the portal server and predefined free websites. After
passing authentication, the user can access the network resources. Cross-subnet authentication allows
Layer 3 forwarding devices to be present between the authentication client and the access device.
In re-DHCP authentication and cross-subnet authentication, the client’s IP address is used for client
identification. After a client passes authentication, the access device generates an access control list (ACL)
for the client based on the client's IP address to permit packets from the client to go through the access
port. Because no Layer 3 devices are present between the authentication clients and the access device in
re-DHCP authentication, the access device can directly learn the clients' MAC addresses, and can
enhance the capability of controlling packet forwarding by also using the learned MAC addresses.
110
Portal authentication process
Cross-subnet authentication process
Figure 42 Portal authentication process
Authentication steps
1.
An authentication client initiates authentication by sending an HTTP request. When the HTTP
packet arrives at the access device, the access device allows it to pass if it is destined for the portal
server or a predefined free website, or redirects it to the portal server if it is destined for other
websites. The portal server pushes a web authentication page to the user and the user enters the
username and password.
2.
The portal server and the access device exchange Challenge Handshake Authentication Protocol
(CHAP) messages. For Password Authentication Protocol (PAP) authentication, this step is skipped.
3.
The portal server assembles the username and password into an authentication request message
and sends it to the access device. Meanwhile, the portal server starts a timer to wait for an
authentication reply message.
4.
The access device and the RADIUS server exchange RADIUS packets to authenticate the user.
5.
The access device sends an authentication reply to the portal server.
6.
The portal server sends an authentication success message to the authentication client to notify it of
logon success.
7.
The portal server sends an authentication reply acknowledgment message to the access device.
With extended portal functions, the process includes additional steps:
8.
The security policy server exchanges security check information with the authentication client to
check whether the authentication client meets the security requirements.
9.
Based on the security check result, the security policy server authorizes the user to access certain
resources, and sends the authorization information to the access device. The access device then
controls access of the user based on the authorization information.
111
Re-DHCP authentication process
Figure 43 Re-DHCP authentication process
Authentication
client
Portal server
Access device
Authentication/
accounting server
Security
policy server
1) Initiate a connection
2) CHAP authentication
3) Authentication request
4) RADIUS
authentication
Timer
5) Authentication reply
6) Authentication
succeeds
7) The user obtains
a new IP address
8) Discover user IP change
9) Detect user IP change
10) Notify login
success
11) IP change
acknowledgment
12) Security check
13) Authorization
The re-DHCP authentication takes the following procedure:
The first steps are the same as those in the direct authentication/cross-subnet authentication process.
1.
After receiving the authentication success message, the authentication client obtains a new public
IP address through DHCP and notifies the portal server that it has obtained a public IP address.
2.
The portal server notifies the access device that the authentication client has obtained a new public
IP address.
3.
Detecting the change of the IP address by examining ARP packets received, the access device
notifies the portal server of the change.
4.
The portal server notifies the authentication client of logon success.
5.
The portal server sends a user IP address change acknowledgment message to the access device.
With extended portal functions, the process includes additional steps:
6.
The security policy server exchanges security check information with the authentication client to
check whether the authentication client meets the security requirements.
7.
Based on the security check result, the security policy server authorizes the user to access certain
resources, and sends the authorization information to the access device. The access device then
controls access of the user based on the authorization information.
Portal authentication across VPNs
In a scenario where the branches belong to different VPNs that are isolated from each other and all
portal users in the branches need to be authenticated by the server at the headquarters, you can deploy
portal authentication across MPLS VPNs. As shown in Figure 44, the PE connecting the authentication
clients serves as the NAS. The NAS is configured with portal authentication and AAA authentication,
112
both of which support authentication across VPNs. Therefore, the NAS can transparently transmit portal
authentication packets of a client in a VPN through the MPLS backbone to the servers in another VPN.
This feature implements centralized authentication of clients present in different VPNs and also ensures
the separation of packets of different VPNs.
Figure 44 Network diagram for portal authentication across VPNs
VPN 1
CE
VPN 3
NAS
AAA
server
MPLS backbone
Host
PE
PE
VPN 2
Host
CE
P
Portal server
CE
NOTE:
• Portal authentication configured on MCEs can also support authentication across VPNs. For information
about MCE, see MPLS Configuration Guide.
• For information about AAA implementation across VPNs, see "Configuring AAA."
• This feature is not applicable to VPNs with overlapping address spaces.
Portal configuration task list
Task
Remarks
Basic portal configuration
Required
Configuring a portal-free rule
Controlling access of portal
users
Configuring an authentication subnet
Setting the maximum number of online portal users
Optional
Specifying an authentication domain for portal users
Specifying NAS-Port-Type for an interface
Optional
Specifying a source IP address for outgoing portal packets
Optional
Specifying an auto redirection URL for authenticated portal users
Optional
Configuring portal detection
functions
Configuring the portal server detection function
Configuring portal user information synchronization
Logging out portal users
Optional
Optional
113
Basic portal configuration
Configuration prerequisites
The portal feature provides a solution for user authentication and security checking. However, the portal
feature cannot implement this solution by itself. RADIUS authentication needs to be configured on the
router (access device) to cooperate with the portal feature to complete user authentication.
The prerequisites for portal authentication are as follows:
•
The portal server and the RADIUS server have been installed and configured properly.
•
With re-DHCP authentication, the IP address check function of the DHCP relay agent is enabled on
the access device, and the DHCP server is installed and configured properly.
•
The portal client, access device, and servers can reach each other.
•
With RADIUS authentication, usernames and passwords of the users are configured on the RADIUS
server, and the RADIUS client configurations are performed on the access device. For information
about RADIUS client configuration, see "Configuring AAA."
•
To implement extended portal functions, you need install and configure the security policy server,
and make sure the ACLs configured on the access device correspond to those resources in the
quarantined area and restricted resources on the security policy server. For information about
security policy server configuration on the access device, see "Configuring AAA."
NOTE:
• The ACL for resources in the quarantined area and that for restricted resources correspond to isolation
ACL and security ACL on the security policy server, respectively.
• You can modify the authorized ACL on the router. However, the new ACL takes effect only for portal users
logging on after the modification.
• For portal authentication to work normally, make sure the device name is no more than 16 characters.
Specifying a portal server for portal authentication
This task allows you to specify the portal server parameters for Layer 3 portal authentication, including
the portal server's IP address and port number, the shared encryption key, and the URL address for web
authentication.
To specify a portal server for portal configuration:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
114
Step
Command
Remarks
By default, no portal server is
specified.
2.
Specify a portal server name
and the related parameters.
portal server server-name ip
ip-address [ key [ cipher |
simple ] key-string | port port-id
| url url-string | vpn-instance
vpn-instance-name ] *
The router allows you to specify up to
four portal servers.
To make sure that the router can send
packets to the portal server in an
MPLS VPN, specify the VPN instance
to which the portal server belongs
when specifying the portal server on
the router.
NOTE:
The configured parameters of a portal server can be modified or deleted only if the portal server is not
referenced on any interface.
Enabling portal authentication
Only after you enable portal authentication on an access interface, can the access interface perform
portal authentication for connected clients.
Configuration prerequisites
Before enabling portal authentication on an interface, make sure that:
•
A valid IP address is configured for the interface or the interface has obtained an IP address.
•
The interface is not added to any port aggregation group.
•
The portal server to be referenced on the interface exists.
Configuration guidelines
•
You cannot enable portal authentication on a Layer 3 aggregate interface or on a Layer 3 Ethernet
interface in an aggregation group. After portal authentication is enabled on a Layer 3 Ethernet
interface, you cannot add the Layer 3 Ethernet interface to an aggregation group.
•
The destination port number that the router uses for sending unsolicited packets to the portal server
must be the same as that the remote portal server actually uses.
•
The portal server and its parameters can be deleted or modified only when the portal server is not
referenced by any interface.
•
Cross-subnet authentication mode (portal server server-name method layer3) does not require
Layer 3 forwarding devices between the access device and the authentication clients. However, if
there are Layer 3 forwarding devices between the authentication client and the access device, you
must select the cross-subnet portal authentication mode.
•
If you have enabled portal on a VLAN interface, HP does not recommend applying a user-defined
flow template on a port in the VLAN. If a user-defined flow template is required on the port, the
user-defined flow template must be defined with the source IP address, destination IP address,
destination port number, and protocol type fields; otherwise, the portal function on the VLAN
interface will not take effect.
•
If you have enabled portal on a routing interface or sub-interface, HP does not recommend
applying a user-defined flow template on the routing interface or sub-interface. If a user-defined
flow template is required on the routing interface or sub-interface, the user-defined flow template
115
must be defined with the source IP address, destination IP address, destination port number, and
protocol fields; otherwise, the portal function will not take effect.
In re-DHCP authentication mode, a client can use a public IP address to send packets before
passing portal authentication. However, responses to the packets are restricted.
•
To enable portal authentication:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
The interface must be a Layer 3
Ethernet interface.
3.
Enable portal authentication
on the interface.
portal server server-name method
{ layer3 | redhcp }
Not enabled by default.
Controlling access of portal users
Configuring a portal-free rule
A portal-free rule allows specified users to access specified external websites without portal
authentication.
The matching items for a portal-free rule include the source and destination IP address, and VLAN.
Packets matching a portal-free rule will not trigger portal authentication, and therefore users sending the
packets can directly access the specified external websites.
To configure a portal-free rule:
Step
Command
1.
Enter system view.
system-view
2.
Configure a portal-free rule.
portal free-rule rule-number { destination { any | ip { ip-address mask
{ mask-length | mask } | any } } | source { any | [ ip { ip-address mask
{ mask-length | mask } | any } | vlan vlan-id ] * } } *
NOTE:
• You cannot configure two or more portal-free rules with the same filtering conditions. Otherwise, the
system prompts that the rule already exists.
• No matter whether portal authentication is enabled, you can only add or remove a portal-free rule,
rather than modifying it.
Configuring an authentication subnet
By configuring authentication subnets, you specify that only HTTP packets from users on the
authentication subnets can trigger portal authentication. If an unauthenticated user is not on any
authentication subnet, the access device discards all the user’s HTTP packets that do not match any
portal-free rule.
To configure an authentication subnet:
116
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
Optional.
3.
Configure an authentication
subnet.
portal auth-network
network-address { mask-length |
mask }
By default, the authentication
subnet is 0.0.0.0/0, which means
that users with any source IP
addresses must pass portal
authentication.
Setting the maximum number of online portal users
You can use this feature to control the total number of online portal users in the system.
To set the maximum number of online portal users allowed in the system:
Step
1.
2.
Enter system view.
Set the maximum number of
online portal users.
Command
Remarks
system-view
N/A
portal max-user max-number
The default maximum number of
online portal users depends on the
system operating mode. For
information about the working
modes, see Fundamentals
Configuration Guide.
NOTE:
If the maximum number of online portal users specified in the command is less than that of the current
online portal users, the command can be executed successfully and will not impact the online portal users,
but the system will not allow new portal users to log on until the number drops down below the limit.
Specifying an authentication domain for portal users
After you specify an authentication domain for portal users on an interface, the router uses the
authentication domain for authentication, authorization, and accounting (AAA) of all portal users on the
interface, ignoring the domain names carried in the usernames. You can specify different authentication
domains for different interfaces as needed.
To specify an authentication domain for portal users on an interface:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Specify an authentication
domain for portal users on the
interface.
portal domain domain-name
By default, no authentication domain is
specified for portal users.
117
NOTE:
The router selects the authentication domain for a portal user on an interface in this order: the
authentication domain specified for the interface, the authentication domain carried in the username, and
the system default authentication domain. For information about the default authentication domain, see
"Configuring AAA."
Specifying NAS-Port-Type for an interface
NAS-Port-Type is a standard RADIUS attribute for indicating the type of a user access port. With this
attribute specified on an interface, when a portal user logs on from the interface, the router uses the
specified NAS-Port-Type value as that in the RADIUS request that it will send to the RADIUS server.
If NAS-Port-Type is not specified, the router uses the access port type obtained. However, if there are
multiple network devices between the Broadband Access Server (BAS, the portal authentication access
device) and a portal client, the BAS may not be able to obtain the correct access port information of a
user. For example, for a wireless client using portal authentication, the access port type obtained by the
BAS may be the type of the wired port that authenticates the user. Therefore, to make sure that the BAS
delivers the correct access port information to the RADIUS server, specify the NAS-Port-Type according to
the practical access environment.
To specify the NAS-Port-Type value for an interface:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Specify the NAS-Port-Type
value for the interface.
portal nas-port-type { ethernet |
wireless }
Not configured by default.
Specifying a source IP address for outgoing portal
packets
After you specify a source IP address for outgoing portal packets, the IP address is used for packet
exchanging between the access device and the portal server.
To specify the source IP address for outgoing portal packets:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
118
Step
Command
Remarks
Optional.
3.
Specify a source IP
address for outgoing
portal packets.
portal nas-ip ip-address
By default, no source IP address is specified
and the IP address of the user logon interface
is used as the source IP address of the portal
packets.
In NAT environments, HP recommends
specifying the interface’s public IP address as
the source IP address of outgoing portal
packets.
Specifying an auto redirection URL for
authenticated portal users
If you specify an auto redirection URL on the access device, after an unauthenticated user passes portal
authentication through the portal authentication page, the access device redirects the user to the URL.
To specify an auto redirection URL for authenticated portal users:
Step
1.
2.
Enter system view.
Specify an auto redirection
URL for authenticated portal
users.
Command
Remarks
system-view
N/A
portal redirect-url url-string
[ wait-time period ]
By default, an authenticated user is
redirected to the URL the user typed
in the address bar before portal
authentication.
The router does not support the
wait-time keyword.
NOTE:
To use this feature, the portal server must be an IMC portal server that supports the page auto-redirection
function.
Configuring portal detection functions
Configuring the portal server detection function
During portal authentication, if the communication between the access device and portal server is
broken off, new portal users will not be able to log on and the online portal users will not be able to log
off normally. To address this problem, the access device needs to be able to detect the reachability
changes of the portal server timely and take corresponding actions to deal with the changes. For
example, once detecting that the portal server is unreachable, the access device will allow portal users
to access network resources without authentication. This function is referred to as portal escape. It allows
for flexible user access control.
119
With the portal server detection function, the router (the access device) can detect the status of a specific
portal server. The specific configurations include:
1.
Detection methods (you can choose either or both)
{
{
2.
Checking portal heartbeat packets: A portal server that supports the portal heartbeat function
(only the IMC portal server supports this function) sends portal heartbeat packets to portal
access devices periodically. If an access device receives a portal heartbeat packet or an
authentication packet within a probe interval, the access device considers that the probe
succeeds and the portal server is reachable; otherwise, it considers that the probe fails and the
portal server is unreachable.
Probe parameters
{
{
3.
Probing HTTP connections: The access device periodically sends TCP connection requests to the
HTTP service port of the portal servers configured on its interfaces. If the TCP connection with a
portal server can be established, the access device considers that the probe succeeds, that is,
the HTTP service of the portal server is open and the portal server is reachable. If the TCP
connection cannot be established, the access device considers that the probe fails and the
portal server is unreachable.
Probe interval: Interval at which probe attempts are made.
Maximum number of probe attempts: Maximum number of consecutive probe attempts allowed.
If the number of consecutive probes reaches this value, the access device considers that the
portal server is unreachable.
Actions to be taken when the server reachability status changes (you can choose one or more)
{
{
{
Sending a trap message: When the status of a portal server changes, the access device sends
a trap message to the network management server. The trap message indicates the name and
current state of the portal server.
Sending a log: When the status of a portal server changes, the access device sends a log
message. The log message indicates the portal server’s name and its current state and original
state.
Disabling portal authentication (enabling portal escape): When the router detects that a portal
server is unreachable, it disables portal authentication on the interfaces configured with the
portal server, that is, it allows all portal users on the interfaces to access network resources. Then,
if the router receives from the portal server portal heartbeat packets or authentication packets
(such as logon requests and logout requests), it re-enables the portal authentication function.
You can configure any combination of the configuration items described above as needed, with respect
of the following:
•
If both detection methods are specified, a portal server is considered unreachable as long as one
detection method fails, and an unreachable portal server is considered recovered only when both
detection methods succeed.
•
If multiple actions are specified, the router will execute all the specified actions when the status of a
portal server changes.
•
The detection function configured for a portal server takes effect on an interface only after you
enable and reference the portal server on the interface.
To configure the portal server detection function:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
120
Step
Configure the portal
server detection
function.
2.
Command
Remarks
portal server server-name server-detect
method { http | portal-heartbeat } * action
{ log | permit-all | trap } * [ interval
interval ] [ retry retries ]
Not configured by default.
The portal server specified in the
command must exist.
NOTE:
The portal heartbeat detection method works only when the portal server supports the portal server
heartbeat function. Currently, only the IMC portal server supports this function. To implement detection
with this method, you also need to configure the portal server heartbeat function on the IMC portal server
and make sure that the product of interval and retry is greater than or equal to the portal server heartbeat
interval, and HP recommends configuring the interval to be greater than the portal server heartbeat
interval configured on the portal server.
Configuring portal user information synchronization
Once the router loses communication with a portal server, the portal user information on the router and
that on the portal server may be inconsistent after the communication resumes. To solve this problem, the
router provides the portal user information synchronization function. This function is implemented by
sending and detecting the portal synchronization packet. The process is as follows:
1.
The portal server sends the online user information to the access device (the router) in a user
synchronization packet at the user heartbeat interval, which is set on the portal server.
2.
Upon receiving the user synchronization packet, the router checks the user information carried in
the packet with its own. If the router finds a nonexistent user in the packet, it informs the portal
server of the information and the portal server will delete the user. If the router finds that one of its
users does not appear in the user synchronization packets within N consecutive synchronization
probe intervals (N is equal to the value of retries configured in the portal server user-sync
command), it considers that the user does not exist on the portal server and logs the user off.
To configure the portal user information synchronization function:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
Not configured by default.
2.
Configure the portal
user information
synchronization
function.
portal server server-name user-sync
[ interval interval ] [ retry retries ]
121
The portal server specified in the
command must exist.
This function can take effect only
when the specified portal server is
referenced and enabled on the
interface connecting the users.
NOTE:
• The user information synchronization function requires that a portal server supports the portal user
heartbeat function. Only the IMC portal server supports portal user heartbeat. To implement the portal
user synchronization function, you also need to configure the user heartbeat function on the portal
server and make sure that the product of interval and retry is greater than or equal to the portal user
heartbeat interval, and HP recommends configuring the interval to be greater than the portal user
heartbeat interval configured on the portal server.
• For redundant user information on the router—information for users who are considered nonexistent on
the portal server—the router deletes the information during the (N+1)th interval, where N is equal to the
value of retries configured in the portal server user-sync command.
Logging out portal users
Logging out a user terminates the authentication process for the user or removes the user from the
authenticated users list.
To log out users:
Step
Command
1.
Enter system view.
system-view
2.
Log out users.
portal delete-user { ip-address | all | interface interface-type
interface-number }
Displaying and maintaining portal
Task
Command
Remarks
Display the ACLs on a specific
interface.
display portal acl { all | dynamic | static }
interface interface-type interface-number [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display portal connection statistics
on a specific interface or all
interfaces.
display portal connection statistics { all |
interface interface-type interface-number } [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display information about a
portal-free rule or all portal-free
rules.
display portal free-rule [ rule-number ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display the portal configuration of
a specific interface.
display portal interface interface-type
interface-number [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display information about a
specific portal server or all portal
servers.
display portal server [ server-name ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
122
Task
Command
Remarks
Display portal server statistics on a
specific interface or all interfaces.
display portal server statistics { all | interface
interface-type interface-number } [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display TCP spoofing statistics.
display portal tcp-cheat statistics [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display information about portal
users on a specific interface or all
interfaces.
display portal user { all | interface
interface-type interface-number } [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Clear portal connection statistics
on a specific interface or all
interfaces.
reset portal connection statistics { all |
interface interface-type interface-number }
Available in user view.
Clear portal server statistics on a
specific interface or all interfaces.
reset portal server statistics { all | interface
interface-type interface-number }
Available in user view.
Clear TCP spoofing statistics.
reset portal tcp-cheat statistics
Available in user view.
Portal configuration examples
Configuring re-DHCP portal authentication
Network requirements
As shown in Figure 45:
•
The host is directly connected to the router and the router is configured for re-DHCP portal
authentication. The host is assigned an IP address through the DHCP server. Before passing portal
authentication, the host uses an assigned private IP address. After passing portal authentication, it
gets a public IP address and then the user can access Internet resources.
•
A RADIUS server serves as the authentication/accounting server.
Figure 45 Network diagram
123
Configuration procedure
NOTE:
• For re-DHCP portal authentication, configure a public address pool (20.20.20.0/24, in this example)
and a private address pool (10.0.0.0/24, in this example) on the DHCP server. (Details not shown.)
• For re-DHCP portal authentication, the router must be configured as a DHCP relay agent and the
portal-enabled interface must be configured with a primary IP address (a public IP address) and a
secondary IP address (a private IP address). For DHCP relay configuration information, see Layer 3—IP
Services Configuration Guide.
• Make sure that the IP address of the portal device added on the portal server is the public IP address of
the interface connecting users (20.20.20.1 in this example), the private IP address range for the IP
address group associated with the portal device is the private network segment where the users reside
(10.0.0.0/24 in this example), and the public IP address range for the IP address group is the public
network segment 20.20.20.0/24.
• Configure IP addresses for the router and servers as shown in Figure 45 and make sure that the host,
router, and servers can reach each other.
• Configure the RADIUS server properly to provide normal authentication/accounting functions for users.
Configure the router:
1.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1, and enter its view.
<Router> system-view
[Router] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the IMC server, set the server type to
extended.
[Router-radius-rs1] server-type extended
# Specify the primary authentication server and primary accounting server, and configure the keys
for communication with the servers.
[Router-radius-rs1] primary authentication 192.168.0.113
[Router-radius-rs1] primary accounting 192.168.0.113
[Router-radius-rs1] key authentication simple radius
[Router-radius-rs1] key accounting simple radius
# Specify to exclude ISP domain names from the usernames to be sent to the RADIUS server.
[Router-radius-rs1] user-name-format without-domain
[Router-radius-rs1] quit
2.
Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[Router] domain dm1
# Configure the ISP domain to use RADIUS scheme rs1.
[Router-isp-dm1] authentication portal radius-scheme rs1
[Router-isp-dm1] authorization portal radius-scheme rs1
[Router-isp-dm1] accounting portal radius-scheme rs1
[Router-isp-dm1] quit
# Configure dm1 as the default ISP domain for all users. Then, if a user enters a username without
any ISP domain at logon, the authentication and accounting methods of the default domain will be
used for the user.
124
[Router] domain default enable dm1
3.
Configure portal authentication:
# Configure the portal server as follows:
{
Name: newpt
{
IP address: 192.168.0.111
{
Key: portal (in plain text)
{
Port number: 50100
{
URL: http://192.168.0.111:8080/portal.
[Router] portal server newpt ip 192.168.0.111 key simple portal port 50100 url
http://192.168.0.111:8080/portal
# Configure the router as a DHCP relay agent, and enable the IP address match check function.
[Router] dhcp enable
[Router] dhcp relay server-group 0 ip 192.168.0.112
[Router] interface Gigabitethernet 3/1/2
[Router–GigabitEthernet3/1/2] ip address 20.20.20.1 255.255.255.0
[Router–GigabitEthernet3/1/2] ip address 10.0.0.1 255.255.255.0 sub
[Router-GigabitEthernet3/1/2] dhcp select relay
[Router-GigabitEthernet3/1/2] dhcp relay server-select 0
[Router-GigabitEthernet3/1/2] dhcp relay address-check enable
# Enable re-DHCP portal authentication on the interface connecting the host.
[Router–GigabitEthernet3/1/2] portal server newpt method redhcp
[Router–GigabitEthernet3/1/2] quit
Configuring cross-subnet portal authentication
Network requirements
As shown in Figure 46:
•
Router A is configured for cross-subnet portal authentication. Before portal authentication, users can
access only the portal server. After passing portal authentication, they can access Internet
resources.
•
A RADIUS server serves as the authentication/accounting server.
Figure 46 Network diagram
125
Configuration procedure
NOTE:
• Make sure that the IP address of the portal device added on the portal server is the IP address of the
interface connecting users (20.20.20.1 in this example), and the IP address group associated with the
portal device is the network segment where the users reside (8.8.8.0/24 in this example).
• Configure IP addresses for the host, routers, and servers as shown in Figure 46 and make sure that they
can reach each other.
• Configure the RADIUS server properly to provide normal authentication/accounting functions for users.
Configure Router A:
1.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<RouterA> system-view
[RouterA] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the IMC server, set the server type to
extended.
[RouterA-radius-rs1] server-type extended
# Configure the primary authentication server, the primary accounting server, and the keys for the
servers to communicate.
[RouterA-radius-rs1] primary authentication 192.168.0.112
[RouterA-radius-rs1] primary accounting 192.168.0.112
[RouterA-radius-rs1] key authentication simple radius
[RouterA-radius-rs1] key accounting simple radius
# Specify that the ISP domain name should not be included in the username sent to the RADIUS
server.
[RouterA-radius-rs1] user-name-format without-domain
[RouterA-radius-rs1] quit
2.
Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[RouterA] domain dm1
# Configure the ISP domain to use RADIUS scheme rs1.
[RouterA-isp-dm1] authentication portal radius-scheme rs1
[RouterA-isp-dm1] authorization portal radius-scheme rs1
[RouterA-isp-dm1] accounting portal radius-scheme rs1
[RouterA-isp-dm1] quit
# Configure dm1 as the default ISP domain for all users. Then, if a user enters a username without
any ISP domain at logon, the authentication and accounting methods of the default domain will be
used for the user.
[RouterA] domain default enable dm1
3.
Configure portal authentication:
# Configure the portal server as follows:
{
Name: newpt
{
IP address: 192.168.0.111
{
Key: portal (in plain text)
126
{
Port number: 50100
{
URL: http://192.168.0.111:8080/portal.
<RouterA> system-view
[RouterA] portal server newpt ip 192.168.0.111 key simple portal port 50100 url
http://192.168.0.111:8080/portal
# Enable portal authentication on the interface connecting Router B.
[RouterA] interface GigabitEthernet 3/1/2
[RouterA–GigabitEthernet3/1/2] portal server newpt method layer3
[RouterA–GigabitEthernet3/1/2] quit
On Router B, configure a default route to subnet 192.168.0.0/24, setting the next hop as 20.20.20.1.
(Details not shown.)
Configuring re-DHCP portal authentication with extended
functions
Network requirements
As shown in Figure 47:
•
The router is configured for re-DHCP extended portal authentication. The host is assigned an IP
address through the DHCP server. Before extended portal authentication, the host uses an assigned
private IP address. After passing the authentication, the host gets a public IP address.
•
When users have passed identity authentication but have not passed security checking, they can
access only subnet 192.168.0.0/24. After passing security checking, they can access Internet
resources.
•
A RADIUS server serves as the authentication/accounting server.
Figure 47 Network diagram
Configuration procedure
127
NOTE:
• For re-DHCP portal authentication, configure a public address pool (20.20.20.0/24, in this example)
and a private address pool (10.0.0.0/24, in this example) on the DHCP server. (Details not shown.)
• For re-DHCP portal authentication, the router must be configured as a DHCP relay agent and the
portal-enabled interface must be configured with a primary IP address (a public IP address) and a
secondary IP address (a private IP address). For DHCP configuration information, see Layer 3—IP
Services Configuration Guide.
• Make sure that the IP address of the portal device added on the portal server is the public IP address of
the interface connecting users (20.20.20.1 in this example), the private IP address range for the IP
address group associated with the portal device is the private network segment where the users reside
(10.0.0.0/24 in this example), and the public IP address range for the IP address group is the public
network segment 20.20.20.0/24.
• Configure IP addresses for the router and servers as shown in Figure 47 and make sure that the host,
router, and servers can reach each other.
• Configure the RADIUS server properly to provide normal authentication/accounting functions for users.
Configure the router:
1.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<Router> system-view
[Router] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the IMC server, you need set the server
type to extended.
[Router-radius-rs1] server-type extended
# Specify the primary authentication server and primary accounting server, and configure the keys
for communication with the servers.
[Router-radius-rs1] primary authentication 192.168.0.113
[Router-radius-rs1] primary accounting 192.168.0.113
[Router-radius-rs1] key authentication simple radius
[Router-radius-rs1] key accounting simple radius
# Specify to exclude ISP domain names from the usernames to be sent to the RADIUS server.
[Router-radius-rs1] user-name-format without-domain
# Configure the IP address of the security policy server.
[Router-radius-rs1] security-policy-server 192.168.0.114
[Router-radius-rs1] quit
2.
Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[Router] domain dm1
# Configure the ISP domain to use RADIUS scheme rs1.
[Router-isp-dm1] authentication portal radius-scheme rs1
[Router-isp-dm1] authorization portal radius-scheme rs1
[Router-isp-dm1] accounting portal radius-scheme rs1
[Router-isp-dm1] quit
# Configure dm1 as the default ISP domain for all users. Then, if a user enters the username without
the ISP domain at logon, the authentication and accounting methods of the default domain will be
used for the user.
128
[Router] domain default enable dm1
3.
Configure the ACL (ACL 3000 ) for resources on subnet 192.168.0.0/24 and the ACL (ACL 3001)
for Internet resources:
NOTE:
On the security policy server, specify ACL 3000 as the isolation ACL and ACL 3001 as the security ACL.
[Router] acl number 3000
[Router-acl-adv-3000] rule permit ip destination 192.168.0.0 0.0.0.255
[Router-acl-adv-3000] rule deny ip
[Router-acl-adv-3000] quit
[Router] acl number 3001
[Router-acl-adv-3001] rule permit ip
[Router-acl-adv-3001] quit
4.
Configure portal authentication:
# Configure the portal server as follows:
{
Name: newpt
{
IP address: 192.168.0.111
{
Key: portal (in plain text)
{
Port number: 50100
{
URL: http://192.168.0.111:8080/portal.
[Router] portal server newpt ip 192.168.0.111 key simple portal port 50100 url
http://192.168.0.111:8080/portal
# Configure the router as a DHCP relay agent, and enable the IP address match check function.
[Router] dhcp enable
[Router] dhcp relay server-group 0 ip 192.168.0.112
[Router] interface GigabitEthernet 3/1/2
[Router–GigabitEthernet3/1/2] ip address 20.20.20.1 255.255.255.0
[Router–GigabitEthernet3/1/2] ip address 10.0.0.1 255.255.255.0 sub
[Router-GigabitEthernet3/1/2] dhcp select relay
[Router-GigabitEthernet3/1/2] dhcp relay server-select 0
[Router-GigabitEthernet3/1/2] dhcp relay address-check enable
# Enable portal authentication on the interface connecting the host.
[Router–GigabitEthernet3/1/2] portal server newpt method redhcp
[Router–GigabitEthernet3/1/2] quit
Configuring cross-subnet portal authentication with extended
functions
Network requirements
As shown in Figure 48:
•
Router A is configured for cross-subnet extended portal authentication. When users have passed
identity authentication but have not passed security checking, they can access only subnet
192.168.0.0/24. After passing the security checking, they can access Internet resources.
•
A RADIUS server serves as the authentication/accounting server.
129
Figure 48 Network diagram
Router A
GE3/1/1
192.168.0.100/24
Portal server
192.168.0.111/24
GE3/1/2
20.20.20.1/24
GE3/1/1
20.20.20.2/24
GE3/1/2
8.8.8.1/24
Host
Radius server
192.168.0.112/24
Router B
8.8.8.2/24
Security policy server
192.168.0.113/24
Configuration procedure
NOTE:
• Make sure that the IP address of the portal device added on the portal server is the IP address of the
interface connecting users (20.20.20.1 in this example), and the IP address group associated with the
portal device is the network segment where the users reside (8.8.8.0/24 in this example).
• Configure IP addresses for the host, routers, and servers as shown in Figure 48 and make sure that they
can reach each other.
• Configure the RADIUS server properly to provide normal authentication/accounting functions for users.
Configure Router A:
1.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<RouterA> system-view
[RouterA] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the IMC server, set the server type to
extended.
[RouterA-radius-rs1] server-type extended
# Specify the primary authentication server and primary accounting server, and configure the keys
for communication with the servers.
[RouterA-radius-rs1] primary authentication 192.168.0.112
[RouterA-radius-rs1] primary accounting 192.168.0.112
[RouterA-radius-rs1] key authentication simple radius
[RouterA-radius-rs1] key accounting simple radius
[RouterA-radius-rs1] user-name-format without-domain
# Configure the IP address of the security policy server.
[RouterA-radius-rs1] security-policy-server 192.168.0.113
[RouterA-radius-rs1] quit
2.
Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[RouterA] domain dm1
130
# Configure the ISP domain to use RADIUS scheme rs1.
[RouterA-isp-dm1] authentication portal radius-scheme rs1
[RouterA-isp-dm1] authorization portal radius-scheme rs1
[RouterA-isp-dm1] accounting portal radius-scheme rs1
[RouterA-isp-dm1] quit
# Configure dm1 as the default ISP domain for all users. Then, if a user enters a username without
any ISP domain at logon, the authentication and accounting methods of the default domain will be
used for the user.
[RouterA] domain default enable dm1
3.
Configure the ACL (ACL 3000 ) for resources on subnet 192.168.0.0/24 and the ACL (ACL 3001)
for Internet resources:
NOTE:
On the security policy server, specify ACL 3000 as the isolation ACL and ACL 3001 as the security ACL.
[RouterA] acl number 3000
[RouterA-acl-adv-3000] rule permit ip destination 192.168.0.0 0.0.0.255
[RouterA-acl-adv-3000] rule deny ip
[RouterA-acl-adv-3000] quit
[RouterA] acl number 3001
[RouterA-acl-adv-3001] rule permit ip
[RouterA-acl-adv-3001] quit
4.
Configure extended portal authentication:
# Configure the portal server as follows:
{
Name: newpt
{
IP address: 192.168.0.111
{
Key: portal (in plain text)
{
Port number: 50100
{
URL: http://192.168.0.111:8080/portal.
[RouterA] portal server newpt ip 192.168.0.111 key simple portal port 50100 url
http://192.168.0.111:8080/portal
# Enable portal authentication on the interface connecting Router B.
[RouterA] interface GigabitEthernet 3/1/2
[RouterA–GigabitEthernet3/1/2] portal server newpt method layer3
[RouterA–GigabitEthernet3/1/2] quit
On Router B, configure a default route to subnet 192.168.0.0/24, setting the next hop as 20.20.20.1.
(Details not shown.)
Configuring portal server detection and portal user information
synchronization
Network requirements
As shown in Figure 49, a host is connected to the router and must pass portal authentication to access the
Internet. A RADIUS server serves as the authentication server.
Detailed requirements are as follows:
131
•
The host is assigned a public network IP address either manually or through DHCP. Before passing
portal authentication, the host can access only the portal server. After passing portal authentication,
the host can access the Internet.
•
The access device (Router) can detect whether the portal server is reachable and send trap
messages upon portal server state changes. When the portal server is unreachable due to, for
example, a connection failure, network device failure, or portal server failure, the access device can
disable portal authentication, allowing users to access the Internet without authentication.
•
The access device can synchronize portal user information with the portal server periodically.
Figure 49 Network diagram
Portal server
GE3/1/1
192.168.0.100/24
GE3/1/2
2.2.2.1/24
Host
192.168.0.111/24
Router
2.2.2.2/24
Gateway : 2.2.2.1/24
RADIUS server
192.168.0.112/24
Configuration considerations
1.
Configure the portal server and enable portal server heartbeat function and the portal user
heartbeat function.
2.
Configure the RADIUS server to implement authentication.
3.
Configure cross-subnet portal authentication on interface GigabitEthernet 3/1/2 of the router.
4.
Configure the portal server detection function on the router, so that Router can detect the status of
the portal server by cooperating with the portal server heartbeat function.
5.
Configure the portal user information synchronization function, so that the router can synchronize
portal user information with the portal server by cooperating with the portal user heartbeat
function.
NOTE:
• Configure IP addresses for the host, router, and servers as shown in Figure 49 and make sure that they
can reach each other.
• Configure the RADIUS server properly to provide normal authentication functions for users.
• If the portal server is an IMC server, the RADIUS server must be an IMC server, too.
Configuring the portal server (IMC PLAT 5.0)
NOTE:
The following assumes that the portal server runs on IMC PLAT 5.0(E0101) and IMC UAM 5.0(E0101).
1.
Configure the portal server.
a. Log in to IMC and select the Service tab.
132
b. Select User Access Manager > Portal Service Management > Server from the navigation tree to
enter the portal server configuration page, as shown in Figure 50.
c. Configure the portal server heartbeat interval and user heartbeat interval.
d. Use default values for the other parameters.
e. Click OK.
Figure 50 Portal server configuration
2.
Configure the IP address group:
a. Select User Access Manager > Portal Service Management > IP Group from the navigation tree
to enter the portal IP address group configuration page.
b. Click Add to enter the page shown in Figure 51.
c. Enter the IP group name.
d. Enter the start IP address and end IP address of the IP group.
Make sure that the host IP address is in the IP group.
e. Select a service group.
By default, the group Ungrouped is used.
f. Select the IP group type Normal.
g. Click OK.
133
Figure 51 Adding an IP address group
3.
Add a portal device:
a. Select User Access Manager > Portal Service Management > Device from the navigation tree to
enter the portal device configuration page.
b. Click Add to enter the page shown in Figure 52.
c. Enter the device name NAS.
d. Enter the IP address of the router’s interface connected to the user.
e. Enter the key, which must be the same as that configured on the router.
f. Set whether to enable IP address reallocation.
This example uses direct portal authentication, and therefore select No from the Reallocate IP
list.
g. Select Yes for both Support Server Heartbeat and Support User Heartbeat.
h. Click OK.
Figure 52 Adding a portal device
4.
Associate the portal device with the IP address group:
134
a. As shown in Figure 53, click the icon in the Port Group Information Management column of
device NAS to enter the port group configuration page.
Figure 53 Device list
b. Click Add to enter the page shown in Figure 54.
c. Enter the port group name.
d. Select the configured IP address group.
The IP address used by the user to access the network must be within this IP address group.
e. Use the default settings for the other parameters.
f. Click OK.
Figure 54 Adding a port group
5.
Select User Access Manager > Service Parameters > Validate System Configuration from the
navigation tree to validate the configuration.
Configuring the router
1.
Configure a RADIUS scheme:
# Create RADIUS scheme rs1 and enter its view.
<Router> system-view
[Router] radius scheme rs1
# Configure the server type for the RADIUS scheme. When using the IMC server, configure the
RADIUS server type as extended.
[Router-radius-rs1] server-type extended
# Specify the primary authentication server, and configure the keys for communication with the
servers.
135
[Router-radius-rs1] primary authentication 192.168.0.112
[Router-radius-rs1] primary accounting 192.168.0.112
[Router-radius-rs1] key authentication simple radius
[Router-radius-rs1] key accounting simple radius
# Specify to exclude ISP domains from the usernames to be sent to the RADIUS server.
[Router-radius-rs1] user-name-format without-domain
[Router-radius-rs1] quit
2.
Configure an authentication domain:
# Create ISP domain dm1 and enter its view.
[Router] domain dm1
# Configure the ISP domain to use RADIUS scheme rs1.
[Router-isp-dm1] authentication portal radius-scheme rs1
[Router-isp-dm1] authorization portal radius-scheme rs1
[Router-isp-dm1] accounting portal radius-scheme rs1
[Router-isp-dm1] quit
# Configure dm1 as the default ISP domain for all users. Then, if a user enters a username without
any ISP domain at logon, the authentication methods of the default domain will be used for the
user.
[Router] domain default enable dm1
3.
Configure portal authentication:
# Configure a portal server on the router, making sure the IP address, port number and URL match
those of the actual portal server.
[Router] portal server newpt ip 192.168.0.111 key simple portal port 50100 url
http://192.168.0.111:8080/portal
# Enable portal authentication on the interface connecting the host.
[Router] interface Gigabitethernet 3/1/2
[Router–GigabitEthernet3/1/2] portal server newpt method layer3
[Router–GigabitEthernet3/1/2] quit
4.
Configure the portal server detection function:
# Configure the access device to detect portal server newpt, specifying the detection method as
portal heartbeat probe, setting the server probe interval to 40 seconds, and specifying the access
device to send a server unreachable trap message and disable portal authentication to permit
unauthenticated portal users if two consecutive probes fail.
[Router] portal server newpt server-detect method portal-heartbeat action trap
permit-all interval 40 retry 2
NOTE:
The product of interval and retry must be greater than or equal to the portal server heartbeat interval, and
HP recommends configuring the interval to be greater than the portal server heartbeat interval configured
on the portal server.
5.
Configure portal user information synchronization:
# Configure the access device to synchronize portal user information with portal server newpt,
setting the synchronization probe interval to 600 seconds, and specifying the access device to log
off users if the users do not appear in the user synchronization packets sent from the server within
two consecutive probe intervals.
[Router] portal server newpt user-sync interval 600 retry 2
136
NOTE:
The product of interval and retry must be greater than or equal to the portal user heartbeat interval, and
HP recommends configuring the interval to be greater than the portal user heartbeat interval configured
on the portal server.
Verifying the configuration
Use the following command to display information about the portal server.
<Router> display portal server newpt
Portal server:
1)newpt:
IP
: 192.168.0.111
Key
: ******
Port : 50100
URL
Status
: http://192.168.0.111:8080/portal
: Up
The Up state of the portal server indicates that the portal server is reachable. If the access device detects
that the portal server is unreachable, you can see the portal server status is Down in the command output,
and the access device generates a server unreachable trap "portal server newpt lost" and disables
portal authentication on the access interface, so the client can access the external network without
authentication.
Cross-subnet portal authentication across VPNs
Network requirements
As shown in Figure 55, Router A, as the PE router connecting the user side, needs to provide cross-subnet
portal authentication for hosts in VPN 1 through communication with the RADIUS server and portal
server in VPN 3.
Figure 55 Network diagram
Configuring Router A
NOTE:
• Before enabling portal authentication, be sure to configure the MPLS L3VPN capabilities properly and
specify VPN targets for VPN 1 and VPN 3 so that VPN 1 and VPN 3 can communicate with each other.
This example gives only the access authentication configuration on the user-side PE. For information
about MPLS L3VPN, see MPLS Configuration Guide.
• Configure the RADIUS server properly to provide normal authentication/accounting functions for users.
137
1.
Configure a RADIUS scheme:
# Create a RADIUS scheme named rs1 and enter its view.
<RouterA> system-view
[RouterA] radius scheme rs1
# Configure the VPN instance to which the RADIUS scheme belongs as vpn3.
[RouterA-radius-rs1] vpn-instance vpn3
# Set the server type for the RADIUS scheme. When using the IMC server, set the server type to
extended.
[RouterA-radius-rs1] server-type extended
# Specify the primary authentication server and primary accounting server, and configure the keys
for communication with the servers.
[RouterA-radius-rs1] primary authentication 192.168.0.111
[RouterA-radius-rs1] primary accounting 192.168.0.111
[RouterA-radius-rs1] key accounting simple radius
[RouterA-radius-rs1] key authentication simple radius
# Specify to exclude ISP domains from the usernames to be sent to the RADIUS server.
[RouterA-radius-rs1] user-name-format without-domain
# Specify the source IP address for RADIUS packets to be sent as 3.3.0.3.
[RouterA-radius-rs1] nas-ip 3.3.0.3
[RouterA-radius-rs1] quit
IMPORTANT:
Use the nas-ip command to specify the source IP address for RADIUS packets to be sent, and make sure
that the source IP address is consistent with the IP address of the access device specified on the server, so
as to avoid authentication failures.
2.
Configure an authentication domain:
# Create an ISP domain named dm1 and enter its view.
[RouterA] domain dm1
# Configure the ISP domain to use RADIUS scheme rs1.
[RouterA-isp-dm1] authentication portal radius-scheme rs1
[RouterA-isp-dm1] authorization portal radius-scheme rs1
[RouterA-isp-dm1] accounting portal radius-scheme rs1
[RouterA-isp-dm1] quit
# Configure dm1 as the default ISP domain for all users. Then, if a user enters a username without
any ISP domain at logon, the authentication and accounting methods of the default domain will be
used for the user.
[RouterA] domain default enable dm1
3.
Configure portal authentication:
# Configure the portal server as follows:
{
Name: newpt
{
IP address: 192.168.0.111
{
VPN: vpn3
{
Key: portal (in plain text)
{
Port number: 50100
138
{
URL: http://192.168.0.111:8080/portal.
[RouterA] portal server newpt ip 192.168.0.111 vpn-instance vpn3 key simple portal
port 50100 url http://192.168.0.111:8080/portal
# Enable cross-subnet portal authentication on the interface connecting the user side.
[RouterA] interface Gigabitethernet 3/1/1
[RouterA–GigabitEthernet3/1/1] portal server newpt method layer3
[RouterA–GigabitEthernet3/1/1] quit
Verifying the configuration
Execute the display portal server command to check whether the portal configuration has taken effect.
After Host passes portal authentication, perform the display portal user command to view information
about online portal users on Router A.
[RouterA] display portal user all
Index:2
State:ONLINE
SubState:NONE
ACL:NONE
Work-mode:stand-alone
VPN instance:vpn1
MAC
IP
Vlan
Interface
---------------------------------------------------------------------------000d-88f7-c268
3.3.0.1
0
GigabitEthernet3/1/1
Total 1 user(s) matched, 1 listed.
Troubleshooting portal
Inconsistent keys on the router (access device) and the portal
server
Symptom
When a user is forced to access the portal server, the portal server displays neither the portal
authentication page nor any error message. What the user sees is a blank web page.
Analysis
The key configured on the router and that on the portal server are inconsistent, causing CHAP message
exchange failure. As a result, the portal server does not display the authentication page.
Solution
•
Use the display portal server command to display the key for the portal server on the router and
view the key for the router on the portal server.
•
Use the portal server command to modify the key on the router or modify the key on the portal
server to make sure that the keys are consistent.
139
Incorrect server port number on the router (access device)
Symptom
After a user passes the portal authentication, you cannot force the user to log out by executing the portal
delete-user command on the router, but the user can log out by using the disconnect attribute on the
authentication client.
Analysis
When you execute the portal delete-user command on the router to force the user to log out, the router
actively sends a REQ_LOGOUT message to the portal server. The default listening port of the portal
server is 50100. However, if the listening port configured on the router is not 50100, the destination port
of the REQ_LOGOUT message is not the actual listening port on the server. Thus, the portal server cannot
receive the REQ_LOGOUT message. As a result, you cannot force the user to log out the portal server.
When the user uses the disconnect attribute on the client to log out, the portal server actively sends a
REQ_LOGOUT message to the router. The source port is 50100 and the destination port of the
ACK_LOGOUT message from the router is the source port of the REQ_LOGOUT message so that the
portal server can receive the ACK_LOGOUT message correctly, no matter whether the listening port is
configured on the router. Therefore, the user can log out the portal server.
Solution
Use the display portal server command to display the listening port of the portal server on the router and
use the portal server command in the system view to modify it to make sure that it is the actual listening
port of the portal server.
140
Configuring password control
Overview
Password control refers to a set of functions provided by the local authentication server to control user
login passwords, super passwords, and user login status based on predefined policies. The rest of this
section describes the password control functions in detail.
•
Minimum password length
By setting a minimum password length, you can enforce users to use passwords long enough for
system security. If a user specifies a shorter password, the system rejects the setting and prompts
the user to re-specify a password.
•
Minimum password update interval
This function allows you to set the minimum interval at which users can change their passwords. If
a non-manage level user logs in to change the password but the time that elapses since the last
change is less than this interval, the system denies the request. For example, if you set this interval
to 48 hours, a non-manage level user cannot change the password twice within 48 hours. This
prevents users from changing their passwords frequently.
This function is not effective on users of the manage level. For information about user levels, see
Fundamentals Configuration Guide.
This function is not effective on a user who is prompted to change the password at the first login or
a user whose password has just been aged out.
•
Password aging
Password aging imposes a lifecycle on a user password. After the password aging time expires,
the user needs to change the password.
If a user enters an expired password when logging in, the system displays an error message and
prompts the user to provide a new password and to confirm it by entering it again. The new
password must be a valid one and the user must enter exactly the same password when confirming
it.
•
Early notice on pending password expiration
When a user logs in, the system checks whether the password will expire in a time equal to or less
than the specified period. If so, the system notifies the user of the expiration time and provides a
choice for the user to change the password. If the user provides a new password that is
complexity-compliant, the system records the new password and the time. If the user chooses to
leave the password or the user fails to change it, the system allows the user to log in using the
current password.
Telnet, SSH, and terminal users, who log in to the device through a console or AUX port, can
change their passwords by themselves. However, FTP users can only have their passwords
changed by the administrator.
•
Login with an expired password
You can allow a user to log in a certain number of times within a specific period of time after the
password expires, so that the user does not need to change the password immediately. For
example, if you set the maximum number of logins with an expired password to 3 and the time
period to 15 days, a user can log in three times within 15 days after the password expires.
141
•
Password history
With this feature enabled, the system maintains certain entries of passwords that a user has used.
When a user changes the password, the system checks the new password against the used ones
to see whether it was used before and, if so, displays an error message. In addition, the new
password must be different from any used ones by at least four characters and the four characters
must not be the same. Otherwise, the user will fail to change the password and the system displays
an error message.
You can set the maximum number of history password records for the system to maintain for each
user. When the number of history password records exceeds your setting, the latest record will
overwrite the earliest one.
•
Login attempt limit
Limiting the number of consecutive failed login attempts can effectively prevent password
guessing.
If an FTP or virtual terminal line (VTY) user fails authentication due to a password error, the system
adds the user to a password control blacklist. If a user fails to provide the correct password after
the specified number of consecutive attempts, the system takes action as configured:
{
{
{
Prohibiting the user from logging in until the user is removed from the blacklist manually.
Allowing the user to try continuously and removing the user from the password control blacklist
when the user logs in to the system successfully or the blacklist entry times out (the blacklist entry
aging time is 1 minute).
Prohibiting the user from logging in within a configurable period of time, and allowing the user
to log in again after the period of time elapses or the user is removed from the password control
blacklist.
A password control blacklist can contain up to 1024 entries.
A login attempt using a wrong username will undoubtedly fail but the username will not be added
to the password control blacklist.
Web users failing login authentication are not added to the password control. Users accessing the
system through the Console or AUX interface are not added to the password control either,
because the system is unable to obtain the IP addresses of these users and these users are
privileged and therefore relatively secure to the system.
•
Password composition checking
A password can be a combination of characters from the following four types:
{
Uppercase letters A to Z
{
Lowercase letters a to z
{
Digits 0 to 9
{
Special characters. For information about special characters, see the password-control
composition command in Security Command Reference.
Depending on the system security requirements, you can set the minimum number of types a
password must contain and the minimum number of characters that are from each type in the
password.
There are four password combination levels in non-FIPS mode: 1, 2, 3, and 4, each representing
the number of character types that a password must at least contain. Level 1 means that a
password must contain characters of one type, level 2 at least two types, and so on.
In FIPS mode, a password must contain four types of characters and each type contains at least
one character. For more information about the FIPS mode, see "Configuring FIPS."
142
When a user sets or changes the password, the system checks if the password meets the
composition requirement. If not, the system displays an error message.
•
Password complexity checking
A less complicated password such as a password containing the username or repeated characters
is more likely to be cracked. For security purposes, you can configure a password complexity
checking policy to make sure that all user passwords are relatively complicated. With such a
policy configured, when a user configures a password, the system checks the complexity of the
password. If the password is complexity-incompliant, the system refuses the password and
displays a password configuration failure message.
You can impose the following password complexity requirements:
{
{
•
A password cannot contain the username or the reverse of the username. For example, if the
username is abc, a password such as abc982 or 2cba is not complex enough.
No character of the password is repeated three or more times consecutively. For example,
password a111 is not complex enough.
Password display in the form of a string of asterisks (*)
For the sake of security, the password a user enters is displayed in the form of a string of asterisks
(*).
•
Authentication timeout management
The authentication period is from when the server obtains the username to when the server finishes
authenticating the user's password. If a Telnet or terminal user fails to log in within the configured
period of time, the system tears down the connection.
•
Maximum account idle time
You can set the maximum account idle time to make accounts staying idle for this period of time
become invalid and unable to log in again. For example, if you set the maximum account idle time
to 60 days and user using the account test has never logged in successfully within 60 days after
the last successful login, the account becomes invalid.
•
Logging
The system logs all successful password changing events and user blacklisting events due to login
failures.
FIPS compliance
The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for features,
commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and non-FIPS mode.
Password control configuration task list
The password control functions can be configured in several views, and different views support different
functions. The settings configured in different views or for different objects have different application
ranges and different priorities:
•
Global settings in system view apply to all local user passwords and super passwords.
•
Settings in user group view apply to the passwords of all local users in the user group.
•
Settings in local user view apply to only the password of the local user.
•
Settings for super passwords apply to only super passwords.
143
The above four types of settings have different priorities:
•
For local user passwords, the settings with a smaller application range have higher priority.
•
For super passwords, the settings configured specifically for super passwords, if any, override those
configured in system view.
Complete the following tasks to configure password control:
Task
Remarks
Enabling password control
Required.
Setting global password control parameters
Optional.
Setting user group password control parameters
Optional.
Setting local user password control parameters
Optional.
Setting super password control parameters
Optional.
Setting a local user password in interactive mode
Optional.
Configuring password control
Enabling password control
To enable password control functions, you need to:
1.
Enable the password control feature in system view. Password control configurations take effect
only after the password control feature is enabled globally.
2.
Enable password control functions. Some password control functions need to be enabled
individually after the password control feature is enabled globally. These functions include:
{
Password aging
{
Minimum password length
{
Password history
{
Password composition checking
You must enable a function for its relevant configurations to take effect.
After global password control is enabled, local user passwords configured on the device are not
displayed when you use the corresponding display commands.
To enable password control:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the password control
feature.
password-control enable
By default, the global password
control feature is disabled.
3.
Enable a specific password
control function.
password-control { aging |
composition | history | length }
enable
144
Optional.
By default, all four password
control functions are enabled.
Setting global password control parameters
The settings in system view have global significance and apply to all device management users. The
password aging time, minimum password length, and password composition policy can be configured
in system view, user group view, or local user view, and these settings with a smaller application scope
have a higher priority.
The password-control login-attempt command takes effect immediately and can thus affect the users
already in the password control blacklist. Other password control configurations do not take effect for
users that have been logged in or passwords that have been configured.
To set global password control parameters:
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Set the password aging time.
password-control aging aging-time
3.
Set the minimum password
update interval.
password-control password
update interval interval
Set the minimum password
length.
password-control length length
4.
Optional.
The default setting is 90 days.
Optional.
The default setting is 24 hours.
Optional.
The default setting is 10
characters.
Optional.
• In non-FIPS mode, by default, a
5.
Configure the password
composition policy.
password-control composition
type-number type-number
[ type-length type-length ]
password must contain at least
one type of characters and
each type must contain at least
one character.
• In FIPS mode, by default, a
password must contain four
types of characters and each
type must contain at least one
character.
6.
Configure the password
complexity checking policy.
password-control complexity
{ same-character | user-name }
check
7.
Set the maximum number of
history password records for
each user.
password-control history
max-record-num
8.
Specify the maximum number
of login attempts and the
action to be taken when a
user fails to log in after the
specified number of attempts.
Optional.
By default, the system does not
perform password complexity
checking.
Optional.
The default setting is 4.
Optional.
password-control login-attempt
login-times [ exceed { lock |
lock-time time | unlock } ]
145
By default, the maximum number
of login attempts is 3 and a user
failing to log in after the specified
number of attempts must wait for 1
minute before trying again.
Step
9.
Set the number of days during
which the user is notified of
the pending password
expiration.
Command
Remarks
password-control
alert-before-expire alert-time
Optional.
The default setting is 7 days.
Optional.
10. Set the maximum number of
days and maximum number
of times that a user can log in
after the password expires.
password-control
expired-user-login delay delay
times times
11. Set the authentication timeout
time.
password-control
authentication-timeout
authentication-timeout
Optional.
12. Set the maximum account idle
time.
password-control login idle-time
idle-time
Optional.
By default, a user can log in three
times within 30 days after the
password expires.
The default setting is 60 seconds.
The default setting is 90 days.
Setting user group password control parameters
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a user group and enter
user group view.
user-group group-name
N/A
3.
Configure the password
aging time for the user group.
4.
Configure the minimum
password length for the user
group.
Optional.
password-control aging aging-time
By default, the aging time of the
user group is the same as the
global password aging time.
Optional.
password-control length length
By default, the minimum password
length of the user group is the same
as the global minimum password
length.
Optional.
5.
Configure the password
composition policy for the
user group.
password-control composition
type-number type-number
[ type-length type-length ]
By default, the password
composition policy of the user
group is the same as the global
password composition policy.
Setting local user password control parameters
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a local user and enter
local user view.
local-user user-name
N/A
146
Step
Command
Remarks
Optional.
3.
Configure the password
aging time for the local user.
password-control aging aging-time
By default, the setting equals that
for the user group to which the
local user belongs. If no aging time
is configured for the user group,
the global setting applies to the
local user.
Optional.
4.
Configure the minimum
password length for the local
user.
password-control length length
By default, the setting equals that
for the user group to which the
local user belongs. If no minimum
password length is configured for
the user group, the global setting
applies to the local user.
Optional.
5.
Configure the password
composition policy for the
local user.
password-control composition
type-number type-number
[ type-length type-length ]
By default, the settings equal those
for the user group to which the
local user belongs. If no password
composition policy is configured
for the user group, the global
settings apply to the local user.
Setting super password control parameters
CLI commands are executed in four levels: visit, monitor, system, and manage, in ascending order.
Accordingly, login users are divided into four levels, each corresponding to a command level. A user of
a certain level can only use the commands at that level or lower levels.
To switch from a lower user level to a higher one, a user needs to enter a password for authentication.
This password is called a super password. For more information about super passwords, see
Fundamentals Configuration Guide.
To set super password control parameters:
Step
Command
Remarks
system-view
N/A
1.
Enter system view.
2.
Set the password aging time
for super passwords.
password-control super aging
aging-time
3.
Configure the minimum length
for super passwords.
password-control super length
length
Optional.
By default, the super password
aging time is the same as the
global password aging time.
Optional.
147
By default, the minimum super
password length is the same as the
global minimum password length.
Step
4.
Command
Configure the password
composition policy for super
passwords.
Remarks
password-control super
composition type-number
type-number [ type-length
type-length ]
Optional.
By default, the super password
composition policy is the same as
the global password composition
policy.
Setting a local user password in interactive mode
You can set a password for a local user in interactive mode. When doing so, you need to confirm the
password.
To set a password for a local user in interactive mode:
Step
Command
1.
Enter system view.
system-view
2.
Create a local user and enter local user view.
local-user user-name
3.
Set the password for the local user in interactive
mode.
password
Displaying and maintaining password control
Task
Command
Remarks
Display password control
configuration.
display password-control [ super ]
[ | { begin | exclude | include }
regular-expression ]
Available in any view.
Display information about users in
the password control blacklist.
display password-control blacklist
[ user-name name | ip
ipv4-address | ipv6 ipv6-address ]
[ | { begin | exclude | include }
regular-expression ]
Available in any view.
Delete users from the password
control blacklist.
reset password-control blacklist
{ all | user-name name }
Available in user view.
Available in user view.
Clear history password records.
reset password-control
history-record [ user-name name |
super [ level level ] ]
148
The reset password-control
history-record command can
delete the history password
records of one or all users even
when the password history
function is disabled.
Password control configuration example
Network requirements
Implementing the following global password control policy:
•
An FTP or VTY user failing to provide the correct password in two successive login attempts is
permanently prohibited from logging in.
•
A user can log in five times within 60 days after the password expires.
•
The password aging time is 30 days.
•
The minimum password update interval is 36 hours.
•
The maximum account idle time is 30 days.
•
A password cannot contain the username or the reverse of the username.
•
No character occurs consecutively three or more times in a password.
Implementing the following super password control policy:
A super password must contain at least three types of valid characters, five or more of each type.
Implementing the following password control policy for local Telnet user test:
•
The password must contain at least 12 characters.
•
The password must consist of at least two types of valid characters, five or more of each type.
•
The password aging time is 20 days.
Configuration procedure
# Enable the password control feature globally.
<Sysname> system-view
[Sysname] password-control enable
# Prohibit the user from logging in forever after two successive login failures.
[Sysname] password-control login-attempt 2 exceed lock
# Set the password aging time to 30 days for all passwords.
[Sysname] password-control aging 30
# Set the minimum password update interval to 36 hours.
[Sysname] password-control password update interval 36
# Specify that a user can log in five times within 60 days after the password expires.
[Sysname] password-control expired-user-login delay 60 times 5
# Set the maximum account idle time to 30 days.
[Sysname] password-control login idle-time 30
# Refuse any password that contains the username or the reverse of the username.
[Sysname] password-control complexity user-name check
# Specify that no character of the password can be repeated three or more times consecutively.
[Sysname] password-control complexity same-character check
# Specify that a super password must contain at least three types of characters and each type must
contain at least five characters.
[Sysname] password-control super composition type-number 3 type-length 5
# Configure a super password.
149
[Sysname] super password level 3 simple 12345ABGFTweuix
# Create a local user named test.
[Sysname] local-user test
# Set the service type of the user to Telnet.
[Sysname-luser-test] service-type telnet
# Set the minimum password length to 12 for the local user.
[Sysname-luser-test] password-control length 12
# Specify that the password of the local user must contain at least two types of characters and each type
must contain at least five characters.
[Sysname-luser-test] password-control composition type-number 2 type-length 5
# Set the password aging time to 20 days for the local user.
[Sysname-luser-test] password-control aging 20
# Configure the password of the local user in interactive mode.
[Sysname-luser-test] password
Password:***********
Confirm :***********
Updating user(s) information, please wait........
[Sysname-luser-test] quit
Verifying the configuration
# Display the global password control configuration.
<Sysname> display password-control
Global password control configurations:
Password control:
Enabled
Password aging:
Enabled (30 days)
Password length:
Enabled (10 characters)
Password composition:
Enabled (1 types,
Password history:
Enabled (max history record:4)
1 characters per type)
Early notice on password expiration: 7 days
User authentication timeout:
60 seconds
Maximum failed login attempts:
2 times
Login attempt-failed action:
Lock
Minimum password update time:
36 hours
User account idle-time:
30 days
Login with aged password:
5 times in 60 day(s)
Password complexity:
Enabled (username checking)
Enabled (repeated characters checking)
# Display the password control configuration for super passwords.
<Sysname> display password-control super
Super password control configurations:
Password aging:
Enabled (30 days)
Password length:
Enabled (10 characters)
Password composition:
Enabled (3 types,
# Display the password control configuration for local user test.
<Sysname> display local-user user-name test
The contents of local user test:
150
5 characters per type)
State:
Active
ServiceType:
telnet
Access-limit:
Disable
User-group:
system
Current AccessNum: 0
Bind attributes:
Authorization attributes:
Password aging:
Enabled (20 days)
Password length:
Enabled (12 characters)
Password composition:
Enabled (2 types,
Total 1 local user(s) matched.
151
5 characters per type)
Managing public keys
Overview
To protect data confidentiality during transmission, the data sender uses an algorithm and a key to
encrypt the plain text data before sending the data out, and the receiver uses the same algorithm with the
help of a key to decrypt the data, as shown in Figure 56.
Figure 56 Encryption and decryption
The keys that participate in the conversion between the plain text and the cipher text can be the same or
different, dividing the encryption and decryption algorithms into the following types:
•
Symmetric key algorithm—The keys for encryption and decryption are the same.
•
Asymmetric key algorithm—The keys for encryption and decryption are different, one is the public
key, and the other is the private key. The information encrypted with the public key can only be
decrypted with the corresponding private key, and vice versa. The private key is kept secret, and the
public key may be distributed widely. The private key cannot be practically derived from the public
key. Asymmetric key algorithms include the Revest-Shamir-Adleman Algorithm (RSA), the Digital
Signature Algorithm (DSA), and the Elliptic Curve Digital Signature Algorithm (ECDSA).
The asymmetric key algorithms can be used for the following purposes:
•
To encrypt and decrypt data—Any public key receiver can use the public key to encrypt information,
but only the private key owner can decrypt the information. This mechanism ensures confidentiality.
Only RSA can be used for data encryption and decryption.
•
To authenticate a sender—Also called digital signature. The key owner uses the private key to
"sign" information to be sent, and the receiver decrypts the information with the sender’s public key
to verify information authenticity. RSA, DSA, and ECDSA can be used for digital signature.
Asymmetric key algorithms are widely used in various applications. For example, Secure Shell (SSH) and
Public Key Infrastructure (PKI) use the algorithms for digital signature. For information about SSH and PKI,
see "Configuring SSH" and "Configuring PKI."
NOTE:
The router does not support ECDSA.
FIPS compliance
The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for features,
commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and non-FIPS mode.
152
Public key configuration task list
Public key configuration tasks enable you to manage the local asymmetric key pairs and configure the
peer host public keys on the local device. By completing these tasks, the local device is ready to work
with applications such as SSH and SSL to implement data encryption/decryption, or digital signature.
Complete these tasks to configure public keys:
Task
Remarks
Configuring a local
asymmetric key pair on the
local device
Creating a local asymmetric key pair
Displaying or exporting the local host public key
Destroying a local asymmetric key pair
Choose one or more
tasks.
Specifying the peer public key on the local device
Configuring a local asymmetric key pair on the
local device
Creating a local asymmetric key pair
Configuration guidelines
When you create an asymmetric key pair on the local device, follow these guidelines:
•
Create an asymmetric key pair of the proper type to work with a target application.
•
After you enter the command, specify a proper modulus length for the key pair. The following table
compares these types of key pairs.
Table 7 A comparison between different types of asymmetric key pairs
Type
Number of key pairs
Modulus length
• In non-FIPS mode: 512 to
RSA
Two key pairs, one server key
pair and one host key pair.
Each key pair comprises a
public key and a private key.
2048 bits and defaults to
1024 bits.
• In FIPS mode: 2048 bits.
• In non-FIPS mode: 512 to
DSA
One key pair, the host key pair.
Remarks
2048 bits and defaults to
1024 bits.
• In FIPS mode: 1024 to 2048
bits and defaults to 1024 bits.
NOTE:
Only SSH1.5 uses the RSA server key pair.
Configuration procedure
To create a local asymmetric key pair:
153
To achieve high
security, specify at least
768 bits.
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Create a local asymmetric
key pair.
public-key local create
{ dsa | ecdsa | rsa }
By default, no asymmetric key pair is created.
The router does not support the ecdsa
keyword.
NOTE:
Key pairs created with the public-key local create command are saved automatically and can survive
system reboots.
Displaying or exporting the local host public key
In some applications, such as SSH, to allow your local device to be authenticated by a peer device
through digital signature, you must display or export the local host public key, which will then be
specified on the peer device.
To display or export the local host public key, choose one of the following methods:
•
Displaying and recording the host public key information
•
Displaying the host public key in a specific format and saving it to a file
•
Exporting the host public key in a specific format to a file
If your local device functions to authenticate the peer device, you must specify the peer public key on the
local device. For more information, see "Specifying the peer public key on the local device."
Displaying and recording the host public key information
After you display the host public key, record the key information for manually configuration of the key on
the peer device.
To display the local public key:
Task
Command
Remarks
Display the local RSA public keys
display public-key local rsa public [ | { begin
| exclude | include } regular-expression ]
Available in any view.
Display the local DSA host public
key.
display public-key local dsa public [ | { begin
| exclude | include } regular-expression ]
Use at least one
command..
NOTE:
The display public-key local rsa public command displays both the RSA server and host public keys.
Recording the RSA host public key is enough.
Displaying the host public key in a specific format and saving it to a file
After you display the host public key in a specific format, save the key to a file, and transfer this file to the
peer device.
To display the local host public key in a specific format:
154
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Display the RSA host public key:
2.
Display the local host public
key in a specific format.
public-key local export rsa
{ openssh | ssh1 | ssh2 }
Use at least one command.
• Display the DSA host public key:
public-key local export dsa
{ openssh | ssh2 }
The ssh1 keyword is not
available for FIPS mode.
Exporting the host public key in a specific format to a file
After you export a host public key in a specify format to a file, transfer the file to the peer device.
To export a local host public key in a specific format to a file:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Export the RSA host public key:
2.
Export the local host public
key in a specific format to a
file.
public-key local export rsa
{ openssh | ssh1 | ssh2 }
filename
Use at least one command.
• Export the DSA host public key:
public-key local export dsa
{ openssh | ssh2 } filename
The ssh1 keyword is not available
for FIPS mode.
Destroying a local asymmetric key pair
You may need to destroy a local asymmetric key pair and generate a new pair when an intrusion event
has occurred, the storage media of the device is replaced, the asymmetric key has been used for a long
time, the local certificate expires, or mode changes between FIPS and non-FIPS. The key pairs generated
in FIPS mode cannot be used in non-FIPS mode, and vice versa. For more information about the local
certificate, see "Configuring PKI."
To destroy a local asymmetric key pair:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Destroy a local asymmetric
key pair.
public-key local destroy { dsa |
ecdsa | rsa }
The router does not support the
ecdsa keyword.
Specifying the peer public key on the local device
In SSH, to enable the local device to authenticate a peer device, specify the peer public key on the local
device. Take one of the following methods:
Method
Prerequisites
Remarks
155
Method
Import the public key
from a public key file
(recommended)
Prerequisites
Remarks
1.
Save the host public key of the intended
asymmetric key pair in a file.
2.
Transfer a copy of the file through FTP
or TFTP in binary mode to the local
device.
• Display and record the public key of the
intended asymmetric key pair.
Manually configure
the public key—input
or copy the key data
• If the peer device is an HP device, use the
display public-key local public
command to view and record its public
key. A public key displayed by other
methods for the HP device may not be in
a correct format.
During the import process, the system
automatically converts the public key to
a string in Public Key Cryptography
Standards (PKCS) format.
• The recorded public key must be in
the correct format, or the manual
configuration of a
format-incompliant public key will
fail.
• Always use the first method if you
are not sure about the format of the
recorded public key.
NOTE:
• The device supports up to 20 peer public keys.
• For information about displaying or exporting the host public key, see "Displaying or exporting the
local host public key."
To import the host public key from a public key file to the local device:
Step
Command
1.
Enter system view.
system-view
2.
Import the host public key from the public key file.
public-key peer keyname import sshkey filename
To manually configure the peer public key on the local device:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify a name for the public
key and enter public key view.
public-key peer keyname
N/A
3.
Enter public key code view.
public-key-code begin
N/A
4.
Configure the peer public key.
Type or copy the key
Spaces and carriage returns are allowed
between characters.
5.
Return to public key view.
public-key-code end
When you exit public key code view, the
system automatically saves the public key.
6.
Return to system view.
peer-public-key end
N/A
Displaying and maintaining public keys
Task
Command
Remarks
Display the local public keys
display public-key local { dsa | ecdsa | rsa } public [ |
{ begin | exclude | include } regular-expression ]
Available in any
view.
156
Task
Command
Remarks
Display the specified or all peer
public keys on the local device.
display public-key peer [ brief | name
publickey-name ] [ | { begin | exclude | include }
regular-expression ]
Available in any
view.
Public key configuration examples
Manually specifying the peer public key on the local router
Network requirements
As shown in Figure 57, to prevent illegal access, Router B (the local device) authenticates Router A (the
peer device) through a digital signature. Before configuring authentication parameters on Router B,
configure the public key of Router A on Router B.
•
Configure Router B to use the asymmetric key algorithm of RSA to authenticate Router A.
•
Manually specify the host public key of Router A's public key pair on Router B.
Figure 57 Network diagram
Configuration procedure
1.
Configure Router A:
# Create local RSA key pairs on Router A, setting the modulus length to the default, 1024 bits.
<RouterA> system-view
[RouterA] public-key local create rsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++
++++++
++++++++
++++++++
# Display the public keys of the local RSA key pairs.
[RouterA] display public-key local rsa public
=====================================================
Time of Key pair created: 09:50:06
2007/08/07
Key name: HOST_KEY
Key type: RSA Encryption Key
=====================================================
157
Key code:
30819F300D06092A864886F70D010101050003818D0030818902818100D90003FA95F5A44A2A2CD3F
814F
9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD
995C
669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA326470034DC07
8B2B
AA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A10203010001
=====================================================
Time of Key pair created: 09:50:07
2007/08/07
Key name: SERVER_KEY
Key type: RSA Encryption Key
=====================================================
Key code:
307C300D06092A864886F70D0101010500036B003068026100999089E7AEE9802002D9EB2D0433B87
BB61
58E35000AFB3FF310E42F109829D65BF70F7712507BE1A3E0BC5C2C03FAAF00DFDDC63D004B4490DA
CBA3
CFA9E84B9151BDC7EECE1C8770D961557D192DE2B36CAF9974B7B293363BB372771C2C1F020301000
1
2.
Configure Router B:
# Configure the host public key of Router A's RSA key pairs on Router B. In public key code view,
input the host public key of Router A. The host public key is the content of HOST_KEY displayed on
Router A by using the display public-key local dsa public command.
<RouterB> system-view
[RouterB] public-key peer routera
Public key view: return to System View with "peer-public-key end".
[RouterB-pkey-public-key] public-key-code begin
Public key code view: return to last view with "public-key-code end".
[RouterB-pkey-key-code]30819F300D06092A864886F70D010101050003818D0030818902818100
D900
03FA95F5A44A2A2CD3F814F9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E5
1E5E
353B3A9AB16C9E766BD995C669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62
DB12
5035EA326470034DC078B2BAA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A
1020
3010001
[RouterB-pkey-key-code] public-key-code end
[RouterB-pkey-public-key] peer-public-key end
# Display the host public key of Router A saved on Router B.
[RouterB] display public-key peer name routera
=====================================
Key Name
: routera
Key Type
: RSA
Key Module: 1024
=====================================
Key Code:
158
30819F300D06092A864886F70D010101050003818D0030818902818100D90003FA95F5A44A2A2CD3F
814F
9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD
995C
669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA326470034DC07
8B2B
AA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A10203010001
The output shows that the host public key of Router A saved on Router B is consistent with the one
created on Router A.
Importing a public key from a public key file
Network requirements
As shown in Figure 58, to prevent illegal access, Router B (the local router) authenticates Router A (the
peer router) through a digital signature. Before configuring authentication parameters on Router B,
configure the public key of Router A on Router B.
•
Configure Router B to use the asymmetric key algorithm of RSA to authenticate Router A.
•
Import the host public key of Router A from the public key file to Router B.
Figure 58 Network diagram
Configuration procedure
1.
Create key pairs on Router A and export the host public key.
# Create local RSA key pairs on Router A, setting the modulus length to the default, 1024 bits.
<RouterA> system-view
[RouterA] public-key local create rsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++
++++++
++++++++
++++++++
# Display the public keys of the local RSA key pairs.
[RouterA] display public-key local rsa public
=====================================================
Time of Key pair created: 09:50:06
2007/08/07
Key name: HOST_KEY
Key type: RSA Encryption Key
=====================================================
159
Key code:
30819F300D06092A864886F70D010101050003818D0030818902818100D90003FA95F5A44A2A2CD3F
814F
9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD
995C
669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA326470034DC07
8B2B
AA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A10203010001
=====================================================
Time of Key pair created: 09:50:07
2007/08/07
Key name: SERVER_KEY
Key type: RSA Encryption Key
=====================================================
Key code:
307C300D06092A864886F70D0101010500036B003068026100999089E7AEE9802002D9EB2D0433B87
BB61
58E35000AFB3FF310E42F109829D65BF70F7712507BE1A3E0BC5C2C03FAAF00DFDDC63D004B4490DA
CBA3
CFA9E84B9151BDC7EECE1C8770D961557D192DE2B36CAF9974B7B293363BB372771C2C1F020301000
1
# Export the RSA host public key HOST_KEY to a file named routera.pub.
[RouterA] public-key local export rsa ssh2 routera.pub
2.
Enable the FTP server function on Router A.
# Enable the FTP server function, create an FTP user with the username ftp, password 123, and
user level 3. This user level ensures that the user has the permission to perform FTP operations.
[RouterA] ftp server enable
[RouterA] local-user ftp
[RouterA-luser-ftp] password simple 123
[RouterA-luser-ftp] service-type ftp
[RouterA-luser-ftp] authorization-attribute level 3
[RouterA-luser-ftp] quit
3.
On Router B, get the public key file of Router A.
# From Router B, use FTP to log in to Router A, and get the public key file routera.pub with the file
transfer mode of binary.
<RouterB> ftp 10.1.1.1
Trying 10.1.1.1 ...
Press CTRL+K to abort
Connected to 10.1.1.1.
220 FTP service ready.
User(10.1.1.1:(none)):ftp
331 Password required for ftp.
Password:
230 User logged in.
[ftp] binary
200 Type set to I.
[ftp] get routera.pub
227 Entering Passive Mode (10,1,1,1,5,148).
125 BINARY mode data connection already open, transfer starting for /routera.pub.
160
226 Transfer complete.
FTP: 299 byte(s) received in 0.189 second(s), 1.00Kbyte(s)/sec.
[ftp] quit
221 Server closing.
4.
Import the host public key of Router A to Router B.
# Import the host public key of Router A from the key file routera.pub to Router B.
<RouterB> system-view
[RouterB] public-key peer routera import sshkey routera.pub
# Display the host public key of Router A on Router B.
[RouterB] display public-key peer name routera
=====================================
Key Name
: routera
Key Type
: RSA
Key Module: 1024
=====================================
Key Code:
30819F300D06092A864886F70D010101050003818D0030818902818100D90003FA95F5A44A2A2CD3F
814F
9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD
995C
669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA326470034DC07
8B2B
AA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A10203010001
The output shows that the host public key of Router A saved on Router B is consistent with the one
created on Router A.
161
Configuring IPsec
The term "router" in this document refers to both routers and Layer 3 switches.
Overview
IP Security (IPsec) is a security framework defined by the IETF for securing IP communications. It is a Layer
3 VPN technology that transmits data in a secure tunnel established between two endpoints.
IPsec provides the following security services in insecure network environments:
•
Confidentiality—The sender encrypts packets before transmitting them over the Internet, protecting
the packets from being eavesdropped en route.
•
Data integrity—The receiver verifies the packets received from the sender to make sure they are not
tampered with during transmission.
•
Data origin authentication—The receiver verifies the authenticity of the sender.
•
Anti-replay—The receiver examines packets and drops outdated and duplicate packets.
IPsec delivers the following benefits:
•
Reduced key negotiation overheads and simplified maintenance by supporting the IKE protocol.
IKE provides automatic key negotiation and automatic IPsec security association (SA) setup and
maintenance.
•
Good compatibility. You can apply IPsec to all IP-based application systems and services without
modifying them.
•
Encryption on a per-packet rather than per-flow basis. Per-packet encryption allows for flexibility
and greatly enhances IP security.
IPsec comprises a set of protocols, including Authentication Header (AH), Encapsulating Security
Payload (ESP), Internet Key Exchange (IKE), and algorithms for authentication and encryption. AH and
ESP provides security services and IKE performs automatic key exchange. For more information about IKE,
see "Configuring IKE."
Basic concepts
Security protocols
IPsec comes with the following security protocols:
•
AH (protocol 51)—Provides data origin authentication, data integrity, and anti-replay services by
adding an AH header to each IP packet. AH is suitable only for transmitting non-critical data
because it cannot prevent eavesdropping, although it can prevent data tampering. AH supports
authentication algorithms such as MD5 and SHA-1.
•
ESP (protocol 50)—Provides data encryption as well as data origin authentication, data integrity,
and anti-replay services by inserting an ESP header and an ESP trailer in IP packets. Unlike AH, ESP
encrypts data before encapsulating the data to guarantee data confidentiality. ESP supports
encryption algorithms such as DES, 3DES, and AES, and authentication algorithms such as MD5
and SHA-1. The authentication function is optional to ESP.
162
Both AH and ESP provide authentication services, but the authentication service provided by AH is
stronger. In practice, you can choose either or both security protocols. When both AH and ESP are used,
an IP packet is encapsulated first by ESP and then by AH. Figure 59 shows the format of IPsec packets.
Security association
A security association is an agreement negotiated between two communicating parties called IPsec
peers. It comprises a set of parameters for data protection, including security protocols, encapsulation
mode, authentication and encryption algorithms, and shared keys and their lifetime. SAs can be set up
manually or through IKE.
An SA is unidirectional. At least two SAs are needed to protect data flows in a bidirectional
communication. If two peers want to use both AH and ESP to protect data flows between them, they
construct an independent SA for each protocol.
An SA is uniquely identified by a triplet, which consists of the security parameter index (SPI), destination
IP address, and security protocol identifier (AH or ESP).
An SPI is a 32-bit number for uniquely identifying an SA. It is transmitted in the AH/ESP header. A
manually configured SA requires an SPI to be specified manually for it. An IKE-created SA will have an
SPI generated at random.
A manually configured SA never ages out. An IKE created SA has the following types of lifetime:
•
Time-based lifetime—Defines how long the SA can be valid after it is created.
•
Traffic-based lifetime—Defines the maximum traffic that the SA can process.
The SA becomes invalid when either of the lifetime timers expires. Before the SA expires, IKE negotiates
a new SA, which takes over immediately after its creation.
Encapsulation modes
IPsec supports the following IP packet encapsulation modes:
•
Tunnel mode—IPsec protects the entire IP packet, including both the IP header and the payload. It
uses the entire IP packet to calculate an AH or ESP header, and then encapsulates the original IP
packet and the AH or ESP header with a new IP header. If you use ESP, an ESP trailer is also
encapsulated. Tunnel mode is typically used for protecting gateway-to-gateway communications.
•
Transport mode—IPsec protects only the IP payload. It uses only the IP payload to calculate the AH
or ESP header, and inserts the calculated header between the original IP header and payload. If
you use ESP, an ESP trailer is also encapsulated. The transport mode is typically used for protecting
host-to-host or host-to-gateway communications.
Figure 59 shows how the security protocols encapsulate an IP packet in different encapsulation modes.
Figure 59 Encapsulation by security protocols in different modes
Authentication algorithms and encryption algorithms
1.
Authentication algorithms:
163
IPsec uses hash algorithms to perform authentication. A hash algorithm produces a fixed-length
digest for an arbitrary-length message. IPsec peers respectively calculate message digests for each
packet. If the resulting digests are identical, the packet is considered intact.
IPsec supports the following hash algorithms for authentication:
{
{
MD5—Takes a message of arbitrary length as input and produces a 128-bit message digest.
SHA-1—Takes a message of a maximum length less than the 64th power of 2 in bits as input
and produces a 160-bit message digest.
Compared with SHA-1, MD5 is faster but less secure.
2.
Encryption algorithms:
IPsec mainly uses symmetric encryption algorithms, which encrypt and decrypt data by using the
same keys. The following encryption algorithms are available for IPsec on the device:
{
{
{
DES—Encrypts a 64-bit plain text block with a 56-bit key. DES is the least secure but the fastest
algorithm. It is sufficient for general security requirements.
3DES—Encrypts plain text data with three 56-bit DES keys. The key length totals up to 168 bits.
It provides moderate security strength and is slower than DES.
AES—Encrypts plain text data with a 128-bit, 192-bit, or 256-bit key. AES provides the highest
security strength and is slower than 3DES.
IPsec SA setup modes
An IPsec SA can be set up in one of the following modes:
•
Manual mode—In this mode, you manually configure and maintain all SA settings. Advanced
features like periodical key update are not available. However, this mode implements IPsec
independently of IKE.
•
ISAKMP mode—In this mode, IKE automatically negotiates and maintains IPsec SAs for IPsec. This
mode is available only for FIPS mode.
If the number of IPsec tunnels in your network is small, use the manual mode. If the number of IPsec
tunnels is large, use the ISAKMP mode.
IPsec tunnel
An IPsec tunnel is a bidirectional channel created between two peers. An IPsec tunnel comprises one or
more pairs of SAs.
IPsec for IPv6 routing protocols
You can use IPsec to protect routing information and defend against attacks for these IPv6 routing
protocols: OSPFv3, IPv6 BGP, and RIPng. IPsec enables these IPv6 routing protocols to encapsulate
outbound protocol packets and de-encapsulate inbound protocol packets with the AH or ESP protocol.
If an inbound protocol packet is not IPsec protected, or fails to be de-encapsulated, for example, due to
decryption or authentication failure, the routing protocol discards that packet.
You must manually configure SA parameters in an IPsec policy for IPv6 routing protocols. The IKE key
exchange mechanism is applicable only to one-to-one communications. IPsec cannot implement
automatic key exchange for one-to-many communications on a broadcast network, where routers must
use the same SA parameters (SPI and key) to process packets for a routing protocol.
164
Protocols and standards
Protocols and standards relevant to IPsec are as follows:
•
RFC 2401, Security Architecture for the Internet Protocol
•
RFC 2402, IP Authentication Header
•
RFC 2406, IP Encapsulating Security Payload
•
RFC 4552, Authentication/Confidentiality for OSPFv3
•
RFC4301, Security Architecture for the Internet Protocol
•
RFC4302, IP Authentication Header
•
RFC4303, IP Encapsulating Security Payload (ESP)
FIPS compliance
The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for features,
commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and non-FIPS mode.
Implementing IPsec
IPsec can be implemented based on ACLs, tunnel interfaces, or applications:
•
ACL-based IPsec uses ACLs to identify the data flows to be protected. To implement ACL-based IPsec,
configure IPsec policies, reference ACLs in the policies, and apply the policies to physical interfaces
(see "Implementing ACL-based IPsec"). By using ACLs, you can customize IPsec policies as needed,
implementing IPsec flexibly.
•
Application-based IPsec protects the packets of a service. This IPsec implementation method can be
used to protect IPv6 routing protocols. It does not require any ACL, nor does it depend on the
routing mechanism. To configure service-based IPsec, configure manual IPsec policies and bind the
policies to an IPv6 routing protocol. See "Configuring IPsec for IPv6 routing protocols."
ACL-based IPsec and routing-based IPsec are available for both IPv4 and IPv6 packets, and the
configuration procedures are the same for IPv4 and IPv6.
Implementing ACL-based IPsec
This feature is available only for FIPS mode.
Feature restrictions and guidelines
ACLs for IPsec take effect only on traffic that is generated by the device and traffic that is destined for the
device. They do not take effect on traffic forwarded through the device. For example, an ACL-based IPsec
tunnel can protect log messages the device sends to a log server, but it cannot protect the data flows and
voice flows that are forwarded by the device. For more information about configuring an ACL for IPsec,
see "Configuring an ACL."
Typically, IKE uses UDP port 500 for communication, and AH and ESP use the protocol numbers 51 and
50. Make sure traffic of these protocols is not denied on the interfaces with IKE or IPsec configured.
165
ACL-based IPsec configuration task list
The following is the generic configuration procedure for implementing ACL-based IPsec:
1.
Configure an ACL for identifying data flows to be protected.
2.
Configure IPsec transform sets to specify the security protocols, and authentication and encryption
algorithms.
3.
Configure an IPsec policy group to associate data flows with the IPsec transform sets and specify
the SA negotiation mode, the peer IP addresses (the start and end points of the IPsec path), the
required keys, and the SA lifetime.
4.
Apply the IPsec policies to interfaces to finish IPsec configuration.
Complete the following tasks to configure ACL-based IPsec:
Task
Remarks
Configuring an ACL
Configuring an IPsec transform set
Required.
Configuring an IPsec policy
Basic IPsec configuration.
Applying an IPsec policy group to an interface
Configuring the IPsec session idle timeout
Optional.
Enabling ACL checking for de-encapsulated IPsec packets
Optional.
Configuring the IPsec anti-replay function
Optional.
Configuring packet information pre-extraction
Optional.
Enabling invalid SPI recovery
Optional.
Configuring an ACL
ACLs can be used to identify traffic. They are widely used in scenarios where traffic identification is
desired, such as QoS and IPsec.
Keywords in ACL rules
IPsec uses ACLs to identify data flows. An ACL is a collection of ACL rules. Each ACL rule is a deny or
permit statement. A permit statement identifies a data flow protected by IPsec, and a deny statement
identifies a data flow that is not protected by IPsec. With IPsec, a packet is matched against the
referenced ACL rules and processed according to the first rule that it matches:
•
Each ACL rule matches both the outbound traffic and the returned inbound traffic..
•
In the outbound direction, if a permit statement is matched, IPsec considers that the packet requires
protection and continues to process it. If a deny statement is matched or no match is found, IPsec
considers that the packet does not require protection and delivers it to the next function module.
•
In the inbound direction:
{
{
Non-IPsec packets that match a permit statement are dropped.
IPsec packets that match a permit statement and are destined for the device itself are
de-encapsulated and matched against the rule again. Only those that match a permit statement
are processed by IPsec.
166
When defining ACL rules for IPsec, follow these guidelines:
•
Permit only data flows that need to be protected and use the any keyword with caution. With the
any keyword specified in a permit statement, all outbound traffic matching the permit statement will
be protected by IPsec and all inbound IPsec packets matching the permit statement will be received
and processed, but all inbound non-IPsec packets will be dropped. This will cause the inbound
traffic that does not need IPsec protection to be all dropped.
•
Avoid statement conflicts in the scope of IPsec policy groups. When creating a deny statement, be
careful with its matching scope and matching order relative to permit statements. The policies in an
IPsec policy group have different match priorities. ACL rule conflicts between them are prone to
cause mistreatment of packets. For example, when configuring a permit statement for an IPsec
policy to protect an outbound traffic flow, you must avoid the situation that the traffic flow matches
a deny statement in a higher priority IPsec policy. Otherwise, the packets will be sent out as normal
packets. If they match a permit statement at the receiving end, they will be dropped by IPsec.
•
In an IPsec policy, the device supports configuring only one ACL. Make sure to configure all rules in
one ACL for the IPsec policy to reference.
Configuring ACL rules
To make sure that SAs can be set up and the traffic protected by IPsec can be processed correctly at the
remote peer, on the remote peer, create a mirror image ACL rule for each ACL rule created at the local
peer.
If the ACL rules on peers do not form mirror images of each other, SAs can be set up only when both of
the following requirements are met:
•
The range specified by an ACL rule on one peer is covered by its counterpart ACL rule on the other
peer.
•
The peer with the narrower rule initiates SA negotiation. If a wider ACL rule is used by the SA
initiator, the negotiation request might be rejected because the matching traffic is beyond the scope
of the responder.
Protection mode
Data flows can be protected in standard mode, where one tunnel protects one data flow. The data flow
permitted by an ACL rule is protected by one tunnel that is established solely for it. The standard data
flow protection mode is available only for FIPS mode.
For more information about ACL configuration, see ACL and QoS Configuration Guide.
To use IPsec in combination with QoS, make sure that IPsec's ACL classification rules match the QoS
classification rules. If the rules do not match, QoS may classify the packets of one IPsec SA to different
queues, causing packets to be sent out of order. When the anti-replay function is enabled, IPsec will
discard the packets beyond the anti-replay window in the inbound direction, resulting in packet loss. For
more information about QoS classification rules, see ACL and QoS Configuration Guide.
Configuring an IPsec transform set
An IPsec transform set, part of an IPsec policy, defines the security parameters for IPsec SA negotiation,
including the security protocol, and the encryption and authentication algorithms.
You can configure up to 10000 IPsec transform sets in the system.
To configure an IPsec transform set:
167
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an IPsec transform set
and enter its view.
ipsec transform-set
transform-set-name
By default, no IPsec transform set
exists.
Optional.
ESP by default.
3.
Specify the security protocol
for the IPsec transform set.
transform { ah | ah-esp | esp }
Only when a security protocol is
selected, can you configure
security algorithms for it. For
example, you can specify the
ESP-specific security algorithms
only when you select ESP as the
security protocol.
In non-FIPS mode, ESP supports
three IP packet protection schemes:
encryption only, authentication
only, or both encryption and
authentication.
In FIPS mode, ESP must use both
the authentication and encryption
algorithms.
• Specify the encryption
algorithm for ESP:
esp encryption-algorithm
{ 3des | aes-cbc-128 |
aes-cbc-192 | aes-cbc-256 |
des } *
4.
Specify the security
algorithms.
• Specify the authentication
algorithm for ESP:
esp authentication-algorithm
{ md5 | sha1 } *
• Specify the authentication
algorithm for AH:
ah authentication-algorithm
{ md5 | sha1 } *
168
Configure at least one command.
By default, no security algorithm is
specified in non-FIPS mode.
In FIPS mode, the default
authentication algorithm is SHA1
for AH.
In FIPS mode, the default
authentication algorithm and
encryption algorithm for ESP are
SHA1 and AES-CBC-128,
respectively.
The 3des, des, and md5 keywords
are not available for FIPS mode.
Step
Command
Remarks
Optional.
Tunnel mode by default
5.
Specify the IP packet
encapsulation mode for the
IPsec transform set.
encapsulation-mode { transport |
tunnel }
This command is available only for
IKEv1.
Transport mode applies only when
the source and destination IP
addresses of data flows match
those of the IPsec tunnel.
IPsec for IPv6 routing protocols
supports only the transport mode.
Changes to an IPsec transform set affect only SAs negotiated after the changes. To apply the changes to
existing SAs, execute the reset ipsec sa command to clear the SAs so that they can be set up using the
updated parameters.
Configuring an IPsec policy
IPsec policies define which IPsec transform sets should be used to protect which data flows. An IPsec
policy is uniquely identified by its name and sequence number.
IPsec policies fall into the following categories:
•
Manual IPsec policy—The parameters are configured manually, such as the keys, the SPIs, and the
IP addresses of the two ends in tunnel mode.
•
IKE-based IPsec policy—The parameters are automatically negotiated through IKE.
Configuring a manual IPsec policy
To guarantee successful SA negotiations, follow these guidelines when configuring manual IPsec policies
at the two ends of an IPsec tunnel:
•
The IPsec policies at the two ends must have IPsec transform sets that use the same security protocols,
security algorithms, and encapsulation mode.
•
The remote IP address configured on the local end must be the same as the IP address of the remote
end.
•
At each end, configure parameters for both the inbound SA and the outbound SA and make sure
that different SAs use different SPIs.
•
The local inbound SA must use the same SPI and keys as the remote outbound SA. The same is true
of the local outbound SA and remote inbound SA.
•
The keys for the local and remote inbound and outbound SAs must be in the same format. For
example, if the local inbound SA uses a key in characters, the local outbound SA and remote
inbound and outbound SAs must use keys in characters.
Follow these guidelines when you configure an IPsec policy for an IPv6 routing protocol:
•
You do not need to configure ACLs or IPsec tunnel addresses.
•
Within a certain routed network scope, the IPsec transform sets used by the IPsec policies on all
routers must have the same security protocols, security algorithms, and encapsulation mode. For
OSPFv3, the scope can be directly connected neighbors or an OSPFv3 area. For RIPng, the scope
can be directly connected neighbors or a RIPng process. For IPv6 BGP, the scope can be directly
connected neighbors or a neighbor group.
169
•
All SAs (both inbound and outbound) within the routed network scope must use the same SPI and
keys.
•
Configure the keys on all routers within the routed network scope in the same format. For example,
if you enter the keys in hexadecimal format on one router, do so across the routed network scope.
Before you configure a manual IPsec policy, configure the ACL used for identifying protected traffic and
the IPsec transform sets. ACLs are not required for IPsec policies for an IPv6 protocol.
To configure a manual IPsec policy:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a manual IPsec
policy and enter its view.
ipsec policy policy-name
seq-number manual
By default, no IPsec policy exists.
Not needed for IPsec policies to be
applied to IPv6 routing protocols and
required for other applications.
3.
Assign an ACL to the
IPsec policy.
By default, an IPsec policy references no
ACL.
security acl acl-number
The ACL supports match criteria of the
VPN attribute.
An IPsec policy can reference only one
ACL. If you apply multiple ACLs to an
IPsec policy, only the last one takes
effect.
4.
5.
6.
Assign an IPsec
transform set to the IPsec
policy.
Configure the local
address and the remote
address of the IPsec
tunnel.
Configure an SPI for an
SA.
By default, an IPsec policy references no
IPsec transform set.
transform-set transform-set-name
A manual IPsec policy can reference only
one IPsec transform set. To change an
IPsec transform set for an IPsec policy,
you must remove the reference first.
• Configure the local address of
Not needed for IPsec policies to be
applied to IPv6 routing protocols and
required for other applications.
• Configure the remote address
By default, the tunnel local and remote
addresses are not configured.
the IPsec tunnel:
tunnel local ip-address
of the IPsec tunnel:
tunnel remote ip-address
sa spi { inbound | outbound } { ah
| esp } spi-number
170
You can configure the tunnel local and
remote addresses only in FIPS mode.
By default, no SPI is configured for an
SA.
Step
Command
Remarks
• Configure an authentication
key in hexadecimal for AH:
sa authentication-hex
{ inbound | outbound } ah
[ cipher string-key | simple
hex-key ]
• Configure an authentication
key in characters for AH:
sa string-key { inbound |
outbound } ah [ cipher |
simple ] string-key
• Configure a key in characters
for ESP:
sa string-key { inbound |
outbound } esp [ cipher |
simple ] string-key
Configure keys for the
SA.
7.
• Configure an authentication
key in hexadecimal for ESP:
sa authentication-hex
{ inbound | outbound } esp
[ cipher string-key | simple
hex-key ]
Configure keys properly for the security
protocol (AH or ESP) you have specified.
If you configure a key in two modes:
string and hexadecimal, only the last
configured one will be used.
If you configure a key in characters for
ESP, the device automatically generates
an authentication key and an encryption
key for ESP.
The sa string-key command is not
available for FIPS mode.
• Configure an encryption key in
hexadecimal for ESP:
sa encryption-hex { inbound |
outbound } esp [ cipher
string-key | simple hex-key ]
NOTE:
You cannot change the creation mode of an IPsec policy from manual to through IKE, or vice versa. To
create an IKE-based IPsec policy, delete the manual IPsec policy, and then use IKE to configure an IPsec
policy.
Configuring an IKE-based IPsec policy
Before you configure an IKE-based IPsec policy, complete the following tasks:
•
Configure the ACLs and the IPsec transform sets for the IPsec policy.
•
Configure the IKE peer. For more information about IKE peer configuration, see "Configuring IKE."
The parameters for the local and remote ends must match.
To configure an IKE-based IPsec policy:
Step
Command
Remark
N/A
1.
Enter system view.
system-view
2.
Create an IKE-based IPsec
policy and enter its view.
ipsec policy policy-name
seq-number isakmp
171
By default, no IPsec policy exists.
The isakmp mode is available only
for FIPS mode.
Step
Command
Remark
Optional.
3.
4.
5.
6.
Configure an IPsec connection
name.
connection-name name
By default, no IPsec connection
name is configured.
This command is available only for
FIPS mode.
By default, an IPsec policy
references no ACL.
Assign an ACL to the IPsec
policy.
security acl acl-number
Assign IPsec transform sets to
the IPsec policy.
transform-set
transform-set-name&<1-6>
By default, an IPsec policy
references no IPsec transform set.
ike-peer peer-name
An IPsec policy cannot reference
any IKE peer that is already
referenced by an IPsec profile, and
vice versa.
Specify an IKE peer for the
IPsec policy.
This command is available only for
FIPS mode.
This command is available only for
FIPS mode.
Optional.
Tunnel mode by default.
7.
Specify the IP packet
encapsulation mode.
encapsulation-mode { transport |
tunnel }
Transport mode applies only when
the source and destination IP
addresses of data flows match
those of the IPsec tunnel.
IPsec for IPv6 routing protocols
supports only the transport mode.
Optional.
8.
Enable and configure the
perfect forward secrecy
feature for the IPsec policy.
pfs { dh-group2 | dh-group5 |
dh-group14 }
By default, the PFS feature is not
used for negotiation.
For more information about PFS,
see "Configuring IKE."
This command is available only for
FIPS mode.
Optional.
9.
Set the SA lifetime.
sa duration { time-based seconds |
traffic-based kilobytes }
By default, the global SA lifetime is
used.
This command is available only for
FIPS mode.
Optional.
10. Enable the IPsec policy.
policy enable
11. Return to system view.
quit
Enabled by default.
This command is available only for
FIPS mode.
N/A
172
Step
Command
Remark
Optional.
12. Set the global SA lifetime.
ipsec sa global-duration
{ time-based seconds |
traffic-based kilobytes }
3600 seconds for time-based SA
lifetime by default.
1843200 kilobytes for
traffic-based SA lifetime by default.
This command is available only for
FIPS mode.
With SAs to be established through IKE negotiation, an IPsec policy can reference up to six IPsec
transform sets. During negotiation, IKE searches for a fully matched IPsec transform set at the two ends of
the expected IPsec tunnel. If no match is found, no SA can be set up and the packets expecting to be
protected will be dropped.
During IKE negotiation for an IPsec policy with PFS enabled, an additional key exchange is performed.
If the local end uses PFS, the remote end must also use PFS for negotiation and both ends must use the
same DH group. Otherwise, the negotiation will fail.
An SA uses the global lifetime settings when it is not configured with lifetime settings in IPsec policy view.
When negotiating to set up SAs, IKE uses the local lifetime settings or those proposed by the peer,
whichever are smaller.
Applying an IPsec policy group to an interface
This function is available only for FIPS mode.
An IPsec policy group is a collection of IPsec policies with the same name but different sequence numbers.
In an IPsec policy group, an IPsec policy with a smaller sequence number has a higher priority.
You can apply an IPsec policy group to a logical or physical interface to protect certain data flows. To
cancel the IPsec protection, remove the application of the IPsec policy group.
For each packet to be sent out an IPsec protected interface, the system looks through the IPsec policies in
the IPsec policy group in ascending order of sequence numbers. If an IPsec policy matches the packet,
the system uses the IPsec policy to protect the packet. If no match is found, the system sends the packet out
without IPsec protection.
To apply an IPsec policy group to an interface:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
Only VLAN interfaces and Layer 3
Ethernet interfaces support an IPsec
policy group.
3.
Apply an IPsec policy group
to the interface.
ipsec policy policy-name
An interface can reference only
one IPsec policy group. An IPsec
policy can be applied to only one
interface.
173
Configuring the IPsec session idle timeout
An IPsec session is created when the first packet matching an IPsec policy arrives. Also created is an IPsec
session entry, which records the quintuplet (source IP address, destination IP address, protocol number,
source port, and destination port) and the matched IPsec tunnel.
An IPsec session is automatically deleted after the idle timeout expires.
Subsequent data flows search the session entries according to the quintuplet to find a matched item. If
found, the data flows are processed according to the tunnel information. Otherwise, they are processed
according to the original IPsec process: search the policy group or policy at the interface, and then the
matched tunnel.
The session processing mechanism of IPsec saves intermediate matching procedures, improving the IPsec
forwarding efficiency.
To set the IPsec session idle timeout:
Step
1.
Enter system view.
Command
Remark
system-view
N/A
Optional.
2.
Set the IPsec session idle
timeout.
ipsec session idle-time seconds
300 seconds by default.
This command is available only for
FIPS mode.
Enabling ACL checking for de-encapsulated IPsec packets
In tunnel mode, the IP packet encapsulated in an inbound IPsec packet might be out of protection of the
ACL specified in the IPsec policy. After being de-encapsulated, such packets bring threats to the network
security. You can enable ACL checking for de-encapsulated IPsec packets. All packets failing the
checking are discarded, improving the network security.
To enable ACL checking for de-encapsulated IPsec packets:
Step
1.
Enter system view.
2.
Enable ACL checking for
de-encapsulated IPsec
packets.
Command
Remarks
system-view
N/A
Optional.
ipsec decrypt check
Enabled by default.
This command is available only for
FIPS mode.
Configuring the IPsec anti-replay function
This function is available only for FIPS mode.
The IPsec anti-replay function protects networks against anti-replay attacks by using a sliding window
mechanism called anti-replay window. This function checks the sequence number of each received IPsec
packet against the current IPsec packet sequence number range of the sliding window. If the sequence
174
number is not in the current sequence number range, the packet is considered a replayed packet and is
discarded.
IPsec packet de-encapsulation involves complicated calculation. De-encapsulation of replayed packets
not only makes no sense, but also consumes large amounts of resources and degrades performance,
resulting in DoS. IPsec anti-replay checking, when enabled, is performed before the de-encapsulation
process, reducing resource waste.
In some cases, however, the sequence numbers of some normal service data packets may be out of the
current sequence number range, and the IPsec anti-replay function may drop them as well, affecting the
normal communications. If this happens, disable IPsec anti-replay checking or adjust the size of the
anti-replay window as required.
IPsec anti-replay checking does not affect manually created IPsec SAs. According to the IPsec protocol,
only IPsec SAs negotiated by IKE support anti-replay checking.
IMPORTANT:
• IPsec anti-replay checking is enabled by default. Do not disable it unless it needs to be disabled.
• A wider anti-replay window results in higher resource cost and more system performance degradation,
which is against the original intention of the IPsec anti-replay function. Specify an anti-replay window
size that is as small as possible.
To configure IPsec anti-replay checking:
Step
1.
Enter system view.
2.
Enable IPsec anti-replay
checking.
Command
Remarks
system-view
N/A
Optional.
ipsec anti-replay check
Enabled by default.
This command is available only for
FIPS mode.
Optional.
3.
Set the size of the IPsec
anti-replay window.
ipsec anti-replay window width
32 by default.
This command is available only for
FIPS mode.
Configuring packet information pre-extraction
If you apply both an IPsec policy and QoS policy to an interface, by default, the interface first uses IPsec
and then QoS to process IP packets, and QoS classifies packets by the headers of IPsec-encapsulated
packets. If you want QoS to classify packets by the headers of the original IP packets, enable the packet
information pre-extraction feature.
For more information about QoS policy and classification, see ACL and QoS Configuration Guide.
To configure packet information pre-extraction:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
175
Step
Command
Remarks
This command is available only for
FIPS mode.
2.
Enter IPsec policy view.
ipsec policy policy-name
seq-number [ isakmp | manual ]
3.
Enable packet information
pre-extraction.
qos pre-classify
Disabled by default.
This command is available only for
FIPS mode.
Enabling invalid SPI recovery
When the security gateway at one end of an IPsec tunnel loses its SAs due to rebooting or any other
reason, its peer security gateway may not know the problem and send IPsec packets to it. These packets
will be discarded by the receiver because the receiver cannot find appropriate SAs for them, resulting in
a traffic blackhole. This situation changes only after the concerned SAs on the sender get aged out and
new SAs are established between the two peers. To prevent such service interruption, configure the
invalid SPI recovery feature.
The invalid SPI recovery feature allows the receiver to send an INVALID SPI NOTIFY message to tell the
sender the invalid SPIs. Upon receiving the message, the sender immediately deletes the corresponding
SAs. The subsequent traffic triggers the two peers to set up new SAs for data transmission.
Because attackers may exploit INVALID SPI NOTIFY messages to attack the IPsec packet sender (DoS
attack), the invalid SPI recovery feature is disabled by default, making the receiver discard packets with
invalid SPIs.
To enable invalid SPI recovery:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
Optional.
2.
Enable invalid SPI recovery.
ipsec invalid-spi-recovery enable
Disabled by default.
This command is available only
for FIPS mode.
Configuring IPsec for IPv6 routing protocols
IMPORTANT:
Do not apply an IPsec policy used for an IPv6 routing protocol to an interface. If you do so, the interface
will drop all packets, because the IPsec policy references no ACL.
Complete the following tasks to configure IPsec for IPv6 routing protocols:
Task
Remarks
Configuring an IPsec transform set
Required.
176
Task
Remarks
Required.
Configuring a manual IPsec policy
ACLs and IPsec tunnel addresses are not needed.
Required.
Applying an IPsec policy to an IPv6 routing
protocol
See Layer 3—IP Routing Configuration Guide.
Displaying and maintaining IPsec
Task
Command
Remarks
Display IPsec policy information.
display ipsec policy [ brief | name
policy-name [ seq-number ] ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display IPsec transform set
information.
display ipsec transform-set
[ transform-set-name ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display IPsec SA information.
display ipsec sa [ brief | duration |
policy policy-name [ seq-number ] |
remote [ ipv6 ] ip-address ] [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display IPsec session information.
display ipsec session [ tunnel-id integer ]
[ | { begin | exclude | include }
regular-expression ]
Display IPsec packet statistics.
display ipsec statistics [ tunnel-id integer ]
[ | { begin | exclude | include }
regular-expression ]
Available in any view.
Display IPsec tunnel information.
display ipsec tunnel [ | { begin | exclude
| include } regular-expression ]
Available in any view.
Clear SAs.
reset ipsec sa [ parameters dest-address
protocol spi | policy policy-name
[ seq-number ] | remote ip-address ]
Clear IPsec sessions.
reset ipsec session [ tunnel-id integer ]
This command is available
only for FIPS mode.
Clear IPsec statistics.
reset ipsec statistics
Available in user view.
Available in any view.
This command is available
only for FIPS mode.
Available in user view.
The parameters and remote
keywords are available only
for FIPS mode.
Available in user view.
IPsec configuration examples
Configuring a manual mode IPsec tunnel for IPv4 packets
This configuration example is applicable only to routers operating in FIPS mode.
177
Network requirements
As shown in Figure 60, configure an IPsec tunnel between Router A and Router B to protect data flows
between them. Configure the tunnel to use the security protocol ESP, the encryption algorithm AES 128,
and the authentication algorithm SHA1-HMAC-96.
Figure 60 Network diagram
Router A
Router B
GE3/1/1
2.2.2.1/24
Internet
GE3/1/1
2.2.3.1/24
Configuration procedure
1.
Configure Router A:
# Configure an IP address for GigabitEthernet 3/1/1.
[RouterA] interface GigabitEthernet 3/1/1
[RouterA-GigabitEthernet3/1/1] ip address 2.2.2.1 255.255.255.0
[RouterA-GigabitEthernet3/1/1] quit
# Define an ACL to identify data flows between Router A and Router B.
[RouterA] acl number 3101
[RouterA-acl-adv-3101] rule 0 permit ip source 2.2.2.1 0 destination 2.2.3.1 0
[RouterA-acl-adv-3101] rule 5 permit ip source 2.2.3.1 0 destination 2.2.2.1 0
[RouterA-acl-adv-3101] quit
# Create an IPsec transform set named tran1.
[RouterA] ipsec transform-set tran1
# Specify the encapsulation mode as tunnel.
[RouterA-ipsec-transform-set-tran1] encapsulation-mode tunnel
# Specify the security protocol as ESP.
[RouterA-ipsec-transform-set-tran1] transform esp
# Specify the algorithms for the IPsec transform set.
[RouterA-ipsec-transform-set-tran1] esp encryption-algorithm aes 128
[RouterA-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[RouterA-ipsec-transform-set-tran1] quit
# Create manual IPsec policy map1.
[RouterA] ipsec policy map1 10 manual
# Apply the ACL.
[RouterA-ipsec-policy-manual-map1-10] security acl 3101
# Apply the IPsec transform set.
[RouterA-ipsec-policy-manual-map1-10] transform-set tran1
# Configure the remote IP address of the tunnel.
[RouterA-ipsec-policy-manual-map1-10] tunnel remote 2.2.3.1
# Configure the local IP address of the tunnel.
[RouterA-ipsec-policy-manual-map1-10] tunnel local 2.2.2.1
# Configure the SPIs.
[RouterA-ipsec-policy-manual-map1-10] sa spi outbound esp 12345
[RouterA-ipsec-policy-manual-map1-10] sa spi inbound esp 54321
178
# Configure the keys.
[RouterA-ipsec-policy-manual-map1-10] sa encryption-hex outbound esp
abcdefabcdefabcdefabcdefabcdefab
[RouterA-ipsec-policy-manual-map1-10] sa encryption-hex inbound esp
bafedcbafedcbafedcbafedcbafedcba
[RouterA-ipsec-policy-manual-map1-10] sa authentication-hex outbound esp
0123456789012345678901234567890123456789
[RouterA-ipsec-policy-manual-map1-10] sa authentication-hex inbound esp
9876543210987654321098765432109876543210
[RouterA-ipsec-policy-manual-map1-10] quit
# Apply the IPsec policy group to interface GigabitEthernet 3/1/1.
[RouterA] interface GigabitEthernet 3/1/1
[RouterA-GigabitEthernet3/1/1] ipsec policy map1
2.
Configure Router B:
# Configure an IP address for GigabitEthernet 3/1/1.
[RouterB] interface GigabitEthernet 3/1/1
[RouterB-GigabitEthernet3/1/1] ip address 2.2.3.1 255.255.255.0
[RouterB-GigabitEthernet3/1/1] quit
# Define an ACL to identify data flows between Router A and Router B.
[RouterB] acl number 3101
[RouterB-acl-adv-3101] rule 0 permit ip source 2.2.3.1 0 destination 2.2.2.1 0
[RouterB-acl-adv-3101] rule 5 permit ip source 2.2.2.1 0 destination 2.2.3.1 0
[RouterB-acl-adv-3101] quit
# Create an IPsec transform set named tran1.
[RouterB] ipsec transform-set tran1
# Specify the encapsulation mode as tunnel.
[RouterB-ipsec-transform-set-tran1] encapsulation-mode tunnel
# Specify the security protocol as ESP.
[RouterB-ipsec-transform-set-tran1] transform esp
# Specify the algorithms for the IPsec transform set.
[RouterB-ipsec-transform-set-tran1] esp encryption-algorithm aes 128
[RouterB-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[RouterB-ipsec-transform-set-tran1] quit
# Create a manual IPsec policy.
[RouterB] ipsec policy use1 10 manual
# Apply the ACL.
[RouterB-ipsec-policy-manual-use1-10] security acl 3101
# Apply the IPsec transform set.
[RouterB-ipsec-policy-manual-use1-10] transform-set tran1
# Configure the remote IP address of the tunnel.
[RouterB-ipsec-policy-manual-use1-10] tunnel remote 2.2.2.1
# Configure the local IP address of the tunnel.
[RouterB-ipsec-policy-manual-use1-10] tunnel local 2.2.3.1
# Configure the SPIs.
[RouterB-ipsec-policy-manual-use1-10] sa spi outbound esp 54321
[RouterB-ipsec-policy-manual-use1-10] sa spi inbound esp 12345
179
# Configure the keys.
[RouterB-ipsec-policy-manual-use1-10] sa encryption-hex outbound esp
bafedcbafedcbafedcbafedcbafedcba
[RouterB-ipsec-policy-manual-use1-10] sa encryption-hex inbound esp
abcdefabcdefabcdefabcdefabcdefab
[RouterB-ipsec-policy-manual-use1-10] sa authentication-hex outbound esp
9876543210987654321098765432109876543210
[RouterB-ipsec-policy-manual-use1-10] sa authentication-hex inbound esp
0123456789012345678901234567890123456789
[RouterB-ipsec-policy-manual-use1-10] quit
# Apply the IPsec policy group to interface GigabitEthernet 3/1/1.
[RouterB] interface GigabitEthernet 3/1/1
[RouterB-GigabitEthernet3/1/1] ipsec policy use1
Verifying the configuration
After the configuration, an IPsec tunnel between Router A and Router B should be established, and
the traffic between Router A and Router B should be IPsec protected.
Configuring an IKE-based IPsec tunnel for IPv4 packets
This configuration example is applicable only to routers operating in FIPS mode.
Network requirements
As shown in Figure 60, configure an IPsec tunnel between Router A and Router B to protect data flows
between them. Configure the tunnel to use the security protocol ESP, the encryption algorithm AES 128,
and the authentication algorithm SHA1-HMAC-96.
Configuration procedure
1.
Configure Router A:
# Configure an IP address for GigabitEthernet 3/1/1.
<RouterA> system-view
[RouterA] interface GigabitEthernet 3/1/1
[RouterA-GigabitEthernet3/1/1] ip address 2.2.2.1 255.255.255.0
[RouterA-GigabitEthernet3/1/1] quit
# Define an ACL to identify data flows between Router A and Router B.
[RouterA] acl number 3101
[RouterA-acl-adv-3101] rule 0 permit ip source 2.2.2.1 0 destination 2.2.3.1 0
[RouterA-acl-adv-3101] rule 5 permit ip source 2.2.3.1 0 destination 2.2.2.1 0
[RouterA-acl-adv-3101] quit
# Create an IPsec transform set named tran1.
[RouterA] ipsec transform-set tran1
# Specify the encapsulation mode as tunnel.
[RouterA-ipsec-transform-set-tran1] encapsulation-mode tunnel
# Specify the security protocol as ESP.
[RouterA-ipsec-transform-set-tran1] transform esp
# Specify the algorithms for the IPsec transform set.
[RouterA-ipsec-transform-set-tran1] esp encryption-algorithm aes 128
[RouterA-ipsec-transform-set-tran1] esp authentication-algorithm sha1
180
[RouterA-ipsec-transform-set-tran1] quit
# Configure the IKE peer.
[RouterA] ike peer peer
[RouterA-ike-peer-peer] pre-shared-key Ab12<><>
[RouterA-ike-peer-peer] quit
# Create an IKE-based IPsec policy for IPsec SA negotiation.
[RouterA] ipsec policy map1 10 isakmp
# Apply the IPsec transform set.
[RouterA-ipsec-policy-isakmp-map1-10] transform-set tran1
# Apply the ACL.
[RouterA-ipsec-policy-isakmp-map1-10] security acl 3101
# Apply the IKE peer.
[RouterA-ipsec-policy-isakmp-map1-10] ike-peer peer
[RouterA-ipsec-policy-isakmp-map1-10] quit
# Apply the IPsec policy group to interface GigabitEthernet 3/1/1.
[RouterA] interface GigabitEthernet 3/1/1
[RouterA-GigabitEthernet3/1/1] ipsec policy map1
2.
Configure Router B:
# Configure an IP address for GigabitEthernet 3/1/1.
<RouterB> system-view
[RouterB] interface GigabitEthernet 3/1/1
[RouterB-GigabitEthernet3/1/1] ip address 2.2.3.1 255.255.255.0
[RouterB-GigabitEthernet3/1/1] quit
# Define an ACL to identify data flows between Router A and Router B.
[RouterB] acl number 3101
[RouterB-acl-adv-3101] rule 0 permit ip source 2.2.3.1 0 destination 2.2.2.1 0
[RouterB-acl-adv-3101] rule 5 permit ip source 2.2.2.1 0 destination 2.2.3.1 0
[RouterB-acl-adv-3101] quit
# Create an IPsec transform set named tran1.
[RouterB] ipsec transform-set tran1
# Specify the encapsulation mode as tunnel.
[RouterB-ipsec-transform-set-tran1] encapsulation-mode tunnel
# Specify the security protocol as ESP.
[RouterB-ipsec-transform-set-tran1] transform esp
# Specify the algorithms for the IPsec transform set.
[RouterB-ipsec-transform-set-tran1] esp encryption-algorithm aes 128
[RouterB-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[RouterB-ipsec-transform-set-tran1] quit
# Configure the IKE peer.
[RouterB] ike peer peer
[RouterB-ike-peer-peer] pre-shared-key Ab12<><>
[RouterB-ike-peer-peer] quit
# Create an IKE-based IPsec policy for IPsec SA negotiation.
[RouterB] ipsec policy use1 10 isakmp
# Apply the ACL.
181
[RouterB-ipsec-policy-isakmp-use1-10] security acl 3101
# Apply the IPsec transform set.
[RouterB-ipsec-policy-isakmp-use1-10] transform-set tran1
# Apply the IKE peer.
[RouterB-ipsec-policy-isakmp-use1-10] ike-peer peer
[RouterB-ipsec-policy-isakmp-use1-10] quit
# Apply the IPsec policy group to interface GigabitEthernet 3/1/1.
[RouterB] interface GigabitEthernet 3/1/1
[RouterB-GigabitEthernet3/1/1] ipsec policy use1
Verifying the configuration
After the configuration, IKE negotiation will be triggered to set up SAs when there is traffic between
Router A and Router B. If IKE negotiation is successful and SAs are set up, the traffic between the
two routers will be IPsec protected.
Configuring IPsec for RIPng
The IPsec configuration procedures for protecting OSPFv3 and IPv6 BGP are similar. For more
information about RIPng, OSPFv3, and IPv6 BGP, see Layer 3—IP Routing Configuration Guide.
Network requirements
As shown in Figure 61, Router A, Router B, and Router C are connected. They learn IPv6 routing
information through RIPng.
Configure IPsec for RIPng so that RIPng packets exchanged between the routers are transmitted through
an IPsec tunnel. Configure IPsec to use the security protocol ESP, the encryption algorithm AES-CBC-128,
and the authentication algorithm SHA1-HMAC-96.
Figure 61 Network diagram
Configuation considerations
Perform the following configuration tasks:
•
Configure basic RIPng parameters.
•
Configure a manual IPsec policy.
•
Apply the IPsec policy to a RIPng process to protect RIPng packets in this process or to an interface
to protect RIPng packets traveling through the interface.
Configuration procedure
1.
Configure Router A:
# Assign an IPv6 address to each interface. (Details not shown.)
# Create a RIPng process and enable it on GigabitEthernet 3/1/1.
<RouterA> system-view
[RouterA] ripng 1
[RouterA-ripng-1] quit
182
[RouterA] interface GigabitEthernet 3/1/1
[RouterA-GigabitEthernet3/1/1] ripng 1 enable
[RouterA-GigabitEthernet3/1/1] quit
# Create an IPsec transform set named tran1, and set the encapsulation mode to transport mode,
the security protocol to ESP, the encryption algorithm to AES-CBC-128, and authentication
algorithm to SHA1-HMAC-96.
[RouterA] ipsec transform-set tran1
[RouterA-ipsec-transform-set-tran1] encapsulation-mode transport
[RouterA-ipsec-transform-set-tran1] transform esp
[RouterA-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-128
[RouterA-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[RouterA-ipsec-transform-set-tran1] quit
# Create an IPsec policy named policy001, specify the manual mode for it, set the SPIs of the
inbound and outbound SAs to 123456, and the keys for the inbound and outbound SAs using ESP
to abcdefg.
[RouterA] ipsec policy policy001 10 manual
[RouterA-ipsec-policy-manual-policy001-10] transform-set tran1
[RouterA-ipsec-policy-manual-policy001-10] sa spi outbound esp 123456
[RouterA-ipsec-policy-manual-policy001-10] sa spi inbound esp 123456
[RouterA-ipsec-policy-manual-policy001-10] sa string-key outbound esp abcdefg
[RouterA-ipsec-policy-manual-policy001-10] sa string-key inbound esp abcdefg
[RouterA-ipsec-policy-manual-policy001-10] quit
# Apply IPsec policy policy001 to the RIPng process.
[RouterA] ripng 1
[RouterA-ripng-1] enable ipsec-policy policy001
[RouterA-ripng-1] quit
2.
Configure Router B:
# Assign an IPv6 address to each interface. (Details not shown.)
# Create a RIPng process and enable it on GigabitEthernet 3/1/1 and GigabitEthernet 3/1/2.
<RouterB> system-view
[RouterB] ripng 1
[RouterB-ripng-1] quit
[RouterB] interface GigabitEthernet 3/1/1
[RouterB-GigabitEthernet3/1/1] ripng 1 enable
[RouterB-GigabitEthernet3/1/1] quit
[RouterB] interface GigabitEthernet 3/1/2
[RouterB-GigabitEthernet3/1/2] ripng 1 enable
[RouterB-GigabitEthernet3/1/2] quit
# Create an IPsec transform set named tran1, and set the encapsulation mode to transport mode,
the security protocol to ESP, the encryption algorithm to AES-CBC-128, and authentication
algorithm to SHA1-HMAC-96.
[RouterB] ipsec transform-set tran1
[RouterB-ipsec-transform-set-tran1] encapsulation-mode transport
[RouterB-ipsec-transform-set-tran1] transform esp
[RouterB-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-128
[RouterB-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[RouterB-ipsec-transform-set-tran1] quit
183
# Create an IPsec policy named policy001, specify the manual mode for it, configure the SPIs of
the inbound and outbound SAs as 123456, and the keys for the inbound and outbound SAs using
ESP as abcdefg.
[RouterB] ipsec policy policy001 10 manual
[RouterB-ipsec-policy-manual-policy001-10] transform-set tran1
[RouterB-ipsec-policy-manual-policy001-10] sa spi outbound esp 123456
[RouterB-ipsec-policy-manual-policy001-10] sa spi inbound esp 123456
[RouterB-ipsec-policy-manual-policy001-10] sa string-key outbound esp abcdefg
[RouterB-ipsec-policy-manual-policy001-10] sa string-key inbound esp abcdefg
[RouterB-ipsec-policy-manual-policy001-10] quit
# Apply IPsec policy policy001 to the RIPng process.
[RouterB] ripng 1
[RouterB-ripng-1] enable ipsec-policy policy001
[RouterB-ripng-1] quit
3.
Configure Router C:
# Assign an IPv6 address to each interface. (Details not shown.)
# Create a RIPng process and enable it on GigabitEthernet 3/1/1.
<RouterC> system-view
[RouterC] ripng 1
[RouterC-ripng-1] quit
[RouterC] interface GigabitEthernet 3/1/1
[RouterC-GigabitEthernet3/1/1] ripng 1 enable
[RouterC-GigabitEthernet3/1/1] quit
# Create an IPsec transform set named tran1, and set the encapsulation mode to transport mode,
the security protocol to ESP, the encryption algorithm to AES-CBC-128, and authentication
algorithm to SHA1-HMAC-96.
[RouterC] ipsec transform-set tran1
[RouterC-ipsec-transform-set-tran1] encapsulation-mode transport
[RouterC-ipsec-transform-set-tran1] transform esp
[RouterC-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-128
[RouterC-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[RouterC-ipsec-transform-set-tran1] quit
# Create an IPsec policy named policy001, specify the manual mode for it, and configure the SPIs
of the inbound and outbound SAs as 123456, and the keys for the inbound and outbound SAs
using ESP as abcdefg.
[RouterC] ipsec policy policy001 10 manual
[RouterC-ipsec-policy-manual-policy001-10] transform-set tran1
[RouterC-ipsec-policy-manual-policy001-10] sa spi outbound esp 123456
[RouterC-ipsec-policy-manual-policy001-10] sa spi inbound esp 123456
[RouterC-ipsec-policy-manual-policy001-10] sa string-key outbound esp abcdefg
[RouterC-ipsec-policy-manual-policy001-10] sa string-key inbound esp abcdefg
[RouterC-ipsec-policy-manual-policy001-10] quit
# Apply IPsec policy policy001 to the RIPng process.
[RouterC] ripng 1
[RouterC-ripng-1] enable ipsec-policy policy001
[RouterC-ripng-1] quit
184
Verifying the configuration
After the configuration, Router A, Router B, and Router C learn IPv6 routing information through
RIPng. SAs are set up successfully, and the IPsec tunnel between two peers is up for protecting the
RIPng packets.
# Execute the display ripng command on Router A to view the running status and configuration
information of the specified RIPng process. The output shows that IPsec policy policy001 is applied
to this process successfully.
<RouterA> display ripng 1
RIPng process : 1
Preference : 100
Checkzero : Enabled
Default Cost : 0
Maximum number of balanced paths : 8
Update time
:
30 sec(s)
Suppress time :
120 sec(s)
Timeout time
:
180 sec(s)
Garbage-Collect time :
120 sec(s)
Number of periodic updates sent : 186
Number of trigger updates sent : 1
IPsec policy name: policy001, SPI: 123456
# Execute the display ipsec sa command on Router A to view the information about the inbound
and outbound SAs.
<RouterA> display ipsec sa
===============================
Protocol: RIPng
===============================
----------------------------IPsec policy name: "policy001"
sequence number: 10
acl version: ACL4
mode: manual
----------------------------connection id: 1
encapsulation mode: transport
perfect forward secrecy:
tunnel:
flow:
[inbound ESP SAs]
spi: 123456 (0x3039)
transform-set: ESP-ENCRYPT-DES ESP-AUTH-SHA1
No duration limit for this sa
[outbound ESP SAs]
spi: 123456 (0x3039)
transform-set: ESP-ENCRYPT-DES ESP-AUTH-SHA1
No duration limit for this sa
Similarly, you can view the information on Router B and Router C. (Details not shown.)
185
Configuring IKE
The IKE negotiation mode is available only for FIPS mode.
You cannot configure IKE negotiation on tunnel interfaces or aggregate interfaces.
Overview
Built on a framework defined by the Internet Security Association and Key Management Protocol
(ISAKMP), Internet Key Exchange (IKE) provides automatic key negotiation and SA establishment services
for IPsec, simplifying the application, management, configuration and maintenance of IPsec
dramatically.
Instead of transmitting keys directly across a network, IKE peers transmit keying materials between them,
and calculate shared keys respectively. Even if a third party captures all exchanged data for calculating
the keys, it cannot calculate the keys.
NOTE:
Unless otherwise specified, IKE in this chapter refers to IKEv1.
IKE security mechanism
IKE has a series of self-protection mechanisms and supports secure identity authentication, key
distribution, and IPsec SA establishment on insecure networks.
Data authentication
Data authentication involves two concepts:
•
Identity authentication—Mutual identity authentication between peers. Two authentication
methods are available: pre-shared key authentication and PKI-based digital signature
authentication (RSA signature).
•
Identity protection—Encrypts the identity information with the generated keys before sending the
information.
DH
The DH algorithm is a public key algorithm. With this algorithm, two peers can exchange keying material
and then use the material to calculate the shared keys. Due to the decryption complexity, a third party
cannot decrypt the keys even after intercepting all keying materials.
PFS
The Perfect Forward Secrecy (PFS) feature is a security feature based on the DH algorithm. By making
sure keys have no derivative relations, it guarantees a broken key brings no threats to other keys. For IPsec,
PFS is implemented by adding an additional key exchange at IKE negotiation phase 2.
186
IKE operation
IKE negotiates keys and establishes SAs for IPsec in two phases:
1.
Phase 1—The two peers establish an ISAKMP SA, a secure, authenticated channel for
communication. In this phase, the IKE negotiation mode is the main mode.
2.
Phase 2—Using the ISAKMP SA established in phase 1, the two peers negotiate to establish IPsec
SAs.
Figure 62 IKE exchange process in main mode
Peer 1
Send local
IKE policy
Peer 2
Confirmed policy
SA exchange
Receive the
policy
Search for
matched policy
Key generation
Initiator’s key information
Receiver’s key
information
Key exchange
Algorithm
negotiation
Initiator’s policy
Generate the key
Identity
authentication
Generate the key
Initiator’s identity and
authentication data
Receiver’s identity and
ID and authentication
data exchange
Perform ID/exchange
authentication
Perform ID/exchange
authentication
authentication data
As shown in Figure 62, the main mode of IKE negotiation in phase 1 involves three pairs of messages:
•
SA exchange—Used for negotiating the security policy.
•
Key exchange—Used for exchanging the DH public value and other values like the random number.
Key data is generated in this stage.
•
ID and authentication data exchange—Used for identity authentication and authentication of data
exchanged in phase 1.
IKE functions
IKE provides the following functions for IPsec:
•
Automatically negotiates IPsec parameters such as the keys.
•
Performs DH exchange when establishing an SA, making sure that each SA has a key independent
of other keys.
•
Automatically negotiates SAs when the sequence number in the AH or ESP header overflows,
making sure that IPsec provides the anti-replay service normally by using the sequence number.
•
Provides end-to-end dynamic authentication.
•
Identity authentication and management of peers influence IPsec deployment. A large-scale IPsec
deployment needs the support of CAs or other institutes which manage identity data centrally.
187
Relationship between IKE and IPsec
Figure 63 Relationship between IKE and IPsec
Figure 63 illustrates the relationship between IKE and IPsec:
•
IKE is an application layer protocol using UDP and functions as the signaling protocol of IPsec.
•
IKE negotiates SAs for IPsec and delivers negotiated parameters and generated keys to IPsec.
•
IPsec uses the SAs set up through IKE negotiation for encryption and authentication of IP packets.
Protocols and standards
•
RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP)
•
RFC 2409, The Internet Key Exchange (IKE)
•
RFC 2412, The OAKLEY Key Determination Protocol
Configuration task list for IKE
Determine the following parameters prior to IKE configuration:
•
The strength of the algorithms for IKE negotiation (the security protection level), including the
identity authentication method, encryption algorithm, authentication algorithm, and DH group.
Different algorithms provide different levels of protection. A stronger algorithm means more
resistance to decryption of protected data but requires more resources. Generally, the longer the key,
the stronger the algorithm.
•
The pre-shared key or the PKI domain the certificate belongs to. For more information about PKI
configuration, see "Configuring PKI."
To configure IKE:
Task
Remarks
Configuring a name for the local security gateway
Optional.
Optional.
Configuring an IKE proposal
Required if you want to specify an IKE proposal for
an IKE peer to reference.
188
Task
Remarks
Configuring an IKE peer
Required.
Setting keepalive timers
Optional.
Setting the NAT keepalive timer
Optional.
Configuring a DPD detector
Optional.
Disabling next payload field checking
Optional.
Configuring a name for the local security gateway
If the IKE negotiation peer uses the security gateway name as its ID to initiate IKE negotiation (the id-type
name or id-type user-fqdn command is configured on the initiator), configure the ike local-name
command in system view or the local-name command in IKE peer view on the local device. If you
configure both commands, the name configured by in IKE peer view is used.
To configure a name for the local security gateway:
Step
1.
Enter system view.
2.
Configure a name for the
local security gateway.
Command
Remarks
system-view
N/A
Optional.
ike local-name name
By default, the device name is used as the
name of the local security gateway.
Configuring an IKE proposal
An IKE proposal defines a set of attributes describing how IKE negotiation should take place. You may
create multiple IKE proposals with different preferences. The preference of an IKE proposal is represented
by its sequence number. The lower the sequence number, the higher the preference.
Two peers must have at least one matching IKE proposal for successful IKE negotiation. During IKE
negotiation, the initiator sends its IKE proposals to the peer, and the peer searches its own IKE proposals
for a match. The search starts from the IKE proposal with the lowest sequence number and proceeds in
the ascending order of sequence number until a match is found or all the IKE proposals are found
mismatching. The matching IKE proposals are used to establish the secure tunnel.
The two matching IKE proposals have the same encryption algorithm, authentication method,
authentication algorithm, and DH group. The SA lifetime takes the SA lifetime with a smaller value of the
two.
By default, there is an IKE proposal, which has the lowest preference and uses the default encryption
algorithm, authentication method, authentication algorithm, DH group, and ISAKMP SA lifetime.
To configure an IKE proposal:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
189
Step
Command
Remarks
2.
Create an IKE proposal
and enter its view.
ike proposal proposal-number
N/A
3.
Specify an encryption
algorithm for the IKE
proposal.
encryption-algorithm aes-cbc
[ key-length ]
Optional.
Specify an authentication
method for the IKE
proposal.
authentication-method
{ pre-share | rsa-signature }
Optional.
Specify an authentication
algorithm for the IKE
proposal.
authentication-algorithm sha
4.
5.
6.
Specify a DH group for key
negotiation in phase 1.
128-bit AES in CBC mode by default.
Pre-shared key by default.
Optional.
SHA1 by default.
Optional.
dh { group2 | group5 | group14 }
The default DH group is group2 (the
1024-bit DH group).
Optional.
86400 seconds by default.
7.
Set the ISAKMP SA lifetime
for the IKE proposal.
sa duration seconds
Before an ISAKMP SA expires, IKE
negotiates a new SA to replace it. DH
calculation in IKE negotiation takes
time, especially on low-end devices. To
prevent SA updates from influencing
normal communication, set the lifetime
greater than 10 minutes.
Configuring an IKE peer
For an IKE-based IPsec policy, you must configure an IKE peer by performing the following tasks:
•
Specify the IKE negotiation mode (the main mode) for the local end to use in IKE negotiation phase
1. When acting as the IKE negotiation responder, the local end uses the IKE negotiation mode of
the remote end.
•
Specify the IKE proposals for the local end to use when acting as the IKE negotiation initiator. When
acting as the responder, the local end uses the IKE proposals configured in system view for
negotiation.
•
Configure a pre-shared key for pre-shared key authentication or a PKI domain for digital signature
authentication.
•
Specify the ID type for the local end to use in IKE negotiation phase 1. With pre-shared key
authentication, the ID type must be IP address for main mode IKE negotiation and can be IP address,
FQDN, or user FQDN for aggressive mode IKE negotiation.
•
Specify the name or IP address of the local security gateway. You perform this task only when you
want to specify a special address, a loopback interface address, for example, as the local security
gateway address.
•
Specify the name or IP address of the remote security gateway. For the local end to initiate IKE
negotiation, you must specify the name or IP address of the remote security gateway on the local
end so the local end can find the remote end.
190
•
Enable NAT traversal. If there is NAT gateway on the path for tunneling, you must configure NAT
traversal at the two ends of the IPsec tunnel, because one end may use a public address while the
other end uses a private address.
•
Specify the DPD detector for the IKE peer.
To configure an IKE peer:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an IKE peer and
enter IKE peer view.
ike peer peer-name
N/A
3.
Specify the IKE negotiation
mode for phase 1.
exchange-mode main
Optional.
The default is main.
Optional.
4.
Specify the IKE proposals for
the IKE peer to reference.
5.
Configure a pre-shared key
for pre-shared key
authentication or specify a
PKI domain for digital
signature authentication.
6.
Select the ID type for IKE
negotiation phase 1.
proposal proposal-number&<1-6>
By default, an IKE peer references
no IKE proposals, and, when
initiating IKE negotiation, it uses
the IKE proposals configured in
system view.
• To configure a pre-shared key:
pre-shared-key [ cipher | simple ]
key
• To specify a PKI domain:
Configure either command
according to the authentication
method for the IKE proposal.
certificate domain domain-name
id-type { ip | name | user-fqdn }
Optional.
By default, the ID type is IP.
Optional.
7.
Configure a name for the
local security gateway.
local-name name
By default, no name is configured
for the local security gateway in
IKE peer view, and the security
gateway name configured by
using the ike local-name
command is used.
Optional.
8.
Specify the name of the
remote security gateway.
9.
Configure an IP address for
the local gateway.
remote-name name
The remote gateway name
configured with remote-name
command on the local gateway
must be identical to the local
name configured with the
local-name command on the
peer.
Optional.
local-address ip-address
191
By default, it is the primary IP
address of the interface
referencing the security policy.
Step
Command
Remarks
Optional.
10. Specify the IP addresses of
the remote gateway.
remote-address { hostname |
low-ip-address [ high-ip-address ] }
The remote IP address configured
with the remote-address
command on the local gateway
must be identical to the local IP
address configured with the
local-address command on the
peer.
Optional.
11. Enable the NAT traversal
function for IPsec/IKE.
nat traversal
Required when a NAT gateway is
present in the VPN tunnel
constructed by IPsec/IKE
Disabled by default.
• Set the subnet type of the local
12. Set the subnet types of the
two ends.
end:
local { multi-subnet |
single-subnet }
• Set the subnet type of the peer
end:
peer { multi-subnet |
single-subnet }
Optional.
The default subnet type is
single-subnet.
Use these two commands only
when the device is working
together with a NetScreen
device.
Optional.
13. Apply a DPD detector to the
IKE peer.
dpd dpd-name
No DPD detector is applied to an
IKE peer by default.
For more information about DPD
configuration, see "Configuring a
DPD detector."
NOTE:
After modifying the configuration of an IPsec IKE peer, execute the reset ipsec sa and reset ike sa
commands to clear existing IPsec and IKE SAs. Otherwise, SA re-negotiation will fail.
Setting keepalive timers
IKE maintains the link status of an ISAKMP SA by keepalive packets. Generally, if the peer is configured
with the keepalive timeout, you must configure the keepalive packet transmission interval on the local end.
If the peer receives no keepalive packet during the timeout interval, the ISAKMP SA is tagged with the
TIMEOUT tag (if it does not have the tag), or deleted along with the IPsec SAs it negotiated (when it has
the tag already).
The keepalive timeout configured at the local end must be longer than the keepalive interval configured
at the remote end. Since it seldom occurs that more than three consecutive packets are lost on a network,
the keepalive timeout can be configured to be three times of the keepalive interval.
To set the keepalive timers:
192
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the ISAKMP SA keepalive
interval.
ike sa keepalive-timer interval
seconds
No keepalive packet is sent by
default.
3.
Set the ISAKMP SA keepalive
timeout.
ike sa keepalive-timer timeout
seconds
No keepalive packet is sent by
default.
Setting the NAT keepalive timer
If IPsec traffic needs to pass through NAT security gateways, you must configure the NAT traversal
function. If no packet travels across an IPsec tunnel in a certain period of time, the NAT mapping may get
aged and be deleted, disabling the tunnel beyond the NAT gateway from transmitting data to the
intended end. To prevent NAT mappings from being aged, an ISAKMP SA behind the NAT security
gateway sends NAT keepalive packets to its peer at a certain interval to keep the NAT session alive.
To set the NAT keepalive timer:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the NAT keepalive
interval.
ike sa nat-keepalive-timer interval
seconds
20 seconds by default
Configuring a DPD detector
DPD irregularly detects dead IKE peers. It works as follows:
1.
When the local end sends an IPsec packet, it checks the time the last IPsec packet was received
from the peer.
2.
If the time interval exceeds the DPD interval, it sends a DPD hello to the peer.
3.
If the local end receives no DPD acknowledgement within the DPD packet retransmission interval,
it retransmits the DPD hello.
4.
If the local end still receives no DPD acknowledgement after having made the maximum number of
retransmission attempts (two by default), it considers the peer already dead, and clears the IKE SA
and the IPsec SAs based on the IKE SA.
DPD enables an IKE entity to check the liveliness of its peer only when necessary. It generates less traffic
than the keepalive mechanism, which exchanges messages periodically.
To configure a DPD detector:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a DPD detector and
enter its view.
ike dpd dpd-name
N/A
3.
Set the DPD interval.
interval-time interval-time
193
Optional.
10 seconds by default.
Step
4.
Command
Set the DPD packet
retransmission interval.
time-out time-out
Remarks
Optional.
5 seconds by default.
Disabling next payload field checking
The Next payload field is in the generic payload header of the last payload of the IKE negotiation
message (the message comprises multiple payloads). According to the protocol, this field must be 0 if the
payload is the last payload of the packet. However, it may be set to other values on some brands of
devices. For interoperability, disable the checking of this field.
To disable Next payload field checking:
Step
Command
Remark
1.
Enter system view.
system-view
N/A
2.
Disable Next payload field
checking.
ike next-payload check disabled
Enabled by default.
Displaying and maintaining IKE
Task
Command
Remarks
Display IKE DPD information.
display ike dpd [ dpd-name ] [ | { begin
| exclude | include }
regular-expression ]
Available in any view.
Display IKE peer information.
display ike peer [ peer-name ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display IKE SA information.
display ike sa [ verbose [ connection-id
connection-id | remote-address
remote-address ] ] [ | { begin | exclude
| include } regular-expression ]
Available in any view.
Display IKE proposal information.
display ike proposal [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Clear SAs established by IKE.
reset ike sa [ connection-id ]
Available in user view.
IKE configuration examples
Configuring main mode IKE with pre-shared key authentication
Network requirements
As shown in Figure 64, configure an IKE-based IPsec tunnel between Router A and Router B to secure the
communication between them.
194
For Router A, configure an IKE proposal that uses the sequence number 10 and the authentication
algorithm SHA1. Leave Router B with only the default IKE proposal. Configure the two routers to use the
pre-shared key authentication method.
Figure 64 Network diagram
Router A
Router B
GE3/1/1
1.1.1.1/16
Internet
GE3/1/1
2.2.2.2/16
Configuration procedure
1.
Make sure Router A and Router B can reach each other.
2.
Configure Router A:
# Configure an IP address for GigabitEthernet 3/1/1.
[RouterA] interface GigabitEthernet 3/1/1
[RouterA-GigabitEthernet3/1/1] ip address 1.1.1.1 255.255.0.0
[RouterA-GigabitEthernet3/1/1] quit
# Configure ACL 3101 to identify traffic between Router A and Router B.
[RouterA] acl number 3101
[RouterA-acl-adv-3101] rule 0 permit ip source 1.1.1.1 0 destination 2.2.2.2 0
[RouterA-acl-adv-3101] rule 1 permit ip source 2.2.2.2 0 destination 1.1.1.1 0
[RouterA-acl-adv-3101] quit
# Create IPsec transform set tran1.
[RouterA] ipsec transform-set tran1
# Set the packet encapsulation mode to tunnel.
[RouterA-ipsec-transform-set-tran1] encapsulation-mode tunnel
# Use security protocol ESP.
[RouterA-ipsec-transform-set-tran1] transform esp
# Specify encryption and authentication algorithms.
[RouterA-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-128
[RouterA-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[RouterA-ipsec-transform-set-tran1] quit
# Configure IKE peer peer.
[RouterA] ike peer peer
[RouterA-ike-peer-peer] pre-shared-key Ab12<><>
[RouterA-ike-peer-peer] quit
# Create an IKE proposal numbered 10.
[RouterA] ike proposal 10
# Set the authentication algorithm to SHA1.
[RouterA-ike-proposal-10] authentication-algorithm sha
# Set the authentication method to pre-shared key.
[RouterA-ike-proposal-10] authentication-method pre-share
# Set the ISAKMP SA lifetime to 5000 seconds.
[RouterA-ike-proposal-10] sa duration 5000
[RouterA-ike-proposal-10] quit
# Create an IKE-based IPsec policy.
195
[RouterA] ipsec policy map1 10 isakmp
# Reference IPsec transform set tran1.
[RouterA-ipsec-policy-isakmp-map1-10] transform-set tran1
# Reference ACL 3101 to identify the protected traffic.
[RouterA-ipsec-policy-isakmp-map1-10] security acl 3101
# Reference IKE peer peer.
[RouterA-ipsec-policy-isakmp-map1-10] ike-peer peer
[RouterA-ipsec-policy-isakmp-map1-10] quit
# Apply the IPsec policy to interface GigabitEthernet 3/1/1.
[RouterA] interface GigabitEthernet 3/1/1
[RouterA-GigabitEthernet3/1/1] ipsec policy map1
3.
Configure Router B:
# Configure an IP address for GigabitEthernet 3/1/1.
[RouterB] interface GigabitEthernet 3/1/1
[RouterB-GigabitEthernet3/1/1] ip address 2.2.2.2 255.255.0.0
[RouterB-GigabitEthernet3/1/1] quit
# Configure ACL 3101 to identify traffic between Router A and Router B.
[RouterB] acl number 3101
[RouterB-acl-adv-3101] rule 0 permit ip source 2.2.2.2 0 destination 1.1.1.0 0
[RouterB-acl-adv-3101] rule 1 permit ip source 1.1.1.1 0 destination 2.2.2.2 0
[RouterB-acl-adv-3101] quit
# Create IPsec transform set tran1.
[RouterB] ipsec transform-set tran1
# Set the packet encapsulation mode to tunnel.
[RouterB-ipsec-transform-set-tran1] encapsulation-mode tunnel
# Use security protocol ESP.
[RouterB-ipsec-transform-set-tran1] transform esp
# Specify encryption and authentication algorithms.
[RouterB-ipsec-transform-set-tran1] esp encryption-algorithm aes-cbc-128
[RouterB-ipsec-transform-set-tran1] esp authentication-algorithm sha1
[RouterB-ipsec-transform-set-tran1] quit
# Configure IKE peer peer.
[RouterB] ike peer peer
[RouterB-ike-peer-peer] pre-shared-key Ab12<><>
[RouterB-ike-peer-peer] quit
# Create an IKE-based IPsec policy.
[RouterB] ipsec policy use1 10 isakmp
# Reference ACL 3101 to identify the protected traffic.
[RouterB-ipsec-policy-isakmp-use1-10] security acl 3101
# Reference IPsec transform set tran1.
[RouterB-ipsec-policy-isakmp-use1-10] transform-set tran1
# Reference IKE peer peer.
[RouterB-ipsec-policy-isakmp-use1-10] ike-peer peer
[RouterB-ipsec-policy-isakmp-use1-10] quit
# Apply the IPsec policy to interface GigabitEthernet 3/1/1.
196
[RouterB] interface GigabitEthernet 3/1/1
[RouterB-GigabitEthernet3/1/1] ipsec policy use1
Verifying the configuration
After the configuration, IKE negotiation will be triggered when there is traffic between Router A and
Router B.
Router A uses IKE proposal 10 with the authentication algorithm SHA1. Router B uses the default IKE
proposal with the default authentication algorithm SHA. Because Router B has no proposal matching
proposal 10 of Router A, the routers use the default IKE proposals. The routers do not need to have the
same ISAKMP SA lifetime in the matched IKE proposals. The routers will negotiate a lifetime.
Troubleshooting IKE
When you configure parameters to establish an IPsec tunnel, enable IKE error debugging to locate
configuration problems:
<Router> debugging ike error
Invalid user ID
Symptom
Invalid user ID.
Analysis
In IPsec, user IDs identify data flows and set up different IPsec tunnels for different data flows. At present,
the IP address and username of a user are used as the user ID.
The following is the debugging information:
got NOTIFY of type INVALID_ID_INFORMATION
Or
drop message from A.B.C.D due to notification type INVALID_ID_INFORMATION
Solution
Verify that the ACLs in the IPsec policies configured on the interfaces at both ends are compatible.
Configure the ACLs to mirror each other. For more information about ACL mirroring, see "Configuring
IPsec."
Proposal mismatch
Symptom
The proposals mismatch.
Analysis
The following is the debugging information:
got NOTIFY of type NO_PROPOSAL_CHOSEN
Or
drop message from A.B.C.D due to notification type NO_PROPOSAL_CHOSEN
197
The two parties in the negotiation have no matched proposals.
Solution
For the negotiation in phase 1, look up the IKE proposals for a match.
For the negotiation in phase 2, verify that the parameters of the IPsec policies applied on the interfaces
are matched, and that the referred IPsec transform sets have a match in protocol, encryption and
authentication algorithms.
Failing to establish an IPsec tunnel
Symptom
The expected IPsec tunnel cannot be established.
Analysis
Sometimes this may happen if an IPsec tunnel cannot be established or there is no way to communicate
in the presence of an IPsec tunnel in an unstable network.
If ACLs of both parties are configured correctly, and proposals are also matched, the problem is usually
caused by the reboot of one router after the IPsec tunnel is established.
Solution
•
Use the display ike sa command to verify that both parties have established an SA in phase 1.
•
Use the display ipsec sa policy command to verify that the IPsec policy on the interface has
established IPsec SA.
•
If the two commands show that one party has an SA but the other does not, use the reset ipsec sa
command to clear the IPsec SA that has no corresponding SA, use the reset ike sa command to
clear the IKE SA that has no corresponding IKE SA, and trigger SA re-negotiation.
ACL configuration error
Symptom
ACL configuration error results in data flow blockage.
Analysis
When multiple devices create different IPsec tunnels early or late, a device may have multiple peers. If the
device is not configured with ACL rule, the peers send packets to it to set up different IPsec tunnels in
different protection granularity respectively. As the priorities of IPsec tunnels are determined by the order
they are established, a device cannot interoperate with other peers in fine granularity when its outbound
packets are first matched with an IPsec tunnel in coarse granularity.
Solution
When a device has multiple peers, configure ACLs on the device to distinguish different data flows and
try to avoid configuring overlapping ACL rules for different peers. If it is unavoidable, the subrules in fine
granularity should be configured with higher preferences.
198
Configuring SSH
Overview
Secure Shell (SSH) is a network security protocol. Using encryption and authentication, SSH can
implement remote login and file transfer securely over an insecure network.
Adopting the typical client/server model, SSH can establish a channel to protect data transfer based on
TCP. SSH includes two versions: SSH1.x and SSH2.0 (hereinafter referred to as SSH1 and SSH2), which
are not compatible. SSH2 is better than SSH1 in performance and security. The device can not only work
as an SSH server to provide services to SSH clients, but also work as an SSH client to allow users to
establish SSH connections with a remote SSH server. When acting as an SSH server, the device supports
SSH and SSH1. When acting as an SSH client, the device supports SSH2 only.
The device supports the following SSH applications:
•
Secure Telnet (Stelnet)—Provides secure and reliable network terminal access services. Through
Stelnet, a user can log in to a remote server securely. Stelnet can protect devices against attacks
such as IP spoofing and plain text password interception. The device can act as both the Stelnet
server and Stelnet client.
•
Secure File Transfer Protocol (SFTP)—Based on SSH2, SFTP uses the SSH connection to provide
secure file transfer. The device can serve as the SFTP server, allowing a remote user to log in to the
SFTP server for secure file management and transfer. The device can also serve as an SFTP client,
enabling a user to log in from the device to a remote device for secure file transfer.
•
Secure Copy (SCP)—Based on SSH2, SCP offers a secure method for copying files. The device can
act as the SCP server, allowing a user to log in to the device for file upload and download. The
device can also act as an SCP client, enabling a user to log in from the device to a remote server
for secure file transfer.
How SSH works
This section uses SSH2 as an example.
To establish an SSH connection and communicate with each other through the connection, an SSH client
and an SSH server go through the stages listed in Table 8. For more information about these stages, see
SSH Technology White Paper.
Table 8 Stages involved in secure session establishment
Stages
Description
Connection establishment
The SSH server listens to the connection requests on port 22. After a client
initiates a connection request, the server and the client establish a TCP
connection.
Version negotiation
The two parties determine a version to use after negotiation.
199
Stages
Description
Algorithm negotiation
SSH supports multiple algorithms. Based on the local algorithms, the two parties
determine the key exchange algorithm for generating session keys, the
encryption algorithm for encrypting data, public key algorithm for digital
signature and authentication, and the HMAC algorithm for protecting data
integrity.
Key exchange
The two parties use the Diffie-Hellman (DH) exchange algorithm to dynamically
generate the session key for protecting data transfer and the session ID for
identifying the SSH connection. In this stage, the client authenticates the server
as well.
Authentication
The SSH server authenticates the client in response to the client's authentication
request.
Session request
After passing authentication, the client sends a session request to the server to
request the establishment of a session (Stelnet or SFTP).
After the server grants the request, the client and the server start to communicate
with each other in the session.
Interaction
In this stage, you can execute commands from the client by pasting the
commands in text format (the text must be within 2000 bytes). The commands
must be available in the same view. Otherwise, the server might not be able to
execute the commands correctly.
To execute commands of more than 2000 bytes, save the commands in a
configuration file, upload it to the server through SFTP, and use it to restart the
server.
SSH authentication
When the device acts as an SSH server, it supports the following authentication methods:
•
Password authentication—The SSH server uses AAA for authentication of the client. During
password authentication, the SSH client encrypts its username and password, encapsulates them
into an authentication request, and sends the request to the server. After receiving the request, the
SSH server decrypts the request to get the username and password in plain text, checks the validity
of the username and password locally or by a remote AAA server, and then informs the client of the
authentication result.
When the remote AAA server checks the validity of the username, it requires the user for a
password secondary authentication by sending the SSH server an authentication response with a
prompt. The prompt is transparently transmitted to the client, and displayed on the client to notify
the user to enter a specified password. After the user enters the correct password and passes
validity check by the remote AAA server, the device returns an authentication success message to
the client.
NOTE:
Only clients that run SSH2 or a later version support password secondary authentication that is initiated
by the AAA server.
•
Publickey authentication—The server authenticates the client by the digital signature. During
publickey authentication, the client sends the server a publickey authentication request that contains
its username, public key, and publickey algorithm information (or the digital certificate that carries
the public key information). The server checks whether the public key is valid. If the public key is
200
invalid, the authentication fails. Otherwise, the server authenticates the client by the digital
signature. Finally, it informs the client of the authentication result. The device supports using the
publickey algorithms RSA and DSA for digital signature.
A client can send public key information to the device that acts as the server for validity check in
either of the following methods:
{
{
The client directly sends the user's public key information to the server, and the server checks the
validity of the user's public key.
The client sends the user's public key information to the server through a digital certificate, and
the server checks the validity of the digital certificate. When acting as a client, the device does
not support this method.
•
Password-publickey authentication—The server requires clients that run SSH2 to pass both
password authentication and publickey authentication. However, if a client runs SSH1, it only needs
to pass either authentication.
•
Any authentication—The server requires the client to pass either of password authentication and
publickey authentication.
SSH support for MPLS L3VPN
With this function, you can configure the device as an SSH client to establish connections with SSH
servers in different MPLS L3VPNs.
As shown in Figure 65, the hosts in VPN 1 and VPN 2 access the MPLS backbone through PEs, with the
services of the two VPNs isolated. After a PE is enabled with the SSH client function, it can establish SSH
connections with CEs in different VPNs that are enabled with the SSH server function to implement secure
access to the CEs and secure transfer of log file.
Figure 65 Network diagram
FIPS compliance
The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for features,
commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and non-FIPS mode.
201
Configuring the device as an SSH server
You can configure the device as an Stelnet server or SFTP server. Because the configuration procedures
are similar, the SSH server represents the Stelnet server and SFTP server unless otherwise specified.
SSH server configuration task list
Task
Remarks
Generating local DSA or RSA key pairs
Required.
Enabling the SSH server function
Required for Stelnet, SFTP and SCP servers.
Enabling the SFTP server function
Required only for SFTP server.
Configuring the user interfaces for SSH clients
Required.
Configuring a client's host public key
Required if publickey authentication is configured for
users and the clients directly send the public keys to
the server for validity check.
See "Configuring PKI."
Configuring the PKI domain of the client certificate
Required if publickey authentication is configured for
users and the clients send the public keys to the server
through digital certificates for validity check.
The PKI domain must have the CA certificate to verify
the client certificate.
Configuring an SSH user
Required for publickey authentication users and
optional for other authentication users.
Setting the SSH management parameters
Optional.
Generating local DSA or RSA key pairs
DSA or RSA key pairs are required for generating the session key and session ID in the key exchange
stage, and can also be used by a client to authenticate the server. When a client tries to communicate
with a server, it compares the public key that it receives from the server with the server public key that it
saved locally. If the keys are consistent, the client uses the public key to authenticate the digital signature
that receives from the server. If the digital signatures are consistent, the authentication succeeds. If the
digital signatures are consistent, the authentication succeeds.
To support SSH clients that use different types of key pairs, generate both DSA and RSA key pairs on the
SSH server.
Configuration guidelines
•
The public-key local create rsa command generates a server RSA key pair and a host RSA key pair.
Each of the key pairs consists of a public key and a private key. The public key in the server key pair
of the SSH server is used in SSH1 to encrypt the session key for secure transmission of the key. As
SSH2 uses the DH algorithm to generate the session key on the SSH server and client, no session
key transmission is required in SSH2 and the server key pair is not used.
•
The public-key local create dsa command generates only the host key pair.
202
SSH1 does not support the DSA algorithm.
•
Configuration procedure
To generate local DSA or RSA key pairs on the SSH server:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Generate DSA or RSA key
pairs.
public-key local create { dsa | rsa }
By default, neither DSA key pair
nor RSA key pairs exist.
Enabling the SSH server function
The SSH server function on the device allows clients to communicate with the device through SSH.
To enable the SSH server function:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the SSH server
function.
ssh server enable
Disabled by default.
NOTE:
When the device acts as an SCP server, only one SCP user is allowed to access to the SCP server at one
time.
Enabling the SFTP server function
This SFTP server function enables clients to log in to the SFTP server through SFTP.
To enable the SFTP server function:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the SFTP server
function.
sftp server enable
Disabled by default.
NOTE:
When the device functions as the SFTP server, only one client can access the SFTP server at a time.
Configuring the user interfaces for SSH clients
An SSH client accesses the device through a VTY user interface. You must configure the user interfaces for
SSH clients to allow SSH login. The configuration takes effect only for the clients that try to log in after the
configuration.
203
IMPORTANT:
Before you configure a user interface to support SSH, you must configure its authentication mode to
scheme. Otherwise, the protocol inbound command fails.
To configure the user interface for SSH clients:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter VTY user interface view.
user-interface vty number
[ ending-number ]
N/A
3.
Set the login authentication
mode to scheme.
authentication-mode scheme
By default, the authentication
mode is password.
4.
Configure the user interface to
support SSH login.
protocol inbound { all | ssh }
Optional.
By default, Telnet, PAD, and SSH
are supported.
For more information about the authentication-mode and protocol inbound commands, see
Fundamentals Command Reference.
Configuring a client's host public key
This configuration task is only necessary if publickey authentication is configured for users and the clients
directly send the public key to the server for validity check.
During publickey authentication, when a client directly sends the public key to the server for validity
check, the server first compares the SSH username and host public key that it receives from the client with
those saved locally. If the information is consistent, it checks the digital signature that the client sends. The
digital signature is calculated by the client according to the private key that corresponds to the host
public key.
You must configure the client's DSA or RSA host public key on the server, and specify the corresponding
host private key on the client to generate the digital signature, so that the client can pass publickey
authentication with correct digital signature. If the device serves as a client, corresponding host private
key is specified by the specified public key algorithm.
You can manually configure the public key of an SSH client on the server, or import it from the public key
file:
•
Manually configuring the client's host public key—You can type or copy the client host public key
on the client to the SSH server. The host public key must be in the DER encoding format, which has
not been converted.
If you use the device to act as the client, you can use the display public-key local public command
to view the host public key and copy its contents to the server. A host public key obtained in other
ways might be in incorrect format and cannot be saved on the server. HP recommends that you
configure a client public key by importing it from a public key file.
•
Import the client's host public key from the public key file—You can upload the client's host public
key file (in binary) to the server, for example, through FTP or TFTP, and import the uploaded file to
the server. During the import process, the server automatically converts the public key in the public
key file to a string in PKCS format.
You can configure up to 20 SSH client public keys on an SSH server.
204
Configuring a client public key manually
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter public key view.
public-key peer keyname
N/A
3.
Enter public key code view.
public-key-code begin
N/A
4.
Configure a client's host
public key.
Enter the content of the host public
key
Spaces and carriage returns are
allowed between characters.
5.
Return to public key view and
save the configured host
public key.
public-key-code end
When you exit public key code
view, the system automatically
saves the public key.
Return to system view.
peer-public-key end
N/A
6.
Importing a client public key from a public key file
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Import the public key from a
public key file.
public-key peer keyname import
sshkey filename
N/A
For more information about client public key configuration, see "Managing public keys."
Configuring an SSH user
To configure an SSH user that uses publickey authentication, you must perform the procedure in this
section.
To configure an SSH user that uses password authentication, whether together with publickey
authentication or not, you must configure a local user account by using the local-user command for local
authentication, or configure an SSH user account on an authentication server, for example, a RADIUS
server, for remote authentication. For more information about the local-user command, see Security
Command Reference.
For password-only SSH users, you do not need to perform the procedure in this section to configure them
unless you want to use the display ssh user-information command to display all SSH users, including the
password-only SSH users, for centralized management.
Configuration guidelines
When you perform the procedure in this section to configure an SSH user, follow these guidelines:
•
You can set the service type to Stelnet, SFTP or SCP.
•
You can enable one of the following authentication modes for the SSH user:
{
Password—The user must pass password authentication.
{
Publickey authentication—The user must pass publickey authentication.
{
Password-publickey authentication—As an SSH2.0 user, the user must pass both password and
publickey authentication. As an SSH1 user, the user must pass either password or publickey
authentication.
205
{
Any—The user can use either password authentication or publickey authentication.
Except password authentication, the other authentication methods require a client's host public key
or digital certificate to be specified.
•
{
{
If a client directly sends the user's public key information to the server, the server must specify the
client's public key and the specified public key must be already existed. For more information
about public keys, see "Configuring a client's host public key."
If a client sends the user's public key information to the server through a digital certificate, the
server must specify the PKI domain to verify the client certificate. For more information about
configuring PKI domain, see "Configuring PKI." The CA certificate in the specified PKI domain
must be available for verification to guarantee that the authorized SSH users pass the
authentication.
•
If publickey authentication, whether with password authentication or not, is used, the command
level accessible to the user is set by the user privilege level command on the user interface. If only
password authentication is used, the command level accessible to the user is authorized by AAA.
•
SSH1 does not support SFTP or SCP. For an SSH1 client, you must set the service type to stelnet or
all.
•
For an SFTP SSH user, the working folder depends on the authentication method:
{
{
If only password authentication is used, the working folder is authorized by AAA.
If publickey authentication, whether with password authentication or not, is used, the working
folder is set by using the ssh user command.
If you change the authentication mode or public key for an SSH user that has been logged in, the
change can take effect only at the next login of the user.
•
Configuration procedure
To configure an SSH user and specify the service type and authentication method:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Create an SSH user, and specify the service type
2.
Create an SSH user, and
specify the service type
and authentication
method.
and authentication method for Stelnet users:
ssh user username service-type stelnet
authentication-type { password | { any |
password-publickey | publickey } assign
{ pki-domain pkiname | publickey keyname } }
• Create an SSH user, and specify the service type
and authentication method for all users, SCP or
SFTP users:
ssh user username service-type { all | scp | sftp }
authentication-type { password | { any |
password-publickey | publickey } assign
{ pki-domain pkiname | publickey keyname }
work-directory directory-name }
Use either command.
The any and
publickey keywords
are not available in
FIPS mode.
Setting the SSH management parameters
Setting the SSH management parameters can improve the security of SSH connections. The SSH
management parameters include:
206
•
Whether the SSH server is compatible with SSH1 client.
•
RSA server key pair update interval, applicable to users using SSH1 client.
•
SSH user authentication timeout period. You can set this parameter to reject a connection if the
authentication for the connection has not been finished before the timeout period expires.
•
Maximum number of SSH authentication attempts. You can set this parameter to prevent malicious
password cracking.
•
SFTP connection idle timeout period. Once the idle period of an SFTP connection exceeds the
specified threshold, the system automatically tears the connection down.
To set the SSH management parameters:
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Enable the SSH server to
support SSH1 clients.
ssh server compatible-ssh1x
enable
3.
Set the RSA server key pair
update interval.
ssh server rekey-interval hours
By default, the interval is 0, and the
RSA server key pair is not updated.
4.
Set the SSH user
authentication timeout period.
ssh server authentication-timeout
time-out-value
Optional.
Set the maximum number of
SSH authentication attempts.
ssh server authentication-retries
times
Optional.
Configure the SFTP
connection idle timeout
period.
sftp server idle-timeout
time-out-value
Optional.
5.
6.
Optional.
By default, the SSH server supports
SSH1 clients.
Optional.
60 seconds by default.
3 by default.
10 minutes by default.
NOTE:
Authentication fails if the number of authentication attempts (including both publickey and password
authentication) exceeds that specified by the ssh server authentication-retries command.
Configuring the device as an Stelnet client
Stelnet client configuration task list
Task
Remarks
Specifying a source IP address or source interface for the Stelnet
client
Optional.
Enabling/disabling first-time authentication
Optional.
Establishing a connection to an Stelnet server
Required.
207
Specifying a source IP address or source interface for the
Stelnet client
By default, an Stelnet client uses the IP address of the outbound interface specified by the route to the
Stelnet server when communicating with the Stelnet server. You can specify a source IP address or source
interface for the client to communicate with the server. To make sure that the Stelnet client and the Stelnet
server can communicate with each other, and to improve the manageability of Stelnet clients in the
authentication service, HP recommends that you specify a loopback interface or dialer interface as the
source interface.
To specify a source IP address or source interface for the Stelnet client:
Step
Enter system view.
1.
Specify a source IP address
or source interface for the
Stelnet client.
2.
Command
Remarks
system-view
N/A
• Specify a source IPv4 address or source
Select either method.
interface for the Stelnet client:
ssh client source { interface interface-type
interface-number | ip ip-address }
• Specify a source IPv6 address or source
interface for the Stelnet client:
ssh client ipv6 source { interface
interface-type interface-number | ipv6
ipv6-address }
By default, an Stelnet
client uses the IP address
of the outbound
interface specified by
the route to the Stelnet
server when
communicating with the
Stelnet server.
Enabling/disabling first-time authentication
When the device works as an SSH client and connects to the SSH server, you can configure whether the
device supports first-time authentication.
•
If first-time authentication is not supported, a client not configured with the server host public key
refuses to access the server. To enable the client to access the server, you must configure the server
host public key locally and specify the public key name for authentication on the client in advance.
•
If first-time authentication is supported, when a client not configured with the server host public key
accesses the server for the first time, the user can continue accessing the server, and save the host
public key on the client. When accessing the server again, the client will use the saved server host
public key to authenticate the server. In a secure network, first-time authentication can simplify client
configuration, but also bring some potential security risks.
Enabling first-time authentication
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Enable first-time
authentication.
ssh client first-time enable
Disabling first-time authentication
208
Optional.
Enabled by default.
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Disable first-time
authentication.
undo ssh client first-time
Enabled by default.
3.
Configure the server host
public key.
See "Configuring a client's host
public key"
The method for configuring the
server host public key on the client
is similar to that for configuring
client public key on the server.
4.
Specify the host public key
name of the server.
ssh client authentication server
server assign publickey keyname
N/A
Establishing a connection to an Stelnet server
You can start the Stelnet client to establish a connection to an Stelnet server, and specify the public key
algorithm, the preferred encryption algorithm, the preferred HMAC algorithm, and the preferred key
exchange algorithm.
To establish a connection to an Stelnet server:
Task
Command
Remarks
• Establish a connection to an IPv4 server:
Establish a connection
to an Stelnet server.
ssh2 server [ port-number ] [ vpn-instance
vpn-instance-name ] [ identity-key { dsa | rsa } |
prefer-compress { zlib | zlib-openssh } |
prefer-ctos-cipher { 3des | aes128 | aes256 | des } |
prefer-ctos-hmac { md5 | md5-96 | sha1 | sha1-96 }
| prefer-kex { dh-group-exchange | dh-group1 |
dh-group14 } | prefer-stoc-cipher { 3des | aes128 |
aes256 | des } | prefer-stoc-hmac { md5 | md5-96 |
sha1 | sha1-96 } ] *
• Establish a connection to an IPv6 server:
ssh2 ipv6 server [ port-number ] [ vpn-instance
vpn-instance-name ] [ identity-key { dsa | rsa } |
prefer-compress { zlib | zlib-openssh }
|prefer-ctos-cipher { 3des | aes128 | aes256 | des } |
prefer-ctos-hmac { md5 | md5-96 | sha1 | sha1-96 }
| prefer-kex { dh-group-exchange | dh-group1 |
dh-group14 } | prefer-stoc-cipher { 3des | aes128 |
aes256 | des } | prefer-stoc-hmac { md5 | md5-96 |
sha1 | sha1-96 } ] *
Use either command in
user view.
Algorithms dsa, 3des,
des, md5, md5-96,
dh-group-exchange,
and dh-group1 are not
available in FIPS mode.
Only the algorithm
aes256 is available in
FIPS mode.
Configuring the device as an SFTP client
SFTP client configuration task list
Task
Remarks
Specifying a source IP address or source interface for the SFTP client
Optional.
209
Task
Remarks
Enabling/disabling first-time authentication
Optional.
Establishing a connection to an SFTP server
Required.
Working with SFTP directories
Optional.
Working with SFTP files
Optional.
Displaying help information
Optional.
Terminating the connection with the SFTP server
Optional.
Specifying a source IP address or source interface for the SFTP
client
By default, an SFTP client uses the IP address of the outbound interface specified by the route to the SFTP
server when communicating with the SFTP server. You can specify a source IP address or source interface
for the client to communicate with the server. To make sure that the SFTP client and the SFTP server can
communicate with each other, and to improve the manageability of SFTP clients in the authentication
service, HP recommends that you specify a loopback interface or dialer interface as the source interface.
To specify a source IP address or interface for the SFTP client:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• Specify a source IPv4 address or interface
2.
Specify a source IP
address or interface for
the SFTP client.
for the SFTP client:
sftp client source { ip ip-address |
interface interface-type
interface-number }
• Specify a source IPv6 address or interface
for the SFTP client:
sftp client ipv6 source { ipv6 ipv6-address
| interface interface-type
interface-number }
Use either command.
By default, an SFTP client uses
the IP address of the outbound
interface specified by the route
to the SFTP server when
communicating with the SFTP
server.
Establishing a connection to an SFTP server
You can start the SFTP client to establish a connection to an SFTP server, and specify the public key
algorithm, the preferred encryption algorithm, preferred HMAC algorithm, and preferred key exchange
algorithm. After the connection is established, you can directly enter SFTP client view on the server to
perform directory and file operations.
To establish a connection to an SFTP server:
210
Task
Remarks
Command
• Establish a connection to an IPv4 SFTP server:
Establish a connection
to an SFTP server and
enter SFTP client view.
sftp server [ port-number ] [ vpn-instance
vpn-instance-name ] [ identity-key { dsa | rsa } |
prefer-compress { zlib | zlib-openssh }
|prefer-ctos-cipher { 3des | aes128 | aes256 |
des } | prefer-ctos-hmac { md5 | md5-96 | sha1 |
sha1-96 } | prefer-kex { dh-group-exchange |
dh-group1 | dh-group14 } | prefer-stoc-cipher
{ 3des | aes128 | aes256 | des } |
prefer-stoc-hmac { md5 | md5-96 | sha1 |
sha1-96 } ] *
• Establish a connection to an IPv6 SFTP server:
sftp ipv6 server [ port-number ] [ vpn-instance
vpn-instance-name ] [ identity-key { dsa | rsa }|
prefer-compress { zlib | zlib-openssh } |
prefer-ctos-cipher { 3des | aes128 | aes256 |
des } | prefer-ctos-hmac { md5 | md5-96 | sha1 |
sha1-96 } | prefer-kex { dh-group-exchange |
dh-group1 | dh-group14 } | prefer-stoc-cipher
{ 3des | aes128 | aes256 | des } |
prefer-stoc-hmac { md5 | md5-96 | sha1 |
sha1-96 } ] *
Use either command in
user view.
Algorithms dsa, 3des,
des, md5, md5-96,
dh-group-exchange, and
dh-group1 are not
available in FIPS mode.
Only the algorithm
aes256 is available in
FIPS mode.
Working with SFTP directories
SFTP directory operations include:
•
Changing or displaying the current working directory
•
Displaying files under a specified directory or the directory information
•
Changing the name of a specified directory on the server
•
Creating or deleting a directory
To work with the SFTP directories:
Step
Command
Remarks
1.
Enter SFTP client view.
For more information, see
"Establishing a connection to an
SFTP server."
N/A
2.
Change the working directory
of the remote SFTP server.
cd [ remote-path ]
Optional.
3.
Return to the upper-level
directory.
cdup
Optional.
4.
Display the current working
directory on the SFTP server.
pwd
Optional.
5.
Display files under a specified
directory.
• dir [ -a | -l ] [ remote-path ]
• ls [ -a | -l ] [ remote-path ]
211
Optional.
The dir command functions as the
ls command.
Command
Remarks
Change the name of a
specified directory on the
SFTP server.
rename oldname newname
Optional.
7.
Create a new directory on the
SFTP server.
mkdir remote-path
Optional.
8.
Delete one or more directories
from the SFTP server.
rmdir remote-path&<1-10>
Optional.
Command
Remarks
Step
6.
Working with SFTP files
SFTP file operations include:
•
Changing the name of a file
•
Downloading a file
•
Uploading a file
•
Displaying a list of the files
•
Deleting a file
To work with SFTP files:
Step
1.
Enter SFTP client view.
For more information, see
"Establishing a connection to an
SFTP server."
N/A
2.
Change the name of a
specified file on the SFTP
server.
rename old-name new-name
Optional.
Download a file from the
remote server and save it
locally.
get remote-file [ local-file ]
Optional.
4.
Upload a local file to the SFTP
server.
put local-file [ remote-file ]
Optional.
5.
Display the files under a
specified directory.
• dir [ -a | -l ] [ remote-path ]
• ls [ -a | -l ] [ remote-path ]
6.
Delete one or more directories
from the SFTP server.
• delete remote-file&<1-10>
• remove remote-file&<1-10>
3.
Optional.
The dir command functions as the
ls command.
Optional.
The delete command functions as
the remove command.
Displaying help information
This configuration task will display a list of all commands or the help information of an SFTP client
command, such as the command format and parameters.
To display a list of all commands or the help information of an SFTP client command:
212
Command
Step
1.
Enter SFTP client view.
For more information, see "Establishing a connection to an
SFTP server."
2.
Display a list of all commands or the help
information of an SFTP client command.
help [ all | command-name ]
Terminating the connection with the SFTP server
Step
Command
Remarks
N/A
1.
Enter SFTP client view.
For more information, see
"Establishing a connection to an
SFTP server."
2.
Terminate the connection with
the SFTP server and return to
user view.
• bye
• exit
• quit
Use any of the commands.
These three commands function in
the same way.
Configuring the device as an SCP client
SCP client configuration task list
Task
Remarks
Enabling/disabling first-time authentication
Optional.
Transferring files with an SCP server
Required.
Transferring files with an SCP server
213
Task
Remarks
Command
• Upload a file to the SCP server:
Connect to the SCP
server, and transfer files
with the server.
scp [ ipv6 ] server [ port-number ] put source-file-path
[ destination-file-path ] [ identity-key { dsa | rsa } |
prefer-compress { zlib | zlib-openssh } |
prefer-ctos-cipher { 3des | aes128 | aes256 | des }
| prefer-ctos-hmac { md5 | md5-96 | sha1 |
sha1-96 } | prefer-kex { dh-group-exchange |
dh-group1 | dh-group14 } | prefer-stoc-cipher
{ 3des | aes128 | aes256 | des } | prefer-stoc-hmac
{ md5 | md5-96 | sha1 | sha1-96 } ] *
• Download a file from the SCP server:
scp [ ipv6 ] server [ port-number ] get source-file-path
[ destination-file-path ] [ identity-key { dsa | rsa } |
prefer-compress { zlib | zlib-openssh } |
prefer-ctos-cipher { 3des | aes128 | aes256 | des }
| prefer-ctos-hmac { md5 | md5-96 | sha1 |
sha1-96 } | prefer-kex { dh-group-exchange |
dh-group1 | dh-group14 } | prefer-stoc-cipher
{ 3des | aes128 | aes256 | des } | prefer-stoc-hmac
{ md5 | md5-96 | sha1 | sha1-96 } ] *
Use either command.
Only SSH users whose
user privilege levels are
3 can upload files to the
SCP server.
Algorithms dsa, 3des,
des, md5, md5-96,
dh-group-exchange,
and dh-group1 are not
available in FIPS mode.
Only the algorithm
aes256 is available in
FIPS mode.
Displaying and maintaining SSH
Task
Command
Remarks
Display the source IP address or
interface configured for the SFTP
client.
display sftp client source [ | { begin | exclude
| include } regular-expression ]
Available in any view.
Display the source IP address or
interface information configured for
the Stelnet client.
display ssh client source [ | { begin | exclude
| include } regular-expression ]
Available in any view.
Display SSH server status
information or session information
on an SSH server.
display ssh server { status | session } [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display the mappings between
SSH servers and their host public
keys on an SSH client.
display ssh server-info [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display information about one or
all SSH users on an SSH server.
display ssh user-information [ username ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display the public keys of the local
key pairs.
display public-key local { dsa | rsa } public
[ | { begin | exclude | include }
regular-expression ]
Available in any view.
Display the public keys of the SSH
peers.
display public-key peer [ brief | name
publickey-name ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
214
Stelnet configuration examples
When the router acts as an Stelnet server for password
authentication
Network requirements
As shown in Figure 66, you can log in to the router through the Stelnet client (SSH2) that runs on the host.
The router acts as the Stelnet server and uses password authentication. The username and password of
the client are saved on the router.
Figure 66 Network diagram
Stelnet client
192.168.1.56/24
Stelnet server
GE3/1/1
192.168.1.40/24
Host
Router
Configuration procedure
1.
Configure the Stelnet server:
# Generate the RSA key pairs.
<Router> system-view
[Router] public-key local create rsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++++
++++++++++++++
+++++
++++++++
# Generate a DSA key pair.
[Router] public-key local create dsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++
# Enable the SSH server function.
[Router] ssh server enable
215
# Configure an IP address for interface GigabitEthernet 3/1/1, which the Stelnet client will use as
the destination for SSH connection.
[Router] interface GigabitEthernet 3/1/1
[Router-GigabitEthernet3/1/1] ip address 192.168.1.40 255.255.255.0
[Router-GigabitEthernet3/1/1] quit
# Set the authentication mode for the user interface to AAA.
[Router] user-interface vty 0 4
[Router-ui-vty0-4] authentication-mode scheme
# Enable the user interface to support SSH.
[Router-ui-vty0-4] protocol inbound ssh
[Router-ui-vty0-4] quit
# Create local user client001 with the password as aabbcc and service type as ssh.
[Router] local-user client001
[Router-luser-client001] password simple aabbcc
[Router-luser-client001] service-type ssh
[Router-luser-client001] quit
# (Optional.) Specify the service type for user client001 as stelnet, and the authentication method
as password.
[Router] ssh user client001 service-type stelnet authentication-type password
2.
Establish a connection to the Stelnet server:
The device supports a variety of Stelnet client software, such as PuTTY, and OpenSSH. This
example uses an Stelnet client that runs PuTTY Version 0.58.
To establish a connection to the Stelnet server:
a. Launch PuTTY.exe to enter the interface as shown in Figure 67.
b. In the Host Name (or IP address)field, enter the IP address of the Stelnet server.
216
Figure 67 Specifying the host name (or IP address)
c. Click Open to connect to the server.
If the connection is successfully established, the system asks you to enter the username and
password. After entering the username (client001) and password (aabbcc), you can enter the
command-line interface of the server.
When the router acts as an Stelnet server for publickey
authentication
Network requirements
As shown in Figure 68, you can log in to the router through the Stelnet client (SSH2) that runs on the host.
The router acts as the Stelnet server, adopting publickey authentication and the RSA public key algorithm.
Figure 68 Network diagram
Stelnet client
192.168.1.56/24
Host
Stelnet server
GE3/1/1
192.168.1.40/24
Router
217
Configuration procedure
In the server configuration, the client public key is required. Use the client software to generate the RSA
key pair on the client before configuring the Stelnet server.
The device supports a variety of Stelnet client software, such as PuTTY, and OpenSSH. This example uses
an Stelnet client that runs PuTTY Version 0.58.
1.
Configure the Stelnet client:
# Generate an RSA key pair.
a. Run PuTTYGen.exe, select SSH-2 RSA and click Generate.
Figure 69 Generating a key pair on the client
When the generator is generating the key pair, you must move the mouse continuously and
keep the mouse off the green progress bar shown in Figure 70. Otherwise, the progress bar
stops moving and the key pair generating progress stops.
218
Figure 70 Generating process
b. After the key pair is generated, click Save public key and specify the file name as key.pub to
save the public key.
Figure 71 Saving a key pair on the client
219
c. Click Save private key to save the private key.
A warning window pops up to prompt you whether to save the private key without any
protection.
d. Click Yes and enter the name of the file for saving the key (private.ppk in this case).
e. Transmit the public key file to the server through FTP or TFTP. (Details not shown.)
2.
Configure the Stelnet server:
# Generate the RSA key pairs.
<Router> system-view
[Router] public-key local create rsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++++
++++++++++++++
+++++
++++++++
# Generate a DSA key pair.
[Router] public-key local create dsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++
# Enable the SSH server function.
[Router] ssh server enable
# Configure an IP address for interface GigabitEthernet 3/1/1, which the Stelnet client will use as
the destination for SSH connection.
[Router] interface GigabitEthernet 3/1/1
[Router-GigabitEthernet3/1/1] ip address 192.168.1.40 255.255.255.0
[Router-GigabitEthernet3/1/1] quit
# Set the authentication mode for the user interface to AAA.
[Router] user-interface vty 0 4
[Router-ui-vty0-4] authentication-mode scheme
# Enable the user interface to support SSH.
[Router-ui-vty0-4] protocol inbound ssh
[Router-ui-vty0-4] quit
# Import the client's public key from file key.pub and name it ClientKey.
[Router] public-key peer ClientKey import sshkey key.pub
# Specify the authentication method for user client002 as publickey, and assign the public key
ClientKey to the user.
220
[Router] ssh user client002 service-type stelnet authentication-type publickey assign
publickey ClientKey
3.
Specify the private key file and establish a connection to the Stelnet server:
a. Launch PuTTY.exe on the Stelnet client to enter the interface as shown in Figure 72.
b. In the Host Name (or IP address) field, enter the IP address of the Stelnet server
(192.168.1.40).
Figure 72 Specifying the host name (or IP address)
c. Select Connection > SSH > Auth from the navigation tree.
The window as shown in Figure 73 appears.
d. Click Browse… to bring up the file selection window, navigate to the private key file
(private.ppk) and click OK.
221
Figure 73 Specifying the private key file
e. Click Open to connect to the server.
If the connection is successfully established, the system asks you to enter the username. After
entering the username (client002), you can enter the command-line interface of the server.
When the router acts as an Stelnet client for password
authentication
Network requirements
As shown in Figure 74, you can log in to Router B through the Stelnet client running on Router A. Router
B acts as the Stelnet server and uses password authentication. The username and password of the client
are saved on Router B.
Figure 74 Network diagram
Stelnet client
GE3/1/1
192.168.1.56/24
Stelnet server
GE3/1/1
192.168.1.40/24
Router A
Router B
Configuration procedure
1.
Configure the Stelnet server:
# Generate the RSA key pairs.
<RouterB> system-view
[RouterB] public-key local create rsa
222
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++++
++++++++++++++
+++++
++++++++
# Generate a DSA key pair.
[RouterB] public-key local create dsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++
# Enable the SSH server function.
[RouterB] ssh server enable
# Configure an IP address for interface GigabitEthernet 3/1/1, which the Stelnet client will use as
the destination address of the SSH connection.
[RouterB] interface GigabitEthernet 3/1/1
[RouterB-GigabitEthernet3/1/1] ip address 192.168.1.40 255.255.255.0
[RouterB-GigabitEthernet3/1/1] quit
# Set the authentication mode for the user interface to AAA.
[RouterB] user-interface vty 0 4
[RouterB-ui-vty0-4] authentication-mode scheme
# Enable the user interface to support SSH.
[RouterB-ui-vty0-4] protocol inbound ssh
[RouterB-ui-vty0-4] quit
# Create local user client001, with the password as aabbcc and service type as ssh.
[RouterB] local-user client001
[RouterB-luser-client001] password simple aabbcc
[RouterB-luser-client001] service-type ssh
[RouterB-luser-client001] quit
# (Optional.) Specify the service type for user client001 as stelnet, and the authentication method
as password.
[RouterB] ssh user client001 service-type stelnet authentication-type password
2.
Establish a connection to the Stelnet server:
# Configure an IP address for interface GigabitEthernet 3/1/1.
<RouterA> system-view
[RouterA] interface GigabitEthernet 3/1/1
[RouterA-GigabitEthernet3/1/1] ip address 192.168.1.56 255.255.255.0
[RouterA-GigabitEthernet3/1/1] quit
223
[RouterA] quit
{
If the client supports first-time authentication, you can directly establish a connection from the
client to the server.
# Establish an SSH connection to the Stelnet server 192.168.1.40.
<RouterA> ssh2 192.168.1.40
Username: client001
Trying 192.168.1.40 ...
Press CTRL+K to abort
Connected to 192.168.1.40 ...
The Server is not authenticated. Continue? [Y/N]:y
Do you want to save the server public key? [Y/N]:n
Enter password:
After you enter the correct password, you can log in to Router B successfully.
{
If the client does not support first-time authentication, perform the following configurations.
# Disable first-time authentication.
[RouterA] undo ssh client first-time
# Configure the host public key of the SSH server. You can get the server host public key by
using the display public-key local dsa public command on the server, because the client uses
the DSA server host public key to authenticate the server by default.
[RouterA] public-key peer key1
[RouterA-pkey-public-key] public-key-code begin
[RouterA-pkey-key-code]308201B73082012C06072A8648CE3804013082011F0281810
0D757262C4584C44C211F18BD96E5F0
[RouterA-pkey-key-code]61C4F0A423F7FE6B6B85B34CEF72CE14A0D3A5222FE08CECE
65BE6C265854889DC1EDBD13EC8B274
[RouterA-pkey-key-code]DA9F75BA26CCB987723602787E922BA84421F22C3C89CB9B0
6FD60FE01941DDD77FE6B12893DA76E
[RouterA-pkey-key-code]EBC1D128D97F0678D7722B5341C8506F358214B16A2FAC4B3
68950387811C7DA33021500C773218C
[RouterA-pkey-key-code]737EC8EE993B4F2DED30F48EDACE915F0281810082269009E
14EC474BAF2932E69D3B1F18517AD95
[RouterA-pkey-key-code]94184CCDFCEAE96EC4D5EF93133E84B47093C52B20CD35D02
492B3959EC6499625BC4FA5082E22C5
[RouterA-pkey-key-code]B374E16DD00132CE71B020217091AC717B612391C76C1FB2E
88317C1BD8171D41ECB83E210C03CC9
[RouterA-pkey-key-code]B32E810561C21621C73D6DAAC028F4B1585DA7F42519718CC
9B09EEF0381840002818000AF995917
[RouterA-pkey-key-code]E1E570A3F6B1C2411948B3B4FFA256699B3BF871221CC9C5D
F257523777D033BEE77FC378145F2AD
[RouterA-pkey-key-code]D716D7DB9FCABB4ADBF6FB4FDB0CA25C761B308EF53009F71
01F7C62621216D5A572C379A32AC290
[RouterA-pkey-key-code]E55B394A217DA38B65B77F0185C8DB8095522D1EF044B465E
8716261214A5A3B493E866991113B2D
[RouterA-pkey-key-code]485348
[RouterA-pkey-key-code] public-key-code end
[RouterA-pkey-public-key] peer-public-key end
224
# Specify the host public key for the Stelnet server (192.168.1.40) as key1.
[RouterA] ssh client authentication server 10.165.87.136 assign publickey key1
[RouterA] quit
# Establish an SSH connection to SSH server 192.168.1.40.
<RouterA> ssh2 192.168.1.40
Username: client001
Trying 192.168.1.40
Press CTRL+K to abort
Connected to 192.168.1.40...
Enter password:
After you enter the correct username and password, you can log in to Router B successfully.
When the router acts as an Stelnet client for publickey
authentication
Network requirements
As shown in Figure 75, you can log in to Router B through the Stelnet client that runs on Router A. Router
B acts as the Stelnet server, adopting publickey authentication and the DSA public key algorithm.
Figure 75 Network diagram
Stelnet client
GE3/1/1
192.168.1.56/24
Stelnet server
GE3/1/1
192.168.1.40/24
Router A
Router B
Configuration procedure
In the server configuration, the client public key is required. Use the client software to generate a DSA key
pair on the client before configuring the Stelnet server.
1.
Configure the Stelnet client:
# Configure an IP address for interface GigabitEthernet 3/1/1.
<RouterA> system-view
[RouterA] interface GigabitEthernet 3/1/1
[RouterA-GigabitEthernet3/1/1] ip address 192.168.1.56 255.255.255.0
[RouterA-GigabitEthernet3/1/1] quit
# Generate a DSA key pair.
[RouterA] public-key local create dsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++
# Export the DSA public key to file key.pub.
225
[RouterA] public-key local export dsa ssh2 key.pub
[RouterA] quit
Then, transmit the public key file to the server through FTP or TFTP. (Details not shown.)
2.
Configure the Stelnet server:
# Generate the RSA key pairs.
<RouterB> system-view
[RouterB] public-key local create rsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++++
++++++++++++++
+++++
++++++++
# Generate a DSA key pair.
[RouterB] public-key local create dsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++
# Enable SSH server function.
[RouterB] ssh server enable
# Configure an IP address for interface GigabitEtherne 3/1/1, which the Stelnet client will use as
the destination address of the SSH connection.
[RouterB] interface GigabitEthernet 3/1/1
[RouterB-GigabitEthernet3/1/1] ip address 192.168.1.40 255.255.255.0
[RouterB-GigabitEthernet3/1/1] quit
# Set the authentication mode for the user interface to AAA.
[RouterB] user-interface vty 0 4
[RouterB-ui-vty0-4] authentication-mode scheme
# Enable the user interface to support SSH.
[RouterB-ui-vty0-4] protocol inbound ssh
# Set the user command privilege level to 3.
[RouterB-ui-vty0-4] user privilege level 3
[RouterB-ui-vty0-4] quit
# Import the peer public key from the file key.pub, and name it ClientKey.
[RouterB] public-key peer ClientKey import sshkey key.pub
# Specify the authentication method for user client002 as publickey, and assign the public key
ClientKey to the user.
226
[RouterB] ssh user client002 service-type stelnet authentication-type publickey
assign publickey ClientKey
3.
Establish an SSH connection to the Stelnet server (192.168.1.40).
<RouterA> ssh2 192.168.1.40
Username: client002
Trying 192.168.1.40 ...
Press CTRL+K to abort
Connected to 192.168.1.40 ...
The Server is not authenticated. Continue? [Y/N]:y
Do you want to save the server public key? [Y/N]:n
Then, you can log in to Router B successfully.
SFTP configuration examples
When the router acts as an SFTP server for password
authentication
Network requirements
As shown in Figure 76, you can log in to the router through the SFTP client that runs on the host. The router
acts as the SFTP server and uses password authentication. The username and password of the client are
saved on the router.
Figure 76 Network diagram
Configuration procedure
1.
Configure the SFTP server:
# Generate the RSA key pairs.
<Router> system-view
[Router] public-key local create rsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++++
++++++++++++++
+++++
++++++++
# Generate a DSA key pair.
227
[Router] public-key local create dsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++
# Enable the SSH server function.
[Router] ssh server enable
# Enable the SFTP server.
[Router] sftp server enable
# Configure an IP address for interface GigabitEthernet 3/1/1, which the client will use as the
destination for SSH connection.
[Router] interface GigabitEthernet 3/1/1
[Router-GigabitEthernet3/1/1] ip address 192.168.1.45 255.255.255.0
[Router-GigabitEthernet3/1/1] quit
# Set the authentication mode of the user interface to AAA.
[Router] user-interface vty 0 4
[Router-ui-vty0-4] authentication-mode scheme
# Enable the user interface to support SSH.
[Router-ui-vty0-4] protocol inbound ssh
[Router-ui-vty0-4] quit
# Configure a local user named client002 with the password aabbcc and the service type ssh.
[Router] local-user client002
[Router-luser-client002] password simple aabbcc
[Router-luser-client002] service-type ssh
[Router-luser-client002] quit
# Configure the user authentication method as password and service type as SFTP.
[Router] ssh user client002 service-type sftp authentication-type password
2.
Establish a connection to the SFTP server:
The device supports a variety of SFTP client software. This example uses an SFTP client that runs
PSFTP of PuTTY Version 0.58.
NOTE:
PSFTP supports only password authentication.
To establish a connection to the SFTP server:
a. Run the psftp.exe to launch the client interface as shown in Figure 77, and enter the following
command:
open 192.168.1.45
b. Enter username client002 and password aabbcc as prompted to log in to the SFTP server.
228
Figure 77 SFTP client interface
When the router acts as an SFTP client for publickey
authentication
Network requirements
As shown in Figure 78, you can log in to Router B through the SFTP client that runs on Router A. Router
B acts as the SFTP server, adopting publickey authentication and the RSA public key algorithm.
Figure 78 Network diagram
Configuration procedure
In the server configuration, the client public key is required. Use the client software to generate an RSA
key pair on the client before configuring the SFTP server.
1.
Configure the SFTP client:
# Configure an IP address for interface GigabitEthernet 3/1/1.
<RouterA> system-view
[RouterA] interface GigabitEthernet 3/1/1
[RouterA-GigabitEthernet3/1/1] ip address 192.168.0.2 255.255.255.0
[RouterA-GigabitEthernet3/1/1] quit
# Generate the RSA key pairs.
[RouterA] public-key local create rsa
The range of public key size is (512 ~ 2048).
229
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++++
++++++++++++++
+++++
++++++++
# Export the host public key to file pubkey.
[RouterA] public-key local export rsa ssh2 pubkey
[RouterA] quit
Then, transmit the public key file to the server through FTP or TFTP. (Details not shown.)
2.
Configure the SFTP server:
# Generate the RSA key pairs.
<RouterB> system-view
[RouterB] public-key local create rsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++++
++++++++++++++
+++++
++++++++
# Generate a DSA key pair.
[RouterB] public-key local create dsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++
# Enable the SSH server function.
[RouterB] ssh server enable
# Enable the SFTP server function.
[RouterB] sftp server enable
# Configure an IP address for interface GigabitEthernet 3/1/1, which the client will use as the
destination address of the SSH connection.
[RouterB] interface GigabitEthernet 3/1/1
[RouterB-GigabitEthernet3/1/1] ip address 192.168.0.1 255.255.255.0
[RouterB-GigabitEthernet3/1/1] quit
230
# Set the authentication mode of the user interface to AAA.
[RouterB] user-interface vty 0 4
[RouterB-ui-vty0-4] authentication-mode scheme
# Enable the user interface to support SSH.
[RouterB-ui-vty0-4] protocol inbound ssh
[RouterB-ui-vty0-4] quit
# Import the peer public key from the file pubkey, and name it RouterKey.
[RouterB] public-key peer RouterKey import sshkey pubkey
# For user client001, set the service type as SFTP, authentication method as publickey, public key
as RouterKey, and working folder as cf0:/.
[RouterB] ssh user client001 service-type sftp authentication-type publickey assign
publickey RouterKey work-directory cf0:/
3.
Establish a connection between the SFTP client and the SFTP server:
# Establish a connection to the SFTP server and enter SFTP client view.
<RouterA> sftp 192.168.0.1 identity-key rsa
Input Username: client001
Trying 192.168.0.1 ...
Press CTRL+K to abort
Connected to 192.168.0.1 ...
The Server is not authenticated. Continue? [Y/N]:y
Do you want to save the server public key? [Y/N]:n
sftp-client>
# Display files under the current directory of the server, delete file z, and check that the file has
been deleted successfully.
sftp-client> dir
-rwxrwxrwx
1 noone
nogroup
1759 Aug 23 06:52 config.cfg
-rwxrwxrwx
1 noone
nogroup
225 Aug 24 08:01 pubkey2
-rwxrwxrwx
1 noone
nogroup
283 Aug 24 07:39 pubkey
drwxrwxrwx
1 noone
nogroup
0 Sep 01 06:22 new
-rwxrwxrwx
1 noone
nogroup
225 Sep 01 06:55 pub
-rwxrwxrwx
1 noone
nogroup
0 Sep 01 08:00 z
sftp-client> delete z
The following File will be deleted:
/z
Are you sure to delete it? [Y/N]:y
This operation might take a long time.Please wait...
File successfully Removed
sftp-client> dir
-rwxrwxrwx
1 noone
nogroup
1759 Aug 23 06:52 config.cfg
-rwxrwxrwx
1 noone
nogroup
225 Aug 24 08:01 pubkey2
-rwxrwxrwx
1 noone
nogroup
283 Aug 24 07:39 pubkey
drwxrwxrwx
1 noone
nogroup
0 Sep 01 06:22 new
-rwxrwxrwx
1 noone
nogroup
225 Sep 01 06:55 pub
# Add a directory named new1 and check that it has been created successfully.
231
sftp-client> mkdir new1
New directory created
sftp-client> dir
-rwxrwxrwx
1 noone
nogroup
1759 Aug 23 06:52 config.cfg
-rwxrwxrwx
1 noone
nogroup
225 Aug 24 08:01 pubkey2
-rwxrwxrwx
1 noone
nogroup
283 Aug 24 07:39 pubkey
drwxrwxrwx
1 noone
nogroup
0 Sep 01 06:22 new
-rwxrwxrwx
1 noone
nogroup
225 Sep 01 06:55 pub
drwxrwxrwx
1 noone
nogroup
0 Sep 02 06:30 new1
# Rename the directory new1 to new2 and check that the directory name has been changed
successfully.
sftp-client> rename new1 new2
File successfully renamed
sftp-client> dir
-rwxrwxrwx
1 noone
nogroup
1759 Aug 23 06:52 config.cfg
-rwxrwxrwx
1 noone
nogroup
225 Aug 24 08:01 pubkey2
-rwxrwxrwx
1 noone
nogroup
283 Aug 24 07:39 pubkey
drwxrwxrwx
1 noone
nogroup
0 Sep 01 06:22 new
-rwxrwxrwx
1 noone
nogroup
225 Sep 01 06:55 pub
drwxrwxrwx
1 noone
nogroup
0 Sep 02 06:33 new2
# Download the pubkey2 file from the server and save it as local file public.
sftp-client> get pubkey2 public
Remote
file:/pubkey2 --->
Local file: public
Downloading file successfully ended
# Upload a local file named pu to the server, save it as puk, and check that the file has been
uploaded successfully.
sftp-client> put pu puk
Local file:pu --->
Remote file: /puk
Uploading file successfully ended
sftp-client> dir
-rwxrwxrwx
1 noone
nogroup
1759 Aug 23 06:52 config.cfg
-rwxrwxrwx
1 noone
nogroup
225 Aug 24 08:01 pubkey2
-rwxrwxrwx
1 noone
nogroup
283 Aug 24 07:39 pubkey
drwxrwxrwx
1 noone
nogroup
0 Sep 01 06:22 new
drwxrwxrwx
1 noone
nogroup
0 Sep 02 06:33 new2
-rwxrwxrwx
1 noone
nogroup
283 Sep 02 06:35 pub
-rwxrwxrwx
1 noone
nogroup
283 Sep 02 06:36 puk
sftp-client>
# Exit SFTP client view.
sftp-client> quit
Bye
<RouterA>
232
SCP configuration examples
File transfer with password authentication
Network requirements
As shown in Figure 79, Router A acts as an SCP client and Router B acts as an SCP server. A user can
securely transfer files with Router B through Router A. Router B uses the password authentication method
and the client's username and password are saved on Router B.
Figure 79 Network diagram
Configuration procedure
1.
Configure the SCP server:
<RouterB> system-view
[RouterB] public-key local create rsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++++
++++++++++++++
+++++
++++++++
# Generate a DSA key pair.
[RouterB] public-key local create dsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits of the modulus[default = 1024]:
Generating Keys...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++
# Enable the SSH server function.
[RouterB] ssh server enable
# Configure an IP address for GigabitEthernet 3/1/1, which the client will use as the destination
for Stelnet connection.
[RouterB] interface GigabitEthernet 3/1/1
[RouterB-GigabitEthernet3/1/1] ip address 192.168.0.1 255.255.255.0
[RouterB-GigabitEthernet3/1/1] quit
233
# Set the authentication mode of the user interface to AAA.
[RouterB] user-interface vty 0 4
[RouterB-ui-vty0-4] authentication-mode scheme
# Enable the user interface to support SSH.
[RouterB-ui-vty0-4] protocol inbound ssh
[RouterB-ui-vty0-4] quit
# Create a local user named client001 with the password as aabbcc and service type as ssh.
[RouterB] local-user client001
[RouterB-luser-client001] password simple aabbcc
[RouterB-luser-client001] service-type ssh
[RouterB-luser-client001] quit
# (Optional.) Configure the SSH user client001 with service type as scp and authentication method
as password.
[RouterB] ssh user client001 service-type scp authentication-type password
2.
Configure an IP address for GigabitEthernet 3/1/1 on the SCP client.
<RouterA> system-view
[RouterA] interface GigabitEthernet 3/1/1
[RouterA-GigabitEthernet3/1/1] ip address 192.168.0.2 255.255.255.0
[RouterA-GigabitEthernet3/1/1] quit
[RouterA] quit
3.
Connect to the SCP server, download the file remote.bin from the server, and save it locally to the
file local.bin.
<RouterA> scp 192.168.0.1 get remote.bin local.bin
Username: client001
Trying 192.168.0.1 ...
Press CTRL+K to abort
Connected to 192.168.0.1 ...
The Server is not authenticated. Continue? [Y/N]:y
Do you want to save the server public key? [Y/N]:n
Enter password:
18471 bytes transfered in 0.001 seconds.
234
Configuring packet-filter firewall
Overview
A firewall can block unauthorized accesses from the Internet to a protected network while allowing
internal network users to access the Internet through, for example, WWW, or to send/receive emails. A
firewall can also be used to control access to the Internet, for example, to permit only specific hosts within
the organization to access the Internet.
Another application of firewall is to protect mainframes and important resources (such as data) on the
internal network. Any access to protected data must be first filtered by the firewall, even if such an access
is initiated by a user within the internal network.
A packet-filter firewall uses an ACL to filter IP packet. For each IP packet to be forwarded, the firewall first
obtains the header information of the packet, including the number of the upper layer protocol carried
by the IP layer, the source address, destination address, source port number, and destination port
number of the packet. Then, it compares the obtained header information against the preset ACL rules
and processes the packet according to the comparison result.
A packet-filter firewall supports fragment inspection and filtering. It checks the following elements:
•
Packet type, which can be non-fragmented packet, first fragment, or non-first fragment.
•
Layer 3 information of the packet, for matching against basic ACL rules and advanced ACL rules
without information above Layer 3.
•
Upper layer Information, for matching against advanced ACL rules containing information above
Layer 3.
NOTE:
For more information about ACL, see ACL and QoS Configuration Guide.
Configuring packet filtering
You can apply an ACL to filter incoming or outgoing IP packets on an interface. When an ACL is applied
to an interface, the time range-based filtering will also work at the same time.
A basic ACL defines rules based on only the Layer 3 source IP addresses to analyze and process data
packets. An advanced ACL defines rules according to the information such as source and destination IP
addresses of packets, the type of protocol over IP, and TCP/UDP source and destination ports.
Configuring IPv4 packet filtering on an interface
•
The rule you add to an ACL that has been used by the firewall packet-filter command cannot take
effect if hardware resources are insufficient or the firewall packet-filter command does not support
the rule. Such rules are marked as uncompleted in the display acl { acl-number | all | name
acl-name } slot slot-number command output. To successfully apply the rule, you must delete the rule
and then reconfigure it when hardware resources are sufficient.
To configure IPv4 packet filtering on an interface:
235
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Apply an IPv4 ACL to the
interface to filter IPv4 packets.
firewall packet-filter { acl-number |
name acl-name } { inbound |
outbound }
IPv4 packets are not filtered by
default.
Configuring IPv6 packet filtering on an interface
IPv6 packet filtering is a basic firewall function based on an IPv6 ACL. You can configure IPv6 packet
filtering in the inbound or outbound direction of an interface, and you can configure multiple IPv6 ACLs
in each direction.
To configure IPv6 packet filtering on an interface:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Apply an IPv6 ACL to the
interface to filter IPv6 packets.
firewall packet-filter ipv6
{ acl6-number | name acl6-name }
{ inbound | outbound }
IPv6 packets are not filtered by
default.
The rule you add to an ACL that has been used by the firewall packet-filter ipv6 command cannot take
effect if hardware resources are insufficient or the firewall packet-filter ipv6 command does not support
the rule. Such rules are marked as uncompleted in the display acl { acl-number | all | name acl-name }
slot slot-number command output. To successfully apply the rule, you must delete the rule and then
reconfigure it when hardware resources are sufficient.
Configuring port mapping
Two mapping mechanisms exist: general port mapping and basic ACL–based host port mapping.
•
A general port mapping refers to a mapping of a user-defined port number to an application layer
protocol. If port 8080 is mapped to HTTP, for example, all TCP packets the destination port of which
is port 8080 are regarded as HTTP packets.
•
A host port mapping refers to a mapping of a user-defined port number to an application layer
protocol for packets to some specific hosts. For example, you can establish a host port mapping so
that all TCP packets using port 8080 sent to the network segment 10.110.0.0 are regarded as HTTP
packets. The address range of hosts can be specified by means of a basic ACL.
To configure port mapping:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
236
Step
Configure mapping between
the port and the application
protocol.
2.
Command
Remarks
port-mapping application-name
port port-number [ acl acl-number ]
The application layer protocols
supported by this function include
FTP, GTP, H323, HTTP, RTSP,
SCCP, SIP, SMTP, and SQLNET.
Displaying packet filter information
Task
Command
Remarks
Display packet filter information for
interfaces.
display firewall packet-filter { all |
interface interface-type
interface-number } [ inbound |
outbound ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Packet-filter firewall configuration example
Network requirements
As shown in Figure 80:
•
The internal network of a company is connected to Serial 3/1/9/1:2 of the router, and the internal
users access the Internet through GigabitEthernet 3/1/1 of the router.
•
The company provides WWW, FTP and Telnet services to the outside. The internal subnet of the
company is 129.1.1.0, on which the internal FTP server address is 129.1.1.1, the Telnet server address
is 129.1.1.2, the internal WWW server address is 129.1.1.3, and the public address of the company
is 20.1.1.1. NAT is enabled on the router so that hosts on the internal network can access to the
Internet and external hosts can access the internal servers.
•
By using the firewall feature, the company intends to achieve the following aim: only specific users
on external networks are given access to the internal servers, and only specific hosts on the internal
network are permitted to access external networks.
•
Assume that the IP address of a specific external user is 20.3.3.3.
237
Figure 80 Network diagram
129.1.1.1/24
129.1.1.2/24
FTP server Telnet server
129.1.1.3/24
WWW server
Internal network
GE3/1/1
129.1.1.5/24
Serial 3/1/9/1:2
20.1.1.1/16
WAN
Internal host
Router
v
External host
129.1.1.4/24
20.3.3.3/32
Configuration procedure
# Enable the firewall function on the router.
<Router> system-view
[Router] firewall enable
# Create advanced ACL 3001.
[Router] acl number 3001
# Configure rules to permit specific hosts to access external networks and permit internal servers to
access external networks.
[Router-acl-adv-3001] rule permit ip source 129.1.1.1 0
[Router-acl-adv-3001] rule permit ip source 129.1.1.2 0
[Router-acl-adv-3001] rule permit ip source 129.1.1.3 0
[Router-acl-adv-3001] rule permit ip source 129.1.1.4 0
# Configure a rule to prohibit all IP packets from passing the firewall.
[Router-acl-adv-3001] rule deny ip
[Router-acl-adv-3001] quit
# Create advanced ACL 3002.
[Router] acl number 3002
# Configure a rule to allow a specific external user to access internal servers.
[Router-acl-adv-3002] rule permit tcp source 20.3.3.3 0 destination 129.1.1.0 0.0.0.255
# Configure a rule to permit specific data (only packets of which the port number is greater than 1024)
to get access to the internal network.
[Router-acl-adv-3002] rule permit tcp destination 20.1.1.1 0 destination-port gt 1024
[Router-acl-adv-3002] rule deny ip
[Router-acl-adv-3002] quit
# Apply ACL 3001 to filter packets that come in through GigabitEthernet 3/1/1.
[Router] interface gigabitEthernet 3/1/1
[Router-GigabitEthernet3/1/1] firewall packet-filter 3001 inbound
# Apply ACL 3002 to filter packets that come in through Serial 3/1/9/1:2.
[Router-GigabitEthernet3/1/1] quit
[Router] interface serial 3/1/9/1:2
[Router-Serial3/1/9/1:2] firewall packet-filter 3002 inbound
238
Configuring ALG
ALG overview
The Application Level Gateway (ALG) feature is used to process application layer packets.
Usually, Network Address Translation (NAT) translates only IP address and port information in packet
headers; it does not analyze fields in application layer payloads. However, the packet payloads of some
protocols may contain IP address or port information, which, if not translated, may cause problems. For
example, an FTP application involves both data connection and control connection, and data connection
establishment dynamically depends on the payload information of the control connection. ALG can
process the payload information to make sure that the data connections can be established.
ALG can work with NAT to implement the following functions:
•
Address translation:
Resolves the source IP address, port, protocol type (TCP or UDP), and remote IP address
information in packet payloads.
•
Data connection detection:
Extracts information required for data connection establishment and establishing data connections
for data exchange.
•
Application layer status checking:
Inspects the status of the application layer protocol in packets. If the status is right, updating the
packet state machine and performing further processing; otherwise, dropping packets with
incorrect states.
Support for the above functions depends on the application layer protocol. ALG can process packets of
the following protocols:
•
DNS
•
FTP
•
H.323, including Registration, Admission, Status (RAS), H.225, and H.245
•
ILS
•
MSN and QQ
•
NBT
•
RTSP
•
SCCP
•
SIP
•
SQLNET, a language in Oracle
•
TFTP
The following example describes the operation of FTP on an ALG-enabled router. As shown in Figure 81,
the host on the external network accesses the FTP server on the internal network in passive mode through
the ALG-enabled router.
239
Figure 81 Network diagram for ALG-enabled FTP application in passive mode
The communication process includes the following stages:
1.
Establishing a control connection:
The host sends a TCP connection request to the server. If a TCP connection is established, the server
and the host enter the user authentication stage.
2.
Authenticating the user:
The host sends the server an authentication request, which contains the FTP commands (user and
password) and the contents.
When the request passes through the ALG-enabled router, the commands in the payload of the
packet will be resolved and used to check whether the state machine transition is going on
correctly. If not, the request will be dropped. In this way, ALG protects the server against clients
that send packets with state machine errors or log into the server with illegal user accounts.
An authentication request with a correct state is forwarded by the ALG-enabled router to the server,
which authenticates the host according to the information in the packet.
3.
Establishing a data connection:
If the host passes the authentication, a data connection is established between it and the server. If
the host is accessing the server in passive mode, the data connection process is different. In
passive mode, the server sends the host a PASV response that uses its private network address and
port number (IP1, Port1). When the response arrives at the ALG-enabled router, the router resolves
the packet and translates the server’s private network address and port number into the server’s
public network address and port number (IP2, Port2) respectively. Then, the router uses the public
network address and port number to establish a data connection with the host.
4.
Exchanging data:
The host and the FTP server exchange data through the established data connection.
Enabling ALG
240
Step
1.
2.
Command
Remarks
Enter system view.
system-view
N/A
Enable ALG.
alg { all | dns | ftp | h323 | ils |
msn | nbt | qq | rtsp | sccp | sip |
sqlnet | tftp }
Optional.
By default, ALG is enabled for all
protocols.
The tftp keyword is not supported.
Configuring a port mapping
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
Optional.
2.
Configure a mapping
between a port and an
application protocol.
port-mapping application-name
port port-number [ acl acl-number ]
The source field of the ACL rule
must be the public address of the
internal server, which is the
address for external users to use to
access the internal server.
Displaying ALG
Task
Command
Remarks
Display port mapping information.
display port-mapping [ application-name |
port port-number ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
ALG configuration examples
The following examples describe only ALG-related configurations, assuming that other required
configurations on the server and client have been done.
FTP ALG configuration example
Network requirements
As shown in Figure 82, a company uses the private network segment 192.168.1.0/24, and has four
public network addresses: 5.5.5.1, 5.5.5.9, 5.5.5.10, and 5.5.5.11. The company wants to provide FTP
services to the outside.
Configure NAT and ALG on the router so that hosts on the external network can access the FTP server on
the internal network.
241
Figure 82 Network diagram
Configuration procedure
# Configure the address pool and ACL.
<Router> system-view
[Router] nat address-group 1 5.5.5.9 5.5.5.11
[Router] acl number 2001
[Router-acl-basic-2001] rule permit
[Router-acl-basic-2001] quit
# Enable ALG for FTP.
[Router] alg ftp
# Configure NAT.
[Router] interface GigabitEthernet 3/1/1
[Router-GigabitEthernet3/1/1] nat outbound 2001 address-group 1
[Router-GigabitEthernet3/1/1] quit
# Configure a NAT service interface binding.
[Router] interface nat 5/0/1
[Router-NAT5/0/1] nat binding interface GigabitEthernet 3/1/1
[Router-NAT5/0/1] quit
# Configure the internal FTP server.
[Router] interface GigabitEthernet 3/1/1
[Router-GigabitEthernet3/1/1] nat server protocol tcp global 5.5.5.10 ftp inside
192.168.1.2 ftp
SIP/H.323 ALG configuration example
H.323 ALG configuration is similar to SIP ALG configuration. This example describes SIP ALG
configuration.
Network requirements
As shown in Figure 83, a company uses the private network segment 192.168.1.0/24, and has four
public network addresses: 5.5.5.1, 5.5.5.9, 5.5.5.10, and 5.5.5.11. SIP UA 1 is on the internal network
and SIP UA 2 is on the outside network.
Configure NAT and ALG on the router so that SIP UA 1 and SIP UA 2 can communicate by using their
aliases, and SIP UA 1 selects an IP address from the range 5.5.5.9 to 5.5.5.11 when registering with the
SIP server on the external network.
242
Figure 83 Network diagram
Configuration procedure
# Configure the address pool and ACL.
<Router> system-view
[Router] nat address-group 1 5.5.5.9 5.5.5.11
[Router] acl number 2001
[Router-acl-basic-2001] rule permit source 192.168.1.0 0.0.0.255
[Router-acl-basic-2001] rule deny
[Router-acl-basic-2001] quit
# Configure NAT.
[Router] interface GigabitEthernet 3/1/2
[Router-GigabitEthernet3/1/2] nat outbound 2001 address-group 1
[Router-GigabitEthernet3/1/2] quit
# Configure a NAT service interface binding.
[Router] interface nat 5/0/1
[Router-NAT5/0/1] nat binding interface GigabitEthernet 3/1/2
[Router-NAT5/0/1] quit
NBT ALG configuration example
Network requirements
As shown in Figure 84, a company using the private network segment 192.168.1.0/24 wants to provide
NBT services to the outside.
Configure NAT and ALG on the router so that Host A uses 5.5.5.9 as its external IP address, the WINS
server uses 5.5.5.10 as its external IP address, and Host B can access the WINS server and Host A by
using host names.
Figure 84 Network diagram
WINS server
GE3/1/1
192.168.1.1/24
GE3/1/2
5.5.5.1/24
Internet
192.168.1.2/24
Router
Host B
Host A
192.168.1.3/24
243
Configuration procedure
# Configure a static NAT entry.
<Router> system-view
[Router] interface nat 5/0/1
[Router-NAT5/0/1] nat static 192.168.1.3 5.5.5.9
[Router-NAT5/0/1] quit
# Enable ALG for NBT.
[Router] alg nbt
# Configure NAT.
[Router] interface GigabitEthernet 3/1/2
[Router-GigabitEthernet3/1/2] nat outbound static
# Configure the internal WINS server.
[Router-GigabitEthernet3/1/2] nat server protocol udp global 5.5.5.10 137 inside
192.168.1.2 137
[Router-GigabitEthernet3/1/2] nat server protocol udp global 5.5.5.10 138 inside
192.168.1.2 138
[Router-GigabitEthernet3/1/2] nat server protocol tcp global 5.5.5.10 139 inside
192.168.1.2 139
[Router-GigabitEthernet3/1/2] quit
# Configure a NAT service interface binding.
[Router] interface nat 5/0/1
[Router-NAT5/0/1] nat binding interface GigabitEthernet 3/1/2
[Router-NAT5/0/1] quit
244
Managing sessions
Overview
The session management feature is a common feature to implement session-based services such as
network address translation (NAT), and intrusion detection and protection. This feature regards packet
exchanges at transport layer as sessions and updates the status of sessions or ages out sessions
according to the information in the initiators’ or responders’ packet information.
Session management allows multiple features to process the same service packet respectively. It
implements the following functions:
•
Fast match between packets and sessions
•
Management of transport layer protocol state
•
Identification of application layer protocol types
•
Session aging based on protocol state
•
Special packet match for the application layer protocols requiring port negotiation
•
Resolution of ICMP error control packets and session match based on resolution results
Session management principle
The session management function tracks the status of connections by inspecting the transport layer
protocol (TCP or UDP) information, and performs unified status maintenance and management of all
connections.
Note that the session management function implements only connection status tracking. It itself cannot
block potential attack packets.
Session management implementation
The session management feature implemented on the device provides the following functions:
•
Supporting session creation, session status update and timeout time setting based on protocol state
for such IPv4 packets as TCP, UDP, ICMP, Raw IP packets.
•
Supporting port mapping for application layer protocols and allowing application layer protocols
to use customized ports.
•
Supporting ICMP error packet mapping and allowing the system to search for original sessions
according to the payload of these packets. Because error packets are generated due to host errors,
the mapping can help speed up the aging of the original sessions.
•
Supporting session management of control channels and dynamic data channels of application
layer protocols, for example, FTP.
•
Limiting the number of session-based connections. For more information, see Layer 3—IP Services
Configuration Guide.
245
Session management configuration task list
Complete the following tasks to configure session management:
•
Setting session aging times based on protocol state
•
Configuring session aging times based on application layer protocol type
•
Clearing sessions manually
These tasks are mutually independent and can be configured in any order. You can configure them as
required.
Setting session aging times based on protocol state
If a session entry is not matched with any packets in a specified period of time, the entry will be aged out.
Do not set a too short aging time when the number of sessions exceeds 800000. Otherwise, the console
might be slow in response.
To set the session aging times based on protocol state:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
The system supports keywords syn, tcp-est, and
udp-ready.
The defaults are as follows:
2.
Set the aging time
for sessions of a
specified protocol
and in a specified
state.
session aging-time { accelerate
| fin | icmp-closed |
icmp-open | rawip-open |
rawip-ready | syn | tcp-est |
udp-open | udp-ready }
time-value
•
•
•
•
•
•
•
•
•
•
accelerate—10 seconds.
fin—30 seconds.
icmp-closed—30 seconds.
icmp-open—60 seconds.
rawip-open—30 seconds.
rawip-ready—60 seconds.
syn—15 seconds.
tcp-est—300 seconds.
udp-open—30 seconds.
udp-ready—60 seconds.
Configuring session aging times based on application layer
protocol type
Aging times set in this task applies to only the sessions in the READY/ESTABLISH state. For sessions in the
READY (with UDP) or ESTABLISH (with TCP) state, you can set the session aging times according to the
types of the application layer protocols to which the sessions belong.
Do not set a too short aging time when the number of sessions exceeds 800000. Otherwise, the console
might be slow in response.
To set session aging times based on application layer protocol type:
246
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
The defaults are as follows:
2.
Set the aging time for sessions
of an application layer
protocol.
application aging-time { dns | ftp
| msn | qq | sip } time-value
•
•
•
•
•
dns—60 seconds.
ftp—3600 seconds.
msn—3600 seconds.
qq—60 seconds.
sip—300 seconds.
Enabling checksum verification
NOTE:
The cards with silkscreen IM-NAT and IM-NAT-II do not support this feature.
To make sure session tracking is not affected by packets with checksum errors, you can enable checksum
verification for protocol packets. With checksum verification enabled, the session management feature
processes only packets with correct checksums, and packets with incorrect checksums will be processed
by other services based on the session management.
Checksum verification might degrade device performance.
To enable checksum verification for protocol packets:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable checksum verification.
session checksum { all | { icmp |
tcp | udp } * }
Disabled by default.
Specifying persistent sessions
NOTE:
The cards with silkscreen IM-NAT and IM-NAT-II do not support this feature.
You can set some sessions that match the permit statements in the specified ACL as persistent sessions,
and set longer lifetime or never-age-out persistent sessions. A lifelong session is not removed until the
device receives a connection close request from the initiator or responder, or you manually clear the
session entries.
You can set the persistent session criteria by specifying a basic or advanced ACL. All sessions permitted
by the ACL are persistent sessions.
For more information about the configuration of basic and advance ACLs, see ACL and QoS
Configuration Guide.
To specify persistent sessions:
247
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
By default, no persistent sessions
are specified.
2.
Specify persistent sessions.
session persist acl acl-number
[ aging-time time-value ]
You can reference only one ACL. If
you configure this command
multiple times, the most recent
configuration takes effect.
Clearing sessions manually
Task
Command
Remarks
Clear sessions.
reset session [ slot slot-num ]
[ source-ip source-ip ]
[ destination-ip destination-ip ]
[ protocol-type protocol-type ]
[ source-port source-port ]
[ destination-port destination-port ]
[ vpn-instance vpn-instance-name ]
Available in user view.
Configuring session logging
A session log records information about user access, IP address translation, and traffic, and can be sent
to the log server in a specific format. It can help network administrators in security auditing.
Enabling session logging
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter NAT interface view.
interface nat interface-number
N/A
3.
Enable session logging.
session log enable [ acl
acl-number ]
Disabled by default.
Setting the session logging threshold
When the holdtime of a session reaches the preset threshold, the system outputs a session log.
To set the session logging threshold:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
248
Step
Command
Remarks
Optional.
2.
Set the threshold for session
logging.
session log time-active time-value
0 by default, which means that the
system does not output session logs
based on session holdtime
threshold.
Configuring session log export
Session logs are exported in the form of flow logs.
To configure session log exporting:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Specify the flow log packet
version.
userlog flow export version
version-number
Optional.
1.0 by default.
Optional.
3.
Specify the source IP address
for the flow log packets.
userlog flow export source-ip
ip-address
By default, the source IP address is
the IP address of the interface
sending the flow log packets by
default.
• Specify the IPv4 address and
UDP port number of the flow
log server:
userlog flow export slot
slot-number [ vpn-instance
vpn-instance-name ] host
ip-address udp-port
4.
Specify to export flow logs to
the flow log server or the
information center
• Specify the IPv6 address and
UDP port number of the flow
log server:
userlog flow export slot
slot-number [ vpn-instance
vpn-instance-name ] host ipv6
ipv6-address udp-port
• Specify to export flow logs to
the information center:
userlog flow syslog
By default, IP address and UDP
port of the flow log server are not
specified, and flow logs are
always exported to the flow log
server if you do not specify to
export them to the information
center.
If you specify to export flow logs to
both the flow log server and the
information center, flow logs are
exported to only the information
center.
Flow logs cannot be sent to the
flow log server through tunnels.
For more information about flow logging functions, see Network Management and Monitoring
Configuration Guide.
For more information about flow logging commands, see Network Management and Monitoring
Command Reference.
Displaying and maintaining session management
249
Task
Command
Remarks
Display the session aging times for
application layer protocols.
display application aging-time [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display the session aging times in
different protocol states.
display session aging-time [ | { begin |
exclude | include } regular-expression ]
Available in any view.
Display information about sessions.
display session table [ slot slot-number ]
[ source-ip source-ip ] [ destination-ip
destination-ip ] [ protocol-type { icmp |
raw-ip | tcp | udp } ] [ source-port
source-port ] [ destination-port
destination-port ] [ count | verbose ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display statistics about sessions.
display session statistics [ slot slot-num ]
[ | { begin | exclude | include }
regular-expression ]
Available in any view.
Display session relationship table
information.
display session relation-table [ slot
slot-num ] [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display configuration and statistics
about logs.
display userlog export slot slot-number
[ | { begin | exclude | include }
regular-expression ]
Available in any view. For
more information about this
command, see Layer 3—IP
Services Command
Reference.
Clear sessions.
reset session [ slot slot-num ] [ source-ip
source-ip ] [ destination-ip
destination-ip ] [ protocol-type
protocol-type ] [ source-port source-port ]
[ destination-port destination-port ]
[ vpn-instance vpn-instance-name ]
Available in user view.
Clear session statistics.
reset session statistics [ slot slot-num ]
Available in user view.
reset userlog flow export slot
slot-number
Available in user view. For
more information about this
command, see Layer 3—IP
Services Command
Reference.
reset userlog flow logbuffer slot
slot-number
Available in user view. For
more information about this
command, see Network
Management and
Monitoring Command
Reference.
Clear the log statistics on a
specified card.
Clear flow logs in the buffer.
250
Configuring TCP and ICMP attack protection
Overview
An attacker can attack the router during the process of TCP connection establishment or by sending a
large number of ICMP fragments. To prevent such attacks, the router provides the following features:
•
SYN Cookie
•
Protection against Naptha attacks
This document describes the attacks these features can prevent, working mechanisms of these features,
and configuration procedures.
Enabling the SYN Cookie feature
As a general rule, the establishment of a TCP connection involves the following handshakes:
1.
The request originator sends a SYN message to the target server.
2.
After receiving the SYN message, the target server establishes a TCP connection in
SYN_RECEIVED state, returns a SYN ACK message to the originator, and waits for a response.
3.
After receiving the SYN ACK message, the originator returns an ACK message. Thus, the TCP
connection is established.
Attackers may mount SYN Flood attacks during TCP connection establishment. They send a large number
of SYN messages to the server to establish TCP connections, but they never make any response to SYN
ACK messages. As a result, a large amount of incomplete TCP connections are established, resulting in
heavy resource consumption and making the server unable to handle services correctly.
The SYN Cookie feature can prevent SYN Flood attacks. After receiving a TCP connection request, the
server directly returns a SYN ACK message, instead of establishing an incomplete TCP connection. Only
after receiving an ACK message from the client can the server establish a connection, and then enter
ESTABLISHED state. In this way, large amounts of incomplete TCP connections could be avoided to
protect the server against SYN Flood attacks.
Follow these guidelines when you enable the SYN Cookie feature:
•
If you enable MD5 authentication for TCP connections, the SYN Cookie configuration is ineffective.
Then, if you disable MD5 authentication for TCP connections, the SYN Cookie configuration
automatically becomes effective. For more information about MD5 authentication, see Layer 3—IP
Routing Configuration Guide.
•
With the SYN Cookie feature enabled, only the maximum segment size (MSS), instead of the
window's zoom factor and timestamp, is negotiated during TCP connection establishment.
To enable the SYN Cookie feature:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the SYN Cookie feature.
tcp syn-cookie enable
Enabled by default.
251
Enabling protection against Naptha attacks
Naptha attacks are similar to the SYN Flood attacks. Attackers can perform Naptha attacks by using the
six TCP connection states (CLOSING, ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, LAST_ACK, and
SYN_RECEIVED), and SYN Flood attacks by using only SYN_RECEIVED state.
Naptha attackers control a huge amount of hosts to establish TCP connections with the server, keep these
connections in the same state (any of the six), and request for no data so as to exhaust the memory
resource of the server. As a result, the server cannot process normal services.
Protection against Naptha attacks mitigates such attacks by accelerating the aging of TCP connections
in a state. After the feature is enabled, the device (serving as a TCP server) periodically checks the
number of TCP connections in each state. If the device detects that the number of TCP connections in a
state exceeds the maximum number, it considers that a Naptha attack occurs and accelerates the aging
of TCP connections in this state. The device will stop accelerating the aging of TCP connections when the
number of TCP connections in the state is less than 80% of the maximum number (1 at least).
Follow these guidelines when you enable the protection against Naptha attack:
•
With the protection against Naptha attack enabled, the router will periodically check and record
the number of TCP connections in each state.
•
With the protection against Naptha attack enabled, if the router detects that the number of TCP
connections in a state exceeds the maximum number, the router will consider that as Naptha
attacks and accelerate the aging of these TCP connections. The router will not stop accelerating the
aging of TCP connections until the number of TCP connections in the state is less than 80% of the
maximum number.
To enable the protection against Naptha attack:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the protection
against Naptha attack.
tcp anti-naptha enable
Disabled by default.
Optional.
3.
Configure the maximum
of TCP connections in a
state.
tcp state { closing | established |
fin-wait-1 | fin-wait-2 | last-ack |
syn-received } connection-number
number
4.
Configure the TCP state
check interval.
tcp timer check-state time-value
5 by default.
If the maximum number of TCP
connections in a state is 0, the aging
of TCP connections in this state will
not be accelerated.
Optional.
30 seconds by default.
Displaying and maintaining TCP and ICMP attack
protection
252
Task
Command
Remarks
Display current TCP connection state.
display tcp status [ | { begin | exclude |
include } regular-expression ]
Available in any view.
253
Configuring IP source guard
Overview
IP source guard is intended to improve port security by blocking illegal packets. For example, it can
prevent invalid hosts from using a valid IP address to access the network.
IP source guard can filter packets according to the packet source IP address, source MAC address, and
VLAN tag. It supports these types of binding entries:
•
IP-port binding entry
•
MAC-port binding entry
•
IP-MAC-port binding entry
•
IP-VLAN-port binding entry
•
MAC-VLAN-port binding entry
•
IP-MAC-VLAN-port binding entry
After receiving a packet, an IP source guard-enabled port obtains the key attributes (source IP address,
source MAC address and VLAN tag) of the packet and then looks them up in the IP source guard entries.
If there is a match, the port forwards the packet. Otherwise, the port discards the packet.
Figure 85 Diagram for the IP source guard function
A binding entry can be statically configured or dynamically added.
The router supports only dynamically added IP + MAC + port binding entries.
IP source guard is a port-based function. IP source guard entries on one port do not affect packet
forwarding on other ports.
Dynamic IP source guard entries
Dynamic IP source guard entries are generated dynamically according to client entries on the DHCP
snooping or DHCP relay agent device. They are suitable for scenarios where many hosts reside on a LAN
and obtain IP addresses through DHCP. Once DHCP allocates an IP address to a client, IP source guard
automatically adds the client entry to allow the client to access the network. A user using an IP address
not obtained through DHCP cannot access the network. Dynamic IPv6 source guard entries can also be
obtained from client entries on the ND snooping device.
254
•
Dynamic IPv4 source guard entries are generated dynamically based on DHCP snooping or DHCP
relay entries to filter incoming IPv4 packets on a port.
•
Dynamic IPv6 source guard entries are generated dynamically based on DHCPv6 snooping or ND
snooping entries to filter incoming IPv6 packets on a port.
The router supports generating IP source guard entries based only on DHCP relay entries. For more
information about DHCP relay, see Layer 3—IP Services Configuration Guide.
Enabling IPv4 source guard on a port
With IPv4 source guard enabled, a port can obtain dynamic IPv4 source guard entries from the DHCP
module to filter packets. On a Layer 3 Ethernet port or VLAN interface, IP source guard cooperates with
DHCP relay, dynamically obtains the DHCP relay entries generated during dynamic IP address
allocation across network segments, and generates IP source guard entries accordingly.
Dynamic IPv4 source guard entries might include the MAC address, IP address, VLAN, incoming
interface, and entry type (DHCP relay) information. IP source guard applies these entries to the port to
filter packets.
To generate IPv4 source guard entries dynamically based on DHCP entries, make sure DHCP relay is
configured and working correctly. For information about DHCP relay configuration, see Layer 3—IP
Services Configuration Guide.
To configure the IPv4 source guard function on a port:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Enable IPv4 source guard on
the port.
ip verify source { ip-address
mac-address }
Disabled by default.
NOTE:
Although dynamic IPv4 source guard entries are generated based on DHCP entries, the number of
dynamic IPv4 source guard entries is not necessarily the same as that of the DHCP entries.
Displaying IP source guard
Task
Command
Remarks
Display IP source guard entries.
display ip source binding [ interface
interface-type interface-number | ip-address
ip-address | mac-address mac-address ] [ slot
slot-number ] [ | { begin | exclude | include }
regular-expression ]
Available in any view.
255
IP source guard configuration example
Network requirements
As shown in Figure 86, the host and the DHCP server are connected to the router through the router
interfaces GigabitEthernet 3/0/1 and GigabitEthernet 3/0/2, respectively. DHCP relay is enabled on
the router. The host (with the MAC address of 0001-0203-0406) obtains an IP address from the DHCP
server through the DHCP relay agent.
Enable the IPv4 source guard binding function on interface GigabitEthernet 3/0/1 to filter packets
based on the DHCP relay entry, allowing only packets from clients that obtain IP addresses from the
DHCP server to pass.
Figure 86 Network diagram
Configuration procedure
1.
Configure the DHCP relay agent:
# Configure IP addresses for the interfaces. (Details not shown.)
# Enable DHCP relay.
<Router> system-view
[Router] dhcp enable
# Configure the IP address of the DHCP server.
[Router] dhcp relay server-group 1 ip 10.1.1.1
# Configure GigabitEthernet 3/0/1 to operate in DHCP relay mode.
[Router] interface GigabitEthernet 3/0/1
[Router-GigabitEthernet3/0/1] dhcp select relay
# Correlate GigabitEthernet 3/0/1 with DHCP server group 1.
[Router-GigabitEthernet3/0/1] dhcp relay server-select 1
[Router-GigabitEthernet3/0/1] quit
2.
Configure the IPv4 source guard function:
# Configure the IPv4 source guard binding function on GigabitEthernet 3/0/1 to filter packets
based on both the source IP address and MAC address.
[Router] interface GigabitEthernet 3/0/1
[Router-GigabitEthernet3/0/1] ip verify source ip-address mac-address
[Router-GigabitEthernet3/0/1] quit
3.
Verify the configuration:
# Display the generated IPv4 source guard binding entries.
[Router] display ip source binding
Total entries found: 1
MAC Address
IP Address
VLAN
Interface
Type
0001-0203-0406
192.168.0.1
N/A
GE3/0/1
DHCP-RLY
256
Troubleshooting IP source guard
Symptom
Failed to configure the IP source guard function on an interface.
Analysis
IP source guard is not supported on an interface that is in an aggregation group.
Solution
Remove the interface from the aggregation group.
257
Configuring ARP attack protection
In this chapter, SPE cards refer to cards prefixed with SPE, for example, SPE-1020-E-II.
Overview
Although ARP is easy to implement, it provides no security mechanism and thus is prone to network
attacks. An attacker can send
•
ARP packets by acting as a trusted user or gateway. As a result, the receiving router obtains
incorrect ARP entries, and thus a communication failure occurs.
•
A large number of IP packets with unreachable destinations. As a result, the receiving router
continuously resolves destination IP addresses and thus its CPU is overloaded.
•
A large number of ARP packets to bring a great impact to the CPU.
For more information about ARP attack features and types, see ARP Attack Protection Technology White
Paper.
ARP attacks and viruses are threatening LAN security. The router can provide multiple features to detect
and prevent such attacks. This chapter mainly introduces these features.
ARP attack protection configuration task list
Task
Flood
prevention
Remarks
Configuring ARP
defense against IP
packet attacks
Configuring ARP source
suppression
Optional.
Configure this function on
gateways (recommended).
Optional.
Enabling ARP blackhole routing
Configure this function on
gateways (recommended).
Optional.
Configuring source MAC-based ARP attack detection
Configure this function on
gateways (recommended).
Optional.
Configuring ARP packet source MAC consistency check
User and
gateway
spoofing
prevention
Configure this function on
gateways (recommended).
Optional.
Configuring ARP active acknowledgement
Configure this function on
gateways (recommended).
Optional.
Configuring ARP strict active acknowledgement
258
Configure this function on
gateways (recommended).
Task
Remarks
Optional.
Configuring authorized ARP
Configure this function on
gateways (recommended).
Configuring ARP defense against IP packet attacks
Introduction
If a router receives a large number of IP packets from a host to unreachable destinations:
•
The router sends a large number of ARP requests to the destination subnets, which increases the
load of the destination subnets.
•
The router keeps trying to resolve destination IP addresses, which increases the load of the CPU.
To protect the router from IP packet attacks, you can enable the ARP source suppression function or ARP
blackhole routing function.
If the packets have the same source address, you can enable the ARP source suppression function. With
the function enabled, whenever the number of ARP requests triggered by the packets with unresolvable
destination IP addresses from a host within 5 seconds exceeds a specific threshold, the router suppresses
the sending host from triggering any ARP requests within the following 5 seconds.
If the packets have various source addresses, you can enable the ARP blackhole routing function. After
receiving an IP packet whose destination IP address cannot be resolved by ARP, the router with this
function enabled immediately creates a blackhole route and simply drops all packets matching the route
during the aging time (defaults to 25 seconds) of the blackhole route.
Configuring ARP source suppression
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable ARP source suppression.
arp source-suppression enable
Disabled by default.
3.
Set the maximum number of packets with the
same source IP address but unresolvable
destination IP addresses that the router can
receive in 5 consecutive seconds.
arp source-suppression limit
limit-value
Optional.
10 by default.
Enabling ARP blackhole routing
Step
Command
Remarks
N/A
1.
Enter system view.
system-view
2.
Enable ARP blackhole
routing.
arp resolving-route enable
259
Optional.
Enabled by default.
Displaying and maintaining ARP defense against IP packet
attacks
Task
Command
Remarks
Display the ARP source suppression
configuration information.
display arp source-suppression [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Configuring source MAC-based ARP attack
detection
Introduction
This feature checks the number of ARP packets received from the same MAC address within 5 seconds
against a specific threshold. If the threshold is exceeded, the device adds the MAC address in an ARP
attack entry. Before the entry is aged out, the device handles the attack by using either of the following
methods:
•
Monitor—Generates log messages.
•
Filter—Generates log messages and discards subsequent ARP packets from that MAC address.
When an attack is detected on a VLAN interface, the router in filter method also discards IP packets from
or to the MAC address.
You can exclude the MAC addresses of some gateways and servers from this detection. This feature
does not inspect ARP packets from those devices even if they are attackers.
Only the ARP packets delivered to the CPU are checked.
Configuration procedure
To configure source MAC-based ARP attack detection:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable source MAC-based
ARP attack detection and
specify a handling method.
arp anti-attack source-mac { filter |
monitor }
Disabled by default.
3.
Configure the threshold.
arp anti-attack source-mac
threshold threshold-value
Optional.
4.
Configure the aging time for
source MAC-based ARP
attack detection entries.
arp anti-attack source-mac
aging-time time
Optional.
260
50 by default.
300 seconds by default.
Step
Command
Remarks
Optional.
5.
Exclude MAC addresses from
source MAC-based ARP
attack detection.
arp anti-attack source-mac
exclude-mac mac-address&<1-n>
By default, no MAC address is
excluded from source MAC-based
ARP attack detection.
The maximum value for n is 10.
NOTE:
After an ARP attack detection entry expires, the MAC address of the entry becomes ordinary.
Displaying and maintaining source MAC-based ARP attack
detection
Task
Command
Remarks
Display attacking entries detected.
display arp anti-attack source-mac { slot
slot-number | interface interface-type
interface-number } [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Configuring ARP packet source MAC consistency
check
This feature enables a gateway to filter out ARP packets whose source MAC address in the Ethernet
header is different from the sender MAC address in the message body, so that the gateway can learn
correct ARP entries.
By default, on SPE cards, the gateway filters out ARP packets whose source MAC address in the Ethernet
header is an address of all 0s, a broadcast MAC address, the host's MAC address, or a multicast MAC
address.
To enable ARP packet source MAC address consistency check:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable ARP packet source MAC
address consistency check.
arp anti-attack valid-check enable
Disabled by default.
261
Configuring ARP active acknowledgement
Introduction
Typically, the ARP active acknowledgement feature is configured on gateway devices to identify invalid
ARP packets.
ARP active acknowledgement works before the gateway creates or modifies an ARP entry to avoid
generating any incorrect ARP entry. For more information about its working mechanism, see ARP Attack
Protection Technology White Paper.
Configuration procedure
To configure ARP active acknowledgement:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable the ARP active
acknowledgement function.
arp anti-attack active-ack enable
Disabled by default.
Configuring ARP strict active acknowledgement
Typically, the ARP strict active acknowledgement feature is configured on gateway devices to identify
invalid ARP packets.
Strict active acknowledgement works before the gateway receives ARP replies and need to create or
modify an ARP entry to avoid generating any incorrect ARP entry. The gateway does not learn any ARP
entry from the received ARP replies destined to other hosts, and import the replies to the logs.
The ARP strict active acknowledgement function must work together with the ARP blackhole routing
function. Otherwise, the router operates in ARP active acknowledgement mode instead of ARP strict
active acknowledgement mode. For information about ARP blackhole routing, see "Enabling ARP
blackhole routing."
To configure ARP strict active acknowledgement:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable ARP blackhole routing.
arp resolving-route enable
N/A
3.
Enable ARP strict active acknowledgement.
arp anti-attack active-ack strict
enable
Disabled by default.
262
Configuring authorized ARP
Introduction
Authorized ARP entries are generated based on the DHCP clients' address leases on the DHCP server or
dynamic bindings on the DHCP relay agent. For more information about DHCP server and DHCP relay
agent, see Layer 3—IP Services Configuration Guide.
After enabled with authorized ARP, an interface is disabled from learning dynamic ARP entries to prevent
attacks from unauthorized clients that send packets using other clients' IP or MAC addresses, and to
allow only authorized clients to access network resources. Thus network security is enhanced.
NOTE:
Static ARP entries can overwrite authorized ARP entries, and authorized ARP entries can overwrite
dynamic ARP entries. But authorized ARP entries cannot overwrite static ARP entries, and dynamic ARP
entries cannot overwrite authorized ARP entries.
Configuration procedure
To enable authorized ARP:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
3.
Configure the DHCP server (or DHCP
relay agent) to support authorized ARP.
dhcp update arp
Not configured by default.
4.
Enable authorized ARP on the interface.
arp authorized enable
Disabled by default.
NOTE:
With the arp authorized enable command executed, an interface of a DHCP server (or a DHCP relay
agent) that does not support authorized ARP is disabled from dynamically learning ARP entries and
cannot generate authorized ARP entries.
Authorized ARP configuration example (on a DHCP server)
Network requirements
As shown in Figure 87, Router A acts as a DHCP server with an IP address pool of 10.1.1.0/24. Enable
authorized ARP on GigabitEthernet 3/1/1 of Router A. The host obtains an IP address of 10.1.1.2/24
from the DHCP server.
263
Figure 87 Network diagram
Configuration procedure
1.
Configure Router A:
# Configure the IP address of GigabitEthernet 3/1/1.
<RouterA> system-view
[RouterA] interface GigabitEthernet 3/1/1
[RouterA-GigabitEthernet3/1/1] ip address 10.1.1.1 24
[RouterA-GigabitEthernet3/1/1] quit
# Configure DHCP.
[RouterA] dhcp enable
[RouterA] dhcp server ip-pool 1
[RouterA-dhcp-pool-1] network 10.1.1.0 mask 255.255.255.0
[RouterA-dhcp-pool-1] quit
# Enter Ethernet interface view.
[RouterA] interface GigabitEthernet 3/1/1
# Configure the DHCP server to support authorized ARP.
[RouterA-GigabitEthernet3/1/1] dhcp update arp
# Enable authorized ARP.
[RouterA-GigabitEthernet3/1/1] arp authorized enable
2.
After the host obtains an IP address from Router A, display the authorized ARP entry information on
Router A.
[RouterA] display arp all
Type: S-Static
D-Dynamic
A-Authorized
IP Address
MAC Address
VLAN ID
Interface
Aging
Type
10.1.1.2
0012-3f86-e94c
N/A
GE3/1/1
N/A
A
The output shows that an IP address of 10.1.1.2 has been assigned to the host.
After that, the host must use the IP address and MAC address that are consistent with those in the
authorized ARP entry to communicate with Router A. Otherwise, the communication fails. Thus the
client validity is guaranteed.
Authorized ARP configuration example (on a DHCP relay
agent)
Network requirements
As shown in Figure 88, Router A acts as a DHCP server with an IP address pool of 10.10.1.0/24. Router
B is a DHCP relay agent, which conveys the IP address from the DHCP server to the host. Enable
authorized ARP on GigabitEthernet 3/1/2 of Router B.
264
Figure 88 Network diagram
DHCP relay agent
GE3/1/1
10.1.1.2/24
DHCP server
Router B
GE3/1/2
10.10.1.1/24
Host
GE3/1/1
10.1.1.1/24
Router A
Configuration procedure
1.
Configure Router A:
# Configure the IP address of GigabitEthernet 3/1/1.
<RouterA> system-view
[RouterA] interface GigabitEthernet 3/1/1
[RouterA-GigabitEthernet3/1/1] ip address 10.1.1.1 24
[RouterA-GigabitEthernet3/1/1] quit
# Configure DHCP.
[RouterA] dhcp enable
[RouterA] dhcp server ip-pool 1
[RouterA-dhcp-pool-1] network 10.10.1.0 mask 255.255.255.0
[RouterA-dhcp-pool-1] gateway-list 10.10.1.1
[RouterA-dhcp-pool-1] quit
[RouterA] ip route-static 10.10.1.0 24 10.1.1.2
2.
Configure Router B:
# Enable DHCP.
<RouterB> system-view
[RouterB] dhcp enable
# Configure the IP addresses of GigabitEthernet 3/1/1 and GigabitEthernet 3/1/2.
[RouterB] interface GigabitEthernet 3/1/1
[RouterB-GigabitEthernet3/1/1] ip address 10.1.1.2 24
[RouterB-GigabitEthernet3/1/1] quit
[RouterB] interface GigabitEthernet 3/1/2
[RouterB-GigabitEthernet3/1/2] ip address 10.10.1.1 24
# Enable DHCP relay agent on GigabitEthernet 3/1/2.
[RouterB-GigabitEthernet3/1/2] dhcp select relay
[RouterB-GigabitEthernet3/1/2] quit
# Add the DHCP server 10.1.1.1 to DHCP server group 1.
[RouterB] dhcp relay server-group 1 ip 10.1.1.1
# Correlate GigabitEthernet 3/1/2 to DHCP server group 1.
[RouterB] interface GigabitEthernet 3/1/2
[RouterB-GigabitEthernet3/1/2] dhcp relay server-select 1
# Configure the DHCP server to support authorized ARP.
265
[RouterB-GigabitEthernet3/1/2] dhcp update arp
# Enable authorized ARP.
[RouterB-GigabitEthernet3/1/2] arp authorized enable
3.
After the host obtains the IP address from Router A, display the authorized ARP information on
Router B.
[RouterB] display arp all
Type: S-Static
D-Dynamic
A-Authorized
IP Address
MAC Address
VLAN ID
Interface
Aging Type
10.10.1.2
0012-3f86-e94c
N/A
GE3/1/2
N/A
A
The output shows that Router A assigned an IP address of 10.10.1.2 to the host.
After that, the host must use the IP address and MAC address that are consistent with those in the
authorized ARP entry to communicate with Router B. Otherwise, the communication fails. Thus the
client validity is guaranteed.
266
Configuring URPF
In this chapter, SPC cards refer to the interface cards prefixed with SPC, for example, SPC-GT48L.
Overview
Unicast Reverse Path Forwarding (URPF) protects a network against source address spoofing attacks,
such as denial of service (DoS) and distributed denial of service (DDoS) attacks.
Attackers send packets with a forged source address to access a system that uses IP-based authentication,
in the name of authorized users or even the administrator. Even if the attackers cannot receive any
response packets, the attacks are still disruptive to the attacked target.
Figure 89 Source address spoofing attack
As shown in Figure 89, an attacker on Router A sends the server (Router B) requests with a forged source
IP address 2.2.2.1, and Router B sends response packets to IP address 2.2.2.1 (Router C). Consequently,
both Router B and Router C are attacked. URPF can prevent such attacks.
URPF check modes
URPF supports two check modes:
•
Strict URPF—For a packet to pass strict URPF check, the source address of the packet and the
receiving interface must match the destination address and output interface of a FIB entry. In some
scenarios such as asymmetrical routing, strict URPF might discard valid packets. Strict URPF is often
deployed between a provider edge (PE) device and a customer edge (CE) device.
•
Loose URPF—For a packet to pass loose URPF check, the source address of the packet must match
the destination address of a FIB entry. Loose URPF can avoid discarding valid packets, but might let
go attack packets. Loose URPF is often deployed between ISPs, especially in asymmetrical routing.
URPF features
When a default route exists, all packets that fail to match a specific FIB entry can match the default route
during URPF check and thus are permitted to pass. To avoid this situation, you can disable URPF from
using any default route to discard such packets.
By default, URPF discards packets that can only match a default route.
URPF operation
URPF does not check multicast packets.
267
Figure 90 shows how URPF works.
Figure 90 URPF work flow
1.
URPF checks source address validity:
{
{
{
2.
3.
Discards packets with a source broadcast address.
Discards packets with an all-zero source address but a non-broadcast destination address. (A
packet with source address 0.0.0.0 and destination address 255.255.255.255 might be a
DHCP or BOOTP packet and cannot be discarded.)
Proceeds to step 2 for other packets.
URPF checks whether the source address matches a FIB entry:
{
If yes, proceeds to step 3.
{
If not, discards the packet.
URPF checks whether the matching route is a default route:
268
{
{
4.
If yes, URPF checks whether the allow-default-route keyword is configured to allow the default
route: if yes, proceeds to step 4. If not, discards the packet.
If not, proceeds to step 4.
URPF checks whether the receiving interface matches the output interface of the matching FIB entry:
{
{
If yes, forwards the packet.
If not, URPF checks whether the check mode is loose: if yes, forwards the packet. If not, discards
the packet.
Network application
Figure 91 Network diagram
Configure strict URPF check between an ISP network and a customer network, and loose URPF check
between ISPs.
Configuring URPF
You can configure URPF on a specific interface. URPF configured on an interface takes effect on the
interface only.
Configuration restrictions and guidelines:
When you configure URPF on an interface, follow these restrictions and guidelines:
•
URPF does not work on tunnel interfaces.
•
URPF checks only packets arriving at the interface.
•
SPC interface cards support only strict IPv4 URPF check.
269
Configuration procedure
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter interface view.
interface interface-type
interface-number
N/A
Disabled by default.
3.
Enable URPF check
ip urpf { loose | strict }
[ allow-default-route ]
The loose and allow-default-route
keywords are supported only in
SPE operating mode. For
information about the system
operating mode, see
Fundamentals Configuration
Guide.
Do not configure the
allow-default-route keyword for
loose URPF check. Otherwise,
URPF might fail to work.
URPF configuration example
Network requirements
As shown in Figure 92, enable strict URPF check on GigabitEthernet 3/1/1 of Router B and permit
packets from network 10.1.1.0/24.
Enable strict URPF check on GigabitEthernet 3/1/1 of Router A to allow using the default route for URPF
check.
Figure 92 Network diagram
Configuration procedure
1.
Configure Router B:
# Specify the IP address of GigabitEthernet 3/1/1.
[RouterB] interface GigabitEthernet 3/1/1
[RouterB-GigabitEthernet3/1/1] ip address 1.1.1.2 255.255.255.0
# Enable strict URPF check on GigabitEthernet 3/1/1.
[RouterB-GigabitEthernet3/1/1] ip urpf strict acl 2010
2.
Configure Router A:
# Specify the IP address of GigabitEthernet 3/1/1.
<RouterA> system-view
[RouterA] interface GigabitEthernet 3/1/1
[RouterA-GigabitEthernet3/1/1] ip address 1.1.1.1 255.255.255.0
270
# Enable strict URPF check on GigabitEthernet 3/1/1 and allow using the default route for URPF
check.
[RouterA-GigabitEthernet3/1/1] ip urpf strict allow-default-route
271
Configuring COPS
Overview
Common Open Policy Service (COPS) is a simple query and response protocol that can be used to
exchange policy information between a policy server and its clients. For example, COPS can be used to
perform policy-based admission control over Resource Reservation Protocol (RSVP) signaling messages.
Through the interaction between the clients and the server, all RSVP signaling messages can be
monitored and controlled in a centralized way. This helps realize negotiation, scheduling, and
implementation of end-to-end resources on the overall network.
In addition, COPS is also a service-oriented network management protocol. It can be used to perform
policy-based admission control over a variety of network applications, such as quality of service (QoS),
network access, and firewall. HP devices can act as clients to interact with the remote policy server and
implement policy-based admission control over 802.1X services.
COPS defines policy decision point (PDP) and policy enforcement point (PEP) in its communication model.
A PDP is a policy server, and a PEP is a client. They can exchange policy information through COPS.
COPS characteristics
A PEP and a PDP exchange COPS messages as follows: The PEP sends policy requests, policy updates,
and policy deletes to the remote PDP and the PDP returns decisions back to the PEP. COPS has the
following characteristics:
•
Using TCP as its transport layer protocol for reliable exchange of messages between clients and the
server.
•
Providing extensibility to support a variety of client services without the need of modifying COPS.
•
Providing message level security for authentication, replay protection, and message integrity. IP
Security (IPsec) and Transport Layer Security (TLS) can be leveraged to authenticate and protect the
exchanged messages between the PEP and the PDP.
•
A client and a server share requests and decisions. A policy request sent by a PEP is stored in the
remote PDP until the PEP requests to remove it. For a policy request, the PDP can make a solicited
decision right after the request is received, or make an unsolicited decision when status changes. A
PEP modifies its local decision to keep it consistent with that on the PDP after receiving the decision.
•
A PDP can configure a policy for a PEP and issue decisions to the PEP according to the policy. In
case the policy is not available, the PDP can notify the PEP to remove its local decisions.
COPS interaction
Figure 93 shows the COPS message interaction process.
272
Figure 93 COPS message interaction process
1.
After startup, the PEP initiates a TCP connection request to the PDP. After the TCP connection is
established, the PEP and PDP exchange COPS messages through the connection.
2.
The PEP sends a Client-Open (OPN) message to the PDP to request a COPS connection. This
message notifies the PDP of the client type supported by the PEP.
3.
If the PDP supports the client type, it returns a Client-Accept (CAT) message to the PEP. Otherwise,
it returns a Client-Close (CC) message. After the COPS connection is established, the PEP and the
PDP send each other Keep-Alive (KA) messages to keep the COPS connection.
4.
The PEP sends a Request (REQ) message to the PDP to request a policy for a specific service, and
starts the response timeout timer. If the PEP does not receive any response from the PDP within the
specified response timeout timer, it removes the REQ state immediately and notifies the PDP to
remove the saved REQ state.
5.
After receiving the REQ message from the PEP, the PDP replies a Decision (DEC) message
containing decision content to the PEP.
6.
After receiving the DEC message, the PEP conducts service processing according to the decision
defined in the DEC message, and sends a Report (RPT) message to notify the PDP of the processing
result. The PDP can update and remove the decision at any time. If the PEP receives a DEC
message after the response timeout timer expires, the PEP does not process the message.
7.
If the PDP specifies the interval for reporting accounting information when the PDP and the PEP
establish the COPS connection, the PEP periodically sends RPT messages containing accounting
information to the PDP after the PEP receives the DEC message.
COPS applications
COPS can be applied to 802.1X authentication to implement authorization policy control over 802.1X
users. Figure 94 shows a typical network diagram.
273
Figure 94 Network diagram
After the PEP starts, it establishes a COPS connection with the PDP according to the COPS configuration.
After a 802.1X user passes authentication and gets online, the PEP and the PDP interact as follows:
•
As the PEP, the device sends the PDP a REQ message containing the online user information
(username, host IP address, host MAC address, access port number), to request authorization
information for the user (such as VLAN and ACL) from the PDP.
•
According to the submitted user information and the PDP's policy configuration, the PDP sends the
PEP a DEC message containing the authorization information. When the user is online, the PDP can
update the authorization information for the user at any time.
•
If the accounting interval is specified on the PDP, the PEP periodically sends RPT messages
containing accounting information to the PDP when the user is online.
•
After the user gets offline, the PEP notifies the PDP to remove the policy request for the user.
NOTE:
If both COPS and another protocol such as RADIUS are configured on the access device for user
authorization, only COPS is effective. For more information about other authorization schemes, see
"Configuring AAA."
Protocols and standards
RFC 2748, Common Open Policy Service
COPS configuration task list
COPS configuration includes configuring the COPS client ID and configuring a COPS scheme. A COPS
scheme takes effect after being referenced by a service module. Only 802.1X can reference COPS
schemes. For more information, see "Configuring 802.1X."
After a COPS scheme is referenced by a service module, modifications to the COPS scheme do not take
effect immediately. To bring them into effect, cancel the reference of the COPS scheme for the service
module and then reference the COPS scheme again.
Complete the following tasks to configure COPS:
274
Task
Remarks
Setting the COPS client ID
Required.
Configuring a COPS
scheme
Creating a COPS scheme
Required.
Specifying a PDP
Required.
Setting the COPS response timeout
time
Optional.
Setting the reconnection attempt
interval
Optional.
Setting the shared key for COPS
packet exchange
Optional.
Setting the COPS client ID
As the PEP, the device uses a COPS client ID to identify itself. The COPS client ID and the interface
information of the COPS service compose the PEP ID in the OPN packet sent to the PDP. The PDP uses the
PEP ID to identify the PEP.
One device can be configured with only one COPS client ID.
If multiple PEPs communicate with the same PDP, the COPS client ID configured on each PEP must be
unique.
To set the COPS client ID:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Set the COPS client ID.
cops id pep-id
By default, no COPS client ID is
configured.
Configuring a COPS scheme
The device supports up to 16 COPS schemes.
Creating a COPS scheme
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a COPS scheme,
and enter its view.
cops scheme scheme-name
By default, no COPS scheme exists.
275
Specifying a PDP
Up to two PDPs can be specified in a COPS scheme, and they function as the primary PDP and backup
PDP according to the order they are specified.
The PEP first tries to establish a TCP connection to the primary PDP. If the attempt fails, the PEP contacts
the backup PDP. The PEP will not stop until a connection is successfully established or the reference of the
COPS scheme is cancelled.
To specify a PDP:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter COPS scheme view.
cops scheme cops-scheme-name
N/A
3.
Specify a PDP.
server ipv4 ipv4-address [ port
port-number ]
By default, no PDP is specified.
Setting the COPS response timeout time
After the PEP sends a REQ message to the PDP, the PEP starts the response timeout timer. If the PEP does
not receive any response from the PDP before the timer expires, it directly removes the REQ message and
notifies the service module.
To set the COPS response timeout time:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter COPS scheme view.
cops scheme scheme-name
N/A
3.
Set the COPS response
timeout time.
timer response timeout time
Optional.
5 seconds by default.
Setting the reconnection attempt interval
If the PEP fails to establish a COPS connection with a PDP, or the COPS connection is torn down because
the keep-alive (KA) timer times out, the PEP tries to establish a COPS connection with the other PDP if two
PDPs are specified. The attempt to establish a connection with either of the PDPs will not stop until a
connection is successfully established or the reference of the COPS scheme is cancelled.
If only one PDP is specified, the PEP tries to establish a COPS connection with the PDP repeatedly until the
connection is successfully established or the reference of the COPS scheme is cancelled.
The reconnection attempt interval specifies the time interval from when the current connection attempt
fails to when the next connection attempt is initiated.
To set the reconnection attempt interval:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
276
Step
Command
Remarks
N/A
2.
Enter COPS scheme view.
cops scheme scheme-name
3.
Set the reconnection
attempt interval.
timer reconnect interval interval
Optional.
60 seconds by default.
Setting the shared key for COPS packet exchange
A shared key helps verify the integrity of the COPS packets transferred between a PEP and a PDP and
make sure the PEP communicates with the correct PDP. The sender uses the specified algorithm and
shared key to generate a digest carried in COPS packets. After receiving the COPS packets, the receiver
uses the same algorithm and shared key to generate a digest and compare it against the digest in the
received packets. If they are the same, the packets pass the integrity check. Otherwise, the receiver drops
the packets.
The configuration of shared key on the PEP must be consistent with that on the PDP. That is, if a shared key
is configured on the PEP, the same one must be configured on the PDP. If no shared key is configured on
the PEP, do not configure a shared key on the PDP either.
To set the shared key for COPS packet exchange:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter COPS scheme view.
cops scheme scheme-name
N/A
3.
Set the shared key for COPS
packet exchange.
key key-string [ algorithm
hmac-md5-96 ]
Optional.
By default, no shared key is
configured.
Displaying and maintaining COPS
Task
Command
Remarks
Display COPS connection
information.
display cops connection [ slot slot-number ] [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
NOTE:
The COPS connection information is available only after the COPS scheme is referenced by a service
module.
COPS configuration example
Network requirements
As shown in Figure 95, the 802.1X client connects to GigabitEthernet 3/1/2 of the device, and the
device connects to two PDPs and one RADIUS server. The requirements are as follows:
277
•
The device uses the RADIUS server to perform authentication and accounting for the 802.1X user.
•
After the 802.1X user passes authentication, the device functions as the PEP to request user
authorization attributes from the PDP.
•
The two PDPs back up each other. The IP address of the primary PDP is 192.168.0.3/24, and the IP
address of the backup PDP is 192.168.0.4/24.
•
The reconnection attempt interval is 30 seconds, the response timeout time is 10 seconds, the
shared key is abcdefg, and the HMAC-MD5-96 algorithm is adopted.
Figure 95 Network diagram
PDP (backup)
PDP
IP: 192.168.0.4/24
Port: 3288
RADIUS server
IP: 192.168.0.3/24
Port: 3288
IP: 192.168.0.2/24
GE3/1/1
192.168.0.1/24
GE3/1/2
IP network
PEP
802.1X client
Device
Configuration procedure
Before you perform the following configuration, configure the RADIUS server to make sure that
authentication and accounting operate correctly, and configure the PDPs, including COPS connection
parameters, usernames, and their authorization attributes (such as VLAN and ACL).
The following involves part of AAA and RADIUS configurations. For more information, see "Configuring
AAA."
1.
Configure the RADIUS scheme:
<Device> system-view
# Create RADIUS scheme radius1 and enter its view.
[Device] radius scheme radius1
# Specify the primary authentication server, the primary accounting server, and the authentication
and accounting keys.
[Device-radius-radius1] primary authentication 192.168.0.2
[Device-radius-radius1] primary accounting 192.168.0.2
[Device-radius-radius1] key authentication name
[Device-radius-radius1] key accounting money
# Configure the scheme to exclude the domain names from usernames sent to the RADIUS server.
(Optional, keep this configuration consistent with that configured on the server.)
[Device-radius-radius1] user-name-format without-domain
[Device-radius-radius1] quit
2.
Configure the authentication domain:
# Create ISP domain bbb and enter its view.
[Device] domain bbb
# Configure the authentication and accounting methods for the domain.
278
[Device-isp-bbb] authentication lan-access radius-scheme radius1
[Device-isp-bbb] accounting lan-access radius-scheme radius1
[Device-isp-bbb] quit
3.
Configure COPS:
# Set the COPS client ID as 192.168.0.1.
[Device] cops id 192.168.0.1
# Create COPS scheme cops1x and enter its view.
[Device] cops scheme cops1x
# Specify the primary PDP with IP address 192.168.0.3 and port number 3288.
[Device-cops-cops1x] server ipv4 192.168.0.3 port 3288
# Specify the backup PDP with IP address 192.168.0.4 and port number 3288.
[Device-cops-cops1x] server ipv4 192.168.0.4 port 3288
# Set the COPS reconnection attempt interval to 30 seconds.
[Device-cops-cops1x] timer reconnect interval 30
# Set the COPS response timeout timer to 10 seconds.
[Device-cops-cops1x] timer response timeout 10
# Set the shared key for COPS message exchange to abcdefg, and specify the HMAC-MD5-96
algorithm.
[Device-cops-cops1x] key abcdefg algorithm hmac-md5-96
[Device-cops-copa1x] quit
4.
Configure 802.1X:
# Enable 802.1X globally.
[Device] dot1x
# Enable 802.1X on GigabitEthernet 3/1/2.
[Device] dot1x interface GigabitEthernet 3/1/2
# Configure 802.1X to reference COPS scheme cops1x.
[Device] dot1x cops cops1x
Verifying the configuration
After 802.1X references the COPS scheme, the device establishes a COPS connection with the primary
PDP. To view COPS connection information, use the display cops connection command:
[Device] display cops connection
PEP ID: 192.168.0.1-s0
Client Type: COPS-1X
Status: UP
Connection Losts: 2
Reconnections: 4
KA Timer: 30s
ACCT Timer: 600s
Reconnect Interval: 30s
Response Timeout: 10s
Current TCP Connection:
PEP:
192.168.0.1/1031
PDP:
192.168.0.3/3288
Last TCP Connection:
PEP:
192.168.0.1/1031
PDP:
192.168.0.4/3288
TX:
REQ: Succ
101,
Fail
4
RPT: Succ
100,
Fail
1
279
OPN: Succ
1,
Fail
0
KA:
Succ
5,
Fail
0
DRQ: Succ
1,
Fail
0
SSC: Succ
3,
Fail
0
RX:
CAT: 1
KA: 5
S-DEC: 100
UNS-DEC: 2
SSQ: 3
After the user passes 802.1X authentication, the PDP assigns the authorization attributes to the 802.1X
user. To view online user connection information, use the display connection command.
Troubleshooting COPS
A COPS connection cannot be established after the COPS
scheme is referenced
Symptom
After the PEP initiates a policy request, the PDP does not return any response.
Analysis
•
The COPS client ID is not configured for the PEP device.
•
The COPS scheme referenced by the service module is not configured.
•
No PDP is specified or a wrong PDP is specified in the COPS scheme referenced by the service
module.
•
The shared key set in the COPS scheme referenced by the service module is not consistent with that
configured on the specified PDP in the scheme.
•
Set the COPS client ID for the PEP device.
•
Reference the COPS scheme for the service module.
•
Specify the correct PDP in the COPS scheme.
•
Make sure the shared key in the COPS scheme is consistent with that configured on the specified
PDP.
Solution
280
Configuring FIPS
NOTE:
Only the SR02SRP1F3 and SR02SRP2F3 cards support FIPS configuration.
Overview
The Federal Information Processing Standard (FIPS) 140-2, developed by the National Institute of
Standard and Technology (NIST) of the United States, specifies the security requirements for
cryptographic modules. FIPS 140-2 defines four levels of security, simply named "Level 1" to "Level 4"
from low to high. The device supports Level 2.
Unless otherwise noted, FIPS in the document refers to FIPS 140-2.
FIPS self-tests
When the device works in FIPS mode, it has self-test mechanisms, including the power-up self-test and
conditional self-tests, to ensure the normal operation of cryptography modules. You can also trigger a
self-test. If a self-test fails, the device reboots.
Power-up self-tests
The power-up self-test, also called "known-answer test", examines the availability of FIPS-allowed
cryptographic algorithms. A cryptographic algorithm is run on data for which the correct output is
already known. The calculated output is compared with the known answer. If they are not identical, the
known-answer test fails.
The power-up self-test examines the following cryptographic algorithms: DSA (signature and
authentication), RSA (signature and authentication), RSA (encryption and decryption), AES, 3DES, SHA1,
SHA256, SHA512, HMAC-SHA1, and random number generator algorithms.
Conditional self-tests
A conditional self-test runs when an asymmetrical cryptographic module or a random number generator
module is invoked. Conditional self-tests include the following types:
•
Pair-wise consistency test—This test is run when a DSA/RSA asymmetrical key-pair is generated. It
uses the public key to encrypt a plain text, and uses the private key to decrypt the encrypted text. If
the decryption is successful, the test succeeds. Otherwise, the test fails.
•
Continuous random number generator test—This test is run when a random number is generated.
If two consecutive random numbers are different, the test succeeds. Otherwise, the test fails. This test
is also run when a DSA/RSA asymmetrical key pair is generated.
281
Triggering self-tests
To examine whether the cryptography modules operate normally, you can use a command to trigger a
self-test on the cryptographic algorithms. The triggered self-test is the same as the power-up self-test.
To trigger a self-test:
Step
Command
1.
Enter system view.
system-view
2.
Trigger a self-test.
fips self-test
Configuring FIPS mode
After you enable FIPS mode, the system has strict security requirements, and performs self-test on
cryptography modules to make sure they operate correctly. For Common Criteria (CC) evaluation in FIPS
mode, the router also operates in an operating mode that complies with the CC standard.
Before enabling FIPS mode, complete the following tasks:
Configure the login username and password.
•
The password must comprise no less than 8 characters and must contain uppercase and lowercase
letters, digits, and special characters.
•
Delete all MD5-based digital certificates.
•
Delete all key pairs.
To configure FIPS, complete the following tasks:
1.
Enable the FIPS mode.
2.
Enable the password control function.
3.
Configure local user attributes (including local username, service type, and password) on the
router.
4.
Save the configuration.
5.
Reboot the router to enter FIPS mode.
Enabling FIPS mode
After enabling FIPS mode, you must reboot the device to validate the configuration.
To enable FIPS mode:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable FIPS mode
fips mode enable
Not enabled by default.
After you enable FIPS mode and reboot the router, the following changes occur:
•
FTP/TFTP is disabled.
•
Telnet is disabled.
282
•
HTTP is disabled.
•
SNMPv1 and SNMPv2c are disabled. Only SNMPv3 is available.
•
SSL only supports TLS1.0.
•
SSH does not support SSHv1 clients.
•
SSH only supports RSA.
•
Generated RSA key pairs must have a modulus length of 2048 bits. Generated DSA key pairs must
have a modulus of at least 1024 bits.
•
SSH, SNMPv3, IPsec and SSL do not support DES, 3DES, RC4, or MD5.
Displaying and maintaining FIPS
Task
Command
Remarks
Display FIPS state.
display fips status
Available in any view.
FIPS configuration example
Network requirements
Configure the router to operate in FIPS mode and create a local user for the PC so that PC can log in to
the router in FIPS mode.
Figure 96 Network diagram
Configuration procedure
CAUTION:
After you enable the FIPS mode, be sure to create a local user and its password before you reboot the
router. Otherwise, you cannot log in to the router. To log into the router, you must reboot the router without
loading the configuration file (by ignoring or removing the configuration file).
1.
Configure the router:
# Enable the FIPS mode.
<Sysname> system-view
[Sysname] fips mode enable
FIPS mode change requires a device reboot. Continue?[Y/N]:y
Change the configuration to meet FIPS mode requirements, save the configuration
to the next-startup configuration file, and then reboot to enter FIPS mode.
# Enable the password control function.
[Sysname] password-control enable
283
# Create a local user named test, and set its service type as terminal, privilege level as 3, and password
as AAbbcc1234%. The password must contain both uppercase and lowercase letters, digits, and special
characters.
[Sysname] local-user test
[Sysname-luser-test] service-type terminal
[Sysname-luser-test] authorization-attribute level 3
[Sysname-luser-test] password
Password:***********
Confirm :***********
Updating user(s) information, please wait...........
[Sysname-luser-test] quit
# Save the configuration.
[Sysname] save
The current configuration will be written to the device. Are you sure? [Y/N]:y
Please input the file name(*.cfg)[flash:/startup.cfg]
(To leave the existing filename unchanged, press the enter key):
flash:/startup.cfg exists, overwrite? [Y/N]:y
Validating file. Please wait..........................
Saved the current configuration to mainboard device successfully.
Configuration is saved to device successfully.
[Sysname] quit
# Reboot the router.
<Sysname> reboot
2.
Verify the configuration:
After the router reboots, enter the username test and password AAbbcc1234%. The system prompts that
your first login is successful, and asks you to enter a new password. Enter a new password which has at
least four characters different than the previous one and confirm the password. Then, the system displays
the <Sysname> prompt.
User interface aux0 is available.
Please press ENTER.
Login authentication
Username:test
Password:
Info: First logged in. For security reasons you will need to change your password.
Please enter your new password.
Password:**********
Confirm :**********
Updating user(s) information, please wait...........
<Sysname>
# Display the current FIPS mode.
<Sysname> display fips status
FIPS mode is enabled
284
Configuring PKI
Overview
The Public Key Infrastructure (PKI) is a general security infrastructure for providing information security
through public key technologies.
PKI, also called asymmetric key infrastructure, uses a key pair to encrypt and decrypt the data. The key
pair consists of a private key and a public key. The private key must be kept secret but the public key
needs to be distributed. Data encrypted by one of the two keys can only be decrypted by the other.
A key problem of PKI is how to manage the public keys. PKI employs the digital certificate mechanism to
solve this problem. The digital certificate mechanism binds public keys to their owners, helping distribute
public keys in large networks securely.
With digital certificates, the PKI system provides network communication and e-commerce with security
services such as user authentication, data non-repudiation, data confidentiality, and data integrity.
HP's PKI system provides certificate management for IP Security (IPsec), Secure Sockets Layer (SSL), and
WLAN Authentication and Privacy Infrastructure (WAPI).
PKI terminology
Digital certificate
A digital certificate is a file signed by a certificate authority (CA) for an entity. It includes mainly the
identity information of the entity, the public key of the entity, the name and signature of the CA, and the
validity period of the certificate, where the signature of the CA ensures the validity and authority of the
certificate. A digital certificate must comply with the international standard of ITU-T X.509. The most
common standard is X.509 v3.
This document involves local certificate and CA certificate. A local certificate is a digital certificate
signed by a CA for an entity, and a CA certificate is the certificate of a CA. If multiple CAs are trusted
by different users in a PKI system, the CAs will form a CA tree with the root CA at the top level. The root
CA has a CA certificate signed by itself and each lower level CA has a CA certificate signed by the CA
at the next higher level.
Certificate revocation list
An existing certificate might need to be revoked when, for example, the user name changes, the private
key leaks, or the user stops the business. Revoking a certificate will remove the binding of the public key
with the user identity information. In PKI, the revocation is made through certificate revocation lists (CRLs).
Whenever a certificate is revoked, the CA publishes one or more CRLs to show all certificates that have
been revoked. The CRLs contain the serial numbers of all revoked certificates and provide an effective
way for checking the validity of certificates.
A CA might publish multiple CRLs when the number of revoked certificates is so large that publishing
them in a single CRL might degrade network performance, and it uses CRL distribution points to indicate
the URLs of these CRLs.
285
CA policy
A CA policy is a set of criteria that a CA follows in processing certificate requests, issuing and revoking
certificates, and publishing CRLs. Usually, a CA advertises its policy in the form of certification practice
statement (CPS). A CA policy can be acquired through out-of-band means such as phone, disk, and
email. As different CAs might use different methods to check the binding of a public key with an entity,
make sure that you understand the CA policy before selecting a trusted CA for certificate request.
PKI architecture
A PKI system consists of entities, a CA, a registration authority (RA) and a PKI repository, as shown
in Figure 97.
Figure 97 PKI architecture
PKI entity—An entity is an end user of PKI products or services, such as a person, an organization, a
device like a router or a switch, or a process running on a computer.
CA—A CA is a trusted authority responsible for issuing and managing digital certificates. A CA issues
certificates, specifies the validity periods of certificates, and revokes certificates as needed by publishing
CRLs.
RA—A registration authority (RA) is an extended part of a CA or an independent authority. An RA can
implement functions including identity authentication, CRL management, key pair generation and key
pair backup. The PKI standard recommends that an independent RA be used for registration
management to achieve higher security of application systems.
Repository—A PKI repository can be a Lightweight Directory Access Protocol (LDAP) server or a common
database. It stores and manages information like certificate requests, certificates, keys, CRLs and logs
when it provides a simple query function.
LDAP is a protocol for accessing and managing PKI information. An LDAP server stores user information
and digital certificates from the RA server and provides directory navigation service. From an LDAP server,
an entity can retrieve local and CA certificates of its own as well as certificates of other entities.
PKI applications
The PKI technology can satisfy the security requirements of online transactions. As an infrastructure, PKI
has a wide range of applications. Here are some application examples.
286
VPN—A virtual private network (VPN) is a private data communication network built on the public
communication infrastructure. A VPN can leverage network layer security protocols (for instance, IPsec)
in conjunction with PKI-based encryption and digital signature technologies for confidentiality.
Secure emails—Emails require confidentiality, integrity, authentication, and non-repudiation. PKI can
address these needs. The secure email protocol that is developing rapidly is Secure/Multipurpose
Internet Mail Extensions (S/MIME), which is based on PKI and allows for transfer of encrypted mails with
signature.
Web security—For web security, two peers can establish an SSL connection first for transparent and
secure communications at the application layer. With PKI, SSL enables encrypted communications
between a browser and a server. Both of the communication parties can verify each other’s identity
through digital certificates.
PKI operation
In a PKI-enabled network, an entity can request a local certificate from the CA and the device can check
the validity of certificates. Here is how it operates:
1.
An entity submits a certificate request to the RA.
2.
The RA reviews the identity of the entity and then sends the identity information and the public key
with a digital signature to the CA.
3.
The CA verifies the digital signature, approves the application, and issues a certificate.
4.
The RA receives the certificate from the CA, sends it to the LDAP server or other distribution points
to provide directory navigation service, and notifies the entity that the certificate is successfully
issued.
5.
The entity retrieves the certificate. With the certificate, the entity can communicate with other
entities safely through encryption and digital signature.
6.
The entity makes a request to the CA when it needs to revoke its certificate. The CA approves the
request, updates the CRLs and publishes the CRLs on the LDAP server or other distribution points.
PKI configuration task list
Task
Remarks
Configuring an entity DN
Required.
Configuring a PKI domain
Required.
Submitting a PKI certificate request
Submitting a certificate request
in auto mode
Submitting a certificate request
in manual mode
Required.
Use either approach.
Retrieving a certificate manually
Optional.
Verifying PKI certificate
Optional.
Destroying a local RSA or ECDSA key pair
Optional.
Deleting a certificate
Optional.
Configuring an access control policy
Optional.
287
Configuring an entity DN
A certificate is the binding of a public key and the identity information of an entity, where the identity
information is identified by an entity distinguished name (DN). A CA identifies a certificate applicant
uniquely by entity DN.
An entity DN is defined by these parameters:
•
Common name of the entity.
•
Country code of the entity, a standard 2-character code. For example, US represents the United
States.
•
Fully qualified domain name (FQDN) of the entity, a unique identifier of an entity on the network.
It consists of a host name and a domain name and can be resolved to an IP address. For example,
www.whatever.com is an FQDN, where www is a host name and whatever.com a domain name.
•
IP address of the entity.
•
Locality where the entity resides.
•
Organization to which the entity belongs.
•
Unit of the entity in the organization.
•
State where the entity resides.
Configuration guidelines
•
The configuration of an entity DN must comply with the CA certificate issue policy. You must
determine, for example, which entity DN parameters are mandatory and which are optional.
Otherwise, certificate requests might be rejected.
•
Up to two entities can be created on a device.
•
The Windows 2000 CA server has some restrictions on the data length of a certificate request. If the
entity DN in a certificate request goes beyond a certain limit, the server will not respond to the
certificate request.
Configuration procedure
To configure an entity DN:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create an entity and enter its
view.
pki entity entity-name
No entity exists by default.
3.
Configure the common name
for the entity.
common-name name
4.
Configure the country code
for the entity.
country country-code-str
5.
Configure the FQDN for the
entity.
fqdn name-str
Optional.
No common name is specified by
default.
Optional.
288
No country code is specified by
default.
Optional.
No FQDN is specified by default.
Step
Command
Optional.
6.
Configure the IP address for
the entity.
ip ip-address
7.
Configure the locality for the
entity.
locality locality-name
No IP address is specified by
default.
Optional.
No locality is specified by default.
Optional.
8.
Configure the organization
name for the entity.
organization org-name
9.
Configure the unit name for
the entity.
organization-unit org-unit-name
10. Configure the state or
province for the entity.
Remarks
No organization is specified by
default.
Optional.
No unit is specified by default.
Optional.
state state-name
No state or province is specified by
default.
Configuring a PKI domain
Before requesting a PKI certificate, an entity needs to be configured with some enrollment information,
which is referred to as a PKI domain. A PKI domain is intended only for convenience of reference by other
applications like IKE and SSL, and has only local significance. The PKI domain configured on a device
is invisible to the CA and other devices, and each PKI domain has its own parameters.
A PKI domain is defined by these parameters:
•
Trusted CA—An entity requests a certificate from a trusted CA.
•
Entity—A certificate applicant uses an entity to provide its identity information to a CA.
•
RA—Generally, an independent RA is in charge of certificate request management. It receives the
registration request from an entity, checks its qualification, and determines whether to ask the CA
to sign a digital certificate. The RA only checks the application qualification of an entity. It does not
issue any certificate. Sometimes, the registration management function is provided by the CA, in
which case no independent RA is required. HP recommends you to deploy an independent RA.
•
URL of the registration server—An entity sends a certificate request to the registration server
through Simple Certification Enrollment Protocol (SCEP), a dedicated protocol for an entity to
communicate with a CA.
•
Polling interval and count—After an applicant makes a certificate request, the CA might need a
long period of time if it verifies the certificate request manually. During this period, the applicant
needs to query the status of the request periodically to get the certificate as soon as possible after
the certificate is signed. You can configure the polling interval and count to query the request status.
•
IP address of the LDAP server—An LDAP server is usually deployed to store certificates and CRLs.
If this is the case, you need to configure the IP address of the LDAP server.
•
Fingerprint for root certificate verification—After receiving the root certificate of the CA, an entity
needs to verify the fingerprint of the root certificate, namely, the hash value of the root certificate
content. This hash value is unique to every certificate. If the fingerprint of the root certificate does not
match the one configured for the PKI domain, the entity will reject the root certificate.
289
Configuration guidelines
•
Up to 32 PKI domains can be created on a device.
•
The CA name is required only when you retrieve a CA certificate. It is not used when in local
certificate request.
•
The URL of the server for certificate request does not support domain name resolution.
Configuration procedure
To configure a PKI domain:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a PKI domain and
enter its view.
pki domain domain-name
No PKI domain exists by default.
3.
Specify the trusted CA.
ca identifier name
No trusted CA is specified by
default.
4.
Specify the entity for
certificate request.
certificate request entity
entity-name
5.
Specify the authority for
certificate request.
certificate request from { ca | ra }
No authority is specified by
default.
6.
Configure the URL of the
server for certificate request.
certificate request url url-string
No URL is configured by default.
7.
Configure the polling interval
and attempt limit for querying
the certificate request status.
certificate request polling { count
count | interval minutes }
The polling is executed for up to 50
times at the interval of 20 minutes
by default.
Specify the LDAP server.
ldap-server ip ip-address [ port
port-number ] [ version
version-number ]
Optional.
8.
9.
Configure the fingerprint for
root certificate verification.
No entity is specified by default.
The specified entity must exist.
Optional.
root-certificate fingerprint { md5 |
sha1 } string
No LDP server is specified by
default.
Required when the certificate
request mode is auto and optional
when the certificate request mode
is manual. In the latter case, if you
do not configure this command, the
fingerprint of the root certificate
must be verified manually.
No fingerprint is configured by
default.
Submitting a PKI certificate request
When requesting a certificate, an entity introduces itself to the CA by providing its identity information
and public key, which will be the major components of the certificate. A certificate request can be
submitted to a CA in offline mode or online mode. In offline mode, a certificate request is submitted to
a CA by an "out-of-band" means such as phone, disk, or email.
Online certificate request falls into manual mode and auto mode.
290
Submitting a certificate request in auto mode
In auto mode, an entity automatically requests a certificate from the CA server if it has no local certificate
for an application working with PKI. For example, when PKI certificate authentication is used, if no local
certificate is available during IKE negotiation, the entity automatically requests one, and saves the local
certificate after retrieving it from the CA. If the PKI domain has no CA certificate before the entity submits
the certificate request, the entity automatically retrieves the CA certificate first.
To configure an entity to submit a certificate request in auto mode:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter PKI domain view.
pki domain domain-name
N/A
3.
Set the certificate request
mode to auto.
certificate request mode auto
[ key-length key-length | password
{ cipher | simple } password ] *
Manual by default.
NOTE:
If an automatically requested certificate will expire or has expired, the entity does not initiate a re-request
to the CA automatically, and the services using the certificate might be interrupted.
Submitting a certificate request in manual mode
In manual mode, you must submit a local certificate request for an entity. Before the request, you must
retrieve a CA certificate and generate a key pair for the PKI domain.
The CA certificate in the PKI domain is used to verify the authenticity and validity of a local certificate.
Generating an RSA key pair is an important step in certificate request. The key pair includes a public key
and a private key. The private key is kept by the user. The public key is transferred to the CA along with
some other information. For more information about RSA and ECDSA key pair configuration, see
"Managing public keys."
Configuration guidelines
•
If a PKI domain already has a local certificate, creating an RSA key pair will result in inconsistency
between the key pair and the certificate. To generate a new RSA key pair, delete the local certificate
and then issue the public-key local create command.
•
A newly created key pair will overwrite the existing one. If you perform the public-key local create
command in the presence of a local RSA or ECDSA key pair, the system will ask you whether you
want to overwrite the existing one.
•
If a PKI domain already has a local certificate, you cannot request another certificate for it. This
helps avoid inconsistency between the certificate and the registration information resulting from
configuration changes. Before requesting a new certificate, use the pki delete-certificate command
to delete the existing local certificate and the CA certificate stored locally.
•
When it is impossible to request a certificate from the CA through SCEP, you can print the request
information or save the request information to a local file, and then send the printed information or
saved file to the CA by an out-of-band means. To print the request information, use the pki
request-certificate domain command with the pkcs10 keyword. To save the request information to
291
a local file, use the pki request-certificate domain command with the pkcs10 filename filename
option.
•
Make sure the clocks of the entity and the CA are synchronous. Otherwise, the validity period of the
certificate will be abnormal.
•
The pki request-certificate domain configuration will not be saved in the configuration file.
Configuration procedure
To submit a certificate request in manual mode:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter PKI domain view.
pki domain domain-name
N/A
3.
Set the certificate request
mode to manual.
certificate request mode manual
4.
Return to system view.
quit
N/A
5.
Retrieve a CA certificate
manually.
See "Retrieving a certificate
manually"
N/A
6.
Generate a local RSA or
ECDSA key pair.
public-key local create rsa
No local RSA or ECDSA key pair
exists by default.
7.
Submit a local certificate
request manually.
pki request-certificate domain
domain-name [ password ]
[ pkcs10 [ filename filename ] ]
N/A
Optional.
Manual by default.
Retrieving a certificate manually
You can download CA certificates or local certificate from the CA server and save them locally. To do so,
use either the offline mode or the online mode. In offline mode, you must retrieve a certificate by an
out-of-band means like FTP, disk, or email, and then import it into the local PKI system.
Certificate retrieval serves the following purposes:
•
Locally store the certificates associated with the local security domain for improved query efficiency
and reduced query count
•
Prepare for certificate verification
Configuration guidelines
•
Before retrieving a local certificate in online mode, be sure to complete LDAP server configuration.
•
If a PKI domain already has a CA certificate, you cannot retrieve another CA certificate for it. This
restriction helps avoid inconsistency between the certificate and registration information resulted
from configuration changes. To retrieve a new CA certificate, use the pki delete-certificate
command to delete the existing CA certificate and the local certificate first.
•
The pki retrieval-certificate configuration will not be saved in the configuration file.
•
Be sure that the device system time falls in the validity period of the certificate so that the certificate
is valid.
292
Configuration procedure
To retrieve a certificate manually:
Step
1.
Enter system view.
Command
Remarks
system-view
N/A
• In online mode:
2.
Retrieve a certificate
manually.
pki retrieval-certificate { ca | local } domain
domain-name
Use either command.
• In offline mode:
pki import-certificate { ca | local } domain
domain-name { der | p12 | pem } [ filename
filename ]
Verifying PKI certificate
A certificate needs to be verified before being used. Verifying a certificate will check that the certificate
is signed by the CA and that the certificate has neither expired nor been revoked.
You can specify whether CRL checking is required in certificate verification. If you enable CRL checking,
CRLs will be used in verification of a certificate. In this case, be sure to retrieve the CA certificate and
CRLs to the local device before the certificate verification. If you disable CRL checking, you only need to
retrieve the CA certificate.
Verifying certificates with CRL checking
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter PKI domain view.
pki domain domain-name
N/A
3.
Specify the URL of the CRL
distribution point.
crl url url-string
Optional.
No CRL distribution point URL is
specified by default.
Optional.
By default, the CRL update period
depends on the next update field in
the CRL file.
4.
Set the CRL update period.
crl update-period hours
5.
Enable CRL checking.
crl check enable
6.
Return to system view.
quit
N/A
7.
Retrieve the CA certificate.
See "Retrieving a certificate
manually"
N/A
Retrieve CRLs.
pki retrieval-crl domain
domain-name
Optional.
Enabled by default.
N/A
8.
293
The pki retrieval-crl domain
command cannot be saved in the
configuration file.
Step
9.
Verify the validity of a
certificate.
Command
Remarks
pki validate-certificate { ca | local }
domain domain-name
N/A
NOTE:
The CRL update period defines the interval at which the entity downloads CRLs from the CRL server. The
CRL update period setting manually configured on the device is prior to that carried in the CRLs.
Verifying certificates without CRL checking
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enter PKI domain view.
pki domain domain-name
N/A
3.
Disable CRL checking.
crl check disable
4.
Return to system view.
quit
N/A
5.
Retrieve the CA certificate.
See "Retrieving a certificate
manually"
N/A
6.
Verify the validity of the
certificate.
pki validate-certificate { ca | local }
domain domain-name
N/A
nabled by default.
Destroying a local RSA or ECDSA key pair
A certificate has a lifetime, which is determined by the CA. When the private key leaks or the certificate
is about to expire, you can destroy the old RSA or ECDSA key pair and then create a pair to request a
new certificate.
To destroy a local RSA key pair:
Step
Command
1.
Enter system view.
system-view
2.
Destroy a local RSA or ECDSA key
pair.
public-key local destroy { ecdsa | rsa }
Deleting a certificate
When a certificate requested manually is about to expire or you want to request a new certificate, you
can delete the current local certificate or CA certificate.
To delete a certificate:
294
Step
Command
1.
Enter system view.
system-view
2.
Delete certificates.
pki delete-certificate { ca | local } domain domain-name
Configuring an access control policy
By configuring a certificate attribute-based access control policy, you can further control access to the
server, providing additional security for the server.
To configure a certificate attribute-based access control policy:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Create a certificate attribute
group and enter its view.
pki certificate attribute-group
group-name
No certificate attribute group
exists by default.
3.
Configure an attribute rule for
the certificate issuer name,
certificate subject name, or
alternative subject name.
attribute id { alt-subject-name
{ fqdn | ip } | { issuer-name |
subject-name } { dn | fqdn | ip } }
{ ctn | equ | nctn | nequ }
attribute-value
Optional.
4.
Return to system view.
quit
N/A
5.
Create a certificate
attribute-based access control
policy and enter its view.
pki certificate access-control-policy
policy-name
No access control policy exists by
default.
6.
Configure a certificate
attribute-based access control
rule.
rule [ id ] { deny | permit }
group-name
No restriction exists on the issuer
name, certificate subject name
and alternative subject name by
default.
No access control rule exists by
default.
A certificate attribute group must
exist to be associated with a rule.
Displaying and maintaining PKI
Task
Command
Remarks
Display the contents or request
status of a certificate.
display pki certificate { { ca | local } domain
domain-name } [ | { begin | exclude |
include } regular-expression ]
Available in any view.
Display CRLs.
display pki crl domain domain-name [ |
{ begin | exclude | include }
regular-expression ]
Available in any view.
Display information about one
or all certificate attribute
groups.
display pki certificate attribute-group
{ group-name | all } [ | { begin | exclude |
include } regular-expression ]
Available in any view.
295
Task
Command
Remarks
Display information about one
or all certificate attribute-based
access control policies.
display pki certificate access-control-policy
{ policy-name | all } [ | { begin | exclude |
include } regular-expression ]
Available in any view.
PKI configuration examples
The SCEP add-on is required when you use the Windows Server as the CA. In this case, when you
configure the PKI domain, you need to use the certificate request from ra command to specify that the
entity requests a certificate from an RA.
The SCEP add-on is not required when RSA Keon is used. In this case, when you configure a PKI domain,
you need to use the certificate request from ca command to specify that the entity requests a certificate
from a CA.
Certificate request from an RSA Keon CA server
Network requirements
The device submits a local certificate request to the CA server.
The device acquires the CRLs for certificate verification.
Figure 98 Network diagram
Configuration procedure
1.
Configure the CA server:
# Create a CA server named myca.
In this example, you need to configure these basic attributes on the CA server at first:
{
{
Nickname—Name of the trusted CA.
Subject DN—DN information of the CA, including the Common Name (CN), Organization Unit
(OU), Organization (O), and Country (C).
The other attributes might be left using the default values.
# Configure extended attributes.
After configuring the basic attributes, you need to perform configuration on the jurisdiction
configuration page of the CA server. This includes selecting the proper extension profiles,
enabling the SCEP autovetting function, and adding the IP address list for SCEP autovetting.
# Configure the CRL distribution behavior.
After completing the configuration, you need to perform CRL related configurations. In this
example, select the local CRL distribution mode of HTTP and set the HTTP URL to
http://4.4.4.133:447/myca.crl.
296
After the configuration, make sure that the system clock of the device is synchronous to that of the
CA, so that the device can request certificates and retrieve CRLs properly.
2.
Configure the router:
a. Configure the entity DN:
# Configure the entity name as aaa and the common name as router.
<Router> system-view
[Router] pki entity aaa
[Router-pki-entity-aaa] common-name router
[Router-pki-entity-aaa] quit
b. Configure the PKI domain:
# Create PKI domain torsa and enter its view.
[Router] pki domain torsa
# Configure the name of the trusted CA as myca.
[Router-pki-domain-torsa] ca identifier myca
# Configure the URL of the registration server in the format of http://host:port/Issuing
Jurisdiction ID, where Issuing Jurisdiction ID is a hexadecimal string generated on the CA
server.
[Router-pki-domain-torsa] certificate request url
http://4.4.4.133:446/c95e970f632d27be5e8cbf80e971d9c4a9a93337
# Set the registration authority to CA.
[Router-pki-domain-torsa] certificate request from ca
# Specify the entity for certificate request as aaa.
[Router-pki-domain-torsa] certificate request entity aaa
# Configure the URL for the CRL distribution point.
[Router-pki-domain-torsa] crl url http://4.4.4.133:447/myca.crl
[Router-pki-domain-torsa] quit
c. Generate a local key pair using RSA:
[Router] public-key local create rsa
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Press CTRL+C to abort.
Input the bits in the modulus [default = 1024]:
Generating Keys...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++
d. Apply for certificates:
# Retrieve the CA certificate and save it locally.
[Router] pki retrieval-certificate ca domain torsa
Retrieving CA/RA certificates. Please wait a while......
The trusted CA's finger print is:
MD5
fingerprint:EDE9 0394 A273 B61A F1B3 0072 A0B1 F9AB
SHA1 fingerprint: 77F9 A077 2FB8 088C 550B A33C 2410 D354 23B2 73A8
297
Is the finger print correct?(Y/N):y
Saving CA/RA certificates chain, please wait a moment......
CA certificates retrieval success.
# Retrieve CRLs and save them locally.
[Router] pki retrieval-crl domain torsa
Connecting to server for retrieving CRL. Please wait a while.....
CRL retrieval success!
# Request a local certificate manually.
[Router] pki request-certificate domain torsa challenge-word
Certificate is being requested, please wait......
[Router]
Enrolling the local certificate,please