Internet Engineering Task Force J. Espi Internet-Draft R. Atkinson Intended status: Standards Track University of Strathclyde Expires: September 24, 2010 March 23, 2010 Proactive Route Optimization for FMIPv6 draft-espi-ietf-mipshop-profmipv6-00.txt Abstract The Fast Handovers for Mobile IPv6 (FMIPv6) protocol was developed from the experience of MIPv6 and the facilities provided by link layer triggers, allowing for a proactive approach to handover that minimises packet exchange delay and packet loss. On completion of handover, the mobile node engages MIPv6 procedures in to update the Home Agent with the mobile node's new location. Subsequently, the mobile node may carry out Return Routability with the correspondent node(s) for route optimization. However, this method leaves scope to optimize handover delays derived from the signalling message exchange. This document proposes an enhancement to FMIPv6, the Proactive Route Optimization for FMIPv6 (PRO-FMIPv6) protocol, which aims to further reduce the signalling load thereby improving the overall performance of the handover process. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on 24th September 2010. Espi & Atkinson Expires September 24, 2010 [Page 1] Internet-Draft PRO-FMIPv6 March 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Language Requirements . . . . . . . . . . . . . . . . . . 3 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Modifications to MIPv6 and FMIPv6 Mobility Header-based messages . . . . . . . . . . . . . . . . . . 6 3.1.1. Modified FBU Mobility Message Format . . . . . . . . . 6 3.1.2. Proactive HoTI Message . . . . . . . . . . . . . . . . 8 3.1.3. Proactive CoTI Message . . . . . . . . . . . . . . . . 8 3.2. New Mobility Options . . . . . . . . . . . . . . . . . . . 9 3.2.1. BU Info Option . . . . . . . . . . . . . . . . . . . . 9 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Corrrespondent Node Operation . . . . . . . . . . . . . . 9 4.1.1. Data Structures . . . . . . . . . . . . . . . . . . . 10 4.1.2. Route Optimization Signalling . . . . . . . . . . . . 10 4.1.2.1. Receiving PHoTI and PCoTI . . . . . . . . . . . . 10 4.1.2.2. Sending Binding Acks . . . . . . . . . . . . . . . 11 4.1.2.3. Sending Binding Refresh Requests . . . . . . . . . 11 4.2. Home Agent Operation . . . . . . . . . . . . . . . . . . . 11 4.3. New Access Router Operation . . . . . . . . . . . . . . . 11 4.4. Previous Access Router Operation . . . . . . . . . . . . . 11 4.5. Mobile Node Operation . . . . . . . . . . . . . . . . . . 11 5. Configurable Parameters . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Normative References . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Espi & Atkinson Expires September 24, 2010 [Page 2] Internet-Draft PRO-FMIPv6 March 2010 1. Introduction The process of leaving a network link to join another is referred to as handover. Fast Handovers for Mobile IPv6 (FMIPv6) [RFC5568] enables a proactive approach to handover: before handover, the mobile node (MN) forms a new care-of address and solicits the present/ previous access router to start forwarding packets to that address at the next/new access router's link. As a consequence, the communication disruption is limited to the link layer procedures, i.e., synchronizing to the new access point (AP). Subsequently, the FMIPv6-enabled MN updates the binding cache of its home agent (HA) with its new care-of address (NCoA) and, optionally, the correspondent node (CN)'s binding cache for optimal routing via the Return Routability procedure [RFC3775]. The standard procedures based on FMIPv6 handover and route optimisation leave scope to reduce the handover delays and the signalling latency [RFC4651]. This document introduces Proactive Route Optimization for FMIPv6, namely, PRO-FMIPv6, which reduces this latency by carrying out the signalling towards route optimization proactively. More specifically, this specification suggests using cryptographically generated addresses to bind the home address (HoA) and the previous care-of address (PCoA) to the NCoA. The signalling exchange between MN and CN, carried out proactively, allows the CN to check the validity of the new care-of address through a cryptographic route test. PRO-FMIPv6 is independent of the link-layer technology. The document updates the format of the "(Proactive) Home Address Test Initiation (PHoTI)" message, "(Proactive) Care-of Test Initiation (PCoTI)" message and "Fast BU (FBU)" message. It also defines a new type of Mobility Header-based option; the "Binding Update Info (BUInfo)". The handovers defined in this specification can interwork with MIPv6/ FMIPv6 enabled networks as they are backwards compatible. 1.1. Language Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The use of the term, "silently ignore" is not defined in RFC 2119. However, the term is used in this document and can be similarly construed. The following terminology and abbreviations are used in this document Espi & Atkinson Expires September 24, 2010 [Page 3] Internet-Draft PRO-FMIPv6 March 2010 in addition to those defined in [RFC3775, RFC5568]. Proxy Binding Update (PrBU): It is a BU sent on behalf of the MN by any other network entity. Token Table: It is kept by the CN. It contains the MN's HoA, PCoA and tentative NCoA, the two tokens used for route optimization security check and the NAR's prefix. 2. Protocol Overview The proposed protocol aims to integrate a novel signalling scheme for route optimization within the FMIPv6-provided facilities. As in FMIPv6, through the "Router Solicitation for Proxy Advertisement (RtSolPr)" and "Proxy Router Advertisement (PrRtAdv)" messages, the MN also formulates a prospective new CoA (NCoA) when it is still present on the PAR's link. This address can be used immediately in the new subnet link when the MN has received a "Fast Binding Acknowledgment (FBack)" (see Section 6.2.3 in [RFC5568]) message prior to its movement. In the event it moves without receiving an FBack, the MN can still use the NCoA after announcing its attachment through an "Unsolicited Neighbor Advertisement (UNA)" message (with the 'O' bit set to zero) [RFC4861]; the NAR may respond to this UNA message if it wishes to provide a different IP address to use. In this way, NCoA configuration latency is reduced. The information provided in the PrRtAdv message can be used even when DHCP [RFC3315] is used to configure an NCoA on the NAR's link. In this case, the protocol supports forwarding using PCoA, and the MN performs DHCP once it attaches to the NAR's link. The MN still formulates an NCoA for FBU processing; however, it MUST NOT send data packets using the NCoA in the FBU. Like FMIPv6, the MN generates the NCoA from the NAR's prefix, included in the PrRtAdv message. However, additionally, the MN generates two random numbers (tokens). The NCoA is form as shown in equation (1). NCoA = NAR_prefix | hash (HoA | token1 | token2) (1) Each of the tokens (token1 and token2) is included in a Mobility Header-based message (PHoTI and PCoTI) that traverse different paths to the CN. The PHotI message is sent to the CN via the HA just like the HoTI message in standard MIPv6, and the PCoTI message is sent via the NAR. The CN receives both packets (PHoTI and PCoTI) from the home and care-of addresses respectively. This requires both the HA Espi & Atkinson Expires September 24, 2010 [Page 4] Internet-Draft PRO-FMIPv6 March 2010 and the NAR to proxy those packets, i.e., the HA has to set the IPv6 source address field in the PHoTI packet to the home address, and the NAR has to set the PCoTI source address to the new care-of address. Moreover, the PAR and the HA update their MN's NCoA entries with the NCoA included in the PHoTI message. On receipt of the two tokens, the CN is able to check whether the home and care-of addresses fit with that in equation (1). If the NCoA is valid, the CN updates its binding cache and replies with a BA. However, if the check is not valid, the packets are silently discarded. Immediately after sending FBU | PHoTI and PCoTI, the MN starts layer 2 handover. After joining the new link, the MN announces its attachment with a UNA message that instructs NAR to forward packets to the MN. The MN MUST receive a FBack message from the PAR indicating the tunnel is correctly set. The MN MUST receive at least one FBack since this message is bicasted from the PAR to both the PCoA and NCoA. Likewise, the MN MUST receive a BA from the HA acknowledging the MN's NCoA. Also, if the CN's validity check is met, the CN MUST send a BA to the NCoA. Espi & Atkinson Expires September 24, 2010 [Page 5] Internet-Draft PRO-FMIPv6 March 2010 MN PAR NAR HA CN | | | | | |------RtSolPr--->| | | | |<-----PrRtAdv----| | | | | | | | | |FBU|PHoTI|BUInfo>|--------PHoTI|BUInfo-------->|-PHoTI|BUInfo->| |--------------PCoTI--- -------->|----------PCoTI-------------->| | |-----HI------>| | | | |<-----HAck----| | | | | |<------BA-----| | | <--FBack---|--FBack---> | send | | | |<========== packets | disconnect forward | | | | packets =========>| | | | | |<-----------BA----------------| | | | | | connect | | | send | | |<======================== packets |--------UNA ------------------->| | | |<========================= deliver packets | | | | | | PRO-FMIPv6 signalling. 3. Message Formats 3.1. Modifications to MIPv6 and FMIPv6 Mobility Header-based messages 3.1.1. Modified FBU Mobility Message Format The 'O' flag has been added as follows. Espi & Atkinson Expires September 24, 2010 [Page 6] Internet-Draft PRO-FMIPv6 March 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|O| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Modified FBU Mobility Message. IP Fields: Source Address: The PCoA Destination Address: The IP address of the Previous Access Router. 'A' flag: See [RFC5568]. 'H' flag: MUST be set to one. See [RFC3775],[RFC5568]. 'L' flag: See [RFC3775]. 'K' flag: See [RFC3775]. 'O' flag: The Proactive Route Optimization ('O') is set by the MN to request the PAR to forward the enclosed mobility options to the HA. Reserved: This field is unused. MUST be set to zero. For descriptions of other fields present in this option header, refer to Section 6.2.2 of [RFC5568]. The FBU message is sent by the MN using its PCoA to the PAR's IP address Espi & Atkinson Expires September 24, 2010 [Page 7] Internet-Draft PRO-FMIPv6 March 2010 3.1.2. Proactive HoTI Message In [RFC3775] the HoTI message is designed to initiate the return routability procedure and request a home keygen token from a correspondent node. The Proactive Home Test Init message is forwarded by the HA to the CN using the MH Type value 1. The HoTI message has been modiffied including the 'O' flag to indifcate proactive optimization. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Home Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . HoTI([RFC3775])-related . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Proactive HoTI. 3.1.3. Proactive CoTI Message In [RFC3775] the CoTI message is used to initiate the return routability procedure and request a care-of keygen token from a correspondent node. The Proactive Care-of Test Init message is forwarded by the NAR to the CN using the MH Type value 1. The CoTI message has been modified including the 'O' flag to indicate proactive optimization. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: Espi & Atkinson Expires September 24, 2010 [Page 8] Internet-Draft PRO-FMIPv6 March 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Care-of Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . CoTI([RFC3775])-related . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Proactive CoTI. 3.2. New Mobility Options 3.2.1. BU Info Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|P| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BU Info. The BU Info option header is equivalent to the BU message [RFC3775]. The flags remain the same as in [RFC3775], including those defined in [RFC3963], [RFC4140] and [RFC5213] ('R', 'M' and 'P' respectively). Type: 28 For descriptions of other fields present in this option header, refer to Section 6.1.7 of [RFC3775]. 4. Protocol Details 4.1. Corrrespondent Node Operation Espi & Atkinson Expires September 24, 2010 [Page 9] Internet-Draft PRO-FMIPv6 March 2010 4.1.1. Data Structures In addition to a Bining Cache, the CN MUST maintain a Token Table, where the CN keeps track of the tokens received and mobility related information from the MN. Each MN already contacting the CN towards route optimization has one entry. Each entry has five fields: HoA: obtained at session set up NCoA: retrieved from PHoTI (IP in IP encapsulation) and PCoTI messages Token1: token included in PHoTI message Token2: token included in PCoTI message NAR's prefix: retrieved from PCoTI message This Token Table MAY be implemmented in any manner consistent with the behaviour described in this document. 4.1.2. Route Optimization Signalling 4.1.2.1. Receiving PHoTI and PCoTI The CN, on receipt of either the PHoTI or the PCoTI message, MUST create an (incomplete) entry in the Token Table. This entry will be kept until the second message is received or MAX_TOKEN LIFETIME seconds are elapsed. The MAX_TOKEN LIFETIME timeout period is devised to prevent memory exhaustion due to the size of the CN's Token Table. If both messages are correctly received within a MAX_TOKEN LIFETIME seconds time frame, then the CN will MUST validate the following tests: NCoA MUST be a unicast routable address. PHoTI and PCoTI MUST have same nonce index. Fields in the Token Table MN's entry (NAR's prefix, tokens 1 and 2, Home Address) MUST meet equation (1). If the tests are met, then the CN processes the BUInfo option (included in the PHoTI message) as described in RFC 3775, Section 9.5.1. Next, the CN sends a BA to the MN's NCoA according to RFC 3775, Section 9.5.4. Espi & Atkinson Expires September 24, 2010 [Page 10] Internet-Draft PRO-FMIPv6 March 2010 If the tests are not met, the MN's entry is removed from the Token Table. 4.1.2.2. Sending Binding Acks Refer to RFC 3775, Section 9.5.4. 4.1.2.3. Sending Binding Refresh Requests This document does not address refreshing bindings. 4.2. Home Agent Operation The Home Agent operation is largely based on [RFC3775]. On receipt of a PHoTI message, the Home Agent checks the validity of the enclosed BU Info option. If the validity check is successful, the Home Agent MUST send a BA to the MN's NCoA. Next, the Home Agent forwards the PHoTI message to the CN's address. However, if the validity check fails, the Home Agent silently ignores the PHoTI message. The Binding Cache entry is to last MAX_RR_BINDING LIFETIME seconds. In the eventuality of expiration of the Binding Cache entry, the Home Agent operates as in [RFC3775]. 4.3. New Access Router Operation The NAR MUST behave as stated in [RFC5568]. Prior to handoff, the MN sends the PHoTI and the PCoTI messages, that traverse different paths towards the CN. The PCoTI message is routed along the PCoA-NCoA-CN path. The NAR, on recepit of the PCoTI message, MUST forward it to the CN, including the PCoA as a home address option (defined in [RFC3775]). 4.4. Previous Access Router Operation The PAR MUST behave as stated in [RFC5568]. Additionally, of receipt of the PoTI message, it MUST forward it to the HA, including the PCoA as a home address option ([RFC3775]). 4.5. Mobile Node Operation The protocol begins when the MN sends the RtSolPr to its PAR to resolve one or more Access Points Identifiers to subnet-specific information. In response, the PAR sends the PrRtAdv containing one or more [AP-ID, AR-Info] tuples [RFC5568]. Espi & Atkinson Expires September 24, 2010 [Page 11] Internet-Draft PRO-FMIPv6 March 2010 From the information received in the PrRtAdv message, the MN generates a prospective NCoA using equation (1). In order to do so, the MN generates two random tokens that it concatenates to the HoA and applies a SHA1 hash function to the result. The MN will then send two messages, the FBU and the PCoTI. The FBU message comprises a PHoTI message and a BUInfo option enclosed in a MIPv6 FBU message. The MN sends this message to the PAR. In the BUInfo option, bit 'A' MUST be set. The PCoTI message is sent to the NAR, that will forward it to the CN (IPv6 encapsulation). Next, the MN performs handover to the NAR. After the attachment, the MN should receive two acknowledgements, specifically, from the PAR and the HA. The MN may receive a third acknowledgement from the CN, in the special case wherethe CN is PRO-FMIPv6 enabled. 5. Configurable Parameters Mobile nodes rely on the configuration parameters defined in section 12 of [RFC3775] and section 9 of [RFC5568]. Each mobile node MUST have a configuration mechanism to adjust the parameters. In addition, the value of MAX_TOKEN LIFETIME ([RFC3775]) is reduced to 3 seconds. The rationale behind this is that the MN sends both the PHoTI and PCoTI messages simultaneously and therefore the CN expects to receive them at approximately the same time. 6. Security Considerations Firstly, a malicious MN may try to redirect traffic from his HoA or PCoA to a NCoA. E.g., if a MN is connected with a server through a high-speed connection, the MN could redirect the stream towards a low-speed NAR (in terms of processing or link capacity). PRO-FMIPv6 precludes MN from carrying out this kind of attacks: The NAR can voluntarily discard the PCoTI message if the QoS required for the MN is too high, if the proposed NCoA is not acceptable, if the source PCoA or HoA is from a domain not accepted, if the NAR does not have any established trust relationship with the PAR, if the demanded buffer size is too high or if the access control parameters do not meet the security requirements. The NAR retrieves information on all the previously mentioned issues from the HI message. Espi & Atkinson Expires September 24, 2010 [Page 12] Internet-Draft PRO-FMIPv6 March 2010 Even if this kind of Denial of Service (DoS) attack could be effectively carried out, the malevolent MN would not be capable of specifying any concrete IPv6 address. The rationally behind that is that it would be virtually impossible for a MN to find two random numbers such that the result of equation (1) is equivalent to the target IPv6 address. Secondly, a malicious 3rd party may try to steal a node's (either mobile or fixed) IPv6 address by creating a binding cache entry at the CN. PRO-FMIPv6 prevents attackers from doing this. In case a HA receives a PHoTI message for whose HoA has no administrative agreement, it silently ignores it. Thirdly, one or more attackers may want to consume all the memory available in the CN's tokens table by sending a number of PHoTI or PCoTI messages. In any case, every time a CN receives a BU|t1 or BU|t2 the CN overrides the correspondent HoA or NCoA respectively, so therefore there is only one entry at the tokens table for each MN, independently of how frequently performs the signalling towards route optimization. Moreover, registers in the token table are only kept for MAX_TOKEN LIFETIME seconds. Finally, the protocol inherits the vulnerabilities identified in [RFC5568] for the RtSolPr, PrRtAdv and FBU messages. 7. IANA Considerations TBD 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. Espi & Atkinson Expires September 24, 2010 [Page 13] Internet-Draft PRO-FMIPv6 March 2010 Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009. Authors' Addresses Jorge Espi University of Strathclyde Glasgow, UK Phone: +44 0141 548 2527 Email: jorge.espi@eee.strath.ac.uk Robert C. Atkinson University of Strathclyde Glasgow, UK Phone: +44 0141 548 2879 Email: r.atkinson@eee.strath.ac.uk Espi & Atkinson Expires September 24, 2010 [Page 14] Internet-Draft PRO-FMIPv6 March 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Espi & Atkinson Expires September 24, 2010 [Page 15]