Chapter 6. Registration on Cisco Expressway

This chapter covers the following topics:

Images Registration Conflict Policy: This topic will explain how to use the Conflict Policy on the Cisco Expressway to control H.323 endpoint registration.

Images Registration Restriction Policy: This topic will explain how to use the Restriction Policy on the Cisco Expressway to control which endpoints are allowed or denied registration for both H.323 and SIP.

Images Registration Authentication: This topic will explain how to control registration to the Cisco Expressway using MD5 encryption and authentication.

Images Subzones and Membership Rules: This topic will recapitulate all the policies mentioned throughout this chapter by reviewing the registration process, examining how each of these policies fit into the bigger registration picture, and concluding with an explanation of the subzones and membership rules.

Before calls can be made, endpoints must first register to the call control server. When it comes to registration to the Cisco Expressway, there are many differences from registration to the CUCM. Out of the box there is very little that must be configured before endpoints will be able to register with either SIP or H.323. However, there are several policies that exist on the Expressway that allows an administrator to control which endpoints are allowed to register. This extra layer of security can affect many other aspects within the expressway environment.

Although this chapter does not cover any objectives from the Implementing Cisco Collaboration Cloud and Edge Solutions (CLCEI) exam 300-820, it does establish a foundation for other topics you will be required to know for the exam.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 6-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”

Table 6-1 ”Do I Know This Already?” Section-to-Question Mapping

Images

Caution

The goal of self-assessment is to gauge your mastery of the topics in this chapter. If you do not know the answer to a question or are only partially sure of the answer, you should mark that question as wrong for purposes of the self-assessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.


1. Which of the following settings can affect how long an H.323 registration will remain in the database of the Expressway?

a. Call Time to Live

b. Registration Time to Live

c. Time to Live

d. Registration Conflict Policy

2. What setting does Cisco recommend configuring the Registration Conflict Policy to when endpoints are configured with Static IP Addresses?

a. Overwrite

b. Reject

c. Allow

d. Deny

3. Deny List has been enabled on the Expressway, and an Allow List rule is created using Regex for 55/d/d.* Which of the following statements is true when an endpoint tries to register with the alias?

a. The registration will fail because the Allow List rule requires 55 to precede any alias registering.

b. The registration will fail because the Deny List has been enabled.

c. The registration will succeed because the Allow List ends in .* which allows anything to register.

d. The registration will succeed because deny list is enabled but there is not a rule in the deny list to prevent registration.

4. When enabling the Registration Restriction Policy on the Expressway, what options exist?

a. Allow List, Deny List or Both

b. Allow List or Deny List only

c. Allow List, Deny List or Policy Service

d. Allow List, Deny List, External Policy Service or Internal Policy Service

5. What protocol is used for Authentication over SIP endpoints?

a. Digest

b. MD5

c. H.235

d. NTP

6. Which of the following statements is true regarding configuring Registration Authentication on the Expressway?

a. Authentication can be enabled universally across the Expressway or based on individual subzones.

b. Authentication requires signed certificates to secure communications between the endpoint and the Expressway.

c. The Expressway can use the Local Database and an LDAP server for authentication credentials at the same time.

d. The Expressway can use the Local Database or an LDAP server for Authentication credentials, but only one can be enabled at a time.

7. Which of the following logical components that make up the Cisco Expressway can be used to connect a call to an endpoint not registered to the Expressway?

a. Local Zone

b. Default Subzone

c. Traversal Subzone

d. Default Zone

e. Link

f. Subzone

8. What number does the binary value 11000000 represent?

a. 192

b. 128

c. 224

d. 144

Foundation Topics

Registration Conflict Policy

One of the security features that exists on the Cisco Expressway is the registration conflict policy. This policy does not ever need to be enabled because it is always operational in one of two modes: “Reject” or “Overwrite”. However, the registration conflict policy is only operational within the H.323 standard for communication. The reason this policy exists is because duplicate aliases cannot exist within the H.323 standard. This behavior can be contrasted with SIP, which does support the use of duplicate aliases. A SIP server will route a call request out to every device that is registered with an alias that matches the dialed alias. The H.323 gatekeeper will only route a call request out to a single alias match, therefore if duplicate aliases attempted to register from different endpoints, an error message would occur, and the call attempt would fail.

Since the registration conflict policy does not need to be enabled, the administrator only needs to configure it to enact the desired behavior. If the conflict policy is configured to Reject, which is the default setting, any device that tries to register to the Expressway with an H.323 alias that conflicts with another device already registered with the same alias information will be rejected. For example, if endpoint 1 has an IP address of 192.168.1.101 and is registered to the Expressway with the H.323 E.164 alias 6501 and endpoint 2 with the IP address of 192.168.1.102 tries to register with the H.323 E.164 alias 6501, the Expressway will send a RRJ to endpoint 2 rejecting the registration attempt. The error message that would be logged in the Cisco Expressway would be Expressway: Event=“Registration Rejected” Reason=“duplicate alias”.

