Home > Articles > Configuring the Enhanced Interior Gateway Routing Protocol

Configuring the Enhanced Interior Gateway Routing Protocol

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Dec 25, 2006.

Configuring EIGRP Authentication

You can prevent your router from receiving fraudulent route updates by configuring neighbor router authentication. You can configure EIGRP neighbor authentication (also called neighbor router authentication or route authentication) such that routers can participate in routing based on predefined passwords.

This section first describes router authentication in general, followed by a discussion of how to configure and troubleshoot EIGRP Message Digest 5 (MD5) authentication.

Router Authentication

Neighbor router authentication can be configured such that routers only participate in routing based on predefined passwords.

By default, no authentication is used for routing protocol packets. When neighbor router authentication has been configured on a router, the router authenticates the source of each routing update packet that it receives. This is accomplished by the exchange of an authentication key (also called a password) that is known to both the sending and the receiving router.

The router uses two types of authentication:

  • Simple password authentication (also called plain text authentication)—Supported by Integrated System-Integrated System (IS-IS), Open Shortest Path First (OSPF), and Routing Information Protocol Version 2 (RIPv2)
  • MD5 authentication—Supported by OSPF, RIPv2, BGP, and EIGRP

Both forms of authentication work in the same way, with the exception that MD5 sends a message digest instead of the authenticating key itself. The message digest is created using the key (and a key ID with some protocols) and a message, but the key itself is not sent, preventing it from being read while it is being transmitted. Simple password authentication sends the authenticating key itself over the wire.

With simple password authentication, a password (key) is configured on a router; each participating neighbor router must be configured with the same key.

MD5 authentication is a cryptographic authentication. A key (password) and key ID are configured on each router. The router uses an algorithm based on the routing protocol packet, the key, and the key ID to generate a message digest (also called a hash) that is appended to the packet. Unlike the simple authentication, the key is not exchanged over the wire—the message digest is sent instead of the key, which ensures that nobody can eavesdrop on the line and learn keys during transmission.

EIGRP MD5 Authentication

By default, no authentication is used for EIGRP packets. You can configure EIGRP to use MD5 authentication.

When EIGRP neighbor authentication has been configured on a router, the router authenticates the source of each routing update packet that it receives. The MD5 keyed digest in each EIGRP packet prevents the introduction of unauthorized or false routing messages from unapproved sources.

For EIGRP MD5 authentication, you must configure an authenticating key and a key ID on both the sending router and the receiving router. Each key has its own key ID, which is stored locally. The combination of the key ID and the interface associated with the message uniquely identifies the authentication algorithm and MD5 authentication key in use.

EIGRP allows keys to be managed using key chains. Each key definition within the key chain can specify a time interval for which that key will be activated (known as its lifetime). Then, during a given key's lifetime, routing update packets are sent with this activated key. Only one authentication packet is sent, regardless of how many valid keys exist. The software examines the key numbers in order from lowest to highest, and it uses the first valid key it encounters.

Keys cannot be used during time periods for which they are not activated. Therefore, it is recommended that for a given key chain, key activation times overlap to avoid any period of time for which no key is activated. If a time period occurs during which no key is activated, neighbor authentication cannot occur, and therefore routing updates will fail.

Configuring MD5 Authentication

