Configuring Gatekeeper Security

The options that are available for securing the gatekeeper-controlled H.323 network were discussed in Chapter 16. Proper planning and design up front of the desired security function simplifies the configuration.

To configure the gatekeeper to authenticate requests, it is first necessary to set up the authentication, authorization, and accounting feature (AAA) within Cisco IOS. AAA can use credentials that are configured in either a local database on the gatekeeper or an external RADIUS security server such as the Cisco Secure Access Control Server (ACS). AAA can also send accounting records to the RADIUS server to track events such as call duration, invalid login attempts, and so on.

The exact AAA configuration depends on several factors that are beyond the scope of this book. For guidance configuring AAA, please refer to Cisco.com.

When you are using authentication, it is important that you synchronize the time between the gatekeeper and all the gateways on the network. The Network Time Protocol (NTP) is the best way to accomplish this. To enable NTP, use the ntp server command in global configuration mode. The should be that of a known good NTP time source that is reachable on the network. More information on configuring NTP is available on Cisco.com.

The security token required-for all | registration command is used on the gatekeeper to authenticate gateways during registration or to do per-call authentication. If the registration option is selected, the gateway credentials are validated before the gateway can successfully register. If the all option is used, credentials are checked during registration and for each call that is presented to the gatekeeper.

On the gateway, the security password wordall | endpoint | per-call command is used in gateway configuration mode. If the endpoint option is selected, authentication occurs only during registration. The per-call option causes credentials to be sent on every call request. The all option enables both registration and per-call authentication. The word parameter sets the password to be used for the gateway.

You can use the tokenless call authentication feature for endpoints that do not support tokens, such as CallManager. To configure tokenless call authentication, you must create an access control list (ACL) on the gatekeeper. The ACL must include permit statements for the IP address of every device that is authorized to place call routing requests to the gatekeeper.

After you create the ACL, you enter the command security acl answerarq <1-99> in gatekeeper configuration mode. The <1-99> parameter refers to the ACL you just created. When this is complete, all ARQs that are received from gateways that have IP addresses permitted by the ACL are answered, whether or not they contain a security token.

It is important to note that tokenless call authentication applies to ARQs only and has no effect on gateway registration with the gatekeeper. Also, you can use token-based and tokenless call authentication at the same time. They are not mutually exclusive.

Example 17-23 shows the configuration that is necessary to enable gateway registration authentication. In this example, per-call authentication is not being done. The AAA feature is using locally configured user IDs and passwords rather than a RADIUS server.

Example 17-23. Enabling Gateway Registration Security

BOISE GATEWAY
boise#show running-config
Building configuration...
!
! Unnecessary output deleted
!
interface FastEthernet0/0
 ip address 10.1.5.200 255.255.255.0
 h323-gateway voip interface
 h323-gateway voip id boise multicast
 h323-gateway voip h323-id boise@cisco.com 
 h323-gateway voip tech-prefix 1#
 h323-gateway voip bind srcaddr 10.1.5.200
!
gateway 
 security password goodguy level endpoint 
!
end

GATEKEEPER A
GKA#show running-config
Building configuration...
!
! Unnecessary output deleted
!
username leeds@cisco.com password 0 goodguy
username boise@cisco.com password 0 goodguy 
username miami@cisco.com password 0 goodguy
!
aaa new-model
!
!
aaa authentication login default local
aaa authentication login h323 local 
aaa authorization exec default local
aaa authorization exec h323 local
!
gatekeeper 
 zone local boise cisco.com 10.1.5.1
 zone local miami cisco.com
 zone local leeds cisco.com
 zone prefix miami 21........
 security token required-for registration 
 gw-type-prefix 1#* default-technology
 rrq dynamic-prefixes-accept
 arq reject-unknown-prefix
 bandwidth interzone default 64
 no shutdown
!
!
ntp server 10.1.5.200 
!
end
 

If a RADIUS server such as Cisco Secure ACS had been used, the credentials would not have appeared in the Cisco IOS configuration. Also note that NTP has been configured and is being used to synchronize the gatekeeper clock.