If an organization wants to use H.323, then Cisco recommends that the endpoints be configured with static IP addresses and the conflict policy be left at the default value of Reject. The reason for this recommendation is because H.323 registrations do not drop out of the gatekeeper registration database immediately after the endpoint loses connection to the gatekeeper. There is a setting within the Expressway called Time to Live that determines how long an H.323 registration will remain in the database before the endpoint is required to renew the registration. The default value for this setting is 1800 seconds, or 30 minutes, and it can be changed to as little as 60 seconds or as much as 65534 seconds. Assume for a moment that DHCP is used for endpoint addressing instead of statically assigned IP addresses. Endpoint 1 has been assigned a DHCP address of 192.168.1.101 and registers to the Cisco Expressway with an H.323 E.164 alias of 6501. After a reboot of the endpoint the DHCP assigns a new IP address of 192.168.1.103 and the endpoint tries to register again to the Expressway with the H.323 E.164 alias of 6501. This time the Expressway sends a RRJ to the endpoint because there is already a registration entry with a different IP address using the same alias, and the Time-to-Live counter has not yet expired. Therein lies the problem that can be easily resolved with statically assigning IP addresses to the endpoints. However, if the enterprise environment requires DHCP addresses to be used on the endpoints, there is another setting that can be used with the conflict policy.

If registration conflict policy is configured as Overwrite, then any device that tries to register to the Expressway with an alias that already exists within the registration database, the entry that is registered will be unregistered and the device trying to register will receive a RCF from the Expressway confirming the registration request. Using the same analogy that was previously described, the address record of 6501 associated to IP address 192.168.1.101 would be unregistered and the new RRQ for the alias 6501 associated with IP address 192.168.1.103 would be allowed to register. With that said, the limitation of configuring the Expressway with the registration conflict policy set to Overwrite should be obvious. Should a different endpoint try to register via H.323 with the same E.164 alias as an endpoint already registered to the same Expressway while the conflict policy is set to overwrite, the endpoint currently registered will be unregistered. After unregistering from the Expressway, that endpoint would immediately attempt to register again, cause the second endpoint to unregister. This cycle would continue causing potentially serious call routing issues. There is not any mechanism built within the Cisco Expressway to contend with this issue. For this reason, Cisco recommend that H.323 endpoints registering to the Expressway use static IP addresses and the registration conflict policy be left at the default value of Reject. Keep in mind that this setting is an H.323 setting and has no bearing on SIP registrations. Additionally, multiple SIP endpoints can register with the same alias on an Expressway without any routing issues.

Images

To set the registration conflict policy, follow these steps:

Step 1. From the web interface of the Cisco Expressway, navigate to Configuration > Protocols > H.323.

Step 2. In the Registration conflict mode field, choose a value from the drop-down list (Overwrite or Reject).

Step 3. Click Save.

Images

Figure 6-1 Registration Conflict Policy on the Cisco Expressway

Registration Restriction Policy

Chapter 3 discusses SIP and H.323 settings on the Cisco Expressway for registration. During that chapter it was mentioned that SIP needs to be enabled, and at least one domain must be established within the database before SIP endpoints can register to the Expressway. No settings have to be configured for H.323 endpoints to register to the Expressway. The only security policy that exists preconfigured out of the box on the Expressway that effects how endpoints register is the registration conflict policy, and that only impacts H.323 endpoint registration. I mention all this to emphasis that there is no security enabled on the Expressway that will limit or control endpoint registration out of the box. Any endpoint that is pointed to the Expressway for registration will be allowed to register without restriction. Any limitations you wish to enforce will have to be manually and purposefully enabled and configured by the Expressway administrator. The good news is that there are two very good policies that can be configured to control registration, and they both affect SIP and H.323 equally and without bias.

The first of these policies is called the registration restriction policy. This policy service controls which endpoints are allowed to register to the Expressway, and it can be configured to use an Allow List or a Deny List. There are two settings that must be configured when configuring the registration restriction policy. You must first enable the service by selecting Allow List or Deny List from the Configuration dropdown menu. Note that the only way to enable this policy is to choose the list type you want to use, allow or deny, therefore both the Deny List and Allow List cannot be enabled simultaneously. The administrator must choose one or the other. Once enabled the administrator must then configure the policies themselves to determine what endpoints will be allowed or denied registration based on their alias. If the Expressway is configured to use Allow List, but no allow list policies are configured, all endpoints will be forbidden to register to the Expressway, because no alias pattern is “allowed” to register. In like manner, if the Expressway is configured to use Deny List and no deny list policies are configured, all endpoints attempting to register to the Expressway will be allowed, because no alias pattern is “denied” from registration.

Images

To enable the registration restriction policy, follow these steps:

Step 1. From the web interface of the Expressway, navigate to Configuration > Registration > Configuration.

Step 2. In the Restriction policy field, choose a value from the drop-down list. The options include:

a. Allow List

b. Deny List

c. Policy service

Step 3. Click Save.

Step 4. Assuming either Allow List or Deny List has been selected, next you’ll need to navigate to either Configuration > Registration > Allow List or Configuration > Registration Deny List depending on which policy is being used.

Step 5. Click New.

Step 6. In the Pattern type field, enter the type of pattern you are allowing or denying.

