INTERNET-DRAFT Charles Perkins Working Group Nokia Research July 30,2000 Hossam Afifi expires 30 January 2001 INT Evry Internet General Packet Radio Service (IGPRS); Service description draft-afifi-igprs-00.txt Status of this Memo This document is an individual contribution for consideration by the IPNG Working Group of the Internet Engineering Task Force. Comments should be submitted to the mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract We propose an architecture (IGPRS) for the integration of the IPv6 protocol in the GPRS infrastructure. The data and signalling protocol suite will be based on mobile IPv6 protocol (instead of the GTP protocol). This new infrastructure will take advantage of the available internet protocols for routing and security. Since it is targetted to co-exist with the GPRS, it is a partial translation of MAP specifications to Internet protocols. This document uses some of the GPRS Service document and some of its terminology. The IGPRS interface will be complementary to GPRS protocols and can co-exist with them. It represents hence a smooth migration to an all IP network. A GPRS terminal that has IGPRS functionality will be able to directly use the internet infrastructure for data and signalling transmission. A GPRS Base Station that has this additional functionality will be able to translate all the traffic coming from an enhanced GPRS terminal Page 1 GPRS Interface to Mobile IPv6 to a conventional IPv6 protocol suite. IPv4 can be used by mobile applications but the underlying infrastructure will be only based on IPv6. Transition mechanisms should hence be used when IPv4 is required. Since a large legacy of management protocols is available and necessary in the GPRS/GSM+2 infrastructure and since the GPRS data protocols are designed to co-exist with the GSM, we propose an architecture that supports mobile Ipv6 as the data protocol and diameter as the main signalling protocol (AAA). In the boundaries we propose to interface the internet protocols with the conventional GPRS entities (e.g. HLRs, MSC/VLRs) in order to keep the necessary user management consistency. The resulting architecture is then composed of enhanced Ipv6 GPRS terminals, enhanced GPRS Base stations and enhanced HLR/VLR functionalities capable of dealing with Internet protocols. Table of Contents ---------------------- 1. Introduction 2. Abbreviations and terminology 3. Protocol Overview 4. Packet formats 5. Procedures 6. Security considerations 7. Security Function 1 . Introduction and scope This document gives the service description of the Internet Based GPRS system (IGPRS) that represents an evolution of the current GPRS service as defined in the document [GPRS]. It is hence mainly compliant with the current GPRS service description principles. It gives the procedures and functionalities that have to be implemented in the terminals and in the network in order to operate an IPv4/IPv6 based mobile public data network. This system is designed to run in presence of the conventional GPRS and GSM systems. The base protocol in this architecture is IPv6 and does not at all preclude IPv4 in the mobile node. However, all mobility and signalling procedures are achieved using the v6 version only. IGPRS fully relies on the normal layer 2 GPRS protocols and eventually data compression. The following sections give the detailed operation of the IGPRS system. The rest of this document is organized as follows. Section 2 gives some definitions and abbreviations that will be frequently used in the subsequent sections. Section 3 defines the protocol main entities and states describing a mobile node and their relation to Mobile IPv6 states. In Section 4 we describe the packet formats. Section 5 gives the procedures and transitions between the protocol functions. Section 6 gives the security functions necessary for user authentication. 2 . Abbreviations and terminology Page 2 GPRS Interface to Mobile IPv6 DNS Domain Name Service IGSS Internet GPRS Support Server, it must be a v6 Home Agent. IMSI International Mobile Subscriber Identity NAI Network Access Identifier MIPv6 Mobile IP v6 MN Mobile Node PCB Protocol Control Block. Information associated with a node. PLMN Public Land Mobile Network RA Routing Area, A space of administration for a single Home Agent. RAC Routing Area Code; IPv6 Prefix code RAI Routing Area Identity; The canonical Name of the router responsible of the RAC RLC Radio Link Control TLLI Temporary Logical Link Identity TMSI Temporary Mobile Subscriber Identity Regional Registration Identity The GPRS architecture is mainly composed of a mobile node (MS), a base station (BSS), a home agent (SGSN) and databases (HLR). Most of entities in the IGPRS protocol suite are the same as defined in the GPRS infrastructure except for: IGSS, that replaces the SGSN. It is a Home Agent running Ipv6 with additional Diameter, DNS, routing and security functionalities. It can co-exist with an SGSN node. BSS, is the same as in the GPRS network except that it implements IPv4/IPv6 routing functionalities. A BSS may represent a group of layer 2 bridging equipments. It may be capable of header compression/decompression facilities and could be based on a connection oriented layer 2 protocol. The main architecture of this document is based on the integration of the Home Agent entity in the SGSN. A second alternative is possible with the home agent being embedded in the GGSN. We do not consider this architecture in this document and we leave it for further study. 3 . Protocol Overview In this section we present the main entities implied in IGPRS. Page 3 GPRS Interface to Mobile IPv6 +--------+ +------+ +------+ +--------+-----+ +--------+-----+ |IP/MIP6 | | IP6 | | MIP6 | |Diameter| MAP | |DIAMETER| MAP | |------- | | | | | | | | | | | | LLC | | LLC | +------+ +--------+-----+ +--------+-----+ | RLC | | RLC | | MAC | | MAC | | GSM/RF | |GSM/RF| +--------+ +------+ MN BSS IGSS HLR MSC/VLR(optional) 3 . 1 . Protocol Entities IPv6 is implemented on the physical layer and layer 2 of the GPRS protocol. We identify the Mobile node MN, BSS, IGSS, HLR interface and MSC/VLR interface as the entities representing IGPRS. The MN has some interactions with the BSS and others with the IGSS. The BSS is responsible of informing the MN of its location area (the subnetwork in IPv6) and of its Home Agent identity. The IGSS initiates security functions and updates the HLR with any necessary mobility management procedure. The optional dialogue between the IGSS and MSC/VLR is for further study. Mobile IPv6 is only seen between the MN and the IGSS. The rest of the entities are not part of the mobility process. We describe in the following section the interaction of the IPv6 layer with layer 2 states. Some procedures in the IGPRS proposal are timer based and others location based. The first procedures are necessary to save the air interface resources and to rapidely detect any MN disappear. The second set of procedures correspond to mobility management at the network level. The Mobile Node (MN) The v6 Mobility Management (MM) activities related to a IGPRS subscriber are characterized by one of three different states. Each state describes a certain level of functionality and information allocated. It is to be noted that the MN will keep a link local address whenever it has to establish any pre-authentication procedure. Once it has to send user data it should obtain a valid address. This will be explained later. The IPv6 layer will be able to detect at each time the current state of the entity along with the related state variables and to achieve the necessary procedures. IDLE (IGPRS) State In GPRS IDLE state, the subscriber is not attached to the IGPRS mobility management. The MN and IGSS context hold no valid routing information for the subscriber. The subscriber-related mobility management procedures are not performed. The MN does not have a home agent (IGSS) neither. Since the MN listens to multicast layer1 physical information it can perform locally PLMN selection and IGPRS cell selection and re-selection processes. Data transmission to and from the mobile node as well as the paging of the subscriber are not possible. The GPRS MN is seen as not reachable in this case. From an IP/IPv6 point of view the node does not have any valid address (except a link local), valid default router or valid home agent information (routing area). In order to establish contexts in the MN and the IGSS, the MN shall perform the IGPRS Attach procedure explained in the Procedures section. STANDBY State Page 4 GPRS Interface to Mobile IPv6 In STANDBY state, the subscriber is attached to IGPRS mobility management. The MN and IGSS have established contexts for the subscriber's IMSI/NAI. Pages for data or signalling information may be received. User IPv6 reception and transmission are not possible in this state. The MN performs IGPRS Home Agent selection and IGPRS cell selection and re-selection locally. The MN listens on the broadcast channel to learn about the router advertisement and hence to know its prefix and whether it is still in the same routing area (HA) or not. The MN executes mobility management procedures to inform the IGSS when it has entered a new HA zone. This includes MIP procedures. The MN does not inform the IGSS on a change of cell in the same HA zone. Therefore, the location information in the IGSS context contains only the identification of the MN but not its cell location. The MN may initiate activation or deactivation of contexts while in STANDBY state. A context shall be activated before data can be transmitted or received for this PCB context. The IGSS may have to send data or signalling information to an MN in STANDBY state. Paging in the STANDBY state is accomplished by Neighbour Sollicitation messages sent from the IGSS or BSS. The suffix is simply set to the IMSI identifier. It should be noted that no DAD is to be done on a IGPRS network. Paging may not be an efficient way to reach the MN but the procedure should be implemented to solve at minimum, emergency situations. An alternative to paging is to wait until the node subscribes with a new IGSS or updates the old one through the periodic routing updates as described in the following sections. The MN or the network may initiate the IGPRS Detach procedure to move to the IDLE state. After expiry of the mobile reachable timer the IGSS may perform an implicit detach in order to return in the IGSS to IDLE state. READY State In READY state, the IGSS updates the MN context with its subnetwork (prefix). The MN performs mobility management procedures to provide the network with the actual selected cell (prefix). IGPRS cell selection and re-selection is done locally by the MN, or may optionally be controlled by the network. The MN Prefix is sent periodically to the IGSS via the BSS (the procedure can be achieved with hob-by-hop Options or ICMPv6 messages). When a mobile node makes a handover to a new cell, the default router may or may not change according to the network topology. Two cells may be in the same routing area. However it is good to know the cell identity (that would correspond to some layer two details) for a better interaction with the fixed network. The mobile node learns this information from the radio layer and forwards it to the BSS and IGSS ( through an ICMPv6 or Destination Option). The MN may send and receive Internet PDUs in this state. The network initiates no IGPRS pages for an MN in READY state The IGSS transfers downlink data to the BSS responsible for the subscriber's actual IGPRS cell. Regardless if a radio resource is allocated to the subscriber or not, the MN remains in the READY state even when there is no data being communicated. The READY state is supervised by a timer. An MN context moves from READY state to STANDBY state when the READY timer expires. In order to move from READY state to IDLE state, the MN initiates the IGPRS Detach procedure. This means that the IPv6 global address is no more valid. Page 5 GPRS Interface to Mobile IPv6 Mobility management in the IGSS side This section describes the additional states that have to be maintained relating IPv6 to the lower layer. The states are mainly related to timers. Some states are kept in both the MN and IGSS. READY Timer Function The READY timer function maintains the READY timer in the MN and IGSS. The READY timer controls the time an MN remains in READY state in the MN and the IGSS. The READY timer shall be reset and begin running in the MN when a packet is transmitted, and in the IGSS when it is correctly received. When the READY timer expires, the MN and IGSS contexts shall return to STANDBY state. The length of the READY timer shall be the same in the MN and IGSS. The initial length of the READY timer shall be defined by a default value. The IGSS, and only the IGSS, may change the length of the READY timer by transmitting a new value in the Attach Accept, Routing Area Update Accept. If the READY timer length is set to zero, the MN shall immediately be forced into STANDBY state. Periodic RA Update Timer Function Routing Area Update functionality is directly coupled with the MIPv6 management. The Periodic RA Update Timer function monitors the periodic RA update procedure in the MN. The periodic RA update timer is unique within an RA. Upon expiry of the periodic RA update timer, the MN shall start a periodic routing area update procedure. Mobile Reachable Timer Function The Mobile Reachable Timer function monitors the periodic RA update procedure in the IGSS. The mobile reachable timer shall be slightly longer than the periodic RA update timer used by an MN. The mobile reachable timer is stopped when the READY state is entered. The mobile reachable timer is reset and started when the state returns to STANDBY. If the mobile reachable timer expires, the IGSS shall stop sending IGPRS paging messages to the MN, but other features may happen immediately. 4 . Messages Formats This section describes the necessary packet and headers format for IGPRS infrastructure. We identify messages from the MN to the IGSS. From the IGSS to the HLR and vice-versa. Inter IGSS Diameter Extensions: IGSS to HLR Diameter Messages: IPv6 Hop-by-Hop IGSS option: IPv6 Router Sollicitations Authentication Header and options: 5 . IGPRS Procedures and Functions In this section we describe the actions that entities have to take to implement the mobility management for IGPRS. We start by describing the functions activated in IPv6 due to the state transitions occuring in both MN and IGSS. We also explain the procedures that are used to accomplish the routing update (change of HA and of default router). Page 6 GPRS Interface to Mobile IPv6 5 . 1 . State transition in the MN and IGSS This section gives details on the changes that will happen when a MN goes from one state to the other. These state information are obtained from the lower layers. The movement from one state to the next is dependent on the current state (IDLE, STANDBY, or READY) and the event occurred (e.g., IGPRS attach). We describe the IPv6 necessary actions when such a transition happens. +-------+ +-------+ | IDLE | | IDLE | +-------+ /+-------+ / \ // \ \|/ /|\ /\|/ /|\ | | / | | \ / | \ / +-------+ | +-------+ | READY | /|\ | READY | +-------+ | +-------+ / \ | / \ \|/ /|\ | \|/ /|\ | | | | | \ / \ \ / +-------+ \ +-------+ |STANDBY| \ |STANDBY| +-------+ +-------+ MM states diagrams for MN and IGSS Moving from IDLE to READY: - IGPRS Attach: The MN requests access and a logical link to an IGSS is initiated. Moving from STANDBY to IDLE: - Implicit Detach: The MN and the IGSS shall return to IDLE. - Cancel Location: The IGSS receives a MAP Cancel Location message from the HLR (through the Diameter extensions). Moving from STANDBY to READY: - PDU transmission: The MN sends a packet to the IGSS, possibly in response to a page. - PDU reception: The IGSS receives an IPv6 from the MN. Moving from READY to STANDBY: - READY timer expiry: The MN and the IGSS return to STANDBY state. - Force to STANDBY: The IGSS indicates an immediate return to STANDBY state before the READY timer expires. - Abnormal RLC condition: The IGSS returns to STANDBY state in case of Page 7 GPRS Interface to Mobile IPv6 delivery problems on the radio interface or in case of irrecoverable disruption of a radio transmission. Moving from READY to IDLE: - IGPRS Detach: The MN or the network requests to return to IDLE state. The IGSS may delete the MN from its entries. - Cancel Location: The IGSS receives a MAP Cancel Location message from the HLR. Attach Function A IGPRS attach is made to the IGSS. A IGPRS-attached MN makes NAI/IMSI attach via the IGSS. In the attach procedure, the MN shall provide its identity and an indication of which type of attach that is to be executed. The regional Registration should be used as much as possible to prevent too many authentication exchanges with the home IGSS. A Temporary identification should be used (P-TMSI) After having executed the IGPRS attach, the MN is in READY state and the IGSS also. The detailed procedure of an attach function is described here- after: The MN initiates the attach procedure by sending an ICMPv6 router sollicitation message. The BSS, using the DIAMETER Protocol Direct Reboot Indication (IMSI or P-TMSI and old RAI, old P-TMSI Signature) sends a message to the IGSS. On the point to point wireless link the MN sends its IMSI for authentication. NAI/IMSI shall be included if the MN does not have a valid P-TMSI available. If the MN has a valid P-TMSI, then P-TMSI and the old RAI (Prefix) associated with P-TMSI shall be included in the ICMPv6 packet. If the MN identifies itself with P-TMSI and the IGSS has changed since detach, the new IGSS sends an Identification Request (P-TMSI, old RAI, old P-TMSI Signature) diameter message to the old IGSS to request the IMSI. The old IGSS responds with Identification Response (NAI/IMSI, Authentication Triplets). If the MN is not known in the old IGSS, the old IGSS responds with an appropriate error cause. The old IGSS also validates the old P-TMSI Signature and responds with an appropriate error cause if it does not match the value stored in the old IGSS. If the MN is unknown in both the old and new IGSS, the IGSS sends a DIAMETER Home-Agent-MIP-Request (Identity Type = IMSI) to the BSS. The MN responds and the BSS forwards with Identity Response (NAI/IMSI). If the IGSS address has changed since the IGPRS detach, or if it is the very first attach, then the IGSS informs the HLR: The IGSS sends an Update Location (IGSS IPv6 Address, NAI/IMSI) to the HLR through Diameter extensions. The HLR sends Cancel Location (IMSI, Cancellation Type) to the old IGSS with Cancellation Type set to Update Procedure. The old IGSS acknowledges with Cancel Location Ack (IMSI). If there are any ongoing procedures for that MN, the old IGSS shall wait until these procedures are finished before removing the contexts. The HLR sends Insert Subscriber Data (IMSI, IGPRS subscription data) to the new IGSS. The new IGSS validates the MN presence in the (new) RA. If due to regional subscription restrictions the MN is not allowed to attach in the RA, the IGSS rejects the Attach Request with an appropriate cause, and may return an Insert Subscriber Data Ack (IMSI, ) message to the HLR. If subscription checking fails for other reasons, the IGSS Page 8 GPRS Interface to Mobile IPv6 rejects the Attach Request with an appropriate cause and returns an Insert Subscriber Data Ack (IMSI, Cause) message to the HLR. If all checks are successful then the IGSS constructs a context for the MN and returns an Insert Subscriber Data Ack (IMSI) message to the HLR. The HLR acknowledges the Update Location message by sending an Update Location Ack to the SGSN after the cancelling of old context and insertion of new context are finished. If the Update Location is rejected by the HLR, the IGSS rejects the Attach Request from the MS with an appropriate cause. If the Attach Request cannot be accepted, the IGSS returns an Attach Reject (IMSI, Cause) message to the MN. Detach Function The Detach function allows an MN to inform the network that it wants to make a IGPRS and/or NAI/IMSI detach, and it allows the network to inform an MN that it has been IGPRS-detached or IMSI-detached by the network. The only proposed detach procedure is: - IGPRS detach; The MN is detached from IGPRS either explicitly or implicitly: - Explicit detach: The network or the MN explicitly requests detach. - Implicit detach: The network detaches the MN, without notifying the MN, a configuration-dependent time after the mobile reachable timer expired, or after an irrecoverable radio error causes disconnection of the logical link. In the explicit detach case, a Detach Request (Cause) is sent by the IGSS to the MN, or by the MN to the IGSS. 5 . 2 Mobility Management procedures Cell Update Procedure A cell update takes place when the MN enters a new cell inside the current RA and the MN is in READY state. If the RA has changed, a routing area update is executed instead of a cell update. The MN performs the cell update procedure by sending an uplink packet of any type containing the MN identity to the IGSS with a Hop-by-Hop option. In the direction towards the IGSS, the BSS shall add the Cell Global Identity including RAC to all packets. A cell update is any correctly received and valid IPv6 PDU. The IGSS records this change of cell so that further traffic directed towards the MN is conveyed over the new cell. Routing Area Update Procedure A routing area update takes place when a IGPRS-attached MN detects that it has entered a new RA i.e a different Home Agent domain, when the periodic RA update timer has expired, or when a suspended MN is not resumed by the BSS. The IGSS detects that it is the same sub- network. In this case, the IGSS has the necessary information about the MN and there is no need to inform HLR about the new MN location. A periodic RA update is always an intra IGSS routing area update. Intra IGSS Routing Area Update The Intra IGSS Routing Area Update procedure consists in a change of the default router for the MN while keeping the same HA. The MN sends a Routing Area Update Request (it is done via a v6 binding update) (old RAI, old P-TMSI Signature, Update Type) to the IGSS. Update Type shall indicate RA update or periodic RA update. The BSS shall add the Cell Identity as a Hop-by-hop option. The IGSS validates Page 9 GPRS Interface to Mobile IPv6 the MN presence in the new RA (sub-network). If due to regional subscription restrictions the MN is not allowed to be attached in the RA, or if subscription checking fails, then the IGSS rejects the routing area update. If all checks are successful then the IGSS updates the MN record. A new P-TMSI may be allocated. A confirmation is sent back to the mobile node (P-TMSI, P-TMSI Signature). If P-TMSI was reallocated, the MN acknowledges the new P-TMSI by returning a routing Area Update Complete AVP to the IGSS. If the routing area update procedure fails a maximum allowable number of times, or if the IGSS returns a routing Area Update Reject (Cause) AVP, the MN shall enter IDLE state. Inter IGSS Routing Area Update The Inter IGSS Routing Area Update procedure is explained in the following list. It consists in a change in the HA for the mobile node. The MN sends a Routing Area Update Request (binding update with the old HA address, old P-TMSI Signature, Update Type) to the new IGSS. Update Type shall indicate RA update or periodic RA update. The BSS shall add the Cell Global Identity in the Hop-by-hop option. The new IGSS sends Diameter AVP containing IGSS Context Request (old RAI, TLLI, old P-TMSI Signature, New IGSS Address) to the old IGSS for this MN. The old IGSS validates the old P-TMSI Signature and responds with an appropriate error cause if it does not match the value stored in the old IGSS. This should initiate the security functions in the new IGSS. If the security functions authenticate the MN correctly, the new IGSS shall send an IGSS Context Request (old RAI, TLLI, MN Validated, New IGSS Address) Diameter message to the old IGSS. MN Validated indicates that the new SGSN has authenticated the MN. These procedures are described in the context of the Diameter extensions in details. If the old P-TMSI Signature was valid or if the new IGSS indicates that it has authenticated the MN, the old IGSS stops assigning forwarding the traffic downlink, and responds with IGSS Context Response. If the MN is not known in the old IGSS, the old IGSS responds with an appropriate error cause. Contrary to the original GPRS mechanism where the SGSN adds a new entity in the chain, the IGSS which is a home agent cannot be changed while active contexts are present. In the absence of active contexts the inter IGSS procedure can be applied. A timer is triggered in the old IGSS. The new IGSS sends an IGSS Context Acknowledge message in the appropriate Diameter format to the old IGSS. This informs the old IGSS that the new IGSS is ready to receive data packets belonging to MN and the necessary DNS procedure are executed to change the MN prefix to the one belonging to the new IGSS. The old IGSS marks in its context that the information in the HLR is invalid. If the security functions do not authenticate the MN correctly, then the routing area update shall be rejected, and the new IGSS shall send a reject indication to the old IGSS. The old IGSS shall continue as if the IGSS Context Request was never received. The new IGSS updates the MN entry (new IGSS Address HA) The new IGSS informs the HLR of the change by sending Update Location (IGSS v6 address, IMSI) to the HLR. The HLR sends Cancel Location (IMSI, Cancellation Type) to the old IGSS with Cancellation Type set to Update Procedure (This is done with the Diameter protocol). Then the old IGSS removes the contexts. Otherwise, the contexts are removed only when the timer expires. This allows the old IGSS to ensure that the contexts are kept in the old SGSN in case the MN initiates another inter IGSS routing area update before completing the ongoing routing area update to the new IGSS. The old IGSS acknowledges with Cancel Location Page 10 GPRS Interface to Mobile IPv6 Ack (IMSI) The HLR sends Insert Subscriber Data (IMSI, IGPRS subscription data) to the new IGSS. The new IGSS validates the MN presence in the (new) RA. If due to regional subscription restrictions the MN is not allowed to be attached in the RA, the IGSS rejects the Routing Area Update Request with an appropriate cause, and may return an Insert Subscriber Data Ack message to the HLR. If all checks are successful then the IGSS constructs a context for the MN and returns an Insert Subscriber Data Ack (IMSI) message to the HLR. The HLR acknowledges the Update Location by sending Update Location Ack (IMSI) to the new IGSS. The new IGSS validates the MN presence in the new RA. If due to roaming restrictions the MN is not allowed to be attached in the IGSS, or if subscription checking fails, then the new IGSS rejects the routing area update with an appropriate cause. If all checks are successful then the new IGSS constructs contexts for the MN. The new IGSS responds to the MN with Routing Area Update Accept (P-TMSI, P-TMSI Signature). The MN acknowledges the new P-TMSI by returning a Routing Area Update Complete message to the IGSS. In the case of a rejected routing area update operation, due to regional subscription or roaming restrictions, the new IGSS shall not construct a context. A reject shall be returned to the MN with an appropriate cause. The MN shall not re-attempt a routing area update to that RA. The RAI value shall be deleted when the MN is powered-up. 6 . Security Considerations The Security function: - Guards against unauthorised IGPRS service usage (authentication and service request validation). - Provides user identity confidentiality (temporary identification- Regional Registration, and ciphering). - Provides user data confidentiality (ciphering). Authentication of Subscriber Authentication procedures already defined in GSM and in the Diameter strong authentication shall be used, with the distinction that the procedures are executed from the IGSS. The IGSS may act according to Diameter specifications as a proxy in a chain. The IGPRS Authentication procedure performs subscriber authentication, or selection of the ciphering algorithm and the synchronization of the start of ciphering, or both. Authentication triplets are stored in the IGSS. The Authentication procedure is explained in the following list. If the IGSS does not have previously stored authentication triplets, a Send Authentication Info (IMSI) message is sent to the HLR through the Diameter protocol proxying procedures. The HLR responds with a Send Authentication Info Ack (Authentication Triplets) message. Each Authentication Triplet includes RAND, SRES, and Kc. The IGSS sends an Authentication and Ciphering Request (RAND, CKSN, Ciphering Algorithm) message to the MN. The MN responds with an Authentication and Ciphering Response message through Diameter extensions. The MN starts ciphering after sending the Authentication and Ciphering Response message. The IGSS starts ciphering when a valid Authentication and Ciphering Response is received from the MN. In the routing area update case, if ciphering was used before the routing area update, and if the Authentication procedure is omitted, then the IGSS shall resume ciphering with the same Page 11 GPRS Interface to Mobile IPv6 algorithm when a ciphered Routing Area Update Accept Diameter message is sent, and the MN shall resume ciphering when a ciphered Routing Area Update Accept Diameter message is received. User Identity Confidentiality A Temporary Logical Link Identity (TLLI) identifies a IGPRS user. The relationship between TLLI and IMSI is known only in the MN and in the IGSS. TLLI is derived from the P- TMSI allocated by the IGSS or built by the MN. The IGSS may reallocate the P-TMSI at any time when the MN is in READY state. The reallocation procedure can be performed by the P-TMSI Reallocation procedure, or it can be included in the Attach or Routing Area Update Diameter procedures. P-TMSI Signature P-TMSI Signature is optionally sent by the IGSS to the MN in Attach Accept and Routing Area Update Accept Diameter messages. If the P- TMSI Signature has been sent by the IGSS to the MN since the current P-TMSI was allocated, then the MN shall include the P-TMSI Signature in the next Routing Area Update Request and Attach Request for identification checking purposes. In the Attach and Routing Area Update procedures, the IGSS shall compare the P-TMSI Signature sent by the MN with the signature stored in the IGSS. If the values do not match, the IGSS should use the security functions to authenticate the MN. If the values match or if the P-TMSI Signature is missing, the IGSS may use the security functions to authenticate the MN. The P-TMSI Signature parameter has only local significance in the IGSS that allocated the signature. If ciphering is supported by the network, the IGSS shall send the P-TMSI Signature ciphered to the MS. Routing Area Update Request and Attach Request, into which the MN includes the P-TMSI Signature, are not ciphered. IMEI This is the identification of the terminal. It can be required by a given operator. It is hence taken into consideration in the security functions. 7 . Security Functions P-TMSI Reallocation Procedure This is the procedure by which the MN will obtain a temporary key in the authentication domain of the new IGSS. Diameter messages will help the exchange of keys between the original and the new IGSS. At the end of the procedure the MN should receive a valid P-TMSI using the IKE protocol. Identity Check Procedure The Identity Check procedure is explained in the following list. 1) The IGSS sends Identity Request (Identity Type) to the MN. The MN responds with Identity Response (Mobile Identity). 2) If the IGSS decides to check the IMEI, it sends Check IMEI (IMEI) Diameter message to the BSS that translates it and forwards it to the MN. 0n) References Page 12 GPRS Interface to Mobile IPv6 [CHAP] CHAP, PPP Challenge Handshake Authentication Protocol. rfc- 1994. [GPRS] Draft ETSI EN 301 344 V6.6.0 (2000-02) European Standard (Telecommunications series) Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Service description; Stage 2 (GSM 03.60 version 6.6.0 Release 1997) [ADDRCONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. Authors may be reached at charliep@iprg.nokia.com hossam.afifi@int-evry.fr Page 13 GPRS Interface to Mobile IPv6