CallManager does not support tokens for either registration or per-call security. If CallManager trunks are in use, you cannot enable registration security; otherwise, the CallManager trunk is unable to register. You can use per-call security with CallManager by using the tokenless call authentication feature.

Troubleshooting Gatekeeper Security

If registration or call routing problems occur due to security, you can use one of several tools to determine the problem. Some common causes of security issues include the following:

  • Clocks not synchronized If is the difference is too great between the time stamps on the request and the time in the gatekeeper, the request is rejected. Be sure that NTP is set up and working properly. You can use the show ntp status command to quickly verify NTP operation.
  • User ID mismatch The user ID that is used is the full H.323-ID. The user ID credentials must match.
  • No token being presented Some devices cannot use token authentication, as discussed previously.

Some of the tools that can assist in finding the cause of a problem include the debug h225 asn1, debug gatekeeper main 5, debug aaa authentication, and debug aaa attr trace commands. Example 17-24 shows how the debug h225 asn1 trace can assist with a gateway registration problem.

Example 17-24. Failed Gateway Registration debug h225 asn1 trace

May 17 14:23:23.717: RAS OUTGOING PDU ::=

value RasMessage ::= registrationRequest :
 {
 requestSeqNum 1150
 protocolIdentifier { 0 0 8 2250 0 4 }
 discoveryComplete TRUE
 callSignalAddress
 {
 ipAddress :
 {
 ip '0A0105C8'H
 port 1720
 }
 }
 rasAddress
 {
 ipAddress :
 {
 ip '0A0105C8'H
 port 56775
 }
 }
 terminalType
 {
 vendor
 {
 vendor
 {
 t35CountryCode 181
 t35Extension 0
 manufacturerCode 18
 }
 productId '436973636F47617465776179'H
 versionId '32'H
 }
 gateway
 {
 protocol
 {
 voice :
 {
 supportedPrefixes
 {

 {
 prefix dialedDigits : "1#"
 }
 }
 }, h323 :
 {
 supportedPrefixes
 {
 }
 }
 }
 }
 mc FALSE
 undefinedNode FALSE
 }
 terminalAlias
 {
 h323-ID : {"boise@cisco.com"} 
 }
 gatekeeperIdentifier {"boise"}
 endpointVendor
 {
 vendor
 {
 t35CountryCode 181
 t35Extension 0
 manufacturerCode 18
 }
 productId '436973636F47617465776179'H
 versionId '32'H
 }
 timeToLive 60
 keepAlive FALSE
 willSupplyUUIEs FALSE
 maintainConnection TRUE
 usageReportingCapability
 {
 nonStandardUsageTypes
 {

 {
 nonStandardIdentifier h221NonStandard :
 {
 t35CountryCode 181
 t35Extension 0
 manufacturerCode 18
 }
 data '40'H
 }
 }
 startTime NULL
 endTime NULL
 terminationCause NULL
 }
 }


May 17 14:23:23.865:
May 17 14:23:23.865: RAS INCOMING PDU ::=

value RasMessage ::= registrationReject :
 {
 requestSeqNum 1150
 protocolIdentifier { 0 0 8 2250 0 4 }
 rejectReason securityDenial : NULL 
 gatekeeperIdentifier {"boise"}
 }
 

You can see that the registration request from the Boise gateway was rejected because of securityDenial. In this case, no security information was included in the RRQ. This most likely indicates a configuration error in the gateway. Example 17-25 shows the successful registration process after the configuration was corrected.

Example 17-25. Successful Gateway Registration debug h225 asn1 trace