Step 7. In the Pattern string field, enter the characters and wildcards you are using as the criteria to allow or deny.

Step 8. Click Add Allow List pattern or Add Deny List pattern.

There are four pattern types that can be used when configuring Registration Restriction policies, Exact Match, Prefix, Suffix, and Regular Expressions. Exact match refers to the entire alias and no part can be left out. Prefix and suffix have no limit on the length of characters they can represent. However, they can only represent a part of the alias, not the whole thing. Let’s say we were matching the alias [email protected] using the previously mentioned methods. Obviously, the entire alias would have to be used for an exact match to work. Using just 6501 or just cisco.com would not be adequate for an exact match. If prefix were used, then you could get away with just 6501. In fact, you could use any alias pattern from 6 to [email protected] leaving the “m” off the end. So long as the complete alias is not included in the match, any part of it can be used. Likewise, suffix can be used in the same manner. Anything from m 9the last character) to [email protected] (everything except the first character) can be used. Chapter 4 covered how to use Regular Expressions. This is the first place in the Expressway these expressions can be used. The nice part about using regular expressions in registration restriction policies is that they can be used to represent the middle part of an alias pattern. Using the same alias example previously described, a regular expression such as 650[^0]@cisco.com could be used to match alias patterns bases on the fourth number of the first numeric part of the alias. Basically, this pattern will match all aliases starting at [email protected] through [email protected], but will not match [email protected]. Figure 6-2 illustrates the menus used to enable an Allow List on the Expressway and configure patterns for that allow list.

Images

Figure 6-2 Registration Restriction Policy Allow List on the Cisco Expressway

The same method can be used to create deny policies within the Expressway. However, an alternative method to add devices to the Deny List also exists whereby endpoints already registered to the Expressway can be unregistered and blocked from registering again. From the Web interface of the Expressway, navigate to Status > Registration > By Device, check the box beside registered devices you want to add to the Deny list, and then click the Unregister and Block button at the bottom of the screen. This process will unregister the device from the Expressway and add their entire alias information to the Deny list so they cannot register to the Expressway again. Bear in mind that this option only exists if the deny list has been enabled. If not, then the only option available from the Registration > By Device menu would be to Unregister an endpoint without the “block” option.

When enabling the registration restriction policy from the Configuration > Registration > Configuration menu there is a third option apart from Allow List or Deny List that is rarely discussed. This option is called Policy service. The Policy service option is used if you want to refer all registration restriction policy decisions out to an external service. If you select this option and extra set of configuration fields appear so that you can specify the connection details of the external service.

The Expressway has built in support for Registration Policy and Call Policy configuration. Call Policy will be discussed more in chapter 7. It also supports CPL (Call Processing Language) for implementing more complex policy decisions. CPL is designed as a machine-generated language and is not immediately intuitive; while the Expressway can be loaded with CPL to implement advanced call policy decisions, complex CPL is difficult to write and maintain. The Expressway’s external policy feature allows policy decisions to be taken by an external system which can then instruct the Expressway on the course of action to take, such as whether to accept a registration, fork a call and so on. The external policy server can make routing decisions based on data available from any source that the policy server has access to, allowing companies to make routing decisions based on their specific requirements. When the Expressway is configured to use an external policy server the Expressway sends the external policy server a service request (over HTTP or HTTPS), the service will send a response back containing a CPL snippet which the Expressway will then execute.

To configure Registration Policy to refer all registration restriction policy decisions out to an external service use the following steps:

Step 1. From the web interface of the Expressway navigate to Configuration > Registration > Configuration.

Step 2. Select a Restriction policy of Policy service.

Step 3. Configure the fields identified in Table 6-2:

Images

Table 6-2 External Policy Service Configuration Information for Registration Restriction Policy

Images

Step 4. Click Save.

The Expressway should connect to the policy service server and start using the service for Registration Policy decisions. Any connection problems will be reported on this page. Check the Status area at the bottom of the page and check for additional information messages against the Server address fields. As mentioned before, registration restriction policy operates for both SIP and H.323. You can also control registrations at the subzone level. Each subzone can be configured to allow or deny registrations assigned to it via the subzone membership rules. This means, for example, that you can deny the registration of endpoints with specific IP addresses or subnet ranges by setting up membership rules for those addresses/ranges and setting the target subzone to deny those registration requests. Subzones and Membership Rules will be covered more in the last section of this chapter. The error message the Expressway will report for all devices that are blocked by this restriction policy service will state Expressway: Event=“Registration Rejected” Reason=“not permitted by policy”.

Registration Authentication

The other form of security that has the ability to control which endpoints can register to the Expressway is called registration authentication. Registration authentication should not be confused with administrator authentication or user authentication. Although they operate in a similar manner, administrator and user authentication are a different service of the Expressway and as such are configured from different menus within the Expressway web interface.

When Authentication is enabled, it affects all devices no matter if they’re registered H.323 or SIP. However, each of these communication protocols uses different encryption standards for authentication. SIP uses an encryption process that is known as Digest, and H.323 uses an encryption standard that is known as H.235. Both H.235 and digest use a system that is called MD5 or Message Digest Algorithm 5, which is a messaging system that uses a time stamp from a time server as part of its encryption key. Therefore, no matter if you are using H.323 or SIP with authentication, it is critical that both the Expressway and the device registering to it are pointed to the same NTP (Network Time Protocol) server or synced cluster.