To configure MD5 authentication for EIGRP, complete the following steps:

  • Step 1 Enter configuration mode for the interface on which you want to enable authentication.
  • Step 2 Specify MD5 authentication for EIGRP packets using the ip authentication mode eigrp autonomous-system md5 interface configuration command. The autonomous-system is the EIGRP autonomous system number in which authentication is to be used.
  • Step 3 Enable the authentication of EIGRP packets with a key specified in a key chain by using the ip authentication key-chain eigrp autonomous-system name-of-chain interface configuration command. The autonomous-system parameter specifies the EIGRP autonomous system number in which authentication is to be used. The name-of-chain parameter specifies the name of the authentication key chain from which a key is to be obtained for this interface.
  • Step 4 Enter the configuration mode for the key chain using the key chain name-of-chain global configuration command.
  • Step 5 Identify a key ID to use and enter configuration mode for that key using the key key-id key-chain configuration command. The key-id is the ID number of an authentication key on a key chain. The range of keys is from 0 to 2147483647; the key ID numbers need not be consecutive.
  • Step 6 Identify the key string (password) for this key using the key-string key key-chain-key configuration command. The key is the authentication key-string that is to be used to authenticate sent and received EIGRP packets. The key string can contain from 1 to 80 uppercase and lowercase alphanumeric characters, except that the first character cannot be a number.
  • Step 7 Optionally specify the time period during which this key will be accepted for use on received packets using the accept-lifetime start-time {infinite | end-time | duration seconds} key-chain-key configuration command. Table 3-3 describes the parameters for this command.

    Table 3-3. accept-lifetime Command Parameters

    Parameter

    Description

    start-time

    Beginning time that the key specified by the key command is valid for use on received packets. The syntax can be either of the following:

    hh:mm:ss month date year
    hh:mm:ss date month year
       hh—hours
       mm—minutes
       ss—seconds
       month—first three letters of the month
       date—date (1-31)
       year—year (four digits)

    The default start time and the earliest acceptable date is January 1, 1993.

    infinite

    Indicates the key is valid for use on received packets from the start-time value on.

    end-time

    Indicates the key is valid for use on received packets from the start-time value until the end-time value. The syntax is the same as that for the start-time value. The end-time value must be after the start-time value. The default end time is an infinite time period.

    seconds

    Length of time (in seconds) that the key is valid for use on received packets. The range is from 1 to 2147483646.

  • Step 8 Optionally specify the time period during which this key can be used for sending packets using the send-lifetime start-time {infinite | end-time | duration seconds} key-chain-key configuration command. Table 3-4 describes the parameters for this command.

Table 3-4. send-lifetime Command Parameters

Parameter

Description

start-time

Beginning time that the key specified by the key command is valid to be used for sending packets. The syntax can be either of the following:

hh:mm:ss month date year
hh:mm:ss date month year
hh—hours
mm—minutes
ss—seconds
month—first three letters of the month
date—date (1-31)
year—year (four digits)

The default start time and the earliest acceptable date is January 1, 1993.

infinite

Indicates the key is valid to be used for sending packets from the start-time value on.

end-time

Indicates the key is valid to be used for sending packets from the start-time value until the end-time value. The syntax is the same as that for the start-time value. The end-time value must be after the start-time value. The default end time is an infinite time period.

seconds

Length of time (in seconds) that the key is valid to be used for sending packets. The range is from 1 to 2147483646.

MD5 Authentication Configuration Example

Figure 3-26 shows the network used to illustrate the configuration, verification, and troubleshooting of MD5 authentication.

Figure 3-26

Figure 3-26 Network for EIGRP Authentication Configuration Example

Example 3-13 shows the configuration of the R1 router.

Example 3-13. Configuration of Router R1 in Figure 3-26

R1#show running-config
<output omitted>
key chain R1chain
 key 1
  key-string firstkey
  accept-lifetime 04:00:00 Jan 1 2006 infinite
  send-lifetime 04:00:00 Jan 1 2006 04:01:00 Jan 1 2006
 key 2
  key-string secondkey
  accept-lifetime 04:00:00 Jan 1 2006 infinite
  send-lifetime 04:00:00 Jan 1 2006 infinite
<output omitted>
interface FastEthernet0/0
 ip address 172.16.1.1 255.255.255.0
!
interface Serial0/0/1
 bandwidth 64
 ip address 192.168.1.101 255.255.255.224
 ip authentication mode eigrp 100 md5
 ip authentication key-chain eigrp 100 R1chain
!
router eigrp 100
 network 172.16.1.0 0.0.0.255
 network 192.168.1.0
 auto-summary

MD5 authentication is configured on the serial 0/0/1 interface with the ip authentication mode eigrp 100 md5 command. The ip authentication key-chain eigrp 100 R1chain command specifies that the key chain R1chain is to be used.

The key chain R1chain command enters configuration mode for the R1chain key chain. Two keys are defined. Key 1 is set to firstkey with the key-string firstkey command. This key is acceptable for use on packets received by R1 from January 1, 2006 onward, as specified in the accept-lifetime 04:00:00 Jan 1 2006 infinite command. However, the send-lifetime 04:00:00 Jan 1 2006 04:01:00 Jan 1 2006 command specifies that this key was only valid for use when sending packets for 1 minute on January 1, 2006; it is no longer valid for use in sending packets.

