INTERNET DRAFT G. Dommety Category: Informational Cisco Systems Title: draft-ietf-aaa-mobile-ip-req-00.txt S. Glass April 1999 Nokia Telecommunications T.Hiller Lucent S. Jacobs GTE Laboratories B. Patil Nortelnetworks C. Perkins Sun Microsystems Mobile IP Authentication, Authorization, and Accounting Requirements draft-ietf-aaa-mobile-ip-req-00.txt 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. This document is a submission by the AAA Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the aaa-wg@merit.edu mailing list. Distribution of this memo is unlimited. Abstract The AAA Working Group is currently looking at defining the requirements for Authentication and Authorization. This document contains the requirements which would have to be supported within AAA to aid in providing Mobile IP services. Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 1] Internet Draft Mobile IP AAA Requirements 25 June 1999 Contents Abstract.......................................................... 1 1.0 Introduction ............................................. 2 1.1 Background ............................................... 2 1.2 Terminology .............................................. x 2.0 Mobile IP Utilization of AAA...............................x 2.1 Brokerage with apriori contract arrangements ............. x 2.2 Opportunistic with dynamic/on-the-fly contracting ........ x 2.3 Third party (i.e. pre-paid and/or Credit Service) ........ x 3.0 Mobile IP AAA Requirements ............................... x 3.1 Authentication Requirements .............................. x 3.2 Authorization Requirements ............................... x 3.3 Accounting Requirements .................................. x 4.0 Future Considerations ("in the spirit of Mobile IP").......x 5.0 Security Considerations................................... x A.0 Mobile IP Deployment Types and Overview................... x A.1 Mobile IPv4................................................x A.2 Mobile IPv6................................................x References........................................................ x Authors' Address.................................................. x 1. Introduction 1.1 Background Customers obtain internet services by being provided a point of attachment to a "home domain", generally from an ISP, or other organization from which service requests are made, and fulfilled. With the increasing popularity of mobile devices, a need has been generated to allow users to attach to any domain convenient to their current location. In this way, a customer needs access to resources being provided by an administrative domain different than their home domain (called a "foreign domain"). In no specific order, the need for service from a foreign domain requires, in many models, accounting, which leads directly to authorization, and of course authentication. (Note: there is some argument which of these leads to, and is derived from the others, but there is common agreement that all are needed, and in general simultaneously). An agent in a foreign domain, being called on to provide access to a resource by a mobile user (a.k.a. the customer), is likely to request, if not require, the customer provide credentials which can be authenticated before access to resources are permitted. These resources may be as simple as a conduit back to the customer's home domain, or may be as complex as access to specific private resources within the foreign domain. These credentials can be exchanged in many different ways, all of which are beyond the scope of this document, however the need for this transaction is recognized, and the ability for the foreign domain to authenticate the mobile user Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 2] Internet Draft Mobile IP AAA Requirements 25 June 1999 is necessary in order for the user to be allowed access. Once the mobile user is authenticated, services within the foreign domain it is authorized to access, as well as an account of the actual resources used can be assembled. Mobile IP is a technology that allows a network node ("host computer") to migrate from its "home" network to other networks, either within the same administrative domain, or to other administrative domains. This document will identify, describe, and discuss the functional and performance requirements for Mobile IP in the areas of Authentication, Authorization, and Accounting. The formal description of Mobile IP can be found in [RFC2002], and its supporting documents [RFC2003], [RFC2004], [RFC2005], [RFC2006], and [RFC2290]. A very basic overview of the extent of the Mobile IP protocol is given in appendix A, and is provided for motivation only. 1.2. Terminology This document frequently uses the following terms: Accounting The act of collecting information on resource usage for the purpose of trend analysis, auditing, billing, or cost allocation. Agent Advertisement An advertisement message constructed by attaching a special "mobility extension" to the standard RFC1256 router advertisement message. Authentication The act of verifying the identity of an entity (subject). Authorization The act of determining whether a requesting entity (subject) will be allowed access to a resource (object). Billing The act of preparing an invoice. Care-of Address The termination point of a tunnel toward a mobile node, for datagrams forwarded to the mobile node while it is away from home. The protocol can use two different types of care-of address: A "foreign agent care-of address" is an address of a foreign agent with which the mobile node is registered, and a "co-located care-of address" is an externally obtained local address which the mobile node has associated with one of its own network interfaces. Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 3] Internet Draft Mobile IP AAA Requirements 25 June 1999 Correspondent Node A peer with which a mobile node is communicating. A correspondent node may be either mobile or stationary. Foreign Agent A router on a mobile node's visited network which provides routing services to the mobile node while registered. The foreign agent detunnels and delivers datagrams to the mobile node that were tunneled by the mobile node's home agent. For datagrams sent by a mobile node, the foreign agent may serve as a default router for registered mobile nodes. Foreign Network Any network other than the mobile node's Home Network. Home Address An IP address that is assigned for an extended period of time to a mobile node. It remains unchanged regardless of where the node is attached to the Internet. Home Agent A router on a mobile node's home network which, when the mobile node is away from home, receives traffic for the mobile node, tunnels these datagrams for delivery to the mobile node, and maintains current location information for the mobile node. Home Network A network having a network prefix matching that of a mobile node's home address. Note that standard IP routing mechanisms will deliver datagrams destined to a mobile node's Home Address to the mobile node's Home Network. Inter-domain Accounting Inter-domain accounting is the collection of information on resource usage of an entity with an administrative domain, for use within another administrative domain. In inter-domain accounting, accounting packets and session records will typically cross administrative boundaries. Intra-domain Accounting Intra-domain accounting is the collection of information on resource within an administrative domain, for use within that domain. In intra-domain accounting, accounting packets and session records typically do not cross administrative boundaries. Link A facility or medium over which nodes can communicate at the link layer. A link underlies the network layer. Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 4] Internet Draft Mobile IP AAA Requirements 25 June 1999 Link-Layer Address The address used to identify an endpoint of some communication over a physical link. Typically, the Link-Layer address is an interface's Media Access Control (MAC) address. Mobile Node A host that changes its point of attachment from one network or subnetwork to another. A mobile node may change its location without changing its IP address; it may continue to communicate with other Internet nodes at any location using its home IP address, assuming link-layer connectivity to a point of attachment is available, and either foreign agent, or colocation authorization is available. Mobility Agent Either a Home Agent or a Foreign Agent. Mobility Binding The association of a home address with a care-of address, along with the remaining lifetime of that association. Node A host or a router. Real-time Accounting Real-time accounting involves the processing of information on resource usage within a defined time window. Time constraints are typically imposed in order to limit financial risk. Session record A session record represents a summary of the resource consumption of a user over the entire session. Accounting gateways creating the session record may do so by processing interim accounting events. Tunnel The path followed by a datagram while it is encapsulated. The model is that, while it is encapsulated, a datagram is routed to a knowledgeable decapsulating node, which decapsulates the datagram and then correctly delivers it to its ultimate destination. Visited Network A network other than a mobile node's Home Network, to which the mobile node is currently connected. 1.3. Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119]. Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 5] Internet Draft Mobile IP AAA Requirements 25 June 1999 2.0 Mobile IP Utilization of AAA Mobile IP is dependent on authentication between the mobile node, and its home agent. Moreover, there are modes for authentication between mobile-node and foreign domain, as well as authentication between home domain and foreign domain. There are no authentication modes specific to Mobile IP between mobile node and correspondent node as, to the correspondent, the mobile node is on its home network (this does not preclude the use of any other security type as an enhancement to Mobile IP, such as IPSec, however). In the most general sense, the latter two Mobile IP authentication modes place a demand on the ability for a node in one domain to authenticate a node from another domain for a specific service, perhaps attaching (agreed-on) fee(s) for specific service(s). This can be accomplished in (essentially) two ways: with a pre-existing service agreement between two administrative domains, or by negotiating a service agreement "on-the-fly", possibly with a trusted third party (a.k.a "brokerage"). Each of these topologies is described below. 2.1. Pre-existing Contract Arrangements (Home-Foreign agreement) In some circumstances, there may be an agreement in place before the mobile node joins the foreign domain. This may be in the form of either "bill-before-service", or "service-before-bill" agreement. Note that services and rates are agreed on before hand in both cases, but in the former case the general model is payment is made after service is provided (e.g. home phone service model), and in the later case payment is made before service (e.g. pre-paid phone card model). 2.1.1 Existing 2-party handshake In many circumstances, the mobile user (aka customer) will know which services they need, or are likely to need, from a specific administrative domain before actually visiting it. In this circumstance a service agreement between the two administrative domains may be put in place before the mobile node joins the foreign domain. In this way perhaps the mobile node's credentials, or some way to authenticate them, are at the foreign domain before the mobile node arrives. Similarly, the mobile node may bring with it the foreign domain's credentials, or some way to authenticate them. Services the mobile node requires, has access to, and whatever the billing requirements are for (each) such service may have also been worked out in advanced. In addition, it is likely home and foreign domains have already been authenticated to one another, but a confirmation when service begins MUST be made. 2.1.2 Third party (i.e. pre-paid and/or Credit Service) Contract This category can be broken into a few smaller ones. There's Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 6] Internet Draft Mobile IP AAA Requirements 25 June 1999 the dial-in notion where you plug-in somewhere either directly, or connect via PPP and get Mobile IP service. There's an additional concept of going in to a cyber cafe (or a 7-11) and getting a "pre-paid network card" which you insert into your laptop. At this time Mobile IP registration takes place; perhaps the card shares an authentication to the visited domain (which is the card's home domain) to make sure it's not pirated. The mobile node authenticates itself to its home domain as usual, and if needed, any authentication between the home and foreign domains is resolved as well. 2.1.3 Ramifications for Requirements From the above scenarios we can identify the following requirements: - There MUST be a way for the foreign domain to authenticate the credentials of the mobile node. Either it has the ability to authenticate the credentials itself, or it has the ability to securely contact an authentication authority and have the credentials verified on its behalf. How the local authentication authority does this is beyond the scope of this document, however there MUST NOT be a requirement that the mobile node be in contact with its home domain prior to authenticating itself to the foreign domain (as in a requirement that the mobile node boot at home prior to roaming). - There MUST be a way for the mobile node to authenticate the credentials of the foreign domain. This need not necessarily be before the foreign domain verifies its credentials, and so may be done in cooperation with its home domain. There is an implication in the registration process of Mobile IP that the mobile node verifies itself to the foreign domain before the foreign domain is verified by the mobile node. Whatever the AAA solution, there MUST NOT be a "chicken and egg" problem. - There MUST be a way for the home domain and the foreign domain to mutually authenticate each other. There is an implication in the registration process of Mobile IP that the foreign domain verifies itself to the home domain before the home domain replies, and verifies itself to the foreign domain. Whatever the AAA solution, there MUST NOT be a "chicken and egg" problem. - There must be a way for the foreign domain to be notified of new credentials, either before a mobile node connects to the foreign domain, or while it is connected and receiving service. Depending on the new credentials this may or may-not require a challenge-request from the foreign domain to the registered mobile node. Such speculation is beyond the scope of this document, though any AAA protocol should not preclude this requirement. - If the foreign agents and foreign-domain authentication authorities are different machines then they MUST share a security Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 7] Internet Draft Mobile IP AAA Requirements 25 June 1999 relationship. - There MUST be a way for the foreign agent to "keep state" for pending credential requests while the authentication authority is examining the mobile node's credentials. - The authentication solution must be scalable. Essentially an unlimited number of mobile nodes may be registering with the same foreign agent simultaneously. - Since the mobile node is not likely to get service until its credentials are checked, it MUST be able to provide complete, yet unforgeable credentials without the need to interact with its home domain. - Since the credentials must remain unforgeable, any intervening node MUST NOT be able to learn any (secret) information which may enable it to reconstruct the credentials. - There MUST be a mechanism in the authentication process to guard against replay attacks. 2.2. Dynamic/on-the-fly contracting, the Broker model 2.2.1 Negotiation Topology While the scenarios described above work for a limited number of administrative domains providing service for, or receiving service from, a limited number of administrative domains, it is likely to not be possible for every administrative domain to have service contracts with every other administrative domain. Ideally, then, there needs to be a mechanism in place for "on the fly" negotiations. This document recognizes the fact that there are non-negotiable items related to authentication which are based on site policies, and are likely to be inflexible. Accounting, and authorization, on the other hand, may provide some areas where negotiation between home and foreign administrative domains can take place. As an example, in the single-negotiation scenario, a mobile node, who's home is DOMAIN-A connects to DOMAIN-B with which DOMAIN-A does not already have a service agreement. There may be overlap between the two ISPs authorization and accounting requirements allowing for a service connection. For example, DOMAIN-B may wish to charge the mobile node $20.00 for the connection. If DOMAIN-A (or the MN user) is willing to pay it, then the MN can be granted the authority to use at least the minimal set of Mobile IP services. If DOMAIN-B is willing, other services may also be authorized, such as reverse tunneling, and such a negotiation may also be performed. It's important to note that, if there needs to be a negotiation for Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 08] Internet Draft Mobile IP AAA Requirements 25 June 1999 authorization to certain services, those parameters which are required by all parties for Mobile IP functionality on the visited network SHOULD be negotiated first. That is, in the above example, if reverse tunneling is considered a requirement by the mobile node, then reverse tunnelling MUST be agreed to before billing begins. The same is true if the foreign domain is requiring reverse tunnelling, but the home domain is unwilling to use it. If one party has explicitly demanded a parameter as a requirement, but the other party is unable to provide/accept it, then there is no mid-ground, and (this instance of) on-the-fly contracting has failed. Motivated by this, we propose the ability for a foreign agent to inform a AAA server what services are going to need to be authorized for a specific mobile node, so an authorization decision can be made before registrations are forwarded to the home network. If a AAA server deems the requested combination is not possible, a foreign agent SHOULD return error 65, "administratively prohibited", to the mobile node and await another (modified) registration request. The foreign agent may alter its agent advertisements to the network however it sees fit. We believe it's likely a foreign agent will be advertising in accordance with the policies configured on its AAA server, but the resolution of services these beacons are advertising is likely a superset of all services offered (as per [2002], but NOT necessarily what every mobile node will be authorized to use. 2.2.2 Ramifications for Requirements From the above scenarios we can identify the following requirements in addition to those identified in section 2.1.3 above. - Allowing negotiation of service terms by way of a brokerage model SHOULD be allowed. - AAA MUST recognize that each administrative domain will provide different capabilities (likely a subset of choice of manufacturer, and local policy), and hence service parameters will vary from administrative domain to administrative domain. There MUST be a way for the domains to negotiate a minimal set of service requirements they deem necessary for service. There need not be any guarantee all identified services, or access to them, is available, however. In analogy, there MUST be a way for the home domain to inform the foreign domain which services it deems necessary for communication with the mobile node. - There MUST be a way for the foreign domain and home domains to verify message integrity even though the messages have passed through an intermediate negotiator. Note: the negotiator may be a trusted third-party, or exist in part within multiple domains (such as between brokers in the home and foreign domains). When such negotiations include the mobile node, it MUST be able to verify the integrity of the messages as well. Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 9] Internet Draft Mobile IP AAA Requirements 25 June 1999 3.0 Mobile IP requirements on AAA Based on the above scenarios, and the topology of Mobile IP itself, the following breakdown of requirement for AAA from Mobile IP can be ascertained. We repeat, and add to, all the requirements stated in section 2 above, unionizing when necessary, for completeness. Since Mobile IP provides no distinction between these categories, if AAA requires a policy demanding only one set of services, a restriction on Mobile IP functionality may result. Some administrative policies may demand some restrictions on their networks, but the AAA protocol MUST NOT explicitly make any restrictions. 3.1 Authentication - There MUST be a way for the foreign domain to authenticate the credentials of the mobile node. Either it has the ability to authenticate the credentials itself, or it has the ability to securely contact an authentication authority and have the credentials verified on its behalf. How the local authentication authority does this is beyond the scope of this document. - There MUST be a way for the mobile node to authenticate the credentials of the foreign domain. This need not necessarily be before the foreign domain verifies its credentials, and so may be done in cooperation with its home domain. There is an implication in the registration process of Mobile IP that the mobile node verifies itself to the foreign domain before the foreign domain is verified by the mobile node. Whatever the AAA solution, there MUST NOT be a "chicken and egg" problem. - There MUST be a way for the home domain and the foreign domain to mutually authenticate each other. There is an implication in the registration process of Mobile IP that the foreign domain verifies itself to the home domain before the home domain replies, and verifies itself to the foreign domain. Whatever the AAA solution, there MUST NOT be a "chicken and egg" problem. - AAA authentication support for Mobile IP MUST either be able to be supported by the mobility agents, or the Mobility Agents MUST have a way of obtaining the information they require from a AAA server in a timely fashion. Based on requirements from [2002], this is on the order of less-than 1 sec between request and final response. - Challenge authentications MUST also be supported, though are not as time-critical, and are likely to need to be performed within the resolution of the billing, specifically hourly, 1/2 hourly, 1/4 hourly, every 6 minutes (1/10 of an hour), or maybe as often as once per minute. Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 10] Internet Draft Mobile IP AAA Requirements 25 June 1999 - There must be a way for the foreign agent to "keep state" for pending credential requests while the authentication authority is examining the mobile node's credentials. - The authentication solution must be scalable. The AAA protocol MUST be able to handle unlimited number of authentications as the number of mobile nodes registering with the same foreign agent can be unbounded, as can the number of simultaneous registration attempts. The AAA protocol MUST be able to handle mobility agents providing Mobile IP services to an unlimited number of mobile nodes. - Since the mobile node is not likely to get service until its credentials are checked, it MUST be able to provide complete, yet unforgeable credentials without the need to interact with its home domain. - Since the mobile node's credentials must remain unforgeable, any intervening node must not be able to learn any (secret) information which may enable it to reconstruct the credentials. - There MUST be a mechanism in the authentication process to guard against replay attacks. This mechanism need not be hidden from a snooper, but it must prevent the snooper from successful replay. - There MUST be a way for the foreign domain and home domains to verify message integrity when the messages have passed through an intermediate negotiator. Note: the negotiator may be a trusted third-party, or exist in part within multiple domains (such as negotiation between brokers in the home and foreign domains). When such negotiations include the mobile node, it MUST be able to verify the integrity of the messages as well (as part of the home domain). - AAA MUST NOT place additional constraints on the re-registration of a mobile node with its current home agent. - AAA MUST NOT place the constraint that a mobile node be required to re-register with the same home agent. 3.2 Authorization Mobile IP considers several different resource categories available to the mobile node, but does not differentiate between them. Since Mobile IP provides no distinction between these categories, if AAA were to require a policy demanding only a subset of these resources, a restriction on Mobile IP functionality may result. Some administration domain policies may prohibit authorization to a selection of these, but the AAA protocol itself MUST NOT make any restrictions. Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 11] Internet Draft Mobile IP AAA Requirements 25 June 1999 AAA MUST provide an authorization mechanism for the mobile node to any of the following services for which it is controlling access: - link access to the visited network - router advertisement messages, possibly received in response to solicitations (to either the all subnet broadcast address 255.255.255.255, or the all mobile-agent address 224.0.0.11), or by "snooping" network traffic sent to either the all subnet broadcast address, 255.255.255.255, or the all host IGMP multicast address 224.0.0.1 - potential access to a topologically routable address for the visited subnet (such as that obtained via DHCP, PPP, etc.). AAA MUST provide an authorization mechanism for the foreign agent to provide these services for a visiting mobile node: - foreign agent care-of address service - The ability for the foreign agent to receive tunneled datagrams for the mobile node - The ability for the foreign agent to act as a first-hop router for the mobile node - foreign agent packet decapsulation service - IP-in-IP decapsulation is a required service. - Minimal Encapsulation decapsulation MAY be provided. - GRE decapsulation MAY be provided - foreign agent packet encapsulation (reverse tunnelling) - IP-in-IP encapsulation is required - Minimal Encapsulation encapsulation may be provided - GRE encapsulation may be provided AAA MUST provide an authorization mechanism for the home agent to provide these services for a mobile node visiting another subnet: - the ability to gratuitous ARP, thereby updating the ARP caches of the machines normally one-hop away from the mobile node, and claiming its IP address on the home link. - home agent encapsulation service MUST be provided IP-in-IP encapsulation is required. Minimal Encapsulation encapsulation MAY be provided. GRE encapsulation MAY be provided. - home agent packet decapsulation (reverse tunnelling) - IP-in-IP decapsulation is required - Minimal Encapsulation decapsulation may be provided - GRE decapsulation may be provided. Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 12] Internet Draft Mobile IP AAA Requirements 25 June 1999 The ability for the home agent to then forward the decapsulated datagrams to the network. AAA MUST recognize that each administrative domain will provide different capabilities (likely a subset of choice of manufacturer, and local policy), and hence service parameters will vary from administrative domain to administrative domain. There MUST be a way for the domains to negotiate a minimal set of service requirements they deem necessary for service. There need not be any guarantee all identified services, or access to them, is available, however. In analogy, there MUST be a way for the home domain to inform the foreign domain which services it deems necessary for communication with the mobile node. If any part of the registration process (such as replay protection) is going to involve the AAA servers, access to a real-time clock MUST be authorized. Note that Mobile IP by itself does not require a mobile node and home agent clocks be accurate (just synchronized). 3.3 Accounting There are few accounting considerations within Mobile IP itself. This is primarily due to the fact that Mobile IP considers machine-roaming, and not user-roaming. In any event, we recognize the need for accounting reliability. Accounting information should be authenticatable (to aid in reconciliation). Regardless of the authentication and authorization mechanisms, accounting information SHOULD be available to the domains before registration is finalized. Moreover their SHOULD be a way for any entity running accounting software (mobile nodes and mobility agents) to get a usage summary accurate to within the billing break-down (e.g. hour, 1/2 hour, 1/4 hour, 1/10 hour, minute, etc). The accounting break-down should be itemized to the resolution of the individual service being charged for. For example, basic care-of address, and reverse- -tunnelling services as separate items. Moreover, accounting MUST be able to be broken down to individual authorizations for individual mobile nodes. The local administrative domain may not require such granularity, but AAA MUST NOT prohibit it. It was thought as [RFC2002] was growing that perhaps administrators on foreign domains may want to charge mobile nodes for the service of receiving its data on their subnet. It is possible, where foreign agents have mandated the registration request pass through them, (and/or potentially when no co-location is possible), to tabulate bandwidth on a per-packet, or byte-sum basis, the data being delivered to the mobile node. While this was the "spirit" at the time, no Mobile IP mechanisms were specified to this regard in any of the Mobile IP documents. It is therefore beyond the scope of this document to place any requirements on AAA to do so, but it is believed to be entirely within the scope of AAA to do so. Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 13] Internet Draft Mobile IP AAA Requirements 25 June 1999 3.4 General Requirements - Allowing negotiation of service terms by way of a brokerage model SHOULD be allowed. 4.0 Future Considerations ("in the spirit of Mobile IP") ### I thought this would be something to put the finishing touches on ### the philosophical MIP approach to AAA. Anyone? 5.0 Security Considerations This is a requirements draft for AAA based on Mobile IP. As AAA is security driven, most of this document addresses the security considerations AAA MUST make on behalf of Mobile IP. It is beyond the scope of this document to make any conjectures on the usefulness, or problems which may result from using AAA with Mobile IP. It is, however, entirely within the scope of the AAA protocol to do so. Appendix A - Mobile IP Deployment Types and Overview A.1 Mobile IP - service basics As a first effort to capture the AAA requirements regarding Mobile IP, this document initially considers Mobile IP for IP version 4. In the future Mobile IP for IP version 6 will be incorporated. To understand the requirements Mobile IP places on AAA, a quick presentation of the Mobile IP topology may be helpful. AAA MUST support all possible Mobile IP implementations so as not to reduce the functional support of the Mobile IP protocol. This is not an extensive exploration of the Mobile IP core, and related protocols. The reader is advised to be familiar with the Mobile IP protocols. This section is included for motivation only. A.1.2 The Mobile Node Mobile IP requires a way for the mobile node to establish a link- connection to the foreign subnet. Once this has been achieved, there MUST be a way for the mobile node to passively detect it has moved. This is generally achieved by listening for agent advertisements beaconed by mobility agents. Alternatively, a mobile node may send router solicitations on any of it's links in order to receive the advertisements. When a mobile node receives an advertisement, it determines if this link has changed its point of attachment based on configuration elements such as home subnet prefix, and subnet information contained in the beacons. Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 14] Internet Draft Mobile IP AAA Requirements 25 June 1999 If the mobile node has changed its point of attachment, and it is not on its home subnet, it MUST get a care-of address to use on the visited subnet. While foreign agents in general provide a local care-of address, and decapsulation services for mobile nodes, there is no requirement that a foreign agent MUST be the care-of address for a visiting mobile node, and therefore there is no requirement that a foreign agent MUST provide decapsulation services to a mobile node. A mobile node MAY get a locally routeable address via any dynamic address assignment protocol (such as DHCP, PPP, etc) to use as a care-of address. Regardless of where the local care-of address is physically located, the MN formulates a registration request which MUST always include replay protection, and an extension authenticatable by a home agent on the mobile node's home link. This authenticatable registration request is either directed at the home subnet of the mobile node (if the mobile node has obtained a local care-of address), or at the link address of one of the beaconing foreign agents for forwarding to the mobile node's home subnet. In addition, a beconning foreign agent MAY require the mobile node always pass registration requests through it. If the mobile node is passing the registration request through a foreign agent, the mobile node MAY also make the registration request authenticatable to the foreign agent via a separate extension in the registration request. Note: the mobile node need NOT have an assigned home agent. There is a mechanism in [2002] which describes a home-agent discovery. Also, the mobile node also need NOT have an assigned home address. There are mechanisms being devised to provide a mobile node an assigned home address dynamically from the home subnet at the time of registration. AAA MUST NOT rely on the mobile node having a valid IP address at any time before registration is complete. An authenticatable registration reply from a home agent, sent via the care-of address the mobile node is using, should return shortly. If not, the mobile node is only allowed to attempt to register at most once-per-second. The reply from a home agent will either indicate acceptance, or denial with a suitable error code. The mobile node may then adapt its next registration request accordingly, and reregister. Each registration request and reply is either timestamped, or identified by a unique (to each MN-HA "registration-session") nonce so as to protect against replay attacks. It is the responsibility of the mobile node to reregister in a timely enough fashion as to avoid any lapse in service. While away from its home subnet, a mobile node MUST use its care-of address as its first hop. If the care-of address the mobile node is using belongs to a foreign agent, the foreign agent becomes its first hop router for delivery of all datagrams. If the mobile node is using a colocated care-of address, all datagrams must emanate from the care-of address as if being routed by it, that is the Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 15] Internet Draft Mobile IP AAA Requirements 25 June 1999 care-of address MUST NOT be the source address of the datagram. In this case the mobile node continues to use its home address as the care-of address. If, upon receiving an agent advertisement, the mobile node determines it has changed its point of attachment, and it is now on its home subnet, a special form of the registration request is sent, namely a deregistration request. This notifies the home agent that the mobile node has returned to the home subnet. A gratuitous ARP then needs to be sent by the mobile node to update the ARP-caches of nodes on the home subnet. A.1.3 The Mobility Agent Mobility agents MUST advertise their presence on a link. This is done by appending a "mobility extension" on to an RFC1256 router advertisement. It is common practice for a mobility agent to also append subnet information as well onto the same enhanced router advertisement to aid the mobile node in move detection. These beacons are not allowed to be sent at a rate of more than once-per-second, and must also be sent to either the all-subnet broadcast address, 255.255.255.255, or the all-host IGMP multicast address, 224.0.0.1. The mobility agent must also respond to router solicitation messages sent to either the all-subnet broadcast address, or the all-mobility-agents multicast address 224.0.0.14, by unicasting the same mobility-extension enhanced router advertisement to the requesting node. A.1.3.1 The Foreign agent In addition to the above, foreign agents provide local care-of addresses, and decapsulation services for mobile nodes. There is no requirement that a foreign agent be the care-of address for a visiting mobile node, however, and therefore there is no requirement that a foreign agent provide decapsulation services for a mobile node. As described above, in this case the mobile node must either find another foreign agent willing to decapsulate packets for it, or must find a suitable address to co-locate with. In general practice, however, all foreign agents have the capability to decapsulate packets for visiting mobile nodes, though may be busy due to resources allocated for visiting mobile nodes already registered with them. If the mobile node wishes a foreign agent to serve as the tunnel decapsulation point for it, the foreign agent will receive a registration packet from the mobile node with information destined for the mobile node's home subnet. The registration request MAY also contain a extension authenticating the mobile node to the foreign agent. If the registration request is acceptable, the foreign agent must enter the mobile node's link-layer address in its ARP cache, and the mobile node's home address and requested Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 16] Internet Draft Mobile IP AAA Requirements 25 June 1999 binding lifetime into its visitor's list. The foreign agent should also remember the mobile node's Home Agent address at this time, if supplied. The registration request is then sent verbatim (less any FA authenticator consumed by the foreign agent) to the home subnet identified in the registration request. An extension authenticating the foreign agent to the home agent MAY be attached. If a registration reply does not arrive, the foreign agent is not responsible for retransmitting the registration request. When the foreign agent receives a registration reply, it may contain an extension authenticating the home agent to the foreign agent. The foreign agent should verify the mobile node's home address in the reply exists in its visitor's list, and forward it to the mobile nodes link-layer address contained in its ARP-cache. It must also take note of whether the registration was denied, in which case it may clean up the resources it dedicated to this mobile node, or whether the registration was approved, and if so for how long (and not longer than the FA originally granted). The foreign agent MUST provide the decapsulating service it promised for at least this period. It is the responsibility of the visiting mobile node to renew this registration if it wishes to continues using this foreign agent beyond the granted lifetime. A.1.3.2 The Home Agent Home agents advertise their presence in exactly the same fashion as foreign agents. This is done so a mobile node will know when it has returned home without any special "home-detection" mechanism. Home agents will also receive authenticatable registration requests from "their" mobile nodes which are visiting foreign subnets. The Home Agent must analyze these registration requests, and respond accordingly with an authenticatable registration reply in a reasonable amount of time. In case of denial, a corresponding error code must be returned. In case of approval, it must also include the lifetime which it is willing to act on behalf of the mobile node, not greater than that in the registration request. In addition, the home agent must send a gratuitous ARP on the mobile node's home link identifying the mobile node's home IP address, and its own link-layer address on this interface in order to update the ARP-table entries of nodes on this subnet. In either case an authenticatable registration reply must be sent by the home agent to the care-of address identified in the registration request sent by the mobile node. This registration reply MAY include authentication for the foreign agent servicing the mobile node. When the home agent is acting on behalf of the mobile node, it will receive datagrams on the interface located on the mobile node's home link sent to the mobile node's home IP address, but to its own link-layer address. When this happens, the home agent will encapsulate the datagram using it's address as the source address, and the mobile node's care-of address as the destination, and send Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 17] Internet Draft Mobile IP AAA Requirements 25 June 1999 them to the mobile node's care-of address. Encapsulation can be done in any one of several ways. If the mobile node has requested broadcast and multicast forwarding, the home agent multiply encapsulates these datagrams, first with the mobile node's home address, then with the care-of address being used by the mobile node. The home agent must act on behalf of the mobile node for at least the lifetime it approved in the last registration reply it sent to the care-of address of the mobile node. It is the responsibility of the mobile node to reregister if it will be away from the home network beyond this time. A.2 Mobile IPv6 Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 18] Internet Draft Mobile IP AAA Requirements 25 June 1999 References [RFC1256] Deering, S., editor, "ICMP Router Discovery Messages", September 1991. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", April 1992. [RFC1541] Droms, R., editor, "Dynamic Host Configuration Protocol", October 1993. [RFC1701] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic Routing Encapsulation (GRE)", October 1994. [RFC2002] Perkins, C., editor, "IP mobility support", October 1996. [RFC2003] Perkins, C., "IP Encapsulation within IP", October 1996. [RFC2004] Perkins, C., "Minimal Encapsulation within IP" October 1996. [RFC2005] Solomon, J., "Applicability Statement for IP Mobility Support", October 1996 [RFC2006] D. Cong, D., Hamlen, M., editors, "The Definitions of Managed Objects for IP Mobility Support using SMIv2", October 1996. [RFC2119] Bradner, S., editor, "Key words for use in RFCs to Indicate Requirement Levels.", March, 1997. [RFC2290] Solomon, J., Glass, S., "Mobile-IPv4 Configuration Option for PPP IPCP", February 1998. Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 19] Internet Draft Mobile IP AAA Requirements 25 June 1999 Authors' Addresses Gopal Dommety IOS Network Protocols Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706, USA Phone: 408-525-1404 Fax: 408-526-4952 Email: gdommety@cisco.com Steven M. Glass Nokia Telecommunications 3 Burlington Woods Drive Suite 250 Burlington, MA. 01803 USA Phone: 781-359-5125 Fax: 781-359-5050 Email: steve.glass@ntc.nokia.com Tom Hiller Wireless Data Standards & Architectures Lucent Technologies 263 Shuman Drive Room 1HP2F-218 Naperville, IL 60563, USA Phone: 630-976-7673 Email:tom.hiller@lucent.com Stuart Jacobs Secure Systems Department GTE Laboratories, 40 Sylvan Road, Waltham, MA 02451-1128, USA. Phone: 781-466-3076 Fax: 781-466-2838 Email: sjacobs@gte.com Basavaraj Patil Wireless Technology Labs Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082-4399, USA Phone: 972-684-1489 Fax: 972-685-3207 Email: bpatil@nortelnetworks.com Charles Perkins Sun Microsystems Laboratories 901 San Antonio Road, MS MPK15-214 Palo Alto, CA 94303-4900, USA Phone: 650-786-6464 Fax: 650-786-6445 Email: cperkins@eng.sun.com Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 20]