Images

Authentication policy is applied by the Expressway at the zone and subzone levels. I will discuss more about how authentication is used at the zone level in chapter 9. Authentication controls how the Expressway challenges incoming messages for provisioning, registration, phone books, and calls from the subsequent zone or subzone and whether those messages are rejected, treated as authenticated, or treated as unauthenticated within the Expressway. The primary authentication policy configuration options and their associated behavior are as follows:

Images Check credentials: verify the credentials using the relevant authentication method. Note that in some scenarios, messages are not challenged.

Images Do not check credentials: do not verify the credentials and allow the message to be processed.

Images Treat as authenticated: do not verify the credentials and allow the message to be processed as if having been authenticated.

This might be a little confusing to some readers as to why enabling authentication is not as simple as toggling a switch on or off. There are numerous types of endpoints from many different vendors, and many different scenarios by which authentication may or may not be used. A company may need to cater to endpoints from third-party suppliers that do not support authentication within their registration mechanism. Some companies may want to use authentication for endpoint registration in more secure areas, and not use authentication in less secure areas. Additionally, there are certain features within the Expressway that cannot operate unless packets are marked as authenticated. Whatever the reason authentication may or may not be used is only the justification as to why this policy service exists within the Expressway. With all that said, an explanation of how these three settings operate can be rationalized through a simple analogy.

Imagine walking into a club. The bouncer at the entrance to the club checks your ID to verify you are over the drinking age limit then stamps your hand. When you walk up to the bar the bartender simply needs to see your stamp and can now serve you an alcoholic beverage. This is the same as Check Credentials. Once the bouncer verified your identity and age, the stamp was all you needed to fully utilize the services within the club.

Now imagine walking up to that same club. This time there is no bouncer at the door, so you just walk in. This time when you go up to the bar, the bar tender cannot server you any alcoholic drinks because you don’t have the stamp. You can go into the club; you just can’t drink. This is the same as Do Not Check Credentials. Endpoints can register to the Expressway with this type of encryption, but there are some services they just can’t use.

In a third scenario you walk up to the same club as before. The bouncer is not there this time either, but the stamp and ink pad are sitting on his chair at the entrance. So, you stamp your own hand and go into the club. No one actually check your credentials. But you can now order drinks at the bar because you have the stamp. This is the same as Treat as Authenticated. Messages sent through the Expressway will be marked as authenticated, even though they never actually had their credentials checked. However, since these endpoints have the authenticated stamp, they can utilize all the services available through the Expressway.

The first step to setting up registration authentication is to enable the authentication policy at the subzone level. All subzones support authentication. Since I have not yet discussed subzones on the Expressway yet, I will use the default subzone to illustrate how authentication can be enabled. From the web interface of the Expressway, navigate to Configuration > Local Zone > Default Subzone. In the first section at the top of the screen called Policy, change the Authentication policy to Check credentials. Scroll to the bottom of the page and click Save. Registration authentication has now been enabled. The next step is to configure the authentication credential in the database.

The database type used to verify credentials for registration authentication can be local or remote through Microsoft AD or an OpenLDAP server. The default is to use the Local database located on the Expressway itself. If Local database is the database type being used, the administrator needs to go into the Local database and create a username and password. Multiple credentials can be created, and SIP and H.323 can use the same set of credentials. They are not protocol specific. However, both the username and password are case-sensitive, so pay attention to syntax when creating the credentials. All letters, numbers, and special characters can be used. To configure the local database, navigate to Configuration > Authentication > Devices > Local database. You should see a list of usernames with the source that created the credentials. They can be created locally on the Expressway itself, or through TMS. Click New to create a new set of credentials, enter the Name and Password you want to use and click Create credentials. This creates the authentication credentials that endpoints must use to register to the Expressway.

You can configure the Expressway to use both the local database and an H.350 directory.

If an H.350 directory is configured, the Expressway will always attempt to verify any Digest credentials presented to it by first checking against the local database before checking against the H.350 directory. If an LDAP database is used, then the LDAP configuration settings need to be configured and appropriate schemas will need to be downloaded and configured on the LDAP server itself. If you navigate to Configuration > Authentication > Devices in the Expressway you will see three additional menu options to the Local database.

Images Active Directory Service should be enabled and configured to communicate with a Microsoft Active Directory Service.

Images H.350 directory service should be enabled and configured to communicate with an OpenLDAP Directory Service.

Images H.350 directory schemas. Regardless which LDAP service you choose to use, there are schemas that will need to be downloaded so that the LDAP service can be configured for use in this capacity.

Each LDAP service type has four schema files that can be downloaded. Table 6-3 identifies these four types of schemas along with the ITU specification for these schemas and their descriptions.

Images

Table 6-3 LDAP Schemas for Registration Authentication on Cisco Expressway

Images

