Internet Engineering Task Force M. C. Chuah INTERNET DRAFT Lucent Technologies Y. Li Bay Networks, Inc. 24 April 1997 Security-Oriented Extension to Mobile IP (SOMIP) draft-chuahli-mobileip-somip-00.txt Status of This Memo This document is a submission to the Mobile-IP Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mobile-ip@smallworks.com mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document proposes an extension to the Mobile IP base protocol. The purpose of this extension is to ease the key management problem among mobility agents, and to reduce the number of distant registrations. Expires 23 October 1997 [Page i] Internet Draft Security-Oriented Extension 24 April 1997 Contents Abstract .............................................................. i 1. Introduction ....................................................... 1 1.1. Requirements ................................................. 1 1.2. Architectural Entities ....................................... 1 1.3. Terminology .................................................. 1 1.4. Security Enhancement ......................................... 3 1.5. Reduce Distant Registration Frequency ........................ 4 2. Protocol Overview .................................................. 4 2.1. Agent Discovery .............................................. 4 2.2. Local Registration ........................................... 4 2.3. Home Registration ............................................ 5 2.4. Transit Registration ......................................... 5 2.5. Datagram Routing ............................................. 6 2.6. Interoperability with the Base Protocol ...................... 6 3. Message Formats .................................................... 7 3.1. Agent Advertisement .......................................... 7 3.2. Registration Request ......................................... 7 3.3. Registration Reply ........................................... 8 3.4. Route Request ................................................ 8 3.5. Route Reply .................................................. 9 4. Newly Defined Extensions ........................................... 11 4.1. Registration Server Extension ................................ 11 4.2. Care-of Address Extension .................................... 12 4.3. Agent-Server Authentication Extension ........................ 13 4.4. Mobile-Server Authentication Extension ....................... 13 4.5. Server-Server Authentication Extension ....................... 14 5. Care-of Agent Considerations ....................................... 15 5.1. Receiving Route Request ...................................... 15 5.2. Registration Delivery ........................................ 15 6. Registration Server Considerations ................................. 16 6.1. Data Structure ............................................... 16 6.2. Receiving Registration Request as a Binding Registrar ........ 17 6.3. Receiving Registration Request as a Binding Relay ............ 17 6.4. Sending Route Request ........................................ 18 6.5. Receiving Route Reply ........................................ 18 6.6. Load Balancing ............................................... 19 7. Mobility Agent Considerations ...................................... 19 7.1. Sending Agent Advertisement .................................. 19 7.2. Receiving Registration Request as a Foreign Agent ............ 19 7.3. Receiving Registration Request as a Home Agent ............... 19 7.4. Receiving Registration Reply ................................. 19 7.5. Receiving Route Request ...................................... 19 Expires 23 October 1997 [Page ii] Internet Draft Security-Oriented Extension 24 April 1997 8. Mobile Node Considerations ......................................... 20 8.1. Receiving Agent Advertisement ................................ 20 8.2. Local Registration ........................................... 20 8.3. Home Registration ............................................ 20 8.4. Transit Registration ......................................... 20 8.5. Handoff ...................................................... 21 Reference ............................................................. 21 Acknowledgement ....................................................... 22 Authors's Address ..................................................... 22 Expires 23 October 1997 [Page iii] Internet Draft Security-Oriented Extension 24 April 1997 1. Introduction Mobile IP base protocol [1] provides an efficient, scalable mechanism for node mobility within the Internet. However, the key management between the home and foreign agents, and between the foreign agents and the mobile node is still a problem. Secondly, as Perkins [2] addresses in the hierarchical foreign agents model, each time the mobile node moves, a Registration Request message has to be approved by the mobile node's Home Agent. In cases where the home agent is far away, it may become too expensive or even impossible to complete these frequent registrations. This document proposes an extension to the Mobile IP base protocol to solve these problems. 1.1. Requirements Any of the entities in the base protocol should be able to interoperate with the enhanced entities in this SOMIP model. 1.2. Architectural Entities The SOMIP model introduces the following new architectural entities: Registration Server (RS) An entity providing registration service in terms of a routing domain. A registration server in the mobile node's home routing domain is called the Home Registration Server. A registration server in the routing domain that the mobile node is visiting is called the Local Registration Server. Otherwise, it is called a Transit Registration Server. Care-of Agent (COA) An entity providing care-of addresses and forwarding service. In the base protocol, a care-of agent may be the foreign agent itself. We separate it from the foreign agent in the SOMIP model. 1.3. Terminology Care-of Address The care-of address is redefined, in this SOMIP model, as an IP address from which datagrams can be relayed to the mobile node, whether or not through one or more intermediate nodes. Expires 23 October 1997 [Page 1] Internet Draft Security-Oriented Extension 24 April 1997 Mobility Binding The mobility binding is redefined the same as in the base protocol except that the care-of address uses the definition in this SOMIP model. Registration The registration is redefined as a procedure for mobile node to register a mobility binding with a registration server or a home agent and to obtain a care-of address closer to the home agent, by exchange of Registration Request and Registration Reply messages. In the base protocol, this is a registration with a home agent. The care-of address submitted in the Registration Request is called the child care-of address of the registration. The one obtained by this registration is called the parent care-of address of the registration. Binding Registrar A registration server or home agent, with which the mobile node registers a mobility binding. In the base protocol, this is the home agent, with which a mobility binding is associated. Binding Relay A foreign agent or registration server, through which the Registration Reply for a mobility binding can be delivered to the mobile node. In the base protocol, this is the foreign agent. A mobile node is allowed to register a mobility binding with a binding registrar via a binding relay. Home/Local/Transit Registration A registration where the binding registrar is in the mobile node's home routing domain is called a home registration. A registration where the binding registrar is in the routing domain that is visited by the mobile node is called a local registration. Otherwise, the registration is called a transit registration. Complete Registration The combination of one or more registrations, which allows tunnels to be built such that there will be a routing path from the home agent to the visiting mobile node. Expires 23 October 1997 [Page 2] Internet Draft Security-Oriented Extension 24 April 1997 Binding Route Enabled/Disabled A binding route is enabled if, a datagram destined for the mobile node is automatically relayed from the parent care-of address of a registration to the child care-of address. In the base protocol, this means to build a tunnel from the home agent to the care-of address and to add a routing entry to the care-of address for the mobile node. A binding route is disabled if, a datagram destined for the mobile node is discarded at the parent care-of address of the registration, and an ICMP unreachable error is bounced back to the source address of the datagram. In the base protocol, this means to delete the routing entry and, if necessary, to remove the tunnel from the home agent to the care-of address. 1.4. Security Enhancement The design goal of the SOMIP model is to prevent replay attacks in the mobile node's registration procedure, and to prevent an illegal mobile node from stealing services from a routing domain. The existing mobile IP base protocol does not require that there should be security associations between the mobile node and the foreign agent, and between the home agent and the foreign agent. If there are already such security associations, the SOMIP model works exactly the same way as the base protocol. Otherwise, the SOMIP provides a means to compensate for this hole. If there is no security association between the mobile node and the foreign agent or no security association between the foreign agent and the home agent, the SOMIP model suggests the mobile node not to register directly with its home agent, but to first register with a registration server in the local routing domain. The server in turn allocates a parent care-of address to the mobile node in the reply. If there is a security association between the foreign server and the mobile node's home agent, the mobile node can subsequently register with this home agent using the parent care-of address allocated by the foreign server. If not, however, the SOMIP model directs the mobile node to register with its home registration server via the foreign server. This is feasible because there should be security associations between the foreign server and the home server, and between the mobile node and the home server. In this case, the home server in turn allocates a parent care-of address -- home agent address -- to the mobile node. Thus a complete binding is established, which allows packets to be delivered to the mobile node. Expires 23 October 1997 [Page 3] Internet Draft Security-Oriented Extension 24 April 1997 1.5. Reduce Distant Registration Frequencies When the mobile node moves within a routing domain, it changes its point of attachment from one foreign agent to another, and thus keeps registering with the local registration server. To reduce distant registration frequencies, the mobile node can compare the parent care-of address that is newly allocated with that allocated previously. If they are the same, the mobile node may not necessarily register further with its home registration server or its home agent. 2. Protocol Overview Under the SOMIP model, a complete registration consists of local registrations, home registrations and/or transit registrations. Changes should apply to both the Agent Discovery and the Registration procedures. 2.1 Agent Discovery In the base protocol, the foreign agents advertise their presence via Agent Advertisement messages. The mobile node obtains a child care-of address (which usually is the foreign agent's address) from the advertisements. The SOMIP model requires that the Agent Advertisement messages additionally include a registration server extension so that prospective mobile nodes can choose a registration server for the local registration. The registration extension includes one or more registration addresses. 2.2 Local Registrations When the mobile node detects that it changes the point of attachment, it registers a mobility binding with a local registration server via a foreign agent and obtains a parent care-of address through exchange of Registration Request and Registration Reply with the local server. The local server may request the care-of agent providing the parent care-of address to enable the binding route by exchange of Route Request and Route Reply messages with it. Thereafter packets from a node within the local routing domain may be able to reach the mobile node. For any registration, the SOMIP model requires that a care-of address should be returned to the mobile node by including it in the reply. Expires 23 October 1997 [Page 4] Internet Draft Security-Oriented Extension 24 April 1997 2.3 Home Registrations If the parent care-of address obtained above is not the mobile node's home agent, and it is different from that obtained previously, the mobile node then builds a new mobility binding using this parent care-of address, and registers this binding with its home registration server, via the local server, through exchange of Registration Request and Registration Reply message with it. In this home registration, the parent care-of address obtained through local registration becomes the child care-of address. The care-of address returned from the home registration server is a new parent care-of address which usually is a home agent address. In this case, a complete registration is performed among the mobile node, the foreign agent, the local server, the home server and the home agent. The home server may request the home agent to enable the binding route, that is, to build a tunnel from the new parent care-of address to the child care-of address by exchange of Route Request and Route Reply messages. 2.4 Transit Registrations When the mobile node moves from one routing domain to another and has a valid mobility binding with a previous foreign server, it may issue a transit registration request to that previous foreign server to enable a binding route from the previous parent care-of address to the current one. Such a mobility binding is transitional and helps to ensure that data that has been delivered to the previous parent care-of address can be forwarded to the new parent care-of address. This transitional binding can be removed once the mobile node has completed its registration of the new parent care-of address with the home registration server. Transit registration can also be applied to a foreign server that has no security association with the home server. In this case, the mobile node may register, via the local server, the local parent care-of address with a transit registration server, which in turn allocates a new parent care-of address to the mobile node. The mobile node then registers, via the transit server, this new parent care-of address with the home server. Expires 23 October 1997 [Page 5] Internet Draft Security-Oriented Extension 24 April 1997 2.5 Datagram Routing Through a series of local, transit and home registrations, the mobile node obtains a path from the home agent to the foreign agent. The path consists of a sequence of tunnels with the starting point of the first tunnel as the home agent, and the termination point of the last tunnel as the foreign agent, and each of the tunnels begins with a parent care-of address and ends with a child care-of address. Datagrams sent to the mobile node's home address are intercepted by its home agent, tunneled from one care-of address to another until the foreign agent, and finally delivered to the mobile node by the foreign agent. These tunnels fall into three categories: home tunnels, transit tunnels, and foreign tunnels. A home tunnel begins with a home agent or a parent care-of address allocated by a home registration server, and ends with a child care-of address allocated by another registration server. A transit tunnel begins with a parent care-of address allocated by a registration server and ends with a child care-of address allocated by the current visiting registration server. A foreign tunnel begins with a parent care-of address allocated by the current visiting registration server and ends with a child care-of address allocated by the foreign agent. Each of these tunnels is authorised by two registration servers or by a registration server and a mobility agent. In the reverse direction, datagrams sent by the mobile node are generally delivered to their destination using standard IP routing mechanisms, not necessarily passing through the home or foreign agent. 2.6 Interoperability with the Base Protocol To make the SOMIP model compatible with the base protocol, a few requirements apply to the mobile node, foreign agent and home agent in the SOMIP model. Upon receipt of an agent advertisement message without registration server extension, the mobile node should be able to register with a home agent via the foreign agent as in the base protocol. In this case, the mobile node should not check for the presence of any care-of address extension in the registration reply. When a mobile node that supports SOMIP visits a network that just supports base-protocol, the registration request should be considered as a home registration request. The binding registrar address field can be the home registration server address or the home agent address. If there is no security association between the mobile node Expires 23 October 1997 [Page 6] Internet Draft Security-Oriented Extension 24 April 1997 and the home agent, but there exists one between the mobile node and the home server, then the registration request should be directed to the home server. To determine whether a Registration Request is from a mobile node under the SOMIP model, the request message should include a C-bit in the reserved field. A foreign agent, upon receipt of a Registration Request with C-Bit cleared, should not require that there be a mobile-foreign authentication extension in the request and a foreign-home authentication extension in the further reply message. 3. Messages Formats 3.1 Agent Advertisement The Agent Advertisement messages additionally include a registration server extension, which contains one or more registration server addresses. Thus the mobile node can be informed of registration server addresses and register its mobility binding with one of them. 3.2. Registration Request One bit is added to the Registration Request message to indicate the registration is supported by the SOMIP model. Thus, the Registration Request message under this model 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |S|B|D|M|G|V|C|r| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Binding Registrar | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- SeCurity (C): The C-bit is set by a mobile node or a binding registrar to indicate that the procedure is supported by the SOMIP model. This bit is for the purpose of interoperability with the base protocol. Expires 23 October 1997 [Page 7] Internet Draft Security-Oriented Extension 24 April 1997 Reserved (r): The r-bit should be set to 0. Binding Registrar: A home agent or a registration server. 3.3. Registration Reply There is no change in the format of the Registration Reply message except that, the "Home Agent" field is renamed to "Binding Registrar" field. In addition to a few authentication extensions, the Registration Reply MUST include a care-of address extension so that a registration server can allocate a parent care-of address to the mobile node. The Registration Reply MAY additionally appends a registration server extension to advise the mobile node to choose a registration server address as the next registrar. 3.4. Route Request Message Route Request is used by a registration server to request a care-of agent to enable a binding route to a certain address for the mobile node. IP fields: Source Address Typically the interface address from which the message is sent. Destination Address Typically the IP address of the care-of agent. UDP fields: Source Port Destination Port 434 The UDP header is followed by the fields shown below: Expires 23 October 1997 [Page 8] Internet Draft Security-Oriented Extension 24 April 1997 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 | Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Hop Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Type 32 (Route Request) Reserved sent as zero; ignored on reception. Lifetime The number of seconds remaining before the route is considered expired. A value of zero indicates a request for disabling. A value of 0xffff indicates infinity. Destination Address The home address of the mobile node. Next Hop Address The child care-of address if requested by a registration server, or otherwise a parent care-of address allocated by a registration server. Identification A 64-bit number, constructed by the server, used for matching Route Requests with Route Replies, and for protecting against replay attacks of these messages. Extensions The fixed portion of the Route Request is followed by one or more of the Extensions. 3.5. Route Reply Message The care-of agent returns a Route Reply message to the server which has sent a Route Request (Section 3.4) message. The Reply message contains the necessary codes to inform the server about the status of its Request, along with the lifetime granted by the care-of agent, which MAY be smaller than the original Request. Expires 23 October 1997 [Page 9] Internet Draft Security-Oriented Extension 24 April 1997 IP fields: Source Address Typically copied from the destination address of the Route Request to which the care-of agent is replying. Destination Address Copied from the source address of the Route Request to which the care-of agent is replying UDP fields: Source Port Destination Port Copied from the source port of the corresponding Route Request The UDP header is followed by the fields shown below: 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 | Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Hop Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Type 33 (Route Reply) Code A value indicating the result of the Route Request. See below for a list of currently defined Code values. Lifetime If the Code field indicates that the care-of agent agrees to add the route capability, the Lifetime field is set to the number of seconds remaining before the route is considered expired. A value of zero indicates that the route has been disabled. A value of 0xffff indicates infinity. Expires 23 October 1997 [Page 10] Internet Draft Security-Oriented Extension 24 April 1997 If the Code field indicates that the route was denied, the contents of the Lifetime field are unspecified and MUST be ignored on reception. Destination Address The home address of the mobile node. Next Hop Address The child care-of address if requested by a foreign registration server, or otherwise a parent care-of address allocated by a foreign registration server. Identification A 64-bit number used for matching Route Requests with Route Replies, and for protecting against replay attacks of tunnel messages. The value is based on the Identification field from the Route Request message from the client. Extensions The fixed portion of the Route Reply is followed by one or more of the Extensions. The following values are defined for use within the Code field. 0 route added 64 reason unspecified 65 administratively prohibited 67 server failed authentication 68 requested Lifetime too long 69 poorly formed message Up-to-date values of the Code field are specified in the most recent "Assigned Numbers" [5]. 4. Newly Defined Extensions 4.1. Registration Server Extension This extension is placed in the Agent Advertisement message or Registration Reply message, and used to provide the mobile node a collection of registration servers. Expires 23 October 1997 [Page 11] Internet Draft Security-Oriented Extension 24 April 1997 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 | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registration Server Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registration Server Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 81 Length 2 + 8 * number of registration server addresses Lifetime The number of seconds remaining before the registration server is considered invalid. A value of zero indicates the registration server doesn't provide service to more mobile nodes. A value of 0xffff indicates infinity. Priority The level of authorization. 4.2. Care-of Address Extension This extension is placed in the Registration Reply so that a registration server can allocate a care-of address to the mobile node. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | care-of address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 82 Length 6 Reserved 0 Expires 23 October 1997 [Page 12] Internet Draft Security-Oriented Extension 24 April 1997 care-of address parent care-of address or home agent address 4.3. Agent-Server Authentication Extension This extension is included in the Registration Request and Registration Reply messages between the foreign agent and the foreign registration server, and between the home agent and the home registration server. The SOMIP model requires that there exists a security association between an agent and a registration server in the same routing domain. The extension MAY also be included in the Route Request and Route Reply messages between a registration server and a care-of agent. 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 | SPI .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... SPI (cont.) | Authenticator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 83 Length 4 plus the number of bytes in the Authenticator. SPI Security Parameter Index (4 bytes). An opaque identifier Authenticator (variable length) 4.4. Mobile-Server Authentication Extension This extension is included in the Registration Request and Registration Reply messages between the mobile node and the foreign registration server, and between the mobile node and the home registration server. The SOMIP model requires that there exists a security association between a mobile node and a registration server whether they are in the same routing domain or not. 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 | SPI .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... SPI (cont.) | Authenticator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires 23 October 1997 [Page 13] Internet Draft Security-Oriented Extension 24 April 1997 Type 84 Length 4 plus the number of bytes in the Authenticator. SPI Security Parameter Index (4 bytes). An opaque identifier Authenticator (variable length) 4.5. Server-Server Authentication Extension This extension is included in the Registration Request and Registration Reply messages between two registration servers, especially between the foreign registration server and the home registration server. The SOMIP model requires that there exists a security association between two registration servers whether they are in the same routing domain or not. 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 | SPI .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... SPI (cont.) | Authenticator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 85 Length 4 plus the number of bytes in the Authenticator SPI Security Parameter Index (4 bytes). An opaque identifier Authenticator (variable length) Expires 23 October 1997 [Page 14] Internet Draft Security-Oriented Extension 24 April 1997 5. Care-of Agent Considerations The care-of agent could be an OSPF area border router, an autonomous system border router or a backbone router. The care-of address was originally associated with a foreign agent. In the SOMIP model, the care-of agent is designed to forward traffic destined to the mobile node. 5.1. Receiving Route Request Upon receipt of a Route Request, the care-of agent MUST check the validity of the message. The request is valid if - the UDP checksum is valid; AND - the message includes an Agent-Server Authentication extension at the end and the Authenticator is valid. An invalid request SHOULD be discarded and an error SHOULD be logged. On receipt of a valid Route Request message, the care-of agent SHOULD respond with a Route Reply with the lower 32-bit identification copied from the original request. If the care-of agent is not able to honor the request, it SHOULD put a proper code in the reply. If the care-of agent denies the request and disable the routing capability to the server, it SHOULD set the code to a positive value (0) and the lifetime to 0. Otherwise, if the care-of agent agrees to enable a binding route to the registration server, it SHOULD set the code to a positive value (0) and the lifetime to a value not greater than that in the original Request. The binding route is valid within the granted lifetime and SHOULD be disabled upon its expiry. 5.2. Binding Route Enable/Disable To enable a binding route, in general, the care-of agent MAY first build a tunnel to the next hop address specified in the Route Request message if such a tunnel does not exist previously. The care-of agent then adds a route entry to this tunnel for the mobile node. To disable the registration delivery, the care-of agent can simply remove the entry from the routing table. Expires 23 October 1997 [Page 15] Internet Draft Security-Oriented Extension 24 April 1997 If the next hop address in the Route Request message is in the same routing domain as the care-of agent, the care-of agent MAY flood a host-specific route throughout the routing domain, or the care-of agent adds a host-specific route to an OSPF area border router provided each area border router propagates host-specific routes for the mobile node. This approach assumes that the OSPF protocol is one of the supporting routing protocols. 6. Registration Server Considerations Under the SOMIP model, local registration is used to establish the local mobility binding of a mobile node, that is, the association of the mobile node with a local registration server, a foreign agent, and the lifetime of this association. The local mobility binding MAY create the mobile node's connectivity to the local routing domain. The local registration server, taking the advantage of the above local mobility binding, then establishes a home mobility binding, that is, the association of the mobile node with the home agent or the home registration server of the mobile node, the local registration server, and the lifetime of the association. The registration server MAY be configured with one or more care-of agent addresses, which are allocated to mobile nodes such that traffic load can be balanced. 6.1. Data Structure For each registration server and each visiting mobile node, there are generally two registrations: one where the registration server acts as the binding registrar and the other where the registration server acts as a binding relay. Each registration creates an entry in the registration server cache. The registration server may merge the two entries into one. The entry created by the local/transit registration where the registration server is the binding registrar consists of - mobile node's home address - child care-of address and - lifetime The entry created by the home registration where the registration server is the binding relay consists of Expires 23 October 1997 [Page 16] Internet Draft Security-Oriented Extension 24 April 1997 - mobile node's home address - binding registrar - parent care-of address - lifetime and - the connection status of the tunnel between parent and child care-of address. 6.2. Receiving Registration Request as a Binding Registrar Upon receiving a valid registration request where the registration server is the binding registrar, the server MAY send a positive Registration Reply to the mobile node if there is a security association between itself and the mobile node. In this case, if the registration server previously does not have a mobility binding yet with the mobile node, it SHOULD allocate a parent care-of address, put it in a care-of address extension, and append the extension to the Registration Reply. However, if the registration server has a binding with the mobile node previously, the old care-of address SHOULD be put in that extension. This ensures that the mobile node can obtain the same parent care-of address if repeatedly registering with the registration server. The registration server MAY include a registration server extension in the Registration Reply message for the mobile node to perform further transit/home registrations. The registration server SHOULD include an agent-server or server- server authentication extension in the reply if the binding relay is the foreign agent or another registration server, respectively. If there is no tunnel currently between the parent and child care-of address, the registration server SHOULD direct the care-of agent, by issuing a Route Request message, to build a tunnel from the parent care-of address to the child care-of address for the mobile node. The child care-of address is specified in the Registration Request while the parent care-of address is allocated by the binding registrar. If the registration server is a home server, the parent care-of address it allocates MAY be the home agent address. In this case, the care-of agent is the home agent. 6.3. Receiving Registration Request as a Binding Relay Upon receiving a valid registration request where the registration server is the binding relay, the registration server MUST verify that there is already an entry for this mobile node where it acts as a binding registrar. If not, the Registration Request MAY deny this request. The registration server SHOULD also verify that there is a security association between itself and the binding registrar. If not, the server SHOULD deny this request. The binding lifetime SHOULD Expires 23 October 1997 [Page 17] Internet Draft Security-Oriented Extension 24 April 1997 not be greater than the one with the current mobility binding where the registration server acts as a binding registrar. Otherwise, the server MAY deny this request. If the Registration Request message meets all the requirements above, the registration server MAY relay this request to the binding registrar in the same way as the foreign agent deals with the Registration Request in the base protocol. The registration server MAY deny the request and include a registration server extension for the mobile node to perform further transit/home registrations. The registration server SHOULD include a server-server authentication extension in the request to be relayed, or a mobile-server authentication extension in the reply if the server denies the request above. 6.4. Sending Route Request To ensure the care-of agent can forward traffic to the mobile node, the server SHOULD send a Route Request to the care-of agent. The server SHOULD copy lifetime from the Registration Request to the Route Request. The server SHOULD retransmit Route Request if it has not received a matched Route Reply in a reasonable time. Failure in receipt of such a Route Reply message after a maximum of retransmissions SHOULD be logged for further administrative option. The server MAY choose another care-of agent and repeat the procedure above until no care-of agent is available. In this case, the server SHOULD send a negative Registration Reply to the mobile node. The server SHOULD append an Agent-Server Authentication extension to the Route Request message. The SOMIP model requires that there be a security association between the server and the care-of agent. 6.5. Receiving Route Reply Upon receipt of a Route Reply, the server MUST check the validity of the message. The reply is valid if - the UDP checksum is valid; - the low-order 32 bits of the Identification field in the Route Reply equals to the low-order 32 bits of the Identification field in the most recent Route Request sent to the care-of agent; AND - the reply include a Agent-Server Authentication extension. Expires 23 October 1997 [Page 18] Internet Draft Security-Oriented Extension 24 April 1997 If the code field is negative or the lifetime is zero, the server MUST send a Registration Reply message with a negative code or lifetime set to 0. 6.6. Load Balancing Each registration server occasionally probes their care-of agents on the traffic load that each of them is supporting. The care-of agents each return a metric that has a higher value when the traffic load is higher. Based on such replies, the server can order the list of care-of addresses with the least loaded one being at the top of the list. When the server receives a local registration request, it assigns the least loaded care-of address to that request. 7. Mobility Agent Considerations 7.1 Sending Agent Advertisement A mobility agent SHOULD include a registration server extension in the Agent Advertisements. This can facilitate the mobile node in finding a registration server with whom it has security association for subsequent registrations. 7.2. Receiving Registration Request As a Foreign Agent Upon receiving a Registration Request, a foreign agent SHOULD verify that there is a security association between itself and the binding registrar. If there is, the agent works exactly the same as the foreign agent in the base protocol. Otherwise, the agent SHOULD deny the Registration Request. The agent MAY include a registration server extension in the Registration Reply message for the mobile node to choose another binding registrar and to perform further registrations. 7.3. Receiving Registration Request as a Home Agent The home agent deals with a received Registration Request in the same way as the home agent in the base protocol. 7.4. Receiving Registration Reply The mobility agent deals with a received Registration Reply in the same way as in the base protocol. 7.5. Receiving Route Request The foreign agent SHOULD disregard this message. Expires 23 October 1997 [Page 19] Internet Draft Security-Oriented Extension 24 April 1997 The home agent SHOULD deal with the Route Request in the same way as the care-of agent. The home agent SHOULD additionally send proxy ARP and gratuitous ARP on the home network. The procedure SHOULD be the same as in the base protocol. 8. Mobile Node Considerations 8.1. Receiving Agent Advertisement When a mobile node receives an agent advertisement, it SHOULD check to see if the mobility agent is its home agent. If it is, it does nothing since it is at home. Otherwise, it checks to see if there is a registration server extension in the agent advertisement. If yes, the mobile node SHOULD choose one of the registration servers whose addresses appear in the registration server extension and perform a local registration with the selected server. 8.2 Sending Registration Request The mobile node SHOULD choose a proper binding relay and a binding registrar from previously received Agent Advertisement messages. For local registrations, the binding relay is the foreign agent, and the binding registrar is one of the local registration servers whose addresses appear in the registration server extension. For home registrations, the binding relay is the local registration server while the binding registrar is the home registration server. For transit registrations, the binding registrar is a registration server with whom the mobile node has previously established a mobility binding or with whom the mobile node has a security association, while the binding relay could be a foreign agent or another registration server. If the mobile node previously receives a negative Registration Reply, which includes a registration server extension, it SHOULD choose a proper binding registrar to proceed further registration. The mobile node SHOULD include a mobile-server authentication extension in the request if the binding relay is a registration server. 8.3 Receiving Registration Reply Upon receiving a valid local registration reply, the mobile node SHOULD check to see if the binding registrar or the parent care-of address returned in the reply is its home agent. If yes, this is a complete registration. If it is not, however, the mobile node SHOULD check to see if it has previously established a mobility binding with its home registration server or home agent, using this parent care-of address. Expires 23 October 1997 [Page 20] Internet Draft Security-Oriented Extension 24 April 1997 If it has, nothing needs to be done since the mobile node just changes its point of attachment locally. Otherwise, the mobile node SHOULD perform a home registration using this parent care-of address. In this second registration, the local server will be used as the binding relay and the binding registrar will be set to the home registration server's address. If the reply includes a registration server extension, it means the the binding registrar advises the mobile node to perform further registration with one of the registration servers in the extension. In this case, the mobile node SHOULD choose one of them and proceed with a registration with the local server set to the binding relay, and the selected registration server set to the binding registrar. 8.4. Handoff When a mobile node moves from one foreign routing domain to another, the mobile node performs a local registration with the new local server. Then, it can first do a transit registration with its previous foreign registration server such that a tunnel can be built from the previous foreign server's care-of address to the new local server's care-of address. This tunnel is a transitional tunnel that enables the forwarding of packets that have been sent to the previous foreign server but have not been delivered to the mobile node. Later, it performs a home registration with its home registration server using the new local server's care of address. After establishing a complete binding with the home registration server, the transitional tunnel can be torn down. References [1] Charles Perkins, editor. IP mobility support. RFC 2002, Oct 1996. [2] Charles Perkins. Mobile-IP Local Registration with Hierarchical Foreign Agents. Internet Draft, draft-perkins-mobileip-hierfa-00.txt, February 1996. Work in progress. [3] Charles Perkins. IP Encapsulation within IP. RFC 2003, October 1996. [4] David B. Johnson and Charles Perkins. Route Optimization in Mobile IP. Internet Draft, draft-ietf-mobileip-optim-04.txt, February 1996. Work in progress. [5] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700, October 1994. Expires 23 October 1997 [Page 21] Internet Draft Security-Oriented Extension 24 April 1997 Acknowledgement Many thanks to Y.C. Tay and K.C. Chua at the National University of Singapore for their early support for the development of this memo. Authors' Address Questions about this memo can also be directed to: M. C. Chuah, Performance Analysis Department, Bell Laboratories, Lucent Technologies, 101, Crawfords Corner Road, Holmdel, NJ 07733, USA. Phone: 908-949-7206 Fax: 908-834-5906 Email: chuah@lucent.com Y. Li Protocol Development Group Engineering Department Bay Networks, Inc. 2 Federal Street Billerica, MA 01821, USA. Phone: (508) 916-1130 Fax: (508) 670-8760 Email: yli@BayNetworks.COM Expires 23 October 1997 [Page 22]