Internet Draft Muhammad Jaseemuddin Document: draft-jaseem-rap-cops-mip-00.txt Abderrahmane Lakas Expires April 2001 Nortel Networks October 2000 COPS usage for Mobile IP (MIP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 Abstract. Mobile IP is a protocol that is used to achieve transparent routing of IP packets to a mobile node. A mobile node obtains a care-of- address in the foreign network and registers that address with the home agent. The home agent as well as the foreign agent can apply policies to the mobile node registration. This draft defines COPS [1] usage for Mobile IPv4 [2]. It describes how COPS is used to control Mobile IP registration based on policies. It defines the interactions between the PEP and the PDP to handle Mobile IP registration messages. It also provides a guideline for mobility agents on how to use this COPS client with regards to the registration messages. Conventions used in this document MIP Mobile IP HA Home Agent FA Foreign Agent MN Mobile Node CN Correspondent Node Mobility agent FA or HA Jaseemuddin, Lakas Expires April 2001 [Page 1] Internet Draft COPS usage for Mobile IP (MIP) October 2000 The above terms have been explained in [2]. We define additional terms for this draft as follows. Registration message Registration Request or Reply FPEP PEP client attached to FA HPEP PEP client attached HA FPDP PDP managing FPEP HPDP PDP managing HPEP CoA Care-of address In this draft we use interchangeably the terms FPEP and FA in the context of foreign agent, and HPEP and HA in the context of home agent. We also use the term Mobile to refer to mobile node. 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 [3]. 1. Introduction Mobile IP [2,4] is a protocol that is used to achieve transparent routing of IP packets to a mobile node. An MN has a permanent IP address called home address in its home network. A router in the home sub-net serves as Home Agent (HA) for the MN. When the MN moves from the home network to a foreign network, it obtains a care-of address (CoA) from the foreign network. The CoA may be one of the addresses of the router serving as the Foreign Agent (FA), called the foreign agent CoA, or a co-located CoA. The co-located CoA is a local address that is assigned to MN in a foreign network, which is routable in the IP network. The protocol provides a registration mechanism that is used by MN to register with HA the new CoA. Then, the HA intercepts the data packets destined for the MN's home address, and forward them through an IP tunnel to the CoA. In case of foreign agent CoA, the FA serves as the endpoint of the tunnel, and forwards the packets received from the HA to the MN. If the CoA is a co-located CoA, then the MN is the endpoint of the tunnel, which decapsulates packets received from the HA through the tunnel. The Mobile IP registration involves exchange of Registration Request and Reply messages. The registration can happen through FA. The MN sends Registration Request to the FA, which then relays it to the HA. The Reply comes back from the HA to the FA, which then relays it to the MN. Before registering CoA, the MN discovers a router in the foreign network to get connectivity to the IP network. The router may also serve as FA. The discovery involves exchange of Agent Solicitation and Agent Advertisement messages between the MN and the FA. The FA advertises the set of care-of addresses through the Agent Advertisement message. The MN picks one of the care-of addresses and Jaseemuddin, Lakas Expires April 2001 [Page 2] Internet Draft COPS usage for Mobile IP (MIP) October 2000 register that with the HA. In case of co-located CoA, MN can register that address directly with the HA. Alternatively, the FA can force MN to register its co-located CoA via the FA by setting up R bit in the Agent Advertisement message. The Mobile IP registration request message shows the MN's intent to become a registered node and get IP connectivity in the foreign network. In case of the foreign agent CoA, the FA should serve as the endpoint of HA-FA tunnel, and forward the packets received from the HA to the MN. The registration reply grants the MN the status of a registered node. The registration in a network domain can be subjected to policies defined in that domain. For example, before relaying a Registration Request to the HA, and then the Registration Reply to the MN, the FA may apply policies defined for the mobile user. Similarly, before responding to the Registration Request, the HA may apply policies for user roaming within the foreign domain. Figure 1 illustrates policy framework for Mobile IP. +--------+ +--------+ | | | | | HPDP | | FPDP | | | | | +--------+ +--------+ ^ ^ | | | | 4 | |2,6 | | | | v v +--------+ 3 +--------+ 1 +--------+ | |<-------------------- | |<-----| | | HPEP | 5 | FPEP | 7 | MN | | (HA) | -------------------> | (FA) |----> | | +--------+ +--------+ +--------+ 1. MN sends a Registration Request to FA 2. FPEP and FPDP interact for policy decisions for Registration Request 3. FA relays Registration Request to HA 4. HPEP and HPDP interact for policy decisions 5. HA sends Registration Reply to FA 6. FPEP and FPDP interact for policy decisions for Registration Reply 7. FA forwards Registration Reply to MN Figure 1: A typical policy control registration This draft defines COPS usage for Mobile IPv4 [2,4]. It describes how COPS is used to control Mobile IP registration based on Jaseemuddin, Lakas Expires April 2001 [Page 3] Internet Draft COPS usage for Mobile IP (MIP) October 2000 policies. It brings the registration process under the policy framework. It defines the interactions between the PEP and the PDP, and also provides a guideline for HA and FA to enforce policies with regards to the registration messages. 2. COPS Specific Object Formats This section defines the format of COPS objects that are specific to the COPS-MIP client. 2.1 Common Header, client-type client-type is COPS-MIP (TBD) 2.2 Context Object (Context) C-num = 2, C-Type = 1 0 1 2 3 +---------------+---------------+---------------+---------------+ | R-Type | M-Type | +---------------+---------------+---------------+---------------+ R-Type (Request Type Flag) 0x01 = Incoming-Message request: A MIP message is received 0x04 = Outgoing-Message request: Relaying a MIP message M-Type 0x01 = Registration request 0x02 = Registration reply 2.3 COPS-MIP Objects We define new objects for COPS-MIP. These objects are used within Client Specific Information, Client Specific Decision data, and Replacement data objects. The following common format is defined for these objects: 0 1 2 3 +---------------+---------------+---------------+---------------+ | Length | S-Num | S-Type | +---------------+---------------+---------------+---------------+ | Value ... | +---------------+---------------+---------------+---------------+ The S-Num field defines the general purpose of the object, and S- Type defines the subtype within the object type. Length is a two- octet value that indicates the length in octets of the object including the header. If the size of the object does not fall on a 32-bit word boundary, padding MUST be added to the end of the object Jaseemuddin, Lakas Expires April 2001 [Page 4] Internet Draft COPS usage for Mobile IP (MIP) October 2000 so that it is aligned to the next 32-bit boundary before the object can be sent on the wire. The padding MUST be all-zero values. 2.3.1 Fixed-length Portion Object (FLO) for the Registration Request This object contains the fixed-length portion of the Registration request (24 octets). S-Num = 1, S-Type = 1, Fixed-length portion of the Registration request 2.3.2 Fixed-length Portion Object (FLO) for the Registration Reply This object contains the fixed-length portion of a registration reply (20 octets). S-Num = 1, S-Type = 3, Fixed-length portion of registration Reply 2.3.3 Extensions Object This object is used to carry a list of extensions extracted from the Mobile IP registration messages. The list includes non- authentication extensions and authentication extensions. S-Num = 2, S-Type = 1, (List of registration extensions) 0 1 2 3 +---------------+---------------+---------------+---------------+ | Length | S-Num = 2 | S-Type=1 | +---------------+---------------+---------------+---------------+ | List of Extensions ... | +---------------+---------------+---------------+---------------+ 2.3.4 Extension Specific Errors Object This object is used to indicate extension specific errors. S-Num = 3, S-Type = 1 (Registration message discarded) 0 1 2 3 +---------------+---------------+---------------+---------------+ | Length | S-Num = 3 | S-Type = 1 | +---------------+---------------+---------------+---------------+ When S-Type is equal to 1, the object indicates that the PDP has encountered an extension of type within the range 0-127 that it does not recognize. S-Num = 3, S-Type = 2 (List of extensions not recognized) Jaseemuddin, Lakas Expires April 2001 [Page 5] Internet Draft COPS usage for Mobile IP (MIP) October 2000 0 1 2 3 +---------------+---------------+---------------+---------------+ | Length | S-Num = 3 | S-Type = 2 | +---------------+---------------+---------------+---------------+ | List of extensions types ... | +---------------+---------------+---------------+---------------+ When S-Type is equal to 2, the object contains a list of extension types within the range 128-255 that the PDP has encountered but does not recognize. 2.3.5 Error Specific Data Object This object contains error specific information. It is used in decision objects. The S-Type field indicates the error code. The ESV (Error Specific Value) field, only required for some error types, carries error specific information. S-Num = 3, Error Specific Data 0 1 2 3 +---------------+---------------+---------------+---------------+ | Length | S-Num = 4 | S-Type | +---------------+---------------+---------------+---------------+ | ESV ... | +---------------+---------------+---------------+---------------+ This object is primarily used by the PDP to supply error code to PEP for the outgoing registration reply message. The PDP sends this object in a replacement data object (see section 2.5.1.) The S-Type field maps to the error code defined for the reply message. The error code values that are used in the S-Type are reproduced from [4] in the following: Registration denied by the foreign agent: S-Type = 64, reason unspecified (No ESV) S-Type = 65, administratively prohibited (No ESV) S-Type = 67, mobile node failed authentication (No ESV) S-Type = 68, home agent failed authentication (No ESV) S-Type = 69, requested Lifetime too long. New registration lifetime is provided in the ESV field Registration denied by the home agent: S-Type = 128, reason unspecified (No ESV) S-Type = 129, administratively prohibited (No ESV) S-Type = 131, mobile node failed authentication (No ESV) S-Type = 132, foreign agent failed authentication (No ESV) S-Type = 133, registration Identification mismatch. New value Jaseemuddin, Lakas Expires April 2001 [Page 6] Internet Draft COPS usage for Mobile IP (MIP) October 2000 for identification is provided in the ESV field S-Type = 135, too many simultaneous mobility bindings (No ESV) 2.4 Client Specific Information (ClientSI) Signaled ClientSI contains COPS-MIP objects defined in Section 2.3. 2.5 Decision Object The decision message contains replacement data and client specific decision data objects, which encapsulate COPS-MIP objects. Install, Remove and NULL decision commands are applicable for this usage. Install indicates a positive decision, and Remove a negative decision. The interpretation of Install and Remove commands is as the following: Context: Install Remove Incoming/outgoing message proceed with Abort the (Registration Request) the registration registration and send back a Reply Incoming/outgoing message proceed with Abort the (Registration Reply) the registration registration In case of denying the registration, the PDP may send within the decision error information to the PEP that it includes in its reply message. The trigger flag if set in the decision flags object, indicates to the PEP to generate a registration reply message with the error code supplied in the replacement data object that is discussed in section 2.5.1 2.5.1 Replacement Data object The Replacement Data object is used in decision messages to carry two types of COPS-MIP objects: Error Specific Data objects and Extension objects. The semantics of Replacement is either "insert" or "replace". The PDP may send replacement data to the PEP in order for the later to replace some or all of the data in the outgoing message; e.g., it provides new "lifetime" for the registration reply message in case of error. It may also supply extensions to be inserted in the outgoing message; e.g., it may provide a FA-HA authentication extension for the registration request. When the PEP receives a decision with an ESD as a replacement data, the S-Type indicates the data in the outgoing message that needs to be replaced. For example, code 63 indicates that the ESV denotes the Jaseemuddin, Lakas Expires April 2001 [Page 7] Internet Draft COPS usage for Mobile IP (MIP) October 2000 registration lifetime that should replace the original lifetime in the registration reply. The PDP may also send a FA-HA authentication extension as a replacement data to the FPEP responding to a decision request for an outgoing registration request. Since the extension is missing in the registration request, the FPEP appends it to the registration request before relaying it to the HA. 3. COPS-MIP Operations 3.1 Request (REQ) The PEP solicits policy decisions from the PDP for incoming and outgoing registration messages. When a mobility agent receives a registration request from an MN, the PEP encapsulates the data extracted from the message into COPS-MIP objects, and sends them as a ClientSI in a request to the PDP. The request MUST include the fixed-length portion of the registration message. It MUST include all the non-authentication extensions that mobility agent is required to process [2,4]. The extensions SHOULD be in the same order as they appeared in the registration message. The PEP MAY include the authentication extensions in the request. See section 4 for the details of handling authentication extensions. If the PDP does not recognize any extension of type whose value is within the range [0-127], it MUST NOT process the message and SHOULD respond with a NULL decision message that contains an Extension Specific Error with S-Type = 1. The PEP MAY make local decision, and if it does so, it MUST process all the extensions. If the PDP does not recognize any extension of type whose value is within the range [128-255], it ignores the unrecognized extensions, and MUST process the rest of the message. It MUST include in the decision message an Extension Specific Error object (S-Type=2) containing list of unrecognized extension types. In this case, the PEP MAY make local decisions for those extensions listed in the error object. Local decisions MUST NOT be in conflict with the decisions made by the PDP. The PEP SHOULD also include the IN-interface and OUT-interface, indicating the interface through which the registration message arrived and the interface through which the registration message would be relayed, respectively. := Jaseemuddin, Lakas Expires April 2001 [Page 8] Internet Draft COPS usage for Mobile IP (MIP) October 2000 := *[] [] Multiple context flags may be set in a single REQ message. When multiple flags are set, the Client SI objects are interpreted in all the contexts. 3.2 Decision (DEC) The PDP sends a solicited decision message in response to a registration request. The PDP sends policy decisions to notify the PEP whether it should proceed with the registration or abort it. Depending on the situation, the PDP may include MIP specific information in the decision message for the PEP to use while handling the registration. When the PDP requires the PEP to generate a registration reply message, it MUST set the trigger flag in the decision object. In the case of a positive decision, the PDP sends Install command to the PEP to proceed normally with the registration. For the FPEP, this means that the registration is accepted, and the FA is allowed to relay the registration request to the HA. The PDP may send authentication extensions in a replacement object for the PEP to insert in the outgoing registration request message. The PDP SHOULD NOT set the trigger flag when it sends an INSTALL decision to FPEP. If the trigger flag is set, then the HPEP SHOULD generate a positive Registration reply. When the registration is denied, the PDP sends a decision with a Remove command, and includes an ESD as a replacement data object for the PEP to insert in the registration reply message. For example, the ESD may contain a new Registration lifetime, if the lifetime in the registration request is longer than what is permissible. If the trigger flag is set for a Remove decision, the error code MUST be supplied in an error specific data object, which is encapsulated in the replacement data object. := * := [ | ] Jaseemuddin, Lakas Expires April 2001 [Page 9] Internet Draft COPS usage for Mobile IP (MIP) October 2000 Typically, the PDP responds with the same decision in all the contexts for which the decision is solicited. Hence, it can set multiple context flags in a decision message. In this case additional data provided with the decision are interpreted under all the contexts. If decisions for different contexts contain separate additional data, then the decisions MUST be sent in separate contexts. 3.3 Delete Request State (DRQ) Typically, the PEP sends DRQ to the PDP when the mobility agent receives a deregistration request from MN. The COPS-MIP client SHOULD send DRQ to PDP before deleting a pending Registration Request and sending out Registration Reply with Error. 3.4 Report (RPT) The COPS-MIP responds to the PDP decisions with COPS specified reports. 4. Handling MIP authentication extensions If the PDP is delegated to perform authentication, the PEP MUST send the FLO for the registration message followed by an extension object, all encapsulated in a client SI object. The extension object MUST contain all extensions including the authentication extension that the PDP is required to process, in the order they appear in the message. See section 3.5 in [4] for the ordering and processing requirements of authentication extensions, and [5] for AAA requirements. If an authentication fails, the PDP is required to include the appropriate authentication failure code in the decision message. 5. Foreign Agent Consideration The FA performs validity checks on the registration message before soliciting any decision from the PDP for that message. The FPEP solicits decisions from the PDP for incoming Registration Request messages using the combined context . It sends all the FA related non-authentication extensions in the Registration Request to the PDP. It also sends those HA related non- authentication extensions to the PDP that are used in FPDP decision. If it receives in a PDP decision any HA related non-authentication extensions, it inserts them into the Registration Request before relaying the message to the HA. Although typically the PDP sends a single decision in the combined context, it may send different optional decision objects using different contexts. Hence, the FA should solicit decision in both contexts. For example, if the PDP is playing the role of the authentication authority, then it sends decisions with FA-HA authentication extension in the outgoing context only. Jaseemuddin, Lakas Expires April 2001 [Page 10] Internet Draft COPS usage for Mobile IP (MIP) October 2000 In a COPS request for Registration Reply, the FA sends all the FA related non-authentication extensions to the PDP. If it receives any MN related non-authentication extension in a PDP decision, it inserts them into the Registration Reply before relaying the message to the MN. When the FA receives a Registration Reply from the HA with zero lifetime, it sends DRQ to the PDP to delete the request state(s) installed for that registration. 6. Home Agent Consideration When a HA receives a Registration Request, it solicits decisions using Incoming context. It sends all the non-authentication extensions from the Registration Request to the PDP. If the PDP replies with a decision that includes any FA or MN related non- authentication extension, the HPEP inserts them into the Registration Reply before sending it out. The PDP sets the trigger flag in the decision flags object of its response to the HPEP in order for the later to send the Registration reply. If the decision command is INSTALL, then it indicates that the HPEP should send out a Registry Reply message accepting the request. Otherwise, if the decision is REMOVE then the HPEP returns a negative Registration Reply message with the error code. If HA has installed a single request state in PDP corresponding to a mobility binding, then it should send DRQ to PDP to delete the request state before deleting the mobility binding from its mobility-binding list. 7. COPS State Consideration The PEP can create one state per mobility binding. Therefore, the PEP should use the same handle in its request messages to the PDP for the registration requests and replies related to the same binding. When a mobility binding is removed from the binding list, the PEP should delete the corresponding state. Thus, only one state per binding is maintained. In case of simultaneous bindings, the HPEP creates as many states as the number of simultaneous bindings. 8. Applicability/Optimization The Mobile IP registration process should keep the registration latency low, to minimize the effects of packet drops belonging to IP sessions between MN and CNs that are active during the registration time. The PEP-PDP interaction may contribute significantly to the overall registration latency. Therefore, the PEP should reduce the amount of interactions with the PDP. This warrants fewer decisions solicited by the PEP, and less number of installed states. - The PEP should try to cache decisions and policies locally and make local decisions whenever possible. As long as local decisions are effectively driven by the global policies, there is no real need to seek their validations from PDP. For example, local decisions based on configuration need no validation from the PDP. Jaseemuddin, Lakas Expires April 2001 [Page 11] Internet Draft COPS usage for Mobile IP (MIP) October 2000 - When a mobile sends a registration request to refresh registration after the lifetime of the previous registration request expires, the HPEP can use locally cached decisions to handle the registration. However, if the PDP is delegated to perform authentication, then the PEP is required to solicit decisions even for refresh registration messages. - Likewise, the FA can use locally cached decisions to handle refresh registration requests and replies, as long as the FPDP does not perform authentication. 9. IANA Considerations The S-Type values for the Error Specific Data Object (S-Num = 4) defined in section 2.3.5 are error codes taken from [4]. The extension types used in the Extension List Object defined in section 2.3.4 are values defined in [4]. 10. Security Considerations This document introduces no new security concerns other than those discussed in [1] and [2,4]. It relies on COPS for the integrity of messages and security between PEP and PDP. The mobility agent should follow the security guidelines provided in Section 5 of [2,4]. 11. References [1] Boyle, J. et al, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [2] C. Perkins, "IP Mobility Support for IPv4. RFC 2002, Internet Engineering Task Force, October 1996. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] C. Perkins, "IP Mobility Support for IPv4. Internet Draft, draft-ietf-mobileip-rfc2002-bis-02.txt, September 2000. [5] S. Glass, et al, "Mobile IP Authentication, Authorization, and Accounting Requirements", draft-ietf-mobileip-aaa-reqs-04.txt, June 2000. 12. Acknowledgments The authors would like to thank Bill Gage (Nortel Networks) for his valuable feedback. Jaseemuddin, Lakas Expires April 2001 [Page 12] Internet Draft COPS usage for Mobile IP (MIP) October 2000 13. Author's Addresses Muhammad Jaseemuddin Nortel Networks 100 Constellation Crescent, Nepean, ON K2G 6J8, Canada Phone: 613-765-7520 Email: jaseem@nortelnetworks.com Abderrahmane Lakas Nortel Networks 100 Constellation Crescent, Nepean, ON K2G 6J8, Canada Phone: 613-763-6373 Email: alakas@nortelnetworks.com Jaseemuddin, Lakas Expires April 2001 [Page 13] Internet Draft COPS usage for Mobile IP (MIP) October 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Jaseemuddin, Lakas Expires April 2001 [Page 14]