After the schemas have been downloaded from the Expressway, they will need to be installed on the LDAP Directory server of your choosing. To install the schemas on a Microsoft Active Directory, open an elevated command prompt from the on-screen display of the Microsoft Windows Server hosting this service. This can be done by right-clicking Command Prompt and selecting Run as administrator. Enter the following command in the command prompt:

Ldifde -i -c DC=X <ldap_base> -f filename.ldf

where <ldap_base> is the base DN for your Active Directory server

Once the schemas have been installed on the ASD server, you will need to create an organizational hierarchy by adding H.350 objects. First, use the following steps to create an organizational hierarchy.

Step 1. Open up the Active Directory Users and Computers MMC snap-in.

Step 2. Under your BaseDN right-click and select New Organizational Unit.

Step 3. Create an Organizational unit called h350.

It is good practice to keep the H.350 directory in its own organizational unit to separate out H.350 objects from other types of objects. This allows access controls to be setup which will only allow the Expressway read access to the BaseDN and therefore limit access to other sections of the directory. Next you will need to Add the H.350 objects.

Step 4. Create an ldif file with the following contents:

# MeetingRoom1 endpoint dn: commUniqueId=comm1,ou=h350,DC=X

objectClass: commObject

objectClass: h323Identity

objectClass: h235Identity

objectClass: SIPIdentity

commUniqueId: comm1

h323Identityh323-ID: MeetingRoom1

h323IdentitydialedDigits: 626262

h235IdentityEndpointID: meetingroom1

h235IdentityPassword: mypassword

SIPIdentityUserName: meetingroom1

SIPIdentityPassword: mypassword

SIPIdentitySIPURI: sip:MeetingRoom@X

Step 5. Add the ldif file to the server using the command:

ldifde -i -c DC=X <ldap_base> -f filename.ldf

where: <ldap_base> is the base DN of your Active Directory Server.

This example will add a single endpoint with an H.323 ID alias of MeetingRoom1, an E.164 alias of 626262 and a SIP URI of MeetingRoom@X. The entry also has H.235 and SIP credentials of ID meetingroom1 and password mypassword which are used during authentication. H.323 registrations will look for the H.323 and H.235 attributes; SIP will look for the SIP attributes. Therefore, if your endpoint is registering with just one protocol you do not need to include elements relating to the other. Take special note that the SIP URI in the ldif file must be prefixed by sip:. As you can see, the process for using registration authentication through LDAP directory services is quite complex. For this reason, most people will only use the Local database for registration authentication. Installing schemas for OpenLDAP is even more complicated and less commonly used. Therefore, I will not be covering this procedure in the book. Refer to the “Cisco Expressway Administration Guide” for information on how to install and configure schemas using OpenLDAP.

The last task in configuring the Expressway for registration authentication is to ensure the NTP settings have been configured and that there is at least one active server. This setting can be verified under the System > Time menu from the Expressway web interface. Up to five different NTP servers can be specified and the synchronization status for each NTP server is shown on the same page. Once this process is accomplished, the Expressway will send a “get time” message to the NTP Server, and receive from the NTP server a “sent time” message. This time stamp will be used for each authentication sequence. Figure 6-3 illustrates the configuration settings that must be configured on the Expressway to use registration authentication.

Images

Figure 6-3 Registration Authentication Settings on the Cisco Expressway

Once the Expressway has been configured for authentication, the registering devices will need to be configured for authentication as well. It is necessary to turn on authentication for H.323 but not for SIP. Digest is built into the SIP protocol as an automatic feature that’s used when required and therefore does not need to be enabled. With H.323, it is a separate standard completely and must be enabled to operate. Configure the same username and password that exists in the local database of the Expressway, or on the LDAP server if LDAP is being used instead. Finally, do not forget to configure NTP on the endpoint. The timestamp the endpoint receives from the NTP server must match exactly to the timestamp received by the Expressway, or else registration will fail. Therefore, the same NTP server should be used on both the endpoint and the Expressway. All other settings required on the endpoint for registration must still be configured. Once the endpoint is configured and ready for registration it will attempt to communicate immediately with the Expressway.

After all the configuration settings are correct on the endpoint, it will initiate a handshake with the Expressway to perform a key exchange so that data shared between the endpoint and the Expressway can be securely encrypted and decrypted. Once the encryption is established, the device must first send authentication credentials to the Expressway for authentication. The Expressway will then perform an authentication challenge in order to verify if the username and password are valid. The Expressway will first verify the information against the Local database. If the credentials are determined invalid and remote authentication is enabled through an LDAP server, the Expressway will send an H.350 request out to that server to verify the credentials. If the credentials are still not valid, then the Expressway will return an Authentication Failure message back to the endpoint and registration will fail. If the credentials do check out then the Expressway will send an Authentication OK message and the registration process can continue. This part of the process is the same for both H.323 and SIP. After this point they follow a slightly different process for registration. I will begin by explaining the H.323 registration process.

Images