Key 2 is set to secondkey with the key-string secondkey command. This key is acceptable for use on packets received by R1 from January 1, 2006 onward, as specified in the accept-lifetime 04:00:00 Jan 1 2006 infinite command. This key can also be used when sending packets from January 1, 2006 onward, as specified in the send-lifetime 04:00:00 Jan 1 2006 infinite command.

R1 will therefore accept and attempt to verify the MD5 digest of any EIGRP packets with a key ID equal to 1 or 2. All other MD5 packets will be dropped. R1 will send all EIGRP packets using key 2, because key 1 is no longer valid for use when sending packets.

Example 3-14 shows the configuration of the R2 router.

Example 3-14. Configuration of Router R2 in Figure 3-26

R2#show running-config
<output omitted>
key chain R2chain
 key 1
  key-string firstkey
  accept-lifetime 04:00:00 Jan 1 2006 infinite
  send-lifetime 04:00:00 Jan 1 2006 infinite
 key 2
  key-string secondkey
  accept-lifetime 04:00:00 Jan 1 2006 infinite
  send-lifetime 04:00:00 Jan 1 2006 infinite
<output omitted>
interface FastEthernet0/0
 ip address 172.17.2.2 255.255.255.0
!
interface Serial0/0/1
 bandwidth 64
 ip address 192.168.1.102 255.255.255.224
 ip authentication mode eigrp 100 md5
 ip authentication key-chain eigrp 100 R2chain
!
router eigrp 100
 network 172.17.2.0 0.0.0.255
 network 192.168.1.0
 auto-summary

MD5 authentication is configured on the serial 0/0/1 interface with the ip authentication mode eigrp 100 md5 command. The ip authentication key-chain eigrp 100 R2chain command specifies that the key chain R2chain is to be used.

The key chain R2chain command enters configuration mode for the R2chain key chain. Two keys are defined. Key 1 is set to firstkey with the key-string firstkey command. This key is acceptable for use on packets received by R2 from January 1, 2006 onward, as specified in the accept-lifetime 04:00:00 Jan 1 2006 infinite command. This key can also be used when sending packets from January 1, 2006 onward, as specified in the send-lifetime 04:00:00 Jan 1 2006 infinite command.

Key 2 is set to secondkey with the key-string secondkey command. This key is acceptable for use on packets received by R2 from January 1, 2006 onward, as specified in the accept-lifetime 04:00:00 Jan 1 2006 infinite command. This key can also be used when sending packets from January 1, 2006 onward, as specified in the send-lifetime 04:00:00 Jan 1 2006 infinite command.

R2 will therefore accept and attempt to verify the MD5 digest of any EIGRP packets with a key ID equal to 1 or 2. R2 will send all EIGRP packets using key 1, because it is the first valid key in the key chain.

Verifying MD5 Authentication

Example 3-15 provides the output of the show ip eigrp neighbors and show ip route commands on the R1 router depicted in the network in Figure 3-26. The neighbor table indicates that the two routers have successfully formed an EIGRP adjacency. The routing table verifies that the 172.17.0.0 network has been learned via EIGRP over the serial connection. Example 3-15 also shows the results of a ping to the R2 Fast Ethernet interface address to illustrate that the link is working.

Example 3-15. Output on Router R1 in Figure 3-26

R1#
*Apr 21 16:23:30.517: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.102 (Serial0/
  0/1) is up: new adjacency
R1#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H   Address                 Interface  Hold Uptime   SRTT  RTO   Q  Seq
                                       (sec)         (ms)       Cnt Num
0   192.168.1.102           Se0/0/1      12 00:03:10   17 2280   0  14
R1#show ip route
<output omitted>
Gateway of last resort is not set
D    172.17.0.0/16 [90/40514560] via 192.168.1.102, 00:02:22, Serial0/0/1
     172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
D       172.16.0.0/16 is a summary, 00:31:31, Null0
C       172.16.1.0/24 is directly connected, FastEthernet0/0
     192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.1.96/27 is directly connected, Serial0/0/1
D       192.168.1.0/24 is a summary, 00:31:31, Null0
R1#ping 172.17.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.17.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/15/16 ms