value RasMessage ::= registrationRequest :
 {
 requestSeqNum 1170
 protocolIdentifier { 0 0 8 2250 0 4 }
 discoveryComplete TRUE
 callSignalAddress
 {
 ipAddress :
 {
 ip '0A0105C8'H
 port 1720
 }
 }
 rasAddress
 {
 ipAddress :
 {
 ip '0A0105C8'H
 port 52091
 }
 }
 terminalType
 {
 vendor
 {
 vendor
 {
 t35CountryCode 181
 t35Extension 0
 manufacturerCode 18
 }
 productId '436973636F47617465776179'H
 versionId '32'H
 }
 gateway
 {
 protocol
 {
 voice :
 {
 supportedPrefixes
 {

 {
 prefix dialedDigits : "1#"
 }
 }
 }, h323 :
 {
 supportedPrefixes
 {
 }
 }
 }
 }
 mc FALSE
 undefinedNode FALSE
 }
 terminalAlias
 {
 h323-ID : {"boise@cisco.com"} 
 }
 gatekeeperIdentifier {"boise"}
 endpointVendor
 {
 vendor
 {
 t35CountryCode 181
 t35Extension 0
 manufacturerCode 18
 }
 productId '436973636F47617465776179'H
 versionId '32'H
 }
 timeToLive 60
 tokens 
 { 

 { 
 tokenOID { 1 2 840 113548 10 1 2 1 } 
 timeStamp 1147876446 
 challenge 'F64FAD4A17AFE3C1D0D51ADF38071BA8'H 
 random 164 
 generalID {"boise@cisco.com"} 
 } 
 } 
 cryptoTokens 
 { 
 cryptoEPPwdHash : 
 { 
 alias h323-ID : {"boise@cisco.com"} 
 timeStamp 1147876446 
 token 
 { 
 algorithmOID { 1 2 840 113549 2 5 } 
 paramS 
 { 
 } 
 hash "6D01394D6E13493CB7338E16EADDB9F" 
 } 
 } 
 }
 keepAlive FALSE
 willSupplyUUIEs FALSE
 maintainConnection TRUE
 usageReportingCapability
 {
 nonStandardUsageTypes
 {

 {
 nonStandardIdentifier h221NonStandard :
 {
 t35CountryCode 181
 t35Extension 0
 manufacturerCode 18
 }
 data '40'H
 }
 }
 startTime NULL
 endTime NULL
 terminationCause NULL
 }
 }
May 17 14:34:07.073: RAS INCOMING PDU ::=

value RasMessage ::= registrationConfirm : 
 {
 requestSeqNum 1170
 protocolIdentifier { 0 0 8 2250 0 4 }
 callSignalAddress
 {
 }
 terminalAlias
 {
 h323-ID : {"boise@cisco.com"} 
 }
 gatekeeperIdentifier {"boise"}
 endpointIdentifier {"840F50B400000003"}
 alternateGatekeeper
 {
 }
 timeToLive 60
 willRespondToIRR FALSE
 maintainConnection TRUE
 supportsAdditiveRegistration NULL
 usageSpec
 {

 {
 when
 {
 end NULL
 inIrr NULL
 }
 callStartingPoint
 {
 connect NULL
 }
 required
 {
 nonStandardUsageTypes
 {
 }
 startTime NULL
 endTime NULL
 terminationCause NULL
 }
 }
 }
 }
 

In this example, you can see that both the Cisco Access Token (CAT) and H.235 cryptoToken are included in the RRQ. The Cisco gatekeeper only processes the CAT; it ignores the cryptoToken. The cryptoToken is included for compatibility with third-party gatekeepers. You can also see the H.323 ID and timestamp in the trace output.

Part I: Voice Gateways and Gatekeepers

Gateways and Gatekeepers

Part II: Gateways

Media Gateway Control Protocol

H.323

Session Initiation Protocol

Circuit Options

Connecting to the PSTN

Connecting to PBXs

Connecting to an IP WAN

Dial Plans

Digit Manipulation

Influencing Path Selection

Configuring Class of Restrictions

SRST and MGCP Gateway Fallback

DSP Resources

Using Tcl Scripts and VoiceXML

Part III: Gatekeepers

Deploying Gatekeepers

Gatekeeper Configuration

Part IV: IP-to-IP Gateways

Cisco Multiservice IP-to-IP Gateway

Appendix A. Answers to Chapter-Ending Review Questions

Index



Cisco Voice Gateways and Gatekeepers
Cisco Voice Gateways and Gatekeepers
ISBN: 158705258X
EAN: 2147483647
Year: 2004
Pages: 218

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net