In H.323, the endpoint sends an RRQ (Registration Request) to the Expressway. The Expressway will respond with a RIP (Request in Progress) message because before it can allow any device to register it must check the other security policies in place. Those policies, as have already been discussed, are Registration Conflict policy, which can be set to Reject or Overwrite, and Registration Restriction policy, which can be set to Allow List or Deny List. Finally, the Expressway will check Membership Rules, which I will discuss in the next section. Provided everything to this point has passed, the Expressway will respond with an RCF (Registration Confirm) and the endpoint is registered. If there were any issue with these policies, the Expressway would send an RRJ (Registration Reject) and registration would fail.

Images

With a SIP endpoint, while the messaging is slightly different, the process within the Expressway is very similar. The endpoint sends a “Register” message, along with its IP address and the SIP URI that has been configured on the endpoint. The Expressway will check the Registration Restriction policy for an allow or deny list, and it will verify that the domain in the URI matches the domain that is configured in the Domains section of the Expressway. Like with the H.323 endpoint, the Expressway will also check the Membership Rules. Provided all this passes the test, the Expressway will send a SIP 200OK message and the endpoint will be registered. If any of this fails, then the Expressway will send a 40x error code and registration will fail. Figure 6-4 illustrates the registration process with all the registration security components mentioned throughout this chapter.

Images

Figure 6-4 Registration Process on the Cisco Expressway with Security Components

Subzones and Membership Rules

Examining the registration process previously described, the last component that is verified before an endpoint is allowed to register is the Membership Rules. In order to best understand what Membership Rules are and how they work, you first need to understand the basic logical components that make up the Expressway. The Cisco Expressway can be divided into five logical components, which can be categorized by two main classes; Subzones and Zones. Subzones and Zones exist within the Expressway for different purposes. Since they are not used for the same purpose, it becomes critical that they are not confused with one another.

The Local Zone is the first logical component I will define for you, because it is representative of the Expressway itself. The Expressway is the Local Zone, and the Local Zone is the Expressway. All other logical components that make up the Expressway are defined in how they relate back to the Local Zone. Out of the box, the Local Zone contains by default one Default Zone, one Default Subzone, and one Traversal Subzone. Additional Subzones and additional Zones can be created withing the Local Zone, but I will talk about those more later. First, I need to define the default components that come pre-configured on the Expressway.

The Default Subzone is a logical group within the Local Zone where all endpoints register to by default. This Subzone does not discriminant based on protocol. Both H.323 and SIP endpoints can register here so long as the Expressway has been configured to support that type of registration. This may be the only Subzone needed so long as you have uniform bandwidth and authentication requirements available between all your devices within the organization. If different bandwidth provisions or security authentication requirements are needed for different endpoints within your organization, you should create a new Subzone for each pool of devices. More on that momentarily.

The Traversal Subzone is another logical component of the Expressway. This Subzone is different from all other Subzones, because it is only used to manage and throttle bandwidth for any Traversal calls through the Expressway. Devices registering to the Expressway will never register to the Traversal Subzone. There are four types of traversal calls on the Cisco Expressway, all of which must navigate through the Traversal Subzone. They are, Interworking, IPv4 to IPv6 traversal, Firewall traversal, and Dual Network Interface traversal, which is only available on the Expressway Edge servers.

The Default Zone is the default logical connection into and out of the Local Zone. If Subzones were the interior doors of a building that separates different rooms, then Zones would be the exterior doors that allow people to enter and exit the building itself. Based on this analogy, the Default Zone would be the front door to the Expressway. Devices can only register to the Default Subzone. The Default Zone and Traversal Subzone do not accept any device registration. None of these logical components; the Default Subzone, Default Zone and Traversal Subzone, can be deleted from the Expressway. However, additional Subzones and Zones can be created and deleted.

Different types of Zones can be created on the Expressway for various network routing requirements. Neighbor Zones are used to connect to other parts of the same network. This could be within the same LAN or across the WAN. Traversal Zones are for routing into and out of a network through a firewall. Common applications of this usage include Business-to-Business (B2B) communication. DNS zones are used when DNS plays a role in call routing. This zone could be on an internal or external network. I will discuss Zones more in Chapters 9 and 10.

The fifth and last default logical component that needs mentioned here is the humble Link. A Link is a logical connection between two Subzones or between a Subzone and a Zone. Bases on the building analogy previously described, Links would be the corridors between rooms within the building. Without links, access to these different rooms would not be possible. Consider a scenario where a SIP endpoint and an H.323 endpoint were both registered to the Default Subzone. If Links did not exist, then these two endpoints could not call each other, even though they are registered to the same Subzone. That traversal call must be able to navigate through the Traversal Subzone in order to connect, which is rendered impossible without Links. Out of the box, the Expressway comes with a link preconfigured between the Default Subzone and Traversal Subzone, the Default Subzone and the Default Zone, and between the Default Zone and the Traversal Subzone. Unlike these other default logical components, the default Links can be deleted and created again. In fact, there is a command that can be entered from the CLI of the Cisco Expressway that will create these default Links for you. That command is xCommand DefaultLinksAdd. If other Subzones and Zones are created, Links can be deleted and created for connecting to those logical components as well. Figure 6-5 illustrates the logical components that make up the Cisco Expressway, along with additional Subzones that can also be created for registration.

Images

Figure 6-5 Logical Components that makeup the Cisco Expressway