Troubleshooting MD5 Authentication

This section provides some examples of how to troubleshoot EIGRP MD5 authentication.

Example of Successful MD5 Authentication

Example 3-16 shows output from the debug eigrp packets command on R1, which displays that R1 is receiving EIGRP packets with MD5 authentication, with a key ID equal to 1, from R2.

Example 3-16. debug eigrp packets Command Output on Router R1 in Figure 3-26

R1#debug eigrp packets
EIGRP Packets debugging is on
    (UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
*Apr 21 16:38:51.745: EIGRP: received packet with MD5 authentication, key id = 1
*Apr 21 16:38:51.745: EIGRP: Received HELLO on Serial0/0/1 nbr 192.168.1.102
*Apr 21 16:38:51.745: AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/
  rely 0/0

Similarly, the output of the debug eigrp packets command on R2 shown Example 3-17 illustrates that R2 is receiving EIGRP packets with MD5 authentication, with a key ID equal to 2, from R1.

Example 3-17. debug eigrp packets Command Output on Router R2 in Figure 3-26

R2#debug eigrp packets
EIGRP Packets debugging is on
    (UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
R2#
*Apr 21 16:38:38.321: EIGRP: received packet with MD5 authentication, key id = 2
*Apr 21 16:38:38.321: EIGRP: Received HELLO on Serial0/0/1 nbr 192.168.1.101
*Apr 21 16:38:38.321:   AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/
  rely 0/0

Example of Troubleshooting MD5 Authentication Problems

For this example, the key string for router R1's key 2, the one that it uses when sending EIGRP packets, is changed to be different from the key string that router R2 is expecting. Example 3-18 shows the changes to the configuration for R1.

Example 3-18. Changes to the Configuration of Router R1 in Figure 3-26

R1(config-if)#key chain R1chain
R1(config-keychain)#key 2
R1(config-keychain-key)#key-string wrongkey

The output of the debug eigrp packets command on R2 shown in Example 3-19 illustrates that R2 is receiving EIGRP packets with MD5 authentication, with a key ID equal to 2, from R1, but that there is an authentication mismatch. The EIGRP packets from R1 are ignored, and the neighbor relationship is declared to be down. The output of the show ip eigrp neighbors command confirms that R2 does not have any EIGRP neighbors.

Example 3-19. Output on Router R2 in Figure 3-26

R2#debug eigrp packets
EIGRP Packets debugging is on
    (UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
R2#
*Apr 21 16:50:18.749: EIGRP: pkt key id = 2, authentication mismatch
*Apr 21 16:50:18.749: EIGRP: Serial0/0/1: ignored packet from 192.168.1.101, opcode = 5
  (invalid authentication)
*Apr 21 16:50:18.749: EIGRP: Dropping peer, invalid authentication
*Apr 21 16:50:18.749: EIGRP: Sending HELLO on Serial0/0/1
*Apr 21 16:50:18.749:   AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Apr 21 16:50:18.753: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.101
(Serial0/0/1) is down: Auth failure

R2#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
R2#

The two routers keep trying to reestablish their neighbor relationship. Because of the different keys used by each router in this scenario, R1 will authenticate hello messages sent by R2 using key 1. When R1 sends a hello message back to R2 using key 2, however, an authentication mismatch exists. From R1's perspective, the relationship appears to be up for a while, but then it times out, as illustrated by the messages received on R1 shown in Example 3-20. The output of the show ip eigrp neighbors command on R1 also illustrates that R1 does have R2 in its neighbor table for a short time.

Example 3-20. Output on Router R1 in Figure 3-26

R1#
*Apr 21 16:54:09.821: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.102 (Serial0
  /0/1) is down: retry limit exceeded
*Apr 21 16:54:11.745: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.102 (Serial0
  /0/1) is up: new adjacency
R1#show ip eigrp neighbors
H  Address         Interface Hold Uptime   SRTT  RTO  Q   Seq
                             (sec)          (ms)      Cnt  Num
0  192.168.1.102   Se0/0/1     13 00:00:38    1  5000  1  0
5. Using EIGRP in an Enterprise Network | Next Section Previous Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.

Overview

Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security

Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children

This site is not directed to children under the age of 13.

Marketing

Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out

Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links

This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020