Continuing to build on the logical components that have already been defined, additional Subzones can be created within the Local Zone. Subzones are logical groupings of registered devices, such as endpoints, conference bridges, gateway and so on, for the purposes of bandwidth management and access control. As seen in the previous section, Subzones allow authentication requirements to be set for endpoints attempting to register. By creating multiple Subzones, you can create an environment where some endpoints are required to present credentials before being allowed to register, while other endpoints may not be required to authenticate due to the setting on their respective Subzone. Subzones also determine the bandwidth restrictions to be applied on calls between endpoints, whether calls are established between endpoints within the same Subzone or several different Subzones. When a new Subzone is created, two Links are also created automatically at the same time. One of those links connects the new Subzone to the Default Subzone, and the other Link connects the new Subzone to the Traversal Subzone. Like all other Links within the Expressway, these links can be deleted, and other links can be created.

Images

To create a Subzone on the Cisco Expressway, use the following steps.

Step 1. From the web interface of the Cisco Expressway, navigate to Configuration > Local Zone > Subzones. An easy what to remember this is that a Subzone is a logical component of the Local Zone.

Step 2. Click New and configure the following parameters:

a. Name: I like to use a name like Accounting_SZ or Raleigh_SZ, depending on if I am identifying a department or physical location.

b. Authentication policy: Do not check credentials, Treat as authenticated or Check credentials

Step 3. Click the Create subzone button at the bottom of the page.

I have already established that by default, all devices will register to the Default Subzone. When additional Subzones are created, Membership Rules must also be created to determine where a device will register. Membership rules can be created using either a subnet mask or alias pattern match. An alias pattern match can be configured as an exact match, prefix, suffix, or a regular expression.

In order to use the Subnet function of Membership Rules you do not have to be a master at subnetting. There is a calculator built into the Expressway that will identify the subnet ranges you are entering based on an IP address you enter and the cyber mask you associate with it. In order to understand these concepts, however, a basic understanding of subnetting is required. The purpose of this book is not to teach you networking principles; however, I will cover some basics to subnetting at this time. An IPv4 address is a 32-bit address divided up into four octets of 8 bits. Each bit in these addresses has a binary value, which is a base-2 numeral system represented in a zero or a one. It is often easier to think of these binary values as on or off; a one represents on and a zero represents off. A Byte is made up of eight bits, and each bit position in a Byte holds a specific numeric value. If the bit is on, then you add the value of the that bit to the total for the Byte. If the bit is off, then you do not add the value of that bit to the total for the Byte. The bit values in an octet from left to right are 128, 64, 32, 16, 8, 4, 2, and 1. Table 6-4 illustrates the binary values that total 1-7 and 255. If you were to add up all the bit values, then the Byte would total 255.

Images

Table 6-4 Binary Values for 1 Byte

Images

Understanding how values are calculated for each Byte within an IPv4 address is important to understanding how Subnet Masks work. A Subnet Mask is a networking parameter that defines a range of IP addresses. Subnet Masks define this range base on a number of bits that are considered static within that range, leaving the rest of the bits to dynamically change. That is the range allowed within the Subnet. Since we now know that an IPv4 address is made up of four Bytes with 8 bits per Byte, and one Byte can have a total value of 255, a subnet mask may look something like 255.255.255.0. This mask identifies the first three Bytes as static, meaning they cannot change. The last Byte value is zero, meaning this mask allows for 255 total addresses. If you combine this Subnet Mask with the IP address of 192.168.1.0 then the total addresses within this Subnet range from 192.168.1.0 to 192.168.1.255. Since there are eight bits per Byte, the Subnet Mask does not have to make the cutoff at each full Byte value. For example, you could have an IP address of 192.168.1.0 and a Subnet Mask of 255.255.255.128 and now the IP range is from 192.168.1.0 to 192.168.1.127. If you change the IP address to 192.168.1.128 but leave the Mask the same, then the IP range is now from 192.168.1.128 to 192.168.1.255.

Another way of representing the Subnet Mask is to use a CIDR notation. A CIDR notation is a suffix that follows an IP address. This number is based on the static number of bits within a Subnet Mask. Therefore, If I had an IP address of 192.168.1.100 and a Subnet Mask of 255.255.255.0, then I could write it using a CIDR notation of 192.168.1.100/24. The First three Bytes are considered static in the Subnet Mask, and there are eight bits per Byte. Eight times three is twenty-four, hence the /24. The other example I gave previously of an IP address 192.168.1.128 and a Subnet Mask of 255.255.255.128 could be written as 192.168.1.128/25. All eight bits of the first three Bytes are static, plus one bit from the fourth Byte, totaling twenty-five bits.

Now let me bring this back to the Membership Rules on the Expressway. When the administrator creates a Membership Rule and selects Subnet as the Type, there are two important pieces of information that must be provided in that rule regarding the subnet. The administrator must first provide the Subnet address, which can be any IP address that exists within the subnet being identified for this Membership Rule. That IP address does not have to be the starting IP of the subnet range. It can exist anywhere within the range of the Subnet Mask. The second piece of information the administrator will need to provide is the Prefix length, which is the CIDR notation for the Subnet Mask being configured. Once these two pieces of information have been entered into the Expressway, the calculator built into the Membership Rule will automatically provide the range of IP addresses associated with the IP address and CIDR notation you configured.

For those of you who may be reading this book that already understand how subnetting works, notice that I did not mention the network address or the broadcast address. That’s because this is not true subnetting, like what you’d configure on a router. This tool only uses the basic principles of subnetting to create a range of addresses that determine which endpoints are allowed or not allowed to register to the designated Subzone based on that endpoint’s IP address. Also remember when I mentioned earlier in this chapter that subzones can be configured to Allow or Deny registrations in the same manner as the Registration Restriction Policy. When the Subzone is configured to Allow or Deny it is based on the Membership Rule created here. However, if an endpoint is Denied registration because of this Rule, that only denies registration to this Subzone, not to the Expressway. If an endpoint cannot register to any of the created Subzones based on a Membership Rule match, then they will automatically register to the Default Subzone. Figure 6-6 illustrates how Membership Rules can be configured using a Subnet Mask.

Images

Figure 6-6 Membership Rules Based on a Subnet Mask

The other method by which Membership Rules can determine whether endpoints are allowed or denied registration to a Subzone is using an Alias Pattern Match. Alias Pattern Matches are based on an Exact Match, Prefix, Suffix or Regular Expression. This should seem familiar to you, since these are the same methods used to create Allow List and Deny List patterns.

Images

To create Membership Rules, use the following steps:

Step 1. From the web interface of the Cisco Expressway, navigate to Configuration > Local Zone > Subzone membership rules.

Step 2. Click New and configure the following Setting:

a. Rule name: This is the identifying name for the rule. I like to use a naming convention similar to the Subzone it corresponds with. For example, if the Subzone was called Accounting_SZ then the Membership Rule may be called Accounting_MR.

b. Description: This is an optional settings that describes the reason this Membership Rule exists.

c. Priority: The Expressway will look at all the available rules in the order of their priority. The priority can be anywhere between 1 and 65534, 1 being the highest priority, and 100 is the default priority value.

d. Type: There are two Types that can be selected, as previously described. The settings that follow will change based on the Type selected.

i. Subnet: If this Type is selected then the next three settings will be Subnet address, Prefix length, and Address range. The last one is not a configurable value. It will display the range of IP addresses based on how the first two settings are configured.

ii. Alias pattern match: If this Type is selected then the next two settings will be Pattern type and Pattern string. The Pattern type can be configured as Exact, Prefix, Suffix or Regex.

e. Target subzone: The target cannot be the Traversal Subzone, because no endpoints are allowed to register there, nor can it be the Default Subzone. It can only be a Subzone created by an administrator.

Step 3. Click the Create rule button to create the Membership Rule.

The first rule that matches the credentials of a device trying to register is used, the Expressway will register the device in the Subzone that is associated with the Membership Rule, and no other rules will be search for that registration attempt. If no matches are found, then the Expressway will register the device to the Default Subzone.

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the exercises here, Chapter 22, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep Software Online.

Review All Key Topics

Review the most important topics in this chapter, noted with the Key Topics icon in the outer margin of the page. Table 6-5 lists a reference of these key topics and the page numbers on which each is found.

Images

Table 6-5 Key Topics for Chapter 6

Images

Complete Tables and Lists from Memory

Print a copy of Appendix C, “Memory Tables” (found on the companion website), or at least the section for this chapter, and complete the tables and lists from memory. Appendix D, “Memory Tables Answer Key,” also on the companion website includes completed tables and lists to check your work.

Define Key Terms

Define the following key terms from this chapter and check your answers in the glossary:

H.235

H.350

Microsoft Active Directory (AD)

Call Processing Language (CPL)

Default Subzone

Default Zone

Digest

E.164 Alias

Links

Local Zone

Message Digest Algorithm 5 (MD5)

Membership Rules

Network Time Protocol (NTP)

OpenLDAP

Registration Authentication

Registration Conflict Policy

Registration Restriction Policy

Registration Confirm (RCF)

Request in Progress (RIP)

Registration Reject (RRJ)

Registration Confirm (RRQ)

Subnet Mask

Subzone

Time to Live

Traversal Subzone

Q&A

The answers to these questions appear in Appendix A. For more practice with exam format questions, use the Pearson Test Prep Software Online.

1. What are the three configuration options for the Registration Restriction Policy?

2. List the three configuration options for the Registration Authentication Policy.

3. What are the three main steps to configure Registration Authentication on the Expressway?

4. List the Five default logical components of the Cisco Expressway.

Answers

1. Registration Restriction configuration options

Images Allow List

Images Deny List

Images Policy Service

2. Authentication Policy options

Images Do not check credentials

Images Treat as authenticated

Images Check credentials

3. Registration Authentication steps

Images Enable Authentication at the Subzone Level

Images Create a Username and Password in the Local Database

Images Verify NTP is enabled and synchronized

4. Default logical components

Images Local Zone

Images Default Subzone

Images Traversal Subzone

Images Default Zone

Images Links

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
44.